En este documento, se muestra cómo configurar entornos de vSphere y Google Cloud mínimos para una instalación pequeña de prueba de concepto de clústeres de Anthos alojados en VMware (GKE On-Prem).
La instalación incluye una estación de trabajo de administrador, un clúster de administrador y un clúster de usuario.
Antes de comenzar
Lee la descripción general de los clústeres de Anthos alojados en VMware.
Consulta las versiones compatibles de vSphere.
Consulta los requisitos de licencia de vSphere. Para esta instalación mínima, es suficiente una licencia estándar de vSphere.
Necesitas una instancia en ejecución de vCenter Server.
Necesitas una cuenta de usuario de vCenter con privilegios suficientes. Toma nota del nombre de usuario y la contraseña de esta cuenta.
Requisitos de CPU, RAM y almacenamiento
Para esta instalación mínima, puedes usar un solo host físico que ejecute ESXi.
Estos son los requisitos mínimos de los recursos para tu host de ESXi:
- 8 CPU @ 2.7Ghz con hipersubproceso habilitado
- 80 gibibytes (GiB) de RAM
El requisito mínimo de almacenamiento es de 470 GiB.
Ejemplo de host y almacén de datos
Este es un ejemplo de un host de ESXi y un Almacén de datos de vSphere que cumple con los requisitos:
Configuración del host de ESXi:
- Fabricante: Dell Inc.
- CPU físicas: 8 CPU a 2.7 GHz
- Tipo de procesador: Intel(R) Xeon(R) Platino 8168 CPU @ 2.70GHz
- Sockets del procesador: 2
- Versión de ESXi: 6.7U3
- Versión del servidor de Vcenter: 6.7U3
- Hipersubproceso: habilitado
Configuración de Datastore:
- Tipo: VMFS 6.82
- Tipo de unidad: SSD
- Proveedor: DELL
- Tipo de unidad: lógica
- Nivel RAID: RAID1
Objetos de vSphere
Configura los siguientes objetos en tu entorno de vSphere:
Balanceo de cargas
Los clústeres en esta instalación mínima 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
Planifica las direcciones IP
Más adelante, cuando crees clústeres básicos, deberás especificar direcciones IP estáticas para los nodos del clúster.
Para esta instalación pequeña, te recomendamos que coloques tu estación de trabajo de administrador, los nodos del clúster de administrador y los nodos del clúster de usuario en la misma VLAN de tu red de vSphere. Por ejemplo, supongamos que todas las direcciones IP del rango 172.16.20.0/24 se enrutan a una VLAN específica. Además, supongamos que tu administrador de red indica que puedes usar 172.16.20.49 - 172.16.20.72 para las VM y direcciones IP virtuales (VIP).
En el siguiente diagrama, se ilustra una VLAN que tiene una estación de trabajo de administrador, un clúster de administrador y un clúster de usuario. 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, un nodo trabajador podría anunciar 172.16.20.63 y otro nodo trabajador podría anunciar 172.16.20.64.
Dirección IP de ejemplo: estación de trabajo de administrador
Para la estación de trabajo de administrador, este ejemplo usa la primera dirección en el rango que te proporciona tu administrador de red: 172.16.20.49.
Direcciones IP de ejemplo: nodos del clúster
En la siguiente tabla, se muestra un ejemplo de cómo se pueden usar las direcciones IP para los nodos del clúster. En la tabla, se muestran dos nodos adicionales: admin-vm-5 y user-vm-4. Los nodos adicionales son necesarios durante la actualización del clúster, la actualización y la reparación automática. Para obtener más información, consulta Administra direcciones IP de nodo.
| Nombre de host de la VM | Descripción | Dirección IP |
|---|---|---|
| admin-vm-1 | Nodo del plano de control para el clúster de administrador | 172.16.20.50 |
| admin-vm-2 | Nodo de complemento del clúster de administrador | 172.16.20.51 |
| admin-vm-3 | Nodo de complemento del clúster de administrador | 172.16.20.52 |
| admin-vm-4 | Nodo del plano de control para el clúster de usuario Este nodo está en el clúster de administrador. |
172.16.20.53 |
| admin-vm-5 | 172.16.20.54 | |
| user-vm-1 | Nodo trabajador del clúster de usuario | 172.16.20.55 |
| user-vm-2 | Nodo trabajador del clúster de usuario | 172.16.20.56 |
| user-vm-3 | Nodo trabajador del clúster de usuario | 172.16.20.57 |
| user-vm-4 | 172.16.20.58 |
Direcciones IP de ejemplo: VIP para el clúster de administrador
En la siguiente tabla, se muestra un ejemplo de cómo podrías especificar las VIP para el clúster de administrador:
| VIP | Descripción | Dirección IP |
|---|---|---|
| Es la VIP para el servidor de la API de Kubernetes del clúster de administrador | Configurado en el balanceador de cargas para el clúster de administrador | 172.16.20.59 |
| VIP de complemento del clúster de administrador | Configurado en el balanceador de cargas para el clúster de administrador | 172.16.20.60 |
Direcciones IP de ejemplo: VIP para el clúster de usuario
En la siguiente tabla, se muestra un ejemplo de cómo podrías especificar las VIP para el clúster de usuario.
Ten en cuenta que la VIP para el servidor de la API de Kubernetes del clúster de usuario se configura en el balanceador de cargas del clúster de administrador. Esto se debe a que el servidor de la API de Kubernetes para un clúster de usuario se ejecuta en un nodo en el 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 API de Kubernetes se llama controlPlaneVIP:
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP para el servidor de la API de Kubernetes del clúster de usuario | Configurado en el balanceador de cargas para el clúster de administrador | 172.16.20.61 |
| VIP de Ingress | Configurado en el balanceador de cargas para el clúster de usuario | 172.16.20.62 |
| VIPs de Service | Diez direcciones para los Services de tipo LoadBalancer.Configurado según sea necesario en el balanceador de cargas para el clúster de usuario. Observa que este rango incluye la VIP de entrada. Este es un requisito para el balanceador de cargas de MetalLB. |
172.16.20.62 - 172.16.20.71 |
Direcciones IP para Pods y servicios
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. A menos que tengas una razón para hacer lo contrario, puedes usar los siguientes rangos predeterminados:
| Objetivo | Rango CIDR predeterminado |
|---|---|
| Pods del clúster de administrador | 192.168.0.0/16 |
| Pods del clúster de usuario | 192.168.0.0/16 |
| Services de clústeres de administrador | 10.96.232.0/24 |
| Services de clústeres de usuarios | 10.96.0.0/20 |
Los valores predeterminados ilustran estos puntos:
El rango de CIDR de Pod puede ser el mismo para varios clústeres.
El rango CIDR de Service de un clúster no debe superponerse con el rango de CIDR de servicio de ningún otro clúster.
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. Por ejemplo, el rango de pod predeterminado para un clúster de usuario tiene 2^(32-16) = 2^16 direcciones, pero el rango de servicio predeterminado para un clúster de usuario 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. 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
Dirección IP de los servidores de vCenter, DNS y NTP
Te recomendamos que uses los rangos de direcciones IP privadas que define RFC 1918 para los rangos de Pods y Services.
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 crear tus clústeres de administrador y de usuario, debes conocer las direcciones IP de:
Un servidor DNS que puede usar la estación de trabajo de administrador y los nodos de clústeres
La dirección IP de la puerta de enlace predeterminada para la subred que tiene la estación de trabajo de administrador y los nodos del clústeres. Por ejemplo, supongamos que tu estación de trabajo de administrador, los nodos del clúster de administrador y los nodos del clúster de usuario están en la subred 172.16.20.0/24. La dirección de la puerta de enlace predeterminada para la subred puede ser 172.16.20.1.
Configura tu firewall y proxy
Configura tu firewall y proxy según las reglas de proxy y firewall.
Configura recursos de Google Cloud
Elige un proyecto de Google Cloud existente o crea uno nuevo. Toma nota del ID del proyecto de Cloud.
En el proyecto de Cloud, crea una cuenta de servicio para acceder a los componentes de los clústeres de Anthos alojados en VMware. Esto se denomina cuenta de servicio de acceso a los componentes:
gcloud iam service-accounts create component-access-sa \
--display-name "Component Access Service Account" \
--project PROJECT_ID
Reemplaza PROJECT_ID por el ID de tu proyecto de Cloud.
Crea una clave JSON para tu cuenta de servicio de acceso a los componentes:
gcloud iam service-accounts keys create component-access-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL
Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de la cuenta de servicio de acceso a los componentes.
Otorga roles de IAM a tu cuenta de servicio de acceso a los componentes:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/serviceusage.serviceUsageViewer"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/iam.roleViewer"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/iam.serviceAccountViewer"
Para obtener más información sobre la cuenta de servicio de acceso a los componentes y cómo otorgar roles de IAM, consulta Cuentas de servicio y claves.
Habilite las API de Google
Habilita las siguientes API de Google en tu proyecto de Cloud:
gcloud services enable --project PROJECT_ID \
anthos.googleapis.com \
anthosgke.googleapis.com \
anthosaudit.googleapis.com \
cloudresourcemanager.googleapis.com \
container.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
serviceusage.googleapis.com \
stackdriver.googleapis.com \
opsconfigmonitoring.googleapis.com \
monitoring.googleapis.com \
logging.googleapis.com \
iam.googleapis.com \
storage.googleapis.com