Guia de início rápido dos clusters do Anthos em Bare Metal

Introdução aos clusters do Anthos em Bare Metal

Com os clusters do Anthos em Bare Metal, é possível definir quatro tipos de clusters:

  • administrador: um cluster usado para gerenciar clusters de usuários
  • usuário: um cluster usado para executar cargas de trabalho.
  • autônomo: um único cluster capaz de administrar ele próprio e de também executar cargas de trabalho, mas que não consegue criar ou gerenciar outros clusters de usuários.
  • híbrido: um único cluster para clusters de administração e cargas de trabalho, mas que também consegue gerenciar clusters de usuários.

Neste guia de início rápido, você implanta um cluster híbrido de dois nós com os clusters do Anthos em Bare Metal. Você aprenderá a criar um cluster e a monitorar o processo de criação dele.

Neste guia de início rápido, pressupomos que você tenha um conhecimento básico do Kubernetes

Preparar para clusters do Anthos em Bare Metal

Antes de criar um cluster nos clusters do Anthos em bare metal, siga estas etapas:

  1. Crie um projeto do Google Cloud.
  2. Configure a estação de trabalho do administrador.

Criar um projeto do Google Cloud

Para este guia de início rápido, crie um novo projeto do Google Cloud que organize todos os recursos do Google Cloud. Para criar um cluster em clusters do Anthos em Bare Metal, você precisa de um projeto do Google Cloud em que sua conta tenha o papel de Proprietário.

Consulte Criar e gerenciar projetos para mais detalhes.

Configurar uma estação de trabalho de administrador do Linux

Neste guia de início rápido, usamos bmctl e kubectl para criar e trabalhar com um cluster. Essas ferramentas de linha de comando são executadas em uma estação de trabalho de administrador do Linux. Para mais informações sobre como configurar a estação de trabalho do administrador, consulte Pré-requisitos da estação de trabalho do administrador.

Criar nós de cluster

Crie duas máquinas para servir como nós do cluster:

  • Uma máquina funciona como o nó do plano de controle.
  • Uma máquina funciona como o nó de trabalho.

Acesse Pré-requisitos da máquina do nó do cluster para saber mais sobre os requisitos dos nós do cluster.

Crie um cluster

Para criar um cluster:

  1. Use bmctl para criar um arquivo de configuração.
  2. Editar o arquivo de configuração para personalizá-lo em seu cluster e rede.
  3. Use bmctl para criar o cluster do arquivo de configuração.

Criar um arquivo de configuração

Para criar um arquivo de configuração e ativar as contas de serviço e as APIs automaticamente, verifique se você está no diretório baremetal e emita o comando bmctl com as sinalizações a seguir: 

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

CLUSTER_NAME é o nome do cluster; PROJECT_ID é o projeto que você criou em Criar um projeto do Google Cloud.

O comando acima cria um arquivo de configuração no diretório baremetal no seguinte caminho: bmctl-workspace/cluster1/cluster1.yaml

Editar o arquivo de configuração

Para editar o arquivo de configuração, faça o seguinte:

  1. Abra o arquivo bmctl-workspace/cluster1/cluster1.yaml em um editor.
  2. Edite o arquivo para seu nó específico e os requisitos de rede. Use o arquivo de configuração de amostra abaixo para referência. Este guia de início rápido não usa nem inclui informações sobre o 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
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.0
  # 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

Executar verificações de simulação e criar o cluster

O comando bmctl executa verificações de simulação no arquivo de configuração do cluster antes de criar um cluster. Se as verificações forem bem-sucedidas, o bmctl criará o cluster.

Para executar verificações de simulação e criar o cluster:

  1. Verifique se você está no diretório baremetal.
  2. Execute o comando a seguir para criar o cluster:
    3. ./bmctl create cluster -c CLUSTER_NAME
    Exemplo: 
    ./bmctl create cluster -c cluster1

    O comando bmctl monitora as verificações de simulação e a criação do cluster. Depois, exibe a saída na tela e grava informações detalhadas nos registros bmctl.

Você pode encontrar os registros de bmctl, verificações de simulação e instalação de nós no seguinte diretório: baremetal/bmctl-workspace/CLUSTER_NAME/log

A simulação bmctl verifica a instalação do cluster proposto para as seguintes condições:

  • A distribuição e a versão do Linux são compatíveis.
  • O SELinux não está no modo "restrito".
  • No Ubuntu, o Uncomplicated Firewall (UFW) não está ativo.
  • O Google Container Registry está acessível.
  • Os VIPs estão disponíveis.
  • As máquinas do cluster têm conectividade entre si.
  • As máquinas do balanceador de carga estão na mesma sub-rede da camada 2.

A criação do cluster pode levar vários minutos para ser concluída.

Receber informações sobre o cluster

Depois de criar um cluster, use o comando kubectl para mostrar informações sobre o novo cluster. Durante a criação do cluster, o comando bmctl grava um arquivo kubeconfig do cluster consultado com kubectl. O arquivo kubeconfig é gravado em: bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Exemplo: 

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

Este comando mostra: 

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

Se a criação do cluster falhar nas verificações de simulação, confira se há erros nos registros da verificação de simulação e corrija-os no arquivo de configuração do cluster. Os registros de verificação de simulação estão localizados no diretório /log em: 

~/baremetal/bmctl-workspace/CLUSTER_NAME/log

Os registros de verificação de simulação para cada máquina no cluster estão no diretório CLUSTER_NAME e são organizados por endereço IP. Exemplo: 

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

Ignorar erros de verificação pré-renderização

Se a criação do cluster falhar após as verificações de simulação, reinstale o cluster usando a sinalização --force no comando bmctl.

A sinalização --force é instalada em um cluster atual, mas ignora os resultados de qualquer falha na verificação de simulação devido às portas do servidor já alocadas.

  1. Verifique se você está no diretório baremetal.
  2. Use o comando a seguir com a sinalização --force para recriar o cluster:
    3. ./bmctl create cluster -c CLUSTER_NAME --force
    Exemplo: 
    ./bmctl create cluster -c cluster1 -force

Crie uma implantação e um serviço

Veja o manifesto de uma implantação: 

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"

Salve o manifesto como my-deployment.yaml.

Crie a implantação com o seguinte comando: 

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

Veja a implantação: 

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

A saída mostra que a implantação tem três pods disponíveis e prontos: 

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

O manifesto a seguir define um serviço do tipo LoadBalancer: 

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

Salve o manifesto como my-service.yaml.

Crie o serviço com o seguinte comando: 

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

Veja o Serviço: 

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

Saída:

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

Os clusters do Anthos em bare metal fornecem ao serviço um endereço IP externo. Use o endereço IP externo para chamar o serviço:

curl 172.16.1.21

A saída é uma mensagem "Hello World":

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

Criar um plano de controle de alta disponibilidade

O guia de início rápido criou um cluster híbrido de dois nós simples. Se você quiser criar um plano de controle de alta disponibilidade, crie um cluster que tenha três nós do plano de controle.

Por exemplo, edite o arquivo de configuração para adicionar mais dois nós ao plano de controle:

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>

Executar o balanceador de carga em seu próprio pool de nós

O guia de início rápido criou um cluster híbrido de dois nós simples. O balanceador de carga é executado no mesmo nó que executa o plano de controle.

Se você quiser que o balanceador de carga seja executado no próprio pool de nós, edite os valores nodePoolSpec da seção loadBalancer do arquivo de configuração:

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