appconduits: manage custom Ingresses via Helm
Generally there are two large parts involved with making an application available on k8s (Kubernetes). First is deploying your service/application. Second is making it available on well known endpoints (i.e. via known FQDNs). In k8s there are many different approaches to handling the latter, however one popular way involves declaring and wiring up some combination of one or more Services and/or Ingress definitions.
You can think of of these distinct combinations of well known “hosts” defined on k8s Ingress objects and the Services they route traffic to as well established pipelines for traffic… or “conduits”. These should be treated as first class manageable “things” in one’s deployment footprint for apps, because often you can use them to do very cool things, such has better handle the rollout of new versions, implement canary release traffic flows and on and on.
When you deploy a new version of your application, you can do so via updating an existing k8s Deployment and utilize its capability to handle rolling out your new image by scaling down the old version’s ReplicaSet and bringing up a new one. However an alternative is that you can treat each new app image version as a totally new Deployment and control how traffic flows to it via dedicated Ingress/Service conduits. You do this by altering how much of that live/hot traffic can hit your new Deployment version, all, 50%, or cut it off all together. I like this strategy of unique Deployments per version, because when you release a new Deployment, your old one still remains running…. you just migrate traffic away from it and if you need to revert, there is no lag time in bringing it back online waiting for containers to start; you just send traffic back to it. All of this of course is dependent upon your choice of Ingress Controller (personally I really like Traefik)!
Treat conduits as a 1st class thing
IMHO every unique “host” traffic conduit (Ingress/Service) that can flow traffic to applications should be treated as a 1st class thing that you manage entirely separate from the apps you are deploying. Out of the box, declaring, updating and managing a bunch of separate Ingress/Service objects in k8s is a bit verbose. Secondly manually keeping track of all these YAMLs required for each logical traffic conduit is a bit of a pain, so ideally having a Helm chart for this would be great…. as well as a bit simplified way of expressing a “conduit” that can be translated and generated into the actual YAML that will field Ingress/Services to k8s.
Born from this idea, I created the appconduits Helm chart. Its is a small helm chart you can use to define “conduits” as described above (and in the diagram below) and manage them as distinct functional units.
Check it out at: https://github.com/bitsofinfo/appconduits
Originally published at http://bitsofinfo.wordpress.com on July 12, 2019.