https://dev-journal.hallblazzar.dev/categories/cilium/ Recent content in Cilium on Hallblazzar: Dev Journal Hugo en Sat, 02 May 2026 00:00:00 +0000 https://dev-journal.hallblazzar.dev/posts/2026_may_02_cni_migration/ Sat, 02 May 2026 00:00:00 +0000 https://dev-journal.hallblazzar.dev/posts/2026_may_02_cni_migration/ <div class="notice tip"> <div class="notice-title"> <i class="fa-solid fa-lightbulb" aria-hidden="true"></i>Tip </div> <div class="notice-content">TL;DR: If you&rsquo;re a developer looking for alternatives and migration plans for CNI plugin on your Kubernetes cluster, Cilium is a good choise which supports live-migration from almost any CNIs, NetworkPolicies and comprehensive observability ecosystems.</div> </div> <p>CNI plugin migration for a running Kubernetes cluster, especially in production environment, is never a trivial task. One simple strategy is <a href="https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment" class="external-link" target="_blank" rel="noopener">Blue/Green deployment</a>, which provisions a new cluster with target CNI and moving workloads from current cluster to the new one. This approach ensures the least downtime(still need extra setup, e.g., loadbalancer, to ensure availability) and ignores discrepancy between CNIs. However, what if in-place migration is necessary? This is not common but challenging senario, and mostly needed when operating a cluster with stateful or unmanaged workloads. For instance, a platform provides computing resource by Kubernetes but operators have no control to services deployed on it. If operators want to migrate CNI without letting users aware/involve, in-place migration will still be required.</p>