Kubernetes Orchestration

A Pod is the smallest deployable unit in Kubernetes. It represents a single instance of a running process and can contain one or more containers that share:The same network namespace (IP address and ports)Storage volumesA common lifecycle

Multiple containers in a Pod share the same network and storage, making them ideal for tightly coupled processes. Common patterns include:Sidecar – adds functionality (e.g., logging agent)Ambassador – proxies network trafficAdapter – transforms output for external consumers

An init container runs before the main application containers start. It runs to completion and must succeed before the next init container (or main container) starts. Use cases include:Pre-populating shared volumes with dataWaiting for a dependent service to become availableRunning database migrations

The sidecar pattern places a helper container alongside the main application container within the same Pod. The sidecar extends or enhances the main container's functionality. Examples:Log shipping (e.g., Fluentd sidecar)Service mesh proxy (e.g., Envoy in Istio)Configuration reloading

A Service is an abstraction that defines a logical set of Pods and a policy to access them. It provides:A stable IP address and DNS nameLoad balancing across matching PodsDecoupling of consumers from individual Pod IPsServices use label selectors to target Pods.

ClusterIP is the default Service type. It exposes the Service on an internal IP accessible only within the cluster. Use it for:Internal microservice-to-microservice communicationBackend services not exposed externallyExample: spec.type: ClusterIP

A NodePort Service exposes the Service on a static port (range 30000–32767) on every node's IP. External traffic can reach the Service via <NodeIP>:<NodePort>. It automatically creates a ClusterIP Service that the NodePort routes to.

A LoadBalancer Service provisions an external load balancer from the cloud provider (AWS ELB, GCP LB, etc.). It automatically creates NodePort and ClusterIP Services. Traffic flows: External LB → NodePort → ClusterIP → Pod. Best for production workloads needing external access.

An ExternalName Service maps a Service to an external DNS name using a CNAME record. It does not use selectors or define endpoints. Example: spec.externalName: my.database.example.com. Useful for referencing external services with a cluster-internal DNS alias.

A Deployment manages a set of identical Pods via a ReplicaSet. It provides:Declarative updates – describe the desired stateRolling updates – zero-downtime deploymentsRollback – revert to previous revisionsScaling – adjust replica count

During a rolling update, Kubernetes incrementally replaces old Pods with new ones. Key parameters:maxSurge – max extra Pods above desired count (default 25%)maxUnavailable – max Pods that can be unavailable (default 25%)This ensures the application stays available throughout the update.

Use kubectl rollout undo deployment/<name> to revert to the previous revision. To rollback to a specific revision: kubectl rollout undo deployment/<name> --to-revision=2. View revision history with kubectl rollout history deployment/<name>.