Kubernetes: Extra Optional Exercises

Kubernetes: Extra Optional Exercises

This section contains a few ideas for expanding on what was done in the main lab. These are provided as pointers rather than step by step exercises

Basic Kubernetes Practices

  • Container Health Probes
    We havenโ€™t told Kubernetes any way to know if Smilr app containers it deployed were healthy and actually operational. A started container is not a direct indication of operational health. Kubernetes provides mechanisms called Liveness and Readiness Probes to give it an understanding of the health of the pods
    ๐Ÿ“˜ Liveness and Readiness Probes

  • Pod Resources
    We didnโ€™t provide Kubernetes with any information about how much memory or CPU our pods would need, or the max they should be allowed to use. This can be done with resource requests and resource limits, and it allows Kubernetes to better distribute pods across the nodes
    ๐Ÿ“˜ Managing Compute Resources

  • Auto Scaling
    We manually scaled our deployments, however there are many cases where you want the scaling up & down to be done automatically. This can be done with the Horizontal Pod Autoscaler
    ๐Ÿ“˜ Auto Scaling

  • Initialisation
    Rather than manually running the demoData script we could have used an InitContainer to run the script before starting the rest of the containers in the data-api pod
    ๐Ÿ“˜ Init Containers

Extending with Azure

Advanced

  • MongoDB Replication
    We skipped over this in the main lab, but it can be investigated as an extra task, it requires a โ€œsidecarโ€ container and the use of the StatefulSet we already set up. The sidecar container does some of the Mongo configuration for us
    ๐Ÿ“˜ Kubernetes sidecar for Mongo

  • Helm Chart
    We ended up with a lot of YAML files and in some of them we were making manual changes. Helm provides a way to package Kubernetes apps and manage all the YAML with templates. A Helm chart could be created for Smilr
    ๐Ÿ“˜ Azure Cosmos DB: MongoDB API