This looks really cool! Hopefully it scratches the same itch docker-compose did a long time ago, but for those running Kubernetes.
I was just talking to a coworker this morning about how Helm is great, but its very analogous to debs or rpms: You would use it all day to install core-libraries (or services for k8s) on your system (or cluster), but probably not your first choice for shipping your business application.
I know, with Helm you can update a value for an image of a "release" (Helm term for an installed chart): but you hand off the upgrade of the application to the Tiller server to manage. If anything in your deployment goes south, Kubernetes will just keep trying to push it out until it works or is manually rolled back. Until Kubernetes gets automated rollbacks (https://github.com/kubernetes/kubernetes/issues/23211), this can be less than ideal.
Going with the rpm/deb analogy, I prefer to use something that would take the place of Puppet/Ansible (like Spinnaker) for _my_ applications I release, and still use Helm for the cluster level services like monitoring, logging, etc.
Impressive. We've been steadfastly trying to move away from dev-environments-in-the-cloud (cost minifying) but here's a clean, abstracted way to pull it off without the same VM overhead.
Curious how you would handle a) making sure those dev pods die off, and b) collisions between multiple devs working on the same project.
Disclosure: lead eng for azure containers and kubernetes founder here...
a) For the longest time, I've wanted a "TTL" extension for Kubernetes objects, maybe this is a good excuse to build it. But concretely, since you are paying for the VMs in the cluster (IaaS) the Pods you deploy are "free" (until you run out of cluster capacity, of course)
b) The right way to do this is Kubernetes namespaces. You can specify a different Namespace in each user's draft config file that will place each developer's containers in a different namespace.
Now that I write that, though, that seems like too much work. We should probably automagically build a unique namespace for you...
I'm medium-convinced that Kubernetes will take over the world as soon as someone makes it trivially easy to do k8s dev on a MacBook. Looks like this could get there.
5 comments
[ 4.6 ms ] story [ 28.7 ms ] threadI was just talking to a coworker this morning about how Helm is great, but its very analogous to debs or rpms: You would use it all day to install core-libraries (or services for k8s) on your system (or cluster), but probably not your first choice for shipping your business application.
I know, with Helm you can update a value for an image of a "release" (Helm term for an installed chart): but you hand off the upgrade of the application to the Tiller server to manage. If anything in your deployment goes south, Kubernetes will just keep trying to push it out until it works or is manually rolled back. Until Kubernetes gets automated rollbacks (https://github.com/kubernetes/kubernetes/issues/23211), this can be less than ideal.
Going with the rpm/deb analogy, I prefer to use something that would take the place of Puppet/Ansible (like Spinnaker) for _my_ applications I release, and still use Helm for the cluster level services like monitoring, logging, etc.
[same comment on other link]
Curious how you would handle a) making sure those dev pods die off, and b) collisions between multiple devs working on the same project.
a) For the longest time, I've wanted a "TTL" extension for Kubernetes objects, maybe this is a good excuse to build it. But concretely, since you are paying for the VMs in the cluster (IaaS) the Pods you deploy are "free" (until you run out of cluster capacity, of course)
b) The right way to do this is Kubernetes namespaces. You can specify a different Namespace in each user's draft config file that will place each developer's containers in a different namespace.
Now that I write that, though, that seems like too much work. We should probably automagically build a unique namespace for you...