This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

Implementar Multus con Whereabouts en clústeres de carga de trabajo

Whereabouts es un complemento CNI de administración de direcciones IP (IP Address Management, IPAM) que asigna dinámicamente direcciones IP a los pods en todos los nodos de un clúster. En comparación con otros complementos de IPAM, como host-local, que solo asigna direcciones IP a pods en el mismo nodo, whereabouts asigna direcciones IP en todo el clúster.

En este tema, mostraremos cómo se puede asociar una interfaz de red secundaria a un pod con la dirección IP asignada en el rango especificado mediante whereabouts. Por ejemplo, tendrá Antrea o Calico como la CNI principal, una interfaz secundaria creada con macvlan o ipvlan y Whereabouts como la CNI de IPAM.

Requisitos previos

Instalar el paquete Whereabouts

Para instalar el paquete Whereabouts en un clúster de carga de trabajo y configurar el clúster para utilizarlo:

  1. Configure e instale Whereabouts.

    1. Cree un archivo de configuración que recupere los parámetros de Whereabouts.

      tanzu package available get whereabouts.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH
      
      
      Nota

      El espacio de nombres en el que se van a implementar los componentes whereabouts debe ser kube-system. Se producirá un error en la instalación de cualquier espacio de nombres personalizado.

      Donde PACKAGE-VERSION es la versión del paquete de Whereabouts que desea instalar y FILE-PATH es la ubicación en la que desea guardar el archivo de configuración, por ejemplo, whereabouts-data-values.yaml. El comando anterior creará un archivo de configuración denominado whereabouts-data-values.yaml que contiene los valores predeterminados.

    2. Ejecute el comando tanzu package available list para enumerar las versiones disponibles del paquete Whereabouts, por ejemplo:

      tanzu package available list whereabouts.tanzu.vmware.com -A
       NAME                           VERSION               RELEASED-AT                     NAMESPACE
       whereabouts.tanzu.vmware.com   0.6.1+vmware.2-tkg.1  2023-30-04 18:00:00 +0000 UTC   tanzu-package-repo-global
      
      
      Nota

      Asegúrese de que se pueda acceder al registro de imágenes personalizado si está operando en un entorno restringido por la red.

    3. Ejecute el comando tanzu package available get con --values-schema para ver qué valores de campo se pueden establecer:

      tanzu package available get whereabouts.tanzu.vmware.com/VERSION --values-schema -o FORMAT
      

      Donde: - VERSION es una versión que aparece en los resultados de tanzu package available list: FORMAT es yaml o json

    4. Rellene el archivo de configuración whereabouts-data-values.yaml con los valores de campo que desee.

  2. Elimine todos los comentarios del archivo whereabouts-data-values.yaml:

    yq -i eval '... comments=""' whereabouts-cni-default-values.yaml
    
  3. Ejecute tanzu package install para instalar el paquete.

    tanzu package install whereabouts --package whereabouts.tanzu.vmware.com --version AVAILABLE-PACKAGE-VERSION --values-file whereabouts-data-values.yaml --namespace TARGET-NAMESPACE
    

    Donde:

    • TARGET-NAMESPACE es el espacio de nombres en el que se desea instalar el paquete Whereabouts. Por ejemplo, el espacio de nombres my-packages o tanzu-cli-managed-packages.

      • Si no se especifica la marca --namespace, la CLI de Tanzu instala el paquete en el espacio de nombres default.
      • El espacio de nombres especificado ya debe existir, por ejemplo, al haber ejecutado kubectl create namespace my-packages.
    • AVAILABLE-PACKAGE-VERSION es la versión que recuperó anteriormente (por ejemplo, 0.6.1+vmware.2-tkg.1).
  4. Ejecute tanzu package installed get para comprobar el estado del paquete instalado.

    tanzu package installed get whereabouts -o <json|yaml|table>
    
  5. Cree una definición de recursos personalizada (Custom Resource Definition, CRD) para NetworkAttachmentDefinition que defina la configuración de CNI para las interfaces de red que utilizará Multus CNI con Whereabouts como el tipo de IPAM.

    1. Cree una especificación de CRD. Por ejemplo, este multus-cni-crd.yaml especifica una NetworkAttachmentDefinition con el nombre macvlan-conf que configura una CNI macvlan y tiene whereabouts como el tipo de IPAM:

      ---
      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: macvlan-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "plugins": [
            {
            "type": "macvlan",
            "capabilities": { "ips": true },
            "master": "eth0",
            "mode": "bridge",
            "ipam": {
              "type": "whereabouts",
              "range": "192.168.20.0/24",
              "range_start": "192.168.20.10",
              "range_end": "192.168.20.100",
              "gateway": "192.168.20.1"
              }
            } ]
          }'
      
    2. Cree el recurso; por ejemplo, kubectl create -f multus-cni-crd.yaml

  6. Cree un pod con la anotación k8s.v1.cni.cncf.io/networks para especificar la red adicional que desea agregar.

    1. Cree la especificación del pod; por ejemplo, my-multi-cni-pod.yaml:

      apiVersion: v1
      kind: Pod
      metadata:
        name: pod0
        annotations:
          k8s.v1.cni.cncf.io/networks: macvlan-conf
      spec:
        containers:
        - name: pod0
          command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"]
          image: docker.io/kserving/tools:latest
      
      
    2. Cree el pod. Por ejemplo, kubectl create -f my-multi-cni-crd.yaml crea el pod pod0.

    3. Una vez creado el pod, tendrá tres interfaces de red:

      • lo la interfaz de bucle invertido
      • eth0 la red de pods predeterminada administrada por Antrea o Calico CNI
      • net1 la nueva interfaz creada a través de k8s.v1.cni.cncf.io/networks: macvlan-conf.
      Nota

      La red predeterminada obtiene el nombre eth0 y las interfaces de pod de red adicionales obtienen el nombre net1, net2, etc.

    4. Ejecute kubectl describe pod en pod0 y confirme que el k8s.v1.cni.cncf.io/network-status de anotación enumera todas las interfaces de red.

      Por ejemplo:

      $ kubectl describe pod pod0
      
      Name:         pod0
      Namespace:    default
      Priority:     0
      Node:         tcecluster-md-0-6476897f75-rl9vt/10.170.109.225
      Start Time:   Thu, 25 August 2022 15:31:20 +0000
      Labels:       <none>
      Annotations:  k8s.v1.cni.cncf.io/network-status:
                     [{
                         "name": "",
                         "interface": "eth0",
                         "ips": [
                             "100.96.1.80"
                         ],
                         "mac": "66:39:dc:63:50:a3",
                         "default": true,
                         "dns": {}
                     },{
                         "name": "default/macvlan-conf",
                         "interface": "net1",
                         "ips": [
                             "192.168.20.11"
                         ],
                         "mac": "02:77:cb:a0:60:e3",
                         "dns": {}
                     }]
                   k8s.v1.cni.cncf.io/networks: macvlan-conf
      
      

      A continuación, ejecute kubectl exec sample-pod -- ip a show dev net1 para comprobar si la interfaz de destino está activa y en ejecución con la DIRECCIÓN IP indicada en las anotaciones anteriores. Repita este paso para validar la configuración de otros pods que creará en el siguiente paso.

  7. Cree dos pods adicionales, pod1 en el mismo nodo y pod2 en un nodo diferente. Utilizaremos estos pods para verificar el acceso a la red dentro de un solo nodo y nodos en el clúster.

Validar el tráfico de red entre pods en todo el clúster

Ahora puede comprobar el acceso a la red entre los pods del mismo nodo y los pods del clúster.

  1. Compruebe que el acceso a la red entre los pods del mismo nodo funciona. Por ejemplo, el siguiente comando verifica que pod0 pueda acceder a pod1 a través de su dirección IP asignada.

      kubectl exec -it pod0 -- ping -c 3 192.168.20.12
      PING 192.168.20.12 (192.168.20.12) 56(84) bytes of data.
      64 bytes from 192.168.20.12: icmp_seq=1 ttl=64 time=0.237 ms
      64 bytes from 192.168.20.12: icmp_seq=2 ttl=64 time=0.215 ms
      64 bytes from 192.168.20.12: icmp_seq=3 ttl=64 time=0.156 ms
    
    --- 192.168.20.12 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2030ms
    rtt min/avg/max/mdev = 0.156/0.202/0.237/0.037 ms
    
  2. Compruebe que el acceso a la red entre los pods de un nodo diferente funcione. Por ejemplo, el siguiente comando verifica que pod0 pueda acceder a pod2 a través de su dirección IP asignada.

      kubectl exec -it pod0 -- ping -c 3 <192.168.20.13
      PING 192.168.20.13 (192.168.20.13) 56(84) bytes of data.
      64 bytes from 192.168.20.13: icmp_seq=1 ttl=64 time=0.799 ms
      64 bytes from 192.168.20.13: icmp_seq=2 ttl=64 time=0.626 ms
      64 bytes from 192.168.20.13: icmp_seq=3 ttl=64 time=0.655 ms
    
    --- 192.168.20.13 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2030ms
    rtt min/avg/max/mdev = 0.626/0.693/0.799/0.078 ms
    
check-circle-line exclamation-circle-line close-line
Scroll to top icon