Esta es la primera parte de la guía en la que se explica una pequeña instalación de prueba de concepto de GKE en VMware con un solo clúster de usuario.
En este documento, se muestra cómo configurar entornos mínimos de vSphere y Google Cloud para esta instalación y cómo planificar tus direcciones IP, mientras que en la página de seguimiento Crea clústeres básicos, se muestra cómo crear una estación de trabajo de administrador, un clúster de administrador y un clúster de usuario.
Es posible que la infraestructura que configuraste con esta guía no sea adecuada para tus necesidades de producción ni casos de uso reales. Para obtener más información sobre las instalaciones de producción, consulta las guías y la descripción general de la instalación.
Antes de comenzar
Lee la descripción general de GKE en VMware, que proporciona una descripción general de cómo funciona GKE en VMware, incluida la función de cada componente que instalarás en esta configuración.
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.
Debes estar familiarizado con algunos conceptos básicos de Google Cloud, como los proyectos, los permisos de IAM y las cuentas de servicio. De lo contrario, consulta las siguientes guías para obtener más información:
Descripción general del procedimiento
Estos son los pasos principales que implica esta configuración:
- Configura el entorno. Asegúrate de cumplir con los requisitos de los recursos. Proporcionamos una configuración de ejemplo para un host de ESXi y un almacén de datos de vSphere que cumplen con los requisitos de esta instalación.
- Configura objetos de vSphere. Los componentes de GKE en VMware se ejecutan dentro de una jerarquía de objetos de vSphere.
- Planifica las direcciones IP. GKE en VMware requiere que proporciones direcciones IP para todos los nodos, además de direcciones IP virtuales (VIP) para el acceso de administradores y usuarios a tu implementación. En esta configuración, usarás direcciones IP estáticas para los nodos del clúster. Proporcionamos ejemplos, aunque recomendamos que consultes con tu administrador de red para que te ayude a elegir las direcciones adecuadas para tu propia red.
- Configura tus reglas de firewall y proxy
- Configura los recursos de Google Cloud, incluido un proyecto de Google Cloud que usarás cuando configures y administres GKE en VMware y una cuenta de servicio con los permisos necesarios para acceder al software del componente de GKE en VMware y descargarlo.
1. Configura el entorno
Para esta instalación mínima, puedes usar un solo host físico que ejecute ESXi.
Asegúrate de que tu host tenga la siguiente capacidad mínima de CPU, RAM y almacenamiento:
- 8 CPU físicas a 2.7 GHz con hipersubprocesos habilitados
- 80 gibibytes (GiB) de RAM
- 470 GiB de almacenamiento
Asegúrate de tener instalada la versión 7.0u2 de ESXi o una posterior.
Asegúrate de usar la versión 7.0u2 o una posterior de vCenter Server.
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: 7.0u2 o posterior
- Versión de vCenter Server: 7.0u2 o posterior
- Hipersubproceso: habilitado
Configuración de Datastore:
- Tipo: VMFS 6.82
- Tipo de unidad: SSD
- Proveedor: DELL
- Tipo de unidad: lógica
- Nivel RAID: RAID1
2. Configura objetos de vSphere
Configura los siguientes objetos en tu entorno de vSphere:
Toma nota de los nombres del centro de datos de vSphere, el clúster, el almacén de datos y la red, ya que los necesitarás cuando configures la estación de trabajo de administrador en Crea clústeres básicos.
Si configuraste un almacén de datos de vSAN, usa govc para crear una carpeta en tu directorio datastore y usarla en el disco de máquina virtual (VMDK) de GKE on VMware:
govc datastore.mkdir -namespace=true data-disks
3. Planifica las direcciones IP
Como viste en la descripción general de GKE en VMware, la instalación de GKE en VMware requiere una serie de direcciones IP, incluidas las siguientes:
- Direcciones IP para todos los nodos
- Direcciones IP virtuales (VIP) para acceder a los componentes del plano de control, como los servidores de la API de Kubernetes, y a las aplicaciones que se ejecutan en los clústeres de usuario
- Rangos CIDR para la comunicación entre Pods y objetos Service
Debido a esto, una parte importante de la configuración de GKE en VMware es planificar tus direcciones IP, lo que incluye asegurarse de no crear conflictos de direcciones. Es posible que necesites que el administrador de red te ayude a encontrar valores adecuados para configurar, incluso para esta instalación simple. En el resto de esta sección, proporcionamos ejemplos ilustrativos de valores que funcionan para esta instalación en una red hipotética; tus valores serán diferentes.
Los clústeres en esta instalación mínima usan el balanceador de cargas MetalLB empaquetado. 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
GKE en VMware te permite elegir entre proporcionar direcciones IP estáticas para los nodos del clúster o usar un servidor de DHCP. En esta instalación simple, usarás direcciones IP estáticas.
VLAN de ejemplo
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 el administrador de red indica que puedes usar entre 172.16.20.49 y 172.16.20.69 para las VM y las 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.64 y otro podría anunciar 172.16.20.65.
Dirección IP de ejemplo: estación de trabajo de administrador
Para la estación de trabajo de administrador, en este ejemplo se usa la primera dirección en el rango que te proporcionó el 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. Ten en cuenta que la tabla muestra las direcciones de dos nodos adicionales: admin-vm-6 y user-vm-5. Se necesitan nodos adicionales durante las actualizaciones del clúster, las actualizaciones y la reparación automática. Para obtener más información, consulta Administra direcciones IP de nodos.
| 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 del plano de control para el clúster de administrador. | 172.16.20.51 |
| admin-vm-3 | Nodo del plano de control para el clúster de administrador. | 172.16.20.52 |
| user-vm-1 | Nodo del plano de control para el clúster de usuario | 172.16.20.53 |
| user-vm-2 | Nodo trabajador del clúster de usuario | 172.16.20.54 |
| user-vm-3 | Nodo trabajador del clúster de usuario | 172.16.20.55 |
| user-vm-4 | Nodo trabajador del clúster de usuario | 172.16.20.56 |
| user-vm-5 | 172.16.20.57 |
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 una VIP del plano de control 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 | Configurada en el balanceador de cargas del clúster de administrador. | 172.16.20.58 |
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 y la VIP de entrada están en la misma VLAN que los nodos trabajadores y los del plano de control.
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP para el servidor de la API de Kubernetes del clúster de usuario | Configurada en el balanceador de cargas del clúster de administrador. | 172.16.20.59 |
| VIP de Ingress | Configurada en el balanceador de cargas del clúster de usuario. | 172.16.20.60 |
| 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.60 a 172.16/20.69 |
Direcciones IP para Pods y servicios
Además de las direcciones IP para los nodos del clúster y para acceder a la implementación, también debes especificar los rangos de direcciones que se pueden usar en cada clúster para el tráfico en el clúster.
Para hacerlo, debes especificar un rango CIDR que se usará en las direcciones IP del Pod y otro rango de CIDR que se usará en las direcciones ClusterIP de los servicios de Kubernetes. Estos se especifican como parte de la configuración del clúster, como verás en la siguiente parte de esta guía.
Como parte de tu planificación de IP, decide qué rangos de CIDR deseas usar para los Pods y los Services. A menos que tengas un motivo para hacerlo de otro modo, usa 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, necesitas más Pods que objetos Service, por lo que, para un clúster determinado, es probable que quieras un rango de CIDR de Pod mayor que el rango de CIDR de Service. Por ejemplo, el rango de Pods predeterminado para un clúster de usuario tiene 2^(32-16) = 2^16 direcciones, pero el rango de Service predeterminado para un clúster de usuario solo tiene 2^(32-20) = 2^12 direcciones.
Evita la superposición
En algunos casos, es posible que debas usar rangos CIDR no predeterminados para evitar la superposición con direcciones IP a las que se puede 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 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 internas que define RFC 1918 para tus rangos de pods y servicios.
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 los clústeres de administrador y de usuario, también debes conocer las direcciones IP de los siguientes elementos:
Un servidor DNS que puede usar la estación de trabajo de administrador y los nodos de clústeres
Un servidor NTP que pueden usar los nodos del clúster
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.
4. Configura tu firewall y proxy
Configura tu firewall y proxy para permitir el tráfico necesario de GKE en VMware de acuerdo con las reglas de proxy y firewall. Necesitarás las direcciones IP del nodo del clúster que identificaste en la sección anterior para realizar esta tarea. Ten en cuenta que, debido a que las direcciones IP de los clústeres de usuario y administrador no se asignan a nodos específicos, debes asegurarte de que todas las reglas de firewall relevantes se apliquen a todas las direcciones IP de cada clúster.
5. Configura recursos de Google Cloud
Los proyectos de Google Cloud forman la base para crear, habilitar y usar todos los servicios de Google Cloud, incluidos los que se usan para instalar y administrar GKE en VMware. Si no estás familiarizado con el trabajo con proyectos de Google Cloud, puedes encontrar mucha más información en Crea y administra proyectos.
Elige un proyecto de Google Cloud existente o crea uno nuevo.
Toma nota del ID del proyecto de Google Cloud, ya que lo necesitarás más adelante.
Configura la CLI de Google Cloud
Google Cloud CLI es una herramienta de línea de comandos que puedes usar para trabajar con tu proyecto. Sigue las instrucciones en Cómo instalar el SDK de Google Cloud para asegurarte de tener la versión más reciente.
Permisos necesarios
Si eres el propietario del proyecto (por ejemplo, si lo creaste tú mismo), ya tienes todos los permisos necesarios para realizar el resto de esta simple instalación. Si no eres el propietario del proyecto, tú o el administrador del proyecto deben asegurarse de que la Cuenta de Google tenga los permisos necesarios.
Las siguientes funciones de IAM te permiten crear una cuenta de servicio, asignarle funciones de IAM, habilitar las API y garantizar que la herramienta de gkeadm pueda crear y administrar cuentas de servicio por ti en la segunda parte de esta configuración:
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.serviceAccountKeyAdmin
Si quieres obtener detalles sobre los permisos necesarios para otorgar funciones de IAM por tu cuenta, consulta Otorga, cambia y revoca el acceso a los recursos. Si no tienes estos permisos, otra persona de la organización deberá otorgarte las funciones.
Para otorgar las funciones, sigue estos pasos:
Linux y macOS
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountKeyAdmin"
Windows
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountKeyAdmin"
Reemplaza lo siguiente:
PROJECT_IDEl ID de tu proyecto de Google Cloud.ACCOUNT: Es la dirección de correo electrónico de identificación de tu Cuenta de Google.
Configura cuentas de servicio
Tu proyecto de Google Cloud debe tener cuatro cuentas de servicio para que las use GKE on VMware. En este ejercicio, dos de esas cuentas de servicio se generan automáticamente. Sin embargo, debes crear las otras dos cuentas de servicio de forma manual:
- Cuenta de servicio del registro de conexión (generada automáticamente)
- Cuenta de servicio de supervisión de registros (generada automáticamente)
- Cuenta de servicio de registro de auditoría (crearla manualmente)
- Cuenta de servicio de acceso a los componentes (crearla manualmente)
Cuenta de servicio de registro de auditoría
En tu proyecto de Google Cloud, crea una cuenta de servicio que GKE on VMware pueda usar para enviar registros de auditoría de Kubernetes desde tu clúster a los registros de auditoría de Cloud. Esto se denomina cuenta de servicio de registro de auditoría.
gcloud iam service-accounts create audit-logging-sa \ --project PROJECT_ID
Crea una clave JSON para la cuenta de servicio de registro de auditoría:
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL
Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de tu cuenta de servicio de registro de auditoría.
No es necesario que otorgues ningún rol a tu cuenta de servicio de registro de auditoría.
Cuenta de servicio de acceso a componentes
En tu proyecto de Google Cloud, crea una cuenta de servicio que GKE on VMware pueda usar para descargar el código de componente del clúster en tu nombre desde Container Registry. 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 del proyecto de Google 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 identificación única de tu cuenta de servicio.
Agrega las siguientes funciones de IAM a la 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"
Habilita las APIs de Google
Habilita las siguientes APIs de Google en tu proyecto de Google Cloud. Esto te permite usar todos los servicios de Google Cloud que necesita GKE on VMware en tu proyecto.
gcloud services enable --project PROJECT_ID \ anthos.googleapis.com \ anthosgke.googleapis.com \ anthosaudit.googleapis.com \ cloudresourcemanager.googleapis.com \ connectgateway.googleapis.com \ container.googleapis.com \ gkeconnect.googleapis.com \ gkehub.googleapis.com \ gkeonprem.googleapis.com \ serviceusage.googleapis.com \ stackdriver.googleapis.com \ opsconfigmonitoring.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.com \ iam.googleapis.com \ storage.googleapis.comSi es la primera vez que habilitas la API de GKE On-Prem (
gkeonprem.googleapis.com) en tu proyecto, debes inicializar la API. Para ello, puedes llamar a un comando de gcloud CLI que muestre las versiones disponibles que puedes usar para crear un clúster de usuario:gcloud container vmware clusters query-version-config \ --project=PROJECT_ID \ --location="us-central1"¿Qué sigue?