[k8s] Kubernetes terminology (1).pdf
0 likes63 views
This document provides an overview of common Kubernetes concepts including clusters, namespaces, nodes, pods, services, deployments, horizontal pod autoscaling, ingress, persistent volume claims, configmaps, statefulsets, jobs, cronjobs, monitoring, and logging. It also discusses best practices for deploying applications on Kubernetes including using deployments instead of regular pods, validating Helm upgrades, and monitoring for CPU throttling issues.
[k8s] Kubernetes terminology (1).pdf
- 2. Kubernetes basics 1. Cluster 2. Namespaces 3. Working with a cluster 4. Everything runs on Nodes 5. Pod 6. Service / Deployment 7. Horizontal Pod Autoscaler 8. Deployment strategy 9. Ingress 10. Persistent Volume Claim 11. Configmap 12. Statefullset 13. Job 14. Cron 15. Loadtesting 16. Monitoring 17. Logs Blogpost with some o this content
- 3. Clusters
- 4. 4 Cluster creation Manual in Code
- 5. 5 Working with clusters Tools for the job
- 6. Namespaces
- 7. Everything runs on Nodes
- 9. Pod - Service - Deployment - Autoscaling
- 10. Pod - Service - Deployment - Autoscaling NEED TO KNOW: HPA needs resource limitations set on pods & CPU < 1 will throttle your system.
- 11. 11 Kubernetes - autoscaling The cool stuff Describe the HPA Defined the pods as a deployment With resources ✨ cool stuff 💫
- 12. 12 Kubernetes - Deployment strategy ✨ more cool stuff 💫
- 13. 13 Drupal & Zero downtime deploys Schema updates No Schema updates
- 14. 14 Drupal Zero downtime deploys
- 15. 15 Ingress
- 16. 16 Persistent Volume Claim Pod Pod PVC Volume Claim Volume eg: /sites/default/files /tmp /private
- 17. 17 Configmap MAIN USE Especially practical if you want to use an external docker container image (eg memcache or varnish) with your specific config (without creating your own images)
- 18. 18 Configmap PRACTICAL FOR DEBUGGING Also super practical to add php.ini or nginx or apache config to your custom images. This adds the possibility to fiddle on an (obviously not production) environment with the config without a full build + deployment (which is slow). Change configmap + delete pod (triggers recreate with new config)
- 20. 20 StatefullSet eg: memcache or redis
- 23. 23 Cron
- 24. 24 Loadtesting (job) Put some traffic into it Rolling deploys Autoscaling Filemounts Reverse proxy cache Object Cache Cron Deployment K6 Loadtesting Monitoring sidecar
- 25. 25 Monitoring ⚠ ⚠ ⚠ Sidecars Prevent killing of pods. https://medium.com/finnovate-io/how-to-prevent-kubernetes-cron-jobs-with-sidecar-containers-from-getting- stuck-912c0f1497a3
- 26. 26 Logs
- 27. Infra as code
- 28. Infra as code This is the representation of the above kubernetes concept specifically for (normal) drupal drupal-helm-charts-k8s
- 29. Pitfalls W a r n i n g Fix your version All of a sudden you’re running a newer version of varnish in your cluster , this is something you want to test!
- 30. Pitfalls W a r n i n g # Validate helm to not leave a broken state. - name: DRY RUN run: | cd helm helm upgrade --dry-run --timeout 15m --install -n ${{ inputs.app_key }}-${{ inputs.environment }} -f values-${{ inputs.environment }}.yaml --set deploy.runid=${{ github.run_id }} --set image.tag=${{ inputs.version }} --set image.version=${{ inputs.version }} ${{ inputs.app_key }} . It’s not always correct (sometimes deploys still fail) but will fail if your syntax is wrong in your overrides and will prevent you bringing everything down. Do this before the actual deploy!
- 31. Pitfalls W a r n i n g - name: DRY RUN run: | cd helm helm upgrade --dry-run --timeout 15m --install -n ${{ inputs.app_key }}-${{ inputs.environment }} -f values-${{ inputs.environment }}.yaml --set deploy.runid=${{ github.run_id }} --set image.tag=${{ inputs.version }} --set image.version=${{ inputs.version }} ${{ inputs.app_key }} .
- 32. Pitfalls W a r n i n g The first month in PRD The CPU’s were throttling, even with not much load on the systems. Only after checking Dynatrace and tweaking the CPU from 500m to 1 the throttling disappeared (response time decrease & performance increase).
- 33. Pitfalls W a r n i n g regular POD <VS> Deployment Use a Deployment if you want the pods to be there after a cluster rebuild (eg. global outage). Obviously we learned this the hard way.