ansible-role-flanneld

Ce playbook Ansible est utilisé dans Kubernetes the not so hard way with Ansible - Worker. Il installe et configure le binaire flanneld. Flannel est responsable de fournir un réseau IPv4 de couche 3 entre plusieurs nœuds d'un cluster. Flannel ne contrôle pas comment les conteneurs sont reliés à l'hôte, mais uniquement la manière dont le trafic est transporté entre les hôtes. Cependant, Flannel fournit un plugin CNI pour Kubernetes et des conseils sur l'intégration avec Docker.

Versions

Je tague chaque version et j'essaie de suivre la gestion de version sémantique. Si vous souhaitez utiliser le rôle, je vous recommande de vérifier le dernier tag. La branche principale est principalement pour le développement, tandis que les tags marquent les versions stables. Un tag 8.0.0+0.16.1 signifie que c'est la version 8.0.0 de ce rôle et qu'il est destiné à être utilisé avec la version Flannel 0.16.1 (mais pourrait aussi fonctionner avec des versions plus récentes). Si le rôle lui-même change, X.Y.Z avant + augmentera. Si la version de Flannel change, X.Y.Z après + augmentera. Cela permet de taguer les corrections de bogues et les nouvelles versions majeures du rôle tout en le développant pour une version spécifique de Flannel.

Exigences

• Un cluster etcd doit être opérationnel (voir ansible-role-etcd). Le rôle se connectera au premier nœud qu'il trouve dans le groupe k8s_etcd d'Ansible et exécutera etcdctl là-bas pour ajouter une nouvelle entrée dans etcd. Cette entrée contient la configuration du réseau Flannel et se trouve à "flannel_etcd_prefix/config".
• Plugins CNI (voir ansible-role-cni)

Changelog

voir CHANGELOG.md

Variables du rôle

# L'interface sur laquelle les services K8s devraient écouter. Comme toute la
# communication du cluster devrait utiliser l'interface VPN, le nom de l'interface est
# normalement "wg0", "tap0" ou "peervpn0".
k8s_interface: "tap0"
# Répertoire où les certificats K8s et d'autres configurations sont stockés
# sur les hôtes Kubernetes.
k8s_conf_dir: "/var/lib/kubernetes"
# Répertoire du plugin de réseau CNI
k8s_cni_conf_dir: "/etc/cni/net.d"
# Le répertoire d'où copier les certificats K8s. Par défaut, cela
# s'étend au $HOME LOCAL de l'utilisateur (l'utilisateur qui exécute "ansible-playbook ..."
# plus "/k8s/certs". Cela signifie que si le répertoire $HOME de l'utilisateur est par exemple
# "/home/da_user", alors "k8s_ca_conf_directory" aura une valeur de
# "/home/da_user/k8s/certs".
k8s_ca_conf_directory: "{{ '~/k8s/certs' | expanduser }}"

etcd_bin_dir: "/usr/local/bin"
etcd_client_port: 2379
etcd_certificates:
  - ca-etcd.pem
  - ca-etcd-key.pem
  - cert-etcd.pem
  - cert-etcd-key.pem

flannel_version: "v0.16.1"
flannel_etcd_prefix: "/kubernetes-cluster/network"
flannel_ip_range: "10.200.0.0/16"
flannel_backend_type: "vxlan"
flannel_cni_interface: "cni0"
flannel_subnet_file_dir: "/run/flannel"
flannel_options_dir: "/etc/flannel"
flannel_bin_dir: "/usr/local/sbin"
flannel_cni_conf_file: "10-flannel"
flannel_cni_spec_version: "0.3.1"

flannel_systemd_restartsec: "5"
flannel_systemd_limitnofile: "40000"
flannel_systemd_limitnproc: "1048576"
# Directive "ExecStartPre" dans le fichier de service systemd de flannel. Cette commande
# est exécutée avant le démarrage du service flannel.
flannel_systemd_execstartpre: "/bin/mkdir -p {{flannel_subnet_file_dir}}"
# Directive "ExecStartPost" dans le fichier de service systemd de flannel. Cette commande
# est exécutée après le démarrage du service flannel. Si vous êtes dans le cloud Hetzner,
# cela peut être important. Dans ce cas, cela modifie le paramètre de déchargement de somme de contrôle TX
# pour l'interface "flannel.1". Il semble qu'il y ait un
# bogue de déchargement de somme de contrôle (noyau/driver) avec l'encapsulation vxlan de Flannel
# (tout à l'intérieur de UDP) dans l'encapsulation WireGuard.
# flannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off"

flannel_settings:
  "etcd-cafile": "{{k8s_conf_dir}}/ca-etcd.pem"
  "etcd-certfile": "{{k8s_conf_dir}}/cert-etcd.pem"
  "etcd-keyfile": "{{k8s_conf_dir}}/cert-etcd-key.pem"
  "etcd-prefix": "{{flannel_etcd_prefix}}"
  "iface": "{{k8s_interface}}"
  "public-ip": "{{hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address}}"
  "subnet-file": "{{flannel_subnet_file_dir}}/subnet.env"
  "ip-masq": "true"
  "healthz-ip": "0.0.0.0"
  "healthz-port": "0" # 0 = désactiver

flannel_cni_conf: |
  {
    "name": "{{flannel_cni_interface}}",
    "cniVersion": "{{flannel_cni_spec_version}}",
    "plugins": [
      {
        "type": "flannel",
        "delegate": {
          "hairpinMode": true,
          "isDefaultGateway": true
        }
      },
      {
        "type": "portmap",
        "capabilities": {
          "portMappings": true
        }
      }
    ]
  }

Les paramètres pour le démon Flannel définis dans flannel_settings peuvent être remplacés par la définition d'une variable appelée flannel_settings_user. Vous pouvez également ajouter des paramètres supplémentaires en utilisant cette variable. Par exemple, pour remplacer la valeur par défaut de healthz-ip et ajouter le paramètre kubeconfig-file, ajoutez les paramètres suivants à group_vars/all.yml ou à l'emplacement qui vous convient le mieux :

flannel_settings_user:
  "healthz-ip": "1.2.3.4"
  "kubeconfig-file": "/etc/k8s/k8s.cfg"

Un mot sur flannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off" qui est commenté par défaut. Si la communication Pod-à-Pod fonctionne pour vous (entre hôtes) mais que la communication Pod-à-Service ou Node-à-Service ne fonctionne pas (également entre hôtes), alors définir cette variable pourrait aider. Cela a au moins aidé à faire fonctionner le trafic Flannel via VPN WireGuard dans le cloud Hetzner. Il semble que le déchargement de somme de contrôle TX ne fonctionne pas dans ce cas, ce qui entraîne des erreurs de somme de contrôle. Vous pouvez identifier ce problème de cette manière. Connectez-vous à deux nœuds de travail via SSH. Identifiez un service qui s'exécute par exemple sur worker01 et essayez d'y accéder depuis worker02. Par exemple, le pod kube-dns ou coredns est un bon candidat car il s'exécute pratiquement sur chaque cluster Kubernetes. Malgré le fait que les requêtes DNS sont normalement envoyées via le protocole UDP, DNS fonctionne également avec TCP. Supposons que kube-dns s'exécute sur worker01 et que sur worker02, vous essayiez de vous connecter au service DNS via

telnet 10.32.0.254 53
Essai de connexion à 10.32.0.254...

Mais comme vous pouvez le voir, rien ne se passe. Alors exécutons tcpdump sur worker01, par exemple tcpdump -nnvvvS -i any src host <ip_of_worker02>. Maintenant, nous capturons tout le trafic de worker02 sur worker01. Exécutez à nouveau telnet 10.32.0.254 53 sur worker02 et vous pourrez voir quelque chose comme ceci :

22:17:18.500515 IP (tos 0x0, ttl 64, id 32604, offset 0, flags [none], proto UDP (17), length 110)
    10.8.0.112.43977 > 10.8.0.111.8472: [somme udp ok] OTV, flags [I] (0x08), overlay 0, instance 1
IP (tos 0x10, ttl 63, id 10853, offset 0, flags [DF], proto TCP (6), length 60)
    10.200.94.0.40912 > 10.200.1.37.53: Flags [S], cksum 0x74e3 (incorrect -> 0x890f), seq 3891002740, win 43690, options [mss 65495,sackOK,TS val 2436992709 ecr 0,nop,wscale 7], length 0
...

Si vous regardez de plus près, dans la dernière ligne, vous voyez dans cet exemple cksum 0x74e3 (incorrect -> 0x890f), et c'est le problème. Le paquet SYN est rejeté car la somme de contrôle est incorrecte. Maintenant, si vous désactivez le déchargement de la somme de contrôle pour l'interface flannel.1 sur tous les hôtes (encore une fois, au moins sur le cloud Hetzner), cela fonctionne :

telnet 10.32.0.254 53
Essai de connexion à 10.32.0.254...
Connecté à 10.32.0.254.
Le caractère d'échappement est '^]'.
...

Et si nous examinons à nouveau la sortie de tcpdump :

22:34:26.605677 IP (tos 0x0, ttl 64, id 794, offset 0, flags [none], proto UDP (17), length 110)
    10.8.0.112.59225 > 10.8.0.111.8472: [somme udp ok] OTV, flags [I] (0x08), overlay 0, instance 1
IP (tos 0x10, ttl 63, id 16989, offset 0, flags [DF], proto TCP (6), length 60)
    10.200.94.0.42152 > 10.200.1.37.53: Flags [S], cksum 0xd49b (correct), seq 1673757006, win 43690, options [mss 65495,sackOK,TS val 2438020768 ecr 0,nop,wscale 7], length 0
...

Vous verrez dans la dernière ligne que la somme de contrôle est correcte. Vous pouvez inspecter l'état du déchargement de protocole et d'autres fonctionnalités de l'interface Flannel avec ethtool -k flannel.1.

Dépendances

• etcd (voir ansible-role-etcd)
• Plugins CNI (voir ansible-role-cni ou tout autre rôle qui installe Plugins CNI)

Exemple de Playbook

- hosts: flannel
  roles:
    - githubixx.flanneld

Licence

LICENCE PUBLIQUE GÉNÉRALE GNU Version 3

Informations sur l'auteur

http://www.tauceti.blog