Kubernetes
Download as PPTX, PDF0 likes173 views
The document provides an overview of Kubernetes architecture and components. It describes that a Kubernetes cluster contains a master node which manages container orchestration and worker nodes that run application containers. The master contains components like kube-apiserver, etcd, kube-scheduler and kube-controller-manager. Worker nodes run kubelet and kube-proxy. Kubernetes uses objects like pods, replica sets and deployments to define and manage application workloads across the cluster. Pods are the basic building blocks and controllers help ensure availability of pods.
![Workloads - Controllers
Job
A job controller creates one or more pods and ensures that a
specified number of them successfully terminate.
The job controller tracks the successful completions and
when a specified number of successful completions is
reached, the job is considered complete.
A job controller can be configured to run multiple pods in
parallel
pi-job.yaml:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-
wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4](https://image.slidesharecdn.com/kubernetes-180413001643/85/Kubernetes-23-320.jpg)
Kubernetes
- 2. Cluster Architecture A Kubernetes cluster contains the following: Master (AKA cluster control plane) Node (AKA Worker/Minion) Any Kubernetes cluster must have at least one of each of a master and a node, they can either be a VM or a physical machine.
- 3. Master Components Master components’ primary function is to manage the container orchestration among the Nodes. By default, all the components run on the same machine but can be setup to run on any machine in the cluster. List of components: kube-apiserver etcd kube-scheduler kube-controller-manager cloud-controller-manager
- 4. Master Components kube-apiserver: This component exposes the Kubernetes API, it is the only component of the master that is exposed to the cluster. All the other master components talk to the apiserver to perform their tasks on the kubernetes objects and vice-versa. This component is horizontally scalable (by setting up more master instances) etcd: It is a consistent and highly-available value store used for storing all cluster data. All persistent cluster state is stored in an instance of etcd. kube-scheduler: This component manages and schedules newly created pods which don’t have an assigned node to run on, while assigning the node the kube-scheduler also takes into account factors like individual and collective resource requirements, hardware/software/policy constraints, affinity and anti- affinity specifications etcd.
- 5. Master Components kube-controller-manager: This component manages the controllers. Logically, each ‘controller’ is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process. Node Controller: Responsible for noticing and responding when nodes go down. Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system. Endpoints Controller: Populates the Endpoints object (i.e. , joins Services & Pods). Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
- 6. Master Components cloud-controller-manager: this component interacts with the controllers specific to cloud provider(s). Only the following controllers can be used along with a cloud provider: Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding Route Controller: For setting up routes in the underlying cloud infrastructure Service Controller: For creating, updating and deleting cloud provider load balancers Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
- 7. Node Components Node components maintain running pods and provides the kubernetes runtime environment kubelet: it is the primary agent that runs on every node in the cluster to ensure that the pods are running as per their provided spec. (will be explained later) kube-proxy: enables the Kubernetes service abstraction by maintaining network rules on the host and performing connection forwarding. Container Runtime: a software which is responsible for running containers. Example: Docker, rkt, runc and any OCI runtime-spec implementation. Note: kubelet could also be running on the master as some of the components of the master are configured/setup to run in pods which would be managed by the ‘kubelet’ component.
- 8. Question: Can Node and Master Components run on the same Physical machine/VM? Answer: Yes. For example, the node component ‘kubelet’ also runs on the master as of the components of the master are configured/setup to run in pods which would be managed by the ‘kubelet’ component.
- 10. Kubernetes Objects Persistent entities of a Kubernetes system Represent the desired state of a cluster What containerized applications are running (and on which nodes) The resources available to those applications The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance Object(s) define the intended workload of a cluster The Kubernetes API or kubectl can be used to create, modify, or delete any kubernetes object(s). (kubectl internally calls the kubernetes API)
- 11. Kubernetes Objects Every object consists of two fields: object spec and object status Object Spec: This defines the desired state for the object Object Status: This defines the actual state of the object When using Kubernetes API directly the object spec would have to be provided in a .json file. When providing the object spec via kubectl, the object definition in provided in a .yaml file. At any given time, Kubernetes Master (Kubernetes Control Plane) actively manages an object spec (object’s actual state) to match the object status (object’s desired state) you supplied.
- 12. Kubernetes Objects Below are the mandatory fields that have to be present in every object spec: apiVersion - Which version of the Kubernetes API you’re using to create this object kind - What kind of object you want to create metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace spec – the spec field would be specific to the object being created/updated/deleted. To create the ‘nginx-deployment’ object using kubectl, below is an example command: kubectl apply –f nginx-deployment.yaml nginx-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
- 13. Workloads Kubernetes provides two objects for managing containerized workloads(applications): Pods Controllers A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents a running process on your cluster. A Controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
- 14. Workloads - Pod It is the basic building block of Kubernetes. the smallest and simplest unit of the Kubernetes objects that can be created. A Pod represents a running process on your cluster (a single instance of an application in Kubernetes). A Pod object encapsulates the following components & features: One or more application container(s) Storage resource(s) A unique network IP Options that govern how the container(s) should run Pods are ephemeral. Node Pod container kube-apiserver kubelet
- 15. Workloads - Pod Pods can be setup/configured in following ways: Single container in a pod: This is the most common use case, in this case the pod essentially acts as a wrapper around the container. Multiple containers in a pod: Multiple containers which are tightly coupled and need to share resource can use this type of setup. For example, if we want to push logs from individual containers to an ELK cluster, we can have one application container and another logstash container running in the same pod and have that logstash container process the logs and push it to elasticsearch. The network and storage resources are the ones that would be shared between the containers
- 16. Workloads - Controllers Individual pods are rarely created directly, mainly because of their ephemeral nature. Usually they are created and managed as part of one of the Controller objects. The controller objects manage the replication and rollout, also they provide self-healing capabilities as cluster scope(i.e., if a pod crashes, then it can be recreated on the same node or another node in the cluster) A pod object(specification) is included as part of the controllers.
- 17. Workloads - Controllers There are many types of controllers that can be setup for different used cases, below are a list of them: ReplicaSet ReplicationController (similar to ReplicaSet but don’t support selectors, not recommended by Kubernetes) Deployments StatefulSets DaemonSet Garbage Collection Jobs - Run to Completion CronJob
- 18. Workloads - Controllers ReplicaSet This controller ensures that a specified number of pod replicas are running at any given time When using this controller if a pod needs to be updated, the default behavior of the controller would be to stop/delete all the existing pods and then recreate the new ones.(i.e., replica sets cannot perform a rolling-update) Deployment controller define and manage replicasets as a part of their process and also support rolling-updates to the pods, thus kubernetes recommends using Deployments instead of directly using ReplicaSets.
- 19. Workloads - Controllers Deployment The resources(like IP address of the pod) of a deployment controller are stateless. As mentioned previously, deployment controllers support rolling-update, they also support ‘rolling back’ of updates also, by default it stores last 10 previous states. One of the most common use case of this controller is for ‘Canary Deployments’ Using deployment controller(s) current state of a pod can be updated to a new desired state in a controlled fashion. Deployment controller(s) also provide the flexibility of pausing and resuming, this is helpful when you want to make multiple changes to a pod spec without using a .yaml file for the object. nginx-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
- 20. Workloads - Controllers StatefulSet The resources(like IP address of the pod) of a statefulset controller are stateful. Similar to deployment with additional features that guarantee ordering and uniqueness of the Pods. A ‘Headless’ Service(to publish the IP addresses of Pods in the StatefulSet) has to be defined as a prerequisite of a statefulset. StatefulSets create every pod with a unique identity comprosed of an ordinal index, stable network identity and stable storage. nginx-service.yaml: apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx
- 21. Workloads - Controllers StatefulSet StatefulSet controller(s) maintain a sticky identity for each of their Pods. StatefulSet controller(s) are recommended to be used when one of more of the following features are required: Stable, unique network identifiers. Stable, persistent storage. Ordered, graceful deployment and scaling. Ordered, graceful deletion and termination. Ordered, automated rolling updates. Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. nginx-statefulset.yaml: apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumes: - name: www hostPath: path: /opt/nginx/ type: Directory
- 22. Workloads - Controllers DaemonSet DaemonSet controller(s) ensures that all (or some) Nodes run a copy of a Pod. One of the common used case of a daemonset controller is for running a logs collection daemon on every node, such as fluentd or logstash. By default, a daemonset is configured to run on all nodes, but it can be restricted to run on specific set/type of nodes fluentd-daemonset.yaml: apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd-elasticsearch template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd-elasticsearch image: k8s.gcr.io/fluentd-elasticsearch:1.20 volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers
- 23. Workloads - Controllers Job A job controller creates one or more pods and ensures that a specified number of them successfully terminate. The job controller tracks the successful completions and when a specified number of successful completions is reached, the job is considered complete. A job controller can be configured to run multiple pods in parallel pi-job.yaml: apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "- wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4
- 24. Workloads - Controllers CronJob A CronJob controller manages time based Job controllers. As its names indicates, it can configure a Job controller to be initialized at a given point in time or repeatedly a specific point in time. helloworld-cronjob.yaml: apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo “HelloWorld” restartPolicy: OnFailure