En esta página, se explica cómo instalar GKE On-Prem en un entorno de VMware vSphere 6.5 o 6.7 actualización 3 mediante IP estáticas. También puedes instalar mediante un servidor DHCP.
Descripción general
En las instrucciones de esta página, se muestra cómo crear un clúster de administrador y un clúster de usuario con tres nodos. Después de crear los clústeres, puedes crear clústeres de usuario adicionales y agregar o quitar nodos en un clúster de usuario.
Antes de comenzar
Configura el entorno como se describe en los siguientes temas:
Crea una estación de trabajo de administrador en vSphere.
Obtén información para habilitar el balanceo de cargas manual si deseas usarlo.
Para establecer una conexión SSH a tu estación de trabajo de administrador, ejecuta lo siguiente:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
-
Si estás detrás de un proxy, todos los comandos de
gkectl
usan de forma automática el mismo proxy que se configura en elconfig.yaml
para las solicitudes de Internet de la estación de trabajo de administrador. Este es el entorno recomendado, en el que la estación de trabajo de administrador y todos los clústeres usan el mismo proxy. En este caso de uso, no necesitas establecer variables de entorno del proxy.Opciones de proxy manuales: Si la estación de trabajo de administrador no se ubica detrás del mismo proxy, debes configurar el entorno de forma manual para asegurarte de que tenga acceso a Internet. Puedes establecer la variable de entorno
HTTPS_PROXY
a fin de que entregue mediante el proxy todas las solicitudesHTTPS
, incluidos los comandos degkectl
, pero también debes configurar la variable de entornoNO_PROXY
para todas las solicitudes que deseas excluir del envío.Si también necesitas ejecutar los comandos de
gcloud
ygsutil
de forma individual, puedes configurar Google Cloud CLI para que siempre use un proxy específico. Si deseas obtener instrucciones, consulta Configura la CLI de gcloud para usarla detrás de un proxy o firewall.Usa las siguientes opciones con el fin de configurar un proxy de forma manual para los comandos de
gkectl
:- Todos los comandos de
gkectl
:Puedes usar las variables de entorno
HTTPS_PROXY
yNO_PROXY
para configurar de forma manual cómo se envían todos los comandos degkectl
mediante proxy:- Configura un proxy diferente para los comandos de
gkectl
. Por ejemplo:HTTPS_PROXY="http://my.other.proxy" NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
- Excluye los comandos de
gkectl
del proxy. Por ejemplo:HTTPS_PROXY=""
export HTTP_PROXY="http://[PROXY_ADDRESS]" export HTTPS_PROXY="http://[PROXY_ADDRESS]" export NO_PROXY="[NO_PROXY_ADDRESSES]"
En el ejemplo anterior, se ilustra lo siguiente:
- [PROXY_ADDRESS] puede estar vacío (
""
) o puede ser una dirección IP o el nombre de host del proxy. - [NO_PROXY_ADDRESSES] puede ser una lista separada por comas de URL, direcciones IP o nombres de host que deseas excluir del envío a través del proxy.
- Configura un proxy diferente para los comandos de
- Comandos de
gkectl
únicos:También puedes agregar un prefijo a un comando de
gkectl
individual con la variable de entorno a fin de usar un proxy especificado para esa única llamada.Ejemplos:
Para enviar los comandos de
gkectl
a través de un proxy que es diferente de lo que se especifica en el archivo de configuración (config.yaml
), usa la variable de entornoHTTPS_PROXY
:- Para usar el proxy
http://my.other.proxy
, haz lo siguiente:-
HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
-
HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
-
- Usa un valor vacío para excluir un proxy:
HTTPS_PROXY="" gkectl create cluster --config config.yaml
HTTPS_PROXY="" gkectl check-config --config config.yaml
- Para usar el proxy
- Todos los comandos de
Accede a Google Cloud mediante las credenciales de tu cuenta de usuario de Google Cloud. La cuenta de usuario debe tener al menos la función de visualizador de IAM:
gcloud auth login
Configura un proyecto predeterminado Configurar un proyecto predeterminado de Google Cloud hace que todos los comandos de la CLI de gcloud se ejecuten en el proyecto, de modo que no tengas que especificar el proyecto para cada comando:
gcloud config set project [PROJECT_ID]
Reemplaza
[PROJECT_ID]
por el ID del proyecto. (Puedes encontrar el ID del proyecto en Cloud Console o mediante la ejecución degcloud config get-value project
).
Selecciona un registro de imágenes de contenedor para la instalación
Para la instalación, GKE On-Prem necesita saber dónde extraer sus componentes de clústeres en contenedores. Tienes estas dos opciones:
Container Registry
De forma predeterminada, GKE On-Prem usa un registro de imágenes de contenedor existente de Google, que Container Registry aloja.
Además de configurar tu proxy con el fin de permitir el tráfico desde gcr.io
, no se requiere una configuración adicional para esto.
Registro privado de Docker
Puedes optar por usar un registro privado de Docker para la instalación. GKE On-Prem envía los componentes de clústeres a ese registro de Docker. Para especificar un registro privado de Docker, establece el campo privateregistryconfig
.
Configura un registro privado de Docker para la instalación (opcional)
En esta sección, se explica cómo configurar un registro de Docker existente para instalar GKE On-Prem. Para obtener información sobre cómo crear un registro de Docker, consulta Ejecuta un registro accesible de forma externa.
Después de configurar el registro, debes propagar el campo privateregistryconfig
del archivo de configuración de GKE On-Prem.
Si deseas usar el registro privado de Docker para la instalación, la VM de la estación de trabajo de administrador debe confiar en la CA que firmó el certificado. GKE On-Prem no es compatible con los registros de Docker sin protección. Cuando inicias el registro de Docker, debes proporcionar un certificado y una clave. Una autoridad certificada (CA) pública puede firmar el certificado, o este se puede autofirmar.
Para establecer esta confianza, debes realizar los siguientes pasos desde la VM de la estación de trabajo de administrador:
Crea una carpeta para contener el certificado:
sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
En el comando anterior, [REGISTRY_SERVER] es la dirección IP o el nombre de host de la VM que ejecuta tu registro de Docker.
Copia el archivo de certificado en
/etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt
. Debes asignar el nombreca.crt
al archivo, incluso si tenía un nombre diferente.Reinicia el servicio de Docker:
sudo service docker restart
Verifica que puedas acceder a Docker:
docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]
En el comando anterior, [USERNAME] y [PASSWORD] son las credenciales para acceder al registro de Docker.
Ahora, cuando ejecutes gkectl prepare
durante la instalación, las imágenes necesarias para la instalación se enviarán al registro de Docker.
Soluciona problemas de la configuración de registros
GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
: Asegúrate de tener la dirección IP correcta para la VM que ejecuta el registro de Docker.login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized
: Asegúrate de que el nombre de usuario y la contraseña sean correctos.GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority
: La VM de la estación de trabajo de administrador no confía en el certificado.
Configura direcciones IP estáticas
Si deseas usar direcciones IP estáticas, debes crear dos archivos de configuración de host: uno para el clúster de administrador y otro para el clúster de usuario. Los archivos de configuración de host le indican a GKE On-Prem las direcciones IP y los nombres de host que deben asignarse a los nodos del clúster.
Direcciones IP estáticas para el clúster de administrador
El clúster de administrador necesita direcciones para los siguientes nodos:
- Un nodo para el plano de control del clúster de administrador
- Dos nodos para los complementos del clúster de administrador
- Un nodo temporal ocasional durante una actualización del clúster de administrador
- Uno o tres nodos para cada clúster de usuario asociado
En el caso de un clúster de usuario con alta disponibilidad (HA), el clúster de administrador tiene tres nodos que ejecutan los componentes del plano de control para el clúster de usuario. En un clúster de usuario sin alta disponibilidad, el clúster de administrador tiene un nodo que ejecuta los componentes del plano de control para el clúster de usuario.
Supongamos que N es la cantidad de clústeres de usuario sin alta disponibilidad que deseas crear y H es la cantidad de clústeres de usuario con alta disponibilidad que deseas crear. Luego, en el archivo de configuración de host para el clúster de administrador, debes especificar al menos esta cantidad de direcciones IP:
4 + N + 3 x H
Por ejemplo, supongamos que deseas crear un clúster de administrador y un clúster de usuario con alta disponibilidad. Deberás reservar siete direcciones IP para el clúster de administrador. A continuación, se muestra un ejemplo de un archivo de configuración de host de administrador que especifica siete direcciones IP:
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7
Como puedes ver en el ejemplo anterior, un archivo de configuración de host contiene una estructura de datos YAML.
El campo ips
es un arreglo de direcciones IP y nombres de host. Son las direcciones IP y los nombres de host que GKE On-Prem asignará a los nodos del clúster de administrador.
En el archivo de configuración de host, también debes especificar las direcciones de los servidores DNS, los servidores de tiempo y la puerta de enlace predeterminada que usarán los nodos del clúster de administrador.
Direcciones IP estáticas para un clúster de usuario
Un clúster de usuario necesita una dirección IP por cada nodo y una dirección IP adicional que se usará para un nodo temporal durante una actualización del clúster de usuario.
Por ejemplo, imagina que deseas crear un clúster de usuario que tenga cinco nodos. Luego, deberías reservar seis direcciones IP para el clúster de usuario. Este es un ejemplo de un archivo de configuración de host de usuario que especifica seis pares de IP y nombres de host.
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.17 hostname: user-host1 - ip: 172.16.20.18 hostname: user-host2 - ip: 172.16.20.19 hostname: user-host3 - ip: 172.16.20.20 hostname: user-host4 - ip: 172.16.20.21 hostname: user-host5 - ip: 172.16.20.22 hostname: user-host6
Cada hostname
se interpreta como un nombre de host local sin su dominio. Si especificas un nombre de dominio completamente calificado, se recortará el dominio. Por ejemplo, host1.enterprise.net
se convierte en host1
. El valor de un campo hostname
debe estar en minúscula.
Crea claves privadas de cuentas de servicio en la estación de trabajo de administrador
En Prepara la instalación, creaste cuatro cuentas de servicio. Ahora, debes crear un archivo de claves privadas JSON para cada una de esas cuentas de servicio. Proporcionarás estas claves durante la instalación.
Enumera las direcciones de correo electrónico de las cuentas de servicio
Primero, enumera las cuentas de servicio en el proyecto de Google Cloud:
gcloud iam service-accounts list
En un proyecto de Google Cloud llamado my-gcp-project
, el resultado de este comando se verá así:
gcloud iam service-accounts list ... EMAIL allowlisted-service-account@my-gcp-project.iam.gserviceaccount.com connect-register-service-account@my-gcp-project.iam.gserviceaccount.com connect-agent-service-account@my-gcp-project.iam.gserviceaccount.com log-mon-service-account@my-gcp-project.iam.gserviceaccount.com
Toma nota de la dirección de correo electrónico de cada cuenta. En cada una de las siguientes secciones, debes proporcionar la cuenta de correo electrónico de la cuenta correspondiente.
Cuenta de servicio incluida en la lista de anunciantes permitidos
gcloud iam service-accounts keys create whitelisted-key.json --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
En el ejemplo anterior, [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio incluida en la lista de anunciantes permitidos.
Cuenta de servicio de registro
gcloud iam service-accounts keys create register-key.json \ --iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]
En el comando anterior, [REGISTER_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio de registro.
Cuenta de servicio de Connect
gcloud iam service-accounts keys create connect-key.json \ --iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]
En el comando anterior, [CONNECT_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio de Connect.
Cuenta de servicio de Cloud Monitoring
gcloud iam service-accounts keys create stackdriver-key.json \ --iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]
En el comando anterior, [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio de Cloud Monitoring.
Genera un archivo de configuración
Para iniciar una instalación, debes ejecutar gkectl create-config
a fin de generar un archivo de configuración. Debes modificar el archivo con las especificaciones de tu entorno y con las especificaciones del clúster que desees.
Si deseas generar el archivo, ejecuta el siguiente comando, en el que --config [PATH]
es opcional y acepta una ruta de acceso y un nombre para el archivo de configuración. Si se omite --config
, se crea config.yaml
en el directorio de trabajo actual:
gkectl create-config [--config [PATH]]
Modifica el archivo de configuración
Ahora que generaste el archivo de configuración, debes modificarlo a fin de que sea adecuado para el entorno y para satisfacer tus expectativas con respecto a los clústeres. En las siguientes secciones, se explica cada campo, sus valores previstos y dónde puedes encontrar la información. Algunos campos están comentados de forma predeterminada. Si alguno de esos campos es relevante para la instalación, quita los comentarios y proporciona valores.
En las instrucciones de esta sección, se muestra cómo usar un solo comando que crea un clúster de administrador y uno de usuario. A partir de la versión 1.2, puedes crear los clústeres de administrador y de usuario por separado.
bundlepath
El archivo de paquete de GKE On-Prem contiene todos los componentes de una versión particular de GKE On-Prem.
Cuando creas una estación de trabajo de administrador, se incluye un paquete completo en /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
. La versión de este paquete coincide con la versión de OVA que importaste para crear la estación de trabajo de administrador.
Establece el valor de bundlepath
en la ruta del archivo de paquete de la estación de trabajo de administrador. Es decir, configura bundlepath
de la siguiente manera:
/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
En el ejemplo anterior, [VERSION] es la versión de GKE On-Prem que instalas. La versión más reciente es 1.3.2-gke.1.
Ten en cuenta que puedes mantener el archivo de paquete en una ubicación diferente o asignarle un nombre distinto. Solo asegúrate de que, en el archivo de configuración, el valor de bundlepath
sea la ruta de acceso al archivo de paquete, sin importar cuál sea.
Especificación de vCenter
La especificación de vcenter
conserva la información sobre tu instancia de vCenter Server.
GKE On-Prem necesita esta información para comunicarse con vCenter Server.
vcenter.credentials.address
En el campo vcenter.credentials.address
, se encuentra la dirección IP o el nombre de host de vCenter Server.
Antes de completar vsphere.credentials.address field
, descarga e inspecciona el certificado de entrega de vCenter Server. Ingresa el siguiente comando para descargar el certificado y guardarlo en un archivo llamado vcenter.pem
.
true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Abre el archivo del certificado para ver el nombre común y el alternativo de la entidad:
openssl x509 -in vcenter.pem -text -noout
En el resultado, se muestra el nombre común (CN) de Subject
. Este puede ser una dirección IP o un nombre de host. Por ejemplo:
Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example
Puede que, en el resultado, también se incluyan uno o más nombres de DNS en Subject Alternative Name
:
X509v3 Subject Alternative Name: DNS:vcenter.my-domain.example
Elige el nombre común de Subject
o uno de los nombres de DNS en Subject Alternative Name
para usarlo como el valor de vcenter.credentials.address
en el archivo de configuración. Por ejemplo:
vcenter: credentials: address: "203.0.113.1" ...
vcenter: credentials: address: "my-host.my-domain.example" ...
Debes elegir un valor que aparezca en el certificado. Por ejemplo, si la dirección IP no aparece en el certificado, no puedes usarla para vcenter.credentials.address
.
vcenter.credentials
GKE On-Prem necesita conocer tu nombre de usuario y la contraseña de vCenter Server. Para proporcionar esta información, establece los valores username
y password
en vcenter.credentials
. Por ejemplo:
vcenter: credentials: ... username: "my-name" password: "my-password"
vcenter.datacenter, .datastore, .cluster, .network
GKE On-Prem necesita información sobre la estructura del entorno de vSphere. Establece los valores en vcenter
para proporcionar esta información.
Por ejemplo:
vcenter: ... datacenter: "MY-DATACENTER" datastore: "MY-DATASTORE" cluster: "MY-VSPHERE-CLUSTER" network: "MY-VIRTUAL-NETWORK"
vcenter.resourcepool
Un grupo de recursos de vSphere es una agrupación lógica de VM de vSphere en el clúster de vSphere. Si usas un grupo de recursos que no es el predeterminado, proporciona su nombre a vcenter.resourcepool
. Por ejemplo:
vcenter: ... resourcepool: "my-pool"
Si deseas que GKE On-Prem implemente sus nodos en el grupo de recursos predeterminado del clúster de vSphere, proporciona una string vacía a vcenter.resourcepool
. Por ejemplo:
vcenter: ... resourcepool: ""
vcenter.datadisk
GKE On-Prem crea un disco de máquina virtual (VMDK) para contener los datos del objeto de Kubernetes del clúster de administrador. El instalador crea el VMDK por ti, pero debes proporcionar un nombre para él en el campo vcenter.datadisk
.
Por ejemplo:
vcenter: ... datadisk: "my-disk.vmdk"
- Almacén de datos de vSAN: Crea una carpeta para el VMDK
Si usas un almacén de datos de vSAN, debes colocar el VMDK en una carpeta. Debes crear la carpeta de forma manual con anticipación. Para crear la carpeta, puedes usar
govc
:govc datastore.mkdir -namespace=true my-gke-on-prem-folder
Luego, establece
vcenter.datadisk
en la ruta de acceso del VMDK e incluye la carpeta. Por ejemplo:vcenter: ... datadisk: "my-gke-on-prem-folder/my-disk.vmdk"
En la versión 1.1.1 y en versiones anteriores, un problema conocido requiere que proporciones la ruta de acceso del identificador único universal (UUID) de la carpeta, en lugar de la ruta de acceso del archivo, a
vcenter.datadisk
. Copia esto del resultado del comando degovc
que se mostró antes.Luego, proporciona el UUID de la carpeta en el campo
vcenter.datadisk
. No coloques una barra diagonal delante del UUID. Por ejemplo:vcenter: ... datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
Este problema se solucionó en las versiones 1.1.2 y posteriores.
vcenter.cacertpath
Cuando un cliente, como GKE On-Prem, envía una solicitud a vCenter Server, el servidor debe demostrar su identidad al cliente mediante la presentación de un certificado o un paquete de certificados. Para verificar el certificado o el paquete, GKE On-Prem debe tener el certificado raíz en la cadena de confianza.
Establece vcenter.cacertpath
en la ruta de acceso del certificado raíz. Por ejemplo:
vcenter: ... cacertpath: "/my-cert-folder/the-root.crt"
Tu instalación de VMware tiene una autoridad certificada (CA) que emite un certificado para vCenter Server. El certificado raíz de la cadena de confianza es un certificado autofirmado que crea VMware.
Si no deseas usar la CA de VMware, que es la opción predeterminada, puedes configurar VMware para usar una autoridad certificada diferente.
Si vCenter Server usa un certificado emitido por la CA predeterminada de VMware, existen varias formas de obtener el certificado raíz:
curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip
En el comando anterior, [SERVER_ADDRESS] es la dirección de vCenter Server.
En un navegador, ingresa la dirección de vCenter Server. En el cuadro gris a la derecha, haz clic en Download trusted root CA certificates.
Ingresa este comando para obtener el certificado de entrega:
true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts
En el resultado, busca una URL como la siguiente: https://[SERVER_ADDRESS]/afd/vecs/ca. Ingresa la URL en un navegador. Mediante esta acción, se descarga el certificado raíz.
El archivo descargado se llama downloads.zip
.
Descomprime el archivo:
unzip downloads.zip
Si el comando de descompresión no funciona la primera vez, vuelve a ingresarlo.
Busca el archivo del certificado en certs/lin
.
Especificación del proxy
Si la red se encuentra detrás de un servidor proxy, propaga el campo proxy
con proxy HTTPS y las direcciones que se deben excluir del envío de solicitudes mediante proxy. Por ejemplo:
proxy: url: "https://username:password@domain" noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"
proxy.url
es la URL del proxy HTTPS.proxy.noproxy
incluye los rangos de CIDR, las direcciones IP, los dominios y los nombres de host que no se deben enviar mediante proxy. Por ejemplo, las llamadas a las direcciones IP de los nodos del clúster no se deben enviar mediante proxy. Por lo tanto, si tienes una subred que contiene solo nodos de clústeres, puedes enumerar el rango de CIDR de la subred en el camponoproxy
. Ten en cuenta que si se especificaprivateregistryconfig
, esa dirección se agrega de forma automática para evitar llamadas al registro privado.
Especificación del clúster de administrador
La especificación admincluster
contiene información que GKE On-Prem necesita para crear el clúster de administrador.
admincluster.vcenter.network
En admincluster.vcenter.network
, puedes especificar una red de vCenter para los nodos del clúster de administrador. Ten en cuenta que esto anula la configuración global que proporcionaste en vcenter
. Por ejemplo:
admincluster: vcenter: network: MY-ADMIN-CLUSTER-NETWORK
admincluster.ipblockfilepath
Dado que usas direcciones IP estáticas, debes tener un archivo de configuración de host, como se describe en Configura IP estáticas. Proporciona la ruta de acceso al archivo de configuración de host en el campo admincluster.ipblockfilepath
. Por ejemplo:
admincluster: ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"
admincluster.manuallbspec (modo de balanceo de cargas manual)
El controlador de entrada en el clúster de administrador se implementa como un Service de tipo NodePort.
El Service tiene un ServicePort para HTTP y otro para HTTPS. Si usas el modo de balanceo de cargas manual, debes elegir los valores de nodePort
para estos ServicePorts.
Especifica los valores nodePort
en ingresshttpnodeport
y ingresshttpsnodeport
. Por ejemplo:
admincluster: ... manuallbspec: ingresshttpnodeport: 32527 ingresshttpsnodeport: 30139
El servidor de la API de Kubernetes en el clúster de administrador se implementa como un Service de tipo NodePort
. Si usas el balanceo de cargas manual, debes elegir un valor de nodePort
para el Service. Especifica el valor de nodePort
en controlplanenodeport
. Por ejemplo:
admincluster: ... manuallbspec: ... controlplanenodeport: 30968
El servidor de complementos en el clúster de administrador se implementa como un Service de tipo NodePort
. Si usas el balanceo de cargas manual, debes elegir un valor de nodePort
para el Service. Especifica el valor de nodePort
en controlplanenodeport
. Por ejemplo:
admincluster: manuallbspec: ... addonsnodeport: 30562
admincluster.bigip.credentials (modo de balanceo de cargas integrado)
Si no usas el modo de balanceo de cargas integrado, deja admincluster.bigip
inhabilitado.
Si usas el modo de balanceo de cargas integrado, GKE On-Prem necesita conocer la dirección IP o el nombre de host, el nombre de usuario y la contraseña de tu balanceador de cargas BIG-IP de F5. Establece los valores en admincluster.bigip
para proporcionar esta información.
Por ejemplo:
admincluster: ... bigip: credentials: address: "203.0.113.2" username: "my-admin-f5-name" password: "rJDlm^%7aOzw"
admincluster.bigip.partition (modo de balanceo de cargas integrado)
Si usas el modo de balanceo de cargas integrado, debes crear una partición de BIG-IP para el clúster de administrador. Establece admincluster.bigip.partition
en el nombre de la partición. Por ejemplo:
admincluster: ... bigip: partition: "my-admin-f5-partition"
admincluster.vips
Sin importar si usas el balanceo de cargas integrado o manual para el clúster de administrador, debes completar el campo admincluster.vips
.
Establece el valor de admincluster.vips.controlplanevip
en la dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de administrador. Establece el valor de ingressvip
como la dirección IP que elegiste configurar en el balanceador de cargas para el controlador de entrada del clúster de administrador. Por ejemplo:
admincluster: ... vips: controlplanevip: 203.0.113.3 ingressvip: 203.0.113.4
admincluster.serviceiprange y admincluster.podiprange
El clúster de administrador debe tener un rango de direcciones IP para usar con los Services y uno para usar con los Pods. Estos rangos se especifican en los campos admincluster.serviceiprange
y admincluster.podiprange
. Estos campos se propagan cuando ejecutas gkectl create-config
. Si quieres, puedes cambiar los valores propagados por los valores que desees.
Los rangos de Services y Pods no deben superponerse. Tampoco deben superponerse en ningún clúster con las direcciones IP que se usan para los nodos.
Ejemplo:
admincluster: ... serviceiprange: 10.96.232.0/24 podiprange: 192.168.0.0/16
Especificación del clúster de usuario
La especificación del clúster de usuario, usercluster
, contiene información que GKE On-Prem necesita para crear el clúster de usuario inicial.
Inhabilita las reglas de antiafinidad de DRS de VMware (opcional)
GKE On-Prem crea de forma automática reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos del clúster de usuario, de modo que se distribuyen en al menos tres hosts físicos del centro de datos.
Para esta función, se requiere que el entorno de vSphere cumpla con las siguientes condiciones:
- DRS de VMware debe estar habilitado. Para DRS de VMware, se requiere la edición de licencia vSphere Enterprise Plus. Para aprender a habilitar DRS, consulta Enabling VMware DRS in a cluster (Habilita DRS de VMware en un clúster).
- La cuenta de usuario de vSphere proporcionada en el campo
vcenter
debe tener el permisoHost.Inventory.EditCluster
. - Debe haber al menos tres hosts físicos disponibles.
Recuerda que si tienes una licencia de vSphere Standard, no puedes habilitar DRS de VMware.
Si no tienes habilitado DRS, o si no tienes un mínimo de tres hosts en los que se puedan programar las VM de vSphere, agrega usercluster.antiaffinitygroups.enabled: false
al archivo de configuración.
Por ejemplo:
usercluster: ... antiaffinitygroups: enabled: false
Para obtener más información, consulta las notas de la versión 1.1.0-gke.6.
- En el caso de los clústeres que ejecutan más de tres nodos, sucede lo siguiente:
- Si vSphere vMotion transfiere un nodo a un host diferente, las cargas de trabajo del nodo se deberán reiniciar antes de que se distribuyan de nuevo en los hosts.
usercluster.vcenter.network
En usercluster.vcenter.network
, puedes especificar una red de vCenter para los nodos del clúster de usuario. Ten en cuenta que esto anula la configuración global que proporcionaste en vcenter
. Por ejemplo:
usercluster: vcenter: network: MY-USER-CLUSTER-NETWORK
usercluster.ipblockfilepath
Dado que usas direcciones IP estáticas, debes tener un archivo de configuración de host como se describe en Configura IP estáticas.
Proporciona la ruta de acceso al archivo de configuración de host en el campo usercluster.ipblockfilepath
. Por ejemplo:
usercluster: ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"
usercluster.manuallbspec
(modo de balanceo de cargas manual)
El controlador de entrada en el clúster de usuario se implementa como un Service de tipo NodePort.
El Service tiene un ServicePort para HTTP y otro para HTTPS. Si usas el modo de balanceo de cargas manual, debes elegir los valores de nodePort
para estos ServicePorts.
Especifica los valores nodePort
en ingresshttpnodeport
y ingresshttpsnodeport
. Por ejemplo:
usercluster: manuallbspec: ingresshttpnodeport: 30243 ingresshttpsnodeport: 30879
El servidor de la API de Kubernetes en el clúster de usuario se implementa como un Service de tipo NodePort
. Si usas el balanceo de cargas manual, debes elegir un valor de nodePort
para el Service. Especifica el valor de nodePort
en controlplanenodeport
. Por ejemplo:
usercluster: ... manuallbspec: ... controlplanenodeport: 30562
usercluster.bigip.credentials
(modo de balanceo de cargas integrado)
Si usas el modo de balanceo de cargas integrado, GKE On-Prem debe conocer la dirección IP o el nombre de host, el nombre de usuario y la contraseña del balanceador de cargas BIG-IP de F5 que deseas usar para el clúster de usuario. Establece los valores en usercluster.bigip
para proporcionar esta información.
Por ejemplo:
usercluster: ... bigip: credentials: address: "203.0.113.5" username: "my-user-f5-name" password: "8%jfQATKO$#z" ...
usercluster.bigip.partition
(modo de balanceo de cargas integrado)
Si usas el modo de balanceo de cargas integrado, debes crear una partición de BIG-IP para el clúster de usuario. Establece usercluster.bigip.partition
en el nombre de la partición. Por ejemplo:
usercluster: ... bigip: partition: "my-user-f5-partition" ...
usercluster.vips
Sin importar si usas el balanceo de cargas integrado o manual para el clúster de usuario, debes completar el campo usercluster.vips
.
Establece el valor de usercluster.vips.controlplanevip
como la dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario. Establece el valor de ingressvip
como la dirección IP que elegiste configurar en el balanceador de cargas para el controlador de entrada del clúster de usuario. Por ejemplo:
usercluster: ... vips: controlplanevip: 203.0.113.6 ingressvip: 203.0.113.7
usercluster.serviceiprange
y usercluster.podiprange
El clúster de usuario debe tener un rango de direcciones IP para usar con los Services y uno para usar con los Pods. Estos rangos se especifican en los campos usercluster.serviceiprange
y usercluster.podiprange
. Estos campos se propagan cuando ejecutas gkectl create-config
. Si quieres, puedes cambiar los valores propagados por los valores que desees.
Los rangos de Services y Pods no deben superponerse. Tampoco deben superponerse en ningún clúster con las direcciones IP que se usan para los nodos.
Ejemplo:
usercluster: ... serviceiprange: 10.96.233.0/24 podiprange: 172.16.0.0/12
usercluster.clustername
Establece el valor de usercluster.clustername
en el nombre que desees. Elige un nombre que no supere los 40 caracteres. Por ejemplo:
usercluster: ... clustername: "my-user-cluster-1"
usercluster.masternode.replicas
En el campo usercluster.masternode.replicas
, se especifica cuántos nodos del plano de control quieres que tenga el clúster de usuario. Un nodo de plano de control de un clúster de usuario ejecuta el plano de control de usuario, los componentes del plano de control de Kubernetes. Este valor debe ser 1
o 3
:
- Establece este campo en
1
para ejecutar un plano de control de usuario. - Establece este campo en
3
si deseas tener un plano de control de usuario con alta disponibilidad (HA) compuesto por tres nodos de plano de control y que cada uno ejecute un plano de control del usuario.
usercluster.masternode.cpus
y usercluster.masternode.memorymb
Los campos usercluster.masternode.cpus
y usercluster.masternode.memorymb
especifican la cantidad de CPU y de memoria (en megabytes) que se asigna a cada nodo de plano de control del clúster de usuario. Por ejemplo:
usercluster: ... masternode: cpus: 4 memorymb: 8192
usercluster.workernode.replicas
En el campo usercluster.workernode.replicas
, se especifica la cantidad de nodos trabajadores que quieres que tenga el clúster de usuario. Los nodos trabajadores ejecutan las cargas de trabajo del clúster.
usercluster.workernode.cpus
y usercluster.workernode.memorymb
Los campos usercluster.masternode.cpus
y usercluster.masternode.memorymb
especifican la cantidad de CPU y de memoria (en megabytes) que se asigna a cada nodo trabajador del clúster de usuario. Por ejemplo:
usercluster: ... workernode: cpus: 4 memorymb: 8192 replicas: 3
usercluster.oidc
Si deseas que los clientes del clúster de usuario usen la autenticación de OIDC, establece valores para los campos en usercluster.oidc
. La configuración de OIDC es opcional.
Para aprender a configurar OIDC, consulta Autentica con OIDC.
- Información acerca de la instalación de la versión 1.0.2-gke.3
La versión 1.0.2-gke.3 presenta los siguientes campos de OIDC (
usercluster.oidc
). Estos campos permiten acceder a un clúster desde la consola de Cloud:- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
En la versión 1.0.2-gke.3, si deseas usar OIDC, el campo
clientsecret
es obligatorio incluso si no quieres acceder a un clúster desde la consola de Cloud. En ese caso, puedes proporcionar un valor de marcador de posición paraclientsecret
:oidc: clientsecret: "secret"
usercluster.sni
La indicación del nombre del servidor (SNI), una extensión de la seguridad de la capa de transporte (TLS), permite que los servidores presenten varios certificados en una sola dirección IP y un solo puerto TCP, en función del nombre de host que indique el cliente.
Si la CA ya está distribuida como una CA de confianza para los clientes fuera del clúster de usuario y deseas confiar en esta cadena a fin de identificar clústeres de confianza, puedes configurar el servidor de la API de Kubernetes con un certificado adicional que se presenta a los clientes externos de la dirección IP del balanceador de cargas.
Para usar la SNI con los clústeres de usuario, debes tener tu propia CA y una infraestructura de clave pública (PKI). Debes aprovisionar un certificado de entrega diferente para cada clúster de usuario, y GKE On-Prem agrega cada certificado de entrega adicional a su clúster de usuario respectivo.
Si deseas configurar la SNI en el servidor de la API de Kubernetes del clúster de usuario, proporciona valores para usercluster.sni.certpath
(la ruta al certificado externo) y usercluster.sni.keypath
(la ruta al archivo de claves privadas del certificado externo).
Por ejemplo:
usercluster: ... sni: certpath: "/my-cert-folder/example.com.crt" keypath: "/my-cert-folder/example.com.key"
lbmode
Puedes usar el balanceo de cargas integrado o el balanceo de cargas manual. La elección del modo de balanceo de cargas se aplica al clúster de administrador y al clúster de usuario inicial. También se aplica a cualquier clúster de usuario adicional que crees en el futuro.
Establece el valor de lbmode
en Integrated
o Manual
para especificar la opción de balanceo de cargas. Por ejemplo:
lbmode: Integrated
gkeconnect
La especificación de gkeconnect
contiene información que GKE On-Prem necesita para configurar la administración de los clústeres locales desde la consola de Google Cloud.
Establece gkeconnect.projectid
en el ID del proyecto de Google Cloud en el que deseas administrar los clústeres locales.
Establece el valor de gkeconnect.registerserviceaccountkeypath
en la ruta de acceso del archivo de claves JSON para tu cuenta de servicio de registro.
Establece el valor de gkeconnect.agentserviceaccountkeypath
en la ruta de acceso del archivo de claves JSON para la cuenta de servicio de conexión.
Ejemplo:
gkeconnect: projectid: "my-project" registerserviceaccountkeypath: "/my-key-folder/register-key.json" agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
stackdriver
La especificación de stackdriver
contiene información que GKE On-Prem necesita para almacenar las entradas de registro que generan los clústeres locales.
Establece stackdriver.projectid
en el ID del proyecto de Google Cloud en el que deseas ver los registros de Stackdriver que pertenecen a los clústeres locales.
Establece stackdriver.clusterlocation
en una región de Google Cloud en la que quieras almacenar registros de Stackdriver. Te recomendamos que elijas una región cercana a tu centro de datos local.
Establece stackdriver.enablevpc
en true
si tienes la red del clúster bajo el control de una VPC. Esto garantiza que toda la telemetría fluya a través de las direcciones IP restringidas de Google.
Establece stackdriver.serviceaccountkeypath
en la ruta del archivo de claves JSON de tu cuenta de servicio de Stackdriver Logging.
Ejemplo:
stackdriver: projectid: "my-project" clusterlocation: "us-west1" enablevpc: false serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"
privateregistryconfig
Si tienes un registro privado de Docker, el campo privateregistryconfig
contiene información que GKE On-Prem usa para enviar imágenes al registro privado. Si no especificas un registro privado, gkectl
extrae las imágenes de contenedor de GKE On-Prem de su repositorio de Container Registry, gcr.io/gke-on-prem-release
, durante la instalación.
En privatedockerregistry.credentials
, establece address
en la dirección IP de la máquina que ejecuta el registro privado de Docker. Establece username
y password
en el nombre de usuario y la contraseña del registro privado de Docker. El valor que estableces para address
se agrega de forma automática a proxy.noproxy
.
Cuando Docker extrae una imagen del registro privado, el registro debe demostrar su identidad mediante la presentación de un certificado. El certificado del registro está firmado por una autoridad certificada (CA). Docker usa el certificado de la CA para validar el certificado del registro.
Establece privateregistryconfig.cacertpath
en la ruta del certificado de la CA. Por ejemplo:
privateregistryconfig ... cacertpath: /my-cert-folder/registry-ca.crt
gcrkeypath
Establece el valor de gcrkeypath
como la ruta de acceso del archivo de claves JSON para la cuenta de servicio incluida en la lista de anunciantes permitidos.
Por ejemplo:
gcrkeypath: "/my-key-folder/whitelisted-key.json"
cloudauditlogging
Si deseas enviar los registros de auditoría de Kubernetes al proyecto de Google Cloud, propaga la especificación de cloudauditlogging
. Por ejemplo:
cloudauditlogging: projectid: "my-project" # A GCP region where you would like to store audit logs for this cluster. clusterlocation: "us-west1" # The absolute or relative path to the key file for a GCP service account used to # send audit logs from the cluster serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"
Obtén más información para usar el registro de auditoría.
Valida el archivo de configuración
Completa este paso desde la estación de trabajo de administrador.
Después de modificar el archivo de configuración, ejecuta gkectl check-config
a fin de verificar que el archivo sea válido y se pueda usar para la instalación:
gkectl check-config --config [PATH_TO_CONFIG] --fast
Si el comando muestra algún mensaje de FAILURE
, soluciona los problemas y vuelve a validar el archivo. Usa la marca --fast
para omitir las verificaciones que crean VM de prueba, lo que depende de la imagen de SO del nodo que gkectl prepare
sube desde la estación de trabajo de administrador a vCenter.
Omite las validaciones
Los siguientes comandos de gkectl
ejecutan validaciones de forma automática en el archivo de configuración:
gkectl prepare
gkectl create cluster
gkectl upgrade
Para omitir las validaciones de un comando, pasa --skip-validation-all
. Por ejemplo, para omitir todas las validaciones de gkectl prepare
, usa lo siguiente:
gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all
Si deseas ver todas las marcas disponibles para omitir validaciones específicas, sigue estos pasos:
gkectl check-config --help
Ejecuta gkectl prepare
Antes de realizar la instalación, debes ejecutar gkectl prepare
en la estación de trabajo de administrador para inicializar el entorno de vSphere. gkectl prepare
realiza las siguientes tareas:
Importa la imagen de SO del nodo a vSphere y la marca como plantilla.
Si usas un registro privado de Docker, envía imágenes de GKE On-Prem al registro.
De manera opcional, valida las certificaciones de compilación de las imágenes de contenedor a fin de verificar que las imágenes hayan sido compiladas y firmadas por Google y que estén listas para la implementación.
Ejecuta gkectl prepare
con el archivo de configuración de GKE On-Prem, en el que --validate-attestations
es opcional:
gkectl prepare --config [CONFIG_FILE] --validate-attestations
El resultado positivo de --validate-attestations
es Image [IMAGE_NAME] validated
.
Vuelve a validar el archivo de configuración
Después de subir la imagen de SO del nodo mediante la ejecución de gkectl prepare
, ejecuta gkectl check-config
sin la marca --fast
para que se puedan ejecutar verificaciones adicionales que creen VM de prueba.
gkectl check-config --config [PATH_TO_CONFIG]
Si el comando muestra algún mensaje de FAILURE
, soluciona los problemas y vuelve a validar el archivo.
Instala GKE On-Prem
Creaste un archivo de configuración en el que se especifica cómo se ve el entorno y cómo deseas que se vean los clústeres y, además, validaste el archivo. Ejecutaste gkectl prepare
para inicializar el entorno con el software de GKE On-Prem. Ahora estás listo para iniciar una instalación nueva de GKE On-Prem.
Para instalar GKE On-Prem, crea los clústeres de administrador y usuario. En los siguientes pasos, se indica cómo crear el clúster de administrador y el de usuario durante el mismo proceso. Si deseas crear cada clúster por separado, consulta Crea clústeres de administrador y de usuario por separado para obtener más información.
Para crear los clústeres de administrador y de usuario, haz lo siguiente:
Crea el clúster de administrador y de usuario mediante la ejecución del comando
gkectl create cluster
.gkectl create cluster --config [CONFIG_FILE]
En el ejemplo anterior, [CONFIG_FILE] es el archivo de configuración que creaste antes.
El comando
gkectl create cluster
crea archivoskubeconfig
llamados[CLUSTER_NAME]-kubeconfig
en el directorio actual, en el que [CLUSTER_NAME] es el nombre que estableciste paracluster
. Por ejemplo:MY-VSPHERE-CLUSTER-kubeconfig
En la documentación de GKE On-Prem, se usan los siguientes marcadores de posición para hacer referencia a estos archivos
kubeconfig
:- Clúster de administrador: [ADMIN_CLUSTER_KUBECONFIG]
- Clúster de usuario: [USER_CLUSTER_KUBECONFIG]
Verifica que el clúster esté creado y en ejecución:
Para verificar el clúster de administrador, ejecuta el siguiente comando:
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
En el resultado, se muestran los nodos del clúster de administrador.
Para verificar el clúster de usuario, ejecuta el siguiente comando:
kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]
En el resultado, se muestran los nodos del clúster de usuario. Por ejemplo:
NAME STATUS ROLES AGE VERSION xxxxxx-1234-ipam-15008527 Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-1500852a Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-15008536 Ready <none> 12m v1.14.7-gke.24
Obtén más información sobre cómo volver a usar el archivo de configuración para crear clústeres de usuario adicionales.
Reanuda una instalación
Si la instalación se interrumpe después de crear el clúster de administrador, puedes reanudarla mediante los siguientes pasos:
- Quita la especificación
admincluster
del archivo de configuración. Ejecuta
gkectl create cluster
con las marcas--kubeconfig
y--skip-validation-all
para pasar el archivo kubeconfig del clúster de administrador y omitir las verificaciones previas:gkectl create cluster \ --config [CONFIG_FILE] \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --skip-validation-all
En el ejemplo anterior, [ADMIN_CLUSTER_NAME] es el kubeconfig del clúster de administrador, que se creó en el directorio de trabajo cuando comenzaste la instalación.
Conecta clústeres a Google
Cuando propagas la especificación
gkeconnect
, el clúster de usuario se registra de forma automática con la consola de Cloud. Puedes ver un clúster de GKE On-Prem registrado en el menú de clústeres de Kubernetes de la consola de Cloud. Desde allí, puedes acceder al clúster para ver sus cargas de trabajo.Si no ves tu clúster en la consola de Cloud en un plazo de una hora a partir de su creación, consulta Soluciona problemas de Connect.
Habilitar Ingress
Después de que el clúster de usuario se ejecute, debes habilitar el tráfico de entrada mediante la creación de un objeto Gateway. La primera parte del manifiesto de Gateway siempre es la siguiente:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system
Puedes adaptar el resto del manifiesto según tus necesidades. Por ejemplo, este manifiesto indica que los clientes pueden enviar solicitudes en el puerto 80 mediante el protocolo HTTP/2 y cualquier nombre de host:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*"
Si deseas aceptar solicitudes HTTPS, debes proporcionar uno o más certificados que el controlador de entrada pueda presentar a los clientes.
Para proporcionar un certificado, sigue estos pasos:
- Crea un Secreto que contenga el certificado y la clave.
- Crea un objeto Gateway o modifica uno existente que haga referencia al Secreto. El nombre del objeto Gateway debe ser
istio-autogenerated-k8s-ingress
.
Por ejemplo, supongamos que ya creaste un archivo de certificado, ingress-wildcard.crt
, y un archivo de claves, ingress-wildcard.key
.
Crea un Secreto llamado ingressgateway-wildcard-certs
:
kubectl create secret tls \ --namespace gke-system \ ingressgateway-wildcard-certs \ --cert ./ingress-wildcard.crt \ --key ./ingress-wildcard.key
A continuación, se muestra un manifiesto de un objeto Gateway que hace referencia al Secreto. Los clientes pueden llamar al puerto 443 mediante el protocolo HTTPS y cualquier nombre de host que coincida con *.example.com. Ten en cuenta que el nombre de host en el certificado debe coincidir con el nombre de host en el manifiesto, que es *.example.com en este ejemplo:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*" - hosts: - "*.example.com" port: name: https-demo-wildcard number: 443 protocol: HTTPS tls: mode: SIMPLE credentialName: ingressgateway-wildcard-certs
Puedes crear varios certificados TLS para diferentes hosts si modificas el manifiesto de Gateway.
Guarda el manifiesto en un archivo llamado my-gateway.yaml
y crea el objeto Gateway:
kubectl apply -f my-gateway.yaml
Ahora puedes usar objetos Ingress de Kubernetes de forma estándar.
Crea clústeres de administrador y de usuario por separado
A partir de la versión 1.2 de GKE On-Prem, puedes crear los clústeres de administrador y de usuario por separado. Es decir, puedes comenzar por crear solo un clúster de administrador. Luego, puedes crear uno o más clústeres de usuario, según sea necesario.
Antes de la versión 1.2, sucedía lo siguiente:
El primer clúster de usuario siempre usaba el almacén de datos de los clústeres de administrador. Los clústeres de usuario creados después podían usar un almacén de datos distinto del almacén de datos del clúster de administrador.
Si especificabas un almacén de datos distinto para un clúster de usuario, los nodos trabajadores del clúster de usuario y los objetos PersistentVolume (PV) de los nodos trabajadores usaban ese almacén de datos separado. Sin embargo, las VM del plano de control de usuario y los PV asociados usaban el almacén de datos del clúster de administrador.
A partir de la versión 1.2, sucede lo siguiente:
Cualquier clúster de usuario, incluso el primer clúster, puede usar un almacén de datos distinto del almacén de datos del clúster de administrador.
Si especificas un almacén de datos distinto para un clúster de usuario, los nodos trabajadores del clúster de usuario y sus PV junto con las VM del plano de control de usuario y sus PV usan ese almacén de datos.
Para crear solo un clúster de administrador, quita toda la sección usercluster
del archivo de configuración del clúster. Luego, ingresa el comando gkectl create
:
gkectl create --config [ADMIN_CONFIG_FILE]
En el ejemplo anterior, [ADMIN_CONFIG_FILE] es la ruta de acceso del archivo de configuración al que se le quitó la sección usercluster
.
A continuación, crea un archivo de configuración al que se le haya quitado toda la sección admincluster
. En este archivo, puedes especificar un almacén de datos de vSphere que sea diferente del almacén de datos del clúster de administrador. Si deseas especificar un almacén de datos, ingresa un valor para vcenter.credentials.datastore
. Por ejemplo:
vcenter: credentials: ... ... datastore: "my-user-cluster-datastore"
Para crear un clúster de usuario, ingresa este comando:
gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
En el ejemplo anterior, se ilustra lo siguiente:
- [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador.
- [USER_CLUSTER_CONFIG] es el archivo de configuración del clúster de usuario.
Limitaciones de GKE On-Prem
Limitación | Descripción |
---|---|
Límites máximos y mínimos de los clústeres y los nodos | Consulta Cuotas y límites. El rendimiento del entorno puede afectar estos límites. |
Nombres únicos de clúster de usuario | Todos los clústeres de usuario registrados en el mismo proyecto de Google Cloud deben tener nombres únicos. |
No se pueden implementar los mismos clústeres en más de un centro de datos de vCenter o vSphere | Por el momento, solo puedes implementar un clúster de administrador y un conjunto de clústeres de usuario asociados en un solo centro de datos de vCenter o vSphere. No puedes implementar los mismos clústeres de administrador y de usuario en más de un centro de datos de vCenter o vSphere. |
No se puede cambiar la configuración de un clúster de forma declarativa después de su creación | Si bien puedes crear clústeres adicionales y cambiar el tamaño de los clústeres existentes, no puedes cambiar un clúster existente mediante su archivo de configuración. |
Soluciona problemas
Para obtener más información, consulta Soluciona problemas.
Diagnostica problemas de clústeres mediante gkectl
Usa los comandos gkectl diagnose
para identificar los problemas de clústeres y compartir la información de un clúster con Google. Consulta Diagnostica problemas de clústeres.
Ejecuta comandos de gkectl
de forma detallada
-v5
Registra errores de gkectl
en stderr
--alsologtostderr
Ubica los registros de gkectl
en la estación de trabajo de administrador
Incluso si no pasas las marcas de depuración, puedes ver los registros de gkectl
en el siguiente directorio de la estación de trabajo de administrador:
/home/ubuntu/.config/gke-on-prem/logs
Ubica los registros de la API de clúster en el clúster de administrador
Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes intentar depurarla mediante la inspección de los registros de los controladores de la API de clúster en el clúster de administrador:
Encuentra el nombre del Pod de controladores de la API de clúster en el espacio de nombres
kube-system
, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abre los registros del Pod, en los que [POD_NAME] es el nombre del Pod. De manera opcional, usa
grep
o una herramienta similar para buscar errores:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Depura los problemas de BIG-IP de F5 mediante el kubeconfig del nodo del plano de control del clúster de administrador
Después de una instalación, GKE On-Prem genera un archivo kubeconfig llamado internal-cluster-kubeconfig-debug
en el directorio principal de la estación de trabajo de administrador. Este archivo kubeconfig es idéntico al kubeconfig de tu clúster de administrador, excepto que apunta directamente al nodo del plano de control del clúster de administrador, en el que se ejecuta el plano de control de administrador. Puedes usar el archivo internal-cluster-kubeconfig-debug
para depurar los problemas de BIG-IP de F5.
La validación de gkectl check-config
falla: No se pueden encontrar las particiones de BIG-IP de F5
- Síntomas
La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
- Causas posibles
Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
- Solución
Vuelve a ejecutar
gkectl check-config
.
gkectl prepare --validate-attestations
falla: No se puede validar la certificación de la compilación
- Síntomas
La ejecución de
gkectl prepare
con la marca opcional--validate-attestations
muestra el siguiente error:could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causas posibles
Es posible que no exista una certificación para las imágenes afectadas.
- Solución
Vuelve a descargar y a implementar el OVA de la estación de trabajo de administrador, como se indica en Crea una estación de trabajo de administrador. Si el problema persiste, comunícate con Google para obtener asistencia.
Depura mediante los registros del clúster de arranque
Durante la instalación, GKE On-Prem crea un clúster de arranque temporal. Después de una instalación exitosa, GKE On-Prem borra el clúster de arranque, por lo que solo tienes el clúster de administrador y el de usuario. Por lo general, no deberías tener ningún motivo para interactuar con este clúster.
Si algo sale mal durante una instalación y pasaste --cleanup-external-cluster=false
a gkectl create cluster
, es posible que te resulte útil depurar mediante los registros del clúster de arranque. Puedes buscar el Pod y, luego, obtener sus registros:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Próximos pasos
- Obtén más información para crear clústeres de usuario adicionales.
- Visualiza los clústeres en la consola de Cloud.
- Accede a los clústeres.