From Docker Images over Kubernetes Manifests to Helm Charts

Container haben sich als Standardvehikel zur Bereitstellung und für den Betrieb von modernen Anwendungen etabliert. Kubernetes - ein zentraler Baustein im Betrieb von Cloud-Native-Anwendungen - fungiert als Plattform für unterschiedliche Anwendungsbestandteile.
In diesem Webinar zeigt Thorsten Hans, wie Sie containerisierte Anwendungen verteilen und in unterschiedlichen Kubernetes-Umgebungen bereitstellen können. Wo sollten Ihre Docker Images gespeichert sein? Wie schützen Sie diese? Und wie sieht die Bereitstellung in Kubernetes genau aus? Lernen Sie die etablierten Bereitstellungsmöglichkeiten wie Kubernetes-Manifeste und Helm Charts am praktischen Beispiel kennen.

Transcript

1. Vom Docker Image über Kubernetes-Manifeste hin zu Helm Charts Thorsten Hans @ThorstenHans Cloud-Native Consultant
2. Consultant @ Thinktecture #Azure #Kubernetes #CloudNative #Docker thorsten.hans@thinktecture.com thinktecture.com thorsten-hans.com @ThorstenHans Microsoft MVP | Docker Captain Thorsten Hans
3. What we won’t cover • Docker & Kubernetes Basics • Automated Deployments • Continuous Deployment • GitOps Non-Scope
4. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
5. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
6. • As developers we use Docker to run our dependencies and apps locally • We leverage Docker CLI to poke containers and images • From Ops perspective, Docker unifies packaging & distribution • Docker support is (almost) everywhere Introduction
7. However, having just a bunch of Docker images laying around is not enough. We must provide additional context, configuration, and instruct the application platform on how it should connect the dots between all components of the bigger system Introduction
8. • In Platform-as-a-Service (PaaS) like Azure App Services, we use service capabilities to provide context and configuration • AppSettings & ConnectionStrings • Autoscaling • Diagnostics • We orchestrate PaaS applications using additional cloud services (e.g. Azure Virtual Network, Azure Application Gateway, Azure Front Door, …) Introduction
9. • In Kubernetes, we provide context and configuration by providing corresponding Kubernetes Manifests • ConfigMap, Secret • HorizontalPodAutoscaler • Service • We deploy additional apps to a cluster to support advanced capabilities • We use Cert-Manager to create, rotate, and renew SSL certificates • We use Ingress Controllers to route requests to certain applications in Kubernetes Introduction
10. • Serverless services like Azure Container Apps are based on Kubernetes, their deployment manifests are a superset of regular Kubernetes Manifests • Knowledge about underlying Kubernetes manifests is a benefit • Microsoft.App/containerApps is a combination of • Kubernetes Deployment • Kubernetes Service • Kubernetes HorizontalPodAutoscaler Introduction
11. Bottom line, your Docker Images must be customizable or configurable to run in different environments without having to build a new Docker image when switching the application platform Introduction
12. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
13. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
14. We want to… • Run our Docker Image Kubernetes Manifests
15. We want to… • Run our Docker Image • Provide Configuration Kubernetes Manifests
16. We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption Kubernetes Manifests
17. We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption We use a Pod (the simplest way to run a particular Docker Image) in Kubernetes. Kubernetes Manifests
18. We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption • Run our application twice (replicas: 2) We use a Deployment (which technically contains a Pod spec) in Kubernetes to gain more control over the application at runtime and configure things like replications or upgrade strategies Kubernetes Manifests
19. In Kubernetes we enforce loose coupling by defining labels on resources like Pods. Other resources like HorizontalPodAutoscaler or Deployment are connected using label- selectors. Kubernetes Manifests
20. • Build Kubernetes Manifests for an ASP.NET Core WebAPI • Deploy the app to Kubernetes Demo
21. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
22. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
23. • Think of Helm (https://helm.sh) as the Kubernetes Package Manager • With Helm we can deploy applications (called Charts) • A Chart is • A collection of logically related Kubernetes manifests • A customizable set of values that allow customization upon deployment • When we install a Chart in a Kubernetes cluster, we create a Release • Helm leverages Kubernetes API server (no server-side component necessary) Helm Charts
24. • In Helm, templates are written using the Go Template Language • Helm comes with predefined functions & pipelines that we use in our templates • We can build custom helpers to address DRY and ensure consistency • Installing a Helm Chart is an atomic operation (no matter how many manifests are part of the Chart) • Helm Charts can have dependencies • Helm Charts are distributed using Helm Repositories or Docker Registries (OCI compliant artifacts) Helm Charts
25. • Create a Helm Chart for an ASP.NET Core WebAPI • Deploy a single Helm Chart with different configurations to Kubernetes Demo
26. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
27. • Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda
28. • Use decarative manifests instead of deploying applications imperatively with kubectl • Learn basic Kubernetes Resources (e.g. Deployment, Service, HorizontalPodAutoscaler) • This is also useful if your intent is to use services like Azure Container Apps • Due to indentions, YAML is painful enough! Don’t make it worse by putting multiple resources in a single YAML file • Applying multiple manifests with interconnectivities at once may result in errors • E.g. deploy resources to a namespace that is still being deployed by the same deployment command Conclusion
29. • Use Helm Chart for deploying your applications if • You deploy multiple replications of your app (either to a single or to multiple clusters) • Someone else has to deploy the application and must provide contextual configuration • Trim-down your Helm charts and allow only necessary configuration (values) • Think about implementing an umbrella chart for your entire application to simplify deployment even more • Lint your Helm charts before distributing them Conclusion
30. Thanks for your attention @ThorstenHans