Opciones de Red Disponibles en RKE2

---

Introducción

RKE2 requiere un plugin de CNI para conectar pods y servicios. El plugin de CNI Canal es el predeterminado, pero se admiten todos los plugins de CNI. Todos los plugins de CNI se instalan mediante un chart de Helm después de que los componentes principales estén en funcionamiento y pueden personalizarse modificando las opciones del chart de Helm.

---

Objetivo

Objetivo General:

• El objetivo es identificar las consideraciones y opciones de configuración para modificar el plugin utilizado en RKE2 y ayudar al estudiante a identificar el procedimiento.

---

Desarrollo del Tema

RKE2 se integra con cuatro plugins de CNI diferentes: Canal, Cilium, Calico y Flannel. Cabe señalar que solo Calico y Flannel son opciones para implementaciones de RKE2 con nodos Windows. A continuación una tabla con un resúmen de los plugins disponibles.

Característica	Canal	Cilium	Calico	Flannel
Tipo	Combinación de Calico y Flannel (híbrido)	Basado en eBPF	Red pura L3 y política de red	Red de superposición simple
Modelo de Red	Utiliza Flannel para red y Calico para políticas	Modelo basado en L3/L4 con acceso directo al nodo	L3 (Enrutamiento de Capa 3)	Red de superposición L2/L3
Políticas de Red	Soportado (a través de Calico)	Políticas avanzadas soportadas (basadas en eBPF)	Soporta políticas de Kubernetes y Calico	No tiene soporte incorporado
Rendimiento	Moderado	Alto rendimiento (aprovecha eBPF)	Alto rendimiento	Moderado
Integración con eBPF	No	Sí	Parcial (mejoras posibles)	No
Complejidad de Instalación	Moderado	Mayor complejidad	Moderado	Fácil
Casos de Uso	Necesidades básicas de red y políticas	Alto rendimiento y seguridad avanzada	Red flexible con seguridad	Red simple para necesidades básicas
Plataformas Soportadas	Kubernetes	Kubernetes	Kubernetes, OpenShift	Kubernetes
Escalabilidad	Buena	Excelente	Buena	Limitada
Soporte de Superposición y Enrutamiento	Superposición VXLAN (a través de Flannel)	Enrutamiento nativo, túneles opcionales	Enrutamiento L3 nativo	VXLAN, host-gw, etc.
Compatibilidad con CNI	Sí	Sí	Sí	Sí

Laboratorio para el Estudiante

Indicaciones:

En esta guia el estudiante realizará la instalación de un Cluster de RKE2, modificando la opción por defencto de plugin de Red , compatible con CNI. Se utilizará como ejemplo calico y se procederá a ver algunas de las diferencias en la implementación.

Instalación de Cluster RKE2 utilizando opciones personalizadas de RED (lab-#-master)

Pasos:

1. Desinstalar el cluster1 utilizando la guía: Desinstalación Rancher Kubernetes Engine 2 - RKE2. En todos los nodos del cluster1, si este ha sido previamente instalado.
2. Establecer una sesión como el usuario student a lab-#-master

   export LAB=X
   

   ssh student@lab-${LAB}-master 
   

3. Cambiar al usuario root

   sudo -i
   

4. Procederemos a descargar el script de instalación de RKE2. Es recomendado descargarlo por seguridad.

   curl -sfL https://get.rke2.io --output install.sh
   

   chmod +x install.sh
   

5. Para este laboratorio, utilizaremos la versión de RKE2: v1.29.9+rke2r1. Y ejecutaremos el instalador.

   export INSTALL_RKE2_VERSION=v1.29.9+rke2r1
   

   export INSTALL_RKE2_TYPE=server # Este es el valor por defecto
   

   ./install.sh
   

6. Crearemos el directorio de configuración de rke2.

   mkdir -p /etc/rancher/rke2
   

7. Definiremos el plugin de red a utilizar y los segmentos a utilizar.

   CNI=calico
   CLUSTER_CIDR=10.38.0.0/16 # por defecto 10.42.0.0/16
   SERVICE_CIDR=10.39.0.0/16 # por defecto 10.43.0.0/16
   

8. Crearemos la configuración inicial de rke2. Se mostrará en pantalla y se remplazará el contenido del archivo de configuración /etc/rancher/rke2/config.yaml. En este archivo se puede definir el token, esto se realizará en un laboratorio posterior. Esta configuración comtempla dedicar el nodo master, para cargas de trabajo de control plane el token definido por el usuario y el plugin de red calico.

   TOKEN=$(openssl rand -base64 32)
   

   echo "TOKEN=${TOKEN}"
   echo "CNI=${CNI}"
   

   Asegurese de guardar en un lugar seguro y conocido el contenido de la variable TOKEN, será utilizado en las guías siguientes.

   cat << EOF | tee /etc/rancher/rke2/config.yaml
   write-kubeconfig-mode: "0600" # Es importante proteger este archivo, ya que cotiene las credenciales del administrador del cluster
   node-name: "$(hostname -f)"
   token: "${TOKEN}"
   tls-san:
   - "$(hostname -f)"
   node-label:
   - "cluster=cluster1"
   node-taint:
   - "CriticalAddonsOnly=true:NoExecute"
   cni: ${CNI}
   cluster-cidr: ${CLUSTER_CIDR}
   service-cidr: ${SERVICE_CIDR}
   EOF
   

9. Es recomendable validar el formato del archivo de configuración, para esto instalaremos la herramiento yq. Y validaremos el archivo creado.

   zypper install -y yq
   

   yq /etc/rancher/rke2/config.yaml
   

   echo $? # La salida de este comando deberá ser 0
   

10. Una vez validado el archivo, podemos iniciar y habilitar el servicio. Este proceso puede demorar unos minutos.

    systemctl enable rke2-server.service --now
    

11. Validar es estado del servicio. Debe estar en ejecución active (running)

    systemctl status rke2-server.service
    

12. Validar el estado del cluster. Asegurse que el nombre del sistema muestra el FQDN del nodo. Y que la versión sea la requerida por esta laboratorio y que el estado del nodo sea Ready. Esto puedo demorar unos minutos.

    export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
    

    export PATH=$PATH:/var/lib/rancher/rke2/bin
    

    kubectl version
    

    kubectl get nodes
    

    kubectl get nodes -L cluster # Para validar que se haya aplicado la etiquda del node definida en la configuración de rke2.
    

13. Listar los pods en ejecución en este cluster. Si existe algún pod en estado de error, puede consultar sus bitcoras. Espere hasta que todos los pods, estén en estado Running o Completed.

    kubectl get pods -A
    

14. Existirán algunos pods en estado pending esto es normal, debido al plugin seleccionado. Y se ejecutarán una vez agrege el primero nodo al cluster.
15. Explore los charts utilizados por RKE2, para utilizar este plugin en el cluster. Note que el valor del estado para el type Failed es False.

    kubectl get helmcharts -A |grep calico
    kubectl get helmcharts -n kube-system rke2-calico-crd -o yaml | yq .status
    kubectl get helmcharts -n kube-system rke2-calico -o yaml | yq .status
    

16. Note que los valores en el archivo de configuración de RKE2, fueron pasados de forma automática al Chart de Helm de Calico para activar su configuración. Note los valores definidos para las redes de servicio y de cluster.

    kubectl get helmcharts -n kube-system rke2-calico -o yaml | yq .spec.set
    

17. Explore el contenido del chart utilizado de forma automática por RKE2.

    kubectl get helmcharts -n kube-system rke2-calico -o yaml | yq .spec.chartContent |base64 -d |zcat > /tmp/data.tar
    mkdir /tmp/extract
    tar -xvf /tmp/data.tar -C /tmp/extract/
    

18. Identifique el contenido del chart aplicado. Esto es con fines didacticos y no es necesario realizarlo en un ambiente de producción.

    zypper install -y tree
    tree /tmp/extract/
    

    Ejemplo Salida:

    /tmp/extract/
    └── rke2-calico
        ├── Chart.yaml
        ├── README.md
        ├── templates
        │   ├── _helpers.tpl
        │   ├── certs
        │   │   ├── certs-node.yaml
        │   │   └── certs-typha.yaml
        │   ├── crs
        │   │   ├── configmap-felixconfiguration-templates.yaml
        │   │   └── custom-resources.yaml
        │   ├── felixconfig.yaml
        │   ├── ipamconfig.yaml
        │   ├── tigera-operator
        │   │   ├── 00-namespace-tigera-operator.yaml
        │   │   ├── 00-uninstall.yaml
        │   │   ├── 01-imagepullsecret.yaml
        │   │   ├── 01-kubernetes-services-endpoint.yaml
        │   │   ├── 02-configmap-calico-resources.yaml
        │   │   ├── 02-podsecuritypolicy-tigera-operator.yaml
        │   │   ├── 02-role-tigera-operator.yaml
        │   │   ├── 02-rolebinding-tigera-operator.yaml
        │   │   ├── 02-serviceaccount-tigera-operator.yaml
        │   │   └── 02-tigera-operator.yaml
        │   └── validate-install-crd.yaml
        └── values.yaml
    

19. Explore la configuración de red a nivel del sistema operativo. Ejecute el siguiente comando para identificar las interfaces creadas por el cluster utilizando el plugin de calico, puede identificar que el nombre hace referencia al plugin.

    ip link 
    

20. Identifique que haya sido posible asignar la IP a algún pod y a servicios del namespace, calico-system. Con el siguiente comando.

    kubectl get pods,service -o wide -n calico-system
    

21. Asegurese de guardar el nombre del servidor Master, ya que será utilizado posteriormente, puede verificarlo con el siguiente comando:

    lab-0-master:~ # hostname -f
    

22. Cierre la sesión en el servidor Master del usuario root con el comando exit:

    lab-0-master:~ # exit
    

23. Cierre la sesión en el servidor Master del usuario student con el comando exit:

    student@lab-0-master:~> exit
    

---

Instalación de Servidor Worker 1 (lab-#-node1)

Asegurarse de estar en el servidor bastion con el usuario student

1. Establecer una sesión como el usuario student a lab-#-node1

   export LAB=X
   

   ssh student@lab-${LAB}-node1 
   

2. Cambiar al usuario root

   sudo -i
   

3. Procederemos a descargar el script de instalación de RKE2. Es recomendado descargarlo por seguridad.

   curl -sfL https://get.rke2.io --output install.sh
   

   chmod +x install.sh
   

4. Para este laboratorio, utilizaremos la versión de RKE2: v1.29.9+rke2r1. Y ejecutaremos el instalador.

   export INSTALL_RKE2_VERSION=v1.29.9+rke2r1
   

   export INSTALL_RKE2_TYPE=agent # Este es el valor por defecto
   

   ./install.sh
   

5. Crearemos el directorio de configuración de rke2.

   mkdir -p /etc/rancher/rke2
   

6. Crearemos la configuración inicial de rke2. Se mostrará en pantalla y se remplazará el contenido del archivo de configuración /etc/rancher/rke2/config.yaml. En este archivo se puede definir el token, esto se realizará en un laboratorio posterior. Esta configuración comtempla dedicar el nodo master, para cargas de trabajo de control plane. Y definiremos un token definido por el usuario.

   TOKEN='COLOCAR_VALOR_GENERADO_EN_LA_INSTALACION_DEL_MASTER'
   

   SERVER_NODE='COLOCAR_FQDN_DE_MASTER_DE_LA_SECCION_ANTERIOR'
   

   cat << EOF | tee /etc/rancher/rke2/config.yaml
   write-kubeconfig-mode: "0600"
   server: https://${SERVER_NODE}:9345
   resolv-conf: /etc/resolv.conf # Forzar utilizar DNS local
   node-name: "$(hostname -f)"
   token: "${TOKEN}" 
   node-label:
   - "cluster=cluster1"
   EOF
   

7. Es recomendable validar el formato del archivo de configuración, para esto instalaremos la herramiento yq. Y validaremos el archivo creado.

   zypper install -y yq
   

   yq /etc/rancher/rke2/config.yaml
   

   echo $? # La salida de este comando deberá ser 0
   

8. Una vez validado el archivo, podemos iniciar y habilitar el servicio. Este proceso puede demorar unos minutos.

   systemctl enable rke2-agent.service --now
   

9. Validar es estado del servicio. Debe estar en ejecución active (running)

   systemctl status rke2-agent.service
   

10. Cierre la sesión en el servidor Node1 del usuario root con el comando exit:

    lab-0-node1:~ # exit
    

11. Cierre la sesión en el servidor Node1 del usuario student con el comando exit:

    student@lab-0-node1:~> exit
    

Validación del estado de los componentes de Red en Servidor Worker

1. Establecer una sesión como el usuario student a lab-#-master

   export LAB=X
   

   ssh student@lab-${LAB}-master 
   

2. Cambiar al usuario root

   sudo -i
   

3. Defina el path de credenciales del cluster de Kubernetes y el PATH de los binarios del sistema de RKE2.
   

   export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
   

   export PATH=$PATH:/var/lib/rancher/rke2/bin
   

4. Consulte el estado de los nodos en el cluster. Y confirme que el nuevo nodo es parte del cluster y se encuestra en estado Ready.

   kubectl get nodes
   

5. Consulta el estado de los componentes del namespace calico-system. Debe existit un pod por cada nodo y con el nombre calico-node-* en estado Running y el resto de pods del pluginin de Calico.

   kubectl get pods -n calico-system -o wide
   

Prueba de funcionamiento plugin (Network Policies)

1. Crearemos un namespace para validar el funcionamiento del plugin.

   kubectl create ns test-net
   

2. Crearemos un deployment con la imagen de nginx:latest en el nuevo namespace.

   kubectl create deployment -n test-net test01 --image=docker.io/nginx:latest
   

3. Consultaremos el estado del deployment.

   kubectl rollout status -n test-net deployment/test01
   

4. Por defecto, nuestro cluster no cuenta con recursos de tipo network policies. Realizaremos la prueba de consumir un endpoint desde un pod del nuevo deployment.

   TEST_POD=$(kubectl get pods -n test-net --selector=app=test01 -o name)
   kubectl exec -it -n test-net ${TEST_POD} -- curl https://www.google.com -I --connect-timeout 4|head -n2
   

   El resultado de la prueba debería ser similar a:

   HTTP/1.1 200 OK
   Content-Type: text/html; charset=ISO-8859-1
   

5. Crearemos un recurso tipo network policy, en el cual evitaremos el acceso desde los pods creados por medio del deployment test01 en el namespace test-net a cualquier destino.
6. Cree el archivo np-block-all-egress-traffic.yaml, con el siguiente contenido:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: block-all-egress-traffic
     namespace: test-net
   spec:
     podSelector:
       matchLabels:
         app: test01
     policyTypes:
     - Egress
     egress: []    
   

7. Aplique el cambio al cluster:

   kubectl apply -f np-block-all-egress-traffic.yaml
   

8. Realizaremos la prueba de consumir un endpoint desde un pod del nuevo deployment.

   TEST_POD=$(kubectl get pods -n test-net --selector=app=test01 -o name)
   kubectl exec -it -n test-net ${TEST_POD} -- curl https://www.google.com -Iv --connect-timeout 4|head -n2
   

   Note el error debe ser similar a:

   * Resolving timed out after 4000 milliseconds
   * Closing connection 0
   curl: (28) Resolving timed out after 4000 milliseconds
   command terminated with exit code 28
   

   Esto indica que el pod, no puede acceder a ningun recurso por medio de tráfico saliente, incluyendo el DNS por lo que no puede resolver nombre.
9. Cree el archivo np-allow-dns.yaml, con el siguiente contenido:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-dns
     namespace: test-net
   spec:
     podSelector:
       matchLabels:
         app: test01
     policyTypes:
     - Egress
     egress:
       - to:
         ports:
           - protocol: UDP
             port: 53 # Allow DNS UDP
           - protocol: TCP
             port: 53 # Allow DNS TCP
   

10. Aplique el cambio al cluster:

    kubectl apply -f np-allow-dns.yaml
    

11. Realizaremos la prueba de consumir un endpoint desde un pod del nuevo deployment.

    TEST_POD=$(kubectl get pods -n test-net --selector=app=test01 -o name)
    kubectl exec -it -n test-net ${TEST_POD} -- curl https://www.google.com -Iv --connect-timeout 4
    

    Con el cambio anterior, es posibl observar que existe resolución de nombres para el FQDN, pero no repsonde en menos de 4 segundos, con un mensaje similar a:

    * Trying 172.217.203.104:443...
    * Trying [2607:f8b0:400c:c01::6a]:443...
    * Immediate connect fail for XXXX Network is unreachable
    curl: (28) Failed to connect to www.google.com port 443 after 4000 ms: Timeout was reached
    command terminated with exit code 28
    

12. Cree el archivo np-allow-https.yaml, con el siguiente contenido:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-https
      namespace: test-net
    spec:
      podSelector:
        matchLabels:
          app: test01
      policyTypes:
      - Egress
      egress:
        - to:
          ports:
            - protocol: TCP
              port: 443 # Allow DNS TCP
    

13. Aplique el cambio al cluster:

    kubectl apply -f np-allow-https.yaml
    

14. Realizaremos la prueba de consumir un endpoint desde un pod del nuevo deployment.

    TEST_POD=$(kubectl get pods -n test-net --selector=app=test01 -o name)
    kubectl exec -it -n test-net ${TEST_POD} -- curl https://www.google.com -I --connect-timeout 4|head -n2
    

    El resultado de la prueba debería ser similar a:

    HTTP/1.1 200 OK
    Content-Type: text/html; charset=ISO-8859-1
    

15. Hemos validado el funcionamiento de plugin de Red en RKE2.

IMPORTANTE: Siga el procedimiento de la guía "Desinstalación Rancher Kubernetes Engine 2 - RKE2" y ejecutarlo en ambos nodos del cluster. Si es indicado por su instructor.

Recursos Adicionales

• Networking Options
• Server Config
• Network Policies

---

Conclusión

En este módulo, hemos explorado el proceso de instalación y configuración de un clúster RKE2 utilizando opciones personalizadas de red, así como la instalación y validación de servidores Worker. A través del desarrollo teórico y práctico, los estudiantes han aprendido a manejar configuraciones de red específicas, validar el estado de los componentes de red, y probar el correcto funcionamiento de políticas de red (Network Policies) en un entorno de Kubernetes.

Para profundizar en los temas tratados, recomendamos explorar los recursos adicionales proporcionados, que servirán de apoyo para continuar mejorando sus habilidades y conocimientos en la administración y personalización de clústeres Kubernetes.