Redes de nodo

En este tema se describe cómo personalizar las redes de nodos para clústeres de carga de trabajo, incluida la personalización de direcciones IP de los nodos y la configuración de reservas de DHCP, IPAM de nodo e IPv6 en vSphere.

Configurar las reservas de DHCP del nodo y el registro de DNS de endpoint (solo vSphere)

Para los clústeres nuevos en vSphere debe crear reservas de DHCP para sus nodos y es posible que también deba crear un registro de DNS para su endpoint de plano de control:

Reservas de DHCP para los nodos del clúster:

Como precaución de seguridad en entornos en los que varios nodos del plano de control pueden apagarse o desconectarse durante períodos prolongados, ajuste las reservas de DHCP para las direcciones IP del plano de control y los nodos de trabajo de un clúster recién creado, de modo que las direcciones permanezcan estáticas y las concesiones nunca caduquen.

Para obtener instrucciones sobre cómo configurar reservas de DHCP, consulte la documentación del servidor DHCP.
Registro de DNS para el endpoint del plano de control:

Si utiliza NSX Advanced Load Balancer, no Kube-Vip, para el endpoint del plano de control y establece VSPHERE_CONTROL_PLANE_ENDPOINT en un FQDN en lugar de una dirección IP numérica, reserve las direcciones de la siguiente manera:
1. Recupere la dirección IP del plano de control que NSX ALB asignada al clúster:
```
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
```
2. Registre la dirección IP que aparece como "host" en el resultado (por ejemplo, 192.168.104.107.
3. Cree un registro de DNS A que asocie su FQDN a la dirección IP que registró.
4. Para probar el FQDN, cree un nuevo kubeconfig que utilice el FQDN en lugar de la dirección IP de NSX ALB:
  1. Generar el kubeconfig:
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
```
  2. Edite el archivo kubeconfig KUBECONFIG-TEST para reemplazar la dirección IP por el FQDN. Por ejemplo, reemplace esto:
```
server: https://192.168.104.107:443
```
    por esto:
```
server: https://CONTROLPLANE-FQDN:443
```
  3. Recupere los pods del clúster mediante el kubeconfig modificado:
```
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
```
    Si el resultado muestra los pods, DNS funciona para el FQDN.

Personalizar direcciones IP de nodo de clúster (MC independiente)

Puede configurar bloques de direcciones IP específicos del clúster para los nodos de los clústeres de administración independientes y los clústeres de carga de trabajo que implementan. La forma de hacer esto depende de la infraestructura de nube en la que se ejecuta el clúster:

vSphere

En vSphere, el VSPHERE_NETWORK del archivo de configuración del clúster establece la red de máquina virtual que Tanzu Kubernetes Grid utiliza para los nodos del clúster y otros objetos de Kubernetes. Las direcciones IP se asignan a los nodos mediante un servidor DHCP que se ejecuta en esta red de máquinas virtuales, implementadas de forma independiente desde Tanzu Kubernetes Grid.

Si utiliza redes NSX, puede configurar enlaces de DHCP para los nodos del clúster siguiendo Configurar enlaces estáticos de DHCP en un segmento en la documentación de VMware NSX-T Data Center.

Nota
Para v4.0+, se cambia el nombre de VMware NSX-T Data Center a "VMware NSX".

AWS

Para configurar bloques de direcciones IP específicos del clúster en Amazon Web Services (AWS), establezca las siguientes variables en el archivo de configuración del clúster como se describe en la tabla AWS de la Referencia de variable del archivo de configuración.

Establezca AWS_PUBLIC_NODE_CIDR para establecer un rango de direcciones IP para los nodos públicos.
- Configure AWS_PRIVATE_NODE_CIDR_1 o AWS_PRIVATE_NODE_CIDR_2 para que haya rangos adicionales disponibles.
Establezca AWS_PRIVATE_NODE_CIDR para establecer un rango de direcciones IP para los nodos privados.
- Configure AWS_PRIVATE_NODE_CIDR_1 y AWS_PRIVATE_NODE_CIDR_2 para que haya rangos adicionales disponibles.
Todos los rangos de CIDR de nodo deben estar dentro del rango de VPC del clúster, que de forma predeterminada es 10.0.0.0/16.

Microsoft Azure

Para configurar bloques de direcciones IP específicos del clúster en Azure, establezca las siguientes variables en el archivo de configuración del clúster como se describe en la tabla Microsoft Azure de la Referencia de variable del archivo de configuración.

Establezca AZURE_NODE_SUBNET_CIDR para crear una nueva VNet con un bloque CIDR para las direcciones IP del nodo de trabajador.
Establezca AZURE_CONTROL_PLANE_SUBNET_CIDR para crear una nueva VNet con un bloque CIDR para las direcciones IP del nodo del plano de control.
Establezca AZURE_NODE_SUBNET_NAME para asignar direcciones IP del nodo de trabajador desde el rango de una VNet existente.
Establezca AZURE_CONTROL_PLANE_SUBNET_NAME para asignar direcciones IP del nodo de plano de control del rango de una VNet existente.

Node IPAM (vSphere)

Con la Node IPAM, un proveedor de IPAM en clúster asigna y administra las direcciones IP de los nodos del clúster durante la creación y el escalado del clúster, lo que elimina la necesidad de configurar DHCP externo.

Puede configurar Node IPAM para clústeres de administración independientes en vSphere y los clústeres de carga de trabajo basados en clases que administran. El siguiente procedimiento configura Node IPAM para los clústeres de carga de trabajo basados en clases; Para configurar Node IPAM para un clúster de administración, consulte Configurar Node IPAM en Configuración del clúster de administración para obtener vSphere.

Nota
Este procedimiento no se aplica a TKG con un supervisor de vSphere with Tanzu o con un clúster de administración independiente en AWS o Azure.

Al configurar IPAM del nodo para un clúster de carga de trabajo nuevo o existente, el usuario especifica un grupo de direcciones IP internas desde el que el proveedor de IPAM asigna direcciones IP estáticas y una dirección de puerta de enlace.

Cuando se asignan direcciones a nodos del clúster, Node IPAM siempre selecciona la dirección más baja disponible del grupo.

Requisitos previos

Un clúster de administración independiente de TKG
Servidores de nombres para los nodos de trabajo y el plano de control del clúster de carga de trabajo
- Esto es necesario porque los nodos del clúster ya no recibirán servidores de nombres a través de DHCP para resolver nombres en vCenter.
kubectl y la CLI de Tanzu instaladas de forma local

Limitaciones

Node IPAM tiene las siguientes limitaciones en TKG v2.3:

Solo para clústeres nuevos de carga de trabajo basados en clases implementados por un clúster de administración en vSphere.
- No se pueden convertir clústeres basados en DHCP existentes en Node IPAM.
No se admite el nodo de Windows.
Solo para entornos IPv4 o IPv6, no de pila dual.
Solo asigna direcciones de nodo, no el endpoint del plano de control del clúster.
Node IPAM no comprueba si su grupo de direcciones IP entra en conflicto con los grupos de DHCP que ya están utilizando otros clústeres.

Configurar Node IPAM para un clúster de carga de trabajo

Un grupo de Node IPAM de un clúster de carga de trabajo se puede definir mediante dos tipos de objetos diferentes, en función de cómo se compartan sus direcciones con otros clústeres:

InClusterIPPool configura grupos de direcciones IP que solo están disponibles para los clústeres de carga de trabajo en el mismo espacio de nombres del clúster de administración, como default.
- Este era el único tipo disponible en TKG v2.1 y v2.2.
GlobalInClusterIPPool configura grupos de direcciones IP con direcciones que se pueden asignar a clústeres de carga de trabajo en varios espacios de nombres.

Para configurar un clúster nuevo o existente con Node IPAM:

Cree un archivo de definición de objeto de grupo de IP my-ip-pool.yaml que establezca un rango de direcciones IP de una subred que TKG pueda utilizar para asignar direcciones IP estáticas para el clúster de carga de trabajo. Defina el objeto como un InClusterIPPool o un GlobalInClusterIPPool en función de cómo desea aplicar el ámbito al grupo de direcciones IP, por ejemplo:
- InClusterIPPool: para crear un grupo de direcciones IP inclusterippool para clústeres de carga de trabajo en el espacio de nombres default que contiene el rango 10.10.10.2-10.10.10.100 más 10.10.10.102 y 10.10.10.104:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool
  namespace: default
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
  Nota
  Las versiones anteriores de TKG utilizaban la versión valpha1 del objeto InClusterIPPool, que solo admitía un rango de grupo de direcciones IP contiguas especificado por start y end como se describe en la documentación de TKG v2.1. La actualización de los clústeres a v2.3 convierte sus grupos de direcciones IP a una nueva estructura.
- GlobalInClusterIPPool: para crear un grupo de direcciones IP inclusterippool compartir entre espacios de nombres que contengan las mismas direcciones que el InClusterIPPool anterior:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: GlobalInClusterIPPool
metadata:
  name: inclusterippool
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
Cree el objeto de grupo de direcciones IP:
```
kubectl apply -f my-ip-pool.yaml
```

Configure el clúster de carga de trabajo para que utilice el grupo de direcciones IP dentro de un archivo de configuración del clúster plano o una especificación de objeto de estilo Kubernetes, como se describe en Archivos de configuración.

Por ejemplo:

Archivo de configuración plano (Flat configuration file) (para crear clústeres nuevos):

# The name of the InClusterIPPool object specified above
NODE_IPAM_IP_POOL_NAME: inclusterippool
CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11

Especificación de objeto (Object spec) (para crear clústeres nuevos o modificar los existentes):

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
topology:
  variables:
  - name: network
    value:
      addressesFromPools:
      - apiGroup: ipam.cluster.x-k8s.io
        kind: InClusterIPPool
        name: inclusterippool
  - name: controlplane
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]

Ahora puede implementar el clúster de carga de trabajo.

Reglas de grupos

Los rangos de grupos de direcciones IP no deben superponerse
- Los grupos que se superponen pueden provocar errores y TKG no valida los rangos de grupos ni detecta superposiciones.
No elimine una dirección IP asignada actualmente de un grupo de direcciones IP.

Solucionar problemas de la IPAM del nodo

Para ver si los nodos del clúster tienen direcciones IP asignadas, ejecute kubectl get para enumerar los objetos de máquina específicos de IaaS, vspherevms, y comprobar su estado IPAddressClaimed. True significa que la notificación de dirección del nodo es correcta y, si el estado es False, los resultados del comando informan de una Reason por la cual la condición no está lista:
```
kubectl -n CLUSTER-NAMESPACE get vspherevms
```
Para ver las notificaciones de dirección IP, enumere ipaddressclaims. Para cada máquina, la entrada addressesFromPools hace que se cree una IPAddressClaim:
```
kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
```
Para ver las direcciones IP, enumere ipaddress. El proveedor de la IPAM en el clúster debe detectar cada IPAddressClaim y crear el objeto IPAddress correspondiente:
```
kubectl -n CLUSTER-NAMESPACE get ipaddress
```
Cuando todas las notificaciones de una máquina virtual determinada coinciden con las direcciones IP, CAPV escribe las direcciones IP asignadas en los metadatos de cloud-init de la máquina virtual y crea la máquina virtual. Para ver los pasos de conciliación de direcciones IP, consulte los registros del proveedor de IPAM (CAIP) de la API del clúster y CAPV:
```
kubectl logs -n capv-system capv-controller-manager
kubectl logs -n caip-in-cluster-system capi-in-cluster-controller-manager
```

Redes IPv6 (vSphere)

Puede ejecutar clústeres de carga de trabajo y administración en un entorno de redes de una sola pila solo IPv6 en vSphere con Kube-Vip mediante nodos basados en Ubuntu.

Notas No se pueden crear clústeres IPv6 con un clúster supervisor en vSphere with Tanzu. No se pueden registrar clústeres IPv6 con Tanzu Mission Control. Actualmente no se admiten los servicios de NSX Advanced Load Balancer ni las redes IPv4/IPv6 de doble pila.

Requisitos previos:

Configure vSphere para las direcciones IPv6 a las que el clúster de arranque puede acceder.
Configure la resolución DNS en el daemon de Docker con una dirección IPv6 a la que pueda acceder el clúster de arranque.
Si los clústeres IPv6 necesitan acceder a una red IPv4, como suele ser habitual, configure un proxy HTTP como se describe en Configuración de proxy.

Implementar un clúster de administración de IPv6

Haga lo siguiente en su máquina de arranque para implementar un clúster de administración en un entorno de redes IPv6:

Configure Linux para que acepte anuncios de enrutador para garantizar que la ruta IPv6 predeterminada no se elimine de la tabla de enrutamiento cuando se inicie el servicio de Docker. Para obtener más información, consulte Docker CE elimina la ruta predeterminada de IPv6. sudo sysctl net.ipv6.conf.eth0.accept_ra=2
Cree una regla de enmascaramiento para que el clúster de arranque envíe tráfico saliente desde el clúster de arranque: sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE Para obtener más información sobre las reglas de enmascaramiento, consulte MASQUERADE.
Establezca las siguientes variables en el archivo de configuración para el clúster de administración.
- Establezca TKG_IP_FAMILY en ipv6.
- Establezca VSPHERE_CONTROL_PLANE_ENDPOINT en una dirección IPv6 estática.
- (Opcional) Establezca el CLUSTER_CIDR and SERVICE_CIDR. El valor predeterminado es fd00:100:64::/48 y fd00:100:96::/108, respectivamente.
Implemente el clúster de administración ejecutando tanzu mc create, como se describe en Implementar clústeres de administración desde un archivo de configuración.
- Para admitir IPv6, debe implementar el clúster de administración desde un archivo de configuración, no desde la interfaz del instalador.

Implementar un clúster de carga de trabajo IPv6

Si implementó un clúster de administración de IPv6, implemente un clúster de carga de trabajo IPv6 de la siguiente manera:

Establezca los siguientes variables en el archivo de configuración para el clúster de carga de trabajo.
- Establezca TKG_IP_FAMILY en ipv6.
- Establezca VSPHERE_CONTROL_PLANE_ENDPOINT en una dirección IPv6 estática.
- (Opcional) Establezca el CLUSTER_CIDR and SERVICE_CIDR. El valor predeterminado es fd00:100:64::/48 y fd00:100:96::/108, respectivamente.
Implemente el clúster de carga de trabajo como se describe en Crear clústeres de carga de trabajo.

Clústeres de doble pila (vista previa técnica)

Nota
Esta función se encuentra en el estado de vista previa técnica no compatible; consulte Estados de funciones de TKG.

La función de doble pila permite implementar clústeres con familias de direcciones IP IPv4 e IPv6. Sin embargo, la familia de IP principal es IPv4. Antes de experimentar con esta función, configure el vCenter Server para que admita conectividad IPv4 e IPv6.

A continuación, se muestran las limitaciones de la función de doble pila de esta versión:

La función de doble pila admite vSphere como el único producto de infraestructura como servicio (IaaS).
No se puede configurar una doble pila en clústeres con nodos de Photon OS. Solo se admiten clústeres configurados con un OS_NAME de ubuntu.
No se pueden configurar redes de doble pila para clústeres supervisores de vSphere with Tanzu o los clústeres de carga de trabajo que estos crean.
No se puede implementar un clúster de administración de doble pila con la interfaz del instalador.
No se pueden utilizar los servicios de doble pila o IPv6 en los servicios de equilibrador de carga proporcionados por NSX Advanced Load Balancer (ALB). Puede utilizar kube-vip como proveedor de endpoints del plano de control para un clúster de doble pila. No se ha validado el uso de NSX ALB como proveedor de endpoint del plano de control para un clúster de doble pila.
Solo los componentes de complemento principales, como Antrea, Calico, CSI, CPI y Pinniped, se validaron para la compatibilidad con doble pila en esta versión.

Para configurar la doble pila en los clústeres:

Establezca la marca de función de doble pila:

a. Para habilitar la función en el clúster de administración, ejecute el siguiente comando:
```
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
```
b. Para habilitar la función en el clúster de carga de trabajo, ejecute el siguiente comando:
```
tanzu config set features.cluster.dual-stack-ipv4-primary true
```
Implementar clústeres de administración o Crear clústeres de carga de trabajo, según sea necesario.

En el archivo de configuración del clúster:
- Establezca la variable de configuración de la familia de IP TKG_IP_FAMILY: ipv4,ipv6.
- De forma opcional, establezca los CIDR de servicio y los CIDR de clúster.
Nota
Hay dos CIDR para cada variable. Las familias de IP de estos CIDR siguen el orden de TKG_IP_FAMILY configurado. El rango de CIDR más grande permitido para las direcciones IPv4 es /12 y el rango de SERVICE_CIDR de IPv6 más grande es /108. Si no establece los CIDR, se utilizan los valores predeterminados.
- Establezca el siguiente parámetro del archivo de configuración si utiliza Antrea como CNI para el clúster:
```
ANTREA_ENDPOINTSLICES: true
```
Ahora se puede acceder a los servicios, que tienen una ipFamilyPolicy en sus especificaciones PreferDualStack o RequireDualStack, a través de IPv4 o IPv6.

Nota
Las pruebas de extremo a extremo de la función de doble pila en Kubernetes ascendente pueden fallar, ya que un nodo de clúster solo anuncia su dirección IP principal (en este caso, la dirección IPv4) como su dirección IP.