I'm going to use this opportunity to get up on my soap-box and talk about helm, the "recommended" way to install kubernetes packages.<p>Helm is not a useful abstraction, and needs to change in a BIG way before I consider using it over k8s_raw and ansible.<p>My main complaint with helm is that it doesn't allow one to develop decent abstractions over the core kubernetes resources. IMO it needs to move away from `gotpl` and implement the ability to use more sophisticated templating libraries.<p>I think this block of text elucidates my point:<p>```<p>metadata:<p><pre><code> name: {{ template "drupal.fullname" . }}
labels:
app: {{ template "drupal.fullname" . }}
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
release: "{{ .Release.Name }}"
heritage: "{{ .Release.Service }}"
</code></pre>
```<p>This block of code is in every single resource in every single helm chart. And it's one of MANY similar blocks of code that appear in basically every helm chart. I do not particularly enjoy writing the same massive YAML file over and over again.<p>Configuration management with helm is difficult. It would be nice to be able to declare "required" fields within an application, and enforce those fields with an error message if they are not provided. Currently, there is no way to do this other than having a "required" template that iterates through your "requiredFields" field and calls `{{ .Values.fieldName | required }}`<p>Interacting with the helm API server is difficult, which makes integrating helm with other configuration tools difficult. Specifically Ansible. This is also partly k8's fault ( And my fault, I suppose, because I could write it myself... ), because port-forwarding into the k8 server isn't implemented in any languages other than GoLang.
This article is pretty focused on the build type of k8s developer tools. There are other types as well that can fit into specific places in your workflow. Joe Beda does a fantastic high level overview of the different types in last week's #tgik8s: <a href="https://www.youtube.com/watch?v=QW85Y0Ug3KY" rel="nofollow">https://www.youtube.com/watch?v=QW85Y0Ug3KY</a> .<p>Here's a couple tools that try to tackle this problem in different ways:<p>- Ksync - `docker run -v local:remote` for your k8s cluster (<a href="https://github.com/vapor-ware/ksync" rel="nofollow">https://github.com/vapor-ware/ksync</a>)<p>- Telepresence - extend the cluster network locally (<a href="https://www.telepresence.io/" rel="nofollow">https://www.telepresence.io/</a>)<p>- Forge - end to end development through deployment (<a href="https://forge.sh/" rel="nofollow">https://forge.sh/</a>)
The breadth of different tool styles for Kubernetes is really interesting.<p>At Airbnb we’ve built a tool that’s most analogous to Ksonnet or Forge, but trades a lot of flexibility/extensibility for simplicity. We have this pre-baked model that your kube config has to fit into, and we don’t allow much direct pass through from our config files to raw kubernetes manifest. The upside is that limits the divergence of configuration between any two services, which greatly reduces bus factor and improves maintain ability. I’ve seen many a nightmare in our chef monorepo – no need to go back to ultra-flexible (even Turing complete!) configuration.<p>Another key feature is that there’s no special daemon or whatever required. Our build/deploy system runs the same commands you run on your laptop to build/deploy development versions to your dev kube. This increases anyone’s ability to introspect and debug the system, versus a tool with a daemon that’s doing who-knows-what, and you struggle to get debug access to the right parts.<p>I hope we can open source it one day, but right now it’s under heavy development and has lots of Airbnb-specific magicks built-in.
One tool not mentioned in the article is Jenkins X [0]. It leverages some of the technologies from draft to create a GitOps workflow for full build-push-deploy with CI and CD.<p>[0] <a href="http://jenkins-x.io/" rel="nofollow">http://jenkins-x.io/</a>
<a href="https://keel.sh/" rel="nofollow">https://keel.sh/</a> is also a great release manager / chatops framework.<p>edit: I had keel.io which is some random company. The site I wanted was keel.sh
At GitLab we're building an automated workflow that takes you from zero to k8s called Auto DevOps.<p>Some of the interaction points between Auto DevOps and Kubernetes are:<p>- deploying review apps<p>- deploying production applications<p>- supporting deployment of staging and canary environments<p>- monitoring performance<p>You can also:<p>- easily create a clusters on GKE through the GitLab UI<p>- easily install "helper" applications to set up the cluster<p>- easily install GitLab Runner to run Auto DevOps jobs on the cluster<p>You can read more about it here: <a href="https://docs.gitlab.com/ee/topics/autodevops/" rel="nofollow">https://docs.gitlab.com/ee/topics/autodevops/</a>