Versión 1.8. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.9, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.9.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

Guía de inicio rápido para clústeres de Anthos alojados en equipos físicos

Introducción a los clústeres de Anthos alojados en equipos físicos

Con los clústeres de Anthos en Bare Metal, puedes definir cuatro tipos de clústeres:

De administrador: un clúster que se usa para administrar clústeres de usuario.
De usuario: un clúster que se usa para ejecutar cargas de trabajo.
Independiente: un clúster único que puede administrarse a sí mismo y que también puede ejecutar cargas de trabajo, pero no puede crear ni administrar otros clústeres de usuarios.
Híbrido: un clúster único para el administrador y las cargas de trabajo que también puede administrar clústeres de usuario.

En esta guía de inicio rápido, debes implementar un clúster híbrido de dos nodos con clústeres de Anthos alojados en equipos físicos. Aprenderás a crear un clúster y a supervisar su proceso de creación.

En esta guía de inicio rápido, se supone que tienes conocimientos básicos de Kubernetes

Prepárate para los clústeres de Anthos en equipos físicos

Antes de crear un clúster en clústeres de Anthos en equipos físicos, debes hacer lo siguiente:

Crea un proyecto de Google Cloud
Instala Google Cloud CLI.
Configura una estación de trabajo de administrador de Linux.
Instala la herramienta de bmctl.

Crea un proyecto de Google Cloud

Para esta guía de inicio rápido, crea un nuevo proyecto de Google Cloud que organice todos tus recursos de Google Cloud. Para crear un clúster en clústeres de Anthos en un equipo físico, necesitas un proyecto de Google Cloud en el que tu cuenta tenga una de las siguientes funciones:

Editor
Propietario

Consulta Crea y administra proyectos para obtener más detalles.

Instala Google Cloud CLI

En esta guía de inicio rápido, se usan las herramientas kubectl y bmctl para crear y configurar clústeres. Para instalar estas herramientas, necesitas gcloud y gsutil. Google Cloud CLI incluye las herramientas de línea de comandos de gcloud, gsutil y kubectl.

Para instalar las herramientas necesarias, completa los siguientes pasos:

En tu estación de trabajo de administrador, instala e inicializa el SDK de Cloud con estas instrucciones. Este proceso instala gcloud y gsutil.
Actualiza el SDK de Cloud:
```
gcloud components update
```
Accede con tu Cuenta de Google para administrar tus servicios y cuentas de servicio:
```
gcloud auth login --update-adc
```
Se abrirá una pestaña nueva del navegador y se te solicitará que elijas una cuenta.
Usa gcloud para instalar kubectl:
```
gcloud components install kubectl
```

Configura una estación de trabajo de administrador de Linux

Después de instalar gcloud, gsutil y kubectl, configura una estación de trabajo de administrador de Linux. No uses Cloud Shell como tu estación de trabajo de administrador.

Instala Docker versión 19.03 o posterior. Para aprender a configurar Docker, ve a la página correspondiente a tu distribución de Linux:
Para usar el acceso root, configura SSH en la estación de trabajo de administrador y en las máquinas de nodos de clústeres remotos. En un principio, necesitas la autenticación de contraseña de SSH root habilitada en las máquinas de nodo del clúster remoto para compartir claves desde la estación de trabajo de administrador. Una vez que se aplican las llaves, puedes inhabilitar la autenticación con la contraseña de SSH.
Genera un par de claves públicas/privadas en la estación de trabajo de administrador. No configures una frase de contraseña para las claves. Necesitas las claves a fin de usar SSH para conexiones seguras y sin contraseña entre la estación de trabajo de administrador y las máquinas de nodo del clúster. Genera las claves con el siguiente comando:
```
ssh-keygen -t rsa
```
También puedes usar el acceso de usuario SUDO a las máquinas de nodo del clúster a fin de configurar SSH, pero para conexiones de usuario diferente del usuario raíz sin contraseña, debes actualizar el archivo de configuración del clúster con las credenciales adecuadas. Para obtener más información, ve a la sección #Node access configuration en el archivo de configuración del clúster de muestra.
Agrega la clave pública generada a las máquinas del nodo del clúster. De forma predeterminada, las claves públicas se almacenan en el archivo de identidad id_rsa.pub.
```
ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip
```
Inhabilita la autenticación de contraseña de SSH en las máquinas de nodo del clúster y usa el siguiente comando en la estación de trabajo de administrador para verificar que la autenticación de la clave pública funcione entre la estación de trabajo de administrador y las máquinas de nodo del clúster.
```
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
```

Descarga e instala la herramienta bmctl

Usa la herramienta de línea de comandos de bmctl para crear clústeres en clústeres de Anthos en equipos físicos. El comando bmctl configura automáticamente las cuentas de servicio de Google y habilita las API que necesitas para usar clústeres de Anthos en equipos físicos en el proyecto especificado.

Si deseas crear tus propias cuentas de servicio o hacer otra configuración manual del proyecto tú mismo, consulta Habilita servicios y cuentas de servicio de Google antes de crear clústeres con bmctl.

Para descargar y, luego, instalar la herramienta bmctl, haz lo siguiente:

Crea un directorio nuevo para bmctl:
```
cd ~
mkdir baremetal
cd baremetal
```

Descarga bmctl del bucket de Cloud Storage:

gsutil cp gs://anthos-baremetal-release/bmctl/1.8.9/linux-amd64/bmctl bmctl
chmod a+x bmctl

Para asegurarte de que bmctl esté instalado de forma correcta, consulta la información de ayuda:
```
./bmctl -h
```

Crea los nodos del clúster

Crea dos máquinas que funcionen como nodos para el clúster:

Una máquina funciona como el nodo del plano de control.
Una máquina funciona como nodo trabajador.

Ir ahardware y los requisitos del sistema operativo (Centos ,RHEL yUbuntu) a fin de obtener más información sobre los requisitos para los nodos del clúster.

Crea un clúster

Para crear un clúster, sigue estos pasos:

Usa bmctl para crear un archivo de configuración.
Edita el archivo de configuración a fin de personalizarlo para el clúster y la red.
Usa bmctl para crear el clúster desde el archivo de configuración.

Crea un archivo de configuración

Para crear un archivo de configuración y habilitar las cuentas de servicio y las API automáticamente, asegúrate de estar en el directorio baremetal y ejecutar el comando bmctl con las siguientes marcas:

./bmctl create config -c CLUSTER_NAME \
  --enable-apis --create-service-accounts --project-id=PROJECT_ID

CLUSTER_NAME es el nombre de tu clúster. PROJECT_ID es el proyecto que creaste en Crea un proyecto de Google Cloud.

Con el comando anterior, se crea un archivo de configuración en el directorio baremetal en la siguiente ruta de acceso: bmctl-workspace/cluster1/cluster1.yaml

Edita el archivo de configuración

Para editar el archivo de configuración, sigue estos pasos:

Abre el archivo de configuración bmctl-workspace/cluster1/cluster1.yaml en un editor.
Edita el archivo con tus requisitos específicos de nodo y red. Usa el archivo de configuración de muestra que aparece a continuación como referencia. En esta guía de inicio rápido, no se usa ni se incluye información sobre OpenID Connect (OIDC).

# gcrKeyPath:  < to GCR service account key>
gcrKeyPath: baremetal/gcr.json
# sshPrivateKeyPath:  < to SSH private key, used for node access>
sshPrivateKeyPath: .ssh/id_rsa
# gkeConnectAgentServiceAccountKeyPath:  < to Connect agent service account key>
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
# gkeConnectRegisterServiceAccountKeyPath:  < to Hub registration service account key>
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
# cloudOperationsServiceAccountKeyPath:  < to Cloud Operations service account key>
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: hybrid
  # Anthos cluster version.
  anthosBareMetalVersion: 1.8.9
  # GKE connect configuration
  gkeConnect:
    projectID: PROJECT_ID
  # Control plane configuration
  controlPlane:
    nodePoolSpec:
      nodes:
      # Control plane node pools. Typically, this is either a single machine
      # or 3 machines if using a high availability deployment.
      - address:  CONTROL_PLANE_NODE_IP
  # Cluster networking configuration
  clusterNetwork:
    # Pods specify the IP ranges from which pod networks are allocated.
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    # Services specify the network ranges from which service virtual IPs are allocated.
    # This can be any RFC 1918 range that does not conflict with any other IP range
    # in the cluster and node pool resources.
    services:
      cidrBlocks:
      - 172.26.232.0/24
  # Load balancer configuration
  loadBalancer:
    # Load balancer mode can be either 'bundled' or 'manual'.
    # In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation.
    # In 'manual' mode the cluster relies on a manually-configured external load balancer.
    mode: bundled
    # Load balancer port configuration
    ports:
      # Specifies the port the load balancer serves the Kubernetes control plane on.
      # In 'manual' mode the external load balancer must be listening on this port.
      controlPlaneLBPort: 443
    # There are two load balancer virtual IP (VIP) addresses: one for the control plane
    # and one for the L7 Ingress service. The VIPs must be in the same subnet as the load balancer nodes.
    # These IP addresses do not correspond to physical network interfaces.
    vips:
      # ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server.
      # This address must not be in the address pools below.
      controlPlaneVIP: CONTROL_PLANE_VIP
      # IngressVIP specifies the VIP shared by all services for ingress traffic.
      # Allowed only in non-admin clusters.
      # This address must be in the address pools below.
      ingressVIP: INGRESS_VIP
    # AddressPools is a list of non-overlapping IP ranges for the data plane load balancer.
    # All addresses must be in the same subnet as the load balancer nodes.
    # Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters.
    # addressPools:
    # - name: pool1
    #   addresses:
    #   # Each address must be either in the CIDR form (1.2.3.0/24)
    #   # or range form (1.2.3.1-1.2.3.5).
    #   - LOAD_BALANCER_ADDRESS_POOL-
    # A load balancer nodepool can be configured to specify nodes used for load balancing.
    # These nodes are part of the kubernetes cluster and run regular workloads as well as load balancers.
    # If the node pool config is absent then the control plane nodes are used.
    # Node pool configuration is only valid for 'bundled' LB mode.
    # nodePoolSpec:
    #   nodes:
    #   - address: LOAD_BALANCER_NODE_IP;
  # Proxy configuration
  # proxy:
  #   url: http://[username:password@]domain
  #   # A list of IPs, hostnames or domains that should not be proxied.
  #   noProxy:
  #   - 127.0.0.1
  #   - localhost
  # Logging and Monitoring
  clusterOperations:
    # Cloud project for logs and metrics.
    projectID: PROJECT_ID
    # Cloud location for logs and metrics.
    location: us-central1
    # Whether collection of application logs/metrics should be enabled (in addition to
    # collection of system logs/metrics which correspond to system components such as
    # Kubernetes control plane or cluster management agents).
    # enableApplication: false
  # Storage configuration
  storage:
    # lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks.
    # These disks need to be formatted and mounted by the user, which can be done before or after
    # cluster creation.
    lvpNodeMounts:
      # path specifies the host machine path where mounted disks will be discovered and a local PV
      # will be created for each mount.
      path: /mnt/localpv-disk
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-disks
    # lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem.
    # These subdirectories are automatically created during cluster creation.
    lvpShare:
      # path specifies the host machine path where subdirectories will be created on each host. A local PV
      # will be created for each subdirectory.
      path: /mnt/localpv-share
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-shared
      # numPVUnderSharedPath specifies the number of subdirectories to create under path.
      numPVUnderSharedPath: 5
  # NodeConfig specifies the configuration that applies to all nodes in the cluster.
  nodeConfig:
    # podDensity specifies the pod density configuration.
    podDensity:
      # maxPodsPerNode specifies the maximum number of pods allowed on a single node.
      maxPodsPerNode: 250
    # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
    # containerd and docker are supported.
    containerRuntime: containerd

---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: WORKER_NODE_1_IP
  - address: WORKER_NODE_2_IP

Ejecuta verificaciones previas y crea el clúster

El comando bmctl ejecuta verificaciones previas en tu archivo de configuración de clúster antes de crear un clúster. Si las verificaciones son exitosas, bmctl crea el clúster.

Para ejecutar verificaciones previas y crear el clúster, haz lo siguiente:

Asegúrate de estar en el directorio baremetal.
Ejecuta el siguiente comando para crear el clúster.

./bmctl create cluster -c CLUSTER_NAME

./bmctl create cluster -c cluster1

El comando bmctl supervisa las comprobaciones previas y la creación del clúster, y luego muestra el resultado en la pantalla y escribe información detallada en los registros de bmctl.

Puedes encontrar los registros de verificación de nodo, verificación previa y bmctl en el siguiente directorio: baremetal/bmctl-workspace/CLUSTER_NAME/log

La comprobación previa de bmctl verifica la instalación del clúster propuesta para las siguientes condiciones:

Se admiten la distribución y la versión de Linux.
SELinux no está en modo de aplicación forzosa.
En Ubuntu, el Uncomplicated Firewall (UFW) no está activo.
Se puede acceder a Google Container Registry.
Las VIP están disponibles.
Las máquinas de clústeres tienen conectividad entre sí.
Las máquinas del balanceador de cargas están en la misma subred de Capa 2.

La creación del clúster puede tomar varios minutos en completarse.

Obtén información sobre tu clúster

Después de crear un clúster de manera correcta, usa el comando kubectl para mostrar información sobre el clúster nuevo. Durante la creación del clúster, el comando bmctl escribe un archivo kubeconfig para el clúster que puedes consultar con kubectl. El archivo kubeconfig se escribe en bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Por ejemplo:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes

Este comando muestra la siguiente información:

NAME      STATUS   ROLES    AGE   VERSION
node-01   Ready    master   16h   v1.17.8-gke.16
node-02   Ready    <none>   16h   v1.17.8-gke.16

Si la creación del clúster no pasa las comprobaciones previas, verifica los registros de las comprobaciones previas en busca de errores y corrígelos en el archivo de configuración del clúster. Los registros de las comprobaciones previas se encuentran en el directorio /log en

~/baremetal/bmctl-workspace/CLUSTER_NAME/log

Los registros de las comprobaciones previas para cada máquina en el clúster están en el directorio CLUSTER_NAME y se organizan por dirección IP. Por ejemplo:

bmctl-workspace/cluster1/log
└── preflight-20201007-034844
    ├── 172.17.0.3
    ├── 172.17.0.4
    ├── 172.17.0.5
    ├── 172.17.0.6
    ├── 172.17.0.7
    └── node-network

Ignora errores de comprobación previa

Si la creación de tu clúster falla después de las comprobaciones previas, puedes volver a instalarlo con la marca --force en el comando bmctl.

La marca --force se instala en un clúster existente, pero ignora los resultados de cualquier falla de comprobación previa a causa de puertos de servidor ya asignados.

Asegúrate de estar en el directorio baremetal.
Usa el siguiente comando con la marca --force para volver a crear el clúster:

./bmctl create cluster -c CLUSTER_NAME --force

./bmctl create cluster -c cluster1 --force

Crear una implementación y un servicio

A continuación, se muestra una definición de recurso personalizado para un Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: metrics
      department: sales
  replicas: 3
  template:
    metadata:
      labels:
        app: metrics
        department: sales
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

Guarda la definición de recurso personalizado como my-deployment.yaml.

Crea el Deployment con el siguiente comando:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml

Visualiza el Deployment:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments

El resultado muestra que el Deployment tiene tres Pods disponibles y listos:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment      3/3     3            3           16s

La siguiente definición de recurso personalizado define un servicio de tipo LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: sales
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

Guarda la definición de recurso personalizado como my-service.yaml.

Crea el Service con el siguiente comando:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml

Observa el Service:

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service

Resultado:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S
my-service   LoadBalancer   172.26.232.2   172.16.1.21   80:30060/TCP

Los clústeres de Anthos en equipos físicos le proporcionan al servicio una dirección IP externa. Usa la dirección IP externa para llamar al Service:

curl 172.16.1.21

El resultado es un mensaje de Hello World:

Hello, world!
Version: 2.0.0
Hostname: my-deployment-75d45b64f9-6clxj

Crea un plano de control de alta disponibilidad

En la guía de inicio rápido, se creó un clúster híbrido simple de dos nodos. Si deseas crear un plano de control de alta disponibilidad, crea un clúster que tenga tres nodos del plano de control.

Por ejemplo, edita el archivo de configuración para agregar dos nodos adicionales al plano de control:

controlPlane:
  nodePoolSpec:
    clusterName: cluster1
    nodes:
    # Control Plane node pools. Typically, this is either a single machine
    # or 3 machines if using a high availability deployment.
    - address: <Machine 1 IP>
    - address: <Machine 2 IP>
    - address: <Machine 3 IP>

Ejecuta el balanceador de cargas en su propio grupo de nodos

En la guía de inicio rápido, se creó un clúster híbrido simple de dos nodos. Por lo tanto, el balanceador de cargas se ejecuta en el mismo nodo que ejecuta el plano de control.

Si deseas que el balanceador de cargas se ejecute en su propio grupo de nodos, edita los valores nodePoolSpec de la sección loadBalancer del archivo de configuración:

  loadBalancer:
    nodePoolSpec:
      clusterName: "cluster1"
      nodes:
      - address: <LB Machine 1 IP>
      - address: <LB Machine 2 IP>