Containers and Kubernetes -Notes Leo
- 1. Containers and Kubernetes Leo’s Notes Leopold Gault
- 3. Program Agenda 1. Containers: 1. The need for containers 2. Technical overview of containers 2. Kubernetes: 1. The need for Kubernetes 2. Technical overview of Kubernetes
- 4. Program Agenda 1. Containers: 1. The need for containers 2. Technical overview of containers 2. Kubernetes: 1. The need for Kubernetes 2. Technical overview of Kubernetes
- 5. The need for containers 1. The need for micro-services 2. The need for infrastructure as code
- 6. Monolithic vs SOA vs Microservice
- 7. Monolithic applications VS Microservices Monolithic application Microservices (APIs)
- 8. Monolithic applications VS Microservices Monolithic cake Microservices cake
- 9. The need for containers 1. The need for micro-services 2. The need for infrastructure as code Subject covered orally
- 10. Program Agenda 1. Containers: 1. The need for containers 2. Technical overview of containers 2. Kubernetes: 1. The need for Kubernetes 2. Technical overview of Kubernetes
- 11. Containers: what they are A container is an image of a set of applications and configuration- data. Such image is: • Immutable • Portable • Can be saved in a “photo album”: an images-repository.
- 12. Virtual Machines vs. Containers Virtual Machines ● Each virtual machine (VM) includes the app, the necessary binaries and libraries and an entire guest operating system Containers ● Containers include the app & all of its dependencies, but share the OS kernel with other containers. ● Run as an isolated process in the userspace of the host OS VMs Containers
- 13. Let’s have a look at Wikipedia’s listing Different levels of virtualization source Version of 14th Sept 2017
- 14. Different types of containers • Linux Containers (LXC) • OpenVZ • Warden Containers (used by Pivotal CloudFoundry) • RKT (developed by CoreOS) • Docker • Implementations of the Open Containers Initiative (OCI) • … OS-level virtualization solutions
- 15. Dockerfile Container image docker build Repo Docker registry docker run Container runtime: Linux kernel + Docker engine Highlight about Docker
- 16. Building container images My mongoDB : FROM ubuntu_base_image RUN apt-get update RUN apt-get install mongoDB EXPOSE 8080 ENTRY POINT /uns/binn/mongoDb DockerFile Ubuntu_base_image (from private or public registry) Docker deamon > docker build Container image Repo My Docker registry Leo’s container image
- 17. Container image Repo Docker registry docker run -p 4000 :8080 friendlyhello Container runtime: Linux kernel + Docker engine :8080 :4000
- 18. About building images on top of other images Files that are removed by subsequent layers in the system are actually still present in the images; they’re just inaccessible. E.g. In terms of building images, this also means that if server.js is changed, layer B and layer C will have to be rebuilt (so you have to order your layers from the least likely to change to most likely) Image Image Image Although “BigFile” is no longer accessible in the image ‘Layer C’, it is still present in Layer A, which Layer C is built on. With the right tools, BigFile can still be accessed by anyone having access to the image Layer C. In terms of network traffic, this also means that whenever you push or pull Layer C, BigFile is still transmitted through the network.
- 19. Program Agenda 1. Containers: 1. The need for containers 2. Technical overview of containers 2. Kubernetes: 1. The need for Kubernetes 2. Technical overview of Kubernetes
- 20. The need for Kubernetes 1. The need for declarative infrastructure as code 2. The need for cluster management of container-engines Subject covered orally
- 21. The need for Kubernetes 1. The need for declarative infrastructure as code 2. The need for cluster management of container-engines
- 22. Containers management platforms Manage distributed containers, and their lifecycle Containers Management Platform
- 23. Containers management platforms Manage distributed containers, and their lifecycle Docker Swarm
- 24. Program Agenda 1. Containers: 1. The need for containers 2. Technical overview of containers 2. Kubernetes: 1. The need for Kubernetes 2. Technical overview of Kubernetes
- 25. Components of a K8s cluster
- 26. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to Master node Worker node cloud-controller-manager It is the front-end for the Kubernetes control plane controls kube-proxy Container runtime (Docker, rkt, runc, etc.)
- 27. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to Master node Worker node cloud-controller-manager Distributed key-value store. Provides a dynamic configuration registry. controls kube-proxy Container runtime (Docker, rkt, runc, etc.)
- 28. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to Master node Worker node cloud-controller-manager Watches newly created pods that have no node assigned yet, and selects a node for them to run on. controls kube-proxy Container runtime (Docker, rkt, runc, etc.)
- 29. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to Master node Worker node cloud-controller-manager controls kube-proxy Container runtime (Docker, rkt, runc, etc.) Component on the master that runs controllers. These controllers include: • Node Controller: detects when nodes go down, and responds. • Replication Controller: maintains the correct number of pods for every replication controller object (replicaset?) in the system. • Endpoints Controller: deploys the “Endpoints object” (i.e. services and pods) into the cluster. • Service Account & Token Controllers: Creates default accounts and API access tokens for new namespaces.
- 30. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to Master node Worker node cloud-controller-manager controls kube-proxy Container runtime (Docker, rkt, runc, etc.) Runs controllers that interact with the underlying cloud providers. Those controllers are specific to the cloud-provider. Those controllers are: • Node Controller: when a node stops responding, it checks with the cloud provider to determine if this node has been deleted • Route Controller: sets up routes in the underlying cloud infrastructure • Service Controller: creates, updates and deletes cloud provider load balancers • Volume Controller: creates, attaches, and mounts volumes, and interacts with the cloud provider to orchestrate volumes
- 31. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to controls Master node Worker node cloud-controller-manager Makes sure that containers are running in a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. kube-proxy Container runtime (Docker, rkt, runc, etc.)
- 32. Components of a cluster kube-apiserver etcd kube-scheduler kube-controller-manager Kubelet connected to controls Master node Worker node cloud-controller-manager kube-proxy Enables the Kubernetes service abstraction by maintaining network rules on the host and performing connection forwarding. Container runtime (Docker, rkt, runc, etc.)
- 34. Pods IP2 Shared storage Node 1 IP1 Shared storage (volume) Leo: You normally put in a pod just one container, or a handful of containers that are tightly coupled (e.g. a Tomcat container + a Git syncrhonizer; with both apps interacting thru a local filesystem). You achieve horizontal scaling by replicating pods; not by replicating containers within a pod. Created from an image
- 35. Example of anti-pattern Pod Node 1 IP1
- 36. Pod spec Example of pod spec
- 37. Communication between containers within a same pod Node 1 IP1 Shared storage (volume) From: localhost:8080 To: localhost:3306 Kubernetes has an “IP-per-pod model”: containers within a same pod share the same IP address, and communicate with each other using distinct ports, on localhost. I know this is anti-pattern. It is just an example.
- 38. Pods and network Private overlay network within the Kubernetes cluster Node 1 Node 2 Real network IP3IP1 IP2
- 39. The need for services Private overlay network within the Kubernetes cluster Node 1 Node 2 Real network IP3IP1 IP2 Weblogic cluster Managed server1 Managed server2 App which is a client of the Weblogic cluster
- 40. Services and network Private overlay network within the Kubernetes cluster Node 1 Node 2 Real network IP3 ServiceA IP4 IP1 IP2 Acts like a LB between Pods
- 41. Service A level of abstraction providing an external and durable access to a set of pods. A service : • encompasses serval Pods, • has its own (private) IP (thus allowing consuming services to use the Service’s IP, instead of the Pod’s, which may change frequently), • load balances the IP packets it receives to its Pods.
- 42. Services and network Private overlay network within the Kubernetes cluster Node 1 Node 2 Real network IP3 ServiceA IP4 IP1 IP2 Can optionally be made reachable from the real network Acts like a LB between Pods
- 43. Services and network Private overlay network within the Kubernetes cluster Real network IP3 ServiceA IP4 IP1 IP2 Can optionally be made reachable from the real network Port of your choosing E.g. with the service-type “NodePort”: each hosting node will act as a NAT server specifically for this IP; i.e. it will associate one of its port to the IP4 Acts like a LB between Pods Port of your choosing
- 44. Service A level of abstraction providing an external and durable access to a set of pods. A service : • encompasses serval Pods, • has its own (private) IP (thus allowing consuming services to use the Service’s IP, instead of the Pod’s, which may change frequently), • load balances the IP packets it receives to its Pods. • Provides 3 types of access: • ClusterIP: the service is only visible from inside the cluster
- 45. Services and network Private overlay network within the Kubernetes cluster Node 1 Node 2 Real network IP3 ServiceA IP4 IP1 IP2 Acts like a LB between Pods
- 46. Service A level of abstraction providing an external and durable access to a set of pods. A service : • encompasses serval Pods, • has its own (private) IP (thus allowing consuming services to use the Service’s IP, instead of the Pod’s, which may change frequently), • load balances the IP packets it receives to its Pods. • Provides 3 types of access: • ClusterIP: the service is only visible from inside the cluster • NodePort: each node in the cluster maps an external port to the service’s private IP
- 47. Services and network Private overlay network within the Kubernetes cluster Real network IP3 ServiceA IP4 IP1 IP2 Can optionally be made reachable from the real network Port of your choosing E.g. with the service-type “NodePort”: each hosting node will act as a NAT server specifically for this IP; i.e. it will associate one of its port to the IP4 Acts like a LB between Pods Port of your choosing
- 48. Service A level of abstraction providing an external and durable access to a set of pods. A service : • encompasses serval Pods, • has its own (private) IP (thus allowing consuming services to use the Service’s IP, instead of the Pod’s, which may change frequently), • load balances the IP packets it receives to its Pods. • Provides 3 types of access: • ClusterIP: the service is only visible from inside the cluster • NodePort: each node in the cluster maps an external port to the service’s private IP • LoadBalancer: a LB from the cloud provider will forward the traffic from the service the nodes within it. (like NodePort, but on top of this, an external LB is configured to balance the traffic between the nodes:servicePort?)
- 49. Services and network Private overlay network within the Kubernetes cluster Real (private) network IP3 ServiceA IP4 IP1 IP2 Port of your choosing Acts like a LB between Pods Port of your choosing load balancer (cloud service)
- 50. Services identify their pods (and deployments) thanks to labels
- 51. Deployment features Additional: enforce replicasets, by • deploying the pods, • monitoring them, • Stop/restart them, • redeploying them on another node if needed. • Perform rolling updates • Undo an update if requested Deployments Deployments are a declarative way to ensure that the number of Pods running is equal to what the user declared to want. Deployments keep our Pods up and running, even when the nodes they run on fail. If Pods are declaratively updated (e.g. container image changed) or scaled, the Deployment will handle that.
- 52. Deployment spec vs Pod spec Example of deployment Example of pod The same as a pod spec Specific to deployment spec
- 53. Deployment spec vs Pod spec Example of deployment Example of pod The same as a pod spec Specific to deployment spec
- 54. Deployment spec vs Pod spec Example of deployment Example of pod The same as a pod spec Specific to deployment spec Services identify their pods, and thus their deployments, thanks to labels
- 56. E.g. of deployment spec apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 2 pods matching the template template: # create pods using pod definition in this template metadata: # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is # generated from the deployment name labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 deployment.yaml
Editor's Notes
- #14: https://en.wikipedia.org/wiki/Template:Virtualization_software
- #35: Kubernetes applies IP addresses at the Pod scope - containers within a Pod share their network namespaces - including their IP address. This means that containers within a Pod can all reach each other’s ports on localhost. This does imply that containers within a Pod must coordinate port usage, but this is no different than processes in a VM. This is called the “IP-per-pod” model. https://kubernetes.io/docs/concepts/cluster-administration/networking/