Kubernetes Questions

Kubernetes (K8s) is an open-source container orchestration platform originally developed by Google. It automates the deployment, scaling, and management of containerized applications, grouping containers into logical units for easy discovery and management.

As applications move toward microservices, managing hundreds of containers manually becomes impossible. K8s provides self-healing, automated rollouts/rollbacks, horizontal scaling, service discovery, and load balancing, ensuring high availability and efficient resource utilization.

Kubernetes follows a leader-worker architecture. It consists of a 'Control Plane' (Master) that manages the cluster state and 'Nodes' (Workers) that run the application containers. The Control Plane makes decisions about the cluster, while Nodes maintain the running pods.

1. kube-apiserver: The front end and entry point. 2. etcd: The distributed key-value store for cluster data. 3. kube-scheduler: Assigns pods to nodes. 4. kube-controller-manager: Runs controller processes. 5. cloud-controller-manager: Interacts with cloud providers.

1. kubelet: The agent that ensures containers are running in a Pod. 2. kube-proxy: Manages network rules and traffic forwarding. 3. Container Runtime: The software responsible for running containers (e.g., containerd, CRI-O).

The API server is the central hub for the Kubernetes cluster. It exposes the Kubernetes API, validates and processes REST requests, and serves as the only component that communicates directly with the etcd data store to update cluster state.

etcd is a consistent and highly-available key-value store used as the cluster's database. It stores the entire configuration and state of the cluster. If etcd is lost, the cluster cannot recover its state, making its backup critical.

It is a daemon that embeds the core control loops (controllers). It watches the shared state of the cluster via the API server and makes changes to move the 'current state' toward the 'desired state' (e.g., bringing up a new pod if one fails).

kube-proxy is a network proxy that runs on each node. It implements the Kubernetes Service concept by maintaining network rules on the host and performing connection forwarding, allowing Pods to communicate internally and externally.

The kubelet is the primary 'node agent'. it takes a set of PodSpecs and ensures that the containers described in those specs are running and healthy. It reports the status of the pod and the node back to the API server.

kubectl is the command-line interface (CLI) for running commands against Kubernetes clusters. It communicates with the API server to create, update, delete, and inspect resources within the cluster environment.

Common commands include: `get` (list resources), `describe` (detailed info), `apply` (create/update), `logs` (view container output), `exec` (run commands inside), `delete` (remove resource), and `top` (monitor usage).

It is the automated management of the container lifecycle. This includes provisioning, deployment, scaling (up/down), networking, load balancing, and health monitoring of containers across a cluster of physical or virtual machines.

Docker Swarm is simpler and built into Docker but lacks advanced features. K8s is more complex but highly flexible, offering superior auto-scaling, auto-healing, and a vast ecosystem for complex, high-scale production workloads.

Docker is a technology used to create, package, and run containers on a single host. Kubernetes is a platform for orchestrating those containers across a cluster. Docker is the 'container', while Kubernetes is the 'captain' of the ship managing the containers.

Pods are the smallest deployable units in K8s, representing a single instance of a running process. Management commands: `kubectl get pods`, `kubectl describe pod <name>`, `kubectl logs <name>`, and `kubectl delete pod <name>`.

A container is a single execution environment (like a Docker container). A Pod is a wrapper that can hold one or more containers that share the same network namespace and storage volumes, essentially acting as a 'logical host'.

A pod can be created imperatively using `kubectl run <podname> --image=<image>` or declaratively using a YAML file and the command `kubectl apply -f pod-definition.yaml`.

Using `kubectl logs <pod-name>`. For a multi-container pod, specify the container with `-c <container-name>`. Adding the `-f` flag allows for real-time log streaming (following).

Using `kubectl exec -it <pod-name> -- <command>`. For an interactive shell, use `kubectl exec -it <pod-name> -- /bin/bash` or `/bin/sh` depending on the image.

Using the `kubectl cp` command. Syntax: `kubectl cp <local-file> <namespace>/<pod-name>:<remote-path>` to upload, and reversing the arguments to download to your local machine.

Debugging involves checking the status with `get pods`, inspecting events/errors with `describe pod`, analyzing logs with `logs`, and using `exec` to enter the container and check local environment variables or files.

`kubectl describe pod` provides a high-level summary and recent 'Events'. K8s doesn't have an 'inspect' command like Docker; to see raw JSON/YAML data, use `kubectl get pod <name> -o json` or `yaml`.

Init containers run to completion before app containers start. They are used for setup logic (like waiting for a database). Unlike regular containers, if an init container fails, K8s restarts the pod until it succeeds.

A sidecar is a secondary container that runs alongside the main container in the same Pod. It provides helper tasks like log shipping, proxying (Envoy in Istio), or monitoring without the main app knowing it exists.

Native sidecars (K8s 1.29+) allow containers in a pod to be marked as sidecars so they start before others and stop last. This solves the issue where sidecars would keep Jobs running even after the main task finished.

K8s uses Pod Disruption Budgets (PDB) to ensure a minimum number of pods remain available during maintenance. High availability is achieved through Replicas in Deployments, spreading pods across different Nodes or Availability Zones.

1. ImagePullBackOff (check secret/name). 2. CrashLoopBackOff (check logs/env). 3. Pending (check resources/taints). 4. OOMKilled (increase memory limit). 5. CreateContainerConfigError (check ConfigMaps/Secrets).

It is a single Pod containing two or more containers that share resources like network (localhost) and storage volumes. They are tightly coupled and should always be scheduled on the same node together.

Yes. This is used for patterns like Sidecar, Adapter, and Ambassador. All containers in the Pod share the same IP, port space, and storage, allowing them to communicate efficiently via IPC or localhost.

A Deployment provides declarative updates for Pods. Strategies: 1. RollingUpdate (incremental replacement, zero downtime). 2. Recreate (kill all, then start all, involves downtime). 3. Canary or Blue-Green (manually controlled).

A Deployment manages a ReplicaSet, and a ReplicaSet manages Pods. When you update a Deployment, it creates a new ReplicaSet and gradually moves pods from the old ReplicaSet to the new one.

Replication Controller is the older method. ReplicaSet is the successor that supports 'set-based' label selectors (e.g., matching multiple labels simultaneously), whereas Replication Controllers only support equality-based selectors.

Deployments are for stateless apps where pods are interchangeable. StatefulSets are for applications requiring stable network IDs, stable persistent storage (using VolumeClaimTemplates), and ordered deployment/scaling (e.g., Databases).

Use Deployment for web servers, APIs, and microservices. Use StatefulSet for databases (MySQL, MongoDB), distributed systems (Zookeeper, Kafka), or any app where the pod needs a fixed identity like 'pod-0'.

StatefulSet pods have an ordinal index (0 to N-1). They are created in order (0, then 1...) and deleted in reverse order. Each pod gets a stable hostname (name-0.service) that persists across restarts.

A Headless Service (ClusterIP: None) does not have a single IP. Instead, it returns the direct IPs of all backing Pods. It's used with StatefulSets so clients can talk to specific pods (like the Master in a DB cluster).

Deployment: General stateless apps. StatefulSet: Persistent/Ordered apps. DaemonSet: Ensures that exactly one copy of a Pod runs on every (or selected) node in the cluster (e.g., logging agents).

A ReplicaSet ensures a total number of pods are running across the cluster. A DaemonSet ensures one pod runs per node. When nodes are added/removed, the DaemonSet automatically adds/removes pods on those nodes.

Use DaemonSets for node-level infrastructure: 1. Log collection daemons (Fluentd, Logstash). 2. Monitoring agents (Prometheus Node Exporter). 3. Storage proxies or network plugins that must exist on every node.

K8s creates a new ReplicaSet and scales it up while scaling down the old ReplicaSet. It uses `maxUnavailable` (max pods down during update) and `maxSurge` (max extra pods created) to ensure zero downtime.

1. RollingUpdate (Default). 2. Recreate (Downtime). 3. Blue-Green (Separate environments). 4. Canary (Traffic splitting). 5. Shadow (Mirroring traffic).

A strategy where you maintain two identical production environments. One (Blue) is live, the other (Green) is where you deploy the new version. Once tested, you switch traffic at the Service/Load Balancer level from Blue to Green.

A strategy where a new version is deployed to a small subset of users (the 'canaries'). You monitor its health; if successful, you roll it out to the entire cluster. If it fails, you only affect a tiny fraction of users.

Using `kubectl rollout undo deployment <name>`. You can also specify a specific revision by adding `--to-revision=N`. Use `kubectl rollout history` to view the available versions.

By using `RollingUpdate` combined with `Readiness Probes`. The Readiness probe ensures the new pod is actually ready to handle requests before the old pod is terminated, maintaining continuous service availability.

It terminates all existing pods before starting new ones. It is used when an application cannot run multiple versions simultaneously (e.g., due to schema changes) but involves noticeable downtime.

Services provide a stable IP/DNS to a set of Pods. Types: 1. ClusterIP (internal). 2. NodePort (external on node port). 3. LoadBalancer (Cloud external). 4. ExternalName (CNAME record).

The default service type. It provides a stable IP address accessible only from within the cluster. It load-balances internal traffic among the pods identified by the selector.

Exposes the service on a static port (30000-32767) on each Node’s IP. You can access the service from outside the cluster using `<NodeIP>:<NodePort>`.

Typically used in cloud environments (AWS, GCP, Azure). It creates a cloud provider's load balancer and automatically assigns an external IP that routes to the service's ClusterIP/NodePort.

A service that maps to a DNS name (CNAME record) instead of using selectors. It is used to alias external services (like an RDS database) so they can be accessed via a local K8s service name.

K8s uses Environment Variables and DNS. Every service gets a DNS record (service.namespace.svc.cluster.local). Pods use the cluster DNS (CoreDNS) to look up these service names to resolve IPs.

A cluster-wide DNS service (CoreDNS) is automatically configured. When services are created, the API server notifies CoreDNS to create A/SRV records. Pods inherit DNS settings to resolve these records.

By default, K8s allows all-to-all communication. Boundaries are enforced using 'Network Policies' (pod firewalls) that define ingress and egress rules based on labels and namespaces.

This is handled by the Container Network Interface (CNI) plugin (like Calico or Flannel). It creates an 'Overlay Network' ensuring every Pod has a unique IP across the entire cluster cluster-wide.

Ingress is an API object that manages external HTTP/S access to services. It provides URL-based routing (e.g., domain.com/api), SSL termination, and name-based virtual hosting.

Ingress is just a set of rules. The Ingress Controller is the actual application (Reverse Proxy) that implements those rules, such as Nginx, HAProxy, Traefik, or Istio Ingress Gateway.

Gateway API is the modern successor to Ingress. It is more modular, supports TCP/UDP (not just HTTP), and splits configuration into separate roles (GatewayClass, Gateway, and Routes) for better multi-tenancy.

A Network Policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. It works at the L3/L4 level, essentially acting as a pod-level firewall.

CoreDNS is a modular DNS server that acts as the cluster DNS. It is configured via a ConfigMap (Corefile). It is used automatically by Pods to resolve service names into IPs.

EndpointSlice is a scalable version of Endpoints. It groups network endpoints together to reduce the performance overhead of updating large services with thousands of pods.

Kube-proxy typically uses 'IPtables' or 'IPVS' modes to create rules on each node. When traffic hits a Service IP, these rules redirect the packets to one of the healthy backend Pod IPs.

A Namespace is a logical partition in a Kubernetes cluster used to isolate resources. It allows for multi-tenancy, helping different teams or environments (Dev/Prod) use the same cluster without interference.

Namespaces prevent naming collisions, allow for granular access control (RBAC), and enable resource limits/quotas per team, ensuring one group doesn't consume all cluster resources.

Create a unique Namespace for each team. Apply Role-Based Access Control (RBAC) to limit team access to their namespace and use ResourceQuotas to cap their consumption.

A ResourceQuota object provides constraints that limit aggregate resource consumption per namespace. It can cap the total CPU, Memory, or the number of objects (like Pods or Services) allowed in that namespace.

A LimitRange is a policy to constrain the resource allocations (Limits/Requests) for individual containers or pods within a namespace, ensuring they aren't too small or too large.

Requests are used for scheduling (finding a node with enough space). Limits are enforced at runtime by the container runtime and OS kernel to ensure a container doesn't exceed its allocation.

Request: The minimum resource guaranteed to a container (Scheduler uses this). Limit: The maximum resource a container is allowed to consume (Cgroups enforce this).

QoS is a mechanism K8s uses to decide which pods to evict first when a node runs out of resources. It is determined automatically based on the pod's requests and limits configuration.

1. Guaranteed (Request == Limit). 2. Burstable (Request < Limit). 3. BestEffort (No requests/limits). Guaranteed pods are the last to be evicted.

If a pod exceeds its Memory limit, it is OOM (Out Of Memory) killed by the kernel. If it exceeds its CPU limit, it is 'throttled' (slowed down) but usually not killed.

It cannot. Kubernetes uses kernel cgroups to enforce limits. If the pod attempts to use more, it will be throttled (CPU) or killed (Memory). To grow, the YAML must be updated and the pod restarted.

By applying a ResourceQuota YAML to each tenant's Namespace. This ensures one tenant's load spikes don't starve other tenants of CPU, RAM, or storage.

Using: 1. Namespaces. 2. RBAC. 3. Network Policies (isolation). 4. ResourceQuotas. 5. Taints/Tolerations or Node Affinity to keep tenant workloads on specific hardware.

A ConfigMap is an API object used to store non-confidential data in key-value pairs. It allows you to decouple environment-specific configurations from container images, making apps portable.

Imperatively: `kubectl create configmap <name> --from-literal=key=value` or from a file. Declaratively: Defining a YAML of kind `ConfigMap` and using `kubectl apply`.

In the PodSpec, define a volume of type `configMap`. Then, in the container spec, use `volumeMounts` to mount that volume to a specific file path inside the container.

Use the `envFrom` field in the container spec to inject all keys, or the `env` field with `valueFrom` to inject specific keys from the ConfigMap as environment variables.

ConfigMaps are for plain-text configuration. Secrets are for sensitive data (passwords, tokens). Secrets are Base64 encoded by default and can be encrypted at rest in etcd.

Secrets are objects used to store and manage sensitive information safely. K8s avoids plain-text exposure in the YAML and provides better protection than hardcoding secrets in images.

Using `kubectl create secret generic <name> --from-literal=key=secretvalue`. Like ConfigMaps, they can also be created from files or declarative YAML manifests.

1. `Opaque` (generic). 2. `kubernetes.io/service-account-token`. 3. `kubernetes.io/dockercfg`. 4. `kubernetes.io/tls` (for certificates).

By configuring an `EncryptionConfiguration` resource on the API server. This uses a provider (like AES-GCM or a KMS) to encrypt Secret data before it is written to the etcd disk.

1. Enable Encryption at Rest. 2. Use RBAC to limit access. 3. Integrate with external vaults (HashiCorp Vault). 4. Avoid checking Secrets into Git (use tools like SealedSecrets).

Secrets can be injected as Environment Variables or mounted as Files in a volume. When mounted as a volume, the secret value is projected into the file system in memory (tmpfs).

Volumes provide persistent or ephemeral storage. `EmptyDir` is scratch space; `HostPath` uses node disk; `PV` is cluster-wide storage; `PVC` is a request for that storage.

An ephemeral volume created when a Pod is assigned to a Node. It is empty initially and is deleted permanently when the Pod is removed from that node.

It mounts a file or directory from the host node's filesystem into your Pod. It's used for system-level pods (like log collectors) but is generally avoided for normal apps for security reasons.

PV is a piece of storage in the cluster (the 'disk'). PVC is a request for storage by a user (the 'ticket'). PVCs bind to PVs that meet their size and access mode requirements.

PV is a resource in the cluster managed by admins. PVC is a request for that resource by a developer. PV represents the actual capacity, while PVC is the logic that claims it.

StorageClass allows admins to describe the 'classes' of storage they offer (e.g., 'fast' SSD vs 'slow' HDD). It enables dynamic provisioning so PVs are created automatically when a PVC is made.

It allows storage volumes to be created on-demand. When a user creates a PVC, the StorageClass triggers the cloud provider to create the disk and the K8s PV automatically.

K8s uses the Container Storage Interface (CSI). Storage vendors write CSI drivers that K8s calls to create, attach, and mount disks to nodes and containers seamlessly.

1. ReadWriteOnce (RWO): One node can mount it. 2. ReadOnlyMany (ROX): Many nodes can mount read-only. 3. ReadWriteMany (RWX): Many nodes can mount read-write.

The behavior depends on the PV's Reclaim Policy: `Retain` (manual cleanup needed), `Delete` (disk deleted immediately), or `Recycle` (scrub files and reuse).

It uses a 2-step process: 1. Filtering (finding nodes that meet pod requirements). 2. Scoring (ranking filtered nodes to find the best fit based on resource availability).

Resource requirements, Taints/Tolerations, Node Affinity, Data locality, Inter-pod affinity/anti-affinity, and dead-lines.

Taints are applied to Nodes to repel certain Pods. Tolerations are applied to Pods to allow them to stay on tained Nodes. They work together to ensure pods don't run on inappropriate nodes.

Taints 'mark' a node (e.g., 'this node is for GPU work'). Only Pods with a matching Toleration can be scheduled there. It’s like a 'Keep Out' sign that only certain pods can ignore.

Taints are on Nodes; Tolerations are on Pods. A pod will only schedule on a tainted node if it 'tolerates' that specific taint. If a node has no taints, any pod can schedule there.

Node Affinity is a set of rules used by the scheduler to 'attract' Pods to specific nodes based on labels. It is a more flexible version of the `nodeSelector`.

Affinity pushes pods toward specific nodes or pods. Anti-Affinity pushes pods away from them (e.g., to ensure two copies of a pod aren't on the same node for HA).

Pod Affinity ensures that certain pods are scheduled on the same node (or in the same zone) because they communicate heavily and need low latency.

Pod Anti-Affinity ensures pods are NOT scheduled on the same node. This is critical for high availability, ensuring that if one node fails, the entire service doesn't go down.

Node Affinity 'attracts' pods to nodes. Taints/Tolerations allow nodes to 'repel' pods. Affinity is pod-centric (where should I go?); Taints are node-centric (who can come here?).

The simplest form of node selection constraint. You specify a label in the PodSpec, and the pod will only run on nodes that have that exact key-value label pair.

Using `kubectl label pods <name> key=value`. You can also filter using labels: `kubectl get pods -l key=value` or delete using them: `kubectl delete pods -l key=value`.

Labels are metadata attached to objects. Selectors are used to query and filter those objects. For example, a Service uses a Selector to find which Pods it should route traffic to.

Labels are key-value pairs attached to objects (like Pods). They are used to organize and select subsets of objects but do not have direct functional impact on the container runtime.

Selectors are the primary grouping mechanism in K8s. They allow you to identify a set of objects based on their labels (e.g., 'find all pods where app=frontend and env=prod').

Labels are used for identifying and selecting objects. Annotations are for non-identifying metadata (like build IDs or contact info) that tools and libraries can read.

K8s scales containers by adjusting the 'replica' count in a Deployment/ReplicaSet. This can be done manually via `kubectl scale` or automatically using the HPA.

HPA automatically scales the number of pods in a deployment based on observed CPU utilization or other custom metrics to handle traffic spikes.

HPA queries the Metrics Server periodically. It calculates the ratio of 'current metric' vs 'target metric'. If current usage is higher than target, it tells the Deployment to increase replicas.

VPA automatically sets the resource 'Requests' and 'Limits' for your containers, giving more CPU/RAM to pods that need it and taking it away from those that don't.

Cluster Autoscaler adds or removes physical/virtual Nodes from the cluster itself when pods cannot be scheduled due to lack of resources or when nodes are underutilized.

HPA scales 'out' by adding more pods. VPA scales 'up' by giving existing pods more power (RAM/CPU). Usually, you shouldn't use both on the same metric for the same pod.

By evaluating the equation: `DesiredReplicas = ceil[CurrentReplicas * (CurrentMetric / TargetMetric)]`. If the result differs from the current replica count, K8s adjusts the deployment.

These are health checks. Liveness: Checks if container is alive (restarts if fail). Readiness: Checks if container is ready for traffic. Startup: Checks if app has finished starting up.

A check to see if the container process is still functioning. If a Liveness probe fails, K8s kills the container and starts a new one based on the restart policy.

A check to see if the container is ready to handle requests. If it fails, the pod is removed from the Service endpoints, meaning no traffic is sent to it until it passes.

Specifically for slow-starting apps. It disables Liveness and Readiness checks until the app is fully started, preventing K8s from killing a container that is simply taking a long time to boot.

Liveness triggers a restart. Readiness triggers traffic removal. Use Liveness for deadlocks/crashes; use Readiness for initialization and temporary overloaded states.

By defining `livenessProbe` or `readinessProbe` in the container spec. Methods include `httpGet`, `exec` (running a script), or `tcpSocket` checks.

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is used for batch processing or one-off tasks like database migrations.

Use a Job for any task that needs to run exactly once (or a set number of times) and then exit, such as batch processing data, generating a report, or running a cleanup script.

A CronJob manages time-based Jobs. It runs a task on a repeating schedule (e.g., every hour or every night at 2 AM) using the standard Linux crontab format.

Use CronJobs for periodic maintenance: 1. Nightly backups. 2. Sending daily email summaries. 3. Clearing temporary files or caches every Sunday at midnight.

A Job runs immediately and just once (manually triggered). A CronJob is scheduled and runs automatically multiple times based on the defined schedule.

Define a YAML with `kind: Job`. Set the `restartPolicy` to `OnFailure` or `Never`, and K8s will ensure the pod runs until the process exits with code 0.

If the process exits with a non-zero code, K8s will restart the pod (if `restartPolicy: OnFailure`) until it succeeds or reaches the `backoffLimit` (default is 6 retries).

Role-Based Access Control is a method of regulating access to the K8s API based on the roles of individual users or service accounts within an organization.

RBAC ensures security by following the 'Principle of Least Privilege'. It restricts what actions (get, list, delete) a user can perform on what resources (Pods, Secrets) within the cluster.

A Role is a namespaced object that contains a set of permissions. It defines what can be done (verbs) to which resources within a specific Namespace.

A ClusterRole is non-namespaced. It is used to define permissions for resources across the entire cluster (like Nodes) or for resources within all namespaces simultaneously.

Role is restricted to one Namespace. ClusterRole is Cluster-wide. Use Role for team-level access; use ClusterRole for cluster admins or cluster-level tools.

A RoleBinding grants the permissions defined in a Role to a user, group, or service account. It links the 'What' (permissions) with the 'Who' (identity) within a namespace.

It linking a ClusterRole to an identity. It grants permissions cluster-wide (e.g., allowing a service account to view nodes in the entire cluster).

A ServiceAccount provides an identity for processes that run in a Pod. When a Pod talks to the API server, it uses the credentials assigned to its ServiceAccount to authenticate.

Using RBAC to restrict API access, enabling Network Policies to restrict pod traffic, and using Secrets management for sensitive credentials.

Users are for humans and are managed externally (e.g., LDAP/IAM). ServiceAccounts are for machine processes running in Pods and are managed as K8s objects.

Using `kubectl create serviceaccount <name>`. Once created, you can assign it to a pod by specifying `serviceAccountName: <name>` in the PodSpec.

Custom Resources allow you to extend the K8s API by adding your own objects (e.g., 'Backup' or 'Database') that K8s doesn't support out of the box.

A CRD is the 'blueprint' or schema used to define a new Custom Resource. Once a CRD is applied to the cluster, the API server starts recognizing that new resource type.

An Operator is a method of packaging, deploying, and managing a K8s application. it combines Custom Resources with a Custom Controller to automate complex, domain-specific tasks.

Operators act like a 'human admin' in software. They watch a Custom Resource and perform complex tasks like taking backups, resizing a DB cluster, or upgrading software automatically.

It is an HTTP callback that intercept requests to the API server and 'mutates' (modifies) the resource before it is saved (e.g., automatically adding a sidecar to every pod).

It intercepts requests and 'validates' them. If the resource doesn't meet specific security or business criteria, the webhook rejects the request and the resource is not created.

A Helm chart is a bundle of YAML templates and configuration (values). It is used to package and share K8s applications, making complex deployments repeatable and versioned.

Helm is the 'Package Manager' for K8s (like apt or npm). It allows you to find, share, and use software built for Kubernetes using a single command.

1. `Chart.yaml` (metadata). 2. `values.yaml` (configuration variables). 3. `templates/` (the actual K8s YAML manifests with placeholders).

Helm 3 removed 'Tiller' (the server-side component), significantly improving security. It also introduced JSON schema validation and improved release tracking.

Using `helm install <release-name> <chart-name>`. You can override default configuration by passing a custom values file: `helm install -f values.yaml`.

Using `helm upgrade <release-name> <chart-name>`. Helm calculates the difference between current and new versions and applies only the necessary changes to K8s.

Using `helm rollback <release-name> <revision-number>`. Helm keeps a history of releases, allowing you to quickly revert if an upgrade fails.

Pipelines (Jenkins, GitLab, GitHub Actions) build images, push to a registry, and then use `kubectl` or `helm` commands to update the K8s manifests in the cluster.

GitOps is a practice where Git is the 'Single Source of Truth' for infrastructure. A tool (like ArgoCD) watches Git and automatically syncs the cluster state to match the code.

Easy auditing (via Git history), faster recovery (re-apply from Git), improved security (no direct kubectl access needed), and consistent environments across clusters.

ArgoCD is a declarative GitOps continuous delivery tool for K8s. It monitors Git repositories for K8s manifests and ensures the cluster stays in sync with that code.

Flux is another popular GitOps tool that automatically keeps K8s clusters in sync with configuration in Git and automates updates to those configurations when there is new code.

1. Connect ArgoCD to your Git repo. 2. Define an 'Application' resource pointing to the manifest folder. 3. Enable 'Auto-Sync' or manually sync the app via the UI/CLI.

It is the automation of the entire release process, where every change passing the test suite is automatically deployed to the production K8s cluster without human intervention.

Upgrade the Control Plane components first (API server, etc.), then upgrade the worker nodes one by one by draining them, updating the kubelet, and uncordoning.

Always follow a 'Rolling' approach. Upgrade one node at a time to maintain capacity. Ensure your applications have multiple replicas so they stay available during the node reboots.

Back up the `etcd` data snapshots and the YAML manifests stored in Git. For persistent data, use CSI-level snapshots or tools like Velero to back up PVs and K8s resources together.

Use `etcdctl snapshot save` to create a binary backup file. To restore, use `etcdctl snapshot restore`, which initializes a new etcd data directory from the snapshot.

If a node fails, the Control Plane detects it via missed heartbeats. It marks the node as 'NotReady' and automatically reschedules the affected Pods onto healthy nodes.

Pods on that node stop working. After a timeout (default 5 mins), K8s marks the pods for deletion and the controllers (like Deployment) create new pods on other nodes to maintain replicas.

Using `kubectl drain <node-name>`. This 'cordons' the node (no new pods) and safely evicts all existing pods so maintenance can be performed.

Cordon simply marks a node as unschedulable (no new pods). Drain marks it as unschedulable AND evicts all current pods to other nodes.

Using the 'Prometheus-Grafana' stack for metrics and 'ELK/EFK' for logs. You also monitor the Control Plane health and resource usage (CPU/Memory) of every node.

Prometheus is a time-series database that scrapes metrics from K8s targets. It provides powerful alerting and querying (PromQL) to detect cluster issues in real-time.

Grafana is a visualization tool that connects to Prometheus to create beautiful, real-time dashboards showing the health, traffic, and resource usage of your K8s cluster.

Usually via a 'Logging Agent' (like Fluentd or Promtail) running as a DaemonSet. It scrapes container logs from `/var/log/pods` and sends them to a central store (Elasticsearch).

E=Elasticsearch (Store), L/F=Logstash/Fluentd (Collector), K=Kibana (Visualizer). It is the standard open-source stack for log aggregation and analysis in K8s.

For ad-hoc: `kubectl logs`. For production: Use a cluster-level logging agent that collects stdout/stderr from every pod and ships it to an external log management platform.

1. RBAC (least privilege). 2. Network Policies (isolation). 3. Encrypt etcd. 4. Use Pod Security Standards. 5. Enable Audit Logging. 6. Scan container images for vulnerabilities.

An older K8s feature (deprecated) used to control security-sensitive aspects of pod specification (like running as root). It has been replaced by Pod Security Admission.

A set of three policies (Privileged, Baseline, Restricted) used to enforce different levels of security on pods at the namespace level to prevent privilege escalation.

It acts as a firewall for Pods. It improves security by following a 'Zero Trust' model, blocking all traffic by default and only allowing specific, labeled pods to communicate.

Using 'cert-manager' to automate certificate issuance and renewals. The certificates are stored as `kubernetes.io/tls` Secrets and used by Ingress Controllers to secure HTTPS traffic.

1. `kubectl logs <pod>` to see the application error. 2. `kubectl describe pod` to check exit codes and events. 3. Check environment variables, ConfigMaps, and Secret values.

1. Verify image name/tag. 2. Check if the image exists in the registry. 3. Check for correct `imagePullSecrets` if the registry is private.

It means the scheduler cannot find a node to place the pod. Reasons: Insufficient CPU/Memory, Taints on nodes without Tolerations, or specific Node Affinity rules.

The pod is shutting down. If it's stuck here, it might be waiting for a 'finalizer' to complete or the container process is ignoring the SIGTERM signal.

Check `kubectl describe pod`. Look at the 'Events' section at the bottom; it will tell you if there are scheduling issues, mount failures, or configuration errors.

Using `kubectl get events` for cluster-wide events, or `kubectl describe pod <name>` to see events specifically related to that individual pod.

Out Of Memory Killed. The container tried to use more RAM than its defined 'Limit'. The kernel killed the process to protect the Node from crashing.

1. Check CPU/Memory usage via `top pods`. 2. Analyze application logs for bottlenecks. 3. Check if HPA is scaling correctly. 4. Verify if networking latency or DB locks are the cause.

1. Verify the Ingress rules. 2. Check if the Ingress Controller is running. 3. Ensure the Service selector matches the Pod labels. 4. Test internal connectivity via `kubectl exec`.

1. Check `rollout status`. 2. Inspect logs and events. 3. Use `kubectl rollout undo` to revert to the previous stable version immediately while you investigate the cause.

1. Check Network Policies. 2. Ensure egress traffic is allowed. 3. Check if the Node can reach the external IP. 4. Use an `ExternalName` service or manual `Endpoints` to map the DB.

1. Add more Nodes (Cluster Autoscaler). 2. Reduce the 'Requests' in your Pod spec. 3. Evict non-critical pods with lower priority to make room.

StatefulSet. It provides stable network names (member-0) and persistent storage mapping, ensuring that if a DB pod moves to a new node, it re-attaches to its specific data disk.

Configure the Ingress Controller with an annotation like `nginx.ingress.kubernetes.io/affinity: cookie`. This ensures the load balancer sends the same client to the same pod.

Use an Ingress Controller (Nginx/HAProxy) sitting behind a cloud `LoadBalancer` service. This provides a single IP entry point with URL-based routing and SSL security.

1. Check `kubectl top pod`. 2. Use a profiler to find memory leaks. 3. Set or adjust `limits` in the PodSpec. 4. If it's a Java app, adjust JVM heap settings (Xmx).

A CronJob. You define the schedule `0 2 * * *` and the Job template to execute your maintenance script, and K8s will handle the automated execution and cleanup.