Versión 1.6. 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.7, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.7.

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

Guía de inicio rápido para 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 da por sentado que tienes conocimientos básicos de Kubernetes

Prepara clústeres de Anthos alojados en equipos físicos

El comando de instalación de clústeres de Anthos alojados en equipos físicos, llamado bmctl, se diseñó para optimizar la creación de clústeres. Con el comando, se pueden configurar de forma automática las cuentas de servicio de Google y las API necesarias para los clústeres de Anthos alojados en equipos físicos, y las usaremos en esta guía de inicio rápido.

Si lo deseas, también puedes configurar de forma manual los servicios y las API necesarios antes de crear clústeres con bmctl. Analizaremos los cambios de comandos que necesites realizar más adelante en este documento, pero, para configurar los servicios de Google de forma manual que necesitarás, consulta Habilita servicios y cuentas de servicio de Google.

Antes de crear un clúster mediante los clústeres de Anthos alojados en un equipo físico, asegúrate de lo siguiente:

Crea un proyecto de Google Cloud en el que tengas la función de Editor o Propietario.
Descarga e instala la herramienta de línea de comandos de bmctl como se describe a continuación.
Configura una estación de trabajo de administrador de Linux para ejecutar bmctl. Nota: No uses Cloud Shell como tu estación de trabajo de administrador.
1. Instala gcloud, gsutil y kubectl como se describe a continuación.
2. Instala Docker versión 19.03 o posterior. (Si quieres obtener instrucciones para configurar Docker, consulta la página para configurar el SO de Linux): Configuración de CentOS, Configuración de RHEL o Cómo configurar Ubuntu).
3. Mediante 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.
4. Genera un par de claves públicas/privadas en la estación de trabajo de administrador (no establezcas una frase de contraseña para las claves). Las claves son necesarias para usar SSH en conexiones seguras y sin contraseña entre la estación de trabajo de administrador y las máquinas de nodos del clúster.
```
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 YAML cluster config con las credenciales adecuadas. Para obtener más información, consulta la sección #Node access configuration en el archivo de configuración del clúster de muestra.
5. 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
```
6. 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
```

Instala utilidades de gcloud

Las herramientas gcloud, gsutil y kubectl se incluyen en la CLI de gcloud.

En tu máquina de administración, instala e inicializa la CLI de gcloud mediante las instrucciones que se indican aquí. Este proceso instala gcloud y gsutil.
Actualiza la CLI de gcloud:
```
gcloud components update
```
Accede con tu Cuenta de Google para administrar 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.

Ten en cuenta que puedes configurar un proyecto predeterminado de Google Cloud en este punto y habilitar otros servicios y las API de Google antes de crear clústeres de Anthos en clústeres alojados en equipos físicos. Configurar un proyecto predeterminado ahorra tiempo cuando habilitas los servicios de forma manual.

Sin embargo, como se muestra en esta guía de inicio rápido, también puedes especificar un proyecto y configurar los servicios de Google requeridos directamente con el comando bmctl cuando creas los clústeres. Cuando haces esto, bmctl siempre usa el ID del proyecto que especificas cuando emites el comando.
Usa gcloud para instalar kubectl:
```
gcloud components install kubectl
```

Instala bmctl

La herramienta de línea de comandos para crear clústeres en clústeres de Anthos alojados en equipos físicos es bmctl. Descarga bmctl de un bucket de Cloud Storage.

Para descargar 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.6.2/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 tus nodos de clúster

Crea dos máquinas que funcionarán como nodos para tu clúster:

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

Ten en cuenta que tu estación de trabajo de administrador debe poder establecer una conexión ssh a estos nodos y tener acceso al VIP del plano de control.

Consulta los requisitos de hardware y del sistema operativo (Centos, RHEL y Ubuntu) a fin de obtener más información sobre lo que se requiere para los nodos del clúster.

Crear 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 del clúster y PROJECT_ID es el proyecto de Google en el que tienes la función de Propietario o Editor.

Con este comando, se crea un archivo de configuración en el directorio baremetal en 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 para tus requisitos específicos de nodo y red. Consulta el archivo de configuración de muestra a continuación. Ten en cuenta que, en esta guía de inicio rápido, omitimos 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.6.2
  # 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 VIPs 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 LB 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 VIPs: 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.
    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
---
# 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_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 se completan correctamente, se 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.

Los registros de bmctl , así como los registros de comprobación previa y de instalación del nodo, se encuentran en el 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.
No están activos en Ubuntu, AppArmor y UFW.
En CentOS/RHEL, el firewall 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 L2.

La creación del clúster puede tardar varios minutos.

Obtén información sobre tu clúster

Después de crear el clúster de forma correcta, el comando kubectl te muestra 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 del clúster falla después de la comprobación previa, puedes intentar reinstalar el clúster 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

Crea un Deployment y un Service

Este es un manifiesto para una implementación:

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 el manifiesto como my-deployment.yaml y crea el Deployment:

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 tu Deployment tiene tres Pods en ejecución:

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

A continuación, se muestra un manifiesto de 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 el manifiesto como my-service.yaml y crea el Service:

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

Observa que Anthos en equipos físicos le otorgó a este 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 con alta disponibilidad

En esta guía de inicio rápido, se crea 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 que se muestra arriba para agregar 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 esta guía de inicio rápido, se crea un clúster híbrido simple de dos nodos. 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>