1. Crear una organización del cliente

Tiempo estimado para completarlo: 3 horas

Perfil de habilidades: ingeniero de implementaciones

Como operador, puedes crear una organización para proporcionar acceso a la infraestructura de la plataforma a los clientes. Para obtener los permisos que necesitas para crear una organización, pide a tu administrador de seguridad que te asigne el rol de administrador de la organización.

El recurso Organization es el nodo raíz de la jerarquía de recursos con air gap de Google Distributed Cloud (GDC). Todos los recursos que pertenecen a una organización se agrupan en el nodo de la organización. De esta forma, se obtiene una visibilidad y un control centralizados sobre todos los recursos que pertenecen a una organización.

Para obtener más información sobre las organizaciones, consulta el artículo Introducción a las organizaciones.

1.1. Antes de empezar

Asegúrate de que has instalado lo siguiente:

  • Un navegador en tu sistema.

  • La interfaz de línea de comandos (CLI) de Git.

  • La CLI de kubectl.

  • La CLI de gdcloud.

1.2. Crear un cliente de OIDC en OC IT ADFS

  1. Consulta las instrucciones de configuración de OIDC de ADFS para crear un cliente OpenID Connect (OIDC) en ADFS y que el operador pueda acceder a la organización que vas a crear. Anota el ID de cliente y el secreto de cliente de OIDC. No debes reutilizar el cliente en conexiones a otros clústeres, como el clúster de administrador raíz y otros clústeres de administrador de organización, ni a servicios como ServiceNow.

  2. Añade la siguiente URL de retrollamada de GKE Identity Service a la lista de permitidas del cliente OIDC de ADFS que has creado para la organización que vas a crear:

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

    Por ejemplo:

    • Nombre de la organización: operations
    • Nombre de la instancia de Distributed Cloud: google
    • Nombre de dominio de Distributed Cloud: gdch.test

    En este caso, la URL de retrollamada de GKE Identity Service es https://ais-core.operations.google.gdch.test/finish-login.

  3. Añade la siguiente URL de retrollamada del servicio de identidad de GKE a la lista de permitidas del cliente OIDC de ADFS que has creado para cada zona de tu universo de GDC:

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

    Por ejemplo:

    • Nombre de la organización: operations
    • Nombre de la zona: zone-1
    • Nombre de la instancia de Distributed Cloud: google
    • Nombre de dominio de Distributed Cloud: gdch.test

    En este caso, la URL de retrollamada de GKE Identity Service es https://ais-core.operations.zone-1.google.gdch.test/finish-login.

  4. Define las siguientes variables para usarlas en las secciones posteriores:

    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

    Sustituye las variables por los siguientes valores:

    VariableDefinición
    ADFS_CERT_BASE64 El archivo adfs.pem codificado en base64.
    ADFS_CLIENT_ID El identificador de cliente de ADFS.
    ADFS_CLIENT_SECRET Secreto compartido del cliente de ADFS.
    ADFS_ISSUER_URI URI del emisor de ADFS. Para obtener el URI, comprueba la ruta /adfs/.well-known/openid-configuration del servidor ADFS:

    curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration | jq '.issuer' "https://fs.opscenter.local/adfs"

    El valor suele ser https://adfs.domain.com/adfs.

1.3. Crea subredes globales y divídelas para cada zona

Antes de crear una organización, debe crear las subredes raíz globales y dividirlas para cada zona con la subred de la API pública de gestión de direcciones IP (IPAM). Si vas a crear una organización de la versión 2 en una zona que ya tenía una organización de la versión 1, consulta la página de requisitos adicionales antes de crear tus subredes globales.

Las subredes raíz globales alojan el conjunto de direcciones IP raíz (CIDR) que se divide en cada zona para inicializar todos los clústeres de la organización de inquilinos, incluidos el clúster de infraestructura de la organización y las máquinas virtuales de carga de trabajo. También se pone a disposición de las subredes raíz una pequeña parte del intervalo de direcciones IP como grupo de direcciones IP de difusión general. Puedes asignar automáticamente CIDRs dedicados a cada zona mediante un controlador o puedes proporcionar CIDRs a cada zona manualmente.

Para iniciar una organización, necesitas el intervalo de direcciones IP internas que se indica en el cuestionario de entrada de la organización (OIQ). Debes usar esos intervalos de direcciones IP para crear la subred raíz global en el servidor de la API global.

Debes crear subredes raíz diferentes para cada servidor de API global. La asignación del campo OIQ, el nombre de la subred raíz global y el servidor de la API global se proporciona en la siguiente sección.

1.3.1. Definir el intervalo CIDR de OIQ

Los intervalos de CIDR no pueden solaparse entre sí ni con el zone-infra-cidr.

El zone-infra-cidr se encuentra en cada zona y se puede obtener del cuestionario de información del cliente (CIQ) si el cliente lo ha definido.

Para recuperar el zone-infra-cidr, ejecuta el siguiente comando:

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

A continuación, se muestra un ejemplo de la salida de 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

En este ejemplo, zone-infra-cidr es 192.0.2.0/24, por lo que ningún campo de la OIQ debe solaparse con 192.0.2.0/24.

En la siguiente tabla se muestran los campos de OIQ y sus valores mínimos predeterminados correspondientes:

Campo OIQ Descripción Tamaño mínimo requerido Tamaño mínimo por zona de la organización Nombre de la subred raíz global Servidor de API global
infraVPCCIDR Cargas de trabajo del sistema, como la consola de organización, las APIs de gestión y los servicios propios. \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr Raíz global
defaultVPCCIDR Cargas de trabajo y endpoints de usuarios en la VPC predeterminada de todas las zonas. \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr Organización mundial
orgAdminExternalCIDR Cargas de trabajo y endpoints del clúster perimetral que gestionan el tráfico administrativo entre la red externa y la organización. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 admin-external-root-cidr Raíz global
orgDataExternalCIDR Cargas de trabajo y endpoints a los que los usuarios pueden acceder externamente, como balanceadores de carga externos y NATs de salida. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr Raíz global

Si no tienes suficientes IPs como mínimo predeterminado sugerido, debes seguir el proceso de división manual para crear las subredes de cada zona.

Tenga en cuenta las siguientes limitaciones de los intervalos de subredes IPv4:

  • orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR y defaultVPCCIDR no deben superponerse entre sí, con otros intervalos asignados de la organización ni con ningún intervalo IPv4 de las redes emparejadas. Los CIDRs de estos elementos proceden del espacio de direcciones privadas RFC 1918.

    Redes emparejadas: pueden ser subredes anunciadas con redes externas a través de adjuntos de interconexión o subredes emparejadas con otras VPCs de la misma organización.

  • Si las organizaciones comparten los mismos recursos de interconexión AttachmentGroup, los valores de orgDataExternalCIDR y orgAdminExternalCIDR deben ser únicos. De lo contrario, se permite la superposición con otras organizaciones.

1.3.2. Crear subredes globales en el servidor de la API de administrador raíz global

Antes de crear una organización, debes crear las siguientes subredes en el servidor de la API de administrador raíz global:

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

Estas subredes son necesarias para iniciar la infraestructura de la organización en cada zona.

  1. Debes tener un espacio de nombres con un nombre que coincida con el nombre de la organización que le vas a asignar. Confirma que este espacio de nombres existe:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace

    Si este espacio de nombres no existe, créalo:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME

  2. Crea el archivo YAML de la subred infra-vpc-root-cidr, como ORG_NAME-infra-vpc-root-cidr.yaml:

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

  3. Crea el archivo YAML de la subred admin-external-root-cidr, como ORG_NAME-admin-external-root-cidr.yaml:

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

  4. Crea el archivo YAML de la subred data-external-root-cidr, como ORG_NAME-data-external-root-cidr.yaml:

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

  5. Copia los archivos YAML de las subredes infra-vpc-root-cidr, admin-external-root-cidr y data-external-root-cidr en el repositorio de IaC de la organización raíz:

    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. Asegúrate de que el archivo kustomization.yaml de la raíz de la organización tenga las definiciones Subnet recién añadidas. Comprobar 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. Añade y confirma los archivos YAML de la subred:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. Crear solicitud de combinación:

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

  9. Espera a que se revise el código y se combine.

1.3.3. Dividir las subredes raíz de las zonas

Las subredes raíz globales alojan el intervalo de direcciones IP raíz (CIDR) de todas las zonas. Para consumir el intervalo de direcciones IP de la zona, primero se deben dividir las subredes raíz globales en subredes más pequeñas que puedan consumir las zonas. Cada zona debe tener al menos un intervalo de direcciones IP raíz.

IPAM tiene un controlador global que divide automáticamente la subred raíz global en subredes más pequeñas para las zonas existentes. Los administradores pueden delegar en controladores de IPAM para dividir automáticamente la subred de la zona si no les importa el bloque CIDR exacto que utiliza una zona determinada. El controlador monitoriza la creación de la subred raíz global y crea una subred para cada zona con una longitud de prefijo predeterminada fija.

Subred raíz de zona Longitud de prefijo fija predeterminada
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

Las subredes raíz globales deben tener nombres fijos si quieres que los controladores de IPAM dividan automáticamente la subred de la zona:

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

Si defines la anotación ipam.gdc.goog/pause-auto-division: true para tus recursos Subnet, debes definir manualmente el bloque CIDR exacto que usa una zona determinada. Si creas las subredes raíz globales con nombres diferentes, la anotación ipam.gdc.goog/pause-auto-division no tendrá ningún efecto y las subredes globales no se dividirán automáticamente.

1.3.3.1. Dividir automáticamente las subredes raíz de las zonas

El controlador global divide automáticamente la subred raíz global en subredes más pequeñas para las zonas que ya existen. Por ejemplo, echa un vistazo al siguiente flujo de trabajo para entender cómo divide el controlador la subred raíz global en subredes más pequeñas para las zonas existentes:

Si hay dos zonas llamadas zone1 y zone2, un ejemplo de subred raíz global infra-vpc-root-cidr que usa infraVPCCIDR, como 10.0.0.0/16, del OIQ en el espacio de nombres org-1 tiene este aspecto:

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

Cuando se implementa en la plataforma de GDC, el controlador crea automáticamente dos subredes secundarias llamadas infra-vpc-zone1-root-cidr y infra-vpc-zone2-root-cidr con la longitud de prefijo /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

1.3.3.2. Dividir manualmente las subredes raíz de las zonas

En esta sección se da por hecho que has definido la anotación ipam.gdc.goog/pause-auto-division: true cuando has creado las subredes raíz globales en el servidor de la API de administrador raíz global. Esta anotación pausa el controlador para reconciliar esas subredes raíz globales, lo que te permite crear manualmente la subred raíz y la subred de difusión Anycast de una zona.

Para dividir manualmente la subred raíz global en subredes más pequeñas para las zonas, haz lo siguiente:

  1. Lista las zonas de tu universo:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

  2. Confirma el CIDR dedicado de la subred raíz que quieras aplicar a tu zona. Hazlo con cada zona de tu universo.

  3. Asigna el CIDR dedicado a la subred de tu zona en un archivo 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

    Repite este paso con cada zona de tu universo de GDC.

  4. Confirma el CIDR dedicado de la subred raíz que quieras aplicar a la subred Anycast.

  5. Asigna el CIDR dedicado a la subred de difusión simultánea en un archivo 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. Copia los archivos YAML de la subred zonal en el repositorio de IaC de la organización raíz. Por ejemplo, si tienes dos archivos YAML de subredes zonales:

    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. Asegúrate de que el archivo kustomization.yaml de la raíz de la organización tenga las definiciones Subnet recién añadidas. Comprobar 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. Añade y confirma los archivos YAML de la subred:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  9. Crea la solicitud de combinación:

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

  10. Espera a que se revise el código y se combine.

1.3.3.2.1. Ejemplo de división manual de subredes raíz de zonas para infra-vpc

Si hay dos zonas llamadas zone1 y zone2, una subred raíz global de ejemplo infra-vpc-root-cidr que use infraVPCCIDR, como 192.0.2.0/24, del OIQ en el espacio de nombres org-1 tiene este aspecto:

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

Crea manualmente la subred de cada zona llamada infra-vpc-zone1-root-cidr y infra-vpc-zone2-root-cidr, así como la subred de anycast infra-vpc-anycast-cidr con el CIDR dedicado que decidas:

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

Asegúrate de añadir todos los archivos YAML de subred al repositorio de IaC.

1.3.3.2.2. Ejemplo de división manual de subredes raíz de zonas para un segmento de red de datos

Si hay dos zonas llamadas zone1 y zone2, una subred raíz global de ejemplo data-external-root-cidr que use orgDataExternalCIDR, como 10.0.0.0/24, del OIQ en el espacio de nombres org-1 tiene este aspecto:

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

Crea manualmente la subred de cada zona llamada data-external-zone1-root-cidr y data-external-zone2-root-cidr, así como la subred de anycast data-global-anycast-cidr con el CIDR dedicado que decidas:

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

Asegúrate de añadir todos los archivos YAML de subred al repositorio de IaC.

1.3.3.2.3. Ejemplo de división manual de subredes raíz de zonas para un segmento de red de administrador

Si hay dos zonas llamadas zone1 y zone2, una subred raíz global de ejemplo admin-external-root-cidr que usa el orgAdminExternalCIDR, como 192.168.1.0/24, del OIQ en el espacio de nombres org-1 tiene este aspecto:

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

Crea manualmente la subred de cada zona llamada admin-external-zone1-root-cidr y admin-external-zone2-root-cidr, así como la subred de Anycast admin-global-anycast-cidr con el CIDR dedicado que decidas:

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

Asegúrate de añadir todos los archivos YAML de subred al repositorio de IaC.

1.4. Crear una organización con IAC

Para crear una organización con IAC, siga estos pasos:

  1. Genera una lista de los servidores y tipos de servidores disponibles:

    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}'

    La salida de ejemplo es similar a la siguiente:

    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

    Cuando especifiques --server-quota y --admin-server más adelante, asegúrate de tener suficientes servidores available para completar la solicitud.

  2. Ve al repositorio iac y añade la estructura de directorios de la nueva organización:

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

  3. Crea un 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 ejemplo:

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

    Sustituye las siguientes variables:

    VariableDefinición
    ORG_NAME El nombre de la organización. El nombre de una organización debe cumplir los siguientes criterios:
    • Tener entre 3 y 19 letras ASCII minúsculas, dígitos o guiones.
    • y debe empezar por una letra.
    • No deben terminar con guiones.
    • No debe terminar con la cadena -system.
    LOG_RETENTION_POLICY Configuración de los tiempos de conservación de los registros de auditoría, los registros operativos y las métricas en días.
    KMS_ROOT_KEY_TYPE Esta configuración contiene el tipo de clave raíz elegido para el KMS de una organización. Cada servicio de KMS tiene una clave raíz para cifrar las claves generadas por el KMS. De forma predeterminada, el KMS genera una clave raíz de CTM, una clave raíz almacenada en Thales CipherTrust Manager con una copia de seguridad en un HSM físico. También puedes elegir una clave raíz de software almacenada como secreto de Kubernetes. Transfiere ctm-root o local-root para kmsRootKeyType.

    Un ejemplo del archivo YAML de Organizationrecurso personalizado generado es similar al siguiente:

    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: En la versión 1.14.2 y posteriores, el cifrado IPsec de nodo a nodo está inhabilitado de forma predeterminada. Si se requiere este cifrado IPsec, puedes habilitar el cifrado IPsec de nodo a nodo editando el archivo YAML de recursos personalizados Organization y añadiendo una anotación:

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

    Si se asigna el valor "false" a esta anotación, se habilita el cifrado.

  5. Crea un OrganizationZonalConfig recurso personalizado para cada zona de la implementación:

    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 ejemplo:

    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
    .

    Sustituye las siguientes variables:

    VariableDefinición
    ORG_NAME El nombre de la organización. El nombre de una organización debe cumplir los siguientes criterios:
    • Tener entre 3 y 30 letras ASCII minúsculas, dígitos o guiones.
    • y debe empezar por una letra.
    • No deben terminar con guiones.
    • No debe terminar con la cadena -system.
    ZONES Los nombres de las zonas de la implementación.
    GDC_VERSION Versión del sistema de GDC para la que se creará la organización.
    SERVER_QUOTA Los servidores que se asignarán al clúster de administrador de la organización y al clúster del sistema cuando se generen automáticamente. Si tienes previsto ejecutar recursos de unidades de procesamiento gráfico (GPU) que sean cargas de trabajo basadas en máquinas virtuales, como APIs de inteligencia artificial y aprendizaje automático (IA/AA) preentrenadas, debes aprovisionar máquinas con GPU al crear una organización. Para obtener más información, consulta la sección Habilitar la compatibilidad con GPU para clústeres del sistema.
    ADMIN_SERVER Un par clave-valor del tipo de servidor y la cantidad de servidores de administrador de la organización que se deben asignar a ese tipo de servidor. No se admiten tipos mixtos en los servidores. El valor predeterminado es o1-standard1-64-gdc-metal: 3.
    STORAGE_SIZE El tamaño de los distintos tipos de almacenamiento que se asignarán a la organización. El tamaño mínimo de almacenamiento en bloque de una organización es de 250 Gi, que se define con la marca BlockStandard.

    Un ejemplo del archivo YAML de OrganizationZonalConfigrecurso personalizado generado es similar al siguiente:

    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. Revisa los archivos YAML generados. Los archivos se encuentran en el directorio HOME.

    1. Confirma el tipo de organización. Puedes aprovisionar dos tipos de organizaciones:

      • Arquitectura de la organización v1 (organización v1)
      • Arquitectura de la organización v2 (organización v2)

      De forma predeterminada, las nuevas organizaciones se aprovisionan en función del tipo de implementación que hayas definido en los ajustes de la función de acceso:

      • Las implementaciones de PRODUCTION generan organizaciones de la versión 2 de forma predeterminada.
      • Las implementaciones de ACCREDITED generan organizaciones de la versión 1 de forma predeterminada.

      En el caso excepcional de que tengas que anular el tipo de organización predeterminado de tu tipo de implementación, actualiza el campo spec.compatibilityOptions.architectureOverridePolicy de tu recurso personalizado Organization generado a ForceV1 o ForceV2, en función del tipo de organización que quieras usar. Por ejemplo, el siguiente fragmento de código fuerza la creación de una organización de la versión 2 en una implementación de ACCREDITED:

      ...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...

    2. Confirma los ajustes restantes para asegurarte de que los componentes, como el almacenamiento y la potencia de cálculo, son suficientes para las necesidades de tu empresa.

  7. Copia los recursos personalizados Organization y OrganizationZonalConfig en el repositorio del directorio de la nueva organización:

    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/

    Haz los cambios siguientes:

    • ORG_NAME: el nombre de la organización que has definido en el comando gdcloud organizations config create con el parámetro --name.
    • ZONE: el nombre de cada zona de la implementación. El nombre de la zona se deriva con el siguiente formato: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Por ejemplo, us-central1-b. Consulta la sección de zona del cuestionario de incorporación de clientes para ver las descripciones de los valores del atributo de zona.

  8. Añade el archivo kustomization.yaml de la nueva organización:

    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. Añade la nueva organización como recurso de la organización raíz:

    1. Abre el archivo raíz global kustomization.yaml:

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

    2. Añade el nuevo Organization como recurso al final de la lista de recursos:

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

  10. Añade y confirma el archivo YAML de la organización y los archivos de Kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. Crear solicitud de combinación:

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

  12. Espera a que se revise el código y se combine.

  13. Verifica que estén disponibles las configuraciones globales de la organización y de la zona:

    1. Verifica que la organización global esté disponible en tu universo de GDC:

      kubectl get organization -A

      El resultado debería ser similar al siguiente:

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

    2. Comprueba el estado de la organización global:

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

      Asegúrate de que las condiciones status de la salida de YAML sean True.

    3. Comprueba el estado de la configuración de la organización en cada zona:

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

      Para cambiar de contexto zonal, usa la CLI de gdcloud para iniciar sesión en cada zona antes de comprobar el estado de la organización. Asegúrate de que las condiciones status de la salida de YAML de cada zona sean True.

1.5. Crear subredes globales en el servidor de la API de la organización global

Debes crear el default-vpc-root-cidr en el servidor de la API global de la organización dentro del espacio de nombres platform después de que se ejecute el servidor de la API global. Esta subred raíz asigna la dirección IP de los clústeres de la organización del arrendatario, como los clústeres de usuarios, así como las direcciones IP de las cargas de trabajo de las máquinas virtuales.

  1. Crea el archivo YAML de la subred default-vpc-root-cidr, como default-vpc-root-cidr.yaml:

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

  2. Ve al repositorio iac y añade la estructura de directorios de la organización global:

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

  3. Copia el archivo YAML de la subred default-vpc-root-cidr en el repositorio de IaC del directorio de la nueva organización:

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

  4. Crea el archivo kustomization.yaml en la carpeta de la organización con las definiciones de Subnet que acabas de añadir. Comprobar 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. Añade y confirma el archivo YAML de la organización y los archivos de Kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  6. Crea la solicitud de combinación:

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

  7. Espera a que se revise el código y se combine.

Al igual que las subredes globales del clúster de administrador raíz global, el default-vpc-root-cidr también se divide y se propaga a cada zona para que la organización zonal consuma direcciones IP.

1.7. Configurar NTPRelay de administrador de organización

Debes configurar manualmente la autenticación entre los NTPRelays de administrador raíz y de administrador de organización.

Sigue el procedimiento NTP-P0001.3 (Administrador raíz -> Administrador de organización -> Cifrado de NTPRelay) para configurar el cifrado de esta organización.

1.8. Conectar el proveedor de identidades de IO a la organización con IAC

  1. Consulta la guía de ADFS para crear un cliente de OIDC en ADFS para la nueva organización y anota el ID de cliente y el secreto de cliente del cliente de OIDC.

  2. Define el nombre de tu organización como una variable de entorno:

    export ORG_NAME=ORG_NAME

    Verifica que el ORG_NAME coincida exactamente con el nombre de la organización.

  3. Exporta el archivo kubeconfig del clúster de administrador raíz y ejecuta los siguientes comandos kubectl para obtener los nombres del clúster y de la zona:

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

  4. Añade el archivo ioauthmethod.yaml de la organización:

    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

    Sustituye las siguientes variables:

    VariableDefinición
    ADFS_CERT_BASE64 La codificación base64 del certificado que usa ADFS para autofirmarse, que requiere el servicio de identidad de GKE para establecer una conexión segura con una instancia interna de ADFS.
    ADFS_ORG_CLIENT_ID El ID de OpenID Connect del cliente de la organización en ADFS.
    ADFS_ORG_CLIENT_SECRET El secreto de OpenID Connect del cliente de la organización registrado en ADFS.
    ADFS_ISSUER_URI Un URI de emisor válido, que es necesario para que Identity Service for GKE permita solicitudes de inicio de sesión de redirección a ADFS.

  5. Añade el archivo initial-admin.yaml de la organización:

    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: gdch-infra-operator-USER@opscenter.local
EOF

    Sustituye las siguientes variables:

    VariableDefinición
    USER El nombre de usuario con el prefijo de la IO para iniciar sesión en el clúster inicialmente. Recuerda añadir el prefijo al nombre de usuario.
    EXPIRATION Marca de tiempo con formato RFC 3339 en la que el sistema revoca el acceso. Por ejemplo, "2020-11-14T00:20:12+00:00".

  6. Añade los archivos recién creados al archivo kustomization.yaml en 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. Añade y confirma el archivo YAML de la organización y los archivos de Kustomize:

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

  8. Envía la actualización a GitLab:

    git -c http.sslVerify=false push

  9. Espera a que se revise el código y se combine.

  10. Para confirmar que el operador puede acceder a la organización, inicia sesión en la organización generada y ejecuta el siguiente comando para verificar que existe un proveedor de identidades (IdP) en el ClientConfig de la organización:

    1. Define el archivo kubeconfig de tu clúster de administrador en función de la arquitectura de tu organización:

      • En una organización de la versión 1, ejecuta el siguiente comando:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        Sustituye ORG_ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de administrador de la organización, como /tmp/${ORG}-admin-kubeconfig.

      • En una organización de la versión 2, ejecuta el siguiente comando:

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        Sustituye ORG_INFRA_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de infraestructura de la organización, como /tmp/${ORG}-infra-kubeconfig.

    2. Comprueba que haya un IdP en el ClientConfig de la organización:

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

  11. En la versión 1.14.3, debe aplicar manualmente el rol global-zone-viewer para permitir que todos los usuarios autenticados vean las zonas de un universo mediante la CLI de gdcloud. Aplica los recursos de rol y vinculación de rol:

    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

    Sustituye ORG_GLOBAL_API_SERVER_KUBECONFIG por el archivo kubeconfig del servidor de la API global de la organización. Para obtener más información, consulta Generar manualmente el archivo kubeconfig.

1.9. Conectar el proveedor de identidades del cliente con la organización

Para conectar un proveedor de identidades de cliente a la organización e iniciar sesión en la organización con sus identidades, sigue estos pasos:

  1. Inicia sesión desde la CLI con la cuenta de administrador de IO inicial configurada durante la creación de la organización, que se vincula automáticamente a org-iam-admin en el clúster de administrador de la organización.

  2. Pide al cliente que añada la siguiente URL de retrollamada global de AIS a la lista de permitidas en el cliente de OIDC o SAML que haya creado para la organización que vas a crear:

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

    Por ejemplo, si la URL raíz de GDC es .google.gdch.test y el nombre de la organización es operations, la URL de retrollamada de AIS global es https://ais-core.operations.google.gdch.test/finish-login.

    Si usas un cliente SAML, también debes añadir la siguiente URL de retrollamada global de AIS SAML a la lista de permitidos:

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

  3. Pide al cliente que añada la siguiente URL de retrollamada de AIS a la lista de permitidas en el cliente de OIDC o SAML que haya creado para cada zona. Por ejemplo, en un universo de tres zonas, las URLs de retrollamada de AIS zonales son similares a las siguientes:

    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

    Si la URL raíz de GDC es .google.gdch.test, el nombre de la zona es zone-1 y el nombre de la organización es operations, la URL de retrollamada de AIS es https://ais-core.operations.zone-1.google.gdch.test/finish-login.

    Si usas un cliente SAML, también debes añadir las siguientes URLs de retrollamada de SAML de AIS a la lista de permitidos 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. Define el archivo kubeconfig de tu clúster de administrador en función de la arquitectura de tu organización. Si ya has definido la variable kubeconfig, sáltate este paso.

    • En una organización de la versión 1, ejecuta el siguiente comando:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Sustituye ORG_ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster del administrador de la organización, como /tmp/${ORG}-admin-kubeconfig.

    • En una organización de la versión 2, ejecuta el siguiente comando:

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Sustituye MANAGEMENT_API_SERVER_KUBECONFIG por la ruta al archivo kubeconfig del servidor de la API Management, como /tmp/${ORG}-management-kubeconfig.

  5. En la incidencia de solicitud del cliente para una nueva organización, decide si el proveedor de identidades usa OIDC o SAML. Sigue la guía correspondiente al tipo de IdP:

Configuración con OIDC

  1. Crea un archivo identity-provider-config.yaml y rellénalo consultando los valores del IdP de la cuenta de la PA en las incidencias de creación de la organización:

    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

  2. A continuación, se describen los campos en detalle:

    Atributo Tipo de atributo Descripción
    certificateAuthorityData Obligatorio Un certificado de autoridad de certificación estándar codificado en Base64 y con formato PEM para el proveedor de OIDC.
    clientID Obligatorio ID de la aplicación cliente que envía solicitudes de autenticación al proveedor de OpenID.
    clientSecret Obligatorio Secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC.
    extraParams Opcional Lista separada por comas de pares clave-valor que se codifican como consulta y se envían con la solicitud del endpoint de autenticación.
    groupPrefix Opcional El prefijo que se debe añadir al principio de la reclamación de grupos para evitar conflictos con los grupos ya existentes. Se suele usar al configurar varios proveedores de identidades.
    Debes incluir el prefijo del grupo antes de todos los nombres de grupo. Por ejemplo, si tienes myprefix- como prefijo de grupo y un grupo llamado groupA en tu proveedor de identidades, cuando añadas una política o una vinculación, debes vincular myprefix-groupA. El nombre del grupo se define en el campo groupsClaim.
    groupsClaim Opcional Nombre de la reclamación del token de ID de OIDC que contiene la información de los grupos del usuario. Este nombre debe ser el mismo que el del reivindicación que contiene información sobre la pertenencia a grupos en tu proveedor de OIDC.
    issuerURI Obligatorio La URL a la que se envían las solicitudes de autorización a tu proveedor de OIDC. Este URI debe apuntar al nivel dentro de .well-known/openid-configuration.
    scopes Opcional Lista de identificadores separados por comas para especificar qué privilegios de acceso se solicitan además del ámbito openid.
    userClaim Obligatorio Nombre de la reclamación del token de ID de OIDC que contiene el nombre de usuario. Por ejemplo, si la reclamación de usuario es email, los usuarios se identifican por el campo de usuario del token de OIDC.
    Si falta en el token de ID, la autenticación falla.
    userPrefix Opcional Prefijo que se antepone a las reclamaciones de usuario para evitar conflictos con los nombres de usuario que ya existen. Se suele usar al configurar varios proveedores de identidades.
    Por ejemplo, si la reclamación del usuario es email y el prefijo del usuario es prefix-, los usuarios se identifican como prefix-sally@example.com. El usuario es sally@example.com y el prefijo, prefix-, se añade al usuario para distinguir entre diferentes proveedores de identidad.
    Se recomienda insertar un separador al final del prefijo, tal como se ha descrito anteriormente en esta tabla para el ajuste groupPrefix.

  3. Opcional: Si tu proveedor de identidades usa atributos personalizados, primero configura los atributos en tu IdP. A continuación, añade los pares clave-valor correspondientes en la sección oidc del archivo identity-provider-config.yaml para incluir más reclamaciones sobre los usuarios o grupos, como su departamento o fecha de nacimiento. Cuando apliques los cambios en la configuración del proveedor de identidades, GKE Identity Service reconocerá los atributos personalizados. Aquí tienes un ejemplo de atributos personalizados:

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

  4. Configura la configuración del proveedor de identidades:

    kubectl apply -f identity-provider-config.yaml

  5. Espera a que se vuelvan a configurar los distintos componentes del sistema.

  6. Verifica la configuración abriendo la consola de la interfaz de usuario de administrador de la plataforma en un navegador web. Seleccione Iniciar sesión con pa-idp-oidc en la página de redirección. Si se te redirige a la instancia del proveedor de identidades de la cuenta de administrador de la plataforma y, después de iniciar sesión con la instancia del proveedor de identidades de la cuenta de administrador de la plataforma, se te redirige a la página de la consola de la interfaz de usuario del administrador de la plataforma, la configuración se habrá realizado correctamente. De lo contrario, comprueba los valores de identity-provider-config.yaml y vuelve a aplicar el paso anterior.

Configuración con SAML

  1. Crea un archivo identity-provider-config.yaml y rellénalo consultando los tickets de creación de la organización para obtener los valores del IdP de la cuenta del administrador principal:

    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

  2. A continuación, se describen los campos en detalle:

    .
    Atributo Tipo de atributo Descripción
    idpCertificateDataList Obligatorio Los certificados del proveedor de identidades que se usan para verificar la respuesta SAML. Estos certificados deben estar codificados en Base64 estándar y en formato PEM. Solo se admiten dos certificados como máximo para facilitar la rotación de certificados del IdP.
    idpEntityID Obligatorio El ID de entidad SAML del proveedor de SAML, especificado en formato URI. Por ejemplo, https://www.idp.com/saml.
    idpSingleSignOnURI Obligatorio El URI del endpoint de SSO del proveedor de SAML. Por ejemplo, `https://www.idp.com/saml/sso`.
    groupPrefix Opcional Prefijo opcional que se antepondrá a cada nombre de grupo.
    userPrefix Opcional Prefijo opcional que se antepone al nombre de usuario.
    userAttribute Opcional Nombre del atributo de la respuesta SAML que contiene el nombre de usuario. Si falta este atributo en la respuesta SAML, la autenticación falla.
    groupsAttribute Opcional Nombre del atributo de la respuesta SAML que contiene los grupos del usuario.

  3. Opcional: Si tu proveedor de identidades usa atributos personalizados, primero configura los atributos en tu IdP. A continuación, añade los pares clave-valor correspondientes en la sección saml del archivo identity-provider-config.yaml para incluir más reclamaciones sobre los usuarios o grupos, como su departamento o fecha de nacimiento. Cuando apliques los cambios en la configuración del proveedor de identidades, GKE Identity Service reconocerá los atributos personalizados. Aquí tienes un ejemplo de atributos personalizados:

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

  4. Configura el parche de configuración del proveedor de identidades:

    kubectl apply -f identity-provider-config.yaml

  5. Espera a que se vuelvan a configurar los distintos componentes del sistema.

  6. Verifica la configuración abriendo la consola de la interfaz de usuario de administrador de la plataforma en un navegador web. Seleccione Iniciar sesión con pa-idp-oidc en la página de redirección. Si se te redirige a la instancia del proveedor de identidades de la cuenta de administrador de la plataforma y, después de iniciar sesión con la instancia del proveedor de identidades de la cuenta de administrador de la plataforma, se te redirige a la página de la consola de la interfaz de usuario del administrador de la plataforma, la configuración se habrá realizado correctamente. De lo contrario, comprueba los valores de identity-provider-config.yaml y vuelve a aplicar el paso anterior.

Prefijo de usuario y grupo

Los prefijos de usuarios y grupos deben definirse para cada IdP de Distributed Cloud para evitar conflictos de nombres entre cuentas de diferentes IdPs. El prefijo se usa con el nombre de usuario y de grupo para concatenar el nombre del asunto en las vinculaciones de roles del clúster. Por ejemplo, si el nombre de un usuario es jack@example.com y el prefijo de usuario del proveedor de identidades es example-org-idp-, el nombre de asunto del usuario en el clúster sería example-org-idp-jack@example.com.

Para decidir el valor del prefijo, sigue estos pasos:

  • Incluye el nivel de jerarquía (raíz, organización o proyecto).
  • Incluye el nombre del IdP (adfs, keycloak).
  • Te recomendamos que añadas un carácter separador, como -, como sufijo, ya que no se añade ningún separador entre el prefijo y el nombre de usuario.

Asignar un administrador inicial

Para conceder acceso inicial a la cuenta de PA a la organización, se le debe asignar el rol de administrador de la organización. Para asignar la cuenta de administrador principal como administrador inicial, crea un IAMRoleBinding en el servidor de la 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. Establecer la conectividad de red de la organización

Una organización recién creada está aislada y no se puede acceder a ella desde ninguna red externa. Para que la organización funcione, debes conectarla a una o varias redes externas mediante el servicio Interconnect.

Este proceso implica configurar un conjunto de recursos personalizados que definen la conexión lógica. A continuación, se describen dos situaciones habituales para proporcionar conectividad a una nueva organización.

Situación 1: Asociar una organización a una interconexión compartida

Si ya tienes una interconexión para una red compartida, solo tienes que actualizar AttachmentGroup y RoutePolicy para incluir la nueva organización.

  1. Actualiza el AttachmentGroup: un AttachmentGroup especifica qué organizaciones pueden usar un conjunto de adjuntos de VLAN. Edita el archivo AttachmentGroup YAML y añade la nueva organización a la lista spec.entities. En el caso de las organizaciones de la versión 2, debes especificar la red domainType (OrgAdmin, OrgData o OrgMixed) a la que te quieres conectar.

    Ejemplo de actualización de 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. Actualiza la RoutePolicy: Una RoutePolicy define qué prefijos de IP se anuncian. Edita la política y añade las subredes IP externas de la nueva organización a la spec.out.ipPrefixList. De esta forma, el tráfico entrante puede llegar a la organización.

    Ejemplo de actualización de 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. Aplica los cambios con kubectl apply mediante tu proceso de infraestructura como código (IaC).

Situación 2: Crear una interconexión dedicada

Para una conexión dedicada, debes crear un nuevo conjunto de recursos de interconexión. El proceso completo implica crear cinco recursos personalizados en orden.

  1. Crea un InterconnectLink por cada nueva conexión física.
  2. Crea un InterconnectGroup para agrupar las vinculaciones físicas y permitir la nueva organización.
  3. Crea un AttachmentGroup y especifica la nueva organización en la lista entities.
  4. Crea un RoutePolicy que permita los prefijos de IP entrantes y salientes de esta conexión dedicada.
  5. Crea uno o varios recursos InterconnectAttachment para definir las VLANs y las sesiones de BGP.

Para ver ejemplos completos y los pasos detallados de cada uno de estos recursos, consulta la documentación sobre cómo configurar una interconexión.

1.11 Configurar el webhook de Alertmanager para conectarse a ServiceNow

Sigue los pasos que se indican en MON-T0016 para conectar el webhook de Alertmanager a ServiceNow y crear incidentes.

1.12 Configurar la hoja de precios de facturación de una organización

El subcomponente de facturación de una organización requiere que los productos o servicios que se van a facturar se configuren con el recurso personalizado SKUDescription. Un solo SKUDescription describe un producto o servicio que se va a facturar junto con su precio. Por lo tanto, una colección de SKUDescription objetos se puede considerar la hoja de precios de una organización. En los pasos siguientes se configura la hoja de precios de la organización en IAC.

1.12.1 Obtener la hoja de precios

Si aún no tienes los recursos de la SKUDescription hoja de precios de una organización, ponte en contacto con la oficina de gestión de programas (PMO) para obtenerla. La hoja de precios debe ser una serie de archivos YAML que contengan recursos SKUDescription.

1.12.2. Determinar si la hoja de precios se ha compartido o no

La hoja de precios se puede compartir en todas las organizaciones o se puede configurar en cada organización. El gestor de la oficina de proyectos puede informarte de si la hoja de precios se ha compartido o no.

1.12.2.1 Hoja de precios compartida

Si la hoja de precios se comparte, colóquela en la carpeta common-data compartida de IAC.

  1. Si esta organización no es la primera que se crea, es posible que la hoja de precios ya esté en la carpeta compartida common-data. Si la hoja de precios existe, compruebe que se han seguido los pasos del 2 al 4 y vaya al paso 5.

  2. Crea la carpeta compartida para la hoja de precios.

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

    Sustituye IAC_REPO_PATH por la ruta al repositorio de IAC.

  3. Guarda los recursos YAML de la hoja de precios de SKUDescription en esta carpeta. Después, la carpeta skudescriptions debe contener archivos YAML separados por áreas. Configura la estructura de carpetas y los archivos YAML para que se ajusten a tu caso práctico de facturación:

    • Facturación gestionada por el partner: Google cobra al partner. Coloca los SKUDescription recursos en el espacio de nombres partner-billing-system.

    • Facturación del cliente: el partner cobra al usuario final. Coloca los SKUDescription recursos en el espacio de nombres billing-system.

    En los siguientes ejemplos se muestran las estructuras de archivos de los modelos de facturación de clientes y de socios. En cada modelo, verás dos servicios (computación y almacenamiento) con dos archivos YAML por servicio:

    Facturación de cliente:

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

    Facturación gestionada por el partner:

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

  4. Comprueba que haya un archivo kustomization.yaml en el directorio que incluya todos los archivos YAML de la hoja de precios 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. Exporta la variable de entorno ORG_CLUSTER:

    • En una organización de la versión 1, ejecuta el siguiente comando:

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • En una organización de la versión 2, ejecuta el siguiente comando:

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. Crea el directorio de facturación skudescriptions en la organización:

    • En una organización de la versión 1:

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

    • En una organización de la versión 2:

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

    Sustituye ORG_CLUSTER_NAME por el nombre del clúster de administrador de la organización, en función del tipo de versión de tu organización.

  7. Incluye la hoja de precios habitual en la organización:

    • En una organización de la versión 1:

      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

    • En una organización de la versión 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. Añade y confirma el archivo YAML, y personaliza los archivos:

    cd IAC_REPO_PATH
git add "iac"
git commit

  9. Envía la actualización a GitLab:

    git -c http.sslVerify=false push

  10. Espera a que se revise el código y se combine.

  11. Verifica que los objetos SKUDescription existan en el clúster correspondiente a tu modelo de facturación.

    Exporta el valor KUBECONFIG según el tipo de organización.

    • En una organización de la versión 1, ejecuta el siguiente comando:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Sustituye ORG_ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de administrador de la organización, como /tmp/${ORG}-admin-kubeconfig.

    • En una organización de la versión 2, ejecuta el siguiente comando:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Sustituye MANAGEMENT_API_SERVER_KUBECONFIG por la ruta al archivo kubeconfig del servidor de la API Management, como /tmp/${ORG}-management-kubeconfig.

    Ejecuta la CLI kubectl:

    Para la facturación de clientes:

    
kubectl get SKUDescription -n billing-system

    Para la facturación de partners:

    
kubectl get SKUDescription -n partner-billing-system

1.12.2.2. Hoja de precios específica de la organización

Si la hoja de precios es específica de una organización, debe colocarla en la carpeta del clúster de la organización.

  1. Crea el directorio de facturación skudescriptions en el clúster de la organización:

    • En una organización de la versión 1:

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

    • En una organización de la versión 2:

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

  2. Guarda los recursos YAML de la hoja de precios de SKUDescription en esta carpeta. Después, la carpeta skudescriptions debe tener archivos YAML separados por áreas. En el ejemplo siguiente, se muestran dos servicios (compute y storage) con dos archivos YAML cada uno:

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

  3. Asegúrese de que haya un archivo kustomization.yaml en el directorio que incluya todos los archivos YAML de la hoja de precios SKUDescription.

    • En una organización de la versión 1:

      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

    • En una organización de la versión 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. Asegúrate de que el archivo kustomization.yaml de la raíz de la organización tenga la carpeta bil/skudescriptions recién añadida. Consulta IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml para una organización de la versión 1 y IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml para una organización de la versión 2 :

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

  5. Fasea y confirma el archivo YAML y los archivos kustomize:

    cd IAC_REPO_PATH
git add "iac"
git commit

  6. Envía la actualización a GitLab:

    git -c http.sslVerify=false push

  7. Espera a que se revise el código y se combine.

  8. Verifica que los objetos SKUDescription existen en el clúster indicado:

    • En una organización de la versión 1, ejecuta el siguiente comando:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Sustituye ORG_ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de administrador de la organización, como /tmp/${ORG}-admin-kubeconfig.

    • En una organización de la versión 2, ejecuta el siguiente comando:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Sustituye MANAGEMENT_API_SERVER_KUBECONFIG por la ruta al archivo kubeconfig del servidor de la API Management, como /tmp/${ORG}-management-kubeconfig. .

1.13 Crear usos periódicos de facturación

Distributed Cloud ofrece códigos de mantenimiento en almacén (SKU) que generan cargos periódicos. Sin embargo, Distributed Cloud no registra los costes de uso de determinados SKUs. Para gestionar esta información, usa el recurso RecurringUsage. Para obtener más información e instrucciones sobre cómo crear usos periódicos, consulta el artículo Crear usos periódicos.

1.14 Configurar la facturación de una organización

El subcomponente de facturación no empieza a calcular los costes de una organización hasta que se alcanza la hora de inicio de la facturación. La hora de inicio de la facturación tiene el valor predeterminado 9999-01-01T00:00:00-07:00. Por lo tanto, cuando se considera que una organización está lista, el IO anula la hora de inicio de la facturación para iniciar el flujo de trabajo de facturación.

1.14.1. Obtener la hora de inicio de la facturación

La hora de inicio de la facturación debe ser el principio del periodo de cumplimiento, que se indica en el contrato. Si aún no tienes la hora de inicio de la facturación de una organización, ponte en contacto con la oficina de gestión de programas (PMO) para obtener la información.

1.14.2. Asocia una cuenta de pagos de facturación a una organización

Los entornos aislados de Google Distributed Cloud (GDC) requieren una cuenta de facturación para hacer un seguimiento de los costes de los proyectos y las organizaciones. Si no vinculas una cuenta de facturación a una organización o un proyecto, perderás los datos de costes asociados al recurso.

Para cobrar al cliente por el uso del servicio, todas las cuentas de facturación de una organización deben usar una única hoja de precios.

1.14.2.1. Antes de empezar

Antes de continuar, pide a tu administrador de seguridad que te conceda los siguientes roles obligatorios. Estos roles se vinculan al espacio de nombres del proyecto para la facturación a nivel de proyecto o al espacio de nombres de la plataforma para la facturación a nivel de organización:

  • Administrador de la cuenta de facturación de la organización: crea, gestiona y vincula el recurso BillingAccount. Pide a tu administrador de seguridad que te conceda el rol organization-billing-account-admin.

  • Usuario de cuenta de facturación de organización: lee, enumera y vincula el recurso BillingAccount. Pide a tu administrador de seguridad que te conceda el rol organization-billing-account-user.

  • Gestor de cuentas de facturación de la organización: puede leer, enumerar, crear y actualizar el recurso BillingAccountBinding. Pide a tu administrador de seguridad que te conceda el rol organization-billing-manager.

1.14.2.2. Crear una cuenta de facturación

Una cuenta de facturación se identifica de forma única por su name y su namespace. Para crear una cuenta de facturación, usa un recurso personalizado para establecer name y namespace:

  1. Crea un archivo YAML y añade el recurso personalizado BillingAccount y el siguiente contenido:

    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"

    Sustituye las siguientes variables:

    • BIL_ACCOUNT_NAME: el nombre de la cuenta de facturación. Por ejemplo. test-billing-account.
    • BIL_DISPLAY_NAME: el nombre visible de la cuenta de facturación. Por ejemplo. "Test Billing Account".

  2. Verifica el tipo de configuración de pago. Las cuentas de facturación de Distributed Cloud deben tener una de las siguientes configuraciones de pago:

    • cloudBillingConfig: la configuración de pago predeterminada. Esta configuración almacena un ID de cuenta de facturación de Cloud.

    • customConfig: una configuración personalizada para que los partners almacenen su configuración de pago para facturar a la organización. customConfig admite un diccionario de cadenas clave-valor con una clave obligatoria payment-config-type.

    En los siguientes ejemplos se muestran fragmentos de archivos BillingAccount YAML para diferentes configuraciones de pago:

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    Sustituye CLOUD_BILLING_ACCOUNT_ID por elGoogle Cloud ID de tu cuenta de facturación.

    customConfig

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

    Sustituye PAYMENT_CONFIG_TYPE por el tipo de configuración de pago que hayas elegido para tu configuración de facturación personalizada.

    Si no tienes la información de la configuración de tu organización, introduce los siguientes datos:customConfig

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

    En el siguiente archivo YAML se muestra un recurso BillingAccount completo con la configuración de 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. Guarda el archivo YAML del recurso personalizado. Ejecuta la CLI de kubectl para aplicar el recurso en el clúster de la organización o el proyecto específicos que quieras facturar:

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

Para vincular una organización a un BillingAccount, sigue estos pasos:

  1. Añade el siguiente contenido al archivo YAML billingaccountbinding.yaml:

    • En la sección billingAccountRef, rellena el campo name con el contenido del campo name del BillingAccount que quieras vincular.
    • En la sección metadata, rellena el campo namespace con el contenido del campo idéntico del recurso BillingAccount. En este ejemplo, el espacio de nombres de la organización es platform:
    apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform

  2. Aplica el archivo billingaccountbinding.yaml:

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

1.14.3 Antes de empezar

Antes de continuar, pide a tu administrador de seguridad que te conceda el rol Bil Monitor (bil-monitor) en el clúster de administrador de la organización para el espacio de nombres billing-system. Este permiso te permite leer recursos relacionados para la validación.

1.14.4. Anular la hora de inicio de la facturación

  1. Crea dos archivos YAML con las siguientes rutas:

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

      • Crea las subcarpetas necesarias para cada archivo si faltan.

  2. Añade el recurso SubcomponentOverride y el siguiente contenido a cada archivo:

    Para la facturación de clientes:

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

    • Archivo 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 la facturación gestionada por el partner:

    • Añade la marca enablePartnerBilling: true al final de cada archivo YAML:

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

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

    Sustituye las siguientes variables:

    • ORG_NAME: el nombre de la organización. Por ejemplo: org-1.

    • BILLING_START_TIME: marca de tiempo para iniciar el flujo de trabajo de facturación.La marca de tiempo debe seguir el formato RFC 3339. Por ejemplo, si el flujo de trabajo de facturación empieza el 01/01/2024 con la zona horaria del horario estándar del Pacífico de EE. UU. y Canadá (UTC-8), añade el valor de la marca de tiempo como 2024-01-01T00:00:00-08:00.

    • BILLING_TIMEZONE: la zona horaria del flujo de trabajo de facturación. La zona horaria debe seguir el formato RFC 3339. Por ejemplo, si la zona horaria de facturación es la hora estándar del Pacífico de EE. UU. y Canadá (UTC-8), añade el valor de la zona horaria como PST8PDT.

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

    • Archivo 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. Guarda y almacena los archivos YAML en la carpeta infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

  4. Crea una solicitud de extracción que contenga los archivos YAML junto con el archivo de personalización necesario.

1.14.5 Valida la hora de inicio de la facturación

Verifica que has anulado la hora de inicio de la facturación del monetizador y la generación de facturas:

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 Configurar la política de red del proxy de almacenamiento de objetos en el clúster de administración de la organización

1.15.1 Crear el archivo YAML de la política de red

Crea el archivo YAML de la política de red allow-obs-system-ingress-traffic, como networkpolicy.yaml:

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

1.15.2. Aplica la política de red al clúster de administrador de la organización

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Crear un sitio de copia de seguridad

Si aprovechas la asistencia de recuperación tras fallos, debes volver a completar los pasos anteriores para el sitio de copia de seguridad. Si no tienes habilitada la recuperación ante desastres, sáltate esta sección.

  1. Sigue las instrucciones de la sección 1.4. - 1.9. para crear otra organización para el sitio de copia de seguridad.

1.17. Solucionar problemas de creación de organizaciones

1.17.1. Confirma que todos los recursos implementados estén en buen estado y presentes

El proceso de creación de la organización crea varios recursos en diferentes clústeres de Kubernetes. Primero, comprueba los recursos implementados y asegúrate de que estén en buen estado. En las siguientes secciones se describen los recursos creados para una organización llamada operations.

1.17.2. Confirmar todos los recursos implementados en el clúster de administrador raíz

Sigue estos pasos para confirmar que todos los recursos del clúster de administrador raíz están en buen estado y presentes:

  1. Para obtener la configuración de kubeconfig necesaria para el clúster de administrador raíz, sigue las instrucciones de IAM-R0004. Asegúrate de definir las siguientes variables de entorno y alias para estas instrucciones de verificación:

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

  2. Confirma que los recursos del cortafuegos están disponibles:

    1. Establece una conexión SSH con el cortafuegos y confirma que se ha creado un nuevo vsys:

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

      El resultado debería ser similar al siguiente:

      vsys1 {
vsys2 {

    2. Consulta el recurso FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system

      El resultado debería ser similar al siguiente:

      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. Confirma que los recursos de almacenamiento están disponibles:

    1. Consulta el recurso StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system

      El resultado debería ser similar al siguiente:

      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. Confirma que los recursos de HSM están disponibles:

    1. Comprueba los HSMs:

      k get hsms -n gpc-system

      El resultado debería ser similar al siguiente:

      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. Comprueba el clúster de HSM:

      k get hsmcluster -n gpc-system

      El resultado debería ser similar al siguiente:

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

    3. Comprueba el tenant del HSM:

      k get hsmtenant -A

      El resultado debería ser similar al siguiente:

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

  5. Confirma que los recursos de la máquina y del nodo están disponibles:

    1. Consulta los AddressPoolClaimrecursos:

      k get addresspoolclaims -A

      El resultado debería ser similar al siguiente:

      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. Consulta los NodePoolClaimrecursos:

      k get nodepoolclaims -A

      El resultado debería ser similar al siguiente:

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

    3. Consulta los NodePoolrecursos:

      k get nodepool -A

      El resultado debería ser similar al siguiente:

      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. Comprueba los clústeres de Bare Metal:

      k get baremetalclusters -A

      El resultado debería ser similar al siguiente:

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

    5. Comprueba las máquinas físicas:

      k get baremetalmachines -A

      El resultado debería ser similar al siguiente:

      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. Comprueba los servidores. Están en estado provisioned:

      k get servers -n gpc-system | grep provisioned

      El resultado debería ser similar al siguiente:

      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. Comprueba el clúster de Kubernetes:

      k get cluster -A

      El resultado debería ser similar al siguiente:

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

    8. Comprueba los secretos de kubeconfig:

      k get secrets -A | grep kubeconfig

      El resultado debería ser similar al siguiente:

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

1.17.3. Confirmar todos los recursos implementados en los clústeres de organización de la versión 1

Sigue estos pasos para confirmar que todos los recursos del clúster de administrador de la organización y del clúster del sistema de una organización v1 están en buen estado y presentes. Si tienes una organización de la versión 2, ve a la siguiente sección.

1.17.3.1. Confirmar todos los recursos implementados en un clúster de administrador de organización

  1. Para obtener la configuración de kubeconfig necesaria para el clúster de administrador raíz, sigue las instrucciones de IAM-R0004. Asegúrate de definir las siguientes variables de entorno y alias para estas instrucciones de verificación:

    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. Confirma que los recursos de la máquina y del nodo están disponibles:

    1. Comprueba los clústeres de Bare Metal:

      ka get baremetalclusters -A

      El resultado debería ser similar al siguiente:

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

    2. Comprueba las máquinas físicas:

      ka get baremetalmachines -A

      El resultado debería ser similar al siguiente:

      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. Comprueba las máquinas:

      ka get machines -A

      El resultado debería ser similar al siguiente:

      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. Consulta los VirtualmachinesInstancerecursos:

      ka get virtualmachineinstances -A

      El resultado debería ser similar al siguiente:

      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. Consulta los NodePoolrecursos:

      ka get nodepools -A

      El resultado debería ser similar al siguiente:

      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. Comprueba los clústeres de Kubernetes:

      ka get clusters -A

      El resultado debería ser similar al siguiente:

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

    7. Comprueba los nodos:

      ka get nodes -A

      El resultado debería ser similar al siguiente:

      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. Comprueba los secretos de kubeconfig:

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

      El resultado debería ser similar al siguiente:

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

1.17.3.2. Confirma todos los recursos implementados en el clúster de usuarios del sistema

Sigue estos pasos para confirmar que todos los recursos del clúster del sistema están en buen estado y presentes:

  1. Para obtener la configuración de kubeconfig necesaria para el clúster de administrador raíz, sigue las instrucciones de IAM-R0004. Asegúrate de definir las siguientes variables de entorno y alias para estas instrucciones de verificación:

    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. Confirma que los recursos de la máquina y del nodo están disponibles:

    1. Consulta el recurso VirtualmachineInstance:

      ku get vmi -A

      El resultado es similar al siguiente (si se ha creado un clúster de usuarios):

      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. Comprueba los nodos:

      ku get nodes

      El resultado debería ser similar al siguiente:

      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. Comprueba las asignaciones de GPU:

      ku get gpuallocations -A

      El resultado debería ser similar al siguiente:

      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. Confirmar todos los recursos implementados en los clústeres de organización de la versión 2

Sigue estos pasos para confirmar que todos los recursos del clúster de infraestructura de la organización de una organización de la versión 2 están en buen estado y presentes. Si tienes una organización de la versión 1, omite esta sección.

  1. Para obtener la configuración de kubeconfig necesaria para el clúster de administrador raíz, sigue las instrucciones de IAM-R0004. Asegúrate de definir las siguientes variables de entorno y alias para estas instrucciones de verificación:

    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. Confirma que los nodos y los servidores de la API estén en buen estado:

    1. Comprueba los nodos:

      ka get nodes -A

      El resultado debería ser similar al siguiente:

      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. Comprueba los secretos de kubeconfig:

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

      El resultado debería ser similar al siguiente:

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

  3. Comprueba las asignaciones de GPU para confirmar que los recursos de GPU están listos, si procede:

    ka get gpuallocations -A

    El resultado debería ser similar al siguiente:

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

1.17.5. Confirmar que todos los recursos de la organización se han conciliado

Sigue estos pasos para confirmar que todos los recursos relacionados con la organización del clúster de administrador raíz global y zonal están en buen estado y presentes, suponiendo que el objetivo sea crear una organización operations con dos zonas: zone-1 y zone-2.

  1. Sigue los pasos que se indican en Acceder a la API de administrador raíz global para acceder al servidor de la API global y usa el siguiente alias para la API kubectl de administrador raíz global.

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

  2. Confirma que los recursos de organización globales están disponibles:

    1. Consulta los recursos globales de Organization:

      kga get organization -A

      El resultado debería ser similar al siguiente:

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. Consulta los recursos globales de OrganizationReplica:

      kga get organizationreplica -A

      El resultado debería ser similar al siguiente:

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

    3. Consulta los recursos globales de OrganizationZonalConfig:

      kga get organizationzonalconfig -A

      El resultado debería ser similar al siguiente:

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

    4. Consulta los recursos globales de OrganizationZonalConfigReplica:

      kga get organizationzonalconfigreplica -A

      El resultado debería ser similar al siguiente:

      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. Define el alias de configuración de kubeconfig del clúster de administrador raíz zonal:

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

  4. Confirma que los recursos de organización zonales están disponibles:

    1. Consulta los Organizationrecursos:

      ka get organization -A

      El resultado debería ser similar al siguiente:

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

    2. Consulta los OrganizationReplicarecursos:

      ka get organizationreplica -A

      El resultado debería ser similar al siguiente:

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

    3. Consulta los OrganizationZonalConfigReplicarecursos:

      ka get organizationzonalconfigreplica -A

      El resultado debería ser similar al siguiente:

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

  5. Sigue los pasos que se indican en Permitir que cualquier dirección acceda a una organización para permitir el tráfico de DCI en los clústeres de administrador de la organización desde el sitio de origen hasta el sitio de copia de seguridad.