26. Arranque de varias zonas

Tiempo estimado para completar la actividad: 3 horas

Propietario del componente operable: MZ

Perfil de habilidad: ingeniero de implementación

26.1. Descripción general

El bootstrapping multizona implica configurar el plano de control global raíz. La primera zona de un universo establece el plano de control global. Se unen zonas adicionales al plano de control global. Unirse a un plano de control global es un proceso más complejo que establecer el plano de control, ya que se debe establecer la confianza entre el plano de control global del universo y la zona nueva. Cuando se une a un plano de control global, se involucran dos zonas:

  • Zona de anclaje: Es una zona que ya forma parte del plano de control global. Debe ser la zona cuya instancia de GitLab se usa para aplicar cambios de infraestructura como código (IaC) a la API global del universo.
  • Zona de unión: Es la zona que se une al plano de control global.

Inicializaste la primera zona del universo en Inicializar varias zonas. Esa zona sirve como zona de anclaje cuando otras zonas se unen al universo.

Si ya existe una API global en el universo y estás iniciando una zona que se une al universo, completa los siguientes pasos.

26.2. Inicia el multizona en las zonas que se unen a un universo

Antes de continuar, confirma que inicializaste varias zonas en la zona de anclaje.

26.2.1. Inicia el contenedor de la herramienta de IO

Para garantizar la seguridad y la capacidad de auditoría, el proceso de bootstrapping de varias zonas debe realizarse con credenciales personales para acceder a Kubernetes (no con una configuración de administrador de Kubernetes) y con IaC para la aprobación de varias partes de las solicitudes de autorización para realizar acciones sensibles. Todas las herramientas necesarias para realizar las acciones de bootstrapping se incluyen en el contenedor de IO Tool. Consulta el proceso de configuración del contenedor de la herramienta de IO OOPS-P0065 para saber cómo iniciar el contenedor en el entorno de OIC. Una zona que se une al plano de control global implica interacciones con dos zonas, una de las cuales (la zona de anclaje) no opera en condiciones del día 0, por lo que se deben emplear medidas de autenticación y autorización a nivel de producción para garantizar que no se vea comprometida la seguridad de la zona de anclaje.

26.2.2. Inicializa el repositorio de GitLab

Usa las credenciales del proveedor de identidad (IdP) configurado en Configuración de infraestructura como código y sigue el proceso OOPS-P0066 para administrar el acceso de los usuarios de GitLab.

Clona el repositorio de IaC de la zona de anclaje:

git clone https://iac.GLOBAL_DNS_DOMAIN/gdch/iac.git /tmp/iac

Reemplaza GLOBAL_DNS_DOMAIN por el dominio de DNS del universo.

Proporciona el nombre de usuario y la contraseña cuando se te solicite.

26.2.3. Agrega los roles necesarios

Sigue las instrucciones del manual de ejecución del proceso de acceso y elevación de privilegios IAM-R0005 para crear las vinculaciones de roles y el rol de clúster necesarios:

  • Agrega una vinculación de rol de clúster con el rol de clúster mz-bootstrap-joining-editor en el clúster root-admin de la zona de unión.
  • Agrega una vinculación de rol de clúster con el rol de clúster mz-bootstrap-anchor-reader en el clúster root-admin de la zona de anclaje.
  • Agrega una vinculación de rol con el rol mz-bootstrap-viewer en el espacio de nombres mz-system en la API global de la zona de anclaje.

26.2.4. Crea una solicitud de token

Cuando se une a un plano de control global, se establece contacto entre la zona de unión y la zona de anclaje con un token de arranque de la API global. Se usa una solicitud de token para solicitar un token de la API global en la zona de anclaje.

  1. Crea una rama nueva para una solicitud de combinación:

    cd /tmp/iac
git checkout -b JOINING_ZONE_NAME-mz-token-request

    Reemplaza JOINING_ZONE_NAME por el nombre de la zona, según se deriva del Cuestionario de admisión del cliente, como se describe en la nota al final de la sección.

  2. Accede a la zona de unión. Consulta la interfaz de línea de comandos de gcloud para obtener más detalles. Esto es necesario porque el comando gdcloud del siguiente paso interactúa con el clúster de administrador raíz en la zona de unión para obtener un par de clave de encriptación de claves pública para transferir de forma segura el token de arranque de la zona de anclaje a la zona de unión.

  3. Genera el archivo YAML de solicitud de token:

    gdcloud system multi-zone create-token-request --cluster root --zone JOINING_ZONE_NAME --client-type api-join --namespace global-kube-system --output-file /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml

  4. Crea o actualiza el archivo kustomization.yaml.

    1. Abre el archivo:

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

    2. Si el archivo ya existía, agrega un elemento mz-token-request.yaml a la lista resources. De lo contrario, agrega el archivo YAML del recurso completo:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
- mz-token-request.yaml

    3. Guarda el archivo y sal de vim.

  5. Confirma los cambios en la rama:

    git add infrastructure
git commit

  6. Envía la rama a GitLab:

    git push

  7. Haz que los cambios se combinen en la rama main. Consulta el manual IAC-R0004 para obtener más detalles.

26.2.5. Crear token

Sigue estos pasos para crear el token de arranque en la zona de unión:

  1. Crea una rama nueva para una solicitud de combinación:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token

  2. Accede a la zona de anclaje. Consulta la interfaz de línea de comandos de gcloud para obtener más detalles. Esto es necesario porque el comando gdcloud del siguiente paso interactúa con la API global en la zona de anclaje para crear y encriptar un token de arranque.

  3. Genera el archivo YAML del token:

    gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace global-kube-system --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml

  4. Crea o actualiza el archivo kustomization.yaml.

    1. Abre el archivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Si el archivo ya existía, agrega un elemento mz-token.yaml a la lista resources. De lo contrario, agrega el archivo YAML completo del recurso:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization
resources:
- mz-token.yaml

    3. Guarda el archivo y sal de vim.

  5. Confirma los cambios en la rama:

    git add infrastructure
git commit

  6. Envía la rama a GitLab:

    git push

  7. Haz que los cambios se combinen en la rama main. Consulta el manual IAC-R0004 para obtener más detalles.

26.2.6. Crea el recurso de arranque

Sigue estos pasos para crear el recurso de arranque en el clúster de administrador raíz de la zona de unión:

  1. Crea una rama nueva para una solicitud de combinación:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-bootstrap

  2. Accede a la zona de anclaje. Consulta la interfaz de línea de comandos de gcloud para obtener más detalles. Esto es necesario porque, durante una operación de unión, el comando gdcloud del siguiente paso interactúa con el clúster de administrador raíz en la zona de anclaje para recuperar información de conectividad para interactuar con la API global en la zona de anclaje.

  3. Genera el archivo YAML de arranque:

    gdcloud system multi-zone create-bootstrap --type join --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-bootstrap.yaml

  4. Crea o actualiza el archivo kustomization.yaml:

    1. Abre el archivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Si el archivo ya existía, agrega un elemento mz-token.yaml a la lista resources. De lo contrario, agrega el archivo YAML completo del recurso:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization
resources:
- mz-bootstrap.yaml

    3. Guarda el archivo y sal de vim.

  5. Confirma los cambios en la rama:

    git add infrastructure
git commit

  6. Envía la rama a GitLab:

    git push

  7. Haz que los cambios se combinen en la rama main. Consulta el manual IAC-R0004 para obtener más detalles.

Después de que se fusionan los cambios, la IaC propaga el recurso Bootstrap al clúster de administrador raíz de la nueva zona, donde se reconcilia. Esta es una operación asíncrona, por lo que la API global no estará disponible inmediatamente después de la combinación.

26.2.7. Valida la implementación correcta de la API global

Para validar la implementación de la API global, sigue estos pasos:

  1. Accede a la zona de unión. Consulta la interfaz de línea de comandos de gcloud para obtener más detalles.

  2. Obtén una configuración de Kubernetes para la API global raíz (global-api). Consulta el manual de ejecución IAM-R0004 para obtener más detalles.

  3. Verifica la conectividad con la API global en la zona de unión:

    kubectl version

26.2.8. Limpia el par de claves

Para borrar el par de claves que se usó para transferir el token de arranque de la zona de anclaje a la zona de unión, sigue estos pasos:

  1. Accede a la zona de unión. Consulta la interfaz de línea de comandos de gcloud para obtener más detalles.

  2. Obtén una configuración de Kubernetes para el clúster de administrador raíz (root-admin). Consulta el manual de ejecución IAM-R0004 para obtener más detalles.

  3. Ejecuta el siguiente comando para borrar el par de claves:

    kubectl delete keypair -n global-kube-system kp

26.2.9. Limpia la solicitud de token

Para borrar el archivo YAML de solicitud de token, sigue estos pasos:

  1. Crea una rama nueva para una solicitud de combinación:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token-request-delete

  2. Borra el archivo YAML de solicitud de token:

    rm /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml

  3. Actualiza el archivo kustomization.yaml:

    1. Abre el archivo:

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

    2. Quita el elemento mz-token-request.yaml de la lista resources, guarda el archivo y cierra vim.

  4. Confirma los cambios en la rama:

    git add infrastructure
git commit

  5. Envía la rama a GitLab:

    git push

  6. Haz que los cambios se combinen en la rama main. Consulta el manual IAC-R0004 para obtener más detalles.

26.2.10. Limpia el token

Una vez que la API global esté disponible en la zona de unión, borra el token, ya que no es necesario:

  1. Crea una rama nueva para una solicitud de combinación:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token-delete

  2. Borra el archivo YAML del token:

    rm /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml

  3. Actualiza el archivo kustomization.yaml si ya existe.

    1. Abre el archivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Quita el elemento mz-token.yaml de la lista resources, guarda el archivo y cierra vim.

  4. Confirma los cambios en la rama:

    git add infrastructure
git commit

  5. Envía la rama a GitLab:

    git push

  6. Haz que los cambios se combinen en la rama main. Consulta el manual IAC-R0004 para obtener más detalles.

26.2.11. Sincroniza la hora con otras zonas

  1. Sigue NTP P0007: Configura SyncServers multizona para sincronizar la hora en esta zona con las demás.

26.2.12. Verifica que la API global esté en buen estado

Una vez que se complete el proceso de arranque de la API global, realiza verificaciones de estado para confirmar que la API esté en buen estado:

  1. Obtén el nombre de la zona del servidor de la API del clúster de administrador raíz:

    export ZONE_NAME=$(kubectl get controlplane -n mz-system cp -o jsonpath='{.spec.zone}')

  2. Verifica la marca de tiempo de la última señal de monitoreo de funcionamiento de la API global:

    kubectl get globalapizone -n mz-system ${ZONE_NAME} -o yaml

    La marca de tiempo de latido se propaga en status.lastHeartbeat. La marca de tiempo se actualiza cada 30 segundos. Una API global en buen estado tiene la marca de tiempo de latido más reciente con una antigüedad no mayor a 30 segundos.

26.2.13. Extiende la fecha de vencimiento de la CA global de etcd

La autoridad de certificación (AC) del etcd global tiene una fecha de vencimiento de 90 días. El etcd global es un clúster de etcd que tiene instancias implementadas en varias zonas de GDC. No hay automatización para rotar la CA.

Estas instrucciones se deben aplicar a las zonas existentes que ya se unieron al universo de varias zonas. Después de que se actualicen las zonas existentes, la siguiente zona que se unirá a este universo puede omitir esta sección.

26.2.13.1. Verifica la fecha de vencimiento

Usa la configuración de Kubernetes del administrador para el clúster de administrador raíz en cualquier zona existente. Verifica la fecha de vencimiento de la CA:

export CA_NAME=$(kubectl get etcdca etcd -n global-kube-system -o jsonpath="{.spec.rootCA.name}")

kubectl get secret $CA_NAME -n global-kube-system -o jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -enddate -noout -in -

Si la fecha de vencimiento ya está establecida en alrededor de un año, no se requiere ninguna otra acción. Si es inferior a un año, consulta Rota la CA con una duración más larga.

26.2.13.2. Rota la CA con una duración más larga

Sigue MZ-T0001 para rotar la CA. Asegúrate de que la especificación del certificado de la nueva CA contenga un valor de duration: 8760h.