Esta es la primera parte de una guía en la que se explica una pequeña instalación de prueba de concepto de Google Distributed Cloud con un clúster de usuario único.
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 sección 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 configures con esta guía no sea adecuada para tus casos de uso y necesidades de producción reales. Para obtener más información sobre las instalaciones de producción, consulta la Descripción general de la instalación y las guías.
Antes de comenzar
Lee la descripción general de Google Distributed Cloud, que proporciona una descripción general de cómo funciona Google Distributed Cloud, 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.
Deberías conocer 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 involucrados en esta configuración:
- Configura el entorno. Asegúrate de poder cumplir con los requisitos de los recursos. Proporcionamos una configuración de ejemplo para un host 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 Google Distributed Cloud se ejecutan dentro de una jerarquía de objetos de vSphere.
- Planifica tus direcciones IP. Google Distributed Cloud 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 te recomendamos que consultes a tu administrador de red para que te ayude a elegir las direcciones adecuadas para tu propia red.
- Configura las reglas de firewall y proxy
- Configura recursos de Google Cloud, incluido un proyecto de Google Cloud que usarás cuando configures y administres Google Distributed Cloud, y una cuenta de servicio con los permisos necesarios para acceder al software del componente de Google Distributed Cloud y descargarlo.
1. Configura tu 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 de hipersubprocesos habilitados
- 80 gibibytes (GiB) de RAM
- 470 GiB de almacenamiento
Asegúrate de tener ESXi 7.0u2 o superior instalado.
Asegúrate de usar vCenter Server 7.0u2 o una versión posterior.
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, el clúster, el almacén de datos y la red de vSphere, ya que los necesitarás para configurar 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 para usarla con el disco de máquina virtual (VMDK) de GKE alojado en VMware:
govc datastore.mkdir -namespace=true data-disks
3. Planifica las direcciones IP
Como se vio en la descripción general de Google Distributed Cloud, una instalación de Google Distributed Cloud requiere varias 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 de CIDR para la comunicación entre los Pods y los Services
Debido a esto, una parte importante de la configuración de Google Distributed Cloud es planificar tus direcciones IP, lo que incluye asegurarse de no crear ningún conflicto de direcciones. Es posible que necesites que el administrador de red te ayude a encontrar valores adecuados para configurar, incluso para esta simple instalación. 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 en paquetes de 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
Google Distributed Cloud te permite elegir entre proporcionar direcciones IP estáticas para los nodos de tu clúster o usar un servidor DHCP. En esta instalación sencilla, usarás direcciones IP estáticas.
Ejemplo de VLAN
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 dice que puedes usar 172.16.20.49 a 172.16.20.69 para 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.64 y otro nodo trabajador 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 en la tabla se muestran las direcciones de dos nodos adicionales: admin-vm-6 y user-vm-5. Los nodos adicionales se necesitan durante las actualizaciones de clústeres y las reparaciones automáticas. 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 | Se configura en el balanceador de cargas para el 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 nodos del plano de control.
| VIP | Descripción | Dirección IP |
|---|---|---|
| VIP para el servidor de la API de Kubernetes del clúster de usuario | Se configura en el balanceador de cargas para el clúster de administrador. | 172.16.20.59 |
| VIP de Ingress | Se configura en el balanceador de cargas para el 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 de los nodos del clúster y de acceder a la implementación, también debes especificar los rangos de direcciones que se pueden usar dentro de cada clúster para el tráfico dentro del clúster.
Para ello, especifica un rango CIDR que se usará en las direcciones IP del Pod y otro rango de CIDR que se usará con las direcciones ClusterIP de los servicios de Kubernetes. Estas 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 quieres usar para los Pods y Services. A menos que tengas un motivo para hacerlo, 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 Services. Por lo tanto, para un clúster determinado, es probable que necesites un rango de CIDR de Pod que sea mayor que el rango de CIDR de Service. Por ejemplo, el rango de Pods predeterminado de un clúster de usuario tiene 2^(32-16) = 2^16 direcciones, pero el rango de Service predeterminado de 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 de 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 dentro del 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 definidos por RFC 1918 para tus rangos de Pods y Service.
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. El 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 campos:
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 Google Distributed Cloud. Para ello, sigue las Reglas de proxy y firewall. Para realizar esta tarea, necesitarás las direcciones IP del nodo del clúster que identificaste en la sección anterior. Ten en cuenta que, debido a que las direcciones IP de los clústeres de usuario y administrador no están asignadas 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 utilizar todos los servicios de Google Cloud, incluidos los que se usan para instalar y administrar Google Distributed Cloud. Si no sabes cómo trabajar 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 será necesario más tarde.
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 que se indican en Instala el SDK de Google Cloud para asegurarte de tener la versión más actualizada.
Permisos necesarios
Si eres el propietario del proyecto (por ejemplo, si tú mismo creaste el proyecto), ya tienes todos los permisos necesarios para realizar el resto de esta instalación simple. Si no eres el propietario del proyecto, tú o el administrador del proyecto deben asegurarse de que tu 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 APIs y asegurarte de 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 tu organización deberá otorgarte los roles.
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: 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 Google Distributed Cloud. En este ejercicio, dos de esas cuentas de servicio se generan automáticamente. Sin embargo, debes crear las otras dos cuentas de servicio manualmente:
- Cuenta de servicio del registro de Connect (generada automáticamente)
- Cuenta de servicio de supervisión de registros (generada automáticamente)
- Cuenta de servicio de registro de auditoría (crear manualmente)
- Cuenta de servicio de acceso a los componentes (crear manualmente)
Cuenta de servicio de registro de auditoría
En tu proyecto de Google Cloud, crea una cuenta de servicio que Google Distributed Cloud pueda usar para enviar registros de auditoría de Kubernetes desde tu clúster a Cloud Audit Logs. Esto se denomina cuenta de servicio de registro de auditoría.
gcloud iam service-accounts create audit-logging-sa \ --display-name "Audit Logging Service Account" \ --project PROJECT_IDReemplaza
PROJECT_IDpor el ID del proyecto de Google Cloud.Obtén la dirección de correo electrónico de la cuenta de servicio de registro de auditoría recién creada:
gcloud iam service-accounts list \ --project PROJECT_IDCrea 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_AUDIT_LOGGINGReemplaza
SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGINGpor 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 la 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 Google Distributed Cloud pueda usar para descargar el código del componente del clúster en tu nombre de 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_IDReemplaza
PROJECT_IDpor el ID del proyecto de Google Cloud.Obtén la dirección de correo electrónico de la cuenta de servicio de acceso a los componentes recién creada:
gcloud iam service-accounts list \ --project PROJECT_IDCrea 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_COMPONENT_ACCESS
Reemplaza
SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESSpor la dirección de correo electrónico de tu cuenta de servicio de acceso a los componentes.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_COMPONENT_ACCESS" \ --role "roles/serviceusage.serviceUsageViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/iam.roleViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --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 necesarios para Google Distributed Cloud 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 \ kubernetesmetadata.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, llama a un comando de gcloud CLI que muestra 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?