Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.
Nesta página, descrevemos os campos aceitos no arquivo de configuração do cluster do Google Distributed Cloud. A tabela a seguir identifica se o campo é obrigatório para cada campo. A tabela também mostra quais campos são mutáveis, o que significa que
os campos podem ser alterados após a criação de um cluster. Conforme observado na tabela,
alguns campos mutáveis só podem ser alterados durante um upgrade de cluster.
Como gerar um modelo para o arquivo de configuração
É possível criar um arquivo de configuração de cluster com o comando bmctl create config. Embora alguns campos tenham valores padrão e outros, como metadata.name, possam ser preenchidos automaticamente, esse arquivo de configuração de formato YAML é um modelo para especificar informações sobre o cluster.
Para criar um novo arquivo de configuração de cluster, use o seguinte comando na
pasta /baremetal:
bmctlcreateconfig-cCLUSTER_NAME
Substitua CLUSTER_NAME pelo nome do cluster que você quer
criar. Para mais informações sobre bmctl, consulte a ferramenta bmctl.
Para um exemplo do arquivo de configuração de cluster gerado, consulte
Amostra de arquivo de configuração de cluster (em inglês).
Como preencher o arquivo de configuração
No arquivo de configuração, insira os valores de campo conforme descrito na tabela de referência de campo a seguir antes de criar ou fazer upgrade do cluster.
Esta seção contém as configurações necessárias para usar o OpenID Connect (OIDC).
Com o OIDC, você usa seu provedor de identidade atual para gerenciar a autenticação de usuários e grupos em clusters do Google Distributed Cloud.
Opcional. Um
certificado codificado em PEM codificado por base64 para o provedor OIDC. Para criar a string, codifique o certificado, incluindo cabeçalhos, em
base64. Inclua a string
resultante em certificateAuthorityData como uma única linha.
Por exemplo (amostra ajustada para caber na tabela):
Opcional. Booleano (true|false). Especifica se um proxy reverso está implantado no cluster para conectar o console do Google Cloud a um provedor de identidade local que não seja acessível publicamente pela Internet. Se o provedor de identidade não estiver acessível pela Internet pública, defina esse campo como true para autenticar com o console do Google Cloud. Por padrão, esse valor está definido como false.
Opcional. String. Prefixo anexado a declarações de grupos para evitar conflitos com nomes atuais. Por exemplo, um grupo
dev e um prefixo oidc:, oidc:dev.
Opcional. String do URL. URL ao qual são enviadas solicitações de autorização para seu OpenID, como
https://example.com/adfs. O servidor da API Kubernetes usa esse URL para descobrir
chaves públicas de verificação de tokens. O
URL precisa usar HTTPS.
Opcional. String do URL. O URL de redirecionamento que kubectl usa para autorização. Quando você ativa o OIDC, é necessário especificar um
valor kubectlRedirectURL.
Opcional. String do URL. Servidor proxy a ser usado para que o cluster se conecte ao provedor OIDC, se aplicável. O valor precisa incluir um nome do host/endereço IP e,
opcionalmente, uma porta, nome de usuário e senha.
Exemplo: http://user:password@10.10.10.10:8888.
Opcional. Lista delimitada por vírgulas. Outros escopos a serem enviados ao provedor OpenID. O Microsoft Azure e o Okta
exigem o escopo offline_access.
Opcional. Booleano (true|false). Quando definida como
true, as verificações de simulação internas são ignoradas ao
aplicar recursos a clusters atuais. O padrão é false.
Mutabilidade: esse valor pode ser modificado para clusters atuais
com o comando bmctl update.
String. O caminho para a chave da conta de serviço de operações.
O Google Distributed Cloud usa a conta de serviço de operações para autenticação com o Google Cloud Observability para acesso à API Logging e à API Monitoring. Com a exceção de clusters de usuários, a chave da conta de serviço de operações é obrigatória. Os clusters de usuários usam as credenciais especificadas para o cluster de gerenciamento (administrador ou híbrido).
Não é possível desativar o Cloud Logging e o Cloud Monitoring para os clusters.
String. Obrigatório. O nome do cluster ao qual você está adicionando o pool de nós. Crie o recurso de pool de nós no mesmo namespace do
cluster associado e faça referência ao nome do cluster neste campo. Para mais informações, consulte Adicionar e remover pools de nós em um cluster.
Booleano. Defina este campo como true para ativar recursos avançados
de rede, como o balanceamento de carga em pacote com o BGP ou o
gateway NAT de saída. Esses dois recursos usam o Gateway de rede para GDC. O Gateway de rede para GDC é o principal componente para ativar recursos avançados de rede no GKE Enterprise e no Google Kubernetes Engine (GKE). Um dos principais benefícios do Gateway de rede para GDC é que é possível alocar dinamicamente endereços IP flutuantes de um conjunto de endereços especificado em um recurso personalizado NetworkGatewayGroup.
Booleano. Defina este campo como false para desativar as capabilities de Entrada incluídas no Google Distributed Cloud. Os recursos de entrada
agrupados para o cluster são compatíveis apenas com a entrada. Se você fizer a integração com o Istio ou o Cloud Service Mesh para aproveitar os benefícios extras de uma malha de serviço totalmente funcional, recomendamos desativar a Entrada em pacote. Por padrão, esse campo é definido como true. Esse campo
não está presente no arquivo de configuração do cluster gerado. Só é possível
desativar a Entrada agrupada para clusters da versão 1.13.0 e posteriores.
Booleano. Defina este campo como true para ativar o modelo de rede do cluster
no modo plano. No modo plano, cada pod tem o próprio endereço IP
exclusivo. Os pods podem se comunicar diretamente sem a
necessidade de um gateway intermediário ou de uma conversão de endereços de rede (NAT, na sigla em inglês).
flatIPv4 é false por padrão. É possível
ativar o modo plano apenas durante a criação do cluster. Depois de ativar o modo
plano para o cluster, não será possível desativá-lo.
Opcional. String. Especifica o modo de rede para o balanceamento de carga do Dataplane V2. A conversão de endereços de rede de origem (SNAT, na sigla em inglês) é o modo de rede padrão. O modo de retorno do servidor direto (DSR, na sigla em inglês) resolve problemas com o balanceamento de carga SNAT. No modo DSR (forwardMode: dsr), o nó do balanceador de carga usa opções de IP para salvar o endereço de origem do cliente.
O modo de rede para o balanceamento de carga do Dataplane V2 só pode ser configurado no momento da criação do cluster.
Obrigatório. Intervalo de endereços IPv4 no formato de bloco CIDR. Os pods especificam os intervalos de IP a partir dos quais as redes de pod são alocadas.
Intervalo CIDR mínimo do pod:valor de máscara de
/18, que corresponde a um tamanho de 14 bits (16.384 endereços
IP).
Intervalo máximo de CIDR do pod: valor de máscara de
/8, que corresponde a um tamanho de 24 bits (16.777.216 endereços
IP).
Obrigatório. Intervalo de endereços IPv4 no formato de bloco CIDR. Especifique o intervalo de endereços IP a partir dos quais os endereços IP virtuais (VIPs) de serviços são alocados. O intervalo não pode se sobrepor a nenhuma sub-rede acessível pela rede. Para mais informações sobre a alocação de endereços para
Internets particulares, consulte
RFC 1918 (em inglês).
Desde o Google Distributed Cloud versão 1.15.0, esse campo é mutável. Se precisar, aumente o número de endereços IP alocados para serviços depois de criar um cluster. Para mais informações, consulte Aumentar o intervalo da rede de serviços.
Só é possível aumentar o intervalo do CIDR de serviço IPv4. Não é possível reduzir o intervalo de rede. Isso significa que não é possível aumentar a máscara (o valor após "/").
Intervalo CIDR mínimo de serviço: valor de máscara de
/24, que corresponde a um tamanho de 8 bits (256
endereços).
Intervalo máximo de CIDR de serviço: valor de máscara de
/12, que corresponde a um tamanho de 20 bits (1.048.576
endereços IP).
Booleano. Os registros de auditoria do Cloud são úteis para investigar solicitações de API
suspeitas e coletar estatísticas Os registros de auditoria do Cloud são ativados
(disableCloudAuditLogging: false) por padrão. Defina como
true para desativar os registros de auditoria do Cloud.
Este campo não é mais usado e não tem efeito. A geração de registros e o monitoramento de aplicativos estão ativados no recurso personalizado do Stackdriver. Para mais informações sobre como ativar a geração de registros e o monitoramento de aplicativos, consulte Ativar a geração de registros e o monitoramento de aplicativos.
String. : uma região do Google Cloud em que você quer armazenar
registros do Logging e métricas do Monitoring.
É recomendável
escolher uma região próxima ao seu data center local. Para mais informações, consulte Locais globais.
Opcional. O campo gcpAccounts especifica uma lista de
contas que recebem o papel clusterrole/cluster-admin do controle de acesso baseado em função (RBAC, na sigla em inglês)
do Kubernetes. As contas com esse
papel têm acesso total a todos os recursos do cluster em todos
os namespaces. Esse campo também configura as políticas do RBAC que permitem que
as contas especificadas usem
o gateway de conexão
para executar comandos kubectl no cluster. Isso será
prático se você tiver vários clusters para gerenciar, especialmente em
um ambiente híbrido com clusters do GKE e
locais.
Esse campo usa uma matriz de nomes de conta. Há suporte para contas
de usuário e contas de serviço. Para os usuários, especifique os
endereços de e-mail da conta do Google Cloud. Para contas de serviço, especifique os
endereços de e-mail no seguinte formato:
SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com.
Por exemplo:
Ao atualizar um cluster para adicionar uma conta, não se esqueça de incluir
todas as contas na lista (contas novas e existentes) porque o
comando de atualização substitui a lista pelo que você especifica
na atualização.
Esse campo se aplica apenas a clusters que podem executar cargas de trabalho. Por
exemplo, não é possível especificar gcpAccounts para clusters de
administrador.
Opcional. Booleano (true|false). Ative ou desative contêineres do sistema bare metal sem raiz. Quando esse campo está ativado, os contêineres do sistema bare metal são executados como usuários não raiz com um ID do usuário no intervalo entre 2.000 e 5.000. Quando desativados, os contêineres do sistema bare metal são executados como um usuário raiz. Por padrão, esse recurso é ativado. Não é recomendável desativar esse recurso porque a execução de contêineres como usuário raiz representa um risco à segurança. Após a criação do cluster, esse campo só poderá ser alternado durante o upgrade. Para mais informações, consulte Não execute contêineres como usuário raiz.
Opcional. Booleano (true|false). Ative ou desative seccomp em todo o cluster. Quando esse campo está desativado, os contêineres sem um perfil seccomp no arquivo de configuração do cluster são executados sem confinamento. Quando esse campo está ativado, os mesmos contêineres são protegidos usando o perfil seccomp padrão do ambiente de execução do contêiner. Esse recurso é ativado por padrão.
Após a criação do cluster, esse campo só poderá ser alternado durante o upgrade.
Para mais informações, consulte Usar seccomp para restringir contêineres.
Opcional. Número inteiro. Valor padrão: 2000. Os contêineres do sistema no Google Distributed Cloud ajudam a instalar e gerenciar clusters. Os IDs dos usuários (UIDs) e IDs dos grupos (GIDs) usados por esses contêineres podem ser controlados pelo campo startUIDRangeRootlessContainers na especificação do cluster. Os contêineres do sistema usam os UIDs e os GIDs no intervalo de startUIDRangeRootlessContainers a startUIDRangeRootlessContainers + 2999, que fornece um intervalo 2000–4999 por padrão. Ao atualizar startUIDRangeRootlessContainers, selecione um valor que garanta que os espaços de UID e GID usados pelos contêineres do sistema não se sobreponham aos atribuídos às cargas de trabalho do usuário. O valor de startUIDRangeRootlessContainers pode ser alterado apenas durante os upgrades.
Opcional. Uma matriz de strings (nomes de domínio e endereços IP). Um nome alternativo do assunto (SAN, na sigla em inglês) é um recurso de certificados SSL que permite definir os nomes de domínio e subdomínios em que você quer que um certificado seja válido. Em um cluster do Google Distributed Cloud, os SANs do certificado do servidor da API incluem os endereços IP e VIP dos nós do plano de controle e os nomes de DNS do Kubernetes por padrão.
Use esse campo para adicionar SANs extras ao certificado do servidor da API para o cluster. Os nomes de domínio precisam estar em conformidade com o RFC 1035.
Para mais informações, consulte Adicionar domínios ao certificado do servidor da API.
Esta seção especifica os endereços IP do pool de nós usado pelo plano de controle e componentes. A especificação do pool de nós do plano de controle, como a especificação do pool de nós do balanceador de carga, é especial. Esta especificação declara e controla recursos críticos do cluster. A origem canônica desse recurso é esta seção no arquivo de configuração do cluster. Não modifique diretamente os recursos do pool de nós do plano de controle de nível superior. Modifique as seções associadas no arquivo de
configuração do cluster.
Opcional. Número inteiro (não negativo). Especifica a quantidade máxima de solicitações de envio de imagem que podem ser adicionadas à fila de processamento para lidar com picos de solicitações. Assim que o envio é iniciado, uma nova solicitação pode ser adicionada à fila. O valor padrão é 10. Esse campo corresponde à opção de configuração do kubelet registryBurst (v1beta1).
O valor de registryPullQPS tem precedência sobre essa configuração. Por exemplo, com as configurações padrão, são permitidos bursts de até 10 consultas simultâneas, mas eles precisam ser processados com a taxa padrão de cinco consultas por segundo. Esse comportamento de burst é usado somente quando registryPullQPS é maior que 0.
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Número inteiro (não negativo). Especifica a taxa de processamento de consultas por segundo (QPS) dos envios de imagens do Container Registry.
Quando registryPullQPS é definido como um valor maior que 0, a taxa de consulta é restrita a esse número de consultas por segundo. Se registryPullQPS estiver definido como 0, não haverá restrição na taxa de consulta. O valor padrão é 5.
Esse campo corresponde à opção de configuração do kubelet registryPullQPS (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Booleano (true|false). Esse campo especifica se os envios do Container Registry são processados em paralelo ou um de cada vez. O padrão é true: especifica que os envios são processados um de cada vez. Quando definido como false, o kubelet envia as imagens em paralelo. Esse campo corresponde à opção
de configuração do kubelet
serializeImagePulls (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Obrigatório. Uma matriz de endereços IP. Normalmente, essa matriz é um endereço IP para uma única máquina ou endereços IP para três máquinas para uma implantação de alta disponibilidade (HA, na sigla em inglês).
Obrigatório. String (endereço IPv4). Ao especificar um pool de nós, use o campo address para especificar o endereço IPv4 padrão para acesso SSH em cada nó. O acesso SSH é necessário para operações administrativas do cluster, como instalações e upgrades. Por padrão, esse endereço IP também é usado para dados e tráfego do Kubernetes. No entanto, se você especificar o endereço k8sIP para um determinado nó, o tráfego será dividido entre os dois endereços do nó, com o endereço k8sIP usado exclusivamente para dados e tráfego do Kubernetes.
Opcional. String (endereço IPv4). Quando você especifica o endereço k8sIP opcional em um nó, ele fica dedicado ao processamento de dados e do tráfego do Kubernetes do nó, como solicitações e respostas para a API Kubernetes, o kubelet e as cargas de trabalho. Quando você especifica k8sIP, o endereço IP padrão do nó nodePoolSpec.nodes.address é usado exclusivamente para conexões SSH com o nó. Se você não especificar um endereço k8sIP, o endereço IP padrão do nó processará todo o tráfego dele.
O arquivo de configuração de cluster gerado por bmctl para o Google Distributed Cloud inclui campos para especificar caminhos para arquivos de credenciais e chaves no sistema de arquivos local. Essas credenciais e chaves são necessárias para conectar os clusters entre si e com o seu projeto do Google Cloud.
String. O caminho para a chave da conta de serviço do Container Registry. A conta de serviço do Container Registry é um agente de serviço que atua em nome do Container Registry ao interagir com os serviços do Google Cloud.
Opcional. String. Valor padrão: global.
A associação da frota para seus clusters é gerenciada pelo serviço de frota (gkehub.googleapis.com) e pelo serviço de conexão (gkeconnect.googleapis.com). A associação da frota pode ser global ou regional. Você tem a opção de usar gkeConnect.location para especificar a região do Google Cloud em que os serviços de frota e conexão são executados, de modo que o tráfego fique restrito à sua região.
Para ver uma lista de regiões aceitas, consulte Regiões compatíveis com a API GKE On-Prem.
Se não for especificada, as instâncias globais dos serviços serão usadas.
Observe o seguinte:
Os clusters criados em versões anteriores à 1.28 são gerenciados pelos serviços globais de frota e conexão.
Os novos clusters criados usando os clientes da API GKE On-Prem, como o console do Google Cloud, a CLI do Google Cloud ou o Terraform, usam a mesma região especificada para a API GKE On-Prem.
Para novos clusters, se você incluir esse campo, a região especificada precisará ser a mesma configurada em gkeOnPremAPI.location. Se as regiões não forem iguais, a criação do cluster falhará.
Obrigatório, string O ID do projeto do Google Cloud que você quer usar para conectar
o cluster ao Google Cloud. Ele também é conhecido como projeto host da frota.
String. O caminho para a chave da conta de serviço do agente.
O Google Distributed Cloud usa essa conta de serviço para manter uma conexão entre o Google Distributed Cloud e o Google Cloud.
String. O caminho para a chave da conta de serviço do registro.
O Google Distributed Cloud usa essa conta de serviço para registrar seus clusters de usuários com o Google Cloud.
Na versão 1.16 e mais recentes, se a API GKE On-Prem estiver ativada no projeto do Google Cloud, todos os clusters do projeto serão automaticamente registrados na API GKE On-Prem na região configurada em clusterOperations.location.
Se você quiser registrar todos os clusters do projeto na API GKE On-Prem, siga as etapas em Antes de começar para ativar e usar a API GKE On-Prem no projeto.
Se você não quiser registrar o cluster na API GKE On-Prem, inclua esta seção e defina gkeOnPremAPI.enabled como false.
Se você não quiser registrar clusters no projeto, desative gkeonprem.googleapis.com (o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.
Se você quiser registrar todos os clusters do projeto na API GKE On-Prem, siga as etapas em Antes de começar para ativar e usar a API GKE On-Prem no projeto.
Se você não quiser registrar o cluster na API GKE On-Prem, inclua esta seção e defina gkeOnPremAPI.enabled como false.
Se você não quiser registrar clusters no projeto, desative gkeonprem.googleapis.com (o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.
O registro do cluster de administrador ou de usuário na API GKE On-Prem permite usar ferramentas padrão (o console do Google Cloud, a CLI do Google Cloud ou o Terraform) para ver detalhes do cluster e gerenciar o ciclo de vida dele. Por exemplo, execute comandos da gcloud CLI para receber informações sobre o cluster.
A API GKE On-Prem armazena metadados de estado do cluster no Google Cloud.
Esses metadados permitem que a API gerencie o ciclo de vida do cluster. As ferramentas padrão usam a API GKE On-Prem e são chamadas coletivamente de clientes da API GKE On-Prem.
Se você definir gkeOnPremAPI.enabled como true, antes de criar ou atualizar o cluster usando bmctl, siga as etapas em Antes de começar para ativar e inicializar a API GKE On-Prem.
Depois de adicionar esta seção e criar ou atualizar o cluster e, em seguida, remover a seção e atualizar o cluster, a atualização falhará.
Se preferir criar o cluster usando uma ferramenta padrão em vez de bmctl, consulte:
Por padrão, o cluster será registrado na API GKE On-Prem se essa API estiver ativada no seu projeto. Defina como false se você não quiser registrar o cluster.
Depois que o cluster é registrado na API GKE On-Prem, se você precisar cancelar esse registro, faça a alteração a seguir e atualize o cluster:
A região do Google Cloud em que a API GKE On-Prem executa e armazena metadados do cluster. Escolha uma das regiões com suporte. Se gkeOnPremAPI.enabled for true, precisará ser uma string não vazia. Se gkeOnPremAPI.enabled for false, não inclua esse campo.
Se essa seção não estiver incluída no arquivo de configuração, esse campo será definido como clusterOperations.location.
String. Define o bloco CIDR do nó IPv4. Os nós podem ter apenas um intervalo
de cada família. Esse bloco CIDR precisa corresponder ao CIDR de pod descrito no
recurso Cluster.
Número inteiro. Define o tamanho da máscara para o bloco CIDR do IPv4 do nó. Por
exemplo, o valor 24 se traduz em uma máscara de rede
/24. Verifique se a máscara de rede de bloco de CIDR do nó é maior
do que a quantidade máxima de pods que o kubelet pode programar, que é
definido na sinalização --max-pods do kubelet.
Número inteiro. Define o tamanho da máscara para o bloco CIDR do IPv6 do nó. Por
exemplo, o valor 120 se traduz em uma máscara de rede
/120. Verifique se a máscara de rede de bloco de CIDR do nó é maior
do que a quantidade máxima de pods que o kubelet pode programar, que é
definido na sinalização --max-pods do kubelet.
Opcional. Número inteiro (não negativo). Especifica a quantidade máxima de solicitações de envio de imagem que podem ser adicionadas à fila de processamento para lidar com picos de solicitações. Assim que o envio é iniciado, uma nova solicitação pode ser adicionada à fila. O valor padrão é 10. Esse campo corresponde à opção de configuração do kubelet registryBurst (v1beta1).
O valor de registryPullQPS tem precedência sobre essa configuração. Por exemplo, com as configurações padrão, são permitidos bursts de até 10 consultas simultâneas, mas eles precisam ser processados com a taxa padrão de cinco consultas por segundo. Esse comportamento de burst é usado somente quando registryPullQPS é maior que 0.
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Número inteiro (não negativo). Especifica a taxa de processamento de consultas por segundo (QPS) dos envios de imagens do Container Registry.
Quando registryPullQPS é definido como um valor maior que 0, a taxa de consulta é restrita a esse número de consultas por segundo. Se registryPullQPS estiver definido como 0, não haverá restrição na taxa de consulta. O valor padrão é 5.
Esse campo corresponde à opção de configuração do kubelet registryPullQPS (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Booleano (true|false). Esse campo especifica se os envios do Container Registry são processados em paralelo ou um de cada vez. O padrão é true: especifica que os envios são processados um de cada vez. Quando definido como false, o kubelet envia as imagens em paralelo. Esse campo corresponde à opção
de configuração do kubelet
serializeImagePulls (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Obsoleto. Desde a versão 1.11.2, é possível atualizar apenas o recurso personalizado VMRuntime para ativar ou desativar o ambiente de execução de VM no GDC.
Booleano. Determina se a emulação de software é usada ou não para executar
máquinas virtuais. Se o
nó for compatível com a virtualização de hardware, defina useEmulation como false para
melhorar o desempenho. Se a virtualização de hardware não for compatível ou você não tiver certeza, defina-a como true.
Opcional. Mapeamento (pares de chave-valor).
Os rótulos são reconciliados para os nós do pool de nós, a menos que a
anotação baremetal.cluster.gke.io/label-taint-no-sync
seja aplicada ao cluster. Para mais informações sobre rótulos, consulte
Rótulos e seletores.
Objeto O nome e uma matriz de endereços IP para o pool do balanceador
de carga do cluster. A configuração do pool de endereços só é válida para o modo de balanceamento de carga bundled em clusters que não são de administrador. É possível adicionar novos pools de endereços a qualquer momento, mas não é possível remover pools de endereços atuais.
Um pool de endereços existente só pode ser editado com alterações nos campos avoidBuggyIPs e manualAssign.
Matriz de intervalos de endereços IP. Especifique uma lista de intervalos de IPs não sobrepostos para o balanceador de carga do plano de dados. Todos os endereços precisam estar na mesma sub-rede que os nós do balanceador de carga.
Opcional. Booleano (true | false). Se true,
o pool omite os endereços IP que terminam em .0 e .255.
Alguns hardwares de rede descartam
tráfego para esses endereços especiais. É possível omitir esse campo. O valor padrão dele
é false.
Opcional. Booleano (true | false). Se true,
os endereços neste pool não serão atribuídos automaticamente aos serviços do
Kubernetes. Se true, um endereço IP nesse pool só será usado quando for especificado explicitamente por um serviço. É possível omitir esse campo. O valor padrão dele
é false.
Opcional. Objeto (lista de mapeamentos). Nesta seção, especificamos um ou mais pares de protocolo de gateway de borda (BGP, na sigla em inglês) da rede local (externa ao cluster). Você especifica pares do BGP ao configurar a parte do balanceamento de carga do plano de controle que faz parte da solução de balanceamento de carga em pacote que usa o BGP. Cada par é especificado com um mapeamento, que consiste em um endereço IP, um número de sistema autônomo (ASN, na sigla em inglês) e, opcionalmente, uma lista de um ou mais endereços IP para nós do plano de controle. A configuração de peering
do BGP para balanceamento de carga do plano de controle não pode ser atualizada após
a criação do cluster.
Opcional. String. : o número do sistema autônomo da
rede que contém o dispositivo de peering externo. Especifique um ASN para cada peer BGP
configurado para o balanceamento de carga do plano de controle, ao configurar a
solução de balanceamento de carga em pacote que usa o BGP.
Para mais informações, consulte
Configurar balanceadores de carga em pacote com o BGP.
Opcional. Matriz de endereços IP (IPv4). Um ou mais endereços IP para
nós do plano de controle que se conectam ao peer de BGP externo, quando você
configura a solução de balanceamento de carga em pacote que usa o BGP. Se você não especificar nenhum nó do plano de controle, todos os nós do plano de controle se conectarão ao par externo. Se você especificar um ou mais endereços IP, apenas os
nós especificados participarão das sessões de peering.
Para mais informações, consulte
Configurar balanceadores de carga em pacote com o BGP.
Opcional. String. Especifica o número de sistema autônomo (ASN, na sigla em inglês) para o cluster que está sendo criado. Esse campo é usado ao configurar a solução de balanceamento de carga
em pacote que usa o protocolo de gateway de borda (BGP, na sigla em inglês).
Para mais informações, consulte
Configurar balanceadores de carga em pacote com o BGP.
Obrigatório. String. Especifica o modo de balanceamento de carga. No modo bundled, o Google Distributed Cloud instala um balanceador de carga nos respectivos nós durante a criação do cluster. No modo manual, o cluster depende de um balanceador de carga externo configurado manualmente. Para mais informações, consulte
Visão geral dos balanceadores de carga.
Opcional. Use esta seção para configurar um pool de nós do balanceador de carga. Os
nós especificados fazem parte do cluster do Kubernetes e executam cargas de trabalho
e balanceadores de carga regulares. Se você não especificar um pool de nós, os nós do plano de controle serão usados para balanceamento de carga. Esta seção se aplica somente quando o modo de balanceamento de carga está definido como bundled.
Se você quiser impedir a execução de cargas de trabalho em um pool de nós do balanceador de carga, adicione o seguinte taint ao nó:
node-role.kubernetes.io/load-balancer:NoSchedule
O Google Distributed Cloud adiciona tolerâncias desse taint aos pods necessários para balanceamento de carga.
Opcional. Número inteiro (não negativo). Especifica o número máximo de solicitações de envio de imagem que podem ser adicionadas à fila de processamento para lidar com picos de solicitações. Assim que o envio é iniciado, uma nova solicitação pode ser adicionada à fila. O valor padrão é 10. Esse campo corresponde à opção de configuração do kubelet registryBurst (v1beta1).
O valor de registryPullQPS tem precedência sobre essa configuração. Por exemplo, com as configurações padrão, são permitidos bursts de até 10 consultas simultâneas, mas eles precisam ser processados com a taxa padrão de cinco consultas por segundo. Esse comportamento de burst é usado somente quando registryPullQPS é maior que 0.
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Número inteiro (não negativo). Especifica a taxa de processamento de consultas por segundo (QPS) dos envios de imagens do Container Registry.
Quando registryPullQPS é definido como um valor maior que 0, a taxa de consulta é restrita a esse número de consultas por segundo. Se registryPullQPS estiver definido como 0, não haverá restrição na taxa de consulta. O valor padrão é 5.
Esse campo corresponde à opção de configuração do kubelet registryPullQPS (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Opcional. Booleano (true|false). Esse campo especifica se os envios do Container Registry são processados em paralelo ou um de cada vez. O padrão é true: especifica que os envios são processados um de cada vez. Quando definido como false, o kubelet envia as imagens em paralelo. Esse campo corresponde à opção
de configuração do kubelet
serializeImagePulls (v1beta1).
Esse campo pode ser definido sempre que você criar, atualizar ou fazer upgrade de um cluster, e a configuração persiste com os upgrades de cluster. Para mais informações, consulte Definir configurações de envio de imagem do kubelet.
Esta seção contém uma matriz de endereços IP para os nós no seu pool de nós do balanceador de carga.
Por padrão, todos os nós no pool de nós do balanceador de carga precisam estar na mesma sub-rede de camada 2 que os VIPs do balanceador de carga configurados na seção loadBalancer.addressPools do arquivo de configuração. No entanto, se você especificar um endereço IP k8sIP do Kubernetes para um nó, somente esse endereço precisará estar na mesma sub-rede de camada 2 que os outros VIPs do balanceador de carga.
Opcional. String (endereço IPv4). Ao especificar um pool de nós, use o campo address para especificar o endereço IPv4 padrão para acesso SSH em cada nó. O acesso SSH é necessário para operações administrativas do cluster, como instalações e upgrades. Por padrão, esse endereço IP também é usado para dados e tráfego do Kubernetes. No entanto, se você especificar o endereço k8sIP para um determinado nó, o tráfego será dividido entre os dois endereços do nó, com o endereço k8sIP usado exclusivamente para dados e tráfego do Kubernetes.
Embora os nós no pool de nós do balanceador de carga possam executar cargas de trabalho, elas são separadas dos nós nos pools de nós de trabalho. Não é possível incluir um determinado nó de cluster em mais de um pool de nós. Endereços IP de nós sobrepostos bloqueiam a criação de clusters e outras operações de clusters.
Opcional. String (endereço IPv4). Quando você especifica o endereço k8sIP opcional em um nó, ele fica dedicado ao processamento de dados e do tráfego do Kubernetes do nó, como solicitações e respostas para a API Kubernetes, o kubelet e as cargas de trabalho. Quando você especifica k8sIP, o endereço IP padrão do nó nodePoolSpec.nodes.address é usado exclusivamente para conexões SSH com o nó. Se você não especificar um endereço k8sIP, o endereço IP padrão do nó processará todo o tráfego dele.
Opcional. String. Especifica o tipo de balanceamento de carga em pacote usado,
Camada 2 ou o Border Gateway Protocol (BGP). Se você estiver usando o
balanceamento de carga
padrão e em pacote, defina type como layer2. Se você
estiver usando o balanceamento de carga
em pacotes com o BGP, defina type como bgp. Se você não definir type, o padrão será layer2.
Obrigatório. Especifica o endereço IP virtual (VIP, na sigla em inglês) para se conectar ao
servidor da API Kubernetes. Esse endereço não pode estar dentro do intervalo de
endereços IP usados para pools de endereços do balanceador de carga,
loadBalancer.addressPools.addresses.
Opcional. Um único endereço IPv4 ou um intervalo de endereços IPv4. Especifique
os endereços IP das máquinas de nós que você quer colocar no
modo de manutenção. Para mais informações, consulte
Colocar os nós no
modo de manutenção.
Exemplo:
maintenanceBlocks:cidrBlocks:-192.168.1.200# Single machine-192.168.1.100-192.168.1.109# Ten machines
Obrigatório. String. Normalmente, o nome do namespace usa um padrão de cluster-CLUSTER_NAME, mas o prefixo cluster- não é estritamente necessário desde o Google Distributed Cloud versão 1.7.2.
Não é possível modificar os valores dos clusters atuais.
Opcional. String. Especifique o nome de usuário não raiz que você quer usar para o
recurso SUDO sem senha e acessar as máquinas de nó no seu
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.
Obsoleto. Desde a versão 1.13.0, o Google Distributed Cloud só aceita containerd como o ambiente de execução do contêiner. O
containerRuntime campo foi descontinuado e removido
do arquivo de configuração do cluster gerado. No Google Distributed Cloud versão 1.13.0 e mais recentes, se o arquivo de configuração do cluster contiver esse campo, o valor precisará ser containerd.
Opcional. Número inteiro. Especifica o número máximo de pods que podem ser executados em um único nó. Para clusters autogerenciados, os valores permitidos para
maxPodsPerNode são 32–250 para
clusters de alta disponibilidade (HA) e 64–250
para clusters que não sejam de HA. Para clusters de usuário, os valores permitidos para
maxPodsPerNode são 32 a 250.
O valor padrão se não for especificado é 110. Depois que o cluster
é criado, esse valor não pode ser atualizado.
Esta seção especifica uma configuração de registro particular no nível do nó para clusters de usuário. Os registros particulares no nível do nó são destinados ao uso com suas cargas de trabalho para dar mais controle sobre envios de imagem e a segurança relacionada.
Para clusters de administrador, o registro particular no nível do nó é especificado na seção de credenciais do arquivo de configuração do cluster de administrador.
Quando aplicável, use esta seção para especificar o nome e o namespace do Secret criado para armazenar o certificado da CA (CA raiz do servidor) do registro particular. Se o registro local não exigir um certificado TLS particular, omita esse bloco.
O suporte à configuração de um registro particular no nível do nó está disponível em Pré-lançamento apenas em clusters da versão 1.29.
String. Esse campo especifica o host e a porta de um único registro particular. É possível especificar o host com um nome de domínio ou um endereço IP. Não inclua o prefixo http ou https.
O campo host é obrigatório ao especificar um registro particular para um cluster de usuário.
O suporte à configuração de um registro particular no nível do nó está disponível em Pré-lançamento apenas em clusters da versão 1.29.
Opcional. Esta seção contém configurações para definir a estratégia de upgrade para os pools de nós de trabalho no seu cluster. Para mais informações, consulte Upgrades paralelos.
Opcional. Booleano (0 ou 1). Padrão: 1.
Esse campo especifica se é ou não necessário fazer upgrade de todos os pools de nós de trabalho de um cluster simultaneamente. Por padrão (1), faça upgrade em sequência, um após o outro. Quando você define concurrentNodePools como 0, os upgrades de todos os pools de nós de trabalho no cluster são feitos em paralelo.
Opcional. Booleano (true | false). Especifica se é necessário usar o próprio servidor de repositório de pacotes no lugar do repositório apt padrão do Docker. Para usar o próprio repositório de pacotes, defina addPackageRepo como false. Use esse recurso para pular a adição de repositórios de pacotes em cada máquina bare metal na implantação. Para mais informações, consulte Usar um servidor de repositório de pacotes particular.
Esta seção contém informações de configuração para verificações periódicas de integridade. No recurso de cluster, a única configuração disponível para verificações de integridade periódicas é o campo enable. Para mais informações, consulte Verificações de integridade periódicas.
Opcional. Booleano (true|false). Ative ou desative as verificações de integridade periódicas do cluster. As verificações de integridade periódicas são ativadas por padrão em todos os clusters. É possível desativar as verificações de integridade periódicas de um cluster definindo o campo periodicHealthCheck.enable como false.
Para mais informações, consulte Desativar as verificações de integridade periódicas.
Opcional. Use esta seção para especificar um registro particular a ser usado nas imagens de carga de trabalho. Esse método de configuração do registro particular na seção de credenciais do arquivo de configuração do cluster é para clusters híbridos ou autônomos que têm apenas pools de nós de trabalho.
Opcional. String. Caminho do arquivo de certificado de CA (CA raiz do servidor) se o servidor de registro
usar um certificado TLS particular. Se o registro local não exigir um certificado TLS particular, omita esse campo.
String. Esse campo especifica o host e a porta de um único registro particular. É possível especificar o host com um nome de domínio ou um endereço IP. Não inclua o prefixo http ou https.
O campo host é obrigatório ao especificar um registro particular para um cluster híbrido ou autônomo.
Opcional. String. Caminho do arquivo de configuração da CLI do Docker, config.json. O Docker salva as configurações de autenticação no arquivo de configuração. Este campo é aplicável apenas ao uso de registros particulares no nível do nó.
Use o campo pullCredentialConfigPath ao configurar um cluster híbrido ou autônomo para dar aos nós acesso a um registro particular que exige autenticação.
Opcional. String. Quando profile é definido como edge para um cluster independente, ele minimiza o consumo de recursos do cluster. O perfil de borda está disponível apenas para clusters independentes.
O perfil de borda reduziu os requisitos de recursos do sistema e é
recomendado para dispositivos de borda com restrições de recursos restritivas.
Para requisitos de hardware associados ao perfil de borda, consulte
Requisitos de
recursos
para clusters independentes que usam o perfil de borda.
String. Uma lista separada por vírgulas de endereços IP, intervalos de endereços IP, nomes de host e nomes de domínio que não podem passar pelo servidor proxy. Quando o Google Distributed Cloud envia uma solicitação para um desses endereços, hosts ou domínios, a solicitação é enviada diretamente.
Opcional. Use esta seção para especificar um espelho de registro que será usado na instalação de clusters no lugar do Container Registry (gcr.io). Para mais informações sobre como usar um espelho de registro, consulte Como instalar o Google Distributed Cloud usando um espelho de registro.
Opcional. String. Caminho do arquivo de certificado de CA (CA raiz do servidor) se o servidor de registro
usar um certificado TLS particular. Se o registro local não exigir um certificado TLS particular, omita esse campo.
String. O endpoint do espelho, que consiste no endereço IP e no número da porta do servidor de registros. Outra opção é usar o próprio namespace
no servidor de registro em vez do namespace raiz. Sem um
namespace, o formato do endpoint é
REGISTRY_IP:PORT. Quando você usa um
namespace, o formato do endpoint é
REGISTRY_IP:PORT/v2/NAMESPACE.
O /v2 é obrigatório ao especificar um namespace.
O campo endpoint é obrigatório ao especificar um
espelho de registro. É possível especificar vários espelhos/endpoints.
Opcional. Uma matriz de nomes de domínio para hosts que são espelhados localmente
para o espelho de registro fornecido (endpoint). Quando o
ambiente de execução do contêiner encontra solicitações de envio para imagens de um host
especificado, ele verifica primeiro o espelho do registro local. Para obter
mais informações, consulte
Criar clusters com base no espelho do registro.
Opcional. String. Caminho do arquivo de configuração da CLI do Docker, config.json. O Docker salva as configurações de autenticação no
arquivo de configuração. Este campo se aplica somente ao uso de espelhos de registro. Se o servidor de registro não exigir um arquivo de configuração
do Docker para autenticação, omita esse campo.
Nesta seção, você especifica a configuração (caminho) dos volumes permanentes locais com suporte de discos montados. Formate e ative esses discos por conta própria. Faça isso antes ou depois da criação do cluster. Para mais informações, consulte Ativações de nós LVP.
Obrigatório. String. Use o campo path para especificar o caminho da máquina host em que os discos montados podem ser descobertos. Um PersistentVolume local (PV) é criado para cada ativação. O caminho padrão é
/mnt/localpv-share. Para instruções sobre como configurar as ativações de nó, consulte Configurar ativações de nó LVP.
Esta seção especifica a configuração de volumes permanentes locais com suporte em subdiretórios em um sistema de arquivos compartilhado. Esses subdiretórios são criados automaticamente durante a criação do cluster.
Para ver mais informações, consulte Compartilhamento de LVP.
Obrigatório. String. Especifique o número de subdiretórios a serem criados em
lvpShare.path. O valor padrão é 5. Para ver instruções sobre como configurar seu compartilhamento LVP, consulte Como configurar um compartilhamento LVP.
Obrigatório. String. Use o campo path para especificar o caminho da máquina host em que os subdiretórios podem ser criados. Um PV local é criado para cada subdiretório. Para ver instruções sobre como configurar seu compartilhamento LVP, consulte Como configurar um compartilhamento LVP.
Obrigatório. String. Especifique o StorageClass a ser usado para criar volumes
permanentes. O StorageClass é criado durante a criação do cluster. O
valor padrão é local-shared. Veja instruções para
configurar seu compartilhamento LVP em
Como configurar
um compartilhamento LVP.
Opcional. Objeto Com um taint de node, você marca um node para que o programador evite ou impeça o uso dele em determinados pods. Um taint consiste em um par de chave-valor e um efeito associado. Os valores key e value são strings que você usa para identificar o taint e o valor effect especifica como os pods são processados para o nó. O objeto taints pode ter
vários taints.
O rótulo effect pode usar um dos seguintes valores:
NoSchedule: nenhum pod pode programar no nó, a menos que tenha uma tolerância correspondente.
PreferNoSchedule: o sistema evita colocar um pod que não tolera o taint no nó, mas não é obrigatório.
NoExecute: pods que não toleram o taint são removidos imediatamente, e pods que toleram o taint nunca são removidos.
No Google Distributed Cloud, os taints são reconciliados para os nós do pool de nós, a menos que a anotação baremetal.cluster.gke.io/label-taint-no-sync seja aplicada ao cluster. Para mais informações sobre
taints, consulte
Taints e tolerâncias.
Obrigatório. String. Especifica o tipo de cluster. O modelo de implantação padrão consiste em um único cluster de administrador e um ou mais clusters de usuário, que são gerenciados pelo cluster de administrador.
O Google Distributed Cloud é compatível com os seguintes tipos de clusters:
Administrador: um cluster usado para gerenciar clusters de usuários
Usuário: cluster usado para executar cargas de trabalho.
Híbrido: um único cluster para administrador e cargas de trabalho, mas que também consegue gerenciar clusters de usuários.
Autônomo: um único cluster com capacidade de autoadministração e que também executa cargas de trabalho, mas que não consegue criar ou gerenciar outros clusters de usuários.
O tipo de cluster é especificado na criação do cluster e não pode ser alterado para atualizações ou upgrades. Para mais informações sobre como criar um cluster, consulte Como criar clusters: visão geral.
Valores permitidos: admin | user | hybrid | standalone
Não é possível modificar os valores dos clusters atuais.
Opcional. Esta seção contém configurações para definir a estratégia de upgrade dos nós em um pool de nós de trabalho. Para mais informações, consulte Upgrades paralelos.
Observação: não adicione esta seção a pools de nós do balanceador de carga ou plano de controle.
Opcional. Esta seção contém configurações para definir upgrades de nó em paralelo para um pool de nós. Em upgrades de clusters padrão típicos, o upgrade de cada nó de cluster é feito em sequência, um após o outro. Ao fazer upgrade do seu cluster, é possível configurar pools de nós de trabalho para que os upgrades de vários nós sejam feitos em paralelo. O upgrade de nós em paralelo acelera significativamente os upgrades do cluster, sobretudo em clusters com centenas de nós.
Para um pool de nós de trabalho, é possível especificar o número de nós que terão upgrade simultâneo e definir um limite mínimo para a execução de cargas de trabalho durante o processo de upgrade.
Opcional. Número inteiro (positivo). Padrão: 1. Máx.: 15.
Por padrão (1), o upgrade dos nós é feito em sequência, um após o outro. Quando você define concurrentNodes como um número maior que 1, esse campo especifica o número de nós que terão upgrade em paralelo. Observe as seguintes restrições para concurrentNodes:
O valor não pode exceder 50% do número de nós do pool nem o número fixo 15, o que for menor. Por exemplo, se o pool de nós tem 20 nós, não é possível especificar um valor maior que 10. Se o pool de nós tem 100 nós, 15 é o valor máximo que pode ser especificado.
Quando você usa esse campo com o campo minimumAvailableNodes, os valores combinados não podem exceder o número total de nós no pool de nós. Por exemplo, se o pool de nós tem 20 nós e minimumAvailableNodes está definido com 18, concurrentNodes não pode exceder 2.
Os upgrades paralelos não respeitam o orçamento de interrupção de pods (PDB, na sigla em inglês).
Se as cargas de trabalho forem sensíveis a interrupções, recomendamos que você especifique minimumAvailableNodes para garantir que uma determinada quantidade de nós permaneça disponível para executar cargas de trabalho durante todo o processo de upgrade. Para mais informações, consulte Upgrades paralelos.
Opcional. Número inteiro (não negativo). Padrão: depende de concurrentNodes. Para mais detalhes sobre os valores padrão de minimumAvailableNodes, consulte Padrões de upgrade paralelo. O minimumAvailableNodes permite especificar a quantidade de nós que precisa estar disponível no pool de nós durante todo o processo de upgrade. Um nó é considerado indisponível quando está com upgrade ativo. Um nó também é considerado indisponível quando qualquer uma das condições a seguir é verdadeira:
O nó está no modo de manutenção.
O nó está em reconciliação.
O nó está interrompido no meio de um upgrade.
Quando você usa esse campo com o campo concurrentNodes, os valores combinados não podem exceder o número total de nós no pool de nós. Por exemplo, se o pool de nós tem 20 nós e concurrentNodes está definido com 10, minimumAvailableNodes não pode exceder 10.
Um valor alto em minimumAvailableNodes minimiza problemas de capacidade para programar pods e, portanto, ajuda a proteger cargas de trabalho durante um upgrade de cluster. No entanto, um valor alto em minimumAvailableNodes aumenta o risco de o upgrade ser interrompido aguardando os nós ficarem disponíveis. Para mais informações, consulte Upgrades paralelos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-02-28 UTC."],[],[]]
