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

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

Criar clusters independentes

Nesta página, mostramos como criar um cluster autônomo, que é um cluster de autogerenciamento que executa cargas de trabalho. Os clusters autônomos não gerenciam outros clusters, eliminando a necessidade de executar um cluster de administrador separado em cenários com recursos restritos. Além disso, os clusters autônomos oferecem dois perfis de instalação:

Padrão: o perfil padrão tem requisitos de recursos limitados.
Borda: o perfil de borda reduziu significativamente os requisitos de recursos do sistema e é recomendado para dispositivos perimetrais com altos limites de recursos.

Antes de criar um cluster autônomo, considere a compensação entre os recursos de redução e a segurança geral. Como os clusters autônomos se autogerenciam, a execução de cargas de trabalho no mesmo cluster aumenta o risco de exposição de dados administrativos confidenciais, como chaves SSH.

Pré-requisitos

Antes de criar um cluster autônomo, confira o seguinte:

O último bmctl é transferido por download (gs://anthos-baremetal-release/bmctl/1.9.8/linux-amd64/bmctl) do Cloud Storage.
A estação de trabalho que executa bmctl tem conectividade de rede com todos os nós no cluster autônomo de destino.
A estação de trabalho que executa bmctl tem conectividade de rede com o VIP do plano de controle do cluster autônomo de destino.
A chave SSH usada para criar o cluster autônomo está disponível para a raiz ou há acesso de usuário SUDO em todos os nós do cluster autônomo de destino.
A conta de serviço connect-register está configurada para uso com o Connect.

Ativar o SELinux

Se você quiser ativar o SELinux para proteger seus contêineres, verifique se o SELinux está ativado no modo Enforced em todas as máquinas host. A partir dos clusters do Anthos na versão Bare Metal 1.9.0 ou posterior, é possível ativar ou desativar o SELinux antes ou depois da criação do cluster ou dos upgrades do cluster. O SELinux é ativado por padrão no Red Hat Enterprise Linux (RHEL) e no CentOS. Se o SELinux estiver desativado em suas máquinas host ou se você não tiver certeza, consulte Como proteger seus contêineres usando o SELinux para instruções sobre como ativá-lo.

Os clusters do Anthos em bare metal são compatíveis com o SELinux apenas em sistemas RHEL e CentOS.

Criar um cluster autônomo

É possível criar um cluster autônomo que tenha um único plano de nós de controle usando o comando bmctl. Esse tipo de configuração reduz o consumo de recursos, mas não fornece alta disponibilidade (HA, na sigla em inglês), e o cluster resultante tem um único ponto de falha.

Também é possível criar um cluster autônomo de alta disponibilidade. No modo de HA, se um nó falhar, outros assumirão o lugar. Para criar um cluster autônomo de alta disponibilidade, você precisa especificar pelo menos três nós para o plano de controle.

O comando bmctl normalmente pode ser executado em uma estação de trabalho separada ou em um dos nós de cluster autônomos. No entanto, se você estiver criando um cluster autônomo com o perfil de perímetro ativado e tiver os recursos mínimos necessários configurados, execute bmctl em uma estação de trabalho separada.

Fazer login no app `gcloud`

Faça login em gcloud como usuário:
```
gcloud auth application-default login
```
Você precisa ter um papel de proprietário ou editor do projeto para usar os recursos automáticos de ativação da API e de criação de contas de serviço, descritos abaixo.

Também é possível adicionar os seguintes papéis de IAM ao usuário:
- Administrador da conta de serviço
- Administrador da chave da conta de serviço
- Administrador de projetos do IAM
- Leitor do Compute
- Administrador do Service Usage
Como alternativa, se você já tiver uma conta de serviço com esses papéis, execute:
```
export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
```
Substitua JSON_KEY_FILE pelo caminho para o arquivo de chave JSON da sua conta de serviço.
Receba o ID do projeto do Google Cloud para usar com a criação do cluster:
```
export CLOUD_PROJECT_ID=$(gcloud config get-value project)
```

Criar um arquivo de configuração de cluster autônomo

Depois de fazer login no gcloud e configurar o projeto, será possível criar o arquivo de configuração do cluster com o comando bmctl. Neste exemplo, todas as contas de serviço são criadas automaticamente pelo comando bmctl create config:

bmctl create config -c STANDALONE_CLUSTER_NAME --enable-apis \
    --create-service-accounts --project-id=$CLOUD_PROJECT_ID

Substitua:

STANDALONE_CLUSTER_NAME pelo nome do cluster autônomo que você quer criar.

Exemplo

O comando a seguir cria um arquivo de configuração para um cluster autônomo chamado standalone1 associado ao ID do projeto my-gcp-project:

bmctl create config -c standalone1 --create-service-accounts --project-id=my-gcp-project

O arquivo é gravado em bmctl-workspace/standalone1/standalone1.yaml.

Outra opção para ativar automaticamente APIs e criar contas de serviço é fornecer as contas de serviço atuais se você tiver as permissões de IAM adequadas. Ou seja, é possível ignorar a criação automática de conta de serviço na etapa anterior no comando bmctl:

bmctl create config -c standalone1

Editar o arquivo de configuração do cluster

Agora que você tem um arquivo de configuração de cluster, faça estas alterações:

Inclua a chave privada SSH para acessar os nós do cluster autônomo:

# bmctl configuration variables. Because this section is valid YAML but not a valid Kubernetes
# resource, this section can only be included when using bmctl to
# create the initial admin/hybrid cluster. Afterwards, when creating user clusters by directly
# applying the cluster and node pool resources to the existing cluster, you must remove this
# section.
gcrKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /path/to/your/ssh_private_key
gkeConnectAgentServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json

Registre seus clusters com a frota de projeto usando o Connect.
- Se você tiver criado o arquivo de configuração usando os recursos automáticos de ativação da API e de criação de contas de serviço, pule esta etapa.
- Se você criou o arquivo de configuração sem usar os recursos de ativação automática de conta e criação de conta de serviço, faça referência às chaves JSON da conta de serviço baixada nos campos gkeConnectAgentServiceAccountKeyPath e gkeConnectRegisterServiceAccountKeyPath correspondentes do arquivo de configuração do cluster.

Altere a configuração para especificar um tipo de cluster de standalone em vez de admin. Se você quiser ativar o perfil de borda para minimizar o consumo de recursos, especifique profile: edge:

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: standalone
  # Edge profile minimizes the resource consumption of Anthos clusters on bare metal. It is only available for standalone clusters.
  profile: edge

Opcional: altere a configuração para especificar um plano de controle com vários nós e de alta disponibilidade. Especifique um número ímpar de nós para poder ter uma maioria de quórum para HA:
```
  # 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: 10.200.0.4
      - address: 10.200.0.5
      - address: 10.200.0.6
```
Se você tiver um número par de nós temporariamente durante a adição ou remoção de nós para manutenção ou substituição, sua implantação manterá a alta disponibilidade, desde que você tenha quórum.
Especifique a densidade do pod dos nós do cluster e o ambiente de execução do contêiner:
```
....
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
  # podDensity specifies the pod density configuration.
  podDensity:
    # maxPodsPerNode specifies at most how many pods can be run 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
....
```
Para clusters autônomos, os valores permitidos para maxPodsPerNode são 32-250 para clusters de alta disponibilidade e 64-250 para clusters que não são de alta disponibilidade. Se não for especificado, o valor padrão será 110. Depois que o cluster for criado, esse valor não poderá ser atualizado.

A densidade de pods também é limitada pelos recursos de IP disponíveis do cluster. Para detalhes, consulte Rede de pod.

O ambiente de execução padrão do contêiner é o contêiner. Se preferir, use o Docker. Para mais informações sobre como alterar o ambiente de execução, consulte nosso guia de ambiente de execução do contêiner. Se você estiver ativando o perfil de borda com os requisitos de recursos mínimos configurados, recomendamos usar containerd.

Criar o cluster autônomo com a configuração do cluster

Use o comando bmctl para implantar o cluster autônomo:

bmctl create cluster -c <var>CLUSTER_NAME</var>

Substitua CLUSTER_NAME pelo nome do cluster que você criou na seção anterior.

Veja a seguir um exemplo do comando para criar um cluster chamado standalone1:

bmctl create cluster -c standalone1

Exemplo da configuração completa do cluster autônomo

A seguir, um exemplo de arquivo de configuração de cluster autônomo criado pelo comando bmctl. Nesta configuração de amostra, são usados nomes de cluster de marcador, VIPs e endereços. Eles podem não funcionar na sua rede.

gcrKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /home/myusername/.ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-standalone1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: standalone1
  namespace: cluster-standalone1
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: standalone
  # Anthos cluster version.
  anthosBareMetalVersion: 1.9.8
  # GKE connect configuration
  gkeConnect:
    projectID: $GOOGLE_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: 10.200.0.4
  # 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:
      - 10.96.0.0/20
  # 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: 10.200.0.71
      # 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: 10.200.0.72
    # 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).
      - 10.200.0.72-10.200.0.90
    # A load balancer node pool 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: <Machine 1 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: $GOOGLE_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 at most how many pods can be run 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
  # KubeVirt configuration, uncomment this section if you want to install kubevirt to the cluster
  # kubevirt:
  #   # if useEmulation is enabled, hardware accelerator (i.e relies on cpu feature like vmx or svm)
  #   # will not be attempted. QEMU will be used for software emulation.
  #   # useEmulation must be specified for KubeVirt installation
  #   useEmulation: false
  # Authentication; uncomment this section if you wish to enable authentication to the cluster with OpenID Connect.
  # authentication:
  #   oidc:
  #     # issuerURL specifies the URL of your OpenID provider, such as "https://accounts.google.com". The Kubernetes API
  #     # server uses this URL to discover public keys for verifying tokens. Must use HTTPS.
  #     issuerURL: <URL for OIDC Provider; required>
  #     # clientID specifies the ID for the client application that makes authentication requests to the OpenID
  #     # provider.
  #     clientID: <ID for OIDC client application; required>
  #     # clientSecret specifies the secret for the client application.
  #     clientSecret: <Secret for OIDC client application; optional>
  #     # kubectlRedirectURL specifies the redirect URL (required) for the gcloud CLI, such as
  #     # "http://localhost:[PORT]/callback".
  #     kubectlRedirectURL: <Redirect URL for the gcloud CLI; optional, default is "http://kubectl.redirect.invalid">
  #     # username specifies the JWT claim to use as the username. The default is "sub", which is expected to be a
  #     # unique identifier of the end user.
  #     username: <JWT claim to use as the username; optional, default is "sub">
  #     # usernamePrefix specifies the prefix prepended to username claims to prevent clashes with existing names.
  #     usernamePrefix: <Prefix prepended to username claims; optional>
  #     # group specifies the JWT claim that the provider will use to return your security groups.
  #     group: <JWT claim to use as the group name; optional>
  #     # groupPrefix specifies the prefix prepended to group claims to prevent clashes with existing names.
  #     groupPrefix: <Prefix prepended to group claims; optional>
  #     # scopes specifies additional scopes to send to the OpenID provider as a comma-delimited list.
  #     scopes: <Additional scopes to send to OIDC provider as a comma-separated list; optional>
  #     # extraParams specifies additional key-value parameters to send to the OpenID provider as a comma-delimited
  #     # list.
  #     extraParams: <Additional key-value parameters to send to OIDC provider as a comma-separated list; optional>
  #     # proxy specifies the proxy server to use for the cluster to connect to your OIDC provider, if applicable.
  #     # Example: https://user:password@10.10.10.10:8888. If left blank, this defaults to no proxy.
  #     proxy: <Proxy server to use for the cluster to connect to your OIDC provider; optional, default is no proxy>
  #     # deployCloudConsoleProxy specifies whether to deploy a reverse proxy in the cluster to allow Google Cloud
  #     # Console access to the on-premises OIDC provider for authenticating users. If your identity provider is not
  #     # reachable over the public internet, and you wish to authenticate using Google Cloud console, then this field
  #     # must be set to true. If left blank, this field defaults to false.
  #     deployCloudConsoleProxy: <Whether to deploy a reverse proxy for Google Cloud console authentication; optional>
  #     # certificateAuthorityData specifies a Base64 PEM-encoded certificate authority certificate of your identity
  #     # provider. It's not needed if your identity provider's certificate was issued by a well-known public CA.
  #     # However, if deployCloudConsoleProxy is true, then this value must be provided, even for a well-known public
  #     # CA.
  #     certificateAuthorityData: <Base64 PEM-encoded certificate authority certificate of your OIDC provider; optional>
  # Node access configuration; uncomment this section if you wish to use a non-root user
  # with passwordless sudo capability for machine login.
  # nodeAccess:
  #   loginUser: <login user name>
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-standalone1
spec:
  clusterName: standalone1
  nodes:
  - address: 10.200.0.5
  - address: 10.200.0.6