La transition d'un réseau CNI Flannel vers Cilium au sein d'un cluster Kubernetes est une opération qui nécessite une planification et une exécution minutieuses. Ce guide détaillé expose la procédure complète de migration, incluant les prérequis et les considérations essentielles.

I. Procédure de Migration Fondamentale

1. Vérifications Préliminaires

• Version du Noyau Linux : Assurez-vous d'utiliser une version >= 4.19.57. Une version >= 5.10 est fortement recommandée pour bénéficier pleinement des optimisations eBPF.
• Désinstallation de Flannel : Procédez à la suppression des composants Flannel et de ses configurations résdiuelles.

kubectl delete -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
sudo rm -rf /var/lib/cni/flannel /etc/cni/net.d/10-flannel.conflist

• Désactivation de kube-proxy (si actif) : Si vous prévoyez d'utiliser Cilium en remplacement total de kube-proxy, supprimez l'instance existante.

kubectl delete daemonset kube-proxy -n kube-system

2. Installation de Cilium

Utilisez Helm pour déployer Cilium en configurant le remplacement de kube-proxy et le type de tunnel.

# Ajout du dépôt Helm de Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update

# Déploiement de Cilium avec eBPF en remplacement de kube-proxy et tunnel VXLAN
helm install cilium cilium/cilium -n kube-system \
  --set kubeProxyReplacement=strict \
  --set tunnel=vxlan \
  --set ipam.mode=kubernetes \
  --set hubble.enabled=true \
  --set hubble.ui.enabled=true

3. Validation du Déploiement

Vérifiez l'état des agents et de l'opérateur Cilium. Tous les composants devraient afficher un statut "OK".

cilium status

II. Paramètres de Configuration Essentiels

Le tableau suivant détaille les options de configuration clés pour une installation robuste de Cilium :

III. Gestion des Risques et Solutions

1. Risques d'Interruption Réseau

• Symptôme : Les pods redémarrés peuvent acquérir de nouvelles adresses IP, entraînant des indisponibilités de service.
• Atténuation : Adoptez une approche de migration progressive par nœud.

# Drainer un nœud pour évacuer les pods (ignorer les DaemonSets de Cilium)
kubectl drain <nom-du-nœud> --ignore-daemonsets --delete-local-data

# Une fois le nœud traité (Cilium installé, pods migrés), le rendre de nouveau planifiable
kubectl uncordon <nom-du-nœud>

2. Problèmes de Compatibilité des Politiques

• Limitation de Flannel : Flannel ne fournit qu'une connectivité réseau de base, sans capacité de politique de sécurité de couche 7 (L7).
• Conversion de Politiques Cilium : Cilium permet la définition de politiques réseau fines, y compris au niveau applicatif.

Exemple : Contrôle d'accès HTTP (impossible avec Flannel)

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend-api
spec:
  endpointSelector:
    matchLabels:
      app: web-frontend
  egress:
  - toEndpoints:
    - matchLabels:
        app: api-backend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/api/v1/orders"

3. Recommandations pour l'Optimisation des Performances

• Mode d'accélération eBPF : Pour les noyaux Linux >= 5.10, activez la translation d'adresses réseau (NAT) basée sur eBPF.

helm upgrade cilium cilium/cilium -n kube-system --reuse-values \
  --set bpf.masquerade=true

• Routage Natif (Native Routing) : Si votre infrastructure réseau sous-jacente permet le routage direct vers les adresses IP des pods, le routage natif peut remplacer VXLAN pour une performance optimale.

# Ajout lors de l'installation ou la mise à jour
helm upgrade cilium cilium/cilium -n kube-system --reuse-values \
  --set routingMode=native

Note : Le routage natif requiert que les IP des pods soient routables directement depuis les autres nœuds.

IV. Analyse Comparative et Bénéfices Architecturaux

Cilium, propulsé par eBPF, surpasse Flannel sur plusieurs aspects clés, offrant des améliorations significatives en termes de performance et de sécurité :

V. Liste de Contrôle pour l'Acceptation Opérationnelle

1. Validation des Fonctions de Base :
   • Vérification de la connectivité entre services de type ClusterIP.
   • Test d'accès externe aux services de type NodePort.
   • Confirmation de la résolution DNS pour les services et pods.
2. Test des Fonctionnalités Avancées :
   • Exécution de cilium connectivity test pour s'assurer que les politiques réseau sont correctement appliquées.
   • Utilisation de l'interface utilisateur de Hubble (accessible généralement sur le port 12000) pour visualiser les flux réseau et les logs de sécurité.
3. Évaluation des Performances :
   • Utilisation d'outils comme netperf pour mesurer le débit TCP et UDP.
   • Surveillance de l'utilisation CPU de cilium-agent (visez une consommation inférieure ou égale à 10%).

Après la migration, une surveillance continue du trafic métier pendant au moins 24 heures est recommandée, avec une attention particulière aux services UDP et aux applications StatefulSet.