Versão 1.11. Esta versão não é mais compatível. Para mais informações, consulte a política de suporte de versões. Para informações sobre como fazer upgrade para a versão 1.12, consulte Como fazer upgrade do Anthos em Bare Metal na documentação da 1.12.

Versões com suporte disponíveis: 1.14 | 1.13 | 1.12

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:

Crie um projeto do Google Cloud.
Instale a Google Cloud CLI.
Configure uma estação de trabalho de administrador do Linux.
Instale a ferramenta bmctl.

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.

Instalar a Google Cloud CLI

Neste guia de início rápido, usamos as ferramentas kubectl e bmctl para criar e configurar clusters. Para instalar essas ferramentas, você precisa de gcloud e gsutil. A Google Cloud CLI inclui as ferramentas de linha de comando gcloud, gsutil e kubectl.

Para instalar as ferramentas necessárias, siga estas etapas:

Na estação de trabalho de administrador, instale e inicialize a Google Cloud CLI usando estas instruções. Esse processo instala gcloud e gsutil.
Atualize a Google Cloud CLI:
```
gcloud components update
```
Faça login com a Conta do Google para gerenciar os serviços e contas de serviço:
```
gcloud auth login --update-adc
```
Uma nova guia do navegador será aberta e você precisará escolher uma conta.
Use gcloud para instalar kubectl:
```
gcloud components install kubectl
```

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

Depois de instalar gcloud, gsutil e kubectl, configure uma estação de trabalho de administrador do Linux. Observação: não use o Cloud Shell como sua estação de trabalho de administrador.

Instale gcloud, gsutil e kubectl, conforme descrito na seção anterior.
Instale o Docker versão 19.03 ou posterior. Para saber como configurar o Docker, acesse a página correspondente à sua distribuição Linux:
Para usar o acesso root, configure o SSH na estação de trabalho de administrador e nas máquinas de nó do cluster remoto. Inicialmente, você precisa da autenticação de senha SSH de root ativada nas máquinas de nós do cluster remoto para compartilhar chaves da estação de trabalho de administrador. Assim que as chaves estiverem em vigor, desative a autenticação de senha SSH.
Gere um par de chaves privada/pública na estação de trabalho de administrador. Não defina uma senha longa para as chaves. Você precisa das chaves para usar o SSH para conexões seguras e sem senha entre a estação de trabalho de administrador e as máquinas de nós do cluster. Gere as chaves com o seguinte comando:
```
ssh-keygen -t rsa
```
Também é possível usar o acesso de usuárioSUDO nas máquinas de nós do cluster para configurar o SSH, mas, para conexões de usuário sem senha e não raiz, é necessário atualizar o arquivo de configuração do cluster com as credenciais apropriadas. Para mais informações, acesse a seção #Node access configuration no arquivo de configuração do cluster de amostra.
Adicione a chave pública gerada às máquinas de nós do cluster. Por padrão, as chaves públicas são armazenadas no arquivo de identidade id_rsa.pub.
```
ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip
```
Desative a autenticação por senha SSH nas máquinas do nó do cluster e use o seguinte comando na estação de trabalho do administrador para verificar se a autenticação de chave pública funciona entre a estação de trabalho de administrador e as máquinas do nó do cluster.
```
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
```

Fazer o download e instalar a ferramenta bmctl

Use a ferramenta de linha de comando bmctl para criar clusters no Anthos em um ambiente bare metal. O comando bmctl configura automaticamente as contas de serviço do Google e ativa as APIs necessárias para usar os clusters do Anthos em bare metal no projeto especificado.

Se você quiser criar suas próprias contas de serviço ou fazer outra configuração manual de projeto, consulte Como ativar os serviços e as contas de serviço do Google antes de criar clusters com bmctl.

Para fazer o download e instalar a ferramenta bmctl:

Crie um novo diretório para bmctl:
```
cd ~
mkdir baremetal
cd baremetal
```

Faça o download de bmctl no bucket Cloud Storage:

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

Verifique se o bmctl está instalado corretamente visualizando as informações de ajuda:
```
./bmctl -h
```

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 os requisitos de hardware e sistema operacional (Centos, RHEL e Ubuntu) para saber mais sobre os requisitos para os nós de cluster.

Criar um cluster

Para criar um cluster:

Use bmctl para criar um arquivo de configuração.
Editar o arquivo de configuração para personalizá-lo em seu cluster e rede.
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:

Abra o arquivo bmctl-workspace/cluster1/cluster1.yaml em um editor.
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
---
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.11.8
  # 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

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:

Verifique se você está no diretório baremetal.
Execute o comando a seguir para criar o cluster:

./bmctl create cluster -c CLUSTER_NAME

./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.

Verifique se você está no diretório baremetal.
Use o comando a seguir com a sinalização --force para recriar o cluster:

./bmctl create cluster -c CLUSTER_NAME --force

./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>