4 ms·

I don't currently use K8s, but am planning to get into it soon. Could you clarify the difference or advantage between using a Kubernetes specific package manage

I don't currently use K8s, but am planning to get into it soon. Could you clarify the difference or advantage between using a Kubernetes specific package manager like Helm vs using a container repository? Isn't part of the point of containers to use prebuilt immutable containers?

swozey 10y ago
I use Helm to deploy containers to various environments and clusters in k8s using its gotepl/sprig template system. The last thing that I want to do with my containers is to lock my environment variables inside of them, then I'm going to need multiple sets of containers per microservice (prod, staging, yaddayadda) and have to go through the process of docker commit, push, etc. Beyond that there are also a lot of Kubernetes specific variables that you want to be able to define before you launch pods. You often need to set namespaces, resource limits, labels, persistentDisks, etc, things that would not be defined in any docker container at all. I also use Helm to template that out. With Helm you can package the network config (load balancers, services), volumes, secrets, etc very easily. These are things that have nothing to do with the actual docker container lifecycle. There are a lot of kubernetes objects that need to be configured for an actual deployment.
- AlexB138 10y ago
  Thanks for the answer. So, again, coming from a place of having done a couple passes of the basics, but otherwise completely ignorant. What is the advantage of having that kind of config info baked into a package vs having it in etcd? Again, I really appreciate it.
  - joseph 10y ago
    When you deploy with Kubernetes, you need some yaml or json files to define the configuration of your stack. Depending on the complexity of the stack, this could grow to a significant number of files. Helm allows this collection of files to be put into a single shareable package. Then, rather than calling the 'kubectl' command a number of times to deploy each individual component, you'd make one call to Helm to do it all at once.
dkoston 10y ago
Immutable containers still may need specific names when they are launched, netowrking settings, etc. Helm holds your deployment configs. Think about having a redis cluster. You need 6 redis containers (at minimum), known names to add to your connection settings in your apps, a job container to run redis-trib, etc. Using helm has let us define a redis cluster configuration that we know works well and anyone at the company can now launch one just by flipping out the pod (container) names, setting a namespace, and configuring memory and CPU limits. For monolithic applications this stuff won't be super useful (or for simple software applications) but in a modern SOA, it saves us tons of time. Need a HA Postgres setup for your new microservice? Great, just change the name of the database pods to match your service name and run "helm install -f my-service-db.yaml postgres" For us at Help.com, it's the new Ansible. We run everything in kubernetes and Helm ensures we have consistent deployments of containers for database clusters, redis clusters, message queue clusters, etc. In addition, the delete feature is amazing when developing your configs. Previously we had to run a ton of kubectl commands to clean up after testing runs or put stuff in a specific namespace which we deleted and recreated. With Helm, we can simply delete a Helm release and it takes care of removing the pods, services, deployments, secrets, etc.

swozey 10y ago

I use Helm to deploy containers to various environments and clusters in k8s using its gotepl/sprig template system. The last thing that I want to do with my containers is to lock my environment variables inside of them, then I'm going to need multiple sets of containers per microservice (prod, staging, yaddayadda) and have to go through the process of docker commit, push, etc. Beyond that there are also a lot of Kubernetes specific variables that you want to be able to define before you launch pods. You often need to set namespaces, resource limits, labels, persistentDisks, etc, things that would not be defined in any docker container at all. I also use Helm to template that out. With Helm you can package the network config (load balancers, services), volumes, secrets, etc very easily. These are things that have nothing to do with the actual docker container lifecycle. There are a lot of kubernetes objects that need to be configured for an actual deployment.

AlexB138 10y ago
Thanks for the answer. So, again, coming from a place of having done a couple passes of the basics, but otherwise completely ignorant. What is the advantage of having that kind of config info baked into a package vs having it in etcd? Again, I really appreciate it.
- joseph 10y ago
  When you deploy with Kubernetes, you need some yaml or json files to define the configuration of your stack. Depending on the complexity of the stack, this could grow to a significant number of files. Helm allows this collection of files to be put into a single shareable package. Then, rather than calling the 'kubectl' command a number of times to deploy each individual component, you'd make one call to Helm to do it all at once.

dkoston 10y ago

Immutable containers still may need specific names when they are launched, netowrking settings, etc. Helm holds your deployment configs. Think about having a redis cluster. You need 6 redis containers (at minimum), known names to add to your connection settings in your apps, a job container to run redis-trib, etc. Using helm has let us define a redis cluster configuration that we know works well and anyone at the company can now launch one just by flipping out the pod (container) names, setting a namespace, and configuring memory and CPU limits. For monolithic applications this stuff won't be super useful (or for simple software applications) but in a modern SOA, it saves us tons of time. Need a HA Postgres setup for your new microservice? Great, just change the name of the database pods to match your service name and run "helm install -f my-service-db.yaml postgres" For us at Help.com, it's the new Ansible. We run everything in kubernetes and Helm ensures we have consistent deployments of containers for database clusters, redis clusters, message queue clusters, etc. In addition, the delete feature is amazing when developing your configs. Previously we had to run a ton of kubectl commands to clean up after testing runs or put stuff in a specific namespace which we deleted and recreated. With Helm, we can simply delete a Helm release and it takes care of removing the pods, services, deployments, secrets, etc.