Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit. Kubernetes automates the distribution and scheduling of application containers across a cluster in an efficient way.
- Service discovery and load balancing
- Storage orchestration
- Automated rollouts and rollbacks
- Secret and configuration management
- Kubernetes is configured on one or more nodes. A node is a machine physical or virtual on which Kubernetes is installed.
- A node is a worker machine where containers are hosted.
- You need to have more than one node for high availability and scaling.
- A cluster is a set of nodes grouped together.
- The master (control plane) watches over the nodes in the cluster and is responsible for the actual orchestration of containers on the worker nodes.
- A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the master.
- A pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources such as volumes (shared storage), networking (a cluster of IP addresses), and a spec (information about how to run a container)
- A pod hosts a single instance of an application.
- In general, a pod has a one-to-one relationship with a container, a single-container pod. But a single pod can have multiple containers of a different kind, a multi-container pod.
- A ReplicaSet maintains a stable set of replica pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical pods.
- Load balancing and Scaling based on a pod template
- Providing fault-tolerance
- A ReplicationController ensures that a specified number of pod replicas are running at any one time.
- [Note] A Deployment that configures a ReplicaSet is the recommended way to set up replication.
kubectl create –f rs.yaml --save-config kubectl apply -f rs.yaml kubectl get replicaset kubectl get replicationcontrollers kubectl delete replicaset <replicaset-name> # update kubectl replace –f rs.yaml # scaling kubectl scale –-replicas=6 –f rs.yaml kubectl scale --replicas=6 replicaset <replicaset-name> # editing Kubectl edit replicaset <replicaset-name>
- The deployment manages pods.
- Instructs Kubernetes on how to create and update instances of your application.
- Scaling ReplicaSets, which scale pods
- Supporting zero-downtime update and rollback by creating and destroying Replicasets
- Once you have created a deployment, the Kubernetes master schedules the application instances in that Deployment to run on individual nodes in the cluster.
- A Kubernetes Deployment Controller continuously monitors those instances and provides a self-healing mechanism to address machine failure or maintenance.
kubectl create deployment < deployment-name> --image=<image name> # scaling kubectl scale deployment –-replicas=3 <deployment-name>
- kube-apiserver: The API server acts as the front-end for Kubernetes. The users, management devices, command-line interfaces all talk to the API server to interact with the cluster.
- etcd key store: etcd is a distributed reliable key-value store used as Kubernetes’ backing store for all cluster data. etcd is responsible for implementing locks within the cluster to ensure there are no conflicts between the nodes.
- Scheduler: A scheduler is responsible for distributing work or containers across multiple worker nodes.
- Controller: A controller makes decisions to orchestrate the working of the cluster and its nodes.
- Node controller
- Replication controller
- Endpoints controller
- Service Account & Token controllers
- cloud-controller-manager: runs controllers that are specific to your cloud provider.
- Node controller
- Route controller
- Service controller
- Worker node
- Kubelet: kubelet is the agent that runs on each worker node in the cluster. The agent is responsible for making sure that the containers are running on the nodes as expected.
- Kube-proxy: The proxy is responsible for networking within a cluster.
- kube-proxy uses the operating system packet filtering layer
- Container Runtime: The container runtime is the underlying software that is used to run containers. Docker is the most popular option.
Object Spec and Status
Almost every Kubernetes object includes two nested object fields:
- spec: the object’s desired state
- status: the object’s current state
The Kubernetes control plane continually and actively manages every object’s actual state to match the desired state you supplied.
Kubernetes Definition File – YAML
apiVersion:v1 # String kind:Pod # String metadata: # Dictionary name: my-app labels: # Dictionary app: myapp type: myapp-web spec: containers: # List - name: nginx-container image: nginx ports: - containerPort: 80
- A Kubernetes definition file always contains 4 top-level fields.
- apiVersion , kind, metadata, and spec
- They are all required fields.
- The “metadata” is a dictionary of key-value pairs, and so does the “labels.”
- Under metadata, you can only specify expected items such as “name ” or “labels.” You CANNOT add any other property under this.
- Under “labels“, you CAN have any kind of key or value pairs.
- The “spec” section is where you specify the desired state of a cluster.
- The “containers” section is a list or array of container settings.
- Labels are key/value pairs that are attached to objects.
- Labels specify identifying attributes of objects that are meaningful and relevant to users.
- Unlike names and UIDs, labels do not provide uniqueness.
- Via a label selector, the client can identify a set of objects.
- Two types of selectors are supported
- equality-based (=, ==, !=)
- set-based (in, notin).
- Multiple conditions by comma (,) — act as a logical AND
kubectl get pods -l environment=production,tier=frontend kubectl get pods -l 'environment in (production, qa)'
- Annotations attach arbitrary non-identifying metadata to objects.
- Annotations are key/value pairs.