Installation and Configuration: CCA practice questions

There are two supported ways to put Cilium on a cluster: the cilium CLI and the Helm chart. The quick installation with the CLI targets the cluster of the current kubectl context, tries to pick the best configuration for the detected distribution, and restarts pods that were already running so that they come under Cilium networking. The version is passed as an argument, for example cilium install 1.20.3, and Helm values can be passed through with --set. The defaults differ per platform; the guide notes, for example, that GKE gets encapsulation with cluster-pool IPAM and EKS uses ENI mode. For clusters above about 500 nodes or with specific datapath requirements, the documentation points to the more detailed Helm-based guides.

Verification follows the same CLI. cilium status --wait reports whether the agent, operator, Hubble and Cluster Mesh are healthy, along with DaemonSet and Deployment readiness and the images in use. cilium connectivity test verifies network connectivity across the cluster and prints a report of the checks it ran. When the install fails, the guide says to start with cilium status and the logs of the failing pods.

Kube-proxy replacement is the configuration choice with the largest effect. With the Helm value kubeProxyReplacement=true, Cilium implements ClusterIP, NodePort, LoadBalancer, externalIPs and hostPort in eBPF so kube-proxy is not needed; the default false only enables in-cluster load balancing of ClusterIP Services. Because nothing then provides the kubernetes Service for the agent, you must set k8sServiceHost and k8sServicePort to the API server address. With the option on, the agent refuses to start if the kernel lacks the required support. To confirm it works, run cilium-dbg status and look for KubeProxyReplacement: True, list programmed services with cilium-dbg service list, and check that iptables-save shows no KUBE-SVC rules. Related tuning includes Maglev consistent hashing with loadBalancer.algorithm=maglev, Direct Server Return for external traffic and XDP acceleration.

Other options are chosen the same way: the routing mode, the IPAM mode (which should not be changed on a running cluster except by a documented migration), Hubble, and features such as Gateway API. The Hubble guide shows the common pattern of changing one value on an existing release with helm upgrade --reuse-values --set hubble.relay.enabled=true.

Upgrades have their own rules. Run the pre-flight check first, which pre-pulls the new image and validates existing CiliumNetworkPolicies. Move one minor version at a time, after updating to the latest patch of the current minor. Avoid --reuse-values across minor versions because it ignores values newly introduced by the chart; export the current values with helm get values and pass them with -f instead. Set upgradeCompatibility to the first Cilium version installed in the cluster to reduce datapath disruption. A failed upgrade can be undone with helm rollback or kubectl rollout undo on the cilium DaemonSet.