Planifica la instalación

Esta página es la primera parte de una guía en la que se explica el uso del software de Google Distributed Cloud (antes conocido como Google Distributed Cloud Virtual) para crear una pequeña instalación de prueba de concepto de los clústeres de GKE en tu hardware Bare Metal. En este documento, se muestra cómo configurar un entorno de hardware mínimo y planificar tus direcciones IP. En el artículo de seguimiento Crea clústeres básicos, se muestra cómo crear un clúster de administrador y uno de usuario.

Es posible que la infraestructura que configures con esta guía no sea adecuada para tus casos de uso y necesidades de producción reales. Para obtener más información sobre las instalaciones de producción, consulta Elige un modelo de implementación.

Antes de comenzar

  1. Consulta Acerca de Google Distributed Cloud.
  2. Familiarízate con algunos conceptos básicos de Google Cloud, incluidos los proyectos, los permisos de IAM y las cuentas de servicio.

  3. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  4. Make sure that billing is enabled for your Google Cloud project.

  5. Toma nota del ID del proyecto de Google Cloud, ya que será necesario más tarde.

Descripción general del procedimiento

La configuración mínima de la infraestructura consiste en estos pasos principales:

  1. Configura la estación de trabajo de administrador. Configura una estación de trabajo de administrador de Linux para tareas de administración locales. Puede ser una máquina existente o dedicada, que puede administrar varios clústeres.

  2. Configura las máquinas de nodos del clúster. Configura al menos tres máquinas para los nodos: un nodo del clúster de administrador, un nodo del plano de control del clúster de usuario y un nodo trabajador del clúster de usuario.

  3. Planifica tus redes. Planifica las direcciones IP para tus máquinas de nodo, direcciones IP virtuales (VIP) y rangos de CIDR de Service y Pod.

  4. Revisa los recursos de Google Cloud necesarios. Para crear clústeres, tu proyecto de Google Cloud requiere API de Google y cuentas de servicio específicas.

1. Configura la estación de trabajo de administrador

La estación de trabajo de administrador aloja herramientas y archivos de configuración para crear clústeres y trabajar con ellos.

Requisitos de hardware

La estación de trabajo de administrador requiere una potencia de procesamiento, memoria y almacenamiento significativas para ejecutar herramientas y almacenar los recursos asociados con la creación y la administración del clúster.

Asegúrate de que la estación de trabajo de administrador cumpla con los siguientes requisitos de hardware:

  • Al menos 2 núcleos de CPU
  • Al menos 4 GiB de RAM
  • Al menos 128 GiB de almacenamiento

Configura el sistema operativo y el software

En la estación de trabajo de administrador, instala y configura los siguientes elementos:

  • Configura Ubuntu

  • Instala gcloud CLI

  • Instalar kubectl

  • Instalar bmctl

Configura el sistema operativo

Para ejecutar bmctl y crear un clúster, la estación de trabajo de administrador tiene los mismos requisitos de sistema operativo (SO) que los nodos. Cada máquina debe ejecutar una versión compatible de Ubuntu, como Ubuntu 20.04.

Ejecuta los siguientes comandos para actualizar la configuración del firewall, instalar y configurar Docker, y asegurarte de que cada máquina use la sincronización de tiempo:

  1. Inhabilita el firewall no complicado (UFW) y verifica su estado:

    sudo ufw disable
sudo ufw status

  2. Quita cualquier versión anterior de Docker, actualiza el administrador de paquetes y, luego, instala la versión más reciente de Docker:

    sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io

  3. Verifica que ahora estés ejecutando la versión 19.03 o una posterior de Docker:

    sudo docker version

    Las versiones del cliente y del servidor deben ser 19.03 o posteriores, como se muestra en la siguiente respuesta de ejemplo:

    Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 ...

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  ...

  4. Crea el grupo docker.

    sudo groupadd docker

  5. Agrega tu información al grupo de Docker:

    sudo usermod -aG docker $USER

  6. Ejecuta el siguiente comando para activar los cambios de grupo:

    newgrp docker

  7. Ejecuta el siguiente comando para verificar que el reloj del sistema esté sincronizado:

    timedatectl

    El resultado de timedatectl debería contener el siguiente estado:

    System clock synchronized: yes

Instala Google Cloud CLI

Para instalar Google Cloud CLI en Ubuntu, sigue las instrucciones de esta guía de instalación.

Realiza los siguientes pasos en la estación de trabajo de administrador para configurar gcloud CLI:

  1. Accede para configurar tu propiedad account de gcloud CLI:

    gcloud auth login

  2. Configura tu propiedad project de gcloud CLI:

    gcloud config set project PROJECT_ID

    Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud.

  3. Verifica que las propiedades account y project estén configuradas correctamente:

    gcloud config list

    En el resultado, se muestran los valores de las propiedades account y project. Por ejemplo:

    [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

Instale kubectl

Para instalar kubectl, haz lo siguiente:

  1. Ejecuta el siguiente comando en la estación de trabajo de administrador:

    gcloud components install kubectl

Instale bmctl

bmctl es la herramienta de línea de comandos propiedad de Google Distributed Cloud que puedes usar para crear y administrar clústeres.

Para instalar bmctl en la estación de trabajo de administrador, sigue estos pasos:

  1. Crea un directorio baremetal y agrégalo a tu ruta de acceso. Si estás en el directorio principal, los comandos son los siguientes:

    mkdir baremetal
export PATH="$HOME/baremetal:$PATH"

  2. Ejecuta el siguiente comando para descargar la última versión del archivo binario bmctl y hacerlo ejecutable:

    gsutil cp gs://anthos-baremetal-release/bmctl/1.29.100-gke.251/linux-amd64/bmctl .
chmod +x ./bmctl

  3. Verifica que bmctl esté instalado y sea ejecutable:

    bmctl version

    La respuesta debería ser similar a la siguiente:

    [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023

Conectividad

La estación de trabajo de administrador necesita acceso a Google Cloud y a todos los nodos del clúster.

Acceso a Google Cloud

La estación de trabajo de administrador accede a Google Cloud para descargar y también instalar imágenes y herramientas, procesar solicitudes de autorización, crear cuentas de servicio, administrar el registro y la supervisión, y mucho más. No puedes crear clústeres sin acceso a Google Cloud.

Accede desde la estación de trabajo de administrador

Para crear y administrar clústeres desde la estación de trabajo de administrador, necesitas el siguiente acceso a las máquinas del nodo:

  • Conectividad de capa 3 a todas las máquinas de nodo del clúster.
  • Acceso a la VIP del plano de control.
  • Acceso SSH sin contraseña a todas las máquinas de nodos del clúster como root o como un usuario con privilegios de sudo sin contraseña

La siguiente sección contiene instrucciones para configurar SSH en la estación de trabajo de administrador y las máquinas de nodo.

2. Configura las máquinas de nodos del clúster

Para la instalación mínima de un clúster de administrador único que no es de alta disponibilidad y un clúster de usuario único sin alta disponibilidad, necesitas tres máquinas:

  • Una máquina para un clúster de administrador con un nodo del plano de control.

  • Dos máquinas para un clúster de usuario con un nodo de plano de control y un nodo trabajador

Requisitos de hardware

Cada máquina de nodo debe cumplir con los siguientes requisitos de hardware:

  • Al menos 2 núcleos de CPU
  • Al menos 4 GiB de RAM
  • Al menos 128 GiB de almacenamiento

Configura Ubuntu

Configura Ubuntu en cada nodo con las mismas instrucciones que se usaron para la estación de trabajo de administrador.

Configura el acceso SSH a los nodos

La estación de trabajo de administrador necesita acceso SSH sin contraseña a todas las máquinas del nodo del clúster. Puedes configurar SSH como root o con un usuario que tenga privilegios sudo sin contraseña.

Estos son los pasos de alto nivel para configurar SSH en Google Distributed Cloud:

  1. Instalar y configurar SSH en todas las máquinas

  2. Crea claves SSH y copia la clave pública en cada máquina de nodo

  3. Inhabilita la autenticación con contraseña en las máquinas de nodo

  4. Verifica el acceso SSH entre la estación de trabajo de administrador y las máquinas de nodo

Instalar y configurar SSH en todas las máquinas

Google Distributed Cloud requiere una comunicación SSH sin contraseña entre la estación de trabajo de administrador y los nodos del clúster. Los siguientes pasos se deben realizar en la estación de trabajo de administrador y en cada máquina de nodo.

Para configurar SSH en máquinas que ejecutan Ubuntu, haz lo siguiente:

  1. Si aún no tienes un servidor SSH en ejecución, instala uno ahora:

    sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

  2. Para habilitar la autenticación de contraseña SSH root, quita los comentarios o agrega las líneas PermitRootLogin y PasswordAuthentication en el archivo /etc/ssh/sshd_config y establece los valores en yes:

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
...
PasswordAuthentication yes

  3. Establece una contraseña raíz:

    sudo passwd root

  4. Para aplicar los cambios de configuración de SSH, reinicia el servicio de SSH:

    sudo systemctl restart ssh.service

  5. Reinicia la máquina.

  6. Establece una conexión SSH desde otra máquina para verificar que SSH funcione.

Crea claves SSH y copia la clave pública en cada máquina de nodo

Para obtener conexiones seguras y sin contraseña entre la estación de trabajo de administrador y los nodos, crea una clave SSH en la estación de trabajo de administrador y comparte la clave pública con los nodos.

  1. En tu estación de trabajo de administrador, genera un par de claves pública y privada. No establezcas una frase de contraseña para las claves:

    ssh-keygen -t rsa

  2. En tu estación de trabajo de administrador, copia la clave pública generada en cada una de las máquinas de nodo:

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    Reemplaza lo siguiente:

    • PUBLIC_KEY: Es la ruta al archivo que contiene la clave pública SSH. De forma predeterminada, la ruta es /home/USERNAME/.ssh/id_rsa.pub.
    • CLUSTER_NODE_IP: La dirección IP de la máquina de nodo
Inhabilitar la autenticación con contraseña en las máquinas de nodo

En este punto, ya no es necesario tener habilitada la autenticación con contraseña.

En cada máquina de nodo:

  1. Abre /etc/ssh/sshd_config, configura PasswordAuthentication como no y guarda el archivo.

  2. Reinicia el servicio de SSH.

    sudo systemctl restart ssh.service
Verifica el acceso SSH entre la estación de trabajo de administrador y las máquinas de nodo

Cuando SSH se configura de forma correcta, puedes establecer una conexión SSH a la máquina del nodo desde la estación de trabajo de administrador (como raíz) sin una contraseña.

Para verificar que la autenticación de clave pública funcione entre la estación de trabajo de administrador y los nodos del clúster, haz lo siguiente:

  1. En la estación de trabajo de administrador, ejecuta el siguiente comando para cada máquina de nodo:

    ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP

    Reemplaza lo siguiente:

    • PRIVATE_KEY: Es la ruta de acceso al archivo que contiene la clave privada SSH. De forma predeterminada, la ruta es /home/USERNAME/.ssh/id_rsa.
    • CLUSTER_NODE_IP: La dirección IP de la máquina de nodo

3. Planifica tus redes

Cuando instalas clústeres, es importante que planifiques las direcciones IP, incluido el hecho de que te asegures de no crear ningún conflicto de direccionamiento. Es posible que necesites que el administrador de red te ayude a encontrar las direcciones adecuadas, incluso para esta instalación simple. Sin contar los CIDR de Pods y Services, necesitas al menos 15 direcciones IP únicas para una instalación mínima de clústeres de administrador y de usuario.

Planifica y especifica direcciones IP para los siguientes componentes del clúster:

  • Nodos de clúster: necesitas una dirección IP para cada máquina de nodo
  • Direcciones IP virtuales (VIP): Necesitas VIP para acceder a los servidores de la API de Kubernetes, el proxy de entrada y los servicios de tipo LoadBalancer
  • Pods y servicios: Necesitas rangos de direcciones CIDR para admitir cada Pod y Service que se ejecutan en tus clústeres.

En el resto de esta sección, hay ejemplos ilustrativos de valores que funcionan para esta instalación en una red hipotética; tus valores serán diferentes.

Para esta pequeña instalación, coloca la estación de trabajo de administrador, el nodo del clúster de administrador y los nodos del clúster de usuario en el mismo dominio de capa 2. Por ejemplo, supongamos que todas las direcciones IP en el rango 172.16.20.0/24 se enrutan a un dominio particular de capa 2. También supongamos que tu administrador de red dice que puedes usar 172.16.20.10 - 172.16.20.12 para direcciones de máquina de nodo y 172.16.0.13 - 172.16.20.24 para VIP.

En el siguiente diagrama, se ilustra un dominio de capa 2 que tiene una estación de trabajo de administrador, un clúster de administrador y un clúster de usuario:

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

Ejemplos de direcciones IP del nodo del clúster

En la siguiente tabla, se muestra un ejemplo de cómo se podrían usar las direcciones IP para los nodos del clúster:

Máquina Descripción Dirección IP
Nodo del plano de control del clúster de administrador Máquina física que funciona como el nodo del plano de control para el clúster de administrador 16/17/2010
Nodo del plano de control del clúster de usuario Máquina física que funciona como el nodo del plano de control para el clúster de usuario 16/17/2011
Nodo trabajador del clúster de usuario Máquina física que ejecuta cargas de trabajo de usuarios 16/17/2012

Ejemplos de direcciones IP virtuales (VIP)

En la siguiente tabla, se muestra un ejemplo de cómo podrías especificar las VIP para los clústeres:

VIP Descripción Dirección IP
Dirección VIP del plano de control del clúster de administrador Dirección VIP del plano de control del clúster de administrador (servidor de la API de Kubernetes del clúster de administrador) 16/17/2013
Dirección VIP del plano de control del clúster de usuario Dirección VIP del plano de control del clúster de usuario (servidor de la API de Kubernetes del clúster de usuario) 16/17/2014
Dirección VIP de entrada VIP de entrada (incluida en el rango de grupos de direcciones de MetalLB) 16/17/2015
Direcciones VIP del servicio Diez direcciones para usar como direcciones IP externas para servicios de tipo LoadBalancer. Las direcciones se asignan según sea necesario en los nodos del clúster de usuario.

Este rango incluye la VIP de entrada. Esta superposición de direcciones IP es un requisito para MetalLB, el balanceador de cargas en paquetes predeterminado.

 Del 16/17/2015 a 172/16/20/24

Direcciones IP para Pods y servicios

Además de las direcciones IP que especificaste para los nodos del clúster y las VIP, debes especificar direcciones para los Pods y los servicios. Especifica un rango CIDR que se usará en las direcciones IP del pod y otro rango CIDR que se usará para las direcciones ClusterIP de los servicios de Kubernetes. Usa direcciones IP en el espacio de direcciones privadas, como se describe en RFC 1918. Estas direcciones se especifican como parte de la configuración del clúster, como se ilustra en la siguiente parte de esta guía.

Como parte de la planificación de la IP, decide qué rangos de CIDR deseas usar para los Pods y los servicios. A menos que tengas un motivo para hacerlo, usa los siguientes rangos sugeridos:

Objetivo Rango de CIDR prepropagado
Pods del clúster de administrador 192.168.0.0/16
Services de clústeres de administrador 10.96.0.0/20
Pods del clúster de usuario 192.168.0.0/16
Services de clústeres de usuarios 10.96.0.0/20

Los rangos sugeridos ilustran estos puntos:

  • El rango de CIDR del pod puede ser el mismo para varios clústeres en el modelo de red predeterminado de modo isla.

  • El rango de CIDR de Service puede ser el mismo para varios clústeres.

  • Por lo general, necesitas más Pods que Services en un clúster, por lo que probablemente desees tener un rango de CIDR de Pod mayor que el rango de CIDR de Service. Por ejemplo, el rango de Pods sugerido para un clúster de usuario tiene 2 (32-16) = 216 direcciones, pero el rango de Service sugerido para un clúster de usuario solo tiene 2(32-20) = 212 direcciones.

Evita la superposición

Para evitar la superposición con direcciones IP a las que se puede acceder en tu red, es posible que debas usar rangos CIDR que sean diferentes de las sugerencias anteriores. Los rangos de Service y Pod no deben superponerse con ninguna dirección fuera del clúster a la que deseas llegar desde dentro del clúster.

Por ejemplo, supongamos que el rango de servicio es 10.96.232.0/24 y el rango de pods es 192.168.0.0/16. El tráfico enviado desde un Pod a una dirección en cualquiera de esos rangos se trata como dentro del clúster y no puede llegar a ningún destino fuera del clúster.

En particular, los rangos de Service y Pod no deben superponerse con lo siguiente:

  • Direcciones IP de nodos en cualquier clúster

  • Direcciones IP que usan las máquinas del balanceador de cargas

  • VIP que usan los balanceadores de cargas y los nodos del plano de control

  • Dirección IP de los servidores DNS o NTP

4. Revisa los recursos de Google Cloud necesarios

Antes de que puedas crear clústeres, Google Distributed Cloud requiere que se habilite un conjunto específico de APIs de Google en tu proyecto de Google Cloud asociado. Para usar las APIs de Google, Google Distributed Cloud requiere cuentas de servicio configuradas con roles de IAM específicos en tu proyecto de Google Cloud asociado.

El proceso de creación de clústeres en la siguiente parte de esta guía, Crea clústeres básicos, habilita las APIs y crea cuentas de servicio de forma automática.

Estas son las APIs de Google que se habilitan automáticamente:

  • anthos.googleapis.com
  • anthosaudit.googleapis.com
  • anthosgke.googleapis.com
  • cloudresourcemanager.googleapis.com
  • connectgateway.googleapis.com
  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • gkeonprem.googleapis.com
  • iam.googleapis.com
  • logging.googleapis.com
  • monitoring.googleapis.com
  • opsconfigmonitoring.googleapis.com
  • serviceusage.googleapis.com
  • stackdriver.googleapis.com
  • storage.googleapis.com

En la siguiente tabla, se describen las cuentas de servicio que se crean automáticamente:

Cuenta de servicio Objetivo Roles
anthos-baremetal-gcr Google Distributed Cloud usa esta cuenta de servicio para descargar imágenes de contenedor de Container Registry. Ninguna
anthos-baremetal-connect El agente de Connect usa esta cuenta de servicio para mantener una conexión entre tu clúster y Google Cloud. Esto permite el acceso al clúster y a las funciones de administración de cargas de trabajo, incluida la consola de Google Cloud y la puerta de enlace de conexión para interactuar con el clúster. roles/gkehub.connect
anthos-baremetal-register El agente de Connect usa esta cuenta de servicio para registrar tus clústeres con una flota. roles/gkehub.admin
anthos-baremetal-cloud-ops El agente de Stackdriver usa esta cuenta de servicio para exportar registros y métricas de clústeres a Cloud Logging y Cloud Monitoring. roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

¿Qué sigue?

Crea clústeres básicos