Crea un clúster de administrador

En esta página, se muestra cómo crear un clúster de administrador para clústeres de Anthos alojados en VMware (GKE On-Prem).

Las instrucciones que aparecen aquí están completas. Para obtener una introducción más corta a fin de crear un clúster de administrador, consulta Crea un clúster de administrador (guía de inicio rápido).

Antes de comenzar

Crea una estación de trabajo de administrador.

Obtén una conexión SSH a tu estación de trabajo de administrador

Obtén una conexión SSH a tu estación de trabajo de administrador

Recuerda que gkeadm activó tu cuenta de servicio de acceso a componentes en la estación de trabajo de administrador.

Sigue todos los pasos restantes de este tema en tu estación de trabajo de administrador en el directorio principal.

Archivo de configuración de credenciales

Cuando usaste gkeadm para crear tu estación de trabajo de administrador, completaste un archivo de configuración de credenciales llamado credential.yaml. Este archivo contiene el nombre de usuario y la contraseña de tu servidor de vCenter.

Archivo de configuración del clúster de administrador

Cuando gkeadm creó la estación de trabajo de administrador, generó un segundo archivo de configuración llamado admin-cluster.yaml. Este archivo de configuración sirve para crear tu clúster de administrador.

Completa el archivo de configuración

bundlePath

Ya se completó este campo.

vCenter

La mayoría de los campos ya están completados con los valores que ingresaste cuando creaste tu estación de trabajo de administrador. La excepción es el campo dataDisk, que debes completar ahora.

network

Decide cómo quieres que los nodos del clúster obtengan sus direcciones IP. Las opciones son las siguientes:

• De un servidor DHCP. Establece network.ipMode.type en "dhcp".

• De una lista de direcciones IP estáticas que proporciones. Configura network.ipMode.type como "static" y crea un archivo de bloques de IP que proporcione las direcciones IP estáticas.

Proporciona valores para los campos restantes en la sección network.

Independientemente de que utilices un servidor DHCP o especifiques una lista de direcciones IP estáticas, necesitas suficientes direcciones IP para cumplir con lo siguiente:

• Tres nodos en el clúster de administrador para ejecutar el plano de control y los complementos del clúster de administrador.

• Un nodo adicional en el clúster del administrador que se usará de forma temporal durante las actualizaciones

• Para cada clúster de usuario que desees crear, uno o tres nodos en el clúster de administrador a fin de ejecutar los componentes del plano de control para el clúster de usuario. Si deseas que el plano de control de un clúster de usuario tenga alta disponibilidad (HA), necesitas tres nodos en el clúster de administrador para el plano de control del clúster de usuario. De lo contrario, solo necesitas un nodo en el clúster de administrador para el plano de control del clúster de usuario.

Por ejemplo, imagina que tienes la intención de crear dos clústeres de usuario: uno con un plano de control de HA y otro con un plano de control que no tiene HA. Luego, necesitarás ocho direcciones IP para los siguientes nodos en el clúster de administrador:

• Tres nodos para el plano de control y los complementos del clúster de administrador
• Un nodo temporal
• Tres nodos para el plano de control del clúster de usuario de alta disponibilidad
• Un nodo para el plano de control del clúster de usuario que no es de alta disponibilidad

Como se mencionó antes, si deseas usar direcciones IP estáticas, debes proporcionar un archivo de bloque de IP. A continuación, te mostramos un ejemplo de un archivo de bloque de IP con ocho hosts:

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
    - ip: 172.16.20.17
      hostname: admin-host8

loadBalancer

Reserva una VIP para el servidor de la API de Kubernetes del clúster de administrador. Reserva otra VIP para el servidor de complementos. Proporciona tus VIP como valores para loadBalancer.vips.controlPlaneVIP y loadBalancer.vips.addonsVIP.

Decide qué tipo de balanceo de cargas quieres usar. Las opciones son las siguientes:

• Balanceo de cargas en paquetes de Seesaw. Configura loadBalancer.kind como "Seesaw" y completa la sección loadBalancer.seesaw.

• Balanceo de cargas integrado en F5 BIG-IP. Configura loadBalancer.kind como "F5BigIP" y completa la sección f5BigIP.

• Balanceo de cargas manual. Configura loadBalancer.kind como "ManualLB" y completa la sección manualLB.

antiAffinityGroups

Configura antiAffinityGroups.enabled como true o false según tus preferencias.

proxy

Si la red que tendrá los nodos del clúster de administrador está detrás de un servidor proxy, completa la sección proxy.

privateRegistry

Decide dónde quieres conservar las imágenes de contenedor de los componentes de clústeres de Anthos alojados en VMware. Las opciones son las siguientes:

• gcr.io. No completes la sección privateRegistry.

• Tu propio registro privado de Docker. Completa la sección privateRegistry.

gcrKeyPath

Establece gcrKeyPath en la ruta de acceso del archivo de claves JSON de la cuenta de servicio de acceso a los componentes.

stackdriver

Completa la sección stackdriver.

cloudAuditLogging

Si quieres integrar los registros de auditoría de Kubernetes a los registros de auditoría de Cloud, completa la sección cloudAuditLogging.

autoRepair

Si deseas habilitar la reparación automática de nodos, establece autoRepair.enabled en true. De lo contrario, configúralo como false.

adminMaster

Si deseas configurar de forma manual las CPU y la memoria del nodo del plano de control del administrador, completa la sección adminMaster.

Valida tu archivo de configuración

Una vez que hayas completado el archivo de configuración de tu clúster de administrador, ejecuta gkectl check-config para verificar que el archivo sea válido:

gkectl check-config --config [CONFIG_PATH]

En el ejemplo anterior, [CONFIG_PATH] es la ruta de acceso del archivo de configuración de tu clúster de administrador.

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

Si deseas omitir las validaciones que llevan más tiempo, pasa la marca --fast. Para omitir validaciones individuales, usa las marcas --skip-validation-xxx. Para obtener más información sobre el comando check-config, consulta Ejecuta verificaciones previas.

Ejecuta gkectl prepare

Ejecuta gkectl prepare para inicializar el entorno de vSphere:

gkectl prepare --config [CONFIG_PATH]

El comando gkectl prepare realiza las siguientes tareas de preparación:

• Importa las imágenes de SO a vSphere y las marca como plantillas de VM.

• Si usas un registro de Docker privado, este comando envía las imágenes de contenedor de Docker a tu registro.

• De forma opcional, este comando valida las certificaciones de compilación de las imágenes de contenedor y verifica las imágenes que Google compiló y firmó, y que están listas para la implementación.

Nota: Si usas nombres de DNS internos o tu estación de trabajo no puede acceder a las direcciones de DNS públicas de Google (8.8.8.8 o 8.8.4.4), debes especificar tu servidor de nombres interno en /etc/resolv.conf.

Crea un balanceador de cargas de Seesaw para tu clúster de administrador

Si decidiste usar el balanceador de cargas de Seesaw integrado, realiza el paso en esta sección. De lo contrario, puedes omitir esta sección.

Crea y configura la VM para tu balanceador de cargas de Seesaw:

gkectl create loadbalancer --config [CONFIG_PATH]

Crea el clúster de administrador

Crea el clúster de administrador:

gkectl create admin --config [CONFIG_PATH]

En el ejemplo anterior, [CONFIG_PATH] es la ruta de acceso del archivo de configuración de tu clúster de administrador.

El comando gkectl create admin crea un archivo kubeconfig llamado kubeconfig en el directorio actual. Necesitarás este archivo kubeconfig más adelante para interactuar con tu clúster de administrador.

Verifica que el clúster de administrador esté en ejecución

Verifica que el clúster de administrador esté en ejecución:

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso de tu archivo kubeconfig.

En el resultado, se muestran los nodos del clúster de administrador.

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 donde 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, clústeres de Anthos alojados en VMware genera un archivo kubeconfig en el directorio principal de la estación de trabajo de administrador, llamado internal-cluster-kubeconfig-debug. 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, clústeres de Anthos alojados en VMware crea un clúster de arranque temporal. Después de una instalación exitosa, clústeres de Anthos alojados en VMware 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]

Para obtener más información, consulta Soluciona problemas.

¿Qué sigue?

Crea un clúster de usuario.