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 Tareas y roles comunes de los usuarios de GKE Enterprise.
En este documento, se muestra cómo configurar entornos mínimos de vSphere y Google Cloud para esta instalación y 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 estar familiarizado con algunos Google Cloud conceptos básicos, incluidos 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 se deben seguir en esta configuración:
- Configura el entorno. Asegúrate de cumplir con los requisitos de 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 los administradores y los usuarios 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 red.
- Configura tu firewall y reglas de 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 al software de componentes 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 con hipersubproceso habilitado
- 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 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:
Anota los nombres del centro de datos, el clúster, el almacén de datos y la red de vSphere, ya que los necesitarás cuando configures tu estación de trabajo de administrador en Cómo crear 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 la 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 componentes del plano de control, como los servidores de la API de Kubernetes, y a las aplicaciones que se ejecutan en tus clústeres de usuarios
- 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 que el administrador de red te ayude a encontrar valores adecuados para configurar, incluso para esta instalación sencilla. 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 en paquetes. 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 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 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 las direcciones de 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 están en la misma VLAN que los nodos de trabajo 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 | Configurado 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 en cada clúster para el tráfico dentro del clúster.
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 los servicios. 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 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:
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 de tu 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 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 los recursos Google Cloud
Los proyectos de Google Cloud 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 estás familiarizado con el trabajo con proyectos de Google Cloud, puedes encontrar mucha más información en Cómo crear y administrar proyectos.
Elige un proyecto de Google Cloud existente o crea uno nuevo.
Anota el 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 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 lo creaste tú mismo), ya tienes todos los permisos necesarios para realizar el resto de esta sencilla instalación. 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.
Los siguientes roles de IAM te permiten crear una cuenta de servicio, asignarle roles de IAM, habilitar APIs y asegurarte de que la herramienta gkeadm
pueda crear y administrar cuentas de servicio por ti en la segunda parte de esta configuración:
resourcemanager.projectIamAdmin
serviceusage.serviceUsageAdmin
iam.serviceAccountCreator
iam.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
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 de Google Cloud debe tener cuatro cuentas 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 conexión (generada automáticamente)
- Cuenta de servicio de supervisión de registros (generada automáticamente)
- Cuenta de servicio de registro de auditoría (creación manual)
- Cuenta de servicio de acceso a 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 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 \ --display-name "Audit Logging Service Account" \ --project PROJECT_ID
Reemplaza
PROJECT_ID
por 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 creada recientemente:
gcloud iam service-accounts list \ --project PROJECT_ID
Crea 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_LOGGING
Reemplaza
SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING
por 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 de Google Cloud, crea una cuenta de servicio que Google Distributed Cloud pueda usar para descargar el código de componentes 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.Obtén la dirección de correo electrónico de la cuenta de servicio de acceso a componentes creada recientemente:
gcloud iam service-accounts list \ --project PROJECT_ID
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_COMPONENT_ACCESS
Reemplaza
SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS
por 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 de Google Cloud. Esto te permite usar todos los Google Cloud servicios 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.com
Si esta 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 la 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?