Nesta página, descrevemos os campos compatíveis com os clusters do Anthos em um arquivo de configuração
de cluster bare metal. 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.
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:
bmctl create config -c CLUSTER_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.
Campos de configuração do cluster
Nome do campo
Resource type
Obrigatório?
Mutável?
anthosBareMetalVersion
Obrigatório. String. A versão do cluster. Esse valor é definido na criação
de clusters e nos upgrades de cluster.
Mutabilidade: esse valor não pode ser modificado para clusters atuais.
A versão só pode ser atualizada por meio do processo de upgrade de cluster.
Recurso de cluster
Sim
Sim
authentication
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 Anthos em clusters bare metal.
Recurso de cluster
—
—
authentication.oidc.certificateAuthorityData
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. String. O ID do aplicativo cliente que faz
solicitações de autenticação para o provedor OpenID.
Recurso de cluster
Não
Não
authentication.oidc.clientSecret
Opcional. String. Senha secreta compartilhada entre o aplicativo cliente do OIDC e o provedor OIDC.
Recurso de cluster
Não
Não
authentication.oidc.deployCloudConsoleProxy
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.
Recurso de cluster
Não
Não
authentication.oidc.extraParams
Opcional. Lista delimitada por vírgulas. Parâmetros de chave-valor extras a serem enviados ao provedor OpenID.
Recurso de cluster
Não
Não
authentication.oidc.groupPrefix
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.
Recurso de cluster
Não
Não
authentication.oidc.group
Opcional. String.
Declaração do JWT
que o provedor usa para retornar grupos de segurança.
Recurso de cluster
Não
Não
authentication.oidc.issuerURL
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.
Recurso de cluster
Não
Não
authentication.oidc.kubectlRedirectURL
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.
Recurso de cluster
Não
Não
authentication.oidc.proxy
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.
Recurso de cluster
Não
Não
authentication.oidc.scopes
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.
Recurso de cluster
Não
Não
authentication.oidc.usernamePrefix
Opcional. String. Prefixo anexado a declarações de nome de usuário.
Recurso de cluster
Não
Não
authentication.oidc.username
Opcional. String.
Declaração do JWT a ser usada como nome de usuário. Se não for especificado, sub será usado como padrão para .
Recurso de cluster
Não
Não
bypassPreflightCheck
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.
Recurso de cluster
Não
Sim
clusterNetwork
Esta seção contém configurações de rede para o cluster.
Recurso de cluster
—
—
clusterNetwork.multipleNetworkInterfaces
Opcional. Booleano. Defina esse campo como true para ativar várias interfaces de rede para seus pods. Essa capacidade está em Visualização.
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.
Exemplo:
pods:
cidrBlocks:
- 192.168.0.0/16
Recurso de cluster
Sim
Não
clusterNetwork.services.cidrBlocks
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).
Exemplo:
services:
cidrBlocks:
- 10.96.0.0/12
Recurso de cluster
Sim
Não
clusterOperations
Esta seção contém informações sobre o Cloud Logging e o
Cloud Monitoring.
Recurso de cluster
—
—
clusterOperations.enableApplication
Booleano. Defina como true para coletar registros/métricas do aplicativo,
além da coleção padrão de registros/métricas do sistema, que
correspondem a componentes do sistema, como o plano de controle do Kubernetes
ou agentes de gerenciamento de cluster.
Booleano. Defina como false para ativar os Registros de auditoria do Cloud.
Os registros de auditoria do Cloud são úteis para investigar solicitações de API suspeitas e
coletar estatísticas Para mais informações, consulte
Ativar a geração de registros de auditoria.
Recurso de cluster
Não
Sim
clusterOperations.location
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.
Exemplo:
location: us-central1
Recurso de cluster
Sim
Não
clusterOperations.projectID
String. O ID do projeto do Google Cloud em que você quer ver
os registros e as métricas.
Recurso de cluster
Sim
Não
controlPlane
Esta seção contém informações sobre o plano de controle e
os componentes dele.
Recurso de cluster
—
—
controlPlane.nodePoolSpec
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.
Recurso de cluster
—
—
controlPlane.nodePoolSpec.nodes
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).
Não é possível modificar os valores dos clusters atuais.
Recurso de cluster
Sim
Não
kubevirt.useEmulation
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.
Recurso de cluster
Não
Sim
loadBalancer
Esta seção contém configurações para balanceamento de carga do cluster.
Recurso de cluster
—
—
loadBalancer.addressPools
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 modificar ou remover pools
de endereços atuais.
Recurso de cluster
Não
Não
loadBalancer.addressPools.addresses
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.
String. O nome que você escolheu para o pool do balanceador de carga do cluster.
Recurso de cluster
Sim
Não
loadBalancer.addressPools.avoidBuggyIPs
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.
Recurso de cluster
Não
Não
loadBalancer.addressPools.manualAssign
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.
Recurso de cluster
Não
Sim
loadBalancer.mode
Obrigatório. String. Especifica o modo de balanceamento de carga. No modo
bundled, os clusters do Anthos em bare metal instalam um balanceador
de carga em nós do balanceador de carga 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.
Valores permitidos: bundled | manual
Recurso de cluster
Sim
Não
loadBalancer.type
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.
Valores permitidos: layer2 | bgp
Recurso de cluster
Não
Não
loadBalancer.nodePoolSpec
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.
Recurso de cluster
—
—
loadBalancer.nodePoolSpec.nodes
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.
Recurso de cluster
Não
Sim
loadBalancer.nodePoolSpec.nodes.address
Opcional. String (endereço IPv4). Endereço IP de um nó.
Recurso de cluster
Não
Sim
loadBalancer.ports.controlPlaneLBPort
Número A porta de destino usada para o tráfego enviado ao plano de controle do
Kubernetes (os servidores da API Kubernetes).
Recurso de cluster
Sim
Não
loadBalancer.vips.controlPlaneVIP
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.
Recurso de cluster
Sim
Não
loadBalancer.vips.ingressVIP
Opcional. String (endereço IPv4). O endereço IP que você escolheu
configurar no balanceador de carga para o tráfego de entrada.
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.
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.
Recurso de cluster
Não
Não
maintenanceBlocks.cidrBlocks
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
Recurso de cluster
Não
Sim
nodeAccess.loginUser
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.
Recurso de cluster
Não
Sim
osEnvironmentConfig.addPackageRepo
Opcional. Booleano (true|false). Especifica se o repositório de pacotes será adicionado ao inicializar máquinas bare metal.
Recurso de cluster
Não
Não
nodeConfig.containerRuntime
Opcional. String. Especifique o ambiente de execução do contêiner, docker
ou containerd, a ser usado para programar contêineres em nós.
Se você não especificar o ambiente de execução do contêiner, o padrão será
docker. Para mais informações sobre como configurar o ambiente de execução do contêiner, consulte Alterar o ambiente de execução do contêiner.
Valores permitidos: containerd | docker
Recurso de cluster
Não
Não
nodeConfig.podDensity
Nesta seção, especificamos a configuração de densidade do pod.
Recurso de cluster
—
—
nodeConfig.podDensity.maxPodsPerNode
Opcional. Integer. 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.
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.
Recurso de cluster
Não
Não
proxy
Se a rede estiver protegida por um servidor proxy, preencha esta seção.
Caso contrário, remova-a.
Recurso de cluster
—
—
proxy.noProxy
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 os clusters do Anthos em bare metal enviam uma solicitação para um
desses endereços, hosts ou domínios, a solicitação é enviada diretamente.
Recurso de cluster
Não
Não
proxy.url
String. O endereço HTTP do servidor proxy. Inclua o número da porta mesmo que ele seja igual à porta padrão do
esquema.
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.
Recurso de cluster
Sim
Não
storage.lvpNodeMounts
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.
Recurso de cluster
Sim
Não
storage.lvpShare
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.
Recurso de cluster
Sim
Não
storage.lvpShare.path
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.
Recurso de cluster
Sim
Não
storage.lvpShare.numPVUnderSharedPath
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.
Recurso de cluster
Sim
Não
storage.lvpShare.storageClassName
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.
Recurso de cluster
Não
Não
type
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. Os clusters do Anthos em bare metal são compatíveis 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 cluster único para administração e cargas de trabalho, mas que também
consegue gerenciar clusters de usuários
Autônomo: um único cluster capaz de administrar ele próprio e de também executar cargas de trabalho, mas que não consegue criar ou gerenciar outros clusters de usuários.
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.
Recurso de cluster
Sim
Não
name
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, já que os clusters do Anthos na versão Bare Metal 1.7.2.
Não é possível modificar os valores dos clusters atuais.
Recurso de namespace
Sim
Não
clusterName
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.
Opcional. Matriz de endereços IP (IPv4). Isso define o pool de nós para os nós de trabalho
Recurso NodePool
Não
Sim
nodes.address
Opcional. String (endereço IPv4). Um ou mais endereços IP para os
nós que formam o pool de nós de trabalho.
Recurso NodePool
Não
Sim
taints
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.
Para clusters do Anthos em Bare Metal, 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.
Exemplo:
taints:
- key: status
value: testpool
effect: NoSchedule
Recurso NodePool
Não
Sim
labels
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.
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.
String. Caminho do arquivo de certificado de CA se o servidor de registro usar um
certificado TLS particular. Se o registro não exigir um certificado TLS particular, deixe
o campo caCertPath em branco.
Espelho do registro
Opcional
Mutável
registryMirrors.pullCredentialConfigPath
String. O caminho para o
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, deixe o campo
pullCredentialConfigPath em branco.
O arquivo de configuração de cluster gerado por bmctl para
clusters do Anthos em bare metal 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
é uma conta de serviço gerenciada pelo Google
que age em nome do
Container Registry ao interagir com os serviços do Google
Cloud.
Credenciais
Não
Sim
sshPrivateKeyPath
String. O caminho para a chave privada SSH. O SSH é necessário para acessar o nó.
Credenciais
Não
Sim
gkeConnectAgentServiceAccountKeyPath
String. O caminho para a chave da conta de serviço do agente.
Os clusters do Anthos em bare metal usam essa conta de serviço para manter uma
conexão entre os clusters do Anthos em Bare Metal e o Google Cloud.
String. O caminho para a chave da conta de serviço do registro.
Os clusters do Anthos em bare metal usam essa conta de serviço para registrar seus clusters
de usuário no Google Cloud.
String. O caminho para a chave da conta de serviço de operações.
Os clusters do Anthos em bare metal usam a conta de serviço de operações para
autenticar com o pacote de operações do Google Cloud para acesso à
API Logging e à API Monitoring.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2023-05-08 UTC."],[],[]]
