Esta página se ha traducido con Cloud Translation API.

Configurar una infraestructura mínima

Esta es la primera parte de una guía que te muestra cómo instalar una pequeña prueba de concepto de Google Distributed Cloud (solo software) para VMware con un solo clúster de usuario. Esta página está dirigida a administradores, arquitectos y operadores que configuran, monitorizan y gestionan la infraestructura tecnológica. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el Google Cloud contenido, consulta Roles y tareas habituales de los usuarios de GKE.

En este documento se explica cómo configurar entornos mínimos de vSphere y Google Cloud para esta instalación y cómo planificar las direcciones IP. En el artículo Crear 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 prácticos 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 empezar

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 de vSphere Standard.
Necesitas una instancia en ejecución de vCenter Server.
Necesitas una cuenta de usuario de vCenter con privilegios suficientes. Anota el nombre de usuario y la contraseña de esta cuenta.
Familiarízate con algunos Google Cloud conceptos básicos, como proyectos, permisos de gestión de identidades y accesos, y 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 hay que seguir para completar la configuración:

Configura tu entorno. Asegúrate de que puedes cumplir los requisitos de recursos. Proporcionamos un ejemplo de configuración para un host ESXi y un almacén de datos de vSphere que cumplen los requisitos de esta instalación.
Configurar objetos de vSphere. Los componentes de Google Distributed Cloud se ejecutan en 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 (VIPs) para que los administradores y los usuarios puedan acceder a tu implementación. En 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.
Configurar las reglas de cortafuegos y proxy
Configura Google Cloud recursos, como un Google Cloud proyecto que usarás al configurar y gestionar 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. Configurar un entorno

Para esta instalación mínima, puedes usar un único host físico que ejecute ESXi.

Asegúrate de que tu host tenga los siguientes requisitos mínimos de CPU, RAM y capacidad de almacenamiento:
- 8 CPUs físicas a 2,7 GHz con hiperprocesamiento habilitado
- 80 gibibytes (GiB) de RAM
- 470 GiB de almacenamiento
Asegúrate de que tienes instalada la versión 7.0u2 o una posterior de ESXi.
Asegúrate de que estás usando vCenter Server 7.0u2 o una versión posterior.

Ejemplo de host y almacén de datos

A continuación, se muestra un ejemplo de un host ESXi y un almacén de datos de vSphere que cumplen los requisitos:

Configuración del host ESXi:
- Fabricante: Dell Inc.
- CPUs físicas: 8 CPUs a 2,7 GHz
- Tipo de procesador: Intel(R) Xeon(R) Platinum 8168 CPU @ 2.70 GHz
- Zócalos de procesador: 2
- Versión de ESXi: 7.0u2 o posterior
- Versión de vCenter Server: 7.0u2 o posterior
- Hyperthreading: habilitado
Configuración de Datastore:
- Tipo: VMFS 6.82
- Tipo de unidad: SSD
- Proveedor: DELL
- Tipo de unidad: lógica
- Nivel de RAID: RAID1

2. Configurar objetos de vSphere

Configure los siguientes objetos en su entorno de vSphere:

Anota los nombres de tu centro de datos, clúster, almacén de datos y red de vSphere, ya que los necesitarás para configurar tu estación de trabajo de administrador en Crear clústeres básicos.

Si ha configurado un almacén de datos de vSAN, utilice govc para crear una carpeta en el 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. Planificar tus direcciones IP

Como has visto en la descripción general de Google Distributed Cloud, una instalación de Google Distributed Cloud requiere varias direcciones IP, entre las que se incluyen las siguientes:

Direcciones IP de todos los nodos
Direcciones IP virtuales (VIPs) 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 usuario
Intervalos CIDR para la comunicación entre pods y servicios

Por este motivo, una parte importante de la configuración de Google Distributed Cloud es planificar tus direcciones IP, lo que incluye asegurarte de que no se produzcan conflictos de direcciones. Es posible que necesites la ayuda de tu administrador de red para encontrar los valores adecuados que debes configurar, incluso para esta instalación sencilla. En el resto de esta sección, se proporcionan ejemplos ilustrativos de valores que funcionan para esta instalación en una red hipotética. Tus valores serán diferentes.

Los clústeres de esta instalación mínima usan el balanceador de carga MetalLB incluido. Este balanceador de carga se ejecuta en los nodos del clúster, por lo que no se necesitan máquinas virtuales adicionales para el balanceo de carga.
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 pequeña instalación, 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 vSphere. Por ejemplo, supongamos que todas las direcciones IP del intervalo 172.16.20.0/24 se enrutan a una VLAN concreta. Supongamos que tu administrador de red te dice que puedes usar el intervalo 172.16.20.49 - 172.16.20.69 para las máquinas virtuales y las direcciones IP virtuales (VIPs).

En el siguiente diagrama se muestra 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 IPs virtuales no se muestran asociadas a ningún nodo concreto de un clúster. Esto se debe a que el balanceador de carga de MetalLB puede elegir qué nodo anuncia la IP virtual de un servicio concreto. Por ejemplo, en el clúster de usuarios, un nodo de trabajo podría anunciar 172.16.20.64 y otro nodo de trabajo podría anunciar 172.16.20.65.

Direcciones IP de un clúster de administrador y un clúster de usuario. — Direcciones IP de un clúster de administrador y un clúster de usuario (haz clic para ampliar)

Dirección IP de ejemplo: estación de trabajo de administrador

En el caso de la estación de trabajo del administrador, este ejemplo usa la primera dirección del intervalo que te ha proporcionado el administrador de la red: 172.16.20.49.

Ejemplo de direcciones IP: nodos de clúster

En la siguiente tabla se muestra un ejemplo de cómo se podrían usar las direcciones IP para los nodos de clúster. Ten en cuenta que la tabla muestra las direcciones de dos nodos adicionales: admin-vm-6 y user-vm-5. Los nodos adicionales son necesarios durante las actualizaciones de clústeres, las actualizaciones y la reparación automática. Para obtener más información, consulta Gestionar direcciones IP de nodos.

Nombre de host de la VM	Descripción	Dirección IP
admin-vm-1	Nodo de plano de control del clúster de administrador.	172.16.20.50
admin-vm-2	Nodo de plano de control del clúster de administrador.	172.16.20.51
admin-vm-3	Nodo de plano de control del clúster de administrador.	172.16.20.52
user-vm-1	Nodo de plano de control del clúster de usuarios.	172.16.20.53
user-vm-2	Nodo de trabajador de clúster de usuarios	172.16.20.54
user-vm-3	Nodo de trabajador de clúster de usuarios	172.16.20.55
user-vm-4	Nodo de trabajador de clúster de usuarios	172.16.20.56
user-vm-5		172.16.20.57

Direcciones IP de ejemplo: IP virtual del clúster de administrador

En la siguiente tabla se muestra un ejemplo de cómo especificar un VIP de plano de control para tu clúster de administrador.

VIP	Descripción	Dirección IP
VIP del servidor de la API de Kubernetes del clúster de administrador	Configurado en el balanceador de carga del clúster de administrador.	172.16.20.58

Direcciones IP de ejemplo: IPs virtuales del clúster de usuarios

En la siguiente tabla se muestra un ejemplo de cómo puede especificar las IPs virtuales de su clúster de usuarios.

Ten en cuenta que la dirección IP virtual del servidor de la API de Kubernetes del clúster de usuario y la dirección IP virtual de entrada están en la misma VLAN que los nodos de trabajador y los nodos del plano de control.

VIP	Descripción	Dirección IP
VIP del servidor de la API de Kubernetes del clúster de usuario	Configurado en el balanceador de carga del clúster de administrador.	172.16.20.59
IP virtual de Ingress	Configurado en el balanceador de carga del clúster de usuarios.	172.16.20.60
Servicio VIPs	Diez direcciones de servicios de tipo `LoadBalancer`. Configurado según sea necesario en el balanceador de carga del clúster de usuarios. Ten en cuenta que este intervalo incluye el VIP de entrada. Este es un requisito del balanceador de carga MetalLB.	172.16.20.60 - 172.16.20.69

Direcciones IP de pods y servicios

Además de las direcciones IP de los nodos del clúster y para acceder a la implementación, también debe especificar los intervalos de direcciones que se pueden usar en cada clúster para el tráfico interno.

Para ello, especifica un intervalo CIDR que se usará para las direcciones IP de los pods y otro intervalo CIDR que se usará para las direcciones ClusterIP de los servicios de Kubernetes. 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 la planificación de tu IP, decide qué intervalos CIDR quieres usar para los pods y los servicios. A menos que tengas un motivo para hacerlo de otra forma, utiliza los siguientes intervalos predeterminados:

Finalidad	Intervalo CIDR predeterminado
Pods de clústeres de administrador	192.168.0.0/16
Pods de clústeres de usuarios	192.168.0.0/16
Servicios del clúster de administrador	10.96.232.0/24
Servicios de clúster de usuarios	10.96.0.0/20

Los valores predeterminados ilustran estos puntos:

El intervalo CIDR de los pods puede ser el mismo en varios clústeres.
El intervalo CIDR de servicio de un clúster no debe solaparse con el intervalo CIDR de servicio de ningún otro clúster.
Normalmente, necesitas más pods que servicios, por lo que, en un clúster determinado, probablemente quieras que el intervalo CIDR de los pods sea mayor que el intervalo CIDR de los servicios. Por ejemplo, el intervalo de pods predeterminado de un clúster de usuario tiene 2^(32-16) = 2^16 direcciones, pero el intervalo de servicios predeterminado de un clúster de usuario solo tiene 2^(32-20) = 2^12 direcciones.

Evita las superposiciones

En algunos casos, es posible que tengas que usar intervalos CIDR no predeterminados para evitar que se solapen con las direcciones IP a las que se puede acceder en tu red. Los intervalos de servicios y pods no deben solaparse con ninguna dirección fuera del clúster a la que quieras acceder desde dentro del clúster.

Por ejemplo, supongamos que tu intervalo de servicio es 10.96.232.0/24 y tu intervalo de pods es 192.168.0.0/16. El tráfico enviado desde un pod a una dirección de cualquiera de esos intervalos se tratará como tráfico dentro del clúster y no llegará a ningún destino fuera del clúster.

En concreto, los intervalos de servicios y pods no deben solaparse con lo siguiente:

Direcciones IP de los nodos de cualquier clúster
Direcciones IP que utilizan las máquinas del balanceador de carga
IPs virtuales usadas por los nodos del plano de control y los balanceadores de carga
Dirección IP de los servidores de vCenter, los servidores DNS y los servidores NTP

Te recomendamos que uses los intervalos de direcciones IP internas definidos en RFC 1918 para tus intervalos de pods y servicios.

Este es uno de los motivos por los que se recomienda usar direcciones RFC 1918. Supongamos que el intervalo de tu pod o servicio contiene direcciones IP externas. El tráfico enviado desde un pod a una de esas direcciones externas se tratará como tráfico dentro del clúster y no llegará al destino externo.

Servidor DNS y pasarela predeterminada

Antes de crear los clústeres de administrador y de usuario, también debes conocer las direcciones IP de lo siguiente:

Un servidor DNS que puedan usar tu estación de trabajo de administrador y los nodos del clúster
Un servidor NTP que pueden usar los nodos de tu clúster
La dirección IP de la pasarela predeterminada de la subred que tiene tu estación de trabajo de administrador y los nodos del clúster. 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 pasarela predeterminada de la subred podría ser 172.16.20.1.

4. Configurar el cortafuegos y el proxy

Configura tu cortafuegos y proxy para permitir el tráfico necesario de Google Distributed Cloud siguiendo las reglas de proxy y cortafuegos. Para llevar a cabo esta tarea, necesitarás las direcciones IP de los nodos del clúster que has identificado en la sección anterior. Ten en cuenta que, como las direcciones IP de los clústeres de usuarios y administradores no se asignan a nodos específicos, debes asegurarte de que todas las reglas de cortafuegos pertinentes se apliquen a todas las direcciones IP de cada clúster.

5. Configurar recursos de Google Cloud

LosGoogle Cloud proyectos Google Cloud son la base para crear, habilitar y usar todos los servicios, incluidos los que se usan para instalar y gestionar Google Distributed Cloud. Si no sabes cómo trabajar con Google Cloud proyectos, puedes consultar mucha más información en el artículo Crear y gestionar proyectos.

Elige un Google Cloud proyecto que ya tengas o crea uno.
Anota el Google Cloud ID del proyecto, ya que lo necesitarás más adelante.

Configurar Google Cloud CLI

Google Cloud CLI es una herramienta de línea de comandos que puedes usar para trabajar con tu proyecto. Sigue las instrucciones de Instalar el SDK de Google Cloud para asegurarte de que tienes la versión más actualizada.

Permisos obligatorios

Si eres el propietario del proyecto (por ejemplo, si lo has creado tú), ya tienes todos los permisos necesarios para completar el resto de esta sencilla instalación. Si no eres el propietario del proyecto, tú o el administrador del proyecto debéis aseguraros de que tu cuenta de Google tenga los permisos necesarios.

Los siguientes roles de gestión de identidades y accesos te permiten crear una cuenta de servicio, asignarle roles de gestión de identidades y accesos, habilitar APIs y asegurarte de que la herramienta gkeadm pueda crear y gestionar cuentas de servicio por ti en la segunda parte de esta configuración:

resourcemanager.projectIamAdmin
serviceusage.serviceUsageAdmin
iam.serviceAccountCreator
iam.serviceAccountKeyAdmin

Para obtener información sobre los permisos necesarios para conceder roles de gestión de identidades y accesos, consulta el artículo Conceder, cambiar y revocar el acceso a los recursos. Si no tienes estos permisos, otra persona de tu organización debe asignarte los roles.

Para conceder los roles, 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"

Haz los cambios siguientes:

PROJECT_ID: el ID de tu Google Cloud proyecto
ACCOUNT: la dirección de correo de identificación de tu cuenta de Google

Configurar cuentas de servicio

Tu proyecto Google Cloud debe tener cuatro cuentas de servicio para que pueda usar Google Distributed Cloud. En este ejercicio, se generarán automáticamente dos de esas cuentas de servicio. Sin embargo, debes crear las otras dos cuentas de servicio manualmente:

Cuenta de servicio de conexión y registro (generada automáticamente)
Cuenta de servicio de registro y monitorización (generada 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 Google Cloud proyecto, 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. Se trata de tu 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
```
Sustituye PROJECT_ID por el ID de tuGoogle Cloud proyecto.
Obtén la dirección de correo de la cuenta de servicio de registro de auditoría que acabas de crear:
```
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
```
Sustituye SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING por la dirección de correo de tu cuenta de servicio de registro de auditoría.

No es necesario que concedas 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 Google Distributed Cloud pueda usar para descargar código de componentes de clúster en tu nombre desde Artifact Registry. Se trata de tu cuenta de servicio de acceso a componentes.
```
gcloud iam service-accounts create component-access-sa \
    --display-name "Component Access Service Account" \
    --project PROJECT_ID
```
Sustituye PROJECT_ID por el ID de tuGoogle Cloud proyecto.
Obtén la dirección de correo de la cuenta de servicio de acceso al componente que acabas de crear:
```
gcloud iam service-accounts list \
    --project PROJECT_ID
```
Crea una clave JSON para tu cuenta de servicio de acceso a componentes:
```
gcloud iam service-accounts keys create component-access-key.json \
   --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS
```
Sustituye SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS por la dirección de correo de tu cuenta de servicio de acceso a componentes.

Añade los siguientes roles de gestión de identidades y accesos a la cuenta de servicio de acceso a 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"

Habilitar las APIs de Google

Habilita las siguientes APIs de Google en tu Google Cloud proyecto. De esta forma, puedes 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 es la primera vez que habilitas la API GKE On-Prem (gkeonprem.googleapis.com) en tu proyecto, debes inicializar la API. Para ello, puedes llamar a un comando de la CLI de gcloud 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"
```
Siguientes pasos

Crear clústeres básicos

Configurar una infraestructura mínima Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.