En este documento, se muestra cómo planificar tus direcciones IP para una instalación de GKE en VMware que incluye clústeres de usuario que usan kubeception.
¿Qué es kubeception?
El término kubeception se usa para transmitir la idea de que un clúster de Kubernetes se usa con el fin de crear y administrar otros clústeres de Kubernetes. En el contexto de GKE en VMware, kubeception se refiere al caso en el que el plano de control de un clúster de usuario se ejecuta en uno o más nodos de un clúster de administrador.
No recomendamos usar kubeception. En su lugar, te recomendamos que uses el plano de control V2. Con el plano de control V2, los nodos del plano de control del clúster de usuario se encuentran en el propio clúster.
Antes de comenzar
Lee la descripción general de GKE en VMware y la descripción general de la instalación.
Ejemplo de asignación de dirección IP
En esta sección, se muestra un ejemplo de cómo asignar direcciones IP estáticas en una instalación que incluye estos elementos:
Una estación de trabajo de administrador
Un clúster de administrador
Un clúster de usuario con alta disponibilidad (HA) que tiene cinco nodos trabajadores
Un clúster de usuario sin alta disponibilidad que tiene cuatro nodos trabajadores
Nodos del clúster de administrador
El clúster de administrador tiene siete nodos:
- Un nodo que ejecuta el plano de control del clúster de administrador
- Dos nodos que ejecutan complementos para el clúster de administrador
- Tres nodos que ejecutan el plano de control para el clúster de usuario con alta disponibilidad
- Un nodo que ejecuta el plano de control para el clúster de usuario sin alta disponibilidad
Balanceo de cargas
Para este ejemplo, supongamos que los clústeres usan el balanceador de cargas MetalLB. Este balanceador de cargas se ejecuta en los nodos del clúster, por lo que no se necesitan VM adicionales para el balanceo de cargas
Subredes
Para este ejemplo, supongamos que cada clúster se encuentra en su propia VLAN y que los clústeres se encuentran en estas subredes:
| VM | Subred | Puerta de enlace predeterminada |
|---|---|---|
| Estación de trabajo de administrador y clúster de administrador | 172.16.20.0/24 | 172.16.20.1 |
| Clúster de usuario 1 | 172.16.21.0/24 | 172.16.21.1 |
| Clúster de usuario 2 | 172.16.22.0/24 | 172.16.22.1 |
En el siguiente diagrama, se ilustran las tres VLAN y subredes. Ten en cuenta que las VIP no se muestran asociadas con ningún nodo en particular en un clúster. Esto se debe a que el balanceador de cargas de MetalLB puede elegir qué nodo anuncia la VIP para un Service individual. Por ejemplo, en el clúster de usuario 1, un nodo trabajador podría anunciar 172.16.21.31 y otro nodo trabajador podría anunciar 172.16.21.32.
Dirección IP de ejemplo: estación de trabajo de administrador
En este ejemplo, la estación de trabajo de administrador se encuentra en la misma subred que el clúster de administrador: 172.16.20.0/24. Una dirección cercana a las direcciones de nodo sería adecuada para la estación de trabajo de administrador. Por ejemplo, 172.16.20.20.
Direcciones IP de ejemplo: nodos del clúster de administrador
Para un clúster de administrador que tiene siete nodos, debes reservar ocho direcciones IP. La dirección adicional es obligatoria, ya que se necesita durante la actualización del clúster y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos en el clúster de administrador:
| Direcciones IP de nodos en el clúster de administrador |
|---|
| 172/16/20.2 a 172/16/20.9 |
Direcciones IP de ejemplo: VIP en la subred del clúster de administrador
En la siguiente tabla, se muestra un ejemplo de cómo puedes designar las VIP para que se configuren en el balanceador de cargas del clúster de administrador. Ten en cuenta que las VIP para los servidores de la API de Kubernetes de los clústeres de usuario se encuentran en la subred del clúster de administrador. Esto se debe a que, en este ejemplo, el servidor de la API de Kubernetes para un clúster de usuario se ejecuta en un nodo del clúster de administrador. Ten en cuenta que, en los archivos de configuración del clúster, el campo en el que especificas la VIP para un servidor de la API de Kubernetes se llama controlPlaneVIP:
| VIP | Dirección IP |
|---|---|
| Es la VIP para el servidor de la API de Kubernetes del clúster de administrador | 172.16.20.30 |
| VIP de complemento del clúster de administrador | 172.16.20.31 |
| VIP para el servidor de la API de Kubernetes del clúster de usuario 1 | 172.16.20.32 |
| VIP para el servidor de la API de Kubernetes del clúster de usuario 2 | 172.16.20.33 |
Direcciones IP de ejemplo: Nodos del clúster de usuario 1
Para un clúster de usuario que tiene cinco nodos, debes reservar seis direcciones IP. La dirección adicional es obligatoria, ya que se necesita durante la actualización del clúster y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos en el clúster de usuario 1:
| Direcciones IP para nodos en el clúster de usuario 1 |
|---|
| 172/16/21.2-172/16/21.7 |
Direcciones IP de ejemplo: VIP en la subred del clúster de usuario 1
En la siguiente tabla, se muestra un ejemplo de cómo podrías designar las VIP que se configurarán en el balanceador de cargas para el clúster de usuario 1:
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP de entrada para el clúster de usuario 1 | Configurado en el balanceador de cargas para el clúster de usuario 1 | 172.16.21.30 |
| VIP de servicio para el clúster de usuario 1 | Diez direcciones para los Services de tipo LoadBalancer.Se configura según sea necesario en el balanceador de cargas para el clúster de usuario 1. Observa que este rango incluye la VIP de entrada. Este es un requisito para el balanceador de cargas de MetalLB. |
172.16.21.30 - 172.16.21.39 |
Direcciones IP de ejemplo: Nodos de clúster de usuario 2
Para un clúster de usuario que tiene cuatro nodos, debes reservar cinco direcciones IP. La dirección adicional es obligatoria, ya que se necesita durante la actualización del clúster y la reparación automática. Por ejemplo, puedes reservar las siguientes direcciones IP para los nodos en el clúster de usuario 2:
| Direcciones IP para nodos en el clúster de usuario 2 |
|---|
| 172.16.22.2 - 172.16.22.6 |
Direcciones IP de ejemplo: VIP en la subred del clúster de usuario 2
En la siguiente tabla, se muestra un ejemplo de cómo podrías designar las VIP que se configurarán en el balanceador de cargas para el clúster de usuario 2:
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP de entrada para el clúster de usuario 2 | Configurado en el balanceador de cargas para el clúster de usuario 2 | 172.16.22.30 |
| VIP de servicio para el clúster de usuario 2 | Diez direcciones para los Services de tipo LoadBalancer.Se configura según sea necesario en el balanceador de cargas para el clúster de usuario 2. Observa que este rango incluye la VIP de entrada. Este es un requisito para el balanceador de cargas de MetalLB. |
172.16.22.30 - 172.16.22.39 |
Direcciones IP de ejemplo: Pods y Services
Antes de crear un clúster, debes especificar un rango CIDR para usar en las direcciones IP del Pod y otro rango en CIDR que se usará en las direcciones ClusterIP de los servicios de Kubernetes.
Decide qué rangos CIDR quieres usar para los Pods y Services. Por ejemplo:
| Objetivo | Rango de CIDR |
|---|---|
| Pods en el clúster de administrador | 192.168.0.0/16 |
| Pods en el clúster de usuario 1 | 192.168.0.0/16 |
| Pods en el clúster de usuario 2 | 192.168.0.0/16 |
| Services en el clúster de administrador | 10.96.232.0/24 |
| Services en el clúster de usuario 1 | 10.96.0.0/20 |
| Services en el clúster de usuario 2 | 10.96.128.0/20 |
En los ejemplos anteriores, se ilustran estos puntos:
El rango de CIDR de Pod puede ser el mismo para varios clústeres.
Por lo general, necesitarás más Pods que Services, por lo que, para un clúster determinado, es probable que quieras un rango de CIDR de pod que sea mayor que el rango de CIDR del Service. El rango de Pod de ejemplo para un clúster de usuario es 192.168.0.0/16, que tiene 2^(32-16) = 2^16 direcciones. Sin embargo, un rango de servicio de ejemplo para un clúster de usuario es 10.96.0.0/20, que solo tiene 2^(32-20) = 2^12 direcciones.
Evita la superposición
Se recomienda usar rangos CIDR no predeterminados para evitar la superposición con las direcciones IP a las que se pueda acceder en tu red. Los rangos de Service y Pod no deben superponerse con ninguna dirección fuera del clúster a la que deseas llegar desde dentro del clúster.
Por ejemplo, supongamos que el rango de Service es 10.96.232.0/24 y el rango de Pod es 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). El tráfico enviado desde un Pod a una dirección en cualquiera de esos rangos se tratará como tráfico en el clúster y no llegará a ningún destino fuera del clúster.
En particular, los rangos de Service y Pod no deben superponerse con lo siguiente:
Direcciones IP de nodos en cualquier clúster
Direcciones IP que usan las máquinas del balanceador de cargas
VIP que usan los balanceadores de cargas y los nodos del plano de control
Direcciones IP de los servidores de vCenter, DNS y NTP
Recomendamos que los rangos de Service y Pod estén en el espacio de direcciones privadas RFC 1918.
Esta es una razón para que la recomendación use direcciones RFC 1918. Supongamos que tu rango de Pod o Service contiene direcciones IP externas. Cualquier tráfico enviado desde un Pod a una de esas direcciones externas se tratará como tráfico en el clúster y no llegará al destino externo.
Servidor DNS y puerta de enlace predeterminada
Antes de completar los archivos de configuración, debes conocer la dirección IP de un servidor DNS que pueden usar la estación de trabajo de administrador y los nodos del clúster.
También debes conocer la dirección IP de la puerta de enlace predeterminada para cada una de las subredes. En los ejemplos anteriores, la puerta de enlace predeterminada para cada subred es la primera dirección en el rango. Por ejemplo, en la subred del clúster de administrador, la puerta de enlace predeterminada se muestra como 172.16.20.1.
Más información
Administra las direcciones IP de los nodos