Instala GKE On-Prem

En esta página, se explica cómo instalar GKE On-Prem en vSphere. En las instrucciones de esta página, se muestra cómo crear un clúster de administración y un clúster de usuario. Después de crear el clúster de administrador y el clúster de usuario inicial, puedes crear clústeres de usuario adicionales.

Antes de comenzar

  1. Configura tu entorno local como se describe en Requisitos del sistema.

  2. Completa los procedimientos en Comenzar ahora.

  3. Crea una estación de trabajo de administrador en vSphere.

  4. Crea un registro de Docker privado, si deseas usar uno.

  5. Obtén información para habilitar el balanceo de cargas manual si deseas usarlo.

  6. Configura IP estáticas, si deseas usarlas.

  7. 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]

  8. Autoriza a gcloud para que acceda a Google Cloud:

    gcloud auth login

  9. Registra gcloud como auxiliar de credenciales de Docker. (Obtén más información sobre este comando):

    gcloud auth configure-docker

  10. 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 la consola de Google Cloud o mediante la ejecución de gcloud config get-value project).

Crea claves privadas de cuentas de servicio en la estación de trabajo de administrador

En Cómo comenzar, 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
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-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 de acceso

gcloud iam service-accounts keys create access-key-file \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

En el comando anterior, [ACCESS_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio de acceso.

Cuenta de servicio de registro

gcloud iam service-accounts keys create register-key \
--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 \
--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 \
--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.

Activa tu cuenta de servicio de acceso para Google Cloud CLI

La activación de tu cuenta de servicio de acceso para la CLI de gcloud hace que todos los comandos de gcloud y gsutil se ejecuten como esa cuenta de servicio. Debido a que tu cuenta de servicio de acceso está en la lista de entidades permitidas para acceder a los objetos binarios de GKE On-Prem, activar la cuenta para la CLI de gcloud te da permiso para descargar objetos binarios de GKE On-Prem desde Cloud Storage.

Para activar tu cuenta de servicio de acceso, ejecuta el siguiente comando. Asegúrate de proporcionar la ruta de acceso al archivo de claves de la cuenta, en caso de que no esté en el directorio de trabajo actual:

gcloud auth activate-service-account --key-file=access-key.json

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 tu instalación, quita los comentarios y proporciona valores.

bundlepath

Un paquete de GKE On-Prem es un conjunto de archivos YAML. En conjunto, los archivos YAML describen todos los componentes en una versión particular de GKE On-Prem.

Cuando creas una estación de trabajo del administrador, se incluye un paquete en /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz.

Configura el valor de bundlepath como la ruta del archivo de paquete. 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.

Ten en cuenta que puedes mantener el archivo de paquete en una ubicación diferente o asignarle un nombre diferente. Solo asegúrate de que, en tu archivo de configuración, el valor de bundlepath sea la ruta al archivo de paquete, cualquiera que sea.

gkeplatformversion

El campo gkeplatformversion contienen la versión de Kubernetes de la versión de GKE On-Prem que instalas. Tiene el siguiente formato:

[KUBERNETES_VERSION]-[GKE_PATCH]

Un ejemplo de la versión de Kubernetes es 1.12.7-gke.19.

Cuando ejecutas gkectl create-config, este campo se propaga.

Los esquemas de control de versiones para bundlepath y gkeplatformversion son diferentes. Sin embargo, una versión determinada del paquete tiene una versión correspondiente de la plataforma de GKE. Por ejemplo, si la versión del paquete es 1.0.10, la versión de la plataforma de GKE debe ser 1.12.7-gke.19.

Para obtener información sobre la correspondencia entre una versión de paquete y la versión de la plataforma de GKE, extrae el archivo del paquete y observa los archivos YAML. En particular, abre gke-onprem-vsphere-[VERSION]-images.yaml y observa el campo osImages. Puedes ver la versión de la plataforma de GKE en el nombre del archivo de imagen del SO. Por ejemplo, en la siguiente imagen de SO, puedes ver que la versión de la plataforma de GKE es 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

vcenter

Usa este campo a fin de declarar la configuración global para tu vCenter Server. GKE On-Prem debe conocer la dirección IP, el nombre de usuario y la contraseña de tu instancia de vCenter Server. Establece los valores en vcenter para proporcionar esta información. Por ejemplo:

vcenter:
  credentials:
    address: "203.0.113.1"
    username: "my-name"
    password: "my-password"

GKE On-Prem necesita información sobre la estructura de tu 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"
  resourcepool: "my-pool"

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"

Si deseas que GKE On-Prem coloque la VMDK en un directorio, debes crear el directorio de forma manual con anticipación. Por ejemplo, puedes usar govc para crear un directorio:

govc datastore.mkdir my-gke-on-prem-directory

Luego, puedes incluir el directorio en el campo vcenter.datadisk:

vcenter:
  ...
  datadisk: "my-gke-on-prem-directory/my-disk.vmdk"

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. El certificado está firmado por una autoridad certificada (CA). El cliente verifica el certificado del servidor mediante el uso del certificado de CA.

Configura vcenter.cacertpath como la ruta del certificado de la CA. Por ejemplo:

vcenter:
  ...
  cacertpath: "/my-cert-directory/altostrat.crt"

Para obtener información sobre cómo descargar el certificado de CA, consulta Cómo descargar e instalar certificados raíz de vCenter Server.

Si vCenter Server usa un certificado autofirmado, puedes extraer el certificado si te conectas a vCenter con openssl desde la estación de trabajo del administrador:

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

gcrkeypath

Establece el valor de gcrkeypath en la ruta del archivo de claves JSON para tu cuenta de servicio de acceso. Por ejemplo:

gcrkeypath: "/my-key-directory/access-key.json"

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

El campo gkeconnect contiene información que GKE On-Prem necesita para configurar la administración de tus clústeres locales desde Google Cloud Console.

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. Configura el valor de gkeconnect.agentserviceaccountkeypath como la ruta del archivo de claves JSON para tu cuenta de servicio de conexión.

Si deseas que el agente de Connect use un proxy para comunicarse con Google Cloud, establece el valor de gkeconnect.proxy en la URL del proxy. Usa el formato http(s)://[PROXY_ADDRESS].

Ejemplo:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-directory/register-key.json"
  agentserviceaccountkeypath: "/my-key-directory/connect-key.json"
  proxy: https://203.0.113.20

stackdriver

En el campo stackdriver, se conserva información que GKE On-Prem necesita para almacenar entradas de registro generadas por tus 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 tus 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.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"
  proxyconfigsecretname: ""
  enablevpc: false
  serviceaccountkeypath: "/my-key-directory/logging-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 a tu 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, configura address como 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 de tu registro privado de Docker.

Cuando Docker extrae una imagen de tu 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.

Configura privateregistryconfig.cacertpath como la ruta del certificado de la CA.

Ejemplo:

privateregistryconfig
  ...
  cacertpath: /my-cert-directory/registry-ca.crt

admincluster

En el campo admincluster, se incluye la información que GKE On-Prem necesita para crear el clúster de administrador.

Red de vCenter: clúster de administrador

En admincluster.vcenter.network, puedes elegir una red de vCenter diferente para tu clúster de administrador. Ten en cuenta que esto reemplaza la configuración global que proporcionaste en vcenter. Por ejemplo:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

Direcciones IP estáticas o DHCP: clúster de administrador

Decide si deseas usar el protocolo de configuración dinámica del host (DHCP) para asignar direcciones IP a los nodos del clúster de administrador. La alternativa es usar direcciones IP estáticas para los nodos del clúster. Ten en cuenta que, si elegiste usar el modo de balanceo de cargas manual, debes usar direcciones IP estáticas para los nodos del clúster.

Si decides usar DHCP, deja el campo admincluster.ipblockfilepath como comentario.

Si eliges usar 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-directory/my-admin-hostconfig.yaml"

Balanceo de cargas integrado: clúster de administrador

Si usas el modo de balanceo de cargas integrado, GKE On-Prem debe conocer la dirección IP, el nombre de usuario y la contraseña de tu balanceador de cargas BIG-IP. 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"

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"

Balanceo de cargas manual: clúster de administrador

Si usas el modo de balanceo de cargas manual, debes usar direcciones IP estáticas para los nodos del clúster. Verifica si estableciste un valor para admincluster.ipblockfilepath. Por ejemplo:

admincluster:
  ipblockfilepath: "/my-config-directory/my-admin-hostconfig.yaml"

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

VIP: clúster de administrador

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

serviceiprange y podiprange: clúster de administrador

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. Si deseas obtener información para elegir los rangos de IP de servicio y de Pod, consulta Optimiza la asignación de direcciones IP.

Los rangos de Services y Pods no deben superponerse. Además, los rangos de servicio y pod que elijas para el clúster de administrador no deben superponerse con los rangos de servicio y pod que elijas para el clúster de usuario.

Ejemplo:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

usercluster

En el campo usercluster, se incluye la información que GKE On-Prem necesita para crear el clúster de usuario inicial.

Red de vCenter: clúster de administrador

En admincluster.vcenter.network, puedes elegir una red de vCenter diferente para los clústeres de usuarios. Ten en cuenta que esto reemplaza la configuración global que proporcionaste en vcenter. Por ejemplo:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

Direcciones IP estáticas o DHCP: clúster de usuario

Decide si deseas usar DHCP para asignar direcciones IP a los nodos de clúster de usuario. La alternativa es usar direcciones IP estáticas para los nodos del clúster. Ten en cuenta que si elegiste el modo de balanceo de cargas manual, debes usar direcciones IP estáticas para los nodos del clúster.

Si decides usar DHCP, deja el campo usercluster.ipblockfilepath como comentario.

Si eliges usar 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-directory/my-user-hostconfig.yaml"

Balanceo de cargas integrado: clúster de usuarios

Si usas el modo de balanceo de cargas integrado, GKE On-Prem debe conocer la dirección IP, el nombre de usuario y la contraseña del balanceador de cargas BIG-IP 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"
  ...

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"
  ...

Balanceo manual de cargas: clúster de usuarios

Si usas el modo de balanceo de cargas manual, debes usar direcciones IP estáticas para los nodos del clúster. Verifica si estableciste un valor para usercluster.ipblockfilepath. Por ejemplo:

usercluster:
  ipblockfilepath: "/my-config-directory/my-user-hostconfig.yaml"
  ...

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

VIP: clúster de usuarios

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

serviceiprange y podiprange: clúster de usuario

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. Si deseas obtener información para elegir los rangos de IP de servicio y de Pod, consulta Optimiza la asignación de direcciones IP.

Los rangos de Services y Pods no deben superponerse. Además, los rangos de servicio y pod que elijas para el clúster de usuarios no deben superponerse con los rangos de servicio y pod que elijas para el clúster de administrador.

Ejemplo:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

clustername

Configura el valor de usercluster.clustername como el nombre que desees. Por ejemplo:

usercluster:
  ...
  clustername: "my-user-cluster-1"

masternode

En el campo usercluster.masternode.replicas, se especifica cuántos nodos del plano de control quieres que tenga el clúster de usuario. Los nodos del plano de control para el clúster de usuario ejecutan los componentes del plano de control del clúster de usuario. Este valor debe ser 1 o 3:

Los campos usercluster.masternode.cpus y usercluster.masternode.memorymb especifican cuántas CPU y cuánta memoria, en megabytes, se asignan a cada nodo del plano de control del clúster de usuario. Por ejemplo:

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

oidc

Si deseas que los clientes del clúster de usuarios usen la autenticación de OIDC, establece valores para los campos en usercluster.oidc. La configuración de OIDC es opcional.

En la versión 1.0.2-gke.3, se agregaron los siguientes campos obligatorios. Estos campos permiten acceder a un clúster desde la consola de Google Cloud:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Si no quieres acceder a un clúster desde la consola de Google Cloud, pero deseas usar OIDC, puedes pasar valores de marcador de posición para estos campos:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Para obtener más información, consulta Autentica con OIDC.

sni

Si deseas proporcionar un certificado de entrega adicional para el servidor de la API de Kubernetes del clúster de usuario, proporciona valores para usercluster.sni.certpath y usercluster.sni.keypath. Por ejemplo:

usercluster:
  ...
  sni:
    certpath: "/my-cert-directory/my-second-cert.crt"
    keypath: "/my-cert-directory/my-second-cert.key"

workernode

En el campo usercluster.workernode.replicas, se especifica la cantidad de nodos trabajadores que quieres que tenga el clúster de usuarios. Los nodos trabajadores ejecutan las cargas de trabajo del clúster.

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

Valida el archivo de configuración

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]

Si el comando muestra algún mensaje FAILURE, soluciona los problemas y vuelve a validar el archivo.

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

Ejecución de gkectl prepare

Antes de realizar la instalación, debes ejecutar gkectl prepare en la estación de trabajo del 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 a tu 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.

Instala GKE On-Prem

Creaste un archivo de configuración en el que se especifica cómo se ve tu entorno y cómo deseas que se vean tus clústeres y, además, validaste el archivo. Ejecutaste gkectl prepare para inicializar tu 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, ejecuta el siguiente comando:

gkectl create cluster --config [CONFIG_FILE]

En el comando anterior, [CONFIG_FILE] es el archivo de configuración que generaste y modificaste.

Puedes volver a usar el archivo de configuración para crear clústeres de usuario adicionales.

Conecta clústeres a Google

  • Cuando creas un clúster de usuario, se registra automáticamente en Google Cloud. Puedes ver un clúster de GKE On-Prem registrado en el menú de clústeres de Kubernetes de la consola de Google Cloud. Desde allí, puedes acceder al clúster para ver sus cargas de trabajo.

  • Si no ves tu clúster en la consola de Google 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:

  1. Crea un Secreto que contenga el certificado y la clave.
  2. 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 una puerta de enlace que hace referencia a tu 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 la manera estándar.

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.

Comportamiento de registro predeterminado

Para gkectl y gkeadm, basta con usar la configuración de registro predeterminada:

  • De forma predeterminada, las entradas de registro se guardan de la siguiente manera:

    • Para gkectl, el archivo de registro predeterminado es /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log y el archivo está vinculado con un symlink con el archivo logs/gkectl-$(date).log en el directorio local en el que ejecutas gkectl.
    • Para gkeadm, el archivo de registro predeterminado es logs/gkeadm-$(date).log en el directorio local en el que ejecutas gkeadm.
  • Todas las entradas de registro se guardan en el archivo de registro, incluso si no se imprimen en la terminal (cuando --alsologtostderr es false).
  • El nivel de verbosidad -v5 (predeterminado) cubre todas las entradas de registro que necesita el equipo de asistencia al cliente.
  • El archivo de registro también contiene el comando ejecutado y el mensaje de error.

Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.

Especifica una ubicación no predeterminada para el archivo de registro

A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl, usa la marca --log_file. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.

A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm, usa la marca --log_file.

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:

  1. 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

  2. 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]

¿Qué sigue?