prep

2026-03-26 11:14:29 +01:00
parent c1609ea9d9
commit a8fa18520c
16 changed files with 730 additions and 261 deletions
--- a/docs/multus-docker-network.md
+++ b/docs/multus-docker-network.md
@@ -0,0 +1,121 @@
+# Connecter un pod Kubernetes au réseau Docker `oc` via Multus CNI
+
+## Contexte
+
+Le schedulerd tourne dans le réseau Docker `oc` avec accès à mongo, loki, nats et consul.
+Les jobs Kubernetes (`oc-monitord`) lancés par le schedulerd n'ont pas accès à ce réseau par défaut.
+
+Multus CNI permet d'attacher une seconde interface réseau au pod, branchée directement sur le bridge Docker `oc`.
+
+---
+
+## Étape 1 — Récupérer les infos du réseau Docker `oc`
+
+```bash
+# Nom du bridge sur l'hôte (les 12 premiers caractères de l'ID)
+docker network inspect oc --format '{{.Id}}' | cut -c1-12
+# → ex: a1b2c3d4e5f6  →  bridge = br-a1b2c3d4e5f6
+
+# Subnet
+docker network inspect oc --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
+# → ex: 172.20.0.0/16
+
+# Gateway
+docker network inspect oc --format '{{range .IPAM.Config}}{{.Gateway}}{{end}}'
+# → ex: 172.20.0.1
+```
+
+---
+
+## Étape 2 — Installer Multus
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
+```
+
+Attendre que les pods soient ready :
+
+```bash
+kubectl -n kube-system wait --for=condition=ready pod -l app=multus --timeout=60s
+```
+
+---
+
+## Étape 3 — Créer la NetworkAttachmentDefinition
+
+Remplacer `br-xxxxxxxxxxxx`, le subnet et la gateway par les valeurs récupérées à l'étape 1.
+
+```yaml
+# oc-network-attachment.yaml
+apiVersion: k8s.cni.cncf.io/v1
+kind: NetworkAttachmentDefinition
+metadata:
+  name: docker-oc-network
+  namespace: default
+spec:
+  config: '{
+    "cniVersion": "0.3.1",
+    "type": "bridge",
+    "bridge": "br-xxxxxxxxxxxx",
+    "isGateway": false,
+    "ipMasq": false,
+    "ipam": {
+      "type": "host-local",
+      "subnet": "172.20.0.0/16",
+      "rangeStart": "172.20.100.0",
+      "rangeEnd": "172.20.100.255",
+      "gateway": "172.20.0.1"
+    }
+  }'
+```
+
+> `rangeStart` / `rangeEnd` dans une plage haute pour éviter les collisions avec les IPs assignées par Docker.
+
+```bash
+kubectl apply -f oc-network-attachment.yaml
+```
+
+---
+
+## Étape 4 — Annoter le pod dans le code
+
+Dans `daemons/execute_monitor_container.go`, ajouter l'annotation sur le `PodTemplateSpec` :
+
+```go
+Template: corev1.PodTemplateSpec{
+    ObjectMeta: metav1.ObjectMeta{
+        Annotations: map[string]string{
+            "k8s.v1.cni.cncf.io/networks": "docker-oc-network",
+        },
+    },
+    Spec: corev1.PodSpec{
+        RestartPolicy: corev1.RestartPolicyNever,
+        // ...
+    },
+},
+```
+
+---
+
+## Étape 5 — Vérifier
+
+Une fois un pod lancé :
+
+```bash
+# Vérifier les interfaces réseau du pod
+kubectl exec <pod-name> -- ip addr
+# Doit afficher eth0 (réseau K8s) + net1 (réseau oc)
+
+# Tester la résolution DNS vers les services Docker
+kubectl exec <pod-name> -- ping mongo
+kubectl exec <pod-name> -- ping loki
+kubectl exec <pod-name> -- ping nats
+```
+
+---
+
+## Points d'attention
+
+- Le plugin CNI `bridge` doit être disponible sur le node — il l'est par défaut sur k3s.
+- Le bridge Docker (`br-xxxxxxxxxxxx`) doit exister sur l'hôte au moment où le pod démarre. Si Docker redémarre, l'ID du bridge peut changer si le réseau est recréé.
+- La résolution DNS des hostnames Docker (`mongo`, `loki`, etc.) depuis le pod nécessite que le pod utilise le DNS Docker (`127.0.0.11`). Si la résolution ne fonctionne pas, ajouter dans la NAD : `"dns": {"nameservers": ["127.0.0.11"]}`.