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.- Instala
gcloud
,gsutil
ykubectl
como se describe a continuación. - 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).
- 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 SSHroot
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 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 YAMLcluster 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. - 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
- Instala
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
ygsutil
. - 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 instalarkubectl
: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_NAMEPor 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
.
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 --forcePor ejemplo:
./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>