Cloud Orchestration with Kubernetes
Cloud Orchestration with Kubernetes
This domain tests container orchestration and how networking, storage, and policy plug into a cluster. Expect Pod, Service, and Ingress semantics, CNI, NetworkPolicy, RBAC, and Juniper Contrail CNI or Multus scenarios.
Core rules
- Control plane: API server handles all requests, etcd stores state, scheduler binds Pods, and controller manager reconciles desired state. Nodes run kubelet, kube-proxy or an eBPF data plane, and a container runtime through CRI.
- Pods are the scheduling unit; Deployments manage ReplicaSets; Services provide stable virtual IPs through ClusterIP, NodePort, or LoadBalancer; Ingress maps HTTP host and path to Services.
- CNI provides pod networking; CSI provides volumes. NetworkPolicy is namespace and pod-selector based and is enforced only if the CNI supports it.
- RBAC uses Roles or ClusterRoles bound to subjects. Namespaces provide scope and quota boundaries.
Worked example
A web Deployment has three replicas; expose it on port 80 with a Service and block all other pods in the namespace. Create a Service with selector app=web and port 80; ClusterIP gives internal reachability. Add a default-deny NetworkPolicy in the namespace, then allow ingress to app=web on TCP/80. Reasoning: the policy only works with a CNI that enforces it; kube-proxy alone does not. The selector must match the Pod labels or the allow rule has no effect.
Traps
- Assuming NetworkPolicy is always enforced. It depends on the CNI plugin.
- Confusing ClusterIP with an externally reachable IP. ClusterIP is virtual and internal.
- Overlapping pod CIDR and service CIDR, which breaks routing.