1. Crie uma organização de clientes

Tempo estimado até à conclusão: 3 horas

Perfil de competências: engenheiro de implementação

Como operador, pode criar uma organização para fornecer acesso dos clientes à infraestrutura da plataforma. Para receber as autorizações necessárias para criar uma organização, peça ao administrador de segurança que lhe atribua a função de administrador da organização.

O recurso Organization é o nó de raiz da hierarquia de recursos isolados do Google Distributed Cloud (GDC) e todos os recursos que pertencem a uma organização são agrupados no nó da organização. Isto oferece visibilidade e controlo centralizados sobre todos os recursos pertencentes a uma organização.

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

1.1. Antes de começar

Certifique-se de que instalou o seguinte:

• Um navegador no seu sistema.

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

• A CLI kubectl.

• A CLI gcloud.

1.2. Crie um cliente OIDC no OC IT ADFS

1. Consulte as instruções de configuração do ADFS OIDC para criar um cliente OpenID Connect (OIDC) no ADFS para o operador aceder à organização que vai criar. Registe o ID de cliente e o segredo do cliente OIDC. Não pode reutilizar o cliente em ligações a 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 retorno do serviço de identidade do GKE à lista de autorizações no cliente OIDC do ADFS que criou para a organização que vai criar:

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

   Por exemplo:

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

   O URL de retorno do serviço de identidade do GKE neste caso é 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 autorizações no cliente OIDC do ADFS que criou para cada zona no seu universo do GDC:

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

   Por exemplo:

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

   O URL de retorno do serviço de identidade do GKE neste caso é https://ais-core.operations.zone-1.google.gdch.test/finish-login.

4. Defina as seguintes variáveis para usar nas secções seguintes:

   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 ficheiro adfs.pem codificado em base64.
   ADFS_CLIENT_ID	O identificador do cliente ADFS.
   ADFS_CLIENT_SECRET	O segredo partilhado do cliente do ADFS.
   ADFS_ISSUER_URI	O URI do emissor do ADFS. Para obter 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" Normalmente, o valor é https://adfs.domain.com/adfs.

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

Nota: esta secção só se aplica se estiver a criar uma organização v2. Se estiver a criar uma organização da versão 1, avance para a secção seguinte.

Antes de criar uma organização, tem de criar as sub-redes raiz globais e dividi-las para cada zona com a sub-rede da API pública de gestão de endereços IP (IPAM). Se estiver a criar uma nova organização v2 numa zona que tinha anteriormente uma organização v1, certifique-se de que consulta a página de pré-requisitos adicionais antes de criar as suas sub-redes globais.

As sub-redes raiz globais alojam o conjunto de intervalos de endereços IP raiz (CIDR) que é dividido em cada zona para iniciar todos os clusters na organização do inquilino, 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 às sub-redes raiz como o conjunto de endereços IP de anycast. Pode atribuir automaticamente CIDRs dedicados a cada zona através de um controlador ou fornecer CIDRs manualmente a cada zona.

Para iniciar uma organização, precisa do intervalo de endereços IP internos introduzido no questionário de introdução de dados da organização (OIQ). Tem de usar esses intervalos de endereços IP para criar a sub-rede raiz global no servidor da API global.

Tem de 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 da API global é fornecido na secção seguinte.

1.3.1. Defina o intervalo CIDR para a OIQ

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

O zone-infra-cidr existe em cada zona e pode ser obtido no questionário de admissão de clientes (CIQ) se o cliente o tiver definido.

Para obter o zone-infra-cidr, execute o seguinte comando:

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

Segue-se um exemplo do resultado 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, pelo que nenhum campo no OIQ se pode sobrepor a 192.0.2.0/24.

A tabela seguinte mostra os campos de OIQ e os respetivos valores mínimos predefinidos:

Campo 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	Cargas de trabalho do sistema, incluindo a consola da organização, as APIs de gestão e os serviços originais.	\( 15 - \lceil \log_2(ZoneNumber) \rceil \)	16	infra-vpc-root-cidr	Raiz global
defaultVPCCIDR	Cargas de trabalho e pontos finais do utilizador na VPC predefinida em várias zonas.	\( 16 - \lceil \log_2(ZoneNumber) \rceil \)	16	default-vpc-root-cidr	Organização global
orgAdminExternalCIDR	Cargas de trabalho e pontos finais 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 pontos finais acessíveis externamente pelos utilizadores, como equilibradores de carga externos e NATs de saída.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	data-external-root-cidr	Raiz global

Se não tiver IPs suficientes como o mínimo sugerido predefinido, tem de seguir o processo de divisão manual para criar as sub-redes para cada zona.

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

• orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR e defaultVPCCIDR não podem sobrepor-se entre si, com outros intervalos atribuídos na organização e com quaisquer intervalos IPv4 em redes com peering. Os CIDRs destes provêm do espaço de endereço privado RFC 1918.

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

• Se as organizações partilharem os mesmos recursos de interconexão, os valores orgDataExternalCIDR e orgAdminExternalCIDR têm de ser únicos.AttachmentGroup Caso contrário, a sobreposição com outras organizações é permitida.

1.3.2. Crie sub-redes globais no servidor da API de administração raiz global

Tem de criar as seguintes sub-redes no servidor da API de administrador principal global antes de criar uma organização:

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

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

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

1. Tem de ter um espaço de nomes com um nome que corresponda ao nome da organização que vai atribuir à sua organização. Confirme se este espaço de nomes existe:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace
   

   Se este espaço de nomes não existir, crie-o:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME
   

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

   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 ficheiro YAML da sub-rede, como ORG_NAME-admin-external-root-cidr.yaml:admin-external-root-cidr

   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 ficheiro YAML da sub-rede, como ORG_NAME-data-external-root-cidr.yaml:data-external-root-cidr

   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 ficheiros 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. Certifique-se de que o ficheiro 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. Prepare e confirme os ficheiros YAML da sub-rede:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

8. Crie um pedido de união:

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

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

1.3.3. Divida as sub-redes raiz para zonas

As sub-redes de raiz globais alojam o intervalo de endereços IP de raiz (CIDR) para todas as zonas. Para consumir o intervalo de endereços IP na zona, primeiro, as sub-redes raiz globais têm de ser divididas em sub-redes mais pequenas para as zonas consumirem. Cada zona tem de 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 mais pequenas para zonas existentes. Os administradores podem delegar nos controladores IPAM para dividir automaticamente a sub-rede da zona se não se importarem com o bloco CIDR exato que uma determinada zona usa. O controlador monitoriza a criação da sub-rede raiz global e cria uma sub-rede para cada zona com um comprimento do prefixo predefinido fixo.

Sub-rede raiz da zona	Comprimento de prefixo fixo predefinido
defaultZoneInfraVPCSubnetSize	16
defaultZoneAdminVRFSubnetSize	23
defaultZoneDataVRFSubnetSize	23
defaultZoneDefaultVPCSubnetSize	16
defaultAnycastSubnetSize	26

As sub-redes raiz globais têm de ter nomes fixos se quiser que os controladores 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 definir a anotação ipam.gdc.goog/pause-auto-division: true para os seus recursos Subnet, tem de definir manualmente o bloco CIDR exato que uma determinada zona usa. Se criar as sub-redes raiz globais com nomes diferentes, a anotação ipam.gdc.goog/pause-auto-division não tem efeito e as sub-redes globais não são divididas automaticamente.

1.3.3.1. Divida automaticamente as sub-redes raiz para zonas

O controlador global divide automaticamente a sub-rede raiz global em sub-redes mais pequenas para as zonas existentes. Por exemplo, considere o seguinte fluxo de trabalho para compreender como o controlador divide a sub-rede raiz global em sub-redes mais pequenas para zonas existentes:

Se existirem duas zonas denominadas zone1 e zone2, um exemplo de sub-rede raiz global infra-vpc-root-cidr que usa o infraVPCCIDR, como 10.0.0.0/16, do OIQ no espaço de nomes org-1 tem o seguinte aspeto:

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 implementado na plataforma GDC, o controlador cria automaticamente duas sub-redes secundárias denominadas 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

Nota: este fluxo de trabalho aplica-se apenas a determinadas sub-redes raiz globais. Também é criada uma sub-rede de anycast a partir da mesma. A sub-rede anycast é a única sub-rede no servidor da API global.

1.3.3.2. Divida manualmente as sub-redes raiz para zonas

Esta secção pressupõe que define a anotação ipam.gdc.goog/pause-auto-division: truewhen quando cria as sub-redes raiz globais no servidor da API de administração raiz global. Esta anotação pausa o controlador para reconciliar essas sub-redes de raiz globais, o que lhe permite criar manualmente a sub-rede de raiz de uma zona e a sub-rede de anycast.

Para dividir manualmente a sub-rede raiz global em sub-redes mais pequenas para zonas, conclua 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 quer aplicar à sua zona. Faça isto para cada zona no seu universo.

3. Atribua o CIDR dedicado à sub-rede da sua zona num ficheiro 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 este passo para cada zona no seu universo do GDC.

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

5. Atribua o CIDR dedicado à sub-rede de anycast num ficheiro 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 ficheiros YAML da sub-rede zonal para o repositório de IAC da organização raiz. Por exemplo, se tiver dois ficheiros YAML de sub-redes zonais:

   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. Certifique-se de que o ficheiro 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. Prepare e confirme os ficheiros YAML da sub-rede:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

9. Crie o pedido de união:

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

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

1.3.3.2.1. Exemplo de divisão manual de sub-redes raiz para zonas para infra-vpc

Se existirem duas zonas denominadas zone1 e zone2, um exemplo de sub-rede raiz global infra-vpc-root-cidr que usa o infraVPCCIDR, como 192.0.2.0/24, do OIQ no espaço de nomes org-1 tem o seguinte aspeto:

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 denominada infra-vpc-zone1-root-cidr e infra-vpc-zone2-root-cidr, e a sub-rede de anycast infra-vpc-anycast-cidr com o CIDR dedicado que 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

Certifique-se de que adiciona todos os ficheiros YAML de sub-redes ao repositório de IAC.

1.3.3.2.2. Exemplo de divisão manual de sub-redes raiz para zonas para o segmento de rede de dados

Se existirem duas zonas denominadas zone1 e zone2, um exemplo de sub-rede raiz global data-external-root-cidr que usa o orgDataExternalCIDR, como 10.0.0.0/24, do OIQ no espaço de nomes org-1 tem o seguinte aspeto:

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 denominada data-external-zone1-root-cidr e data-external-zone2-root-cidr, e a sub-rede de anycast data-global-anycast-cidr com o CIDR dedicado que 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

Certifique-se de que adiciona todos os ficheiros YAML de sub-redes ao repositório de IAC.

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

Se existirem duas zonas denominadas zone1 e zone2, um exemplo de sub-rede raiz global admin-external-root-cidr que usa o orgAdminExternalCIDR, como 192.168.1.0/24, do OIQ no espaço de nomes org-1 tem o seguinte aspeto:

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 denominada admin-external-zone1-root-cidr e admin-external-zone2-root-cidr, e a sub-rede de anycast admin-global-anycast-cidr com o CIDR dedicado que 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

Certifique-se de que adiciona todos os ficheiros YAML de sub-redes ao repositório de IAC.

1.4. Crie 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}'
   

   O exemplo de resultado é semelhante ao seguinte:

   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
   

   Quando especificar --server-quota e --admin-server mais tarde, certifique-se de que tem servidores available suficientes para satisfazer o pedido.

2. Navegue para o repositório iac e adicione a estrutura de diretórios para a 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
   

   Por 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 tem de cumprir os seguintes critérios: Ter entre 3 e 19 letras ASCII minúsculas, dígitos ou hífenes. Começar com uma letra. Não podem ter hífenes no final. Não pode terminar com a string -system.
   LOG_RETENTION_POLICY	A configuração dos tempos de retenção para registos de auditoria, registos operacionais e métricas em dias.
   KMS_ROOT_KEY_TYPE	Esta configuração contém o tipo de chave raiz escolhido para o KMS de uma organização. Cada serviço KMS tem uma chave principal para encriptar as chaves geradas pelo KMS. Por predefinição, o KMS gera uma chave raiz CTM, uma chave raiz armazenada no Thales CipherTrust Manager com uma cópia de segurança de um HSM físico. Também pode escolher uma chave de raiz de software armazenada como um segredo do Kubernetes. Transmita ctm-root ou local-root para kmsRootKeyType.

   Um exemplo do ficheiro YAML de recursos personalizados 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 posteriores, a encriptação IPsec de nó a nó está desativada por predefinição. Se esta encriptação IPsec for necessária, pode ativar a encriptação IPsec de nó para nó editando o ficheiro YAML de recursos personalizados Organization e adicionando uma anotação:

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

   Um valor de "false" para esta anotação ativa a encriptação.

5. Crie um OrganizationZonalConfig recurso personalizado para cada zona na implementaçã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
   

   Por 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é-visualização: o GDC oferece a capacidade de criar organizações assimétricas em várias zonas como uma funcionalidade de pré-visualização a partir da versão 1.14.4. Por exemplo, cada recurso OrganizationZonalConfigpersonalizado pode ser diferente para cada zona. Da mesma forma, pode optar por não criar um OrganizationZonalConfig recurso personalizado para uma zona existente.

   Substitua as seguintes variáveis:

   Variável	Definição
   ORG_NAME	O nome da organização. O nome de uma organização tem de cumprir os seguintes critérios: Ter entre 3 e 30 letras ASCII minúsculas, dígitos ou hífens. Começar com uma letra. Não podem ter hífenes no final. Não pode terminar com a string -system.
   ZONES	Os nomes das zonas na implementação.
   GDC_VERSION	A versão do sistema GDC para criar a organização.
   SERVER_QUOTA	Os servidores a atribuir para o cluster de administrador da organização e o cluster do sistema quando são gerados automaticamente. Se pretender executar recursos da unidade de processamento de gráficos (GPU) que sejam cargas de trabalho baseadas em VMs, como APIs de inteligência artificial e aprendizagem automática (IA/AA) pré-treinadas, tem de aprovisionar máquinas com GPU quando criar uma organização. Para mais informações, consulte a secção Ative o suporte de 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 atribuir para esse tipo de servidor. Os tipos mistos não são suportados para servidores. O valor predefinido é o1-standard1-64-gdc-metal: 3.
   STORAGE_SIZE	O tamanho dos diferentes tipos de armazenamento a atribuir à organização. O tamanho mínimo de armazenamento de blocos para uma organização é de 250 Gi, que é definido com a flag BlockStandard.

   Um exemplo do ficheiro YAML de recursos personalizados 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. Reveja os ficheiros YAML gerados. Os ficheiros estão localizados no diretório HOME.

   1. Confirme o tipo de organização. Existem dois tipos de organizações que pode aprovisionar:

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

      Por predefinição, as novas organizações são aprovisionadas com base no seu tipo de implementação, conforme definido pelas definições do Feature Gate:

      • As implementações do PRODUCTION geram organizações da versão 2 por predefinição.
      • As implementações do ACCREDITED geram organizações da versão 1 por predefinição.

      No caso raro de ter de substituir o tipo de organização predefinido para o seu tipo de implementação, atualize o campo spec.compatibilityOptions.architectureOverridePolicy no recurso personalizado Organization gerado para ForceV1 ou ForceV2, consoante o tipo de organização que quer usar. Por exemplo, o fragmento seguinte força a criação de uma organização v2 numa implementação do ACCREDITED:

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

   2. Confirme as restantes definições para garantir que os componentes, como o armazenamento e a capacidade de computação, são 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 o seguinte:

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

8. Adicione o ficheiro 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 ficheiro kustomization.yaml global root:

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

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

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

10. Prepare e confirme o ficheiro YAML da organização e os ficheiros do Kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
    git commit
    

11. Crie um pedido de união:

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

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

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

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

       kubectl get organization -A
       

       O resultado é semelhante ao seguinte:

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

       Nota: se não conseguir aceder aos servidores da nova organização, pode ter de colaborar com a sua equipa de administração de rede para ativar a conetividade aos endereços IP e às portas adequados para a organização recém-criada.

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

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

       Certifique-se de que as condições status na saída YAML são True.

    3. Verifique o estado 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 iniciar sessão em cada zona antes de verificar o estado da organização. Certifique-se de que as condições status na saída YAML para cada zona são True.

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

Nota: esta secção só se aplica se estiver a criar uma organização v2. Se estiver a criar uma organização da versão 1, avance para a secção seguinte.

Tem de criar o default-vpc-root-cidr no servidor de API global da organização no espaço de nomes platform depois de o servidor de API global estar em execução. Esta sub-rede raiz atribui o endereço IP para clusters na organização de inquilinos, como clusters de utilizadores, bem como endereços IP para cargas de trabalho de VMs.

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

   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 para o repositório iac e adicione a estrutura de diretórios para a organização global:

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

3. Copie o ficheiro YAML da sub-rede default-vpc-root-cidr para o repositório de 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 ficheiro 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. Prepare e confirme o ficheiro YAML da organização e os ficheiros do Kustomize:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

6. Crie o pedido de união:

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

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

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

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

Tem de configurar manualmente a autenticação entre os NTPRelays do administrador principal e do administrador da organização.

Siga o NTP-P0001.3 (Root Admin -> Org Admin NTPRelay Encryption) para configurar a encriptação para esta organização.

1.8. Associe o Fornecedor de identidade do IO à organização com a IAC

1. Consulte o guia do ADFS para criar um cliente OIDC no ADFS para a nova organização e tome nota do ID de cliente e do segredo do cliente do cliente OIDC.

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

   export ORG_NAME=ORG_NAME
   

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

3. Exporte o ficheiro kubeconfig do cluster de administrador raiz e execute os seguintes comandos kubectl para obter 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 ficheiro 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 assinar automaticamente, que o GKE Identity Service requer para estabelecer uma ligação segura com uma instância do ADFS interna.
   ADFS_ORG_CLIENT_ID	O ID do OpenID Connect para o cliente da organização no ADFS.
   ADFS_ORG_CLIENT_SECRET	O segredo do OpenID Connect para o cliente da organização registado no ADFS.
   ADFS_ISSUER_URI	Um URI do emissor válido, que é necessário para o serviço de identidade do GKE permitir pedidos de início de sessão de redirecionamento para o ADFS.

5. Adicione o ficheiro 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 utilizador com o prefixo da IO para iniciar sessão no cluster inicialmente. Lembre-se de anexar o prefixo ao nome de utilizador.
   EXPIRATION	A data/hora formatada no RFC 3339 em que o sistema revoga o acesso. Por exemplo, "2020-11-14T00:20:12+00:00".

6. Anexe os ficheiros criados recentemente ao ficheiro 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. Prepare e confirme o ficheiro YAML da organização e os ficheiros do 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 do código e a união.

10. Para confirmar que o operador pode aceder à organização, inicie sessão na organização gerada e execute o seguinte comando para verificar se existe um fornecedor de identidade (IdP) no ClientConfig da organização:

    1. Defina o ficheiro kubeconfig do cluster de administrador consoante a arquitetura da sua organização:

       • Para uma organização v1, execute o seguinte comando:

         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 v2, execute o seguinte comando:

         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 existe um IdP no ClientConfig da organização:

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

11. Para a versão 1.14.3, tem de aplicar manualmente a função global-zone-viewer para permitir que todos os utilizadores autenticados vejam as zonas num universo através da CLI gdcloud. Aplique os recursos de função e associação de funções:

    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 ficheiro kubeconfig do servidor da API global da organização. Para mais informações, consulte o artigo Gere manualmente o ficheiro kubeconfig.

1.9. Associe o Fornecedor de identidade do cliente à organização

Para associar um fornecedor de identidade (IdP) do cliente à organização e iniciar sessão na organização com as respetivas identidades, conclua os seguintes passos:

1. Inicie sessão na CLI com a conta de administrador de IO inicial definida durante a criação da organização, que está automaticamente associada ao org-iam-admin no cluster de administrador da organização.

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

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

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

   Se estiver a usar um cliente SAML, também tem de adicionar o seguinte URL de retorno de chamada SAML da AIS global à lista de autorizações:

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

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

   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 retorno de chamada da AIS é https://ais-core.operations.zone-1.google.gdch.test/finish-login.

   Se estiver a usar um cliente SAML, também tem de adicionar os seguintes URLs de retorno de chamada SAML da AIS à lista de autorizaçõ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 ficheiro kubeconfig do cluster de administrador consoante a arquitetura da sua organização. Se já definiu a variável kubeconfig, ignore este passo.

   • Para uma organização v1, execute o seguinte comando:

       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 v2, execute o seguinte comando:

       export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
     

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

5. A partir do pedido de registo do cliente para uma nova organização, decida se o IdP usa OIDC ou SAML. Siga o guia que corresponde ao tipo de IdP indicado:

   • Configuração com o OIDC
   • Configuração com SAML
   Nota: escolha a configuração OIDC ou SAML a seguir. Isto baseia-se no IdP do cliente. Não configure ambas.

Configuração com o OIDC

1. Crie um ficheiro identity-provider-config.yaml e preencha-o consultando os pedidos de criação da organização para obter os 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
   

   Nota: atribua um prefixo ao IdP se o cliente não fornecer um. Consulte o artigo Prefixo do utilizador e do grupo para mais informações.

2. Seguem-se as descrições detalhadas dos campos:

   Atributo	Tipo de atributo	Descrição
   certificateAuthorityData	Obrigatório	Um certificado de autoridade de certificação em formato PEM codificado em base64 padrão para o fornecedor de OIDC.
   clientID	Obrigatório	O ID da aplicação cliente que faz pedidos de autenticação ao fornecedor OpenID.
   clientSecret	Obrigatório	O segredo partilhado entre a aplicação cliente OIDC e o fornecedor OIDC.
   extraParams	Opcional	Uma lista separada por vírgulas de pares de chave-valor que são codificados por consulta e enviados com o pedido do ponto final de autenticação.
   groupPrefix	Opcional	O prefixo a adicionar à declaração de grupos para evitar conflitos com os grupos existentes, normalmente usado quando configura vários fornecedores de identidade. Tem de incluir o prefixo do grupo antes de todos os nomes dos grupos. Por exemplo, se tiver myprefix- como prefixo do grupo e um grupo denominado groupA no seu fornecedor de identidade, quando adicionar uma política ou uma associação, tem de associar myprefix-groupA. O nome do grupo é definido no campo groupsClaim. Nota: 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] são identificados como [e-mail].
   groupsClaim	Opcional	O nome da reivindicação no token de ID OIDC que contém as informações dos grupos do utilizador. Este nome tem de ser igual ao nome da reivindicação que contém informações de associação a grupos no seu fornecedor OIDC.
   issuerURI	Obrigatório	O URL para onde os pedidos de autorização são enviados para o seu fornecedor de OIDC. Este URI tem de apontar para o nível dentro de .well-known/openid-configuration.
   scopes	Opcional	Uma lista de identificadores separados por vírgulas para especificar os privilégios de acesso pedidos além do âmbito openid.
   userClaim	Obrigatório	O nome da reivindicação no token de ID OIDC que contém o nome de utilizador. Por exemplo, se a reivindicação do utilizador for email, os utilizadores são identificados pelo campo de utilizador no token OIDC. Se esta informação estiver em falta no token de ID, a autenticação falha.
   userPrefix	Opcional	O prefixo a adicionar aos pedidos de utilizador para evitar conflitos com os nomes de utilizador existentes, normalmente usado quando configura vários fornecedores de identidade. Por exemplo, se a reivindicação do utilizador for email e o prefixo do utilizador for prefix-, os utilizadores são identificados como [e-mail]. O utilizador é [e-mail] e o prefixo, prefix-, é adicionado ao utilizador para distinguir entre diferentes fornecedores de identidade. Recomendamos a inserção de um separador no final do prefixo, conforme descrito anteriormente nesta tabela, para definir groupPrefix.

3. Opcional: se o seu fornecedor de identidade usar atributos personalizados, configure primeiro os atributos no IdP. Em seguida, adicione os pares de chave-valor correspondentes na secção oidc do ficheiro identity-provider-config.yaml para reivindicações adicionais sobre utilizadores ou grupos, como o respetivo departamento ou data de nascimento. Quando aplica as alterações à configuração do Fornecedor de identidade, o GKE Identity Service reconhece os atributos personalizados. Segue-se um exemplo de atributos personalizados:

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

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

   kubectl apply -f identity-provider-config.yaml
   

5. Aguarde que os vários componentes do sistema sejam reconfigurados.

6. Valide a configuração abrindo a consola da IU de administração da plataforma num navegador de Internet. Selecione Iniciar sessão com pa-idp-oidc na página de redirecionamento. Se for redirecionado para a instância do IdP da conta de administrador da plataforma e for redirecionado novamente para a página da consola da IU do administrador da plataforma depois de iniciar sessão com a instância do IdP da conta de administrador da plataforma, a configuração foi bem-sucedida. Caso contrário, verifique os valores em identity-provider-config.yaml e volte a aplicar o passo anterior.

Configuração com SAML

1. Crie um ficheiro identity-provider-config.yaml e preencha-o consultando os pedidos de criação da organização para os 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
   

   Nota: atribua um prefixo ao IdP se o cliente não fornecer um. Consulte o artigo Prefixo do utilizador e do grupo para mais informações.

2. Seguem-se as descrições detalhadas dos campos:

   .

   Atributo	Tipo de atributo	Descrição
   idpCertificateDataList	Obrigatório	Os certificados do IdP usados para validar a resposta SAML. Estes certificados devem estar codificados em Base64 padrão e no formato PEM. Só é suportado um máximo de dois certificados para facilitar a rotação de certificados de IdP.
   idpEntityID	Obrigatório	O ID da entidade SAML para o fornecedor SAML, especificado num formato URI. Por exemplo, https://www.idp.com/saml.
   idpSingleSignOnURI	Obrigatório	O URI para o ponto final de SSO do fornecedor SAML. Por exemplo, `https://www.idp.com/saml/sso`.
   groupPrefix	Opcional	O prefixo opcional a adicionar antes de cada nome de grupo.
   userPrefix	Opcional	O prefixo opcional a adicionar antes do nome de utilizador.
   userAttribute	Opcional	O nome do atributo na resposta SAML que contém o nome de utilizador. Se este atributo estiver em falta na resposta SAML, a autenticação falha.
   groupsAttribute	Opcional	O nome do atributo na resposta SAML que contém os grupos do utilizador.

3. Opcional: se o seu fornecedor de identidade usar atributos personalizados, configure primeiro os atributos no IdP. Em seguida, adicione os pares de chave-valor correspondentes na secção saml do ficheiro identity-provider-config.yaml para reivindicações adicionais sobre utilizadores ou grupos, como o respetivo departamento ou data de nascimento. Quando aplica as alterações à configuração do Fornecedor de identidade, o GKE Identity Service reconhece os atributos personalizados. Segue-se um exemplo de atributos personalizados:

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

4. Configure a correção da configuração do Fornecedor de identidade:

   kubectl apply -f identity-provider-config.yaml
   

5. Aguarde que os vários componentes do sistema sejam reconfigurados.

6. Valide a configuração abrindo a consola da IU de administração da plataforma num navegador de Internet. Selecione Iniciar sessão com pa-idp-oidc na página de redirecionamento. Se for redirecionado para a instância do IdP da conta de administrador da plataforma e for redirecionado novamente para a página da consola da IU do administrador da plataforma depois de iniciar sessão com a instância do IdP da conta de administrador da plataforma, a configuração foi bem-sucedida. Caso contrário, verifique os valores em identity-provider-config.yaml e volte a aplicar o passo anterior.

Prefixo de utilizador e grupo

Os prefixos de utilizadores e grupos têm de ser definidos para cada IdP na nuvem distribuída para evitar conflitos de nomenclatura entre contas de diferentes IdPs. O prefixo é usado com o nome do utilizador e do grupo para concatenar o nome do assunto nas associações de funções no cluster. Por exemplo, para um utilizador com o nome [e-mail] e o prefixo de utilizador do IdP for 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 que adicione um caráter separador, como -, como sufixo, porque não é adicionado nenhum separador entre o prefixo e o nome de utilizador.

Atribua o administrador inicial

Para conceder ao PA acesso inicial à organização, este tem de ser atribuído como administrador da organização. 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 conetividade de rede para a organização

Uma organização criada recentemente está isolada e não pode ser acedida a partir de nenhuma rede externa. Para tornar a organização operacional, tem de a associar a uma ou mais redes externas através do serviço Interconnect.

Este processo envolve a configuração de um conjunto de recursos personalizados que definem a ligação lógica. Seguem-se dois cenários comuns para fornecer conetividade a uma nova organização.

Cenário 1: anexar uma organização a uma interligação partilhada existente

Se tiver uma interligação existente para uma rede partilhada, só tem de atualizar o AttachmentGroup e o RoutePolicy para incluir a nova organização.

1. Atualize o AttachmentGroup: Um AttachmentGroup especifica que organizações podem usar um conjunto de anexos de VLAN. Edite o AttachmentGroupficheiro YAML e adicione a nova organização à lista spec.entities. Para uma organização v2, tem de especificar a rede domainType (OrgAdmin, OrgData ou OrgMixed) à qual se ligar.

   Exemplo de atualização 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: Um RoutePolicy define os prefixos de IP que são anunciados. Edite a política e adicione as sub-redes de IP externas da nova organização ao spec.out.ipPrefixList. Isto permite que o tráfego de entrada chegue à organização.

   Exemplo de atualização 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 alterações através do kubectl apply com o seu processo de infraestrutura como código (IaC).

Cenário 2: criar uma nova interligação dedicada

Para uma ligação dedicada, tem de criar um novo conjunto de recursos de interligação. O processo completo envolve a criação de cinco recursos personalizados por ordem.

1. Crie um InterconnectLink para cada nova ligação física.
2. Crie um InterconnectGroup para agrupar as associações físicas 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 esta ligação dedicada.
5. Crie um ou mais recursos InterconnectAttachment para definir as VLANs e as sessões BGP.

Para ver exemplos abrangentes e passos detalhados para cada um destes recursos, consulte a documentação Configurar uma interconexão.

1.11 Configure o webhook do Alertmanager para estabelecer ligação ao ServiceNow

Siga os passos no artigo MON-T0016 para associar o webhook do Alertmanager ao ServiceNow para a criação de incidentes.

1.12 Configure a folha de preços de faturação para a organização

O subcomponente de faturação de uma organização requer que os produtos ou serviços a faturar sejam configurados com o recurso personalizado SKUDescription. Um único SKUDescription descreve um único produto ou serviço a ser faturado juntamente com o respetivo preço. Por conseguinte, uma coleção de SKUDescription objetos pode ser considerada a lista de preços de uma organização. Os passos seguintes configuram a tabela de preços para a organização no IAC.

1.12.1 Obtenha a folha de preços

Se ainda não tiver os recursos da folha de preços SKUDescription para uma organização, contacte o Program Management Office (PMO) para obter a folha de preços. A tabela de preços tem de ser uma série de ficheiros YAML que contenham recursos SKUDescription.

1.12.2 Determine se a tabela de preços é partilhada ou não

A folha de preços pode ser partilhada por todas as organizações ou configurada organização a organização. O PMO pode informar se a tabela de preços é partilhada ou não.

1.12.2.1 Folha de preços partilhada

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

1. Se esta organização não for a primeira a ser criada, a folha de preços pode já existir na pasta common-datapartilhada. Se a folha de preços existir, verifique se seguiu os passos 2 a 4 e avance para o passo 5.

2. Crie a pasta partilhada para a folha de preços.

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

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

3. Guarde os recursos YAML da SKUDescription folha de preços nesta pasta. Posteriormente, a pasta skudescriptions tem de conter ficheiros YAML separados por área. Configure a estrutura de pastas e os ficheiros YAML para se alinharem com o seu caso de utilização de faturação:

   • Faturação gerida pelo parceiro: a Google cobra ao parceiro. Coloque os SKUDescriptionrecursos no espaço de nomes partner-billing-system.

   • Faturação de cliente: o parceiro cobra ao utilizador final. Coloque os SKUDescriptionrecursos no espaço de nomes billing-system.

   Os exemplos seguintes mostram as estruturas de ficheiros de faturação do cliente e do modelo de faturação operado pelo parceiro. Para cada modelo, vê dois serviços, computação e armazenamento, com dois ficheiros YAML para cada serviço:

   Faturação de clientes:

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

   Faturação gerida pelo parceiro:

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

4. Verifique se existe um ficheiro kustomization.yaml no diretório que inclui todos os ficheiros YAML da folha 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 v1, execute o seguinte comando:

     export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME
     

   • Para uma organização v2, execute o seguinte comando:

     export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME
     

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

   • Para uma organização v1:

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

   • Para uma organização da versão 2:

     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, consoante o tipo de versão da sua organização.

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

   • Para uma organização 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 versão 2:

     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. Prepare e confirme o ficheiro YAML e personalize os ficheiros:

   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 do código e a união.

11. Verifique se os objetos SKUDescription existem no cluster indicado para o seu modelo de faturação correspondente.

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

    • Para uma organização v1, execute o seguinte comando:

      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 v2, execute o seguinte comando:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
      

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

    Execute a CLI kubectl:

    Para a faturação de clientes:

    
    kubectl get SKUDescription -n billing-system
    

    Para faturação de parceiros:

    
    kubectl get SKUDescription -n partner-billing-system
    

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

Se a folha de preços for específica de uma organização, tem de colocar a folha de preços na pasta do cluster da organização.

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

   • Para uma organização v1:

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

   • Para uma organização da versão 2:

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

2. Guarde os recursos YAML da folha de preços SKUDescription nesta pasta. Depois, a pasta skudescriptions tem de ter ficheiros YAML separados por área. No exemplo seguinte, vê dois serviços, compute e storage, com dois ficheiros YAML cada:

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

3. Certifique-se de que existe um ficheiro kustomization.yaml no diretório que inclui todos os ficheiros YAML da folha de preços SKUDescription.

   • Para uma organização 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 versão 2:

     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. Certifique-se de que o ficheiro kustomization.yaml na raiz da organização tem a pasta bil/skudescriptions adicionada recentemente. Verifique IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml para uma organização v1 e IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml para uma organização v2 :

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

5. Prepare e confirme o ficheiro YAML e os ficheiros 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 do código e a união.

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

   • Para uma organização v1, execute o seguinte comando:

     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 v2, execute o seguinte comando:

     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 de gestão, como /tmp/${ORG}-management-kubeconfig. .

1.13 Create Billing recurring usages

A Distributed Cloud oferece unidades de controlo do stock (SKU) que incorrem em cobranças recorrentes. No entanto, o Distributed Cloud não monitoriza os custos de utilização de determinadas SKUs. Para gerir estas informações, use o recurso RecurringUsage. Para ver detalhes e instruções sobre como criar utilizações recorrentes, consulte o artigo Crie utilizações recorrentes.

1.14 Configure a faturação para uma organização

O subcomponente de faturação não começa a calcular o custo de uma organização até atingir a hora de início da faturação. A hora de início da faturação tem um valor predefinido de 9999-01-01T00:00:00-07:00. Por conseguinte, depois de uma organização ser considerada pronta, a OI substitui a hora de início da faturação para iniciar o fluxo de trabalho de faturação.

1.14.1 Obtenha a hora de início da faturação

A hora de início da faturação tem de ser no início do período de desempenho, que está disponível no seu contrato. Se ainda não tiver a hora de início da faturação de uma organização, contacte o Program Management Office (PMO) para obter as informações.

1.14.2 Mapeie a conta de pagamentos de faturação a uma organização

Os ambientes isolados do Google Distributed Cloud (GDC) requerem uma conta de faturação para acompanhar os custos de projetos e organizações. Se não associar uma conta de faturação a uma organização ou a um projeto, perde os dados de custos associados ao recurso.

Para cobrar a utilização dos serviços ao cliente, todas as contas de faturação numa organização usam uma única lista de preços.

1.14.2.1 Antes de começar

Antes de continuar, peça ao administrador de segurança que lhe conceda as seguintes funções obrigatórias. Estas funções estão associadas ao espaço de nomes do projeto para a faturação ao nível do projeto ou ao espaço de nomes da plataforma para a faturação ao nível da organização:

• Administrador da conta de faturação da organização: crie, faça a gestão e associe o recurso BillingAccount. Peça ao administrador de segurança para lhe conceder a função organization-billing-account-admin.

• Utilizador da conta de faturação da organização: ler, listar e associar o recurso.BillingAccount Peça ao administrador de segurança para lhe conceder a função organization-billing-account-user.

• Gestor da conta de faturação da organização: ler, listar, criar e atualizar o recurso BillingAccountBinding. Peça ao administrador de segurança para lhe conceder a função organization-billing-manager.

1.14.2.2 Crie uma nova conta de faturação

Uma conta de faturação é identificada de forma exclusiva pelo respetivo name e namespace. Para criar uma conta de faturação, use um recurso personalizado para estabelecer o name e o namespace:

1. Crie um ficheiro YAML e adicione o recurso personalizado BillingAccount e o seguinte conteúdo:

   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 faturação. Por exemplo. test-billing-account.
   • BIL_DISPLAY_NAME: o nome a apresentar da conta de faturação. Por exemplo. "Test Billing Account".

2. Valide o tipo de configuração de pagamento. As contas de faturação do Distributed Cloud têm de ter uma das seguintes configurações de pagamento:

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

   • customConfig: uma configuração personalizada para os parceiros armazenarem a respetiva configuração de pagamento para faturar à organização. customConfig suporta um dicionário de strings de chave-valor, com uma chave obrigatória payment-config-type.

   Os exemplos seguintes mostram fragmentos de ficheiros YAML para diferentes configurações de pagamento:BillingAccount

   cloudBillingConfig

   spec:
     paymentSystemConfig:
       cloudBillingConfig:
         accountID: CLOUD_BILLING_ACCOUNT_ID
   

   Substitua CLOUD_BILLING_ACCOUNT_ID pelo ID da sua conta de faturação.Google Cloud

   customConfig

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

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

   Se não tiver as informações de customConfigconfiguração da sua organização, introduza os seguintes detalhes:

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

   O ficheiro YAML seguinte 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. Guarde o ficheiro YAML de recursos personalizados. Execute a CLI kubectl para aplicar o recurso no cluster da organização para a organização ou o projeto específico que quer faturar:

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

1.14.2.3 Associe uma organização a uma conta de faturação

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

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

   • Na secção billingAccountRef, preencha o campo name com o conteúdo do campo name no BillingAccount que quer associar.
   • Na secção metadata, preencha o campo namespace com o conteúdo do campo idêntico no recurso BillingAccount. Neste exemplo, o espaço de nomes 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 ficheiro 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 que lhe conceda a função Bil Monitor (bil-monitor) no cluster de administrador org. para o espaço de nomes billing-system. Esta autorização permite-lhe ler recursos relacionados para validação.

1.14.4 Substituir a hora de início da faturação

1. Crie dois ficheiros 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 ficheiro, se estiverem em falta.

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

   Para a faturação de clientes:

   • Ficheiro 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
     

   • Ficheiro 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 a faturação operada pelo parceiro:

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

   • Ficheiro 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
     

   • Ficheiro 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: a data/hora para iniciar o fluxo de trabalho de faturação.A data/hora tem de seguir o formato RFC 3339. Por exemplo, se o fluxo de trabalho de faturação começar a 01/01/2024 com o fuso horário da Hora Padrão do Pacífico dos EUA e do Canadá (UTC-8), adicione o valor da indicação de tempo como 2024-01-01T00:00:00-08:00.

   • BILLING_TIMEZONE: o fuso horário do fluxo de trabalho de faturação. O fuso horário tem de seguir o formato RFC 3339. Por exemplo, se o fuso horário de faturação for a Hora 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), precisa de um SubcomponentOverride adicional para os seguintes espaços de nomes para distribuir OperableParameters aos subcomponentes do servidor da API Management:

   • Ficheiro 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
     

   • Ficheiro 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. Guarde e armazene os ficheiros YAML na pasta infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

4. Crie um pedido de obtenção com os ficheiros YAML juntamente com o ficheiro de personalização necessário.

1.14.5 Valide a hora de início da faturação

Verifique se substituiu a hora de início da faturação para o rentabilizador, bem como 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 administração da organização

Nota: aplicado apenas à arquitetura da organização v2 (organização v2). Ignore se tiver a arquitetura da organização v1 (organização v1).

1.15.1 Crie o ficheiro YAML da política de rede

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

  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 Aplique a política da rede ao cluster de administração da organização

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Crie um site alternativo

Se tirar partido do apoio técnico de recuperação de desastres, tem de concluir novamente os passos anteriores para o site de cópia de segurança. Se não tiver a recuperação de desastres ativada, ignore esta secção.

1. Siga as secções 1.4. - 1.9. para criar outra organização para o site de cópia de segurança.

1.17. Resolva problemas de criação de organizações

1.17.1. Confirme se todos os recursos implementados estão em bom estado e presentes

O processo de criação da organização cria vários recursos em diferentes clusters do Kubernetes. Primeiro, verifique os recursos implementados e certifique-se de que estão em bom estado. As secções seguintes descrevem os recursos criados para uma organização denominada operations.

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

Conclua os passos seguintes para confirmar que todos os recursos no cluster de administrador raiz estão em bom estado e presentes:

1. Obtenha a configuração kubeconfig necessária para o cluster de administrador raiz seguindo as instruções em IAM-R0004. Certifique-se de que define as seguintes variáveis de ambiente e alias para estas instruções de validação:

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

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

   1. Estabeleça uma ligação SSH à firewall e confirme que foi criado um novo vsys:

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

      O resultado é semelhante ao seguinte:

      vsys1 {
      vsys2 {
      

   2. Consulte o recurso FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system
      

      O resultado é semelhante ao seguinte:

      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. Consulte o recurso StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system
      

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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 de HSM:

      k get hsmcluster -n gpc-system
      

      O resultado é semelhante ao seguinte:

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

   3. Verifique o inquilino do HSM:

      k get hsmtenant -A
      

      O resultado é semelhante ao seguinte:

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

5. Confirme que os recursos da máquina e do nó estão disponíveis:

   1. Consulte os AddressPoolClaim recursos:

      k get addresspoolclaims -A
      

      O resultado é semelhante ao seguinte:

      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. Consulte os NodePoolClaim recursos:

      k get nodepoolclaims -A
      

      O resultado é semelhante ao seguinte:

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

   3. Consulte os NodePool recursos:

      k get nodepool -A
      

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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. Estão num estado provisioned:

      k get servers -n gpc-system | grep provisioned
      

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

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

   8. Verifique os segredos do kubeconfig:

      k get secrets -A | grep kubeconfig
      

      O resultado é semelhante ao seguinte:

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

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

Conclua os passos seguintes para confirmar que todos os recursos no cluster de administrador da organização e no cluster do sistema numa organização v1 estão em bom estado e presentes. Se tiver uma organização da versão 2, avance para a secção seguinte.

1.17.3.1. Confirme todos os recursos implementados num cluster de administrador da organização

1. Obtenha a configuração kubeconfig necessária para o cluster de administrador raiz seguindo as instruções em IAM-R0004. Certifique-se de que define as seguintes variáveis de ambiente e alias para estas instruções de validaçã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 que os recursos da máquina e do nó estão disponíveis:

   1. Verifique os clusters bare metal:

      ka get baremetalclusters -A
      

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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. Consulte os VirtualmachinesInstance recursos:

      ka get virtualmachineinstances -A
      

      O resultado é semelhante ao seguinte:

      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. Consulte os NodePool recursos:

      ka get nodepools -A
      

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

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

   7. Verifique os nós:

      ka get nodes -A
      

      O resultado é semelhante ao seguinte:

      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 segredos do kubeconfig:

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

      O resultado é semelhante ao seguinte:

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

1.17.3.2. Confirme todos os recursos implementados no cluster de utilizadores do sistema

Conclua os passos seguintes para confirmar que todos os recursos no cluster do sistema estão em bom estado e presentes:

1. Obtenha a configuração kubeconfig necessária para o cluster de administrador raiz seguindo as instruções em IAM-R0004. Certifique-se de que define as seguintes variáveis de ambiente e alias para estas instruções de validaçã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 que os recursos da máquina e do nó estão disponíveis:

   1. Consulte o recurso VirtualmachineInstance:

      ku get vmi -A
      

      O resultado é semelhante ao seguinte (se tiver sido criado um cluster de utilizadores):

      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 é semelhante ao seguinte:

      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 atribuições de GPU:

      ku get gpuallocations -A
      

      O resultado é semelhante ao seguinte:

      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 implementados nos clusters da organização v2

Conclua os seguintes passos para confirmar que todos os recursos no cluster de infraestrutura da organização numa organização v2 estão em bom estado e presentes. Se tiver uma organização da versão 1, ignore esta secção.

1. Obtenha a configuração kubeconfig necessária para o cluster de administrador raiz seguindo as instruções em IAM-R0004. Certifique-se de que define as seguintes variáveis de ambiente e alias para estas instruções de validaçã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 os servidores da API estão em bom estado:

   1. Verifique os nós:

      ka get nodes -A
      

      O resultado é semelhante ao seguinte:

      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 segredos do kubeconfig:

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

      O resultado é semelhante ao seguinte:

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

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

   ka get gpuallocations -A
   

   O resultado é semelhante ao seguinte:

   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. Confirme se todos os recursos da organização estão reconciliados

Conclua os passos seguintes para confirmar que todos os recursos relacionados com a organização no cluster de administrador raiz global e zonal estão em bom estado e presentes, partindo do princípio de que o objetivo é criar uma organização operations com duas zonas: zone-1 e zone-2.

Nota: para cada recurso, pode verificar o status através de kubectl describe para encontrar informações mais detalhadas sobre falhas. status é um estado agregado de todas as zonas, no qual o campo rolloutStatus contém detalhes de propagação zonal e o campo replicaStatus contém detalhes de aprovisionamento de recursos zonais.

1. Siga o artigo Aceda à API global de administrador principal para aceder ao servidor de API global e use o seguinte alias para o kubectl da API global de administrador principal.

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

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

   1. Verifique os recursos Organization globais:

      kga get organization -A
      

      O resultado é semelhante ao seguinte:

      NAMESPACE    NAME         READY
      gpc-system   operations
      gpc-system   root
      

   2. Verifique os recursos OrganizationReplica globais:

      kga get organizationreplica -A
      

      O resultado é semelhante ao seguinte:

      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 OrganizationZonalConfig globais:

      kga get organizationzonalconfig -A
      

      O resultado é semelhante ao seguinte:

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

   4. Verifique os recursos OrganizationZonalConfigReplica globais:

      kga get organizationzonalconfigreplica -A
      

      O resultado é semelhante ao seguinte:

      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 ao nível da zona estão disponíveis:

   1. Consulte os Organization recursos:

      ka get organization -A
      

      O resultado é semelhante ao seguinte:

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

   2. Consulte os OrganizationReplica recursos:

      ka get organizationreplica -A
      

      O resultado é semelhante ao seguinte:

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

   3. Consulte os OrganizationZonalConfigReplica recursos:

      ka get organizationzonalconfigreplica -A
      

      O resultado é semelhante ao seguinte:

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

5. Siga as instruções em Permita que qualquer endereço aceda a uma organização para permitir o tráfego DCI nos clusters de administração da organização do site de origem para o site de cópia de segurança.