A kubeadm cluster needs exactly one CNI implementation before CoreDNS and normal Pods become ready. This guide installs the stable Cilium 1.19.6 Helm chart and validates node, Pod, Service, DNS, and policy paths.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
helm repo add cilium https://helm.cilium.io/
helm repo update
helm upgrade --install cilium cilium/cilium
--version 1.19.6
--namespace kube-system
kubectl -n kube-system rollout status daemonset/cilium --timeout=5m
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: v1
kind: Pod
metadata: {name: net-a, labels: {app: net-a}}
spec:
containers: [{name: web, image: nginx:1.28-alpine}]
---
apiVersion: v1
kind: Service
metadata: {name: net-a}
spec: {selector: {app: net-a}, ports: [{port: 80}]}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl get nodes
kubectl -n kube-system get pods -l k8s-app=cilium -o wide
kubectl apply -f net-test.yaml
kubectl run net-client --rm -it --restart=Never --image=curlimages/curl:8.14.1 -- http://net-a
kubectl run dns-client --rm -it --restart=Never --image=busybox:1.37 -- nslookup kubernetes.default
cilium status --wait
cilium connectivity test
4. Troubleshooting
Check Cilium Pods and agent logs before debugging workloads. Overlapping host, Pod, and Service CIDRs cause subtle routing failures. CoreDNS will not become healthy until the Pod network works.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete -f net-test.yaml --ignore-not-found
helm uninstall cilium -n kube-system
# Removing the only CNI interrupts all Pod networking.
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
