#Containers:
Containers are the fundamental units of software packaging and execution. They encapsulate an application and its dependencies, providing a consistent environment across different systems.
Internal working:
Isolation: Containers use operating system-level virtualization to run isolated processes. They share the host OS kernel but have their own filesystem, network interfaces, and process space.
Images: Containers are instantiated from images, which are read-only templates containing the application code, libraries, and dependencies. Images are stored in registries like Docker Hub.
Runtime: A container runtime (e.g., Docker, container-d) is responsible for managing the lifecycle of containers, including starting, stopping, and monitoring them.
#Pods:
Pods are the smallest deployable units in Kubernetes and can contain one or more containers. They provide a higher-level abstraction over containers, offering shared resources and a cohesive execution environment.
Internal working:
Shared Network Namespace: Containers within a Pod share the same IP address and network namespace, allowing them to communicate with each other using localhost.
Shared Storage: Pods can define shared storage volumes that are accessible to all containers within the Pod, enabling data sharing and persistence.
Lifecycle Management: The Kubelet, an agent running on each node, manages the lifecycle of Pods. It ensures that the containers within a Pod are running and healthy, restarting them if necessary.
#Deployments:
Deployments are higher-level abstractions that manage the deployment and scaling of Pods. They provide declarative updates to applications, allowing you to define the desired state and let Kubernetes handle the rest.
Internal working:
ReplicaSets: A Deployment manages one or more ReplicaSets, which ensure that a specified number of Pod replicas are running at any given time. When you create or update a Deployment, it automatically creates or updates a ReplicaSet.
Rolling Updates: Deployments support rolling updates, where Pods are updated incrementally to ensure zero downtime. Kubernetes creates a new ReplicaSet with the updated specification and gradually scales it up while scaling down the old one.
Rollback: If an update fails, you can roll back to a previous version of the Deployment. Kubernetes will scale down the current ReplicaSet and scale up the previous one.
Scaling: You can scale a Deployment by adjusting the number of replicas. Kubernetes will modify the number of Pods in the ReplicaSet to match the desired count.
Self-healing: Deployments automatically replace failed Pods to maintain the desired number of replicas. The Deployment controller continuously monitors the state of the Deployment and its associated ReplicaSets and Pods, making adjustments as needed.
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.14.2
ports:
- containerPort: 80
#Internal Workflow
Pod Creation: When you create a Deployment, Kubernetes creates a ReplicaSet based on the Deployment's specification. The ReplicaSet then creates the specified number of Pods.
Scheduling: The Scheduler assigns Pods to suitable nodes based on resource availability and constraints.Pod Deployment: The Kubelet on the assigned node pulls the necessary container images and starts the containers within the Pod.
Networking: Kube-proxy sets up network rules to enable communication between the Pod and other services.
Monitoring and Management: The Deployment controller continuously monitors the state of the Deployment, making adjustments to maintain the desired state.
#Zero downtime: Kubernetes (K8s) facilitates zero downtime through several mechanisms, primarily using Deployments and their rolling update strategy. Here's how Kubernetes achieves zero downtime:
Rolling Updates:
Incremental Updates: Kubernetes performs updates incrementally, meaning it updates a few Pods at a time rather than all at once. This ensures that some instances of the application remain available to handle requests during the update process.
ReplicaSets: When a Deployment is updated, Kubernetes creates a new ReplicaSet with the updated Pod template. It then gradually scales up the new ReplicaSet while scaling down the old one.
Readiness Probes: Kubernetes uses readiness probes to determine when a Pod is ready to accept traffic. During a rolling update, Kubernetes waits for the new Pods to pass their readiness checks before routing traffic to them. This ensures that only healthy Pods serve requests.
Controlled Rollout: You can configure the rolling update strategy to control the pace of the update. Parameters like maxUnavailable and maxSurge allow you to specify how many Pods can be taken down or added at a time during the update.
Rollback: If an issue is detected during the update, Kubernetes allows you to roll back to the previous version of the Deployment. This capability helps maintain service availability by quickly reverting to a known good state.
#Internal Operations of a Deployment:
Creation: When you create a Deployment, Kubernetes creates a ReplicaSet based on the Deployment's specification. The ReplicaSet then creates the specified number of Pods.
Rolling Updates: When you update a Deployment (e.g., change the container image), Kubernetes creates a new ReplicaSet with the updated specification. It gradually scales up the new ReplicaSet while scaling down the old one, ensuring that the desired number of Pods is maintained throughout the process.
Rollback: If an update fails or you need to revert to a previous version, you can roll back the Deployment. Kubernetes will scale down the current ReplicaSet and scale up the previous one.
Scaling: You can scale a Deployment by changing the replicas field. Kubernetes will adjust the number of Pods in the ReplicaSet to match the desired count.
Self-healing: If a Pod fails or is deleted, the ReplicaSet will automatically create a new Pod to replace it, ensuring that the desired number of replicas is always running.
Monitoring and Management: The Deployment controller continuously monitors the state of the Deployment and its associated ReplicaSets and Pods. It makes adjustments as needed to ensure that the actual state matches the desired state.