Esta es la primera parte de una guía que te guía a través de una pequeña instalación de prueba de concepto de Google Distributed Cloud (solo software) para VMware con un solo clúster de usuarios. Esta página está destinada a administradores, arquitectos y operadores que configuran, supervisan y administran la infraestructura tecnológica. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles de usuario y tareas comunes de GKE.
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. En el documento 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 necesidades de producción y casos de uso 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 (solo software) para VMware, que incluye una descripción general 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.
Asegúrate de conocer algunos conceptos Google Cloud básicos, incluidos los proyectos, los permisos de IAM y las cuentas de servicio. Si no es así, consulta las siguientes guías para obtener más información:
Descripción general del procedimiento
Estos son los pasos principales que se deben seguir en esta configuración:
- Configura el entorno. Asegúrate de cumplir con los requisitos de recursos. Proporcionamos un ejemplo de configuración para un host de ESXi y un almacén de datos de vSphere que cumplen con los requisitos para 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 administrador y de usuario a tu implementación. Para esta configuración, usarás direcciones IP estáticas para los nodos del clúster. Proporcionamos ejemplos, pero te recomendamos que consultes con el administrador de tu red para que te ayude a elegir las direcciones adecuadas para tu propia red.
- Configura tus reglas de firewall y proxy
- Configura Google Cloud recursos, incluido un Google Cloud proyecto que usarás cuando configures y administres Google Distributed Cloud, y una cuenta de servicio con los permisos necesarios para acceder y descargar el software de los componentes de Google Distributed Cloud.
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 con hipersubproceso habilitado
- 80 gibibytes (GiB) de RAM
- 470 GiB de almacenamiento
Asegúrate de tener instalada la versión 7.0u2 o posterior de ESXi.
Asegúrate de usar la versión 7.0u2 o 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 de tu centro de datos, clúster, almacén de datos y red de vSphere, ya que los necesitarás cuando configures tu 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 que se usará para el disco de máquina virtual (VMDK) de Google Distributed Cloud:
govc datastore.mkdir -namespace=true data-disks
3. Planifica las direcciones IP
Como viste 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 las aplicaciones que se ejecutan en tus clústeres de usuario
- Rangos CIDR para la comunicación entre Pods y Services
Por este motivo, una parte importante de la configuración de Google Distributed Cloud es planificar tus direcciones IP, lo que incluye asegurarte de no crear conflictos de direcciones. Es posible que necesites la ayuda del administrador de red para encontrar los 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 incluido. 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 del clúster o usar un servidor DHCP. En esta instalación simple, 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 indica que puedes usar 172.16.20.49 - 172.16.20.69 para las VMs 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, 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. Ten en cuenta que la tabla muestra direcciones para dos nodos adicionales: admin-vm-6 y user-vm-5. Se necesitan nodos adicionales durante las actualizaciones y la reparación automática del clúster. 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: VIPs 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 tu 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.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 se encuentran 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 | Configurado 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 - 172.16.20.69 |
Direcciones IP para Pods y servicios
Además de las direcciones IP de los nodos del clúster y para acceder a tu implementación, también debes especificar los rangos de direcciones que se pueden usar dentro de cada clúster para el tráfico interno.
Para ello, 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. 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 CIDR quieres usar para los Pods y Services. A menos que tengas una razón para hacer lo contrario, 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, 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 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 de 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 internas 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, 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 Google Distributed Cloud, según las reglas de proxy y firewall. Para llevar a cabo esta tarea, necesitarás las direcciones IP de los nodos del clúster que identificaste en la sección anterior. Ten en cuenta que, como las direcciones IP de los clústeres de usuario y de administrador no se asignan a nodos específicos, debes asegurarte de que todas las reglas de firewall pertinentes se apliquen a todas las direcciones IP de cada clúster.
5. Configura los recursos Google Cloud
Google Cloud Los proyectos son la base para crear, habilitar y usar todos los Google Cloud servicios, 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 Google Cloud proyecto existente o crea uno nuevo.
Toma nota del Google Cloud ID del proyecto, 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 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 lo creaste tú mismo), 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 APIs y garantizar que la herramienta gkeadm pueda crear y administrar cuentas de servicio por ti en la segunda parte de esta configuración:
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.serviceAccountKeyAdmin
Para obtener detalles sobre los permisos necesarios para otorgar roles de IAM por tu cuenta, consulta Otorga, cambia y revoca el acceso a los recursos. Si no tienes estos permisos, alguien 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_ID: Es el 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 Google Cloud debe tener cuatrocuentas de servicio para que Google Distributed Cloud las use. En este ejercicio, se generan automáticamente dos de esas cuentas de servicio. Sin embargo, debes crear las otras dos cuentas de servicio de forma manual:
- Cuenta de servicio del registro de Connect (se genera automáticamente)
- Cuenta de servicio de supervisión de registros (se genera automáticamente)
- Cuenta de servicio de registro de auditoría (crear manualmente)
- Cuenta de servicio de acceso a componentes (crear manualmente)
Cuenta de servicio de registro de auditoría
En tu proyecto 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 los registros de auditoría de Cloud. Esta 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 de tu proyecto deGoogle 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 tu 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 otorgar funciones a la cuenta de servicio de registro de auditoría.
Cuenta de servicio de acceso a componentes
En tu proyecto Google Cloud , crea una cuenta de servicio que Google Distributed Cloud pueda usar para descargar código de componentes del clúster en tu nombre desde Artifact 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 de tu proyecto deGoogle Cloud .Obtén la dirección de correo electrónico de la cuenta de servicio de acceso a 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 los siguientes 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_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 Google Cloud . Esto te permite usar todos los servicios de Google Cloud que necesita 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 muestre las versiones disponibles que puedes usar para crear un clúster de usuarios:gcloud container vmware clusters query-version-config \ --project=PROJECT_ID \ --location="us-central1"¿Qué sigue?