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:

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.
Establecer una sesión como el usuario student a lab-#-master
```
export LAB=X
```
```
ssh student@lab-${LAB}-master 
```
Cambiar al usuario root
```
sudo -i
```
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
```

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

Crearemos el directorio de configuración de rke2.
```
mkdir -p /etc/rancher/rke2
```

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

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
```
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
```
Una vez validado el archivo, podemos iniciar y habilitar el servicio. Este proceso puede demorar unos minutos.
```
systemctl enable rke2-server.service --now
```
Validar es estado del servicio. Debe estar en ejecución active (running)
```
systemctl status rke2-server.service
```

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.

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

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

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

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/

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

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 
```
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
```
Asegurese de guardar el nombre del servidor Master, ya que será utilizado posteriormente, puede verificarlo con el siguiente comando:
```
lab-0-master:~ # hostname -f
```
Cierre la sesión en el servidor Master del usuario root con el comando exit:
```
lab-0-master:~ # exit
```
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

Establecer una sesión como el usuario student a lab-#-node1
```
export LAB=X
```
```
ssh student@lab-${LAB}-node1 
```
Cambiar al usuario root
```
sudo -i
```
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
```

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

Crearemos el directorio de configuración de rke2.
```
mkdir -p /etc/rancher/rke2
```
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
```
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
```
Una vez validado el archivo, podemos iniciar y habilitar el servicio. Este proceso puede demorar unos minutos.
```
systemctl enable rke2-agent.service --now
```
Validar es estado del servicio. Debe estar en ejecución active (running)
```
systemctl status rke2-agent.service
```
Cierre la sesión en el servidor Node1 del usuario root con el comando exit:
```
lab-0-node1:~ # exit
```
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

Establecer una sesión como el usuario student a lab-#-master
```
export LAB=X
```
```
ssh student@lab-${LAB}-master 
```
Cambiar al usuario root
```
sudo -i
```
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
```
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
```
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)

Crearemos un namespace para validar el funcionamiento del plugin.
```
kubectl create ns test-net
```

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

Consultaremos el estado del deployment.

kubectl rollout status -n test-net deployment/test01

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

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.

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: []

Aplique el cambio al cluster:

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

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.

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

Aplique el cambio al cluster:
```
kubectl apply -f np-allow-dns.yaml
```

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

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

Aplique el cambio al cluster:
```
kubectl apply -f np-allow-https.yaml
```

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

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

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.

Opciones de Red Disponibles en RKE2

Introducción

Objetivo

Desarrollo del Tema

Laboratorio para el Estudiante

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

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

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

Prueba de funcionamiento plugin (Network Policies)

Recursos Adicionales

Conclusión

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

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