1. Crear organización del cliente

Tiempo estimado para completar la actividad: 3 horas

Perfil de habilidad: ingeniero de implementación

Como operador, puedes crear una organización para brindar acceso a los clientes a la infraestructura de la plataforma. Para obtener los permisos que necesitas para crear una organización, pídele a tu administrador de seguridad que te otorgue el rol de administrador de la organización.

El recurso Organization es el nodo raíz de la jerarquía de recursos aislados de Google Distributed Cloud (GDC), y todos los recursos que pertenecen a una organización se agrupan en el nodo de organización. Esto proporciona visibilidad central y control sobre cada recurso que pertenece a una organización.

Para obtener más información sobre las organizaciones, consulta la Descripción general de la organización.

1.1. Antes de comenzar

Asegúrate de haber instalado lo siguiente:

  • Un navegador en tu sistema

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

  • La CLI de kubectl

  • Es la CLI de gcloud.

1.2. Crea un cliente de OIDC en OC IT ADFS

  1. Consulta las instrucciones de configuración de OIDC de ADFS para crear un cliente de OpenID Connect (OIDC) en ADFS para que el operador acceda a la organización que crearás. Registra el ID de cliente y el secreto del 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 la organización, o servicios como ServiceNow.

  2. Agrega la siguiente URL de devolución de llamada de GKE Identity Service a la lista de entidades permitidas en el cliente de OIDC de ADFS que creaste 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 devolución de llamada de GKE Identity Service es https://ais-core.operations.google.gdch.test/finish-login.

  3. Agrega la siguiente URL de devolución de llamada de GKE Identity Service a la lista de entidades permitidas en el cliente de OIDC de ADFS que creaste 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 devolución de llamada de GKE Identity Service es https://ais-core.operations.zone-1.google.gdch.test/finish-login.

  4. Configura 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

    Reemplaza las variables por los siguientes valores:

    VariableDefinición
    ADFS_CERT_BASE64 Es el archivo adfs.pem codificado en base64.
    ADFS_CLIENT_ID Es el identificador del cliente de ADFS.
    ADFS_CLIENT_SECRET Es el secreto compartido del cliente de ADFS.
    ADFS_ISSUER_URI Es el URI de la entidad emisora de ADFS. Para obtener el URI, verifica la ruta de acceso /adfs/.well-known/openid-configuration del servidor de 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, debes crear las subredes raíz globales y dividirlas para cada zona con la subred de la API pública de administración de direcciones IP (IPAM). Si creas una organización de la versión 2 nueva en una zona que antes tenía una organización de la versión 1, asegúrate de consultar la página de requisitos previos adicionales antes de crear tus subredes globales.

Las subredes raíz globales alojan el grupo de rangos de direcciones IP raíz (CIDR) que se divide en cada zona para iniciar todos los clústeres dentro de la organización del arrendatario, incluido el clúster de infraestructura de la organización y las VMs de carga de trabajo. Una pequeña parte del rango de direcciones IP también está disponible para las subredes raíz como el grupo de direcciones IP de difusión para todos. Puedes asignar automáticamente CIDR dedicados a cada zona con un controlador o proporcionar CIDR a cada zona de forma manual.

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

Debes crear diferentes subredes raíz 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 proporcionan en la siguiente sección.

1.3.1. Define el rango de CIDR para OIQ

Los rangos de CIDR no pueden superponerse entre sí ni con zone-infra-cidr.

El zone-infra-cidr existe en cada zona y se puede recuperar del Cuestionario de admisión del cliente (CIQ) si el cliente lo definió.

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 del resultado 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, el zone-infra-cidr es 192.0.2.0/24, por lo que ningún campo del OIQ debe superponerse con 192.0.2.0/24.

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

Campo de OIQ Descripción Tamaño mínimo requerido Tamaño mínimo por zona para la organización Nombre de la subred raíz global Servidor de la API global
infraVPCCIDR Cargas de trabajo del sistema, incluidas la consola de la organización, las APIs de administración y los servicios propios. \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr Raíz global
defaultVPCCIDR Cargas de trabajo y extremos del usuario en la VPC predeterminada en todas las zonas. \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr Organización global
orgAdminExternalCIDR Son las cargas de trabajo y los extremos del clúster perimetral que controlan 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 extremos a los que los usuarios pueden acceder de forma externa, como los balanceadores de cargas externos y los NAT de salida. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr Raíz global

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

Ten en cuenta las siguientes limitaciones para los rangos de subredes IPv4:

  • orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR y defaultVPCCIDR no deben superponerse entre sí, con otros rangos asignados dentro de la organización ni con ningún rango IPv4 en las redes interconectadas. Los CIDR de estos rangos provienen del espacio de direcciones privadas de RFC 1918.

    Redes con intercambio de tráfico: Pueden ser cualquier subred anunciada con redes externas a través de adjuntos de interconexión o subredes que tengan intercambio de tráfico con otras VPC en 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. Crea subredes globales en el servidor de la API del 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 el clúster de 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 asignarás a tu organización. Confirma que este espacio de nombres exista:

    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, por ejemplo, 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, por ejemplo, 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, por ejemplo, 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 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 en la raíz de la organización tenga las definiciones Subnet agregadas recientemente. Verifica 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. Confirma y prepara los archivos YAML de la subred:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. Crea una solicitud de combinación:

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

  9. Espera la revisión de código y la combinación.

1.3.3. Divide las subredes raíz para las zonas

Las subredes raíz globales alojan el rango de direcciones IP raíz (CIDR) para todas las zonas. Para consumir el rango de direcciones IP en la zona, primero se deben dividir las subredes raíz globales en subredes más pequeñas para que las zonas las puedan consumir. Cada zona debe tener al menos un rango 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 los controladores de IPAM para que dividan automáticamente la subred de la zona si no les importa el bloque CIDR exacto que usa una zona determinada. El controlador supervisa 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 la zona Longitud de prefijo fijo predeterminada
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

Las subredes raíz globales deben tener nombres fijos si deseas 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 configuras 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. Divide automáticamente las subredes raíz para las zonas

El controlador global divide automáticamente la subred raíz global en subredes más pequeñas para las zonas existentes. Por ejemplo, considera el siguiente flujo de trabajo para comprender cómo el controlador divide 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 se ve de la siguiente manera:

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. Divide manualmente las subredes raíz para las zonas

En esta sección, se supone que estableciste la anotación ipam.gdc.goog/pause-auto-division: true cuando creaste las subredes raíz globales en el servidor de la API de administrador raíz global. Esta anotación pausa el controlador para conciliar esas subredes raíz globales, lo que te permite crear manualmente la subred raíz de una zona y la subred de difusión para todos.

Para dividir manualmente la subred raíz global en subredes más pequeñas para las zonas, completa los siguientes pasos:

  1. Enumera 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 deseas aplicar a tu zona. Haz esto para 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 para cada zona de tu universo de GDC.

  4. Confirma el CIDR dedicado de la subred raíz que deseas aplicar a la subred de difusión para todos.

  5. Asigna el CIDR dedicado a la subred de difusión por Anycast 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 tuvieras 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 en la raíz de la organización tenga las definiciones Subnet agregadas recientemente. Verifica 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. Confirma y prepara 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 la revisión de código y la combinación.

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

Si hay dos zonas llamadas zone1 y zone2, un ejemplo de subred raíz global infra-vpc-root-cidr que usa infraVPCCIDR, como 192.0.2.0/24, del OIQ en el espacio de nombres org-1 se ve de la siguiente manera:

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 para cada zona llamada infra-vpc-zone1-root-cidr y infra-vpc-zone2-root-cidr, y la subred de difusión por 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 agregar todos los archivos YAML de subred al repositorio de IaC.

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

Si hay dos zonas llamadas zone1 y zone2, un ejemplo de subred raíz global data-external-root-cidr que usa orgDataExternalCIDR, como 10.0.0.0/24, del OIQ en el espacio de nombres org-1 se ve de la siguiente manera:

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 para cada zona llamada data-external-zone1-root-cidr y data-external-zone2-root-cidr, y la subred de difusión por 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 agregar todos los archivos YAML de subred al repositorio de IaC.

1.3.3.2.3. Ejemplo de división manual de subredes raíz para zonas en el segmento de red de administración

Si hay dos zonas llamadas zone1 y zone2, un ejemplo de subred raíz global admin-external-root-cidr que usa orgAdminExternalCIDR, como 192.168.1.0/24, del OIQ en el espacio de nombres org-1 se ve de la siguiente manera:

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 para cada zona llamada admin-external-zone1-root-cidr y admin-external-zone2-root-cidr, y la subred de difusión a cualquier dirección 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 agregar todos los archivos YAML de subred al repositorio de IaC.

1.4. Crea una organización con IAC

Usa la IAC para crear una organización:

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

    El ejemplo de salida es similar al 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 satisfacer la solicitud.

  2. Navega al repositorio iac y agrega la estructura de directorios para 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

    Reemplaza las siguientes variables:

    VariableDefinición
    ORG_NAME Es el nombre de la organización. El nombre de una organización debe cumplir con los siguientes criterios:
    • Debe tener entre 3 y 19 letras ASCII en minúscula, dígitos o guiones.
    • Comienza con una letra.
    • No deben tener guiones finales.
    • No debe terminar con la cadena -system.
    LOG_RETENTION_POLICY Es la configuración de los tiempos de retención para 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 encriptar las claves que genera el KMS. De forma predeterminada, el KMS genera una clave raíz de CTM, una clave raíz almacenada en Thales CipherTrust Manager respaldada por un HSM físico. También puedes elegir una clave raíz de software almacenada como un secreto de Kubernetes. Pasa ctm-root o local-root para kmsRootKeyType.

    Un ejemplo del archivo YAML del recurso personalizado Organization 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, la encriptación IPsec de nodo a nodo está inhabilitada de forma predeterminada. Si se requiere esta encriptación IPsec, puedes habilitar la encriptación IPsec de nodo a nodo editando el archivo YAML de recursos personalizados Organization y agregando una anotación:

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

    El valor "false" para esta anotación habilita el encriptado.

  5. Crea un recurso personalizado OrganizationZonalConfig 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

    Reemplaza las siguientes variables:

    VariableDefinición
    ORG_NAME Es el nombre de la organización. El nombre de una organización debe cumplir con los siguientes criterios:
    • Debe tener entre 3 y 30 letras ASCII en minúscula, dígitos o guiones.
    • Comienza con una letra.
    • No deben tener guiones finales.
    • No debe terminar con la cadena -system.
    ZONES Nombres de las zonas en la implementación.
    GDC_VERSION Es la versión del sistema de GDC para la que se creará la organización.
    SERVER_QUOTA Son 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 planeas ejecutar recursos de unidades de procesamiento de gráficos (GPU) que sean cargas de trabajo basadas en VM, como APIs de inteligencia artificial y aprendizaje automático (IA/AA) previamente entrenadas, debes aprovisionar máquinas con GPU cuando crees una organización. Para obtener más información, consulta la sección Cómo habilitar la compatibilidad con GPU para clústeres del sistema.
    ADMIN_SERVER Es un par clave-valor del tipo de servidor y la cantidad de servidores de administrador de la organización que se asignarán para ese tipo de servidor. No se admiten tipos mixtos para los servidores. El valor predeterminado es o1-standard1-64-gdc-metal: 3.
    STORAGE_SIZE Es el tamaño de los diferentes tipos de almacenamiento que se asignarán a la organización. El tamaño mínimo de almacenamiento en bloque para una organización es de 250 GiB, que se establece con la marca BlockStandard.

    Un ejemplo del archivo YAML del recurso personalizado OrganizationZonalConfig 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 organizaciones nuevas se aprovisionan según el tipo de implementación que se establece en la configuración de la puerta de funciones:

      • 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 poco frecuente en que debas anular el tipo de organización predeterminado para tu tipo de implementación, actualiza el campo spec.compatibilityOptions.architectureOverridePolicy en tu recurso personalizado Organization generado a ForceV1 o ForceV2, según el tipo de organización que desees usar. Por ejemplo, el siguiente fragmento 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 parámetros de configuración restantes para asegurarte de que los componentes, como el almacenamiento y la potencia de procesamiento, sean 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/

    Reemplaza lo siguiente:

    • ORG_NAME: Es el nombre de la organización que definiste en el comando gdcloud organizations config create con el parámetro --name.
    • ZONE: Es el nombre de cada zona en 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 Zona del cuestionario de admisión de clientes para obtener descripciones de los valores del atributo de zona.

  8. Agrega el archivo kustomization.yaml para 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. Agrega la nueva organización como recurso de la organización raíz:

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

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

    2. Agrega el nuevo Organization como un recurso al final de la lista de recursos existente:

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

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

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. Crea una solicitud de combinación:

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

  12. Espera la revisión de código y la combinación.

  13. Verifica que estén disponibles la organización global y las configuraciones zonales:

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

      kubectl get organization -A

      El resultado es similar a este:

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

    2. Verifica 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 en el resultado de YAML sean True.

    3. Verifica 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 acceder a cada zona antes de verificar el estado de la organización. Asegúrate de que las condiciones status en el resultado de YAML para cada zona sean True.

1.5. Crea 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 para los clústeres dentro de la organización del arrendatario, como los clústeres de usuario, así como las direcciones IP para las cargas de trabajo de VM.

  1. Crea el archivo YAML de la subred default-vpc-root-cidr, por ejemplo, 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. Navega al repositorio iac y agrega la estructura de directorios para 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 en el 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 recién agregadas. Verifica 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. Agrega 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 la revisión de código y la combinación.

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

1.7. Configura org-admin NTPRelay

Debes configurar manualmente la autenticación entre los objetos NTPRelay de root-admin y org-admin.

Sigue NTP-P0001.3 (Administrador raíz -> Administrador de la organización: Encriptación de NTPRelay) para configurar la encriptación de esta organización.

1.8. Conecta el proveedor de identidad 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 del cliente de OIDC.

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

    export ORG_NAME=ORG_NAME

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

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

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

  4. Agrega el archivo ioauthmethod.yaml para 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

    Reemplaza las siguientes variables:

    VariableDefinición
    ADFS_CERT_BASE64 Es la codificación en base64 del certificado que usa ADFS para autofirmar, que GKE Identity Service requiere para establecer una conexión segura con una instancia interna de ADFS.
    ADFS_ORG_CLIENT_ID Es el ID de OpenID Connect para el cliente de la organización en ADFS.
    ADFS_ORG_CLIENT_SECRET El secreto de OpenID Connect para el cliente de la organización registrado en ADFS.
    ADFS_ISSUER_URI Un URI de emisor válido, que GKE Identity Service requiere para permitir solicitudes de acceso con redireccionamiento a ADFS.

  5. Agrega el archivo initial-admin.yaml para 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

    Reemplaza las siguientes variables:

    VariableDefinición
    USER Nombre de usuario con el prefijo de la IO para acceder al clúster inicialmente. Recuerda agregar el prefijo al nombre de usuario.
    EXPIRATION Es la 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. Agrega 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. Agrega 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 la revisión de código y la combinación.

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

    1. Configura el archivo kubeconfig del clúster de administrador según la arquitectura de tu organización:

      • Para una organización de la versión 1, ejecuta lo siguiente:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

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

      • Para una organización de la versión 2, ejecuta lo siguiente:

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        Reemplaza 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. Verifica que exista 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, debes aplicar manualmente el rol global-zone-viewer para permitir que todos los usuarios autenticados vean las zonas en un universo con 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

    Reemplaza 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 Cómo generar manualmente el archivo kubeconfig.

1.9. Conecta el proveedor de identidad del cliente a la organización

Para conectar un proveedor de identidad (IdP) del cliente a la organización y acceder a ella con sus identidades, completa los siguientes pasos:

  1. Accede desde la CLI con la cuenta de administrador de IO inicial establecida 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. Pídele al cliente que agregue la siguiente URL de devolución de llamada global de la AIS a la lista de entidades permitidas en el cliente de OIDC o SAML que creó 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 devolución de llamada global de la AIS es https://ais-core.operations.google.gdch.test/finish-login.

    Si usas un cliente de SAML, también debes agregar la siguiente URL de devolución de llamada de SAML global de AIS a la lista de entidades permitidas:

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

  3. Pídele al cliente que agregue la siguiente URL de devolución de llamada de la AIS a la lista de entidades permitidas en el cliente de OIDC o SAML que creó para cada zona. Por ejemplo, para un universo de tres zonas, las URLs de devolución de llamada de la 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 devolución de llamada de AIS es https://ais-core.operations.zone-1.google.gdch.test/finish-login.

    Si usas un cliente de SAML, también debes agregar las siguientes URLs de devolución de llamada de SAML de la AIS a la lista de entidades permitidas para 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. Configura el archivo kubeconfig del clúster de administrador según la arquitectura de tu organización. Si ya configuraste tu variable kubeconfig, omite este paso.

    • Para una organización de la versión 1, ejecuta lo siguiente:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

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

    • Para una organización de la versión 2, ejecuta lo siguiente:

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

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

  5. En el ticket de solicitud del cliente para una organización nueva, decide si el IdP usa OIDC o SAML. Sigue la guía que se asigna al tipo de IdP determinado:

Configuración con OIDC

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

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

  2. A continuación, se incluyen las descripciones detalladas de los campos:

    Atributo Tipo de atributo Descripción
    certificateAuthorityData Obligatorio Un certificado de autoridad certificadora con formato PEM y codificado en base64 estándar para el proveedor de OIDC.
    clientID Obligatorio Es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID.
    clientSecret Obligatorio Es el secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC.
    extraParams Opcional Una lista separada por comas de pares clave-valor que se codifican como consulta y se envían con la solicitud del extremo de autenticación.
    groupPrefix Opcional Es el prefijo que se antepone al reclamo de grupos para evitar conflictos con los grupos existentes. Por lo general, se usa cuando se configuran varios proveedores de identidad.
    Debes incluir el prefijo de grupo antes de todos los nombres de grupos. Por ejemplo, si tienes myprefix- como prefijo de grupo y un grupo llamado groupA en tu proveedor de identidad, cuando agregues una política o una vinculación, debes vincular myprefix-groupA. El nombre del grupo se establece en el campo groupsClaim.
    groupsClaim Opcional Es el nombre de la reclamación en el token de ID de OIDC que contiene la información de los grupos del usuario. Este nombre debe ser el mismo que el de la reclamación que contiene información sobre la membresía de grupo en tu proveedor de OIDC.
    issuerURI Obligatorio Es 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 Es una lista de identificadores separados por comas para especificar qué privilegios de acceso se solicitan, además del permiso openid.
    userClaim Obligatorio Nombre de la reclamación en el token de ID de OIDC que contiene el nombre de usuario. Por ejemplo, si la reclamación del usuario es email, los usuarios se identifican por el campo de usuario en el token de OIDC.
    Si esto falta en el token de ID, la autenticación fallará.
    userPrefix Opcional Es el prefijo que se antepone a las reclamaciones de usuario para evitar conflictos con los nombres de usuario existentes. Por lo general, se usa cuando se configuran varios proveedores de identidad.
    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 usa para distinguir entre diferentes proveedores de identidad.
    Se recomienda insertar un separador al final del prefijo, como se describió anteriormente en esta tabla para establecer groupPrefix.

  3. Opcional: Si tu proveedor de identidad usa atributos personalizados, primero configura los atributos en tu IdP. Luego, agrega los pares clave-valor correspondientes en la sección oidc del archivo identity-provider-config.yaml para incluir declaraciones adicionales sobre los usuarios o grupos, como su departamento o cumpleaños. Cuando aplicas los cambios a la configuración del proveedor de identidad, GKE Identity Service reconoce los atributos personalizados. A continuación, se muestra un ejemplo de atributos personalizados:

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

  4. Configura el proveedor de identidad:

    kubectl apply -f identity-provider-config.yaml

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

  6. Para verificar la configuración, abre la consola de la IU del administrador de la plataforma en un navegador web. En la página de redireccionamiento, selecciona Log in with pa-idp-oidc. Si se te redirecciona a la instancia del IdP de la cuenta de PA y, luego, se te redirecciona a la página de la consola de la IU del administrador de la plataforma después de acceder con la instancia del IdP de la cuenta de PA, la configuración se realizó correctamente. De lo contrario, verifica los valores en identity-provider-config.yaml y vuelve a aplicar el paso anterior.

Configuración con SAML

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

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

  2. A continuación, se incluyen las descripciones detalladas de los campos:

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

  3. Opcional: Si tu proveedor de identidad usa atributos personalizados, primero configura los atributos en tu IdP. Luego, agrega los pares clave-valor correspondientes en la sección saml del archivo identity-provider-config.yaml para incluir declaraciones adicionales sobre los usuarios o grupos, como su departamento o cumpleaños. Cuando aplicas los cambios a la configuración del proveedor de identidad, GKE Identity Service reconoce los atributos personalizados. A continuación, se muestra un ejemplo de atributos personalizados:

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

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

    kubectl apply -f identity-provider-config.yaml

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

  6. Para verificar la configuración, abre la consola de la IU del administrador de la plataforma en un navegador web. Selecciona Log in with pa-idp-oidc en la página de redireccionamiento. Si se te redirecciona a la instancia del IdP de la cuenta de PA y, luego, se te redirecciona a la página de la consola de la IU del administrador de la plataforma después de acceder con la instancia del IdP de la cuenta de PA, la configuración se realizó correctamente. De lo contrario, verifica los valores en identity-provider-config.yaml y vuelve a aplicar el paso anterior.

Prefijo de usuario y grupo

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

Para decidir el valor del prefijo, haz lo siguiente:

  • Incluye el nivel de la jerarquía (raíz, organización, proyecto).
  • Incluye el nombre del IdP (adfs, keycloak).
  • Se recomienda agregar un carácter separador, como -, como sufijo, ya que no se agrega ningún separador entre el prefijo y el nombre de usuario.

Asigna un administrador inicial

Para otorgarle acceso inicial a la organización, se le debe asignar el rol de administrador de la organización. Para asignar la PA 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 Establece la conectividad de red para 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 esté operativa, debes conectarla a una o más redes externas con el servicio de Interconnect.

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

Caso 1: Cómo adjuntar una organización a una interconexión compartida existente

Si tienes una interconexión existente para una red compartida, solo debes 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 YAML AttachmentGroup y agrega la nueva organización a la lista spec.entities. En el caso de una organización de la versión 2, debes especificar la red domainType (OrgAdmin, OrgData o OrgMixed) a la que deseas conectarte.

    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 RoutePolicy: Un RoutePolicy define qué prefijos de IP se anuncian. Edita la política y agrega las subredes de IP externas de la organización nueva a spec.out.ipPrefixList. Esto permite que el tráfico entrante llegue 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 en tu proceso de infraestructura como código (IaC).

Situación 2: Cómo crear una interconexión dedicada nueva

En el caso de 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 elemento InterconnectLink para cada conexión física nueva.
  2. Crea un InterconnectGroup para agrupar los vínculos físicos y permitir la nueva organización.
  3. Crea un AttachmentGroup y especifica la organización nueva en la lista entities.
  4. Crea un objeto RoutePolicy que permita los prefijos de IP entrantes y salientes para esta conexión dedicada.
  5. Crea uno o más recursos InterconnectAttachment para definir las VLAN 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 Configura 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 Configura la hoja de precios de facturación para la organización

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

1.12.1 Obtén la hoja de precios

Si aún no tienes los recursos de la hoja de precios SKUDescription para una organización, comunícate con la Oficina de Administración de Programas (PMO) para obtener la hoja de precios. La hoja de precios debe ser una serie de archivos YAML que contengan recursos SKUDescription.

1.12.2 Determina si la hoja de precios se comparte o no

La hoja de precios se puede compartir con todas las organizaciones o se puede configurar para cada organización. La PMO puede informarte si la hoja de precios se comparte o no.

1.12.2.1 Hoja de precios compartida

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

  1. Si esta organización no es la primera que se crea, es posible que la hoja de precios ya exista en la carpeta compartida common-data. Si existe, verifica que se hayan seguido los pasos del 2 al 4 y continúa con el paso 5.

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

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

    Reemplaza IAC_REPO_PATH por la ruta de acceso al repositorio de IAC.

  3. Guarda los recursos YAML de la hoja de precios SKUDescription en esta carpeta. Luego, la carpeta skudescriptions debe contener archivos YAML separados por área. Configura la estructura de carpetas y los archivos YAML para que se alineen con tu caso de uso de facturación:

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

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

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

    Facturación del cliente:

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

    Facturación operada por el socio:

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

  4. Verifica 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:

    • Para una organización de la versión 1, ejecuta lo siguiente:

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • Para una organización de la versión 2, ejecuta lo siguiente:

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

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

    • Para una organización de la versión 1, haz lo siguiente:

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

    • Para una organización de la versión 2, haz lo siguiente:

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

    Reemplaza ORG_CLUSTER_NAME por el nombre del clúster de administrador de la organización, según el tipo de versión de tu organización.

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

    • Para una organización de la versión 1, haz lo siguiente:

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

    • Para una organización de la versión 2, haz lo siguiente:

      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. Agrega 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 la revisión de código y la combinación.

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

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

    • Para una organización de la versión 1, ejecuta lo siguiente:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

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

    • Para una organización de la versión 2, ejecuta lo siguiente:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

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

    Ejecuta la CLI de kubectl:

    Para la facturación del cliente:

    
kubectl get SKUDescription -n billing-system

    Para la facturación de socios:

    
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 para una organización, debes 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:

    • Para una organización de la versión 1, haz lo siguiente:

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

    • Para una organización de la versión 2, haz lo siguiente:

      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. Luego, la carpeta skudescriptions debe tener archivos YAML separados por área. En el siguiente ejemplo, 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úrate de que haya un archivo kustomization.yaml en el directorio que incluya todos los archivos YAML de la hoja de precios SKUDescription.

    • Para una organización de la versión 1, haz lo siguiente:

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

    • Para una organización de la versión 2, haz lo siguiente:

      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 en la raíz de la organización tenga la carpeta bil/skudescriptions agregada recientemente. Verifica 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. Agrega y confirma el archivo YAML y los archivos de 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 la revisión de código y la combinación.

  8. Verifica que los objetos SKUDescription existan en el clúster determinado:

    • Para una organización de la versión 1, ejecuta lo siguiente:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

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

    • Para una organización de la versión 2, ejecuta lo siguiente:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

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

1.13 Crea usos recurrentes de facturación

Distributed Cloud ofrece unidades de mantenimiento de inventario (SKU) que generan cargos recurrentes. Sin embargo, Distributed Cloud no realiza un seguimiento de los costos de uso de ciertos SKU. Para administrar esa información, usa el recurso RecurringUsage. Para obtener detalles e instrucciones sobre cómo crear usos recurrentes, consulta Crea usos recurrentes.

1.14 Configura la facturación para una organización

El subcomponente de facturación no comienza a calcular el costo 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 un valor predeterminado de 9999-01-01T00:00:00-07:00. Por lo tanto, después de que se considera que una organización está lista, el IO anula la hora de inicio de la facturación para comenzar el flujo de trabajo de facturación.

1.14.1 Obtén la hora de inicio de la facturación

La hora de inicio de la facturación debe ser al comienzo del período de ejecución, que está disponible en tu contrato. Si aún no tienes la fecha de inicio de la facturación de una organización, comunícate con la Oficina de Administración de Programas (PMO) para obtener la información.

1.14.2 Asocia una cuenta de pago 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 costos 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 costos asociados al recurso.

Para cobrarle al cliente el uso del servicio, todas las cuentas de facturación de una organización usan una sola hoja de precios.

1.14.2.1 Antes de comenzar

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

  • Administrador de la cuenta de facturación de la organización: Crea, administra y vincula el recurso BillingAccount. Pídele a tu administrador de seguridad que te otorgue el rol de organization-billing-account-admin.

  • Usuario de la cuenta de facturación de la organización: Puede leer, enumerar y vincular el recurso BillingAccount. Pídele a tu administrador de seguridad que te otorgue el rol de organization-billing-account-user.

  • Administrador de cuentas de facturación de la organización: Puede leer, enumerar, crear y actualizar el recurso BillingAccountBinding. Pídele a tu administrador de seguridad que te otorgue el rol de organization-billing-manager.

1.14.2.2 Crea una cuenta de facturación nueva

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

  1. Crea un archivo YAML y agrega 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"

    Reemplaza las siguientes variables:

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

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

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

    • customConfig: Es una configuración personalizada para que los socios almacenen su configuración de pagos y facturen 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 YAML de BillingAccount para diferentes configuraciones de pago:

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    Reemplaza CLOUD_BILLING_ACCOUNT_ID por el ID de tu cuenta de facturación deGoogle Cloud .

    customConfig

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

    Reemplaza PAYMENT_CONFIG_TYPE por el tipo de configuración de pagos que elegiste para tu configuración de facturación personalizada.

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

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

    En el siguiente archivo YAML, se muestra un recurso BillingAccount completo con la configuración 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 para la organización o el proyecto específicos que deseas facturar:

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

Para vincular una organización a un BillingAccount, haz lo siguiente:

  1. Agrega el siguiente contenido al archivo YAML billingaccountbinding.yaml:

    • En la sección billingAccountRef, completa el campo name con el contenido del campo name en el BillingAccount que deseas vincular.
    • En la sección metadata, completa el campo namespace con el contenido del campo idéntico en el 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 comenzar

Antes de continuar, pídele a tu administrador de seguridad que te otorgue el rol de 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 Anula la hora de inicio de la facturación

  1. Crea dos archivos YAML con las siguientes rutas de acceso:

    • 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 los subdirectorios necesarios para cada archivo si faltan.

  2. Agrega el recurso SubcomponentOverride y el siguiente contenido a cada archivo:

    Para la facturación del cliente:

    • 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 operada por el socio:

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

    Reemplaza las siguientes variables:

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

    • BILLING_START_TIME: Es la 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 comienza el 1/1/2024 con la zona horaria del horario estándar del Pacífico de EE.UU. y Canadá (UTC-8), agrega el valor de la marca de tiempo como 2024-01-01T00:00:00-08:00.

    • BILLING_TIMEZONE: Es 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), agrega 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 hayas anulado la hora de inicio de la facturación para el 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 Configura la política de red del proxy de almacenamiento de objetos en el clúster de administrador de la organización

1.15.1 Crea 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. Crea un sitio de copia de seguridad

Si aprovechas la asistencia para la recuperación ante desastres, debes completar los pasos anteriores nuevamente para el sitio de copia de seguridad. Si no tienes habilitada la recuperación ante desastres, omite esta sección.

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

1.17. Soluciona 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, verifica 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. Confirma todos los recursos implementados en el clúster de administrador raíz

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

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

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

  2. Confirma que los recursos de firewall estén disponibles:

    1. Establece una conexión SSH con el firewall y confirma que se creó un nuevo vsys:

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

      El resultado es similar a este:

      vsys1 {
vsys2 {

    2. Verifica el recurso FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system

      El resultado es similar a este:

      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. Verifica el recurso StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system

      El resultado es similar a este:

      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 del HSM estén disponibles:

    1. Verifica los HSM:

      k get hsms -n gpc-system

      El resultado es similar a este:

      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. Verifica el clúster del HSM:

      k get hsmcluster -n gpc-system

      El resultado es similar a este:

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

    3. Verifica el usuario del HSM:

      k get hsmtenant -A

      El resultado es similar a este:

      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 el nodo estén disponibles:

    1. Verifica los recursos AddressPoolClaim:

      k get addresspoolclaims -A

      El resultado es similar a este:

      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. Verifica los recursos NodePoolClaim:

      k get nodepoolclaims -A

      El resultado es similar a este:

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

    3. Verifica los recursos NodePool:

      k get nodepool -A

      El resultado es similar a este:

      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. Verifica los clústeres de equipos físicos:

      k get baremetalclusters -A

      El resultado es similar a este:

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

    5. Verifica las máquinas Bare Metal:

      k get baremetalmachines -A

      El resultado es similar a este:

      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. Verifica los servidores. Se encuentran en estado provisioned:

      k get servers -n gpc-system | grep provisioned

      El resultado es similar a este:

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

      k get cluster -A

      El resultado es similar a este:

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

    8. Verifica los Secrets del archivo kubeconfig:

      k get secrets -A | grep kubeconfig

      El resultado es similar a este:

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

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

Completa los siguientes pasos para confirmar que todos los recursos del clúster de administrador de la organización y del clúster del sistema en una organización de la versión 1 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. Confirma todos los recursos implementados en un clúster de administrador de la organización

  1. Sigue IAM-R0004 para obtener la configuración de kubeconfig requerida para el clúster de administrador raíz. Asegúrate de configurar las siguientes variables de entorno y el 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 el nodo estén disponibles:

    1. Verifica los clústeres de equipos físicos:

      ka get baremetalclusters -A

      El resultado es similar a este:

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

    2. Verifica las máquinas Bare Metal:

      ka get baremetalmachines -A

      El resultado es similar a este:

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

      ka get machines -A

      El resultado es similar a este:

      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. Verifica los recursos VirtualmachinesInstance:

      ka get virtualmachineinstances -A

      El resultado es similar a este:

      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. Verifica los recursos NodePool:

      ka get nodepools -A

      El resultado es similar a este:

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

      ka get clusters -A

      El resultado es similar a este:

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

    7. Verifica los nodos:

      ka get nodes -A

      El resultado es similar a este:

      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. Verifica los Secrets del archivo kubeconfig:

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

      El resultado es similar a este:

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

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

Completa los siguientes pasos para confirmar que todos los recursos del clúster del sistema estén en buen estado y presentes:

  1. Sigue IAM-R0004 para obtener la configuración de kubeconfig requerida para el clúster de administrador raíz. Asegúrate de configurar las siguientes variables de entorno y el 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 el nodo estén disponibles:

    1. Verifica el recurso VirtualmachineInstance:

      ku get vmi -A

      El resultado es similar al siguiente (si se creó un clúster de usuario):

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

      ku get nodes

      El resultado es similar a este:

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

      ku get gpuallocations -A

      El resultado es similar a este:

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

Completa los siguientes pasos para confirmar que todos los recursos del clúster de infraestructura de la organización en 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. Sigue IAM-R0004 para obtener la configuración de kubeconfig requerida para el clúster de administrador raíz. Asegúrate de configurar las siguientes variables de entorno y el 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. Verifica los nodos:

      ka get nodes -A

      El resultado es similar a este:

      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. Verifica los Secrets del archivo kubeconfig:

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

      El resultado es similar a este:

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

  3. Si corresponde, verifica las asignaciones de GPU para confirmar que los recursos de GPU estén listos:

    ka get gpuallocations -A

    El resultado es similar a este:

    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. Confirma que todos los recursos de la organización se hayan conciliado

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

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

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

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

    1. Verifica los recursos Organization globales:

      kga get organization -A

      El resultado es similar a este:

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. Verifica los recursos OrganizationReplica globales:

      kga get organizationreplica -A

      El resultado es similar a este:

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

    3. Verifica los recursos OrganizationZonalConfig globales:

      kga get organizationzonalconfig -A

      El resultado es similar a este:

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

    4. Verifica los recursos OrganizationZonalConfigReplica globales:

      kga get organizationzonalconfigreplica -A

      El resultado es similar a este:

      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. Establece 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. Verifica los recursos Organization:

      ka get organization -A

      El resultado es similar a este:

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

    2. Verifica los recursos OrganizationReplica:

      ka get organizationreplica -A

      El resultado es similar a este:

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

    3. Verifica los recursos OrganizationZonalConfigReplica:

      ka get organizationzonalconfigreplica -A

      El resultado es similar a este:

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

  5. Sigue los pasos en Permite 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 al sitio de copia de seguridad.