ansible-role-flanneld

Este libro de jugadas de Ansible se utiliza en Kubernetes la manera no tan complicada con Ansible - Trabajador. Instala y configura el binario flanneld. Flannel es responsable de proporcionar una red IPv4 de capa 3 entre múltiples nodos en un clúster. Flannel no controla cómo se conectan los contenedores al anfitrión, solo cómo se transporta el tráfico entre diferentes anfitriones. Sin embargo, Flannel proporciona un complemento CNI para Kubernetes y una guía sobre su integración con Docker.

Versiones

Etiqueto cada lanzamiento e intento seguir con versionado semántico. Si deseas usar el rol, te recomiendo que verifiques la última etiqueta. La rama principal es básicamente desarrollo, mientras que las etiquetas marcan lanzamientos estables. Pero en general, también intento mantener la rama principal en buen estado. Una etiqueta 8.0.0+0.16.1 significa que esta es la versión 8.0.0 de este rol y está destinada a ser utilizada con la versión de Flannel 0.16.1 (pero tal vez también funcione con versiones más nuevas). Si el rol cambia, X.Y.Z antes de + aumentará. Si cambia la versión de Flannel, X.Y.Z después de + aumentará. Esto permite marcar correcciones de errores y nuevas versiones importantes del rol mientras todavía se desarrolla para un lanzamiento específico de Flannel.

Requisitos

• Un clúster etcd debe estar funcionando (ver ansible-role-etcd). El rol se conectará al primer nodo que encuentre en el grupo de Ansible k8s_etcd y ejecutará etcdctl allí para agregar una nueva entrada en etcd. Esa entrada contiene la configuración de red de Flannel y se localiza en "flannel_etcd_prefix/config".
• Complementos CNI (ver ansible-role-cni)

Registro de cambios

ver CHANGELOG.md

Variables del rol

# La interfaz en la que los servicios de K8s deben escuchar. Como toda 
# la comunicación del clúster debería usar la interfaz VPN, el nombre 
# de la interfaz es normalmente "wg0", "tap0" o "peervpn0".
k8s_interface: "tap0"
# Directorio donde se almacenan los certificados y otras configuraciones 
# de K8s en los anfitriones de Kubernetes.
k8s_conf_dir: "/var/lib/kubernetes"
# Directorio del complemento de red CNI
k8s_cni_conf_dir: "/etc/cni/net.d"
# El directorio desde donde copiar los certificados de K8s. Por defecto, 
# esto se expandirá al $HOME LOCAL del usuario (el usuario que ejecuta 
# "ansible-playbook ..." más "/k8s/certs"). Esto significa que si el 
# directorio $HOME del usuario es, por ejemplo, "/home/da_user", entonces 
# "k8s_ca_conf_directory" tendrá un valor 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"
# Directiva "ExecStartPre" en el archivo de servicio systemd de flannel. 
# Este comando se ejecuta antes de que comience el servicio de flannel.
flannel_systemd_execstartpre: "/bin/mkdir -p {{flannel_subnet_file_dir}}"
# Directiva "ExecStartPost" en el archivo de servicio systemd de flannel. 
# Este comando se ejecuta después de que se inicie el servicio de flannel. 
# Si estás en la nube de Hetzner, esto puede ser importante. En este caso, 
# cambia el parámetro de sobrecarga de comprobación de TX para la interfaz 
# "flannel.1". Parece que hay un error de sobrecarga de comprobación 
# (controlador/kernel) con la encapsulación vxlan de flannel (todo 
# dentro de UDP) dentro de la encapsulación de 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 = deshabilitar

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

Los ajustes para el daemon de Flannel definidos en flannel_settings pueden ser sobreescritos definiendo una variable llamada flannel_settings_user. También puedes agregar configuraciones adicionales usando esta variable. Por ejemplo, para sobreescribir el valor predeterminado de healthz-ip y agregar la configuración kubeconfig-file, agrega las siguientes configuraciones a group_vars/all.yml o donde mejor te parezca:

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

Una nota sobre flannel_systemd_execstartpost: "/sbin/ethtool -K flannel.1 tx off" que está comentada por defecto. Si la comunicación de Pod a Pod funciona para ti (a través de los anfitriones) pero la comunicación de Pod a Servicio o de Nodo a Servicio no funciona (también a través de los anfitriones), entonces establecer esta variable y su contenido puede ayudar. Al menos funcionó al ejecutar tráfico de Flannel a través de la VPN de WireGuard en la nube de Hetzner. Parece que la sobrecarga de comprobación de TX no está funcionando en este caso y esto causa errores de comprobación. Puedes identificar este problema así: Inicia sesión en dos nodos trabajadores a través de SSH. Identifica un servicio que esté, por ejemplo, ejecutándose en worker01 y trata de acceder a él desde worker02. Por ejemplo, el pod kube-dns o coredns es un buen candidato ya que normalmente se ejecuta en cada clúster de Kubernetes. A pesar de que las consultas DNS normalmente se envían a través del protocolo UDP, DNS también funciona con TCP. Así que asume que kube-dns se está ejecutando en worker01 y en worker02 intentas conectarte al servicio DNS a través de

telnet 10.32.0.254 53
Trying 10.32.0.254...

Pero como puedes ver, no pasa nada. Así que corramos tcpdump en worker01, por ejemplo, tcpdump -nnvvvS -i any src host <ip_de_worker02>. Ahora capturamos todo el tráfico desde worker02 en worker01. Ejecuta telnet 10.32.0.254 53 nuevamente en worker02 y puedes ver algo como esto:

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
...

Si miras de cerca la última línea, verás en este ejemplo cksum 0x74e3 (incorrect -> 0x890f) y ese es el problema. El paquete SYN se descarta porque la comprobación es incorrecta. Ahora, si deshabilitas la comprobación de sobrecarga para la interfaz flannel.1 en todos los anfitriones (nuevamente, al menos en la nube de Hetzner), funcionará:

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

Y si ahora miramos la salida de tcpdump nuevamente

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
...

verás en la última línea que la comprobación es correcta. Puedes inspeccionar el estado de la sobrecarga de protocolo y otras características de la interfaz de Flannel con ethtool -k flannel.1.

Dependencias

• etcd (ver ansible-role-etcd)
• Complementos CNI (ver ansible-role-cni o cualquier otro rol que instale Complementos CNI)

Ejemplo de libro de jugadas

- hosts: flannel
  roles:
    - githubixx.flanneld

Licencia

LICENCIA PÚBLICA GENERAL GNU Versión 3

Información del autor

http://www.tauceti.blog