A presentation at PHPMiNDS in July 2020 in by Marcus Noble
Marcus Noble @Marcus_Noble_ / AverageMarcus MarcusNoble.co.uk Senior DevOps Engineer @ Elsevier
What I’m going to cover
Some assumptions:
So, what is Kubernetes then? Lets take a look at the official tagline
“Production-Grade Container Orchestration” kubernetes.io What does that even mean? Lets use an strained analogy to put things in place…
Docker containers. Small, packaged, all-included distribution of software.
Container ship - each worker node. Holds many containers. An aside - docker-compose would be the captain of the ship if used in this analogy (single node, controlling all the containers)
Shipping control - Kuberentes Manages what container goes where. Plans out schedules, routes, etc. Handles communication.
Kubernetes Concepts
Pod Smallest controllable unit in Kubernetes Contains 1+ containers Performs a workload Limited use on its own, is a building block All containers in a pod share the same localhost network. Files and directories can be shared using volume mounts (e.g. emptyDir) but each container has it’s own filesystem
Labels Metadata that Kubernetes can use to make decisions Used by “selectors” to link resources Can be used to lookup/filter resources Annotations are a similar metadata but doesn’t have any explicit meaning or purpose, they are more free-form. Although often used by applications to trigger logic.
Deployment Enhancement on top of Pods Ensures a set number of pods are always available (replicas) Handle updates to pods (rolling updates or recreates) Generally the most common resource you’ll work with. Controls pods based on labels.
DaemonSet Schedules pods on every node (scales with your cluster) Specific nodes can be targeted using taints and tolerations (e.g. only run on worker nodes) Generally used for “system” applications such as log collectors, metrics or ingress controllers
Service Acts as basic load balancers for pods Handles communication to multiple pods running the same workload (multiple replicas) Acts as service discovery within the Kubernetes cluster Can be of type “ClusterIP”, “NodePort” or “LoadBalancer” Service discovery via DNS ClusterIP - Single IP only within the cluster that sits in front of all matching pods NodePort - Attached to a port on the host instance and available outside of the cluster LoadBalancer - In a cloud environment it will trigger the creation of a native load balancer (such as an ELB in AWS)
Ingress Provides external access to a service Functionality handled by an Ingress Controller (e.g. Skipper, Traefik, Istio, etc.) Not handled natively by Kubernetes itself
ConfigMap / Secret Mounted into pods as either environment variables or as files Can be used by multiple pods Secrets stored base64 encoded. Encryption depends on how control plane is configured. Secrets can be used for pulling of container images that require authentication
More… Jobs / CronJobs Namespaces Persistent Volumes StatefulSets Service Accounts Admission/Mutation Webhooks Roles (RBAC - Role Based Access Control) … Custom Resource Definitions (CRD)
Why Use Kubernetes?
Self Healing Kubernetes constantly checks the state of all resources against the provided “desired state” and does whatever it can to correct any difference. https://www.pexels.com/photo/brown-and-white-bear-plush-toy-42230/ Pods within a deployment replaced with new pods when one fails. Issue pulling image - try again (with backoff) Service endpoints updated when pods change Stop routing traffic to pods that failed health checks Prevent scheduling new work on unhealthy worker nodes
Infrastructure as Code Kubernetes highly encourages infrastructure as code by having its desired state provided as yaml or json. https://www.pexels.com/photo/abstract-business-code-coding-276452/ While not strictly enforced, you can make changes using the api, it is heavily encouraged. All API changes in effect update the stored desired state - which can then be retrieved if needed.
Resource Optimisation Leverage bin packing to get more workloads onto a single instance. CPU and Memory resources can be allocated / limited to make the best use of your instances. This has the added benefit of helping with cost saving. https://www.pexels.com/photo/box-with-objects-wrapped-in-brown-paper-for-moving-4246242/ This works best when you have a general idea of your applications upper CPU/mem limits and provide that as part of your pod spec
Modular / Extensible Kubernetes allows you to replace much of the core functionality, such as networking, storage and ingress controllers. Additional functionality can be added with the use of Custom Resource Definitions and admission or mutation webhooks. https://www.pexels.com/photo/wood-playing-colorful-colourful-105855/ This is a huge benefit for enterprise consumers as it gives a way to bake in corporate policies and build workaround solutions to help old applications work in a container environment.
“Portable” Kubernetes can run almost anywhere making it a somewhat portable platform to build upon. Be warned though, it’s not so easy to simply lift and shift your clusters workloads from one cloud provider to another. https://www.pexels.com/photo/bicycle-with-flag-3187148/ Be aware! While the platform / workloads can’t easily be lifted and shifted between clouds the understanding and skills around Kubernetes can.
How to get started
Resources Kind - Kubernetes In Docker [https://github.com/kubernetes-sigs/kind] Runs within Docker and allows you to choose the version of Kubernetes you want to run. Very useful for testing and local development. K3S - Lightweight Kubernetes [https://k3s.io/] A small, ready to go Kubernetes setup that you can install on your own servers. Comes with everything needed to get up and running. Managed services: AWS EKS, Google GKE, Azure AKS, Scaleway Kapsule, Civo Kube100, etc… Katacoda -Learn Kubernetes with interactive scenarios [https://www.katacoda.com/courses/kubernetes]
Thank You!