Depois de criar um cluster, é possível alterar alguns aspectos da configuração dele. Por exemplo:
- Adicionar, remover ou substituir nós.
- Adicione ou remova anotações do cluster.
- Modificar os valores dos campos mutáveis nos recursos do cluster e do pool de nós.
- Modifique outros recursos personalizados.
É possível usar bmctl
ou a CLI do Google Cloud para fazer atualizações em um cluster. Se você criou um cluster de administrador ou de usuário usando o Terraform, use-o para atualizar o cluster. Observações:
Muitos aspectos da configuração do cluster são imutáveis e não podem ser atualizados após a criação do cluster. Consulte uma lista abrangente de campos mutáveis e imutáveis na Referência dos campos de configuração do cluster. A referência de campo é uma tabela classificável. Clique nos cabeçalhos das colunas para alterar a ordem de classificação. Clique no nome de um campo para conferir a descrição.
A gcloud CLI e o Terraform só aceitam a atualização de clusters de administrador e usuário. Você precisa usar
bmctl
para atualizar outros tipos de cluster.A gcloud CLI e o Terraform só aceitam alterações nos recursos de cluster e pool de nós. Use
kubectl
oubmctl
para atualizar outros recursos personalizados que afetam o cluster.
Como atualizar clusters
Geralmente, a seguinte sequência de ações é usada para atualizar um cluster:
bmctl
Altere os valores dos campos aplicáveis no arquivo de configuração do cluster, que fica localizado aqui por padrão:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Para atualizar o cluster, execute o comando
bmctl update
:bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
Substitua:
CLUSTER_NAME
: o nome do cluster que você quer atualizar.KUBECONFIG
: para clusters de administrador, híbridos ou independentes, insira o caminho para o arquivo kubeconfig do cluster. Para um cluster de usuário, insira o caminho para o arquivo kubeconfig do cluster de admin.
gcloud CLI
Especifique apenas as flags da configuração que você quer modificar.
Execute o comando de atualização aplicável:
Clusters de administrador:
gcloud container bare-metal admin-clusters update
Clusters de usuários:
gcloud container bare-metal clusters update
.Pools de nós em um cluster de usuário:
gcloud container bare-metal node-pools update
Terraform
Altere os valores dos campos aplicáveis no arquivo de configuração do Terraform usado para criar o cluster ou o pool de nós. Consulte as descrições detalhadas dos campos na documentação de referência do Terraform:
Execute o comando
terraform apply
para atualizar a configuração.
As seções a seguir descrevem alguns exemplos comuns para atualizar um cluster atual.
Adicionar ou remover nós de um cluster
Um pool de nós é um grupo de nós de um cluster que têm a mesma configuração. Lembre-se de que um nó sempre pertence a um pool. Para adicionar um novo nó a um cluster, adicione o nó a um pool específico. Remover um nó de um pool equivale a remover o nó do cluster por completo.
Há três tipos de pools de nós em GDCV para Bare Metal: plano de controle, balanceador de carga e pools de nós de trabalho. Nas seções a seguir, descrevemos como adicionar ou remover nós de cada tipo de pool.
bmctl
Para adicionar ou remover um nó de um pool, adicione ou remova o endereço IP do nó em uma seção específica do arquivo de configuração do cluster. A lista a seguir mostra qual seção editar em um determinado pool de nós:
- Pool de nós de trabalho: adicione ou remova o endereço IP do nó na
seção
spec.nodes
da especificaçãoNodePool
. - Pool de nós do plano de controle: adicione ou remova o endereço IP do nó na
seção
spec.controlPlane.nodePoolSpec.nodes
da especificaçãoCluster
. - Pool de nós do balanceador de carga: adicione ou remova o endereço IP do nó na seção
spec.loadBalancer.nodePoolSpec.nodes
da especificaçãoCluster
.
Exemplo: remover um nó de trabalho
Confira um exemplo de arquivo de configuração de cluster que mostra as especificações de dois nós de trabalho:
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: nodepool1
namespace: cluster-cluster1
spec:
clusterName: cluster1
nodes:
- address: 192.0.2.1
- address: 192.0.2.2
Para remover um nó:
(Opcional) Se o nó que você está removendo estiver executando pods críticos, primeiro coloque o nó no modo de manutenção.
É possível monitorar o processo de drenagem de nós de trabalho visualizando os campos
status.nodesDrained
estatus.nodesDraining
no recursoNodePool
.Edite o arquivo de configuração do cluster para excluir a entrada do endereço IP do nó.
Atualize o cluster:
bmctl update cluster1 \ --kubeconfig=ADMIN_KUBECONFIG
CLI da gcloud
Use um comando update
para adicionar ou remover nós. O comando update
usado e a flag em que o endereço IP é especificado dependem do tipo de pool de nós que você quer atualizar:
Pool de nós de trabalho: execute
gcloud container bare-metal node-pools update
e especifique o endereço IP na flag--node-configs 'node-ip=IP_ADDRESS'
.Pool de nós do plano de controle em um cluster de administrador: execute
gcloud container bare-metal admin-clusters update
e especifique o endereço IP na flag--control-plane-node-configs 'node-ip=IP_ADDRESS'
.Pool de nós do plano de controle em um cluster de usuário: execute
gcloud container bare-metal clusters update
e especifique o endereço IP na flag--control-plane-node-configs 'node-ip=IP_ADDRESS'
.Pool de nós do balanceador de carga: execute
gcloud container bare-metal clusters update
e especifique o endereço IP na flag--metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS'
ou
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'
A flag em que você especifica o endereço IP aceita apenas um node-ip
. Inclua a flag para cada endereço IP no pool de nós.
Os comandos update
substituem todos os endereços IP pelos endereços IP
especificados. Para adicionar um nó, inclua os endereços IP dos nós atuais e o endereço IP do novo nó no comando update
. Da mesma forma, você remove os nós incluindo apenas os endereços IP dos nós que quer manter.
Exemplo: remover um nó de trabalho
Nesta seção, mostramos como remover um nó de trabalho de um pool de nós usando dados de exemplo. Outros comandos da gcloud CLI que podem ser úteis também estão incluídos nas etapas a seguir.
(Opcional) Se o nó que você está removendo estiver executando pods críticos, primeiro coloque o nó no modo de manutenção.
É possível monitorar o processo de drenagem de nós de trabalho visualizando os campos
status.nodesDrained
estatus.nodesDraining
no recursoNodePool
.Execute o comando
list
para listar todos os pools de nós no cluster:gcloud container bare-metal node-pools list \ --cluster=abm-user-cluster1 \ --project=example-project-12345 \ --location=us-central1
O resultado será assim:
NAME LOCATION STATE node-pool-1 us-central1 RUNNING node-pool-2 asia-east1 RUNNING
Execute o comando
describe
para listar todos os endereços IP no pool de nós:gcloud container bare-metal node-pools describe node-pool-1 \ --cluster=abm-user-cluster1 \ --project=example-project-12345 \ --location=us-central1
O exemplo de saída abaixo está truncado para facilitar a leitura:
annotations: ... baremetal.cluster.gke.io/version: 1.16 ... name: projects/example-project-12345/locations/us-central1/bareMetalClusters/abm-user-cluster1/bareMetalNodePools/node-pool-1 nodePoolConfig: nodeConfigs: - nodeIp: 192.0.2.1 - nodeIp: 192.0.2.2 operatingSystem: LINUX state: RUNNING ...
Observe o seguinte no exemplo de saída:
O campo
name
contém o nome totalmente qualificado do pool de nós. Ao especificar o nome do pool de nós em um comando, é possível especificar o nome totalmente qualificado ou o nome do pool de nós, por exemplo,node-pool-1
, junto com--cluster
,--project
e as flags--location
.A seção
nodeConfigs
contém dois camposnodeIp
com os endereços IP dos nós.
Execute o comando a seguir para remover o nó com o endereço IP 192.0.2.1:
gcloud container bare-metal node-pools update node-pool-1 \ --cluster=abm-user-cluster1 \ --project=example-project-12345 \ --location=us-central1 \ --node-configs='node-ip=192.0.2.2'
O comando
update
substitui todos os endereços IP pelos endereços IP especificados. Como 192.0.2.1 não está incluído, o nó foi removido.A saída desse comando é semelhante a:
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
No exemplo de saída, a string
operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9
é oOPERATION_ID
da operação de longa duração. Descubra o status da operação executando o comando a seguir em outra janela de terminal:gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \ --project= example-project-12345 \ --location=us-central1
Você pode executar o comando de novo de vez em quando para verificar o status.
Se a remoção do nó falhar, você poderá forçar a remoção do cluster. Consulte detalhes em Forçar a remoção de nós corrompidos.
Substituir nós do plano de controle de alta disponibilidade
bmctl
É possível usar bmctl
para substituir os nós do plano de controle de alta disponibilidade (HA, na sigla em inglês) em todos os tipos de cluster.
Para substituir um nó em um cluster, siga estas etapas:
- Remova o endereço IP do nó do arquivo de configuração do cluster.
- Atualize o cluster.
- Verifique o status dos nós no cluster.
- Adicione o endereço IP de um novo nó ao mesmo arquivo de configuração do cluster.
- Atualize o cluster.
Exemplo: substituir um nó do plano de controle de alta disponibilidade
Confira um exemplo de arquivo de configuração de cluster que mostra três nós do plano de controle em um cluster de usuário:
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
controlPlane:
nodePoolSpec:
nodes:
- address: 192.0.2.11
- address: 192.0.2.12
- address: 192.0.2.13
Para substituir o último nó listado na seção spec.controlPlane.nodePoolSpec.nodes
,
siga estas etapas:
Remova o nó excluindo a entrada de endereço IP dele no arquivo de configuração do cluster. Depois dessa alteração, o arquivo de configuração do cluster terá esta aparência:
--- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-cluster namespace: cluster-user-cluster spec: controlPlane: nodePoolSpec: nodes: - address: 192.0.2.11 - address: 192.0.2.12
Atualize o cluster executando o seguinte comando:
bmctl update cluster -c CLUSTER_NAME \ --kubeconfig=KUBECONFIG
Faça as mudanças a seguir:
- Substitua CLUSTER_NAME pelo nome do cluster que você quer atualizar.
- Se o cluster for de autogerenciamento, como o cluster de administrador ou independente, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster. Se o cluster for de usuário, como neste exemplo, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de admin.
Depois que o comando
bmctl update
for executado, levará algum tempo para concluir os jobsmachine-preflight
emachine-init
. Confira o status dos nós e os respectivos pools executando os comandos descritos na seção Verificar as atualizações deste documento. Quando o pool e os nós estiverem em estado "pronto", siga para a próxima etapa.Adicione um novo nó do plano de controle ao pool adicionando o endereço IP do novo nó do plano de controle à seção
spec.controlPlane.nodePoolSpec.nodes
do arquivo de configuração do cluster. Depois dessa alteração, o arquivo de configuração do cluster ficará assim:--- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-cluster namespace: cluster-user-cluster spec: controlPlane: nodePoolSpec: nodes: - address: 192.0.2.11 - address: 192.0.2.12 - address: 192.0.2.14
Atualize o cluster executando o seguinte comando:
bmctl update cluster -c CLUSTER_NAME \ --kubeconfig=KUBECONFIG
CLI da gcloud
É possível usar a gcloud CLI para substituir os nós do plano de controle de alta disponibilidade (HA, na sigla em inglês) nos clusters de administrador e usuário.
Para substituir um nó em um cluster, siga estas etapas:
Remova o endereço IP do nó executando o comando
update
aplicável:- Cluster de usuário:
gcloud container bare-metal clusters update
- Cluster de administrador:
gcloud container bare-metal admin-clusters update
- Cluster de usuário:
Verifique o status da remoção do nó no cluster executando
gcloud container bare-metal operations describe OPERATION_ID
.Adicione o endereço IP do novo nó executando o comando
update
aplicável.
Exemplo: substituir um nó do plano de controle de alta disponibilidade
Nesta seção, mostramos como substituir um plano de controle de um cluster usando dados de exemplo. Outros comandos da gcloud CLI que podem ser úteis também estão incluídos nas etapas a seguir.
Execute o comando
list
para listar todos os clusters de usuário em um projeto do Google Cloud:gcloud container bare-metal clusters list \ --project=example-project-12345 \ --location=-
Definir
--location=-
significa listar todos os clusters em todas as regiões. Se você precisar reduzir o escopo da lista, defina--location
como uma região específica.O resultado será assim:
NAME LOCATION VERSION ADMIN_CLUSTER STATE abm-user-cluster1a us-central1 1.16 abm-admin-cluster1 RUNNING abm-user-cluster1b europe-west1 1.16 abm-admin-cluster1 RUNNING
Execute o comando
describe
no cluster:gcloud container bare-metal clusters describe abm-user-cluster1 \ --project=example-project-12345 \ --location=us-central1
O exemplo de saída está truncado para facilitar a leitura:
... controlPlane: controlPlaneNodePoolConfig: nodePoolConfig: nodeConfigs: - nodeIp: 192.0.2.11 - nodeIp: 192.0.2.12 - nodeIp: 192.0.2.13 operatingSystem: LINUX ... name: projects/example-project-1234567/locations/us-central1/bareMetalClusters/abm-user-cluster1a ...
Observe o seguinte no exemplo de saída:
O campo
name
contém o nome totalmente qualificado do cluster. Ao especificar o nome do cluster em um comando, é possível definir o nome totalmente qualificado ou o nome do cluster, por exemplo,abm-user-cluster1a
, com--project
e--location flags
.A seção
nodeConfigs
contém três camposnodeIp
com os endereços IP dos nós do plano de controle.
Remova o nó com o endereço IP
192.0.2.13
:gcloud container bare-metal cluster update abm-user-cluster1a \ --project=example-project-12345 \ --location=us-central1 \ --control-plane-node-configs 'node-ip=192.0.2.11' --control-plane-node-configs 'node-ip=192.0.2.12'
A saída desse comando é semelhante a:
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1956154681749-6078d9def4030-76686d6e-9fcb1d7] to complete
No exemplo de saída, a string
operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7
é oOPERATION_ID
da operação de longa duração. Descubra o status da operação executando o comando a seguir em outra janela de terminal:gcloud container bare-metal operations describe operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 \ --project= example-project-12345 \ --location=us-central1
Você pode executar o comando de novo de vez em quando para verificar o status.
Adicione o novo nó com o endereço IP
192.0.2.14
:gcloud container bare-metal cluster update abm-user-cluster1a \ --project=example-project-12345 \ --location=us-central1 \ --control-plane-node-configs 'node-ip=192.0.2.11' --control-plane-node-configs 'node-ip=192.0.2.12' --control-plane-node-configs 'node-ip=192.0.2.14'
Verificar as atualizações
kubectl
Também é possível ver o status dos nós e os respectivos pools com o comando kubectl get
.
Por exemplo, o comando a seguir mostra o status dos pools de nós no namespace do cluster cluster-my-cluster
:
kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io
O sistema retorna resultados semelhantes aos seguintes:
NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN
cluster-my-cluster 3 0 0 0 0
cluster-my-cluster-lb 2 0 0 0 0
np1 3 0 0 0 0
Reconciling=1
significa que a etapa de reconciliação ainda está em andamento. Aguarde
até o status mudar para Reconciling=0
.
É possível também conferir o status dos nós do cluster executando o seguinte comando:
kubectl get nodes --kubeconfig=KUBECONFIG
CLI da gcloud
Conforme descrito anteriormente, depois de executar um comando update
, é possível verificar o status da operação usando gcloud container bare-metal
operations describe OPERATIONS_ID
. A saída do comando fornece o status dos nós, por exemplo:
...
metrics:
- intValue: '1'
metric: NODES_RECONCILING
- intValue: '2'
metric: NODES_HEALTHY
- intValue: '0'
metric: NODES_FAILED
- intValue: '0'
metric: NODES_IN_MAINTENANCE
- intValue: '3'
metric: NODES_TOTAL
stage: HEALTH_CHECK
...
Seja qual for a ferramenta usada para atualizar um pool de nós, é possível receber o status atual de um pool de nós executando o comando describe
aplicável, conforme mostrado anteriormente.
Confira como diagnosticar seus clusters em Criar snapshots para diagnosticar clusters.
Pools de endereços do balanceador de carga
bmctl
A seção addressPools
contém campos para especificar pools de balanceamento de carga para os balanceadores de carga em pacote do MetalLB e do protocolo de gateway de borda (BGP, na sigla em inglês). É possível adicionar mais pools de endereços de balanceamento de carga a qualquer momento, mas não é possível remover ou modificar pools de endereços atuais. A partir do GKE em Bare Metal versão 1.16.0, é possível
modificar os valores de addressPools.avoidBuggyIPs
e
addressPools.manualAssign
a qualquer momento.
addressPools:
- name: pool1
addresses:
- 198.51.100.0-198.51.100.4
- 198.51.100.240/28
- name: pool2
addresses:
- 198.51.100.224/28
CLI da gcloud
É possível adicionar mais pools de endereços de balanceamento de carga a qualquer momento para os balanceadores de carga em pacote, mas não é possível remover pools de endereços atuais. A flag especificada em gcloud container bare-metal clusters update
para adicionar um pool de endereços depende do tipo de balanceador de carga em pacote:
- MetalLB (camada 2): use a flag
--metal-lb-address-pools
. - Protocolo de gateway de borda (BGP, na sigla em inglês): use a flag
--bgp-address-pools
.
O valor das flags tem o seguinte formato:
'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
O valor tem segmentos que começam com as palavras-chave pool
, avoid-buggy-ip
, manual-assign
e addresses
. Separe cada segmento com uma vírgula.
pool
: um nome de sua escolha para o pool.avoid-buggy-ips
: se você definir comoTrue
, o controlador de gerenciamento de endereços IP (IPAM) não atribuirá endereços IP que terminam em.0
ou.255
para Serviços. Isso evita o problema de dispositivos de consumo com bugs que descartam por erro o tráfego enviado para esses endereços IP especiais. Se não for especificado,False
será usado como padrão. A partir do GKE em Bare Metal versão 1.16.0, é possível modificar esse valor em um pool de endereços atual.manual-assign
: se você não quiser que o controlador IPAM atribua automaticamente os endereços IP desse pool aos Serviços, defina-o comoTrue
. Em seguida, um desenvolvedor pode criar um Serviço do tipoLoadBalancer
e especificar manualmente um dos endereços do pool. Se não for especificado,manual-assign
será definido comoFalse
. A partir do GKE em Bare Metal versão 1.16.0, é possível modificar esse valor em um pool de endereços atual.Na lista de
addresses
: cada endereço precisa ter um intervalo no formato CIDR ou de hífen. Para especificar um único endereço IP em um pool, como o VIP de entrada, use/32
na notação CIDR, por exemplo, 192.0.2.1/32.
Observe as seguintes regras de sintaxe:
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar espaços em branco.
- Separe cada intervalo de endereços IP com um ponto e vírgula.
É possível especificar mais de uma instância da flag, conforme mostrado no exemplo a seguir:
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=False,manual-assign=True,addresses=198.51.100.0/30;198.51.100.64-198.51.100.72' --metal-lb-address-pools='pool=pool3,avoid-buggy-ips=True,manual-assign=True,addresses=203.0.113.0/28'
Para mais informações sobre pools de endereços do balanceador de carga, consulte loadBalancer.addressPools em "Configurar o balanceamento de carga em pacote".
Impedir a exclusão acidental de clusters
bmctl
Se você adicionar a anotação baremetal.cluster.gke.io/prevent-deletion: "true"
ao arquivo de configuração do cluster, não será possível excluir o cluster. Por exemplo, executar kubectl delete cluster
ou bmctl reset
cluster
produz um erro.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: ci-10c3c6f4d9c698e
namespace: cluster-ci-10c3c6f4d9c698e
annotations:
baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
clusterNetwork:
CLI da gcloud
Se você especificar a flag --add-annotations
com o valor baremetal.cluster.gke.io/prevent-deletion="true"
, não será possível excluir o cluster. Exemplo:
Adicione a anotação para evitar a exclusão acidental do cluster:
gcloud container bare-metal clusters update abm-user-cluster1a \ --project=example-project-12345 \ --location=us-central1 \ --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"
Tente excluir o cluster de usuário:
gcloud container bare-metal clusters delete abm-user-cluster1a \ --project=example-project-12345 \ --location=us-central1 \ --force \ --allow-missing
A saída desse comando terá esta aparência:
ERROR: (gcloud.container.bare-metal.clusters.delete) INVALID_ARGUMENT: invalid request: admission webhook "vcluster.kb.io" denied the request: annotations[baremetal.cluster.gke.io/prevent-deletion]: Invalid value: "true": Annotation "baremetal.cluster.gke.io/prevent-deletion" should be removed in order to delete this cluster
Para remover a anotação, especifique
--remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true"
no comandoupdate
.
Ignorar verificações de simulação
Este recurso está disponível apenas com bmctl update
.
O valor padrão do campo bypassPreflightCheck
é false
. Se você definir esse campo como true
no arquivo de configuração do cluster, as verificações de simulação internas serão ignoradas para aplicar recursos aos clusters atuais.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
annotations:
baremetal.cluster.gke.io/private-mode: "true"
spec:
bypassPreflightCheck: true
Adicionar ou remover administradores de cluster
bmctl
É possível adicionar ou remover um usuário ou uma conta de serviço como administrador de um cluster de usuário. Basta especificar endereços de e-mail na seção clusterSecurity.authorization.clusterAdmin.gcpAccounts
do arquivo de configuração do cluster. As contas recebem o papel de administrador do cluster, fornecendo acesso total a ele.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
clusterSecurity:
authorization:
clusterAdmin:
gcpAccounts:
- alex@example.com
- hao@example.com
- my-sa@example-project-12345.iam.gserviceaccount.com
Ao atualizar um cluster de usuário para adicionar uma conta, inclua todas as contas da lista (contas novas e atuais) porque bmctl update
substitui a lista pelo que você especifica no arquivo de configuração. Para remover uma conta, remova-a do arquivo de configuração do cluster e execute bmctl update
.
gcloud CLI
É possível adicionar ou remover um usuário ou uma conta de serviço como administrador do cluster.
Basta especificar um endereço de e-mail na flag --admin-users
. A flag aceita apenas um endereço de e-mail. Para adicionar vários usuários, especifique uma conta em cada flag, por exemplo:
gcloud container bare-metal clusters update abm-user-cluster1a \
--project=example-project-12345 \
--location=us-central1 \
--admin-users=alex@example.com \
--admin-users=hao@example.com
--admin-users=my-sa@example-project-12345.iam.gserviceaccount.com
O comando update
substitui toda a lista de permissões. Especifique todos os usuários atuais e novos que você quer que sejam administradores do cluster.
Definir um usuário de login
Você pode especificar um nome de usuário não raiz que queira usar para acesso com o recurso SUDO sem senha às máquinas de nós do cluster. Sua chave SSH,
sshPrivateKeyPath
, precisa funcionar para o usuário especificado. As operações de criação e atualização de clusters verificam se as máquinas de nós podem ser acessadas com o usuário especificado e com a chave SSH.
bmctl
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
annotations:
baremetal.cluster.gke.io/private-mode: "true"
spec:
nodeAccess:
loginUser: abm
CLI da gcloud
Especifique o usuário que você quer usar para acessar máquinas de nós na flag --login-user
, por exemplo:
gcloud container bare-metal clusters update abm-user-cluster1a \
--project=example-project-12345 \
--location=us-central1 \
--login-user=abm
Rede avançada
Você configura recursos de rede avançados em vários recursos personalizados após a criação do cluster. Para usar os recursos personalizados e os de rede relacionados, ative a rede avançada ao criar o cluster.
bmctl
Defina clusterNetwork.advancedNetworking
como true
na configuração do cluster ao criá-lo:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
clusterNetwork:
...
advancedNetworking: true
...
gcloud CLI
Inclua a flag --enable-advanced-networking
no comando gcloud container bare-metal clusters create
ao criar o cluster.
Depois que o cluster for criado com a rede avançada ativada, será possível configurar os recursos personalizados descritos nesta seção usando kubectl apply
.
NetworkGatewayGroup
O recurso personalizado NetworkGatewayGroup
é usado para fornecer endereços IP flutuantes para recursos de rede avançados, como o gateway NAT de saída ou o recurso de balanceamento de carga em pacote com o BGP.
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
Balanceamento de carga do BGP
Configure o balanceamento de carga do protocolo de gateway de borda (BGP, na sigla em inglês) no recurso do
cluster e em outros recursos personalizados. Os comandos gcloud container bare-metal clusters
create
e update
oferecem suporte à configuração do BGP no recurso de cluster, mas não nos recursos personalizados.
Quando você configura balanceadores de carga em pacote com o BGP, o balanceamento de carga do plano de dados usa, por padrão, os mesmos pares externos especificados para o peering do plano de controle. Como alternativa, é possível configurar o balanceamento de carga do plano de dados separadamente usando os recursos personalizados BGPLoadBalancer
e BGPPeer
. Para mais informações, consulte Configurar balanceadores de carga em pacote com o BGP.
BGPLoadBalancer
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
name: default
namespace: cluster-bm
spec:
peerSelector:
cluster.baremetal.gke.io/default-peer: "true"
BGPPeer
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
name: bgppeer1
namespace: cluster-bm
labels:
cluster.baremetal.gke.io/default-peer: "true"
spec:
localASN: 65001
peerASN: 65002
peerIP: 10.0.3.254
sessions: 2
Aumentar o intervalo da rede de serviço
Para criar mais serviços do que o limite inicial, é possível reduzir a máscara CIDR de serviço IPv4 para aumentar a rede de serviço do cluster. Reduzir a máscara (o valor após "/") resulta em um intervalo de rede maior. Só é possível aumentar o intervalo do CIDR de serviço IPv4. O intervalo de rede não pode ser reduzido, o que significa que a máscara (o valor após "/") não pode ser aumentada.
bmctl
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
...
clusterNetwork:
services:
cidrBlocks:
- 192.0.2.0/14
...
CLI da gcloud
Para aumentar o intervalo do CIDR de serviço IPv4 em um cluster de usuário, especifique o novo intervalo na flag --island-mode-service-address-cidr-blocks
.
gcloud container bare-metal clusters update cluster1 \
--project=example-project-12345 \
--location=us-central1 \
--island-mode-service-address-cidr-blocks=192.0.2.0/14
Definir as configurações de extração de imagem do kubelet
O kubelet é executado em cada nó do cluster. O kubelet é responsável por monitorar contêineres em um nó e garantir que eles estejam íntegros. Quando necessário, o kubelet consulta e extrai imagens do Container Registry.
Atualizar as configurações do kubelet manualmente e mantê-las sincronizadas em todos os nós do cluster pode ser um desafio. Para piorar, as alterações manuais da configuração do kubelet nos nós são perdidas quando você faz upgrade do cluster.
Para ajudar a tornar as atualizações sincronizadas mais fáceis e persistentes, o GKE em Bare Metal permite especificar algumas configurações do kubelet para cada um dos pools de nós do cluster: nós do plano de controle, do balanceador de carga e de trabalho. As configurações se aplicam a todos os nós em um determinado pool e persistem por meio de upgrades de cluster. Os campos dessas configurações são mutáveis, para que você possa atualizá-los a qualquer momento, não apenas durante a criação do cluster.
bmctl
Os campos compatíveis a seguir controlam as operações de pull do Container Registry para o kubelet:
registryBurst
(padrão: 10)registryPullQPS
(padrão: 5)serializeImagePulls
(padrão: true)
Para mais informações sobre cada um dos campos de configuração do kubelet, consulte a Referência do campo de configuração do cluster.
É possível definir esses campos nas seções kubeletConfig
da especificação do cluster e do NodePool para os seguintes pools de nós:
- Especificação de cluster:
- Nós do plano de controle
spec.controlPlane.nodePoolSpec.kubeletConfig
- Nós do balanceador de carga
spec.loadBalancer.nodePoolSpec.kubeletConfig
- Especificação do NodePool:
- Nós de trabalho
spec.kubeletConfig
O exemplo a seguir mostra os campos adicionados com os valores padrão no arquivo de configuração do cluster. Observe que a anotação preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
é obrigatória.
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
annotations:
preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
spec:
...
controlPlane:
nodePoolSpec:
kubeletConfig:
registryBurst: 10
registryPullQPS: 5
serializeImagePulls: true
...
loadBalancer:
nodePoolSpec:
kubeletConfig:
registryBurst: 10
registryPullQPS: 5
serializeImagePulls: true
...
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: node-pool-new
namespace: cluster-cluster1
spec:
clusterName: cluster1
...
kubeletConfig:
registryBurst: 10
registryPullQPS: 5
serializeImagePulls: true
Em cada caso, a configuração se aplica a todos os nós do pool.
CLI da gcloud
As flags a seguir controlam as operações de pull do Container Registry para o kubelet:
Nós do plano de controle
Nós do balanceador de carga
- --bgp-load-balancer-registry-burst
- --bgp-load-balancer-registry-pull-qps
- --disable-bgp-load-balancer-serialize-image-pulls
- --enable-bgp-load-balancer-serialize-image-pulls
- --metal-lb-load-balancer-registry-burst
- --metal-lb-load-balancer-registry-pull-qps
- --disable-metal-lb-load-balancer-serialize-image-pull
- --enable-metal-lb-load-balancer-serialize-image-pulls
Nós de trabalho
Como usar
Veja algumas considerações para ajustar pulls da imagem:
Como as imagens são extraídas em série por padrão, um pull de imagem que demora muito pode atrasar todos os outros pulls de imagem programados em um nó. Pulls de imagem atrasados podem bloquear o processo de upgrade, especialmente quando novas imagens do GKE em bare metal precisam ser implantadas em um nó. Se você for afetado por atrasos de pulls de imagem, desative a opção de serializar pulls de imagem para permitir pulls de imagem paralelos.
Se você encontrar erros de limitação de pull de imagem, como
pull QPS exceeded
, aumente*-registry-pull-qps
e*-registry-burst
para aumentar a capacidade de processamento do pull de imagem. Esses dois campos ajustam a taxa de pull e o tamanho da fila e podem ajudar a resolver outros problemas relacionados à limitação. Valores negativos não são permitidos.