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 alojados 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:

  1. Crea un proyecto de Google Cloud
  2. Configura tu estación de trabajo de administrador.

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 alojados en Bare Metal, necesitas un proyecto de Google Cloud en el que tu cuenta tenga la función de propietario.

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

Configura una estación de trabajo de administrador de Linux

En esta guía de inicio rápido, se usa bmctl y kubectl para crear y trabajar con un clúster. Estas herramientas de línea de comandos se ejecutan en una estación de trabajo de administrador de Linux. Para obtener información sobre cómo configurar la estación de trabajo de administrador, consulta Requisitos previos de la estación de trabajo de administrador.

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.

Consulta Requisitos previos de las máquinas de nodo del clúster para obtener más información sobre los requisitos de los nodos del clúster.

Crea un clúster

Para crear un clúster, sigue estos pasos:

  1. Usa bmctl para crear un archivo de configuración.
  2. Edita el archivo de configuración a fin de personalizarlo para el clúster y la red.
  3. 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:

  1. Abre el archivo de configuración bmctl-workspace/cluster1/cluster1.yaml en un editor.
  2. 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
---
# Cluster configuration. Note that some of these fields are immutable once the cluster is created.
# For more info, see https://cloud.google.com/anthos/clusters/docs/bare-metal/1.13/reference/cluster-config-ref#cluster_configuration_fields
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.13.10
  # 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

---
# 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:

  1. Asegúrate de estar en el directorio baremetal.
  2. Ejecuta el siguiente comando para crear el clúster.
    3. ./bmctl create cluster -c CLUSTER_NAME
    Por ejemplo: 
    ./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.

  1. Asegúrate de estar en el directorio baremetal.
  2. Usa el siguiente comando con la marca --force para volver a crear el clúster:
    3. ./bmctl create cluster -c CLUSTER_NAME --force
    Por ejemplo: 
    ./bmctl create cluster -c cluster1 --force

Crear una implementación y un servicio

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:

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

El siguiente manifiesto define un Service 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:

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>