ansible-role-flanneld

Dieses Ansible-Playbook wird in Kubernetes the not so hard way with Ansible - Worker verwendet. Es installiert und konfiguriert die flanneld-Datei. Flannel ist verantwortlich für die Bereitstellung eines Layer 3 IPv4-Netzwerks zwischen mehreren Knoten in einem Cluster. Flannel steuert nicht, wie Container mit dem Host vernetzt sind, sondern nur, wie der Verkehr zwischen den Hosts transportiert wird. Flannel bietet jedoch ein CNI-Plugin für Kubernetes und eine Anleitung zur Integration mit Docker.

Versionen

Ich tagge jede Veröffentlichung und versuche, das semantische Versionieren einzuhalten. Wenn du die Rolle verwenden möchtest, empfehle ich, das neueste Tag abzurufen. Der Master-Branch ist grundsätzlich in der Entwicklung, während die Tags stabile Versionen kennzeichnen. Ein Tag 8.0.0+0.16.1 bedeutet, dass dies die Version 8.0.0 dieser Rolle ist und sie mit Flannel Version 0.16.1 verwendet werden soll (funktioniert aber möglicherweise auch mit neueren Versionen). Wenn sich die Rolle selbst ändert, wird X.Y.Z vor dem + erhöht. Wenn sich die Flannel-Version ändert, wird X.Y.Z nach dem + erhöht. So können Bugfixes und neue Hauptversionen der Rolle getaggt werden, während sie noch für eine bestimmte Flannel-Version entwickelt wird.

Anforderungen

• Ein etcd-Cluster muss aktiv und erreichbar sein (siehe ansible-role-etcd). Die Rolle wird sich mit dem ersten Knoten verbinden, den sie in Ansible's k8s_etcd-Gruppe findet, und dort etcdctl ausführen, um einen neuen Eintrag in etcd hinzuzufügen. Dieser Eintrag enthält die Flannel-Netzwerkkonfiguration und befindet sich unter "flannel_etcd_prefix/config".
• CNI-Plugins (siehe ansible-role-cni)

Änderungsprotokoll

Siehe CHANGELOG.md

Rollen-Variablen

# Die Schnittstelle, auf der die K8s-Services lauschen sollen. Da die gesamte Clusterkommunikation das VPN verwenden sollte, ist der Schnittstellenname normalerweise "wg0", "tap0" oder "peervpn0".
k8s_interface: "tap0"
# Verzeichnis, in dem die K8s-Zertifikate und andere Konfigurationen auf den Kubernetes-Hosts gespeichert sind.
k8s_conf_dir: "/var/lib/kubernetes"
# CNI-Netzwerk-Plugin-Verzeichnis
k8s_cni_conf_dir: "/etc/cni/net.d"
# Das Verzeichnis, von dem die K8s-Zertifikate kopiert werden. Standardmäßig wird dies auf das lokale $HOME des Benutzers erweitert (den Benutzer, der "ansible-playbook ..." ausführt) plus "/k8s/certs". Das bedeutet, wenn das $HOME-Verzeichnis des Benutzers z.B. "/home/da_user" ist, dann hat "k8s_ca_conf_directory" den Wert "/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"
# "ExecStartPre"-Direktive in der Flannel-Systemd-Dienstdatei. Dieser Befehl wird ausgeführt, bevor der Flannel-Dienst gestartet wird.
flannel_systemd_execstartpre: "/bin/mkdir -p {{flannel_subnet_file_dir}}"
# "ExecStartPost"-Direktive in der Flannel-Systemd-Dienstdatei. Dieser Befehl wird ausgeführt, nachdem der Flannel-Dienst gestartet wurde. Wenn du in der Hetzner-Cloud arbeitest, kann dies wichtig sein. In diesem Fall wird der TX-Checksum-Offload-Parameter für die "flannel.1"-Schnittstelle geändert. Es scheint einen (Kernel/Treiber) Checksum-Offload-Bug mit der Flannel-VXLAN-Kapselung (alles innerhalb von UDP) im WireGuard-Tunnel zu geben.
# 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 = deaktivieren

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
        }
      }
    ]
  }

Die Einstellungen für den Flannel-Daemon, die in flannel_settings definiert sind, können durch Definieren einer Variablen namens flannel_settings_user überschrieben werden. Du kannst auch zusätzliche Einstellungen hinzufügen, indem du diese Variable verwendest. Zum Beispiel, um den Standardwert von healthz-ip zu überschreiben und die Einstellung kubeconfig-file hinzuzufügen, füge die folgenden Einstellungen zu group_vars/all.yml oder an einen Ort hinzu, der dir am besten passt:

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

Ein Wort zu flannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off" , das standardmäßig auskommentiert ist. Wenn die Pod-zu-Pod-Kommunikation für dich funktioniert (über Hosts hinweg), aber Pod-zu-Service oder Node-zu-Service nicht funktioniert (ebenfalls über Hosts), dann könnte das Setzen dieser Variablen und des Inhalts hilfreich sein. Zumindest hat es geholfen, Flannel-Datenverkehr über WireGuard-VPN in der Hetzner-Cloud auszuführen. Es scheint, dass das TX-Offloading in diesem Fall nicht funktioniert und dies führt zu Checksum-Fehlern. Du kannst dieses Problem folgendermaßen identifizieren. Melde dich über SSH bei zwei Worker-Knoten an. Identifiziere einen Dienst, der z.B. auf worker01 läuft und versuche, ihn auf worker02 zu erreichen. Zum Beispiel ist das kube-dns oder coredns-Pod ein guter Kandidat, da es im Grunde in jedem Kubernetes-Cluster läuft. Trotz der Tatsache, dass DNS-Abfragen normalerweise über das UDP-Protokoll gesendet werden, funktioniert DNS auch mit TCP. Angenommen, kube-dns läuft auf worker01 und du versuchst auf worker02, den DNS-Dienst zu erreichen über

telnet 10.32.0.254 53
Trying 10.32.0.254...

Aber wie du sehen kannst, passiert nichts. Lass uns also tcpdump auf worker01 ausführen, z.B. tcpdump -nnvvvS -i any src host <ip_of_worker02>. Jetzt erfassen wir den gesamten Verkehr von worker02 auf worker01. Führe erneut telnet 10.32.0.254 53 auf worker02 aus und du könntest etwas Ähnliches sehen:

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: [udp sum 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
...

Wenn du dir die letzte Zeile genauer ansiehst, siehst du in diesem Beispiel cksum 0x74e3 (incorrect -> 0x890f) und das ist das Problem. Das SYN-Paket wird verworfen, weil die Checksumme falsch ist. Wenn du jetzt das Checksum-Offloading für die flannel.1-Schnittstelle auf allen Hosts deaktivierst (zumindest in der Hetzner-Cloud), funktioniert es:

telnet 10.32.0.254 53
Trying 10.32.0.254...
Connected to 10.32.0.254.
Escape character is '^]'.
...

Und wenn wir uns jetzt wieder die tcpdump-Ausgabe ansehen

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: [udp sum 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
...

wirst du sehen, dass die Checksumme nun korrekt ist. Du kannst den Zustand des Protokoll-Offload und andere Eigenschaften der Flannel-Schnittstelle mit ethtool -k flannel.1 überprüfen.

Abhängigkeiten

• etcd (siehe ansible-role-etcd)
• CNI-Plugins (siehe ansible-role-cni oder irgendeine andere Rolle, die CNI-Plugins installiert)

Beispiel-Playbook

- hosts: flannel
  roles:
    - githubixx.flanneld

Lizenz

GNU GENERAL PUBLIC LICENSE Version 3

Autorinformationen

http://www.tauceti.blog