Kubernetes Production Patterns and Anti-Patterns

Good news about zombies: Kubernetes will soon solve this by having the pause container (which is automatically included in every pod) automatically reap children. [1]<p>Note that this change depends on the shared PID namespace support, which a larger, still-ongoing endeavour [2].<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;commit&#x2F;81d27aa23969b77f5e7e565b0b69234537b0503e" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;commit&#x2F;81d27aa23969...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;issues&#x2F;1615" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;issues&#x2F;1615</a>

This is an excellent check-list of both kubernetes and docker gotchas to avoid.<p>Coming into the k8s ecosystem with very little container experience has been a steep learning curve, and simple, concrete suggestions like this go a LONG way to leveling it out.

We&#x27;ve also published some other workshops for Docker and Kubernetes that we take customers through when onboarding (if needed): <a href="https:&#x2F;&#x2F;github.com&#x2F;gravitational&#x2F;workshop" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gravitational&#x2F;workshop</a><p>Feel free to take them for a spin and feedback welcome and appreciated.

I would like to have seen more &quot;patterns&quot; regarding configuration.<p>Right now, we have a bunch of microservices. Most of them talk to our shared infrastructure. We started with single configuration file, which has grown to monstrous proportions, and is mounted on every pod as a config map.<p>What would be the correct approach? Multiple configmaps with redundant information are just as bad, if not worse.

Might be worth mentioning about Docker&#x27;s native support for multi stage builds: <a href="https:&#x2F;&#x2F;docs.docker.com&#x2F;engine&#x2F;userguide&#x2F;eng-image&#x2F;multistage-build&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.docker.com&#x2F;engine&#x2F;userguide&#x2F;eng-image&#x2F;multistag...</a> (still quite a new feature, plenty of people won&#x27;t have it yet I guess)<p>Edit: oh, you kind of do. Well, it&#x27;s not upcoming any more, it&#x27;s in the latest Docker CE :)

Have you tried out istio yet? It&#x27;s the packaging of Lyft&#x27;s Envoy that Google and IBM are putting together to handle your last two points, circuit breaking and rate limiting and much more.

Awesome github repo! I think i need to incorporated some of your patterns into my work ;)<p>If some of you are interested in Kubernetes GPU cluster for deep learning, this article might be good to read as well. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14526807" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14526807</a>

The presentation of patterns here is quite helpful. Is anyone aware of other resources for container design patterns?<p>The k8s blog has some as well: <a href="http:&#x2F;&#x2F;blog.kubernetes.io&#x2F;2016&#x2F;06&#x2F;container-design-patterns.html" rel="nofollow">http:&#x2F;&#x2F;blog.kubernetes.io&#x2F;2016&#x2F;06&#x2F;container-design-patterns....</a>

Have you tried using Habitat? It pairs nicely with Kubernetes and solves alot of these antipatterns I feel like.<p><a href="https:&#x2F;&#x2F;habitat.sh" rel="nofollow">https:&#x2F;&#x2F;habitat.sh</a><p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-yTeXCY3iM0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-yTeXCY3iM0</a>

Some background on these workshops: we (Gravitational) help SaaS companies package their applications into Kubernetes, this makes them deployable into on-premise environments [1]. This in itself is an unexpected and quite awesome benefit of adopting Kubernetes in your organization: your stack becomes one-click portable.<p>[1] <a href="http:&#x2F;&#x2F;gravitational.com&#x2F;telekube" rel="nofollow">http:&#x2F;&#x2F;gravitational.com&#x2F;telekube</a>

what are everyone&#x27;s thoughts on building containers for running one time binaries? like building a container to run jq or awk or something like that.<p>i&#x27;ve seen this pattern before and it didnt make me feel very good. it reeks of unnecessary complexity.

we use kubernetes, helm and gitlab.. runtime configuration lives in each repo next to code - values.yaml, dev.yaml, test.yaml, prod.yaml to store applications runtime configuration -- each environment is host to 40+ redundant services.. its working quite well but has required a pretty big upfront investment... surprised there was much discussion about monitoring- prometheus and grafana work well for that

Awesome article!

&gt; Anti-Pattern: Direct Use Of Pods &gt; Kubernetes Pod is a building block that itself is not durable.<p>Kind of.. but you can set `restartPolicy: Always` and will always restart in case of failure.