Arquivo de configuração de cluster antigo

Esta página descreve os campos no arquivo de configuração do cluster que foi usado nos clusters do Anthos nas versões 1.3 e anteriores do VMware (GKE On-Prem).

Nos clusters do Anthos no VMware versão 1.4, os arquivos de configuração foram alterados sutilmente. Os novos arquivos são chamados de arquivos de configuração da versão 1. Os arquivos de configuração usados em clusters do Anthos nas versões do VMware anteriores à 1.4 são chamados de arquivos de configuração 0.

Se você quiser usar novos recursos introduzidos em clusters do Anthos no VMware versão 1.4, use os arquivos de configuração v1.

Os arquivos de configuração v0 são compatíveis com as ferramentas dos clusters do Anthos no VMware 1.4. Por exemplo, é possível transmitir um arquivo de configuração v0 para o comando gkectl create cluster nos clusters do Anthos no VMware 1.4. Além disso, é possível executar comandos que convertem seus arquivos de configuração v0 em arquivos v1.

Como converter arquivos de configuração

Os clusters do Anthos no VMware 1.4 usam arquivos de configuração separados para os clusters de administração e de usuário. Ou seja, você usa um arquivo de configuração para criar o cluster de administrador e um arquivo diferente para o cluster de usuário.

Para converter um arquivo de configuração v0 em um arquivo de administrador v1:

gkectl create-config admin --from [OLD_CONFIG_PATH] --config [OUTPUT_PATH]

em que:

• [OLD_CONFIG_PATH] é o caminho do arquivo de configuração v0;

• [OUTPUT_PATH] é um caminho de sua escolha para o arquivo de configuração do cluster de administrador v1 gerado. Se você omitir essa sinalização, gkectl nomeará o arquivo admin-cluster.yaml e o colocará no diretório atual.

Para converter um arquivo de configuração v0 em um arquivo de configuração de cluster de usuário v1:

gkectl create-config cluster --from [OLD_CONFIG_PATH] --config [OUTPUT_PATH]

• [OLD_CONFIG_PATH] é o caminho do arquivo de configuração v0.

• [OUTPUT_PATH] é um caminho de sua escolha para o arquivo de configuração do cluster de usuário v1 gerado. Se você omitir essa sinalização, gkectl nomeará o arquivo user-cluster.yaml e o colocará no diretório atual.

Modelo para o arquivo de configuração v0

Clique para ver um modelo do arquivo de configuração do cluster v0.

# Absolute path to a GKE bundle on disk
# Absolute path to a GKE bundle on disk
bundlepath: ""
# Specify which vCenter resources to use for deployment
vcenter:
  # The credentials and address GKE should use to connect to vCenter
  credentials:
    address: ""
    username: ""
    password: ""
  datacenter: ""
  datastore: ""
  cluster: ""
  network: ""
  resourcepool: ""
  # Provide the name for the persistent disk to be used by the deployment (ending
  # in .vmdk). Any directory in the supplied path must be created before deployment.
  # Not required when adding additional user clusters
  datadisk: ""
  # Provide the path to vCenter CA certificate pub key for SSL verification
  cacertpath: ""
# Specify the proxy configuration.
proxy:
  # The URL of the proxy
  url: ""
  # The domains and IP addresses excluded from proxying
  noproxy: ""
# Specify admin cluster settings for a fresh Anthos clusters on VMware deployment. Omit this section
# and use the --kubeconfig flag when adding a new user cluster to an existing deployment
admincluster:
  # In-Cluster vCenter configuration
  vcenter:
    # If specified it overwrites the network field in global vcenter configuration
    network: ""
  # # The absolute or relative path to the yaml file to use for static IP allocation.
  # # Do not include if using DHCP
  # ipblockfilepath: ""
  # # Specify pre-defined nodeports if using "manual" load balancer mode
  # manuallbspec:
  #   ingresshttpnodeport: 0
  #   ingresshttpsnodeport: 0
  #   controlplanenodeport: 30968
  #   addonsnodeport: 31405
  # Specify the already-existing partition and credentials to use with F5
  bigip:
    # To re-use credentials across clusters we recommend using YAML node anchors.
    # See https://yaml.org/spec/1.2/spec.html#id2785586
    credentials:
      address: ""
      username: ""
      password: ""
    partition: ""
    # # Optionally specify a pool name if using SNAT
    # snatpoolname: ""
  # The VIPs to use for load balancing
  vips:
    # Used to connect to the Kubernetes API
    controlplanevip: ""
    # # Used for admin cluster addons (needed for multi cluster features). Must be the same
    # # across clusters
    # addonsvip: ""
  # The Kubernetes service CIDR range for the cluster. Must not overlap with the pod
  # CIDR range
  serviceiprange: 10.96.232.0/24
  # The Kubernetes pod CIDR range for the cluster. Must not overlap with the service
  # CIDR range
  podiprange: 192.168.0.0/16
  # Spread nodes across at least three physical hosts (requires at least three hosts)
  antiaffinitygroups:
    # Set to false to disable DRS rule creation
    enabled: true
# Specify settings when deploying a new user cluster. Used both with a fresh deployment
# or when adding a new cluster to an existing deployment.
usercluster:
  # In-Cluster vCenter configuration
  vcenter:
    # If specified it overwrites the network field in global vcenter configuration
    network: ""
  # # The absolute or relative path to the yaml file to use for static IP allocation.
  # # Do not include if using DHCP
  # ipblockfilepath: ""
  # # Specify pre-defined nodeports if using "manual" load balancer mode
  # manuallbspec:
  #   ingresshttpnodeport: 30243
  #   ingresshttpsnodeport: 30879
  #   controlplanenodeport: 30562
  #   addonsnodeport: 0
  # Specify the already-existing partition and credentials to use with F5
  bigip:
    # To re-use credentials across clusters we recommend using YAML node anchors.
    # See https://yaml.org/spec/1.2/spec.html#id2785586
    credentials:
      address: ""
      username: ""
      password: ""
    partition: ""
    # # Optionally specify a pool name if using SNAT
    # snatpoolname: ""
  # The VIPs to use for load balancing
  vips:
    # Used to connect to the Kubernetes API
    controlplanevip: ""
    # Shared by all services for ingress traffic
    ingressvip: ""
    # # Used for admin cluster addons (needed for multi cluster features). Must be the same
    # # across clusters
    # addonsvip: ""
  # A unique name for this cluster
  clustername: ""
  # User cluster master nodes must have either 1 or 3 replicas
  masternode:
    cpus: 4
    memorymb: 8192
    # How many machines of this type to deploy
    replicas: 1
  # The number of worker nodes to deploy and their size. Min. 3 replicas
  workernode:
    cpus: 4
    memorymb: 8192
    # How many machines of this type to deploy
    replicas: 3
  # Spread nodes across at least three physical hosts (requires at least three hosts)
  antiaffinitygroups:
    # Set to false to disable DRS rule creation
    enabled: true
  # The Kubernetes service CIDR range for the cluster
  serviceiprange: 10.96.0.0/12
  # The Kubernetes pod CIDR range for the cluster
  podiprange: 192.168.0.0/16
  # # Uncomment this section to use OIDC authentication
  # oidc:
  #   issuerurl: ""
  #   kubectlredirecturl: ""
  #   clientid: ""
  #   clientsecret: ""
  #   username: ""
  #   usernameprefix: ""
  #   group: ""
  #   groupprefix: ""
  #   scopes: ""
  #   extraparams: ""
  #   # Set value to string "true" or "false"
  #   usehttpproxy: ""
  #   # # The absolute or relative path to the CA file (optional)
  #   # capath: ""
  # # Optionally provide an additional serving certificate for the API server
  # sni:
  #   certpath: ""
  #   keypath: ""
  # # Specify whether or not to enable the GKE usage metering feature
  # usagemetering:
  #   bigqueryprojectid: ""
  #   # The ID of the BigQuery Dataset in which the usage metering data will be stored
  #   bigquerydatasetid: ""
  #   # The absolute or relative path to the key file for a GCP service account used by
  #   # gke-usage-metering to report to BigQuery
  #   bigqueryserviceaccountkeypath: ""
  #   # Whether or not to enable the consumption-based metering feature
  #   enableconsumptionmetering: false
# Which load balancer mode to use "Manual" or "Integrated"
lbmode: Integrated
# Specify which GCP project to connect your GKE clusters to
gkeconnect:
  projectid: ""
  # The absolute or relative path to the key file for a GCP service account used to
  # register the cluster
  registerserviceaccountkeypath: ""
  # The absolute or relative path to the key file for a GCP service account used by
  # the GKE connect agent
  agentserviceaccountkeypath: ""
# Specify which GCP project to connect your logs and metrics to
stackdriver:
  projectid: ""
  # A GCP region where you would like to store logs and metrics for this cluster.
  clusterlocation: ""
  enablevpc: false
  # The absolute or relative path to the key file for a GCP service account used to
  # send logs and metrics from the cluster
  serviceaccountkeypath: ""
# Specify Cloud Run configuration
cloudrun:
  enabled: false
# # Optionally use a private Docker registry to host GKE images
# privateregistryconfig:
#   # Do not include the scheme with your registry address
#   credentials:
#     address: ""
#     username: ""
#     password: ""
#   # The absolute or relative path to the CA certificate for this registry
#   cacertpath: ""
# The absolute or relative path to the GCP service account key that will be used to
# pull GKE images
gcrkeypath: ""
# # Configure kubernetes apiserver audit logging
# cloudauditlogging:
#   projectid: ""
#   # A GCP region where you would like to store audit logs for this cluster.
#   clusterlocation: ""
#   # The absolute or relative path to the key file for a GCP service account used to
#   # send audit logs from the cluster
#   serviceaccountkeypath: ""

Como preencher um arquivo de configuração v0

Se você estiver usando um arquivo de configuração v0, insira valores de campo conforme descrito nesta seção.

bundlepath

O arquivo de pacote dos clusters do Anthos no VMware contêm todos os componentes em uma determinada versão dos clusters do Anthos no VMware. Quando você cria uma estação de trabalho de administrador, ela inclui um pacote completo em /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz. A versão desse pacote corresponde à versão do OVA que você importou para criar a estação de trabalho do administrador.

Observação: ao instalar clusters do Anthos no VMware, as versões de gkectl e de pacote precisam ser as mesmas. Se você criou uma estação de trabalho do administrador usando uma OVA que está em uma versão diferente da que você quer instalar, é provável que o pacote completo da estação de trabalho do administrador esteja desatualizado. Nesse caso, você precisará fazer upgrade da estação de trabalho do administrador.

Defina o valor de bundlepath como o caminho do arquivo de pacote da estação de trabalho do administrador. Ou seja, defina bundlepath como:

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

em que [VERSION] é a versão dos clusters do Anthos no VMware que você está instalando. A versão mais recente é 1.6.0-gke.7.

É possível manter seu arquivo de pacote em um local diferente ou atribuir outro nome. No arquivo de configuração, verifique se o valor de bundlepath é o caminho para o arquivo de pacote, seja ele qual for.

Especificação do vCenter

A especificação vcenter contém informações sobre a instância do servidor vCenter. Os clusters do Anthos no VMware precisam dessa informação para se comunicar com o servidor vCenter.

vcenter.credentials.address

O campo vcenter.credentials.address contém o endereço IP ou o nome do host do servidor vCenter.

Antes de preencher o vsphere.credentials.address field, faça o download do certificado de exibição do servidor vCenter e inspecione-o. Digite o comando a seguir para fazer o download do certificado e salvá-lo em um arquivo chamado vcenter.pem.

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Abra o arquivo de certificado para ver o nome comum e o alternativo do assunto:

openssl x509 -in vcenter.pem -text -noout

A saída mostra o nome comum (CN, na sigla em inglês) Subject. Pode ser um endereço IP ou um nome do host. Exemplo:

Subject: ... CN = 203.0.113.100

Subject: ... CN = my-host.my-domain.example

A saída também pode incluir um ou mais nomes de DNS em Subject Alternative Name:

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Escolha o nome comum Subject ou um dos nomes de DNS em Subject Alternative Name para usar como o valor de vcenter.credentials.address no arquivo de configuração. Por exemplo:

vcenter:
  credentials:
    address: "203.0.113.1"
    ...

vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

Você precisa escolher um valor que apareça no certificado. Por exemplo, se o endereço IP não aparecer no certificado, não será possível usá-lo para vcenter.credentials.address.

vcenter.credential.username, .password

Os clusters do Anthos no VMware precisam saber o nome de usuário e a senha do servidor do vCenter. Para fornecer essas informações, defina os valores username e password em vcenter.credentials. Por exemplo:

vcenter:
  credentials:
    username: "my-name"
    password: "my-password"

vcenter.datacenter, .datastore, .cluster, .network

Os clusters do Anthos no VMware precisam de algumas informações sobre a estrutura do ambiente do vSphere. Defina os valores em vcenter para fornecer essas informações. Por exemplo:

vcenter:
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

Observação: é possível especificar diferentes redes vCenter para clusters de administrador e de usuário nos campos admincluster.vcenter.network e usercluster.vcenter.network, respectivamente.

vcenter.resourcepool

Um pool de recursos do vSphere é um agrupamento lógico de VMs no cluster do vSphere. Se você estiver usando um pool de recursos diferente do padrão, forneça um nome para vcenter.resourcepool. Exemplo:

vcenter:
  resourcepool: "my-pool"

Se você quiser que os clusters do Anthos no VMware implantem os nós no pool de recursos padrão do cluster do vSphere, forneça uma string vazia para vcenter.resourcepool. Exemplo:

vcenter:
  resourcepool: ""

vcenter.datadisk

Os clusters do Anthos no VMware criam um disco de máquina virtual (VMDK, na sigla em inglês) para armazenar os dados de objeto do Kubernetes para o cluster de administrador. O instalador cria o VMDK para você, mas é necessário fornecer um nome para o VMDK no campo vcenter.datadisk. Exemplo:

vcenter:
  datadisk: "my-disk.vmdk"

Armazenamento de dados vSAN: como criar uma pasta para o VMDK

Se você estiver usando um armazenamento de dados vSAN, será necessário colocar o VMDK em uma pasta. Você precisa criar a pasta manualmente com antecedência. Para fazer isso, use govc para criar uma pasta:

govc datastore.mkdir -namespace=true my-gke-on-prem-folder

Em seguida, defina vcenter.datadisk como o caminho do VMDK, incluindo a pasta. Exemplo:

vcenter:
datadisk: "my-gke-on-prem-folder/my-disk.vmdk"

Importante: não coloque uma barra antes do nome da pasta.

Na versão 1.1.1 e anteriores, um problema conhecido exige que você forneça o caminho do identificador universal exclusivo (UUID, na sigla em inglês) da pasta, em vez do caminho do arquivo, para vcenter.datadisk. Copie isso da saída do comando govc acima.

Em seguida, forneça o UUID da pasta no campo vcenter.datadisk. Não coloque uma barra antes do UUID. Por exemplo:

vcenter:
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

Esse problema foi corrigido nas versões 1.1.2 e mais recentes.

vcenter.cacertpath

Quando um cliente, como os clusters do Anthos no VMware, envia uma solicitação ao servidor vCenter, o servidor precisa provar a própria identidade ao cliente apresentando um certificado ou um pacote de certificados. Para verificar o certificado ou o pacote, os clusters do Anthos no VMware precisam ter o certificado raiz na cadeia de confiança.

Defina vcenter.cacertpath como o caminho do certificado raiz. Exemplo:

vcenter:
  cacertpath: "/my-cert-folder/the-root.crt"

A instalação do VMware tem uma autoridade de certificação (CA, na sigla em inglês) que emite um certificado para o servidor vCenter. O certificado raiz na cadeia de confiança é um certificado autoassinado criado pela VMware.

Se você não quiser usar a CA do VMWare, que é o padrão, configure o VMware para usar uma autoridade de certificação diferente.

Se o servidor vCenter usar um certificado emitido pela CA do VMware padrão, haverá várias maneiras de conseguir o certificado raiz:

• curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip

  [SERVER_ADDRESS] é o endereço do servidor vCenter.

• Em um navegador, digite o endereço do servidor vCenter. Na caixa cinza à direita, clique em Fazer o download de certificados de CA raiz confiáveis.

• Digite este comando para receber o certificado de exibição:

  true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts

  Na saída, encontre um URL como este: https://[SERVER_ADDRESS]/afd/vecs/ca. Digite o URL em um navegador. Isso faz o download do certificado raiz.

O arquivo baixado é denominado downloads.zip.

Descompacte o arquivo:

unzip downloads.zip

Se o comando para descompactar não funcionar na primeira vez, digite o comando novamente.

Encontre o arquivo de certificado em certs/lin.

Especificação de proxy

Se a rede estiver protegida por um servidor proxy, preencha o campo proxy com o proxy HTTPS e os endereços que precisam ser excluídos do proxy. Por exemplo:

proxy:
  url: "https://username:password@domain"
  noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"

• proxy.url é o URL do proxy HTTPS.
• proxy.noproxy inclui os intervalos de CIDR, os endereços IP, os domínios e os nomes de host que não podem ser encaminhados por proxy. Por exemplo, as chamadas para os endereços IP dos nós do cluster não podem ser encaminhadas por proxy. Portanto, se você tiver uma sub-rede que contenha somente nós de cluster, liste o intervalo CIDR da sub-rede no campo noproxy. Se privateregistryconfig for especificado, esse endereço será adicionado automaticamente para evitar chamadas ao seu registro particular.

Especificação do cluster de administrador

A especificação admincluster contém informações que os clusters do Anthos no VMware precisam para criar o cluster de administrador.

admincluster.vcenter.network

Em admincluster.vcenter.network, é possível especificar uma rede vCenter para os nós do cluster de administrador. Isso modifica a configuração global que você forneceu em vcenter. Por exemplo:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

Como você está usando endereços IP estáticos, é necessário ter um arquivo de configuração de host, conforme descrito em Como configurar IPs estáticos. Forneça o caminho para seu arquivo de configuração de host no campo admincluster.ipblockfilepath. Exemplo:

admincluster:
  ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"

admincluster.manuallbspec.ingresshttpnoodeport, .ingresshttpsnodeport

Remova esses campos. Eles não são usados no cluster de administração.

admincluster.manuallbspec.controlplanenodeport, .addsnodeport (modo de balanceamento de carga manual)

O servidor da API Kubernetes no cluster de administrador é implementado como um serviço do tipo NodePort. Se você estiver usando o balanceamento de carga manual, será necessário escolher um valor nodePort para o serviço. Especifique o valor nodePort em controlplanenodeport. Exemplo:

admincluster:
  manuallbspec:
    controlplanenodeport: 30968

O servidor de complementos no cluster de administrador é implementado como um serviço do tipo NodePort. Se você estiver usando o balanceamento de carga manual, será necessário escolher um valor nodePort para o serviço. Especifique o valor nodePort em controlplanenodeport. Exemplo:

admincluster:
  manuallbspec:
    addonsnodeport: 30562

admincluster.bigip.credentials (modo de balanceamento de carga integrado)

Se você não estiver usando o modo de balanceamento de carga integrado, deixe admincluster.bigip com marca de comentário.

Se você estiver usando o modo de balanceamento de carga integrado, os clusters do Anthos no VMware precisam saber o endereço IP ou o nome do host, o nome de usuário e a senha do balanceador de carga F5 BIG-IP. Defina os valores em admincluster.bigip para fornecer essas informações. Por exemplo:

admincluster:
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.partition (modo de balanceamento de carga integrado)

Se estiver usando o modo de balanceamento de carga integrado, você precisará criar uma partição BIG-IP para o cluster de administrador. Defina admincluster.bigip.partition como o nome da partição. Por exemplo:

admincluster:
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

Se você usa o balanceamento de carga integrado ou manual para o cluster de administrador, é necessário preencher o campo admincluster.vips.

Defina o valor de admincluster.vips.controlplanevip como o endereço IP que você escolheu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de administrador. Defina o valor de addonsvip como o endereço IP que você escolheu configurar no balanceador de carga para os complementos. Exemplo:

admincluster:
  vips:
    controlplanevip: 203.0.113.3
    addonsvip: 203.0.113.4

admincluster.serviceiprange e admincluster.podiprange

O cluster de administrador precisa ter um intervalo de endereços IP para usar em serviços e um para usar em pods. Esses intervalos são especificados pelos campos admincluster.serviceiprange e admincluster.podiprange. Esses campos são preenchidos quando você executa gkectl create-config. Se quiser, é possível alterar os valores preenchidos para valores de sua escolha.

Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods não podem se sobrepor a endereços IP usados para nós em nenhum cluster.

Exemplo:

admincluster:
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

admincluster.antiaffogrous.enabled

Booleano. Defina como true para ativar a criação de regras do DRS. Caso contrário, defina-o como false. Exemplo:

admincluster:
  antiAffinityGroups:
    enabled true

Especificação do cluster de usuário

A especificação do cluster de usuário, usercluster, contém informações que os clusters do Anthos no VMware precisam criar o cluster de usuário inicial.

usercluster.vcenter.network

Em usercluster.vcenter.network, é possível especificar uma rede vCenter para os nós do cluster de usuário. Isso modifica a configuração global que você forneceu em vcenter. Por exemplo:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

usercluster.ipblockfilepath

Como você está usando endereços IP estáticos, é necessário ter um arquivo de configuração de host, conforme descrito em Como configurar IPs estáticos. Forneça o caminho para seu arquivo de configuração de host no campo usercluster.ipblockfilepath. Por exemplo:

usercluster:
  ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"

usercluster.manuallbspec (modo de balanceamento de carga manual)

O controlador de entrada no cluster do usuário é implementado como um serviço do tipo NodePort. O serviço tem um ServicePort para HTTP e outro para HTTPS. Se você estiver usando o modo de balanceamento de carga manual, será necessário escolher valores nodePort para esses ServicePorts. Especifique os valores nodePort em ingresshttpnodeport e ingresshttpsnodeport. Por exemplo:

usercluster:
  manuallbspec:
    ingresshttpnodeport: 30243
    ingresshttpsnodeport: 30879

O servidor da API Kubernetes no cluster de usuário é implementado como um serviço do tipo NodePort. Se você estiver usando o balanceamento de carga manual, será necessário escolher um valor nodePort para o serviço. Especifique o valor nodePort em controlplanenodeport. Por exemplo:

usercluster:
  manuallbspec:
    controlplanenodeport: 30562

usercluster.bigip.credentials (modo de balanceamento de carga integrado)

Se você estiver usando o modo de balanceamento de carga integrado, os clusters do Anthos no VMware precisarão saber o endereço IP ou o nome do host, o nome de usuário e a senha do balanceador de carga F5 BIG-IP que você pretende usar para o cluster de usuário. Defina os valores em usercluster.bigip para fornecer essas informações. Por exemplo:

usercluster:
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"

usercluster.bigip.partition (modo de balanceamento de carga integrado)

Se estiver usando o modo de balanceamento de carga integrado, você precisará criar uma partição BIG-IP para seu cluster de usuário. Defina usercluster.bigip.partition como o nome da partição. Exemplo:

usercluster:
  bigip:
    partition: "my-user-f5-partition"

usercluster.vips

Se você usa o balanceamento de carga integrado ou manual para o cluster de usuário, é necessário preencher o campo usercluster.vips.

Defina o valor de usercluster.vips.controlplanevip como o endereço IP que você escolheu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário. Defina o valor de ingressvip como o endereço IP que você escolheu configurar no balanceador de carga para o controlador de entrada do cluster de usuário. Exemplo:

usercluster:
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

usercluster.clustername

Defina o valor de usercluster.clustername como um nome de sua escolha. Escolha um nome com até 40 caracteres. Exemplo:

usercluster:
  clustername: "my-user-cluster-1"

usercluster.masternode.cpus e usercluster.masternode.memorymb

Os campos usercluster.masternode.cpus e usercluster.masternode.memorymb especificam o número de CPUs e a quantidade de memória, em megabytes, que são alocadas para cada nó do plano de controle do cluster de usuário. Exemplo:

usercluster:
  masternode:
    cpus: 4
    memorymb: 8192

usercluster.masternode.replicas

O campo usercluster.masternode.replicas especifica quantos nós do plano de controle você quer que o cluster do usuário tenha. O nó do plano de controle do cluster de usuário executa o plano de controle do usuário, os componentes do plano de controle do Kubernetes. Esse valor precisa ser 1 ou 3:

• Defina este campo como 1 para executar um plano de controle do usuário.
• Defina este campo como 3 se quiser ter um plano de controle de usuário de alta disponibilidade (HA) composto de três nós, cada um executando um plano de controle de usuário.

usercluster.workernode.cpus e usercluster.workernode.memorymb

Os campos usercluster.workernode.cpus e usercluster.workernode.memorymb especificam quantas CPUs e quanta memória, em megabytes, são alocadas para cada nó de trabalho do cluster de usuário. Exemplo:

usercluster:
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.workernode.replicas

O campo usercluster.workernode.replicas especifica quantos nós de trabalho você quer que o cluster de usuário tenha. Os nós de trabalho executam as cargas de trabalho do cluster.

usercluster.antiaffinitygrous.enabled

Booleano. Defina como true para ativar a criação de regras do DRS. Caso contrário, defina-o como false. Exemplo:

antiAffinityGroups:
  enabled true

usercluster.serviceiprange e usercluster.podiprange

O cluster de usuário precisa ter um intervalo de endereços IP para usar em serviços e um para usar em pods. Esses intervalos são especificados pelos campos usercluster.serviceiprange e usercluster.podiprange. Esses campos são preenchidos quando você executa gkectl create-config. Se quiser, é possível alterar os valores preenchidos para valores de sua escolha.

Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods não podem se sobrepor a endereços IP usados para nós em nenhum cluster.

Exemplo:

usercluster:
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

usercluster.oidc

Se você quiser que os clientes do cluster de usuário usem a autenticação OIDC, defina valores para os campos em usercluster.oidc. A configuração do protocolo OIDC é opcional.

Para saber como configurar o OIDC, consulte Como autenticar com o OIDC.

Sobre a instalação da versão 1.0.2-gke.3

A versão 1.0.2-gke.3 introduz os campos OIDC (usercluster.oidc) a seguir. Esses campos permitem fazer login em um cluster do console do Google Cloud:

• usercluster.oidc.kubectlredirecturl
• usercluster.oidc.clientsecret
• usercluster.oidc.usehttpproxy

Na versão 1.0.2-gke.3, se você quiser usar o OIDC, o campo clientsecret será obrigatório, mesmo que você não queira fazer login em um cluster no console do Google Cloud. Nesse caso, forneça um valor de marcador para clientsecret:

oidc:
clientsecret: "secret"

usercluster.sni

Observação: alguns navegadores e dispositivos legados podem não ser compatíveis com a SNI.

A Server Name Indication (SNI), uma extensão do Transport Layer Security (TLS), permite que os servidores apresentem vários certificados em apenas um endereço IP e uma porta TCP, dependendo do nome do host indicado pelo cliente.

Se a CA já estiver distribuída como uma CA confiável para clientes fora do cluster de usuário e você quiser confiar nessa cadeia para identificar clusters confiáveis, configure o servidor da API Kubernetes com um certificado extra que é apresentado a clientes externos do endereço IP do balanceador de carga.

Para usar a SNI com seus clusters de usuário, você precisa ter sua própria CA e infraestrutura de chave pública (ICP). Você provisiona um certificado de veiculação separado para cada cluster de usuário e os clusters do Anthos no VMware adicionam cada certificado de disponibilização ao respectivo cluster de usuário.

Se quiser configurar a SNI para o servidor da API Kubernetes do cluster de usuário, forneça valores para usercluster.sni.certpath (caminho para o certificado externo) e usercluster.sni.keypath (caminho para o arquivo de chave privada do certificado externo). Exemplo:

usercluster:
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

usagemetering

Se você quiser ativar a medição de uso do cluster, preencha esta seção. Caso contrário, remova esta seção.

usagemetering.bigqueryprojectid

String. O ID do projeto do Google Cloud em que você quer armazenar os dados de medição de uso. Exemplo:

usagemetering:
  bigqueryprojectid: "my-bq-project"

usagemetering.bigquerydatasetid

String. O ID do conjunto de dados do BigQuery em que você quer armazenar os dados de medição de uso. Exemplo:

usagemetering:
  bigquerydatasetid: "my-bq-dataset"

usagemetering.bigqueryserviceaccountkepPath

String. O caminho do arquivo de chave JSON para a conta de serviço do BigQuery. Exemplo:

usagemetering:
  bigqueryserviceaccountkeypath: "my-key-folder/bq-key.json"

usagemetering.enableconsumptionmetering

Booleano. Defina como true se você quiser ativar a medição baseada em consumo. Caso contrário, defina como false. Exemplo:

usagemetering:
  enableconsumptionmetering: true

lbmode

É possível usar o balanceamento de carga integrado ou o balanceamento de carga manual. A escolha do modo de balanceamento de carga se aplica ao cluster de administrador e ao cluster de usuário inicial. Isso também se aplicará a todos os outros clusters de usuário que você criar no futuro.

Para especificar sua opção de balanceamento de carga, defina o valor de lbmode como Integrated ou Manual. Exemplo:

lbmode: Integrated

gkeconnect

A especificação gkeconnect contém informações que os clusters do Anthos no VMware precisam para configurar o gerenciamento dos clusters locais no Console do Google Cloud.

Defina gkeconnect.projectid como o ID do projeto do Google Cloud em que você quer gerenciar os clusters locais.

Defina o valor de gkeconnect.registerserviceaccountkeypath como o caminho do arquivo de chave JSON para a conta de serviço de registro. Defina o valor de gkeconnect.agentserviceaccountkeypath como o caminho do arquivo de chave JSON para a conta de serviço de conexão.

Exemplo:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"

Observação: nas versões anteriores a 1.1.0-gke.6, o agente do Connect usou o servidor proxy especificado no campo gkeconnect.proxy. Da versão 1.1.0-gke.6 em diante, o agente do Connect usa o servidor proxy especificado no campo proxy global. Para mais informações, consulte as notas de lançamento.

stackdriver

Observação: o campo stackdriver.proxyconfigsecretname foi removido na versão 1.1.0-gke.6 em diante. Não o inclua no arquivo de configuração.

A especificação stackdriver contém informações que os clusters do Anthos no VMware precisam para armazenar entradas de registro geradas pelos clusters locais.

Defina stackdriver.projectid como o ID do projeto do Google Cloud em que você quer visualizar os registros do Stackdriver pertencentes aos clusters locais.

Defina stackdriver.clusterlocation como uma região do Google Cloud em que você quer armazenar registros do Stackdriver. É recomendável escolher uma região próxima ao data center local.

Defina stackdriver.enablevpc como true se você tiver a rede do cluster controlada por uma VPC. Isso garante que toda a telemetria flua pelos endereços IP restritos do Google.

Defina stackdriver.serviceaccountkeypath como o caminho do arquivo de chave JSON para a conta de serviço do Stackdriver Logging.

Exemplo:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

cloudrun.enabled

Booleano. Defina como true se você quiser ativar o Cloud Run. Caso contrário, defina-o como false. Exemplo:

cloudrun:
  enabled: true

privateregistryconfig

Note: se você estiver criando um cluster na versão 1.1.1-gke.2, consulte o problema conhecido que afeta o uso de um registro do Docker.

Se você tiver um privateregistryconfigregistro particular do Docker, o campo conterá informações que os clusters do Anthos no VMware usam para enviar imagens para o registro particular. Se você não especificar um registro particular, gkectl extrairá imagens do contêiner dos clusters do Anthos no VMware do repositório do Container Registry, gcr.io/gke-on-prem-release, durante a instalação.

Em privatedockerregistry.credentials, defina address como o endereço IP da máquina que executa o registro particular do Docker. Defina username e password como o nome de usuário e a senha do registro particular do Docker. O valor definido para address é adicionado automaticamente a proxy.noproxy.

Quando o Docker extrai uma imagem do seu registro particular, o registro precisa comprovar a própria identidade apresentando um certificado. O certificado do registro é assinado por uma autoridade de certificação (CA). O Docker usa o certificado da CA para validar o certificado do registro.

Defina privateregistryconfig.cacertpath como o caminho do certificado da CA. Exemplo:

privateregistryconfig:
  cacertpath: /my-cert-folder/registry-ca.crt

gcrkeypath

Defina o valor de gcrkeypath como o caminho do arquivo de chave JSON para sua conta de serviço de acesso.

Exemplo:

gcrkeypath: "/my-key-folder/component-access-key.json"

cloudauditlogging

Se você quiser enviar os registros de auditoria do Kubernetes para o projeto do Google Cloud, preencha a especificação cloudauditlogging. Exemplo:

cloudauditlogging:
  projectid: "my-project"
  # A GCP region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a GCP service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"