1. Criar organização do cliente

Tempo estimado para a conclusão: 3 horas

Perfil de habilidade: engenheiro de implantação

Como operador, você pode criar uma organização para dar aos clientes acesso à infraestrutura da plataforma. Para receber as permissões necessárias para criar uma organização, peça ao administrador de segurança para conceder a você o papel de administrador da organização.

O recurso Organization é o nó raiz da hierarquia de recursos isolados do Google Distributed Cloud (GDC), e todos os recursos pertencentes a um grupo de organizações estão no nó da organização. Isso proporciona visibilidade e controle centralizados sobre todos os recursos dessa organização.

Para mais informações sobre organizações, consulte a Visão geral da organização.

1.1. Antes de começar

Verifique se você instalou o seguinte:

• Um navegador no seu sistema.

• A interface de linha de comando (CLI) do Git.

• A CLI kubectl.

• A CLI gdcloud.

1.2. Criar um cliente OIDC no OC IT ADFS

1. Consulte as instruções de configuração do OIDC do ADFS para criar um cliente OpenID Connect (OIDC) no ADFS para que o operador acesse a organização que você vai criar. Registre o ID do cliente e a chave secreta do cliente OIDC. Não reutilize o cliente em conexões com outros clusters, como o cluster de administrador raiz e outros clusters de administrador da organização, ou serviços como o ServiceNow.

2. Adicione o seguinte URL de callback do serviço de identidade do GKE à lista de permissões no cliente OIDC do ADFS que você criou para a organização que será criada:

   https://ais-core.ORG_NAME.GDC_URL.GDC_DOMAIN/finish-login
   

   Exemplo:

   • nome da organização: operations
   • Nome da instância do Distributed Cloud: google
   • Nome de domínio da Distributed Cloud: gdch.test

   Nesse caso, o URL de callback do GKE Identity Service é https://ais-core.operations.google.gdch.test/finish-login.

3. Adicione o seguinte URL de callback do serviço de identidade do GKE à lista de permissões no cliente OIDC do ADFS que você criou para cada zona no seu universo do GDC:

   https://ais-core.ORG_NAME.ZONE.GDC_URL.GDC_DOMAIN/finish-login
   

   Exemplo:

   • nome da organização: operations
   • Nome da zona: zone-1
   • Nome da instância do Distributed Cloud: google
   • Nome de domínio da Distributed Cloud: gdch.test

   Nesse caso, o URL de callback do GKE Identity Service é https://ais-core.operations.zone-1.google.gdch.test/finish-login.

4. Defina as seguintes variáveis para usar nas próximas seções:

   export ADFS_CERT_BASE64=ADFS_CERT_BASE64
   export ADFS_CLIENT_ID=ADFS_CLIENT_ID
   export ADFS_CLIENT_SECRET=ADFS_CLIENT_SECRET
   export ADFS_ISSUER_URI=ADFS_ISSUER_URI
   

   Substitua as variáveis pelos seguintes valores:

   Variável	Definição
   ADFS_CERT_BASE64	O arquivo adfs.pem codificado em base64.
   ADFS_CLIENT_ID	O identificador do cliente do ADFS.
   ADFS_CLIENT_SECRET	A senha secreta compartilhada do cliente do ADFS.
   ADFS_ISSUER_URI	O URI do emissor do ADFS. Para conseguir o URI, verifique o caminho /adfs/.well-known/openid-configuration do servidor ADFS: curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration | jq '.issuer' "https://fs.opscenter.local/adfs" O valor geralmente é https://adfs.domain.com/adfs.

1.3 Crie sub-redes globais e divida-as para cada zona

Observação: esta seção só se aplica se você estiver criando uma organização v2. Se você estiver criando uma organização da v1, pule para a próxima seção.

Antes de criar uma organização, crie as sub-redes raiz globais e divida-as para cada zona com a sub-rede da API pública de gerenciamento de endereços IP (IPAM). Se você estiver criando uma organização v2 em uma zona que já tinha uma organização v1, consulte a página de outros pré-requisitos antes de criar as sub-redes globais.

As sub-redes raiz globais hospedam o pool de intervalos de endereços IP raiz (CIDR) dividido em cada zona para inicializar todos os clusters na organização do locatário, incluindo o cluster de infraestrutura da organização e as VMs de carga de trabalho. Uma pequena parte do intervalo de endereços IP também é disponibilizada para sub-redes raiz como o pool de endereços IP anycast. É possível atribuir CIDRs dedicados a cada zona automaticamente usando um controlador ou fornecer CIDRs a cada zona manualmente.

Para fazer o bootstrap de uma organização, você precisa do intervalo de endereços IP internos fornecido pelo Questionário de entrada da organização (OIQ, na sigla em inglês). Use esses intervalos de endereços IP para criar a sub-rede raiz global no servidor de API global.

É necessário criar sub-redes raiz diferentes para cada servidor de API global. O mapeamento do campo OIQ, do nome da sub-rede raiz global e do servidor de API global é fornecido na próxima seção.

1.3.1. Definir o intervalo CIDR para a OIQ

Os intervalos de CIDR não podem se sobrepor entre si nem com o zone-infra-cidr.

O zone-infra-cidr existe em cada zona e pode ser recuperado do Questionário de admissão do cliente (CIQ) se o cliente o tiver definido.

Para recuperar o zone-infra-cidr, execute:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system zone-infra-cidr

Confira abaixo um exemplo da saída YAML:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/24
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/32
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/24
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/32

Neste exemplo, o zone-infra-cidr é 192.0.2.0/24. Portanto, nenhum campo na OIQ pode se sobrepor a 192.0.2.0/24.

A tabela a seguir mostra os campos da OIQ e os valores mínimos padrão correspondentes:

Campo de OIQ	Descrição	Tamanho mínimo necessário	Tamanho mínimo por zona para a organização	Nome da sub-rede raiz global	Servidor de API global
infraVPCCIDR	Workloads do sistema, incluindo o console da organização, APIs de gerenciamento e serviços próprios.	\( 15 - \lceil \log_2(ZoneNumber) \rceil \)	16	infra-vpc-root-cidr	Raiz global
defaultVPCCIDR	Cargas de trabalho e endpoints do usuário na VPC padrão em todas as zonas.	\( 16 - \lceil \log_2(ZoneNumber) \rceil \)	16	default-vpc-root-cidr	Organização global
orgAdminExternalCIDR	Cargas de trabalho e endpoints no cluster de perímetro que processam o tráfego administrativo entre a rede externa e a organização.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	admin-external-root-cidr	Raiz global
orgDataExternalCIDR	Cargas de trabalho e endpoints que podem ser acessados externamente por usuários, como balanceadores de carga externos e NATs de saída.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	data-external-root-cidr	Raiz global

Se você não tiver IPs suficientes como o mínimo padrão sugerido, siga o processo de divisão manual para criar as sub-redes de cada zona.

Considere as seguintes limitações para intervalos de sub-rede IPv4:

• orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR e defaultVPCCIDR não podem se sobrepor entre si, com outros intervalos alocados na organização e com intervalos IPv4 em redes de peering. Os CIDRs para eles vêm do espaço de endereço privado RFC 1918.

  Redes com peering: podem ser sub-redes anunciadas com redes externas por anexos de interconexão ou sub-redes com peering com outras VPCs na mesma organização.

• Se as organizações compartilharem os mesmos recursos de interconexão AttachmentGroup, os valores orgDataExternalCIDR e orgAdminExternalCIDR precisarão ser exclusivos. Caso contrário, a sobreposição com outras organizações é permitida.

1.3.2. Criar sub-redes globais no servidor da API de administrador raiz global

Você precisa criar as seguintes sub-redes no servidor da API global de administrador raiz antes de criar uma organização:

• infra-vpc-root-cidr
• admin-external-root-cidr
• data-external-root-cidr

Essas sub-redes são necessárias para inicializar o cluster de infraestrutura da organização em cada zona.

Importante: por padrão, o GDC usa um controlador para dividir automaticamente a sub-rede raiz global e fornecer sub-redes raiz a cada zona. Se você quiser fornecer manualmente as sub-redes raiz de cada zona ou estiver adicionando uma nova zona a um universo existente, defina a anotação ipam.gdc.goog/pause-auto-division: true nos seguintes recursos Subnet para permitir especificações manuais da divisão global de sub-redes raiz.

1. Você precisa ter um namespace com um nome que corresponda ao nome da organização que será atribuído a ela. Confirme se este namespace existe:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace
   

   Se esse namespace não existir, crie-o:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME
   

2. Crie o arquivo YAML da sub-rede infra-vpc-root-cidr, como ORG_NAME-infra-vpc-root-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: infra-vpc
       ipam.gdc.goog/usage: network-root-range
     annotations:
       ipam.gdc.goog/pivot-destination: global-org
     name: infra-vpc-root-cidr
     namespace: ORG_NAME
   spec:
     ipv4Request:
       cidr: INFRA_VPC_CIDR
     type: Root
   

3. Crie o arquivo YAML da sub-rede admin-external-root-cidr, como ORG_NAME-admin-external-root-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/network-segment: admin
       ipam.gdc.goog/usage: network-root-range
     annotations:
       ipam.gdc.goog/pivot-destination: global-org
     name: admin-external-root-cidr
     namespace: ORG_NAME
   spec:
     ipv4Request:
       cidr: ORG_ADMIN_EXTERNAL_CIDR
     type: Root
   

4. Crie o arquivo YAML da sub-rede data-external-root-cidr, como ORG_NAME-data-external-root-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/network-segment: data
       ipam.gdc.goog/usage: network-root-range
     annotations:
       ipam.gdc.goog/pivot-destination: global-org
     name: data-external-root-cidr
     namespace: ORG_NAME
   spec:
     ipv4Request:
       cidr: ORG_DATA_EXTERNAL_CIDR
     type: Root
   

5. Copie os arquivos YAML de sub-rede infra-vpc-root-cidr, admin-external-root-cidr e data-external-root-cidr para o repositório de IAC da organização raiz:

   cp YAML_FILE_PATH/ORG_NAME-infra-vpc-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   cp YAML_FILE_PATH/ORG_NAME-admin-external-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   cp YAML_FILE_PATH/ORG_NAME-data-external-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   

6. Verifique se o arquivo kustomization.yaml na raiz da organização tem as definições Subnet recém-adicionadas. Verifique IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml:

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   metadata:
     name: global-root-kustomization
   resources:
   -   ... # existing resource items
   - ORG_NAME-admin-external-root-cidr.yaml
   - ORG_NAME-data-external-root-cidr.yaml
   - ORG_NAME-infra-vpc-root-cidr.yaml
   

7. Adicione e faça commit dos arquivos YAML da sub-rede:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

8. Criar solicitação de mesclagem:

   git checkout -b ${USERNAME1}-branch
   git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch
   

9. Aguarde a revisão e a fusão do código.

1.3.3. Dividir as sub-redes raiz para zonas

As sub-redes raiz globais hospedam o intervalo de endereços IP raiz (CIDR) de todas as zonas. Para consumir o intervalo de endereços IP na zona, as sub-redes raiz globais precisam primeiro ser divididas em sub-redes menores para que as zonas possam consumir. Cada zona precisa ter pelo menos um intervalo de endereços IP raiz.

O IPAM tem um controlador global que divide automaticamente a sub-rede raiz global em sub-redes menores para as zonas atuais. Os administradores podem delegar aos controladores do IPAM para dividir automaticamente a sub-rede da zona se não se importarem com o bloco CIDR exato usado por uma determinada zona. O controlador monitora a criação da sub-rede raiz global e cria uma sub-rede para cada zona com um comprimento de prefixo padrão fixo.

Sub-rede raiz da zona	Comprimento padrão do prefixo fixo
defaultZoneInfraVPCSubnetSize	16
defaultZoneAdminVRFSubnetSize	23
defaultZoneDataVRFSubnetSize	23
defaultZoneDefaultVPCSubnetSize	16
defaultAnycastSubnetSize	26

As sub-redes raiz globais precisam ter nomes fixos se você quiser que os controladores do IPAM dividam automaticamente a sub-rede da zona:

• infra-vpc-root-cidr
• admin-external-root-cidr
• data-external-root-cidr
• default-vpc-root-cidr

Se você definir a anotação ipam.gdc.goog/pause-auto-division: true para os recursos Subnet, defina manualmente o bloco CIDR exato que uma determinada zona usa. Se você criar as sub-redes raiz globais com nomes diferentes, a anotação ipam.gdc.goog/pause-auto-division não terá efeito, e as sub-redes globais não serão divididas automaticamente.

1.3.3.1. Dividir automaticamente as sub-redes raiz para zonas

O controlador global divide automaticamente a sub-rede raiz global em sub-redes menores para as zonas atuais. Por exemplo, considere o fluxo de trabalho a seguir para entender como o controlador divide a sub-rede raiz global em sub-redes menores para zonas atuais:

Se houver duas zonas chamadas zone1 e zone2, um exemplo de sub-rede raiz global infra-vpc-root-cidr usando o infraVPCCIDR, como 10.0.0.0/16, do OIQ no namespace org-1 será assim:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/14
  type: Root

Quando implantado na plataforma GDC, o controlador cria automaticamente duas sub-redes filhas chamadas infra-vpc-zone1-root-cidr e infra-vpc-zone2-root-cidr com o comprimento do prefixo /16:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

Observação: esse fluxo de trabalho se aplica apenas a algumas sub-redes raiz globais. Uma sub-rede anycast também é criada com base nela. A sub-rede anycast é a única sub-rede no servidor global da API.

1.3.3.2. Dividir manualmente as sub-redes raiz para zonas

Nesta seção, presumimos que você definiu a anotação ipam.gdc.goog/pause-auto-division: true ao criar as sub-redes raiz globais no servidor da API de administrador raiz global. Essa anotação pausa o controlador para reconciliar essas sub-redes raiz globais, o que permite criar manualmente uma sub-rede raiz de uma zona e uma sub-rede anycast.

Para dividir manualmente a sub-rede raiz global em sub-redes menores para zonas, faça o seguinte:

1. Liste as zonas no seu universo:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A
   

2. Confirme o CIDR dedicado da sub-rede raiz que você quer aplicar à sua zona. Faça isso para cada zona no seu universo.

3. Atribua o CIDR dedicado à sub-rede da sua zona em um arquivo YAML, como ORG_NAME-infra-vpc-zone1-root-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: infra-vpc
       ipam.gdc.goog/usage: zone-network-root-range
     annotations:
       ipam.gdc.goog/pivot-destination: global-org
     name: infra-vpc-zone1-root-cidr
     namespace: ORG_NAME
   spec:
     ipv4Request:
       cidr: ZONAL_CIDR
     zone: ZONE_NAME
     propagationStrategy: SingleZone
     type: Branch
     parentReference:
       name: infra-vpc-root-cidr
       namespace: ORG_NAME
   

   Repita essa etapa para cada zona no seu universo do GDC.

4. Confirme o CIDR dedicado da sub-rede raiz que você quer aplicar à sub-rede anycast.

5. Atribua o CIDR dedicado à sub-rede anycast em um arquivo YAML, como ORG_NAME-infra-vpc-anycast-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: infra-vpc
     annotations:
       ipam.gdc.goog/pivot-destination: global-org
     name: infra-vpc-anycast-cidr
     namespace: ORG_NAME
   spec:
     ipv4Request:
       cidr: ANYCAST_CIDR
     propagationStrategy: None
     type: Branch
     parentReference:
       name: infra-vpc-root-cidr
       namespace: ORG_NAME
   

6. Copie os arquivos YAML de sub-rede zonal para o repositório de IaC da organização raiz. Por exemplo, se você tiver dois arquivos YAML de sub-rede zonal:

   cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone1-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone2-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   cp YAML_FILE_PATH/ORG_NAME-infra-vpc-anycast-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
   

7. Verifique se o arquivo kustomization.yaml na raiz da organização tem as definições Subnet recém-adicionadas. Verifique IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml:

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   metadata:
     name: global-root-kustomization
   resources:
   -   ... # existing resource items
   - ORG_NAME-infra-vpc-zone1-root-cidr.yaml
   - ORG_NAME-infra-vpc-zone2-root-cidr.yaml
   - ORG_NAME-infra-vpc-anycast-cidr.yaml
   

8. Adicione e faça commit dos arquivos YAML da sub-rede:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

9. Crie a solicitação de mesclagem:

   git checkout -b ${USERNAME1}-branch
   git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch
   

10. Aguarde a revisão e a fusão do código.

1.3.3.2.1. Dividir manualmente as sub-redes raiz para o exemplo de zonas para infra-vpc

Se houver duas zonas chamadas zone1 e zone2, um exemplo de sub-rede raiz global infra-vpc-root-cidr usando o infraVPCCIDR, como 192.0.2.0/24, do OIQ no namespace org-1 será assim:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/24
  type: Root

Crie manualmente a sub-rede para cada zona chamada infra-vpc-zone1-root-cidr e infra-vpc-zone2-root-cidr, e a sub-rede anycast infra-vpc-anycast-cidr com o CIDR dedicado que você decidir:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

Adicione todos os arquivos YAML de sub-rede ao repositório de IAC.

1.3.3.2.2. Dividir manualmente as sub-redes raiz para o exemplo de zonas do segmento de rede de dados

Se houver duas zonas chamadas zone1 e zone2, uma sub-rede raiz global de exemplo data-external-root-cidr usando o orgDataExternalCIDR, como 10.0.0.0/24, do OIQ no namespace org-1 será assim:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: data-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/24
  type: Root

Crie manualmente a sub-rede para cada zona chamada data-external-zone1-root-cidr e data-external-zone2-root-cidr, e a sub-rede anycast data-global-anycast-cidr com o CIDR dedicado que você decidir:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

Adicione todos os arquivos YAML de sub-rede ao repositório de IAC.

1.3.3.2.3. Exemplo de divisão manual de sub-redes raiz para zonas no segmento de rede de administrador

Se houver duas zonas chamadas zone1 e zone2, uma sub-rede raiz global de exemplo admin-external-root-cidr usando o orgAdminExternalCIDR, como 192.168.1.0/24, do OIQ no namespace org-1 será assim:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: admin-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/24
  type: Root

Crie manualmente a sub-rede para cada zona chamada admin-external-zone1-root-cidr e admin-external-zone2-root-cidr e a sub-rede anycast admin-global-anycast-cidr com o CIDR dedicado que você decidir:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

Adicione todos os arquivos YAML de sub-rede ao repositório de IAC.

1.4. Criar uma organização com IAC

Use a IAC para criar uma organização:

1. Gere uma lista de servidores e tipos de servidores disponíveis:

   kubectl get servers -n gpc-system -o jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'
   

   A saída de exemplo é semelhante a esta:

   ag-aa-bm04   o1-standard1-64-gdc-metal   available
   ag-ab-bm07   o1-standard1-64-gdc-metal   available
   ag-ab-bm11   o1-highmem1-96-gdc-metal    available
   ag-ab-bm12   o1-highmem1-96-gdc-metal    available
   ag-ab-bm13   o1-highmem1-96-gdc-metal    available
   ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
   ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
   ag-ab-bm16   o1-highgpu1-48-gdc-metal    available
   

   Ao especificar --server-quota e --admin-server mais tarde, verifique se você tem servidores available suficientes para atender à solicitação.

2. Navegue até o repositório iac e adicione a estrutura de diretórios da nova organização:

   mkdir -p infrastructure/global/orgs/root/ORG_NAME/
   

3. Crie um recurso personalizado Organization:

   gdcloud organizations config create --name ORG_NAME \
       --log-retention-policy LOG_RETENTION_POLICY \
       --kms-root-key-type KMS_ROOT_KEY_TYPE
   

   Exemplo:

   gdcloud organizations config create --name org-1 \
       --log-retention-policy paAuditLogsRetentionTime=400,ioAuditLogsRetentionTime=2000,operationalLogsRetentionTime=90,metricsRetentionTime=90 \
       --kms-root-key-type ctm-root
   

   Substitua as seguintes variáveis:

   Variável	Definição
   ORG_NAME	O nome da organização. O nome de uma organização precisa atender aos seguintes critérios: Ter de 3 a 19 letras ASCII minúsculas, dígitos ou hifens. Comece com uma letra. Não ter hifens no final. Não pode terminar com a string -system.
   LOG_RETENTION_POLICY	A configuração de tempos de retenção para registros de auditoria, registros operacionais e métricas em dias.
   KMS_ROOT_KEY_TYPE	Essa configuração contém o tipo de chave raiz escolhido para o KMS de uma organização. Todo serviço do KMS tem uma chave raiz para criptografar as chaves geradas pelo KMS. Por padrão, o KMS gera uma chave raiz do CTM, uma chave raiz armazenada no Thales CipherTrust Manager com backup de um HSM físico. Você também pode escolher uma chave raiz de software armazenada como um secret do Kubernetes. Transmita ctm-root ou local-root para kmsRootKeyType.

   Um exemplo do arquivo YAML de recurso personalizado Organization gerado é semelhante ao seguinte:

   apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
   kind: Organization
   metadata:
       namespace: gpc-system
       name: org-1
   spec:
       type: Tenant
       logRetentionPolicy:
           paAuditLogsRetentionTime: 400
           ioAuditLogsRetentionTime: 2000
           operationalLogsRetentionTime: 90
           metricsRetentionTime: 90
       securityConfig:
         kmsRootKeyType: "ctm-root"
   

4. Opcional: Na versão 1.14.2 e mais recentes, a criptografia IPsec de nó para nó está desativada por padrão. Se essa criptografia IPsec for necessária, edite o arquivo YAML de recurso personalizado Organization e adicione uma anotação para ativar a criptografia IPsec de nó para nó:

   metadata:
       annotations:
           n2n.security.private.gdc.goog/node-to-node-encryption-disabled: "false"
   

   Um valor de "false" para essa anotação ativa a criptografia.

5. Crie um recurso personalizado OrganizationZonalConfig para cada zona na implantação:

   gdcloud organizations zonal-configs create --name ORG_NAME \
       --zones=ZONES \
       --version GDC_VERSION \
       --server-quota SERVER_QUOTA \
       --storage-sku STORAGE_SIZE \
       --admin-server ADMIN_SERVER
   

   Exemplo:

   gdcloud organizations zonal-configs create --name org-1 \
       --zones=us-central1-a,us-central1-b \
       --version 1.9.2-gdch.153 \
       --server-quota o1-highmem1-40-gdc-metal=1,o1-standard1-64-gdc-metal=2,o1-highmem1-96-gdc-metal=3,o1-highmem1-104-gdc-metal=4,o1-highmem1-448-gdc-metal=5,o1-highgpu1-48-gdc-metal=6 \
       --storage-sku block-standard=100Ti,file-standard=100Ti,object-standard=100Ti \
       --admin-server o1-standard1-64-gdc-metal=3
   

   Prévia: o GDC oferece a capacidade de criar organizações assimétricas em várias zonas como um recurso de prévia a partir da versão 1.14.4. Por exemplo, cada recurso personalizado OrganizationZonalConfig pode ser diferente para cada zona. Da mesma forma, você pode optar por não criar um recurso personalizado OrganizationZonalConfig para uma zona atual.

   Substitua as seguintes variáveis:

   Variável	Definição
   ORG_NAME	O nome da organização. O nome de uma organização precisa atender aos seguintes critérios: Ter de 3 a 30 letras ASCII minúsculas, dígitos ou hífens. Comece com uma letra. Não ter hifens no final. Não pode terminar com a string -system.
   ZONES	Os nomes das zonas na implantação.
   GDC_VERSION	A versão do sistema GDC para criar a organização.
   SERVER_QUOTA	Os servidores a serem alocados para o cluster de administrador da organização e o cluster do sistema quando eles são gerados automaticamente. Se você pretende executar recursos de unidade de processamento gráfico (GPU) que são cargas de trabalho baseadas em VM, como APIs de inteligência artificial e aprendizado de máquina (IA/ML) pré-treinadas, é necessário provisionar máquinas de GPU ao criar uma organização. Para mais informações, consulte a seção Ativar o suporte a GPU para clusters do sistema.
   ADMIN_SERVER	Um par de chave-valor do tipo de servidor e a quantidade de servidores de administrador da organização a serem alocados para esse tipo de servidor. Tipos mistos não são compatíveis com servidores. O valor padrão é o1-standard1-64-gdc-metal: 3.
   STORAGE_SIZE	O tamanho dos diferentes tipos de armazenamento a serem atribuídos à organização. O tamanho mínimo de armazenamento em blocos para uma organização é de 250 Gi, que é definido com a flag BlockStandard.

   Um exemplo do arquivo YAML de recurso personalizado OrganizationZonalConfig gerado é semelhante ao seguinte:

   apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
   kind: OrganizationZonalConfig
   metadata:
     namespace: gpc-system
     name: org-1-zone1-config
   spec:
     organizationRef:
       name: org-1
     zone: zone1
     version: 1.5.0-gdch.11
     capacities:
       storage:
         block-standard: 10Ti
         file-standard: 10Ti
         object-nearline: 10Ti
         object-standard: 10Ti
       workloadServers:
         o1-highmem1-40-gdc-metal: 1
   

6. Revise os arquivos YAML gerados. Os arquivos estão localizados no diretório HOME.

   1. Confirme o tipo de organização. Há dois tipos de organizações que você pode provisionar:

      • Arquitetura da organização v1 (organização v1)
      • Arquitetura da organização v2 (organização v2)

      Por padrão, as novas organizações são provisionadas com base no tipo de implantação, conforme definido pelas configurações de flag de recurso:

      • As implantações do PRODUCTION geram organizações da v2 por padrão.
      • As implantações do ACCREDITED geram organizações da v1 por padrão.

      No raro caso de precisar substituir o tipo de organização padrão para seu tipo de implantação, atualize o campo spec.compatibilityOptions.architectureOverridePolicy no recurso personalizado Organization gerado para ForceV1 ou ForceV2, dependendo do tipo de organização que você quer usar. Por exemplo, o snippet a seguir força a criação de uma organização v2 em uma implantação ACCREDITED:

      ...
      
      spec:
      ...
        compatibilityOptions:
          architectureOverridePolicy: ForceV2
      
      ...
      

   2. Confirme as configurações restantes para garantir que componentes como armazenamento e capacidade de computação sejam suficientes para as necessidades da sua empresa.

7. Copie os recursos personalizados Organization e OrganizationZonalConfig para o repositório no diretório da nova organização:

   cp YAML_FILE_PATH/ORG_NAME.yaml IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/
   

   cp YAML_FILE_PATH/ORG_NAME-ZONE.yaml IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/
   

   Substitua:

   • ORG_NAME: o nome da organização que você definiu no comando gdcloud organizations config create usando o parâmetro --name.
   • ZONE: o nome de cada zona na implantação. O nome da zona é derivado usando o seguinte formato: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Por exemplo, us-central1-b. Consulte a seção "Zona" no Questionário de admissão de clientes para descrições dos valores do atributo de zona.

8. Adicione o arquivo kustomization.yaml para a nova organização:

   cat > IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/kustomization.yaml << EOF
   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   metadata:
     name: ORG_NAME-kustomization
   resources:
   -   ORG_NAME.yaml
   -   ORG_NAME-ZONE.yaml
   EOF
   

9. Adicione a nova organização como um recurso da organização raiz:

   1. Abra o arquivo kustomization.yaml da raiz global:

      vim /iac/infrastructure/global/orgs/root/kustomization.yaml
      

   2. Adicione o novo Organization como um recurso no final da lista de recursos atual:

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: global-root-kustomization
      resources:
      -   ... # existing resource items
      -   ORG_NAME
      

10. Adicione e faça commit do arquivo YAML da organização e dos arquivos kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
    git commit
    

11. Criar solicitação de mesclagem:

    git checkout -b ${USERNAME1}-branch
    git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch
    

12. Aguarde a revisão e a fusão do código.

13. Verifique se a organização global e as configurações zonais estão disponíveis:

    1. Verifique se a organização global está disponível no seu universo do GDC:

       kubectl get organization -A
       

       O resultado será assim:

       NAMESPACE    NAME    AGE
       gpc-system   org     34s
       gpc-system   root    14h
       

       Observação: se não for possível acessar os servidores da nova organização,talvez seja necessário trabalhar com a equipe de administração de rede para ativar a conectividade com os endereços IP e as portas adequados da organização recém-criada.

    2. Verifique o status da organização global:

       kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG \
           get organization/ORG_NAME -n gpc-system -o yaml
       

       Verifique se as condições status na saída YAML são True.

    3. Verifique o status da configuração da organização em cada zona:

       kubeconfig --kubeconfig ROOT_ADMIN_KUBECONFIG \
           get organization/ORG_NAME -n gpc-system -o yaml
       

       Para mudar os contextos zonais, use a CLI gdcloud para fazer login em cada zona antes de verificar o status da organização. Verifique se as condições status na saída YAML de cada zona são True.

1.5. Criar sub-redes globais no servidor da API da organização global

Observação: esta seção só se aplica se você estiver criando uma organização v2. Se você estiver criando uma organização da v1, pule para a próxima seção.

Você precisa criar o default-vpc-root-cidr no servidor de API global da organização no namespace platform depois que o servidor de API global estiver em execução. Essa sub-rede raiz aloca o endereço IP para clusters dentro da organização do locatário, como clusters de usuário, bem como endereços IP para cargas de trabalho de VM.

1. Crie o arquivo YAML da sub-rede default-vpc-root-cidr, como default-vpc-root-cidr.yaml:

   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/allocation-preference: default
       ipam.gdc.goog/vpc: default-vpc
       ipam.gdc.goog/usage: network-root-range
     name: default-vpc-root-cidr # don't change the name if you want IPAM controller to automatically divide the zone's subnet.
     namespace: platform
   spec:
     type: Root
     ipv4Request:
       cidr: DEFAULT_VPC_CIDR
   

2. Navegue até o repositório iac e adicione a estrutura de diretórios da organização global:

   cd iac; mkdir -p infrastructure/global/orgs/ORG_NAME/
   

3. Copie o arquivo YAML da sub-rede default-vpc-root-cidr para o repositório da IAC no diretório da nova organização:

   cp YAML_FILE_PATH/default-vpc-root-cidr.yaml \
       IAC_REPO_PATH/iac/infrastructure/global/orgs/ORG_NAME/
   

4. Crie o arquivo kustomization.yaml na pasta da organização com as definições Subnet recém-adicionadas. Verifique IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml:

   cat > infrastructure/global/orgs/ORG_NAME/kustomization.yaml << EOF
   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   metadata:
     name: ORG_NAME-kustomization
   resources:
   - default-vpc-root-cidr.yaml
   EOF
   

5. Adicione e faça commit do arquivo YAML da organização e dos arquivos kustomize:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

6. Crie a solicitação de mesclagem:

   git checkout -b ${USERNAME1}-branch
   git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch
   

7. Aguarde a revisão e a fusão do código.

Assim como as sub-redes globais no cluster de administrador raiz global são divididas, o default-vpc-root-cidr também é dividido e propagado para cada zona para que a organização zonal consuma endereços IP.

1.7. Configurar o NTPRelay do administrador da organização

É necessário configurar manualmente a autenticação entre os NTPRelays root-admin e org-admin.

Siga NTP-P0001.3 (administrador raiz -> administrador da organização -> criptografia NTPRelay) para configurar a criptografia para essa organização.

1.8. Conectar o provedor de identidade do IO à organização com IAC

1. Consulte o guia do ADFS para criar um cliente OIDC no ADFS para a nova organização e anote o ID do cliente e a chave secreta do cliente OIDC.

2. Defina o nome da organização como uma variável de ambiente:

   export ORG_NAME=ORG_NAME
   

   Verifique se o ORG_NAME corresponde ao nome exato da organização.

3. Exporte o arquivo kubeconfig do cluster de administrador raiz e execute os seguintes comandos kubectl para receber os nomes do cluster e da zona:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl get clusters -A
   kubectl get zones -n mz-system
   

4. Adicione o arquivo ioauthmethod.yaml para a organização:

   cat > infrastructure/global/orgs/${ORG_NAME}/ioauthmethod.yaml << EOF
   apiVersion: iam.global.private.gdc.goog/v1alpha1
   kind: IOAuthMethod
   metadata:
     name: io-idp-authmethod
     namespace: gpc-system
   oidc:
     certificateAuthorityData: ADFS_CERT_BASE64
     clientID: ADFS_ORG_CLIENT_ID
     clientSecret: ADFS_ORG_CLIENT_SECRET
     groupPrefix: gdch-infra-operator-
     groupsClaim: groups
     issuerURI: ADFS_ISSUER_URI
     scopes: openid email offline_access
     userClaim: email
     userPrefix: gdch-infra-operator-
     cloudConsoleRedirectURI: http://cloud.console.not.enabled
     kubectlRedirectURI: http://localhost:9879/callback
   EOF
   

   Substitua as seguintes variáveis:

   Variável	Definição
   ADFS_CERT_BASE64	A codificação base64 do certificado que o ADFS usa para autoassinatura, que o GKE Identity Service exige para estabelecer uma conexão segura com uma instância interna do ADFS.
   ADFS_ORG_CLIENT_ID	O ID do OpenID Connect para o cliente da organização no ADFS.
   ADFS_ORG_CLIENT_SECRET	A chave secreta do OpenID Connect para o cliente da organização registrada no ADFS.
   ADFS_ISSUER_URI	Um URI de emissor válido, que é exigido pelo serviço de identidade do GKE para permitir solicitações de login de redirecionamento para o ADFS.

5. Adicione o arquivo initial-admin.yaml para a organização:

   cat > infrastructure/global/orgs/${ORG_NAME}/initial-admin.yaml << EOF
   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: ExpirationClusterRoleBinding
   metadata:
     name: iac-binding-USER-org-iam-admin
   spec:
     expirationTimestamp: EXPIRATION
     roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: ClusterRole
       name: organization-iam-admin
     subjects:
       - apiGroup: rbac.authorization.k8s.io
         kind: User
         name: [e-mail]
   EOF
   

   Substitua as seguintes variáveis:

   Variável	Definição
   USER	O nome de usuário com o prefixo da E/S para fazer login no cluster inicialmente. Não se esqueça de anexar o prefixo ao nome de usuário.
   EXPIRATION	O carimbo de data/hora formatado em RFC 3339 em que o sistema revoga o acesso. Por exemplo, "2020-11-14T00:20:12+00:00".

6. Adicione os arquivos recém-criados ao arquivo kustomization.yaml em IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml:

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   metadata:
     name: ORG_NAME-kustomization
   resources:
   -   ... # existing resource items
   - ioauthmethod.yaml
   - initial-admin.yaml
   

7. Adicione e faça commit do arquivo YAML da organização e dos arquivos kustomize:

   git add "infrastructure/global"
   git add "infrastructure/zonal"
   git commit
   

8. Envie a atualização para o GitLab:

   git -c http.sslVerify=false push
   

9. Aguarde a revisão e a fusão do código.

10. Para confirmar que o operador pode acessar a organização, faça login na organização gerada e execute o comando a seguir para verificar se um provedor de identidade (IdP) existe no ClientConfig da organização:

    1. Defina o arquivo kubeconfig do cluster de administrador de acordo com a arquitetura da sua organização:

       • Para uma organização da v1, execute:

         export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
         

         Substitua ORG_ADMIN_CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster de administrador da organização, como /tmp/${ORG}-admin-kubeconfig.

       • Para uma organização da v2, execute:

         export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG
         

         Substitua ORG_INFRA_CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster de infraestrutura da organização, como /tmp/${ORG}-infra-kubeconfig.

    2. Verifique se um IdP existe no ClientConfig da organização:

       kubectl get ClientConfig default -n kube-public -o yaml
       

11. Na versão 1.14.3, é necessário aplicar manualmente a função global-zone-viewer para permitir que todos os usuários autenticados vejam as zonas em um universo usando a CLI gdcloud. Aplique os recursos de papel e vinculação de papel:

    kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: global-zone-viewer
      namespace: mz-system
    rules:
    - apiGroups:
      - location.mz.global.private.gdc.goog
      resources:
      - zones
      verbs:
      - get
      - list
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: global-zone-viewer-binding
      namespace: mz-system
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: global-zone-viewer
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:authenticated
    EOF
    

    Substitua ORG_GLOBAL_API_SERVER_KUBECONFIG pelo arquivo kubeconfig do servidor da API global da organização. Para mais informações, consulte Gerar manualmente o arquivo kubeconfig.

1.9. Conectar o provedor de identidade do cliente à organização

Para conectar um provedor de identidade (IdP) do cliente à organização e fazer login nela com as identidades, siga estas etapas:

1. Faça login na CLI com a conta inicial de administrador de E/S definida durante a criação da organização, que é vinculada automaticamente a org-iam-admin no cluster de administrador da organização.

2. Peça ao cliente para adicionar o seguinte URL de callback global da AIS à lista de permissões no cliente OIDC ou SAML criado para a organização que você vai criar:

   https://ais-core.ORG_NAME.GDC_URL/finish-login
   

   Por exemplo, se o URL raiz do GDC for .google.gdch.test e o nome da organização for operations, o URL de callback global da AIS será https://ais-core.operations.google.gdch.test/finish-login.

   Se você estiver usando um cliente SAML, adicione também o seguinte URL de callback SAML global da AIS à lista de permissões:

   https://ais-core.ORG_NAME.GDC_URL/saml-callback
   

3. Peça ao cliente para adicionar o seguinte URL de callback da AIS à lista de permissões no cliente OIDC ou SAML que ele criou para cada zona. Por exemplo, para um universo de três zonas, os URLs de callback da AIS zonal são semelhantes a estes:

   https://ais-core.ORG_NAME.ZONE_1.GDC_URL/finish-login
   
   https://ais-core.ORG_NAME.ZONE_2.GDC_URL/finish-login
   
   https://ais-core.ORG_NAME.ZONE_3.GDC_URL/finish-login
   

   Se o URL raiz do GDC for .google.gdch.test, o nome da zona for zone-1 e o nome da organização for operations, o URL de callback da AIS será https://ais-core.operations.zone-1.google.gdch.test/finish-login.

   Se você estiver usando um cliente SAML, adicione também os seguintes URLs de retorno de chamada SAML da AIS à lista de permissões de cada zona:

   https://ais-core.ORG_NAME.ZONE_1.GDC_URL/saml-callback
   
   https://ais-core.ORG_NAME.ZONE_2.GDC_URL/saml-callback
   
   https://ais-core.ORG_NAME.ZONE_3.GDC_URL/saml-callback
   

4. Defina o arquivo kubeconfig do cluster de administrador de acordo com a arquitetura da sua organização. Se você já definiu a variável kubeconfig, pule esta etapa.

   • Para uma organização da v1, execute:

       export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
     

     Substitua ORG_ADMIN_CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster de administrador da organização, como /tmp/${ORG}-admin-kubeconfig.

   • Para uma organização da v2, execute:

       export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
     

     Substitua MANAGEMENT_API_SERVER_KUBECONFIG pelo caminho para o kubeconfig do servidor da API Management, como /tmp/${ORG}-management-kubeconfig.

5. No tíquete de solicitação do cliente para uma nova organização, decida se o IdP usa OIDC ou SAML. Siga o guia que corresponde ao tipo de IdP fornecido:

   • Configuração com OIDC
   • Configuração com SAML
   Observação: escolha a configuração do OIDC ou do SAML para seguir. Isso é baseado no IdP do cliente. Não configure os dois.

Configuração com o OIDC

1. Crie um arquivo identity-provider-config.yaml e preencha-o consultando os tíquetes de criação da organização para valores do IdP da conta do PA:

   cat << EOF > identity-provider-config.yaml
   apiVersion: iam.global.gdc.goog/v1
   kind: IdentityProviderConfig
   metadata:
     name: pa-idp-oidc
     namespace: platform
   spec:
     oidc:
       certificateAuthorityData: "PA_IDP_BASE64_ENCODED_CERTIFICATE"
       clientID: PA_IDP_CLIENT_ID
       clientSecret: PA_IDP_CLIENT_SECRET
       groupPrefix: PA_IDP_GROUP_CLAIM
       groupsClaim: PA_IDP_PREFIX
       issuerURI: PA_IDP_ISSUER_URI
       scopes: openid email profile
       userClaim: PA_IDP_USER_CLAIM
       userPrefix: PA_IDP_PREFIX
   EOF
   

   Observação: atribua um prefixo ao IdP se o cliente não fornecer um. Consulte Prefixo de usuário e grupo para mais informações.

2. Confira as descrições detalhadas dos campos:

   Atributo	Tipo de atributo	Descrição
   certificateAuthorityData	Obrigatório	Um certificado de autoridade de certificação padrão codificado em base64 e formatado em PEM para o provedor OIDC.
   clientID	Obrigatório	O ID do aplicativo cliente que faz solicitações de autenticação para o provedor OpenID.
   clientSecret	Obrigatório	A senha secreta compartilhada entre o aplicativo cliente do OIDC e o provedor OIDC.
   extraParams	Opcional	Uma lista separada por vírgulas de pares de chave-valor que são codificados por consulta e enviados com a solicitação de endpoint de autenticação.
   groupPrefix	Opcional	O prefixo a ser adicionado à declaração de grupos para evitar conflitos com os grupos atuais, geralmente usado ao configurar vários provedores de identidade. É necessário incluir o prefixo do grupo antes de todos os nomes de grupo. Por exemplo, se você tiver myprefix- como prefixo do grupo e um grupo chamado groupA no provedor de identidade, ao adicionar uma política ou vinculação, vincule myprefix-groupA. O nome do grupo é definido no campo groupsClaim. Observação: o GDC não insere um separador entre o prefixo e o nome do grupo. Insira um separador, como - ou :, no final do prefixo para aumentar a legibilidade. Caso contrário, prefix e [e-mail] serão identificados como [e-mail].
   groupsClaim	Opcional	O nome da declaração no token de ID do OIDC que contém as informações dos grupos do usuário. Esse nome precisa ser igual ao da declaração que contém informações de associação a grupos no provedor OIDC.
   issuerURI	Obrigatório	O URL para onde as solicitações de autorização são enviadas para o provedor OIDC. Esse URI precisa apontar para o nível dentro de .well-known/openid-configuration.
   scopes	Opcional	Uma lista de identificadores separados por vírgulas para especificar quais privilégios de acesso são solicitados, além do escopo openid.
   userClaim	Obrigatório	O nome da declaração no token de ID do OIDC que contém o nome de usuário. Por exemplo, se a declaração do usuário for email, os usuários serão identificados pelo campo de usuário no token OIDC. Se ele estiver ausente do token de ID, a autenticação falhará.
   userPrefix	Opcional	O prefixo a ser adicionado às declarações de usuário para evitar conflitos com os nomes de usuário atuais, geralmente usado ao configurar vários provedores de identidade. Por exemplo, se a declaração do usuário for email e o prefixo do usuário for prefix-, os usuários serão identificados como [e-mail]. O usuário é [e-mail] e o prefixo prefix- é prefixado no usuário para distinguir os diferentes provedores de identidade. Recomendamos a inserção de um separador no final do prefixo, conforme descrito anteriormente nesta tabela para configurar groupPrefix.

3. Opcional: se o provedor de identidade usar atributos personalizados, primeiro configure os atributos no IdP. Em seguida, adicione os pares de chave-valor correspondentes na seção oidc do arquivo identity-provider-config.yaml para outras declarações sobre usuários ou grupos, como departamento ou aniversário. Quando você aplica as mudanças à configuração do provedor de identidade, o GKE Identity Service reconhece os atributos personalizados. Confira um exemplo de atributos personalizados:

     "attributeMapping": {
     "attribute.birthday": "assertion.birthday",
     "attribute.department": "assertion.department"
     }
   

4. Configure a configuração do provedor de identidade:

   kubectl apply -f identity-provider-config.yaml
   

5. Aguarde a reconfiguração dos vários componentes do sistema.

6. Para verificar a configuração, abra o console da interface do administrador da plataforma em um navegador da Web. Selecione Fazer login com pa-idp-oidc na página de redirecionamento. Se você for redirecionado para a instância do IdP da conta do PA e voltar para a página do console da interface do administrador da plataforma depois de fazer login com a instância do IdP da conta do PA, a configuração será bem-sucedida. Caso contrário, verifique os valores em identity-provider-config.yaml e repita a etapa anterior.

Configuração com SAML

1. Crie um arquivo identity-provider-config.yaml e preencha-o consultando os tíquetes de criação da organização para valores do IdP da conta do PA:

   cat << EOF > identity-provider-config.yaml
   apiVersion: iam.global.gdc.goog/v1
   kind: IdentityProviderConfig
   metadata:
     name: pa-idp-saml
     namespace: platform
   spec:
     saml:
       idpEntityID: PA_IDP_ISSUER_URI
       idpSingleSignOnURI: PA_IDP_SSO_URI
       groupPrefix: PA_IDP_PREFIX
       groupsAttribute: PA_IDP_GROUPS_ATTRIBUTE
       idpCertificateDataList: [PA_IDP_SAML_CERT]
       userAttribute: PA_IDP_USER_ATTRIBUTE
       userPrefix: PA_IDP_PREFIX
   EOF
   

   Observação: atribua um prefixo ao IdP se o cliente não fornecer um. Consulte Prefixo de usuário e grupo para mais informações.

2. Confira as descrições detalhadas dos campos:

   .

   Atributo	Tipo de atributo	Descrição
   idpCertificateDataList	Obrigatório	Os certificados do IdP usados para verificar a resposta SAML. Esses certificados precisam ser codificados em base64 padrão e formatados no formato PEM. Apenas dois certificados são aceitos para facilitar a rotação de certificados do IdP.
   idpEntityID	Obrigatório	O ID da entidade SAML do provedor de SAML, especificado em um formato de URI. Por exemplo, https://www.idp.com/saml.
   idpSingleSignOnURI	Obrigatório	O URI do endpoint de SSO do provedor de SAML. Por exemplo, `https://www.idp.com/saml/sso`.
   groupPrefix	Opcional	O prefixo opcional a ser adicionado ao início de cada nome de grupo.
   userPrefix	Opcional	O prefixo opcional a ser adicionado ao início do nome de usuário.
   userAttribute	Opcional	O nome do atributo na resposta SAML que contém o nome de usuário. Se esse atributo estiver ausente da resposta SAML, a autenticação vai falhar.
   groupsAttribute	Opcional	O nome do atributo na resposta SAML que contém os grupos do usuário.

3. Opcional: se o provedor de identidade usar atributos personalizados, primeiro configure os atributos no IdP. Em seguida, adicione os pares de chave-valor correspondentes na seção saml do arquivo identity-provider-config.yaml para outras declarações sobre usuários ou grupos, como departamento ou aniversário. Quando você aplica as mudanças à configuração do provedor de identidade, o GKE Identity Service reconhece os atributos personalizados. Confira um exemplo de atributos personalizados:

     "attributeMapping": {
     "attribute.birthday": "assertion.birthday",
     "attribute.department": "assertion.department"
     }
   

4. Configure o patch de configuração do provedor de identidade:

   kubectl apply -f identity-provider-config.yaml
   

5. Aguarde a reconfiguração dos vários componentes do sistema.

6. Para verificar a configuração, abra o console da interface do administrador da plataforma em um navegador da Web. Selecione Fazer login com pa-idp-oidc na página de redirecionamento. Se você for redirecionado para a instância do IdP da conta do PA e voltar para a página do console da interface do administrador da plataforma depois de fazer login com a instância do IdP da conta do PA, a configuração será bem-sucedida. Caso contrário, verifique os valores em identity-provider-config.yaml e repita a etapa anterior.

Prefixo de usuário e grupo

Os prefixos de usuário e grupo precisam ser definidos para cada IdP na Distributed Cloud para evitar conflitos de nomenclatura entre contas de diferentes IdPs. O prefixo é usado com o nome do usuário e do grupo para concatenar o nome do assunto nas vinculações de função no cluster. Por exemplo, para um usuário com o nome [e-mail] e o prefixo do usuário do IdP example-org-idp-, o nome do assunto no cluster seria [e-mail].

Para decidir o valor do prefixo:

• Inclua o nível da hierarquia (raiz, organização, projeto).
• Inclua o nome do IdP (adfs, keycloak).
• Recomendamos adicionar um caractere separador, como -, como um sufixo, porque nenhum separador é adicionado entre o prefixo e o nome de usuário.

Atribuir administrador inicial

Para conceder o acesso inicial do PA à organização, ele precisa ser atribuído como administrador dela. Para atribuir o PA como administrador inicial, crie um IAMRoleBinding no servidor da API global:

kubectl apply -f --kubeconfig=GLOBAL_API_SERVER_KUBECONFIG - <<EOF
apiVersion: iam.global.gdc.goog/v1
kind: IAMRoleBinding
metadata:
  name: PA_INITIAL_ADMIN_EMAIL-binding
  namespace: platform
spec:
  roleRef:
    apiGroup: iam.global.gdc.goog
    kind: IAMRole
    name: organization-iam-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: PA_IDP_PREFIXPA_INITIAL_ADMIN_EMAIL
EOF

1.10 Estabelecer conectividade de rede para a organização

Uma organização recém-criada é isolada e não pode ser acessada de nenhuma rede externa. Para tornar a organização operacional, conecte-a a uma ou mais redes externas usando o serviço Interconnect.

Esse processo envolve a configuração de um conjunto de recursos personalizados que definem a conexão lógica. Confira a seguir dois cenários comuns para fornecer conectividade a uma nova organização.

Cenário 1: anexar uma organização a uma interconexão compartilhada

Se você já tiver uma interconexão para uma rede compartilhada, basta atualizar AttachmentGroup e RoutePolicy para incluir a nova organização.

1. Atualize o AttachmentGroup:um AttachmentGroup especifica quais organizações podem usar um conjunto de anexos da VLAN. Edite o arquivo YAML AttachmentGroup e adicione a nova organização à lista spec.entities. Para uma organização da v2, especifique a rede domainType (OrgAdmin, OrgData ou OrgMixed) a ser conectada.

   Exemplo de atualização do AttachmentGroup:

   apiVersion: system.private.gdc.goog/v1alpha1
   kind: AttachmentGroup
   metadata:
     name: attachment-group-shared
     namespace: gpc-system
   spec:
     identifier: shared-network
     entities:
     - orgName: existing-org-1 # Existing organization
       domainType: OrgMixed
     - orgName: new-customer-org # Add the new organization
       domainType: OrgMixed
   

2. Atualize o RoutePolicy:o RoutePolicy define quais prefixos de IP são anunciados. Edite a política e adicione as sub-redes de IP externo da nova organização ao spec.out.ipPrefixList. Isso permite que o tráfego de entrada alcance a organização.

   Exemplo de atualização do RoutePolicy:

   apiVersion: system.private.gdc.goog/v1alpha1
   kind: RoutePolicy
   metadata:
     name: shared-routepolicy
     namespace: gpc-system
   spec:
     # ... other fields ...
     out:
       asPathAccessList:
       - action: Permit
         asPathRegex: ".*"
       ipPrefixList:
       - action: Permit
         ipPrefix: EXTERNAL_SUBNET_OF_EXISTING_ORG_1
       - action: Permit
         ipPrefix: EXTERNAL_SUBNET_OF_NEW_CUSTOMER_ORG # Add new prefix
       # ... deny rules ...
   

3. Aplique as mudanças usando kubectl apply com seu processo de infraestrutura como código (IaC).

Cenário 2: criar uma nova interconexão dedicada

Para uma conexão dedicada, é necessário criar um novo conjunto de recursos de interconexão. O processo completo envolve a criação de cinco recursos personalizados em ordem.

1. Crie um InterconnectLink para cada nova conexão física.
2. Crie um InterconnectGroup para agrupar os links físicos e permitir a nova organização.
3. Crie um AttachmentGroup e especifique a nova organização na lista entities.
4. Crie um RoutePolicy que permita os prefixos de IP de entrada e saída para essa conexão dedicada.
5. Crie um ou mais recursos InterconnectAttachment para definir as VLANs e as sessões do BGP.

Para conferir exemplos abrangentes e etapas detalhadas de cada um desses recursos, consulte a documentação Configurar uma interconexão.

1.11 Configurar o webhook do Alertmanager para se conectar ao ServiceNow

Siga as etapas em MON-T0016 para conectar o webhook do Alertmanager ao ServiceNow e criar incidentes.

1.12 Configurar a tabela de preços de faturamento para a organização

O subcomponente de faturamento de uma organização exige que o produto ou os serviços a serem faturados sejam configurados com o recurso personalizado SKUDescription. Um único SKUDescription descreve um produto ou serviço a ser faturado com o preço. Portanto, uma coleção de objetos SKUDescription pode ser considerada a tabela de preços de uma organização. As etapas a seguir configuram a tabela de preços para a organização na IAC.

1.12.1. Receber a tabela de preços

Se você ainda não tiver os recursos da planilha de preços do SKUDescription para uma organização, entre em contato com o Escritório de Gerenciamento de Programas (PMO) para receber a planilha de preços. A tabela de preços precisa ser uma série de arquivos YAML com recursos SKUDescription.

1.12.2 Determinar se a tabela de preços é compartilhada ou não

A tabela de preços pode ser compartilhada em todas as organizações ou configurada individualmente. A PMO pode informar se a tabela de preços é compartilhada ou não.

1.12.2.1 Planilha de preços compartilhada

Se a tabela de preços for compartilhada, coloque-a na pasta compartilhada common-data do IAC.

1. Se essa não for a primeira organização criada, a tabela de preços já poderá estar na pasta compartilhada common-data. Se a tabela de preços existir, verifique se as etapas de 2 a 4 foram seguidas e prossiga com a etapa 5.

2. Crie a pasta compartilhada para a tabela de preços.

   mkdir -p IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
   

   Substitua IAC_REPO_PATH pelo caminho para o repositório de IAC.

3. Salve os recursos YAML da tabela de preços SKUDescription nessa pasta. Depois disso, a pasta skudescriptions precisa conter arquivos YAML separados por área. Configure a estrutura de pastas e os arquivos YAML para se alinhar ao seu caso de uso de faturamento:

   • Faturamento operado pelo parceiro: o Google cobra do parceiro. Coloque os recursos SKUDescription no namespace partner-billing-system.

   • Faturamento do cliente: o parceiro cobra do usuário final. Coloque os recursos SKUDescription no namespace billing-system.

   Os exemplos a seguir mostram as estruturas de arquivos de faturamento do cliente e do modelo de faturamento operado pelo parceiro. Para cada modelo, você vê dois serviços, computação e armazenamento, com dois arquivos YAML para cada serviço:

   Faturamento do cliente:

   ├── customer
        ├── compute
        │   ├── compute-sku1.yaml
        │   └── compute-sku2.yaml
        └── storage
            ├── storage-sku1.yaml
            └── storage-sku2.yaml
   

   Faturamento operado pelo parceiro:

   ├── partner
        ├── compute
        │   ├── partner-compute-sku1.yaml
        │   └── partner-compute-sku2.yaml
        └── storage
            ├── partner-storage-sku1.yaml
            └── partner-storage-sku2.yaml
   

4. Verifique se há um arquivo kustomization.yaml no diretório que inclui todos os arquivos YAML da tabela de preços SKUDescription.

   touch IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/kustomization.yaml
   cd IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
   kustomize edit add resource */*.yaml
   

5. Exporte a variável de ambiente ORG_CLUSTER:

   • Para uma organização da v1, execute:

     export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME
     

   • Para uma organização da v2, execute:

     export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME
     

6. Crie o diretório de faturamento skudescriptions na organização:

   • Para uma organização da v1:

     mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions
     

   • Para uma organização da v2:

     mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions
     

   Substitua ORG_CLUSTER_NAME pelo nome do cluster de administrador da organização, dependendo do tipo de versão da organização.

7. Inclua a tabela de preços comum na organização:

   • Para uma organização da v1:

     cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml << EOF
     apiVersion: kustomize.config.k8s.io/v1beta1
     kind: Kustomization
     resources:
     - ../../../../common-data/bil/skudescriptions
     EOF
     

   • Para uma organização da v2:

     cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml << EOF
     apiVersion: kustomize.config.k8s.io/v1beta1
     kind: Kustomization
     resources:
     - ../../../../common-data/bil/skudescriptions
     EOF
     

8. Adicione e faça commit do arquivo YAML e personalize os arquivos:

   cd IAC_REPO_PATH
   git add "iac"
   git commit
   

9. Envie a atualização para o GitLab:

   git -c http.sslVerify=false push
   

10. Aguarde a revisão e a fusão do código.

11. Verifique se os objetos SKUDescription existem no cluster especificado para o modelo de faturamento correspondente.

    Exporte o valor KUBECONFIG de acordo com o tipo de organização.

    • Para uma organização da v1, execute:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
      

      Substitua ORG_ADMIN_CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster de administrador da organização, como /tmp/${ORG}-admin-kubeconfig.

    • Para uma organização da v2, execute:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
      

      Substitua MANAGEMENT_API_SERVER_KUBECONFIG pelo caminho para o kubeconfig do servidor da API Management, como /tmp/${ORG}-management-kubeconfig.

    Execute a CLI kubectl:

    Para faturamento do cliente:

    
    kubectl get SKUDescription -n billing-system
    

    Para faturamento de parceiros:

    
    kubectl get SKUDescription -n partner-billing-system
    

1.12.2.2 Planilha de preços específica da organização

Se a tabela de preços for específica de uma organização, coloque-a na pasta do cluster da organização.

1. Crie o diretório de faturamento skudescriptions no cluster da organização:

   • Para uma organização da v1:

     mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions
     

   • Para uma organização da v2:

     mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions
     

2. Salve os recursos YAML da tabela de preços SKUDescription nessa pasta. Depois disso, a pasta skudescriptions precisa ter arquivos YAML separados por área. No exemplo a seguir, você vê dois serviços, compute e storage, com dois arquivos YAML cada:

   .
   ├── compute
   │   ├── compute-sku1.yaml
   │   └── compute-sku2.yaml
   └── storage
       ├── storage-sku1.yaml
       └── storage-sku2.yaml
   

3. Verifique se há um arquivo kustomization.yaml no diretório que inclui todos os arquivos YAML da tabela de preços SKUDescription.

   • Para uma organização da v1:

     touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml
     cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/
     kustomize edit add resource */*.yaml
     

   • Para uma organização da v2:

     touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml
     cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/
     kustomize edit add resource */*.yaml
     

4. Verifique se o arquivo kustomization.yaml na raiz da organização tem a pasta bil/skudescriptions recém-adicionada. Verifique IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml para uma organização da v1 e IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml para uma organização da v2 :

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   resources:
   -   ... # existing resource items
   -   bil/skudescriptions
   

5. Adicione e faça commit do arquivo YAML e dos arquivos kustomize:

   cd IAC_REPO_PATH
   git add "iac"
   git commit
   

6. Envie a atualização para o GitLab:

   git -c http.sslVerify=false push
   

7. Aguarde a revisão e a fusão do código.

8. Verifique se os objetos SKUDescription existem no cluster especificado:

   • Para uma organização da v1, execute:

     export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
     
     kubectl get SKUDescription -n billing-system
     

     Substitua ORG_ADMIN_CLUSTER_KUBECONFIG pelo caminho para o kubeconfig do cluster de administrador da organização, como /tmp/${ORG}-admin-kubeconfig.

   • Para uma organização da v2, execute:

     export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
     
     kubectl get SKUDescription -n billing-system
     

     Substitua MANAGEMENT_API_SERVER_KUBECONFIG pelo caminho para o kubeconfig do servidor da API Management, como /tmp/${ORG}-management-kubeconfig. .

1.13 Criar usos recorrentes de faturamento

O Distributed Cloud oferece unidades de manutenção de estoque (SKUs) que geram cobranças recorrentes. No entanto, o Distributed Cloud não acompanha os custos de uso de determinados SKUs. Para gerenciar essas informações, use o recurso RecurringUsage. Para detalhes e instruções sobre como criar usos recorrentes, consulte Criar usos recorrentes.

1.14 Configurar o faturamento de uma organização

O subcomponente de faturamento não começa a calcular o custo de uma organização até que o horário de início do faturamento seja atingido. O horário de início do faturamento tem um valor padrão de 9999-01-01T00:00:00-07:00. Portanto, depois que uma organização é considerada pronta, o IO substitui o horário de início do faturamento para iniciar o fluxo de trabalho de faturamento.

1.14.1 Receber o horário de início do faturamento

O horário de início do faturamento precisa ser no começo do período de execução, que está disponível no seu contrato. Se você ainda não tiver o horário de início do faturamento de uma organização, entre em contato com o escritório de gerenciamento de programas (PMO, na sigla em inglês) para receber as informações.

1.14.2 Mapear uma conta de pagamento de faturamento para uma organização

Os ambientes isolados do Google Distributed Cloud (GDC) exigem uma conta de faturamento para rastrear custos de projetos e organizações. Se você não vincular uma conta de faturamento a uma organização ou projeto, vai perder os dados de custo associados ao recurso.

Para cobrar o uso do serviço do cliente, todas as contas de faturamento em uma organização usam uma única tabela de preços.

1.14.2.1 Antes de começar

Antes de continuar, peça ao administrador de segurança para conceder a você os seguintes papéis necessários. Essas funções são vinculadas ao namespace do projeto para faturamento no nível do projeto ou ao namespace da plataforma para faturamento no nível da organização:

• Administrador da conta de faturamento da organização: cria, gerencia e vincula o recurso BillingAccount. Peça ao administrador de segurança para conceder a você o papel organization-billing-account-admin.

• Usuário da conta de faturamento da organização: lê, lista e vincula o recurso BillingAccount. Peça ao administrador de segurança para conceder a você o papel organization-billing-account-user.

• Gerente de contas de faturamento da organização: lê, lista, cria e atualiza o recurso BillingAccountBinding. Peça ao administrador de segurança para conceder a você o papel organization-billing-manager.

1.14.2.2 Criar uma conta de faturamento

Uma conta de faturamento é identificada exclusivamente pelo name e pelo namespace. Para criar uma conta de faturamento, use um recurso personalizado para estabelecer o name e o namespace:

1. Crie um arquivo YAML e adicione o recurso personalizado BillingAccount e o conteúdo a seguir:

   apiVersion: billing.gdc.goog/v1
   kind: BillingAccount
   metadata:
     namespace: platform
     name: BIL_ACCOUNT_NAME
   spec:
     displayName: BIL_DISPLAY_NAME
     paymentSystemConfig:
       cloudBillingConfig:
         accountID: "012345-6789AB-CDEF01"
   

   Substitua as seguintes variáveis:

   • BIL_ACCOUNT_NAME: o nome da conta de faturamento. Por exemplo: test-billing-account.
   • BIL_DISPLAY_NAME: o nome de exibição da conta de faturamento. Por exemplo: "Test Billing Account".

2. Verifique o tipo de configuração de pagamento. As contas de faturamento do Distributed Cloud precisam ter uma das seguintes configurações de pagamento:

   • cloudBillingConfig: a configuração de pagamento padrão. Essa configuração armazena um ID da conta do Cloud Billing.

   • customConfig: uma configuração personalizada para que os parceiros armazenem a configuração de pagamento para faturar a organização. customConfig é compatível com um dicionário de strings de chave-valor, com uma chave obrigatória payment-config-type.

   Os exemplos a seguir mostram snippets de arquivos YAML BillingAccount para diferentes configurações de pagamento:

   cloudBillingConfig

   spec:
     paymentSystemConfig:
       cloudBillingConfig:
         accountID: CLOUD_BILLING_ACCOUNT_ID
   

   Substitua CLOUD_BILLING_ACCOUNT_ID pelo ID da sua conta de faturamentoGoogle Cloud .

   customConfig

   spec:
     paymentSystemConfig:
       customConfig:
         "payment-config-type": PAYMENT_CONFIG_TYPE
   

   Substitua PAYMENT_CONFIG_TYPE pelo tipo de configuração de pagamento escolhido para sua configuração de faturamento personalizada.

   Se você não tiver as informações da configuração customConfig da sua organização, insira os seguintes detalhes:

   spec:
     paymentSystemConfig:
       customConfig:
         "payment-config-type": "N/A"
   

   O arquivo YAML a seguir mostra um recurso BillingAccount completo com a configuração cloudBillingConfig:

   apiVersion: billing.gdc.goog/v1
   kind: BillingAccount
   metadata:
     namespace: platform
     name: test-billing-account
   spec:
     displayName: "Test Billing Account"
     paymentSystemConfig:
       cloudBillingConfig:
         accountID: "012345-6789AB-CDEF01"
   

3. Salve o arquivo YAML do recurso personalizado. Execute a CLI kubectl para aplicar o recurso no cluster da organização para a organização ou o projeto específico que você quer faturar:

   kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccount.yaml
   

1.14.2.3 Vincular uma organização a uma conta de faturamento

Para vincular uma organização a um BillingAccount, faça o seguinte:

1. Adicione o seguinte conteúdo ao arquivo YAML billingaccountbinding.yaml:

   • Na seção billingAccountRef, preencha o campo name com o conteúdo do campo name no BillingAccount que você quer vincular.
   • Na seção metadata, preencha o campo namespace com o conteúdo do campo idêntico no recurso BillingAccount. Neste exemplo, o namespace da organização é platform:

   apiVersion: billing.gdc.goog/v1
   kind: BillingAccountBinding
   metadata:
     name: billing
     namespace: platform
   spec:
     billingAccountRef:
       name: BIL_ACCOUNT_NAME
       namespace: platform
   

2. Aplique o arquivo billingaccountbinding.yaml:

   kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccountbinding.yaml
   

1.14.3 Antes de começar

Antes de continuar, peça ao administrador de segurança para conceder a você o papel de monitor de faturamento (bil-monitor) no cluster de administrador da organização para o namespace billing-system. Essa permissão permite ler recursos relacionados para validação.

1.14.4 Substituir o horário de início do faturamento

1. Crie dois arquivos YAML com os seguintes caminhos:

   • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-monetizer-override.yaml.

   • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-invoice-override.yaml.

     • Crie os subdiretórios necessários para cada arquivo, se eles estiverem faltando.

2. Adicione o recurso SubcomponentOverride e o seguinte conteúdo a cada arquivo:

   Para faturamento do cliente:

   • Arquivo bil-monetizer-override.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-monetizer
       namespace: ORG_NAME
     spec:
       subComponentRef: bil-monetizer
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
     

   • Arquivo bil-invoice-override.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-invoice
       namespace: ORG_NAME
     spec:
       subComponentRef: bil-invoice
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
     

   Para faturamento operado por parceiros:

   • Adicione a flag enablePartnerBilling: true ao final de cada arquivo YAML:

   • Arquivo bil-monetizer-override.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-monetizer
       namespace: ORG_NAME
     spec:
       subComponentRef: bil-monetizer
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
           enablePartnerBilling: true
     

   • Arquivo bil-invoice-override.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-invoice
       namespace: ORG_NAME
     spec:
       subComponentRef: bil-invoice
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
           enablePartnerBilling: true
     

   Substitua as seguintes variáveis:

   • ORG_NAME: o nome da organização. Por exemplo, org-1.

   • BILLING_START_TIME: o carimbo de data/hora para iniciar o fluxo de trabalho de faturamento.Ele precisa seguir o formato RFC 3339. Por exemplo, se o fluxo de trabalho de faturamento começar em 01/01/2024 com o fuso horário padrão do Pacífico dos EUA e do Canadá (UTC-8), adicione o valor do carimbo de data/hora como 2024-01-01T00:00:00-08:00.

   • BILLING_TIMEZONE: o fuso horário do fluxo de trabalho de faturamento. O fuso horário precisa seguir o formato RFC 3339. Por exemplo, se o fuso horário de faturamento for o horário padrão do Pacífico dos EUA e do Canadá (UTC-8), adicione o valor do fuso horário como PST8PDT.

   Importante: para arquiteturas da organização v2 (organizações v2), é necessário um SubcomponentOverride adicional para os seguintes namespaces distribuírem OperableParameters aos subcomponentes do servidor da API Management:

   • Arquivo bil-monetizer-override-mp.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-monetizer
       namespace: ORG_NAME-mp
     spec:
       subComponentRef: bil-monetizer
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
           enablePartnerBilling: true
     

   • Arquivo bil-invoice-override-mp.yaml:

     apiVersion: lcm.private.gdc.goog/v1
     kind: SubcomponentOverride
     metadata:
       name: bil-invoice
       namespace: ORG_NAME-mp
     spec:
       subComponentRef: bil-invoice
       backend:
         operableParameters:
           billingStartTime: BILLING_START_TIME
           billingTimezone: BILLING_TIMEZONE
           enablePartnerBilling: true
     

3. Salve e armazene os arquivos YAML na pasta infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

4. Crie uma solicitação de envio contendo os arquivos YAML e o arquivo de personalização necessário.

1.14.5 Validar o horário de início do faturamento

Verifique se você substituiu o horário de início do faturamento para o monetizador e a geração de faturas:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get deployment billing-monetizer -n billing-system \
    -o jsonpath='{.spec.template.spec.containers[0].args}{"\n"}'

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get cronjob billing-ig-job -n billing-system \
    -o jsonpath='{.spec.jobTemplate.spec.template.spec.containers[0].args}{"\n"}'

1.15 Configure a política de rede do proxy de armazenamento de objetos no cluster de administrador da organização

Observação: aplicado apenas à arquitetura da organização v2 (organização v2). Pule se a arquitetura for da organização v1 (organização v1).

1.15.1 Criar o arquivo YAML da política de rede

Crie o arquivo YAML da política de rede allow-obs-system-ingress-traffic, como networkpolicy.yaml:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
      policy.network.gke.io/enable-logging: "true"
      resourcemanager.gdc.goog/propagated-name: allow-obs-system-ingress-traffic
    name: allow-obs-system-ingress-traffic
    namespace: obj-system
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            resourcemanager.gdc.goog/project-name: obs-system
    podSelector: {}
    policyTypes:
    - Ingress

1.15.2 Aplicar a política de rede ao cluster de administrador da organização

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Criar um site de backup

Se você aproveitar o suporte à recuperação de desastres, conclua as etapas anteriores novamente para o site de backup. Se você não tiver a recuperação de desastres ativada, pule esta seção.

1. Siga as seções 1.4. - 1.9. para criar outra organização para o site de backup.

1.17. Resolver problemas na criação da organização

1.17.1. Confirme se todos os recursos implantados estão íntegros e presentes

O processo de criação de uma organização cria vários recursos em diferentes clusters do Kubernetes. Primeiro, verifique os recursos implantados e confira se eles estão em um bom estado. As seções a seguir descrevem os recursos criados para uma organização chamada operations.

1.17.2. Confirme todos os recursos implantados no cluster de administrador raiz.

Conclua as etapas a seguir para confirmar se todos os recursos no cluster de administrador raiz estão íntegros e presentes:

1. Siga IAM-R0004 para receber a configuração kubeconfig necessária para o cluster de administrador raiz. Defina as seguintes variáveis de ambiente e alias para estas instruções de verificação:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   export ORG="ORG_NAME"
   alias k=kubectl
   

2. Confirme se os recursos de firewall estão disponíveis:

   1. Estabeleça uma conexão SSH com o firewall e confirme se um novo vsys foi criado:

      show config running | match 'vsys[0-9] '
      

      O resultado será assim:

      vsys1 {
      vsys2 {
      

   2. Verifique o recurso FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system
      

      O resultado será assim:

      NAME                                   AGE
      kb-ab-fw01-internal-vsys2-operations   4d19h
      kb-ab-fw01-vsys-root-admin             13d
      kb-ac-fw01-internal-vsys2-operations   4d19h
      kb-ac-fw01-vsys-root-admin             13d
      

3. Confirme se os recursos de armazenamento estão disponíveis:

   1. Verifique o recurso StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system
      

      O resultado será assim:

      NAME               STORAGEORG   MGMTIP      READY   AGE
      operations-admin   operations   10.0.2.10   True    5d22h
      operations-user    operations   10.0.2.18   True    5d22h
      root-admin         root         10.0.2.2    True    13d
      

4. Confirme se os recursos do HSM estão disponíveis:

   1. Verifique os HSMs:

      k get hsms -n gpc-system
      

      O resultado será assim:

      NAMESPACE    NAME          AGE    IP               READY   REASON
      gpc-system   zk-aa-hsm01   2h     198.51.100.192   True    ReconcileHSMSuccess
      gpc-system   zk-aa-hsm02   2h     198.51.100.193   True    ReconcileHSMSuccess
      gpc-system   zk-ab-hsm01   2h     198.51.100.194   True    ReconcileHSMSuccess
      
      

   2. Verifique o cluster do HSM:

      k get hsmcluster -n gpc-system
      

      O resultado será assim:

      NAMESPACE    NAME          AGE   READY   REASON
      gpc-system   hsmcluster    38h   True    ReconcileHSMClusterSuccess
      

   3. Verifique o locatário do HSM:

      k get hsmtenant -A
      

      O resultado será assim:

      NAMESPACE    NAME         AGE     READY   REASON
      gpc-system   root         13d     True    ReconcileHSMTenantSuccess
      operations   operations   5d22h   True    ReconcileHSMTenantSuccess
      

5. Confirme se os recursos de máquina e nó estão disponíveis:

   1. Verifique os recursos AddressPoolClaim:

      k get addresspoolclaims -A
      

      O resultado será assim:

      NAMESPACE    NAME                                              AGE
      operations   admin-control-plane-node-pool                     5d23h
      operations   operations-admin-dns-default-ipv4-ipc             5d23h
      operations   operations-admin-load-balancer-default-ipv4-ipc   5d23h
      

   2. Verifique os recursos NodePoolClaim:

      k get nodepoolclaims -A
      

      O resultado será assim:

      NAMESPACE    NAME                            AGE
      operations   admin-control-plane-node-pool   5d23h
      root         root-admin-control-plane        13d
      

   3. Verifique os recursos NodePool:

      k get nodepool -A
      

      O resultado será assim:

      NAMESPACE    NAME                            READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
      operations   admin-control-plane-node-pool   3       0             0         0                  0
      root         root-admin-control-plane        3       0             0         0                  0
      

   4. Verifique os clusters bare metal:

      k get baremetalclusters -A
      

      O resultado será assim:

      NAMESPACE    NAME               CLUSTER            READY
      operations   operations-admin   operations-admin   true
      root         root-admin         root-admin         true
      

   5. Verifique as máquinas bare metal:

      k get baremetalmachines -A
      

      O resultado será assim:

      NAMESPACE    NAME           CLUSTER            READY   INSTANCEID                 MACHINE
      operations   10.251.82.28   operations-admin   true    baremetal://10.251.82.28   10.251.82.28
      operations   10.251.82.29   operations-admin   true    baremetal://10.251.82.29   10.251.82.29
      operations   10.251.82.30   operations-admin   true    baremetal://10.251.82.30   10.251.82.30
      root         10.251.80.2    root-admin         true    baremetal://10.251.80.2    10.251.80.2
      root         10.251.80.3    root-admin         true    baremetal://10.251.80.3    10.251.80.3
      root         10.251.80.4    root-admin         true    baremetal://10.251.80.4    10.251.80.4
      

   6. Verifique os servidores. Eles estão no estado provisioned:

      k get servers -n gpc-system | grep provisioned
      

      O resultado será assim:

      kb-aa-bm01   13d          o1-highmem1-40-gdc-metal    10.251.252.61   10.251.80.2              10.251.252.62   provisioned   true
      kb-aa-bm02   13d          o1-standard1-64-gdc-metal   10.251.252.63   10.251.82.28             10.251.252.64   provisioned   true
      kb-aa-bm03   13d          o1-standard1-64-gdc-metal   10.251.252.65   10.251.82.29             10.251.252.66   provisioned   true
      kb-aa-bm04   13d          o1-standard1-64-gdc-metal   10.251.252.67   10.251.82.30             10.251.252.68   provisioned   true
      kb-aa-bm08   13d          o1-highmem1-96-gdc-metal    10.251.252.75   10.0.35.2                10.251.252.76   provisioned   true
      kb-aa-bm10   13d          o1-highmem1-96-gdc-metal    10.251.252.79   10.0.35.4                10.251.252.80   provisioned   true
      kb-aa-bm14   13d          o1-highgpu1-48-gdc-metal    10.251.252.87   10.0.35.9                10.251.252.88   provisioned   true
      kb-aa-bm15   13d          o1-highgpu1-48-gdc-metal    10.251.252.89   10.0.35.10               10.251.252.90   provisioned   true
      kb-aa-bm16   13d          o1-highgpu1-48-gdc-metal    10.251.252.91   10.0.35.11               10.251.252.92   provisioned   true
      kb-ab-bm01   13d          o1-highmem1-40-gdc-metal    10.251.253.61   10.251.80.3              10.251.253.62   provisioned   true
      kb-ac-bm01   13d          o1-highmem1-40-gdc-metal    10.251.254.61   10.251.80.4              10.251.254.62   provisioned   true
      

   7. Verifique o cluster do Kubernetes:

      k get cluster -A
      

      O resultado será assim:

      NAMESPACE    NAME               AGE
      operations   operations-admin   5d23h
      root         root-admin         13d
      

   8. Verifique os secrets do kubeconfig:

      k get secrets -A | grep kubeconfig
      

      O resultado será assim:

      operations    operations-admin-kubeconfig   Opaque        1      5d22h
      root          root-admin-kubeconfig         Opaque        1      13d
      

1.17.3. Confirme todos os recursos implantados nos clusters da organização v1.

Siga estas etapas para confirmar se todos os recursos no cluster de administrador da organização e no cluster do sistema em uma organização v1 estão íntegros e presentes. Se você tiver uma organização da v2, pule para a próxima seção.

1.17.3.1. Confirmar todos os recursos implantados em um cluster de administrador da organização

1. Siga IAM-R0004 para receber a configuração kubeconfig necessária para o cluster de administrador raiz. Defina as seguintes variáveis de ambiente e o alias para estas instruções de verificação:

   export ORG="ORG_NAME"
   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
       | base64 -d > /tmp/${ORG}-admin-kubeconfig
   export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
   alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"
   

2. Confirme se os recursos de máquina e nó estão disponíveis:

   1. Verifique os clusters bare metal:

      ka get baremetalclusters -A
      

      O resultado será assim:

      NAMESPACE                    NAME                 CLUSTER              READY
      operations-system-cluster    operations-system    operations-system    true
      

   2. Verifique as máquinas bare metal:

      ka get baremetalmachines -A
      

      O resultado será assim:

      NAMESPACE                    NAME            CLUSTER              READY   INSTANCEID                  MACHINE
      operations-system-cluster    10.0.35.10      operations-system    true    baremetal://10.0.35.10      10.0.35.10
      operations-system-cluster    10.0.35.11      operations-system    true    baremetal://10.0.35.11      10.0.35.11
      operations-system-cluster    10.0.35.2       operations-system    true    baremetal://10.0.35.2       10.0.35.2
      operations-system-cluster    10.0.35.3       operations-system    true    baremetal://10.0.35.3       10.0.35.3
      operations-system-cluster    10.0.35.4       operations-system    true    baremetal://10.0.35.4       10.0.35.4
      operations-system-cluster    10.0.35.9       operations-system    true    baremetal://10.0.35.9       10.0.35.9
      operations-system-cluster    10.251.82.205   operations-system    true    baremetal://10.251.82.205   10.251.82.205
      operations-system-cluster    10.251.82.206   operations-system    true    baremetal://10.251.82.206   10.251.82.206
      operations-system-cluster    10.251.82.207   operations-system    true    baremetal://10.251.82.207   10.251.82.207
      operations-system-cluster    10.251.82.232   operations-system    true    baremetal://10.251.82.232   10.251.82.232
      

   3. Verifique as máquinas:

      ka get machines -A
      

      O resultado será assim:

      NAMESPACE                    NAME            NODEPOOL
      operations-system-cluster    10.0.35.10      worker-node-pool-o1-highgpu1-48-gdc-metal
      operations-system-cluster    10.0.35.11      worker-node-pool-o1-highgpu1-48-gdc-metal
      operations-system-cluster    10.0.35.2       worker-node-pool-o1-highmem1-96-gdc-metal
      operations-system-cluster    10.0.35.3       worker-node-pool-o1-highmem1-96-gdc-metal
      operations-system-cluster    10.0.35.4       worker-node-pool-o1-highmem1-96-gdc-metal
      operations-system-cluster    10.0.35.9       worker-node-pool-o1-highgpu1-48-gdc-metal
      operations-system-cluster    10.251.82.205   control-plane-node-pool
      operations-system-cluster    10.251.82.206   control-plane-node-pool
      operations-system-cluster    10.251.82.207   control-plane-node-pool
      operations-system-cluster    10.251.82.232   control-plane-node-pool
      

   4. Verifique os recursos VirtualmachinesInstance:

      ka get virtualmachineinstances -A
      

      O resultado será assim:

      NAMESPACE                    NAME          AGE     PHASE     IP              NODENAME     READY
      operations-system-cluster    vm-19753801   2d16h   Running   10.251.82.207   kb-aa-bm02   True
      operations-system-cluster    vm-3661f750   4d19h   Running   10.251.82.232   kb-aa-bm03   True
      operations-system-cluster    vm-3c77c480   5d20h   Running   10.251.82.206   kb-aa-bm04   True
      

   5. Verifique os recursos NodePool:

      ka get nodepools -A
      

      O resultado será assim:

      NAMESPACE                    NAME                                        READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
      operations-system-cluster    control-plane-node-pool                     3       0             0         0                  0
      operations-system-cluster    worker-node-pool-o1-highgpu1-48-gdc-metal   3       0             0         0                  0
      operations-system-cluster    worker-node-pool-o1-highmem1-96-gdc-metal   2       0             0         0                  0
      

   6. Verifique os clusters do Kubernetes:

      ka get clusters -A
      

      O resultado será assim:

      NAMESPACE                    NAME                 AGE
      operations-system-cluster    operations-system    5d20h
      

   7. Verifique os nós:

      ka get nodes -A
      

      O resultado será assim:

      NAME         STATUS   ROLES                  AGE     VERSION
      kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      

   8. Verifique os secrets do kubeconfig:

      ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig
      

      O resultado será assim:

      NAME                           TYPE     DATA   AGE
      operations-system-kubeconfig   Opaque   1      5d20h
      

1.17.3.2. Confirme todos os recursos implantados no cluster de usuário do sistema.

Conclua as etapas a seguir para confirmar se todos os recursos no cluster do sistema estão íntegros e presentes:

1. Siga IAM-R0004 para receber a configuração kubeconfig necessária para o cluster de administrador raiz. Defina as seguintes variáveis de ambiente e o alias para estas instruções de verificação:

   export ORG="ORG_NAME"
   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
       | base64 -d > /tmp/${ORG}-admin-kubeconfig
   export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
   alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"
   ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig -o jsonpath='{.data.value}' \
       | base64 -d > /tmp/${ORG}-system-kubeconfig
   export SYSTEM_KUBECONFIG=/tmp/${ORG}-system-kubeconfig
   alias ku="kubectl --kubeconfig ${SYSTEM_KUBECONFIG}"
   

2. Confirme se os recursos de máquina e nó estão disponíveis:

   1. Verifique o recurso VirtualmachineInstance:

      ku get vmi -A
      

      A saída será semelhante a esta (se um cluster de usuário tiver sido criado):

      NAMESPACE       NAME            AGE     PHASE     IP            NODENAME     READY
      gdc-vm-infra   vm-61aa554d     3d21h   Running   10.0.35.6     kb-aa-bm10   True
      gdc-vm-infra   vm-b627da1f     3d21h   Running   10.0.35.5     kb-aa-bm08   True
      

   2. Verifique os nós:

      ku get nodes
      

      O resultado será assim:

      NAME          STATUS                     ROLES                  AGE     VERSION
      kb-aa-bm10    Ready                      worker                 5d20h   v1.23.5-gke.1505
      kb-aa-bm14    Ready                      worker                 38h     v1.23.5-gke.1505
      kb-aa-bm15    Ready                      worker                 38h     v1.23.5-gke.1505
      kb-aa-bm16    Ready                      worker                 38h     v1.23.5-gke.1505
      vm-19753801   Ready                      control-plane,master   5d21h   v1.23.5-gke.1505
      vm-3661f750   Ready                      control-plane,master   4d20h   v1.23.5-gke.1505
      vm-3c77c480   Ready                      control-plane,master   5d20h   v1.23.5-gke.1505
      

   3. Verifique as alocações de GPU:

      ku get gpuallocations -A
      

      O resultado será assim:

      NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
      vm-system   kb-aa-bm14   true        A100 PCIe 40GB
      vm-system   kb-aa-bm15   true        A100 PCIe 40GB
      vm-system   kb-aa-bm16
      

1.17.4. Confirme todos os recursos implantados nos clusters da organização v2

Siga estas etapas para confirmar se todos os recursos no cluster de infraestrutura da organização em uma organização v2 estão íntegros e presentes. Se você tiver uma organização da v1, pule esta seção.

1. Siga IAM-R0004 para receber a configuração kubeconfig necessária para o cluster de administrador raiz. Defina as seguintes variáveis de ambiente e o alias para estas instruções de verificação:

   export ORG="ORG_NAME"
   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
       | base64 -d > /tmp/${ORG}-admin-kubeconfig
   export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
   alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"
   

2. Confirme se os nós e servidores de API estão íntegros:

   1. Verifique os nós:

      ka get nodes -A
      

      O resultado será assim:

      NAME         STATUS   ROLES                  AGE     VERSION
      kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
      kb-aa-bm05   Ready    worker                 5d23h   v1.23.5-gke.1505
      kb-aa-bm06   Ready    worker                 5d23h   v1.23.5-gke.1505
      kb-aa-bm07   Ready    worker                 5d23h   v1.23.5-gke.1505
      

   2. Verifique os secrets do kubeconfig:

      ka get secret -n management-kube-system kube-admin-remote-kubeconfig
      

      O resultado será assim:

      NAME                           TYPE     DATA   AGE
      kube-admin-remote-kubeconfig   Opaque   1      5d20h
      

3. Verifique as alocações de GPU para confirmar se os recursos estão prontos, se aplicável:

   ka get gpuallocations -A
   

   O resultado será assim:

   NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
   vm-system   kb-aa-bm14   true        A100 PCIe 40GB
   vm-system   kb-aa-bm15   true        A100 PCIe 40GB
   vm-system   kb-aa-bm16
   

1.17.5. Confirmar se todos os recursos da organização foram reconciliados

Siga estas etapas para confirmar se todos os recursos relacionados à organização no cluster de administrador raiz global e zonal estão íntegros e presentes, supondo que a meta seja criar uma organização operations com duas zonas: zone-1 e zone-2.

Observação: para cada recurso, é possível verificar o status usando kubectl describe para encontrar informações mais detalhadas sobre falhas. status é um status agregado de todas as zonas, em que o campo rolloutStatus contém detalhes da propagação zonal e o campo replicaStatus contém detalhes do provisionamento de recurso zonal zonais.

1. Siga Acessar a API de administrador raiz global para acessar o servidor de API global e use o seguinte alias para o kubectl da API de administrador raiz global.

   alias kga='kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG
   export ORG="ORG_NAME"
   

2. Confirme se os recursos globais da organização estão disponíveis:

   1. Verifique os recursos globais Organization:

      kga get organization -A
      

      O resultado será assim:

      NAMESPACE    NAME         READY
      gpc-system   operations
      gpc-system   root
      

   2. Verifique os recursos globais OrganizationReplica:

      kga get organizationreplica -A
      

      O resultado será assim:

      NAMESPACE    NAME               AGE
      gpc-system   operations-zone1   3d16h
      gpc-system   operations-zone2   3d16h
      gpc-system   root-zone1         3d17h
      gpc-system   root-zone2         3d16h
      

   3. Verifique os recursos globais OrganizationZonalConfig:

      kga get organizationzonalconfig -A
      

      O resultado será assim:

      NAMESPACE    NAME                      AGE
      gpc-system   operations-zone1-config   3d16h
      gpc-system   operations-zone2-config   3d16h
      

   4. Verifique os recursos globais OrganizationZonalConfigReplica:

      kga get organizationzonalconfigreplica -A
      

      O resultado será assim:

      NAMESPACE    NAME                             AGE
      gpc-system   operations-zone1-config-zone1    3d16h
      gpc-system   operations-zone1-config-zone2    3d16h
      gpc-system   operations-zone2-config-zone1    3d16h
      gpc-system   operations-zone2-config-zone2    3d16h
      

3. Defina o alias de configuração do kubeconfig do cluster de administrador raiz zonal:

   alias ka='kubectl --kubeconfig /root/GDC_VERSION/root-admin/root-admin-kubeconfig'
   

4. Confirme se os recursos da organização por zona estão disponíveis:

   1. Verifique os recursos Organization:

      ka get organization -A
      

      O resultado será assim:

      NAMESPACE    NAME         READY
      gpc-system   operations   True
      gpc-system   root         True
      

   2. Verifique os recursos OrganizationReplica:

      ka get organizationreplica -A
      

      O resultado será assim:

      NAMESPACE    NAME         AGE
      gpc-system   operations   3d16h
      gpc-system   root         3d17h
      

   3. Verifique os recursos OrganizationZonalConfigReplica:

      ka get organizationzonalconfigreplica -A
      

      O resultado será assim:

      NAMESPACE    NAME                       AGE
      gpc-system   operations-zone1-config    3d16h
      gpc-system   operations-zone2-config    3d16h
      

5. Siga Permitir que qualquer endereço acesse uma organização para permitir o tráfego de DCI nos clusters de administrador da organização do site de origem para o site de backup.