Master Kubernetes Essentials: kube-proxy, Pods, Deployments, Services & More

1. What is the principle of kube-proxy IPVS? IPVS became GA in Kubernetes 1.11 and is used by kube-proxy for high‑performance load balancing with a hash‑table data structure that scales virtually without limit. In IPVS mode, ipset (an indexed set of IPs, CIDRs, ports, etc.) replaces linear iptables chains, reducing rule count and improving performance.

2. Differences and similarities between kube-proxy IPVS and iptables Both are built on Netfilter, but iptables is a firewall tool while IPVS is dedicated to high‑performance load balancing. IPVS offers better scalability, more sophisticated load‑balancing algorithms, health checks, connection retries, and dynamic ipset updates compared to iptables.

3. What is a static Pod? A static Pod is managed directly by the kubelet on a specific node, not via the API server, and cannot be associated with a ReplicationController, Deployment, or DaemonSet. It is always created by the kubelet on its host node.

4. Possible Pod states

Pending: Pod created but one or more container images are still being pulled.

Running: All containers are created and at least one is running, starting, or restarting.

Succeeded: All containers have terminated successfully and will not restart.

Failed: All containers have terminated, with at least one exiting with a failure.

Unknown: The Pod state cannot be obtained, often due to network issues.

5. Main process of creating a Pod The client submits a Pod manifest to the kube‑apiserver, which notifies the controller‑manager to create the resource. The controller‑manager stores the spec in etcd. The scheduler selects a suitable node, sends the pod spec to the node’s kubelet, and the kubelet creates and runs the Pod, reporting status back to the scheduler and etcd.

6. Pod restart policies RestartPolicy applies to all containers in a Pod and is evaluated by the kubelet on the node. Options are Always (default), OnFailure , and Never . Controllers impose constraints: RC and DaemonSet require Always ; Job allows OnFailure or Never .

7. Pod health‑check mechanisms Kubernetes uses two main probes: LivenessProbe (determines if a container is alive; failing containers are killed) and ReadinessProbe (determines if a container is ready to receive traffic; failing containers are removed from Service endpoints). A StartupProbe can be used for slow‑starting containers.

8. Common LivenessProbe types ExecAction runs a command inside the container; TCPSocketAction attempts a TCP connection; HTTPGetAction performs an HTTP GET request and expects a 2xx‑3xx status code.

9. Typical Pod scheduling methods Deployments/RCs manage replica counts automatically. NodeSelector schedules Pods to nodes with matching labels. NodeAffinity provides required (hard) and preferred (soft) rules. Taints and Tolerations allow nodes to repel or accept specific Pods.

10. Init containers Init containers run to completion before application containers start. They execute sequentially; each must succeed before the next begins. Only after all init containers finish does the Pod become fully initialized.

11. Deployment upgrade process Updating a Deployment creates a new ReplicaSet, scales it up, and scales down the old ReplicaSet step by step until the old set reaches zero replicas.

12. Deployment upgrade strategies Two strategies are supported via spec.strategy.type: Recreate (kills all existing Pods before creating new ones) and RollingUpdate (gradually replaces Pods, configurable with maxUnavailable and maxSurge).

13. DaemonSet characteristics A DaemonSet ensures that exactly one Pod runs on each node in the cluster. It does not support a replicas field. Common use cases include node‑level log collection and monitoring.

14. Horizontal Pod Autoscaling (HPA) HPA monitors metrics (e.g., CPU) via the Metrics Server and adjusts the replica count of a Deployment, RC, or ReplicaSet based on defined thresholds.

15. Service types ClusterIP provides an internal virtual IP; NodePort exposes the Service on a port of each node; LoadBalancer provisions an external load balancer (typically in public clouds).

16. Service load‑balancing policies RoundRobin (default) distributes requests evenly across Pods; SessionAffinity pins a client IP to a specific Pod for the duration of the session.

17. Headless Service A headless Service disables the ClusterIP, allowing clients to retrieve the list of backing Pods directly via label selectors, useful when custom load balancing or peer discovery is needed.

18. Accessing cluster services from outside Options include mapping Pod ports to the host (hostPort), exposing a Service via NodePort , or using a cloud provider’s LoadBalancer service.

19. Ingress Ingress resources define HTTP routing rules that map URLs to Services. An Ingress Controller implements these rules, forwarding traffic directly to Service endpoints and bypassing kube‑proxy.

20. Image pull policies Three policies exist: Always (pulls the image on every start, used for :latest tags), Never (uses only local images), and IfNotPresent (pulls only if the image is absent locally). The default is Always for :latest and IfNotPresent otherwise.

21. Load balancers Load balancers expose Services and can be internal or external. Internal load balancers distribute traffic within the cluster, while external load balancers route traffic from outside the cluster to backend Pods.