ContainerConf 2022: Kubernetes is awesome - but...

Kubernetes is awesome – but…
Continuous Lifecycle / Container Conf 2022

Who we are
© white duck GmbH 2022
Nico Meisenzahl (Head of DevOps Consulting and Operations,
Cloud Solution Architect, Azure & Developer Technologies MVP, GitLab Hero)
Email: nico.meisenzahl@whiteduck.de
Twitter: @nmeisenzahl
LinkedIn: https://www.linkedin.com/in/nicomeisenzahl/
Philip Welz (Senior Kubernetes & DevOps Engineer,
GitLab Hero, CKA, CKAD & CKS)
Twitter: @philip_welz
LinkedIn: https://www.linkedin.com/in/philip-welz

Agenda
• Kubernetes’ mission
• Kubernetes flexibility also leads to complexity
• 3 things you should ask yourself
• Development must be familiar with Kubernetes
• Some technical pitfalls we have seen

Our (white duck) focus / background
• “cloud-native”
• focused on cloud-only
• developer-centric consulting
• we heavily rely on PaaS and managed services
This is the context in which we work and have expertise.

KUBERNETES’ MISSION

Kubernetes …
• provides you with a framework to run distributed systems
resiliently
• takes care of scaling and failover for your application,
provides deployment patterns, and more
• aims to support an extremely diverse variety of workloads,
including stateless, stateful workloads and batch jobs

Allows you to …
• fully leverage the benefits of containers
• increase developer velocity
• deploy applications anywhere
• be cloud-agnostic
• run workloads efficiently
• operate cost efficient
• reduce Time to Market

Too good to be true?
Unfortunately, all that glitters isn’t gold.
Therefore, we decided to deliver this talk.

KUBERNETES FLEXIBILITY ALSO LEADS TO
COMPLEXITY

An example
• “why did you decide to use Kubernetes?”
• “because everyone uses it…”
• “what workload do you run?”
• “we containerized our monolithic stateful application”
• “we are running one container”
A common dialog with potential new clients.

Power but also complexity
• as mentioned, Kubernetes is very flexible that also brings
complexity
• this power can help you to speed up
• if you don’t use the power, you just end up with the complexity
Sadly, we see the latter far too often!

3 THINGS YOU SHOULD ASK YOURSELF

3 things you should ask yourself
1. do I need Kubernetes?
2. does my workload work well with Kubernetes?
3. do I have the people power and knowledge?

Do I need Kubernetes?
• do you run more than one instance?
• do you require advanced deployment/rollout options?
• do you need to scale in/out quickly?
• do you need to scale parts of your application?

Does my workload work well with Kubernetes?
• is your application containerized or containerizable?
• did you follow “the twelve factors”?
• https://12factor.net
• is your application stateless or at least state aware?
• are your able to scale in/out?

Do I have the people power and knowledge?
• operating your cluster requires a team or at least
dedicated time
• also, when using managed Cloud offerings!
• the Kubernetes ecosystem slowed down a bit but is still
fast changing
• 3 releases a year with 12 month of support each
• so do the managed Cloud offerings
• most of them are the cloud providers most-scaling services

Teams having trouble staying ahead of the curve
• “I’m doing a cluster update now and then”
• no dedicated team or time to maintain the cluster
• not being part of the ecosystem and therefore not up-to-date
This can lead to not understanding/seeing dependencies
and a lot of trouble!

An example
• application isn’t reachable after updating a managed
cluster
• update also introduced an updated Ingress Controller, that
enforced Ingress Class (what was mentioned in the docs)
• Ingress Class was missing in all Ingress manifests
• also, Cert Manager HTTP challenges stopped working
• what was realized weeks later after the certificates expired
• just one of many…

DEVELOPMENT MUST BE FAMILIAR
WITH KUBERNETES

Awareness is important
• not every developer needs to be a Kubernetes expert
• but knowing the basics, features and patterns is important to
build successful applications
• a containerized/Kubernetes-based developer inner loop
can
• help to gain awareness and learn basics
• enable teams to be able to debug production systems
• unfortunately, dev teams sometimes completely rely on
operations (how you shouldn’t do it)

SOME TECHNICAL PITFALLS WE HAVE SEEN

Challenges with databases and data services
• if you believe the Internet, the database or data service is just
a “helm install” away
• that is true, but don’t miss Day-2 operations
• you will have to think about and implement high availability,
security, backup of your service as well as your storage
solution
• we recommend using PaaS outside the cluster (if possible)
• this allows you to focus on the important things – implementing
features

Persistent storage with Kubernetes
• you will need a dedicated team to handle this
• just being a Kubernetes expert will not be enough
• Database administrator
• Storage administrator
• Cloud engineer
• can cause issues when scaling nodes
• also, cluster operations can get more complex with stateful
applications
• think of blue/green cluster deployments

The downside of (Micro-)Monolith
• you can run them in Kubernetes but it’s just not great
• we already talked about having the power but not using it
• an example
• most of the time monolith applications aren’t stateless
• e.g., persisting sessions locally
• you will have to invest to make them stateless or at least state-
aware or rely on sticky sessions.
• even if you can scale them, you can just scale your whole
application
• having a complex upgrade task or manual/complex
configuration steps are other examples

Missing Pod Disruption Budget
• they are missing 99% of the time
• helps you run highly available applications even when you
introduce frequent voluntary disruptions
• root causes might be
• a newer feature (staying ahead of the curve)
• not part of the “helm create” templates
• that being said, it needs to be done right

The importance of health probes
• Kubernetes needs them to know what's going on
• examples we saw
• /healthz delivering an HTTP 200 – always
• relying on external dependencies
• same checks for liveness and readiness
• another good example for “dev needs K8s awareness”
• if done right, health probes can help with throttling/self-
healing

Kubernetes/Container Security
• unfortunately, sometimes totally underrated
• a good starting point include
• secure application / deployment code (SAST, SBOM)
• secure container images (selfcontained, distroless)
• Kubernetes policies
• Kubernetes Network policies
• Container Runtime Security
• more details: https://github.com/nmeisenzahl/hijack-kubernetes

Still, …
we love Kubernetes!

Questions?
Nico Meisenzahl (Head of DevOps Consulting and Operations,
Cloud Solution Architect, Azure & Developer Technologies MVP, GitLab Hero)
Email: nico.meisenzahl@whiteduck.de
Twitter: @nmeisenzahl
LinkedIn: https://www.linkedin.com/in/nicomeisenzahl/
Philip Welz (Senior Kubernetes & DevOps Engineer,
GitLab Hero, CKA, CKAD & CKS)
Twitter: @philip_welz
LinkedIn: https://www.linkedin.com/in/philip-welz
Slides: https://www.slideshare.net/nmeisenzahl

ContainerConf 2022: Kubernetes is awesome - but...

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a ContainerConf 2022: Kubernetes is awesome - but...

Semelhante a ContainerConf 2022: Kubernetes is awesome - but... (20)

Mais de Nico Meisenzahl

Mais de Nico Meisenzahl (19)

Último

Último (20)

ContainerConf 2022: Kubernetes is awesome - but...