Versão 1.6. 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.7, consulte Como fazer upgrade do Anthos em Bare Metal na documentação do 1.7.

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

Escopo do guia de início rápido 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 haja uma compreensão básica do Kubernetes.

Como preparar clusters do Anthos em Bare Metal

O comando de instalação dos clusters do Anthos em Bare Metal, chamado bmctl, foi projetado para simplificar a criação de clusters. O comando configura automaticamente as APIs e as contas de serviço do Google necessárias para os clusters do Anthos em Bare Metal, e usaremos esses serviços automatizados neste guia de início rápido.

Se preferir, também é possível configurar manualmente os serviços e APIs necessários antes de criar clusters com o bmctl. Nós anotaremos as alterações no comando que precisarão ser feitas posteriormente neste documento, mas para configurar os serviços do Google necessários manualmente, consulte Como ativar serviços e contas de serviço do Google.

Antes de criar um cluster usando os clusters do Anthos em Bare Metal, é necessário:

Criar um projeto do Google Cloud em que você tenha o papel Editor ou Proprietário.
Fazer o download e instalar a ferramenta de linha de comando bmctl conforme descrito abaixo.
Configurar uma estação de trabalho de administrador do Linux para executar o bmctl. Observação: não use o Cloud Shell como sua estação de trabalho do administrador.
1. Instale gcloud, gsutil e kubectl conforme descrito abaixo.
2. Instale o Docker versão 19.03 ou posterior. Para obter instruções sobre como configurar o Docker, consulte a página sobre como configurar o sistema operacional Linux: Como configurar o CentOS, Como configurar o RHEL ou Como configurar o Ubuntu.
3. Usando o acesso root, configure o SSH na estação de trabalho do administrador e nas máquinas de nós 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.
4. Gere um par de chaves pública/privada na estação de trabalho do administrador. Não defina uma senha longa para as chaves. As chaves são necessárias para usar o SSH para conexões seguras e sem senha entre a estação de trabalho de administração e as máquinas de nós do cluster.
```
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 YAML cluster config com as credenciais apropriadas. Para obter mais informações, consulte a seção #Node access configuration no arquivo de configuração de cluster de amostra.
5. 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
```
6. 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
```

Como instalar utilitários da gcloud

As ferramentas gcloud, gsutil e kubectl estão incluídas na gcloud CLI.

Na máquina de administração, instale e inicialize a gcloud CLI usando estas instruções. Esse processo instala gcloud e gsutil.
Atualizar a CLI gcloud:
```
gcloud components update
```
Faça login com sua Conta do Google para gerenciar os serviços e as contas de serviço:
```
gcloud auth login --update-adc
```
Uma nova guia do navegador será aberta e você precisará escolher uma conta.

Observe que é possível configurar um projeto padrão do Google Cloud neste momento e ativar outros serviços e APIs do Google antes de criar os clusters do Anthos em Bare Metal. A definição de um projeto padrão economiza tempo quando você ativa os serviços manualmente.

No entanto, como mostrado neste guia de início rápido, também é possível especificar um projeto e configurar os serviços necessários do Google diretamente com o comando bmctl durante a criação dos clusters. Ao fazer isso, bmctl sempre usará o ID do projeto especificado ao emitir o comando.
Use gcloud para instalar kubectl:
```
gcloud components install kubectl
```

Como instalar o bmctl

A ferramenta de linha de comando para criar clusters nos clusters do Anthos em Bare Metal é bmctl. Faça o download de bmctl de um bucket do Cloud Storage.

Para fazer o download de 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.6.2/linux-amd64/bmctl bmctl
chmod a+x bmctl

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

Como criar os nós do cluster

Crie duas máquinas que servirão como nós para o cluster:

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

A estação de trabalho de administrador precisa ser capaz de ssh para esses nós e ter acesso ao VIP do plano de controle.

Consulte os requisitos de hardware e do sistema operacional (Centos, RHEL e Ubuntu) para obter mais informações sobre o que é necessário para os nós do cluster.

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

Como 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 e PROJECT_ID é um projeto do Google em que você tem um papel de Proprietário ou Editor.

Este comando cria um arquivo de configuração no diretório baremetal em: bmctl-workspace/cluster1/cluster1.yaml

Como 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. Veja abaixo o arquivo de configuração de amostra: Neste guia de início rápido, omitimos 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.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

Como 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 ele for bem-sucedido, o cluster será criado.

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.

Os registros bmctl e as verificações de simulação e instalação de nós estão no 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 AppArmor e o UFW não estão ativos.
No CentOS/RHEL, o firewall 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 L2.

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

Como receber informações sobre o cluster

Após a criação do cluster, o comando kubectl 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

Como ignorar erros da verificação de simulação

Se a criação do cluster falhar após as verificações de simulação, tente reinstalá-lo 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

Como criar 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 e crie a implantação:

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 resposta mostra que a implantação tem três pods em execução:

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

Veja aqui um manifesto de 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 e crie o serviço:

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

Observe que os clusters do Anthos em Bare Metal fornece 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

Como criar um plano de controle de alta disponibilidade

Este guia de início rápido cria 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 mostrado acima para adicioná-lo a mais nós no 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>

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

Este guia de início rápido cria 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>