26. Bootstrapping multizona

Tiempo estimado para completarlo: 3 horas

Propietario del componente operable: MZ

Perfil de habilidades: ingeniero de implementaciones

26.1. Información general

Para iniciar un clúster multizona, debes configurar el plano de control global raíz. La primera zona de un universo establece el plano de control global. Se añaden zonas 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 una relación de confianza entre el plano de control global del universo y la nueva zona. Cuando se une a un plano de control global, se implican dos zonas:

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

Has inicializado la primera zona del universo en Inicializar multizona. Esa zona sirve como zona de anclaje cuando otras zonas se unen al universo.

Si ya hay una API global en el universo y estás inicializando una zona que se va a unir al universo, sigue estos pasos.

26.2. Bootstrap multizona en zonas que se unen a un universo

Confirma que has inicializado la multizona en la zona de anclaje antes de continuar.

26.2.1. Iniciar contenedor de herramientas de E/S

Por motivos de seguridad y auditabilidad, el proceso de arranque multizona debe realizarse con credenciales personales para acceder a Kubernetes (no con una configuración de Kubernetes de administrador) y con IaC para la aprobación multiparte de las solicitudes de autorización para realizar acciones sensibles. Todas las herramientas necesarias para realizar las acciones de arranque se incluyen en el contenedor de herramientas de E/S. Consulta el proceso de configuración del contenedor de herramientas de E/S OOPS-P0065 para saber cómo iniciar el contenedor en el entorno de OIC. Para que una zona se una al plano de control global, debe interactuar con dos zonas. Una de ellas (la zona de anclaje) no funciona en condiciones del día 0, por lo que se deben emplear medidas de autenticación y autorización de nivel de producción para asegurarse de que no se vea comprometida la seguridad de la zona de anclaje.

26.2.2. Inicializar el repositorio de GitLab

Usa las credenciales del proveedor de identidades configurado en Configuración de la infraestructura como código y sigue el proceso OOPS-P0066 para gestionar 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

Sustituye GLOBAL_DNS_DOMAIN por el dominio DNS del universo.

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

26.2.3. Añadir los roles necesarios

Sigue las instrucciones del runbook IAM-R0005 del proceso de acceso y elevación de privilegios para crear los enlaces de rol y de rol de clúster necesarios:

  • Añade 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.
  • Añade 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.
  • Añade una vinculación de roles con el rol mz-bootstrap-viewer en el espacio de nombres mz-system de la API global de la zona de anclaje.

26.2.4. Crear solicitud de token

Al unirse a un plano de control global, se establece contacto entre la zona que se une y la zona de anclaje mediante un token de arranque de API global. Una solicitud de token se usa para solicitar un token de la API global en la zona de anclaje.

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

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

    Sustituye JOINING_ZONE_NAME por el nombre de la zona, tal como se indica en el cuestionario de incorporación de clientes, como se describe en la nota al final de la sección.

  2. Inicia sesión en la zona de unión. Consulta Interfaz de línea de comandos de gcloud para obtener más información. Esto es necesario porque el comando gdcloud del siguiente paso interactúa con el clúster de administrador raíz de la zona de unión para obtener un par de claves de cifrado de clave 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, añade un elemento mz-token-request.yaml a la lista resources. De lo contrario, añade 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. Consigue que los cambios se combinen en la rama main. Consulta el runbook IAC-R0004 para obtener más información.

26.2.5. Crear token

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

  1. Crea una rama 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. Inicia sesión en la zona de anclaje. Consulta Interfaz de línea de comandos de gcloud para obtener más información. Esto es necesario porque el comando gdcloud del paso siguiente interactúa con la API global de la zona de anclaje para crear y cifrar 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, añade un elemento mz-token.yaml a la lista resources. De lo contrario, añade el archivo YAML del recurso completo:

      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. Consigue que los cambios se combinen en la rama main. Consulta el runbook IAC-R0004 para obtener más información.

26.2.6. Crear 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 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. Inicia sesión en la zona de anclaje. Consulta Interfaz de línea de comandos de gcloud para obtener más información. Esto es necesario porque, durante una operación de unión, el comando gdcloud del paso siguiente interactúa con el clúster de administrador raíz de la zona de anclaje para obtener información de conectividad que permita interactuar con la API global de 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, añade un elemento mz-token.yaml a la lista resources. De lo contrario, añade el archivo YAML del recurso completo:

      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. Consigue que los cambios se combinen en la rama main. Consulta el runbook IAC-R0004 para obtener más información.

Una vez que se hayan combinado los cambios, IaC propagará el recurso Bootstrap al clúster de administrador raíz de la nueva zona, donde se reconciliará. Se trata de una operación asíncrona, por lo que la API global no estará disponible inmediatamente después de la combinación.

26.2.7. Validar que la API global se ha implementado correctamente

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

  1. Inicia sesión en la zona de unión. Consulta Interfaz de línea de comandos de gcloud para obtener más información.

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

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

    kubectl version

26.2.8. Limpiar par de claves

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

  1. Inicia sesión en la zona de unión. Consulta Interfaz de línea de comandos de gcloud para obtener más información.

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

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

    kubectl delete keypair -n global-kube-system kp

26.2.9. Limpiar la solicitud de token

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

  1. Crea una rama 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. Elimina el archivo YAML de la 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. Elimina 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. Consigue que los cambios se combinen en la rama main. Consulta el runbook IAC-R0004 para obtener más información.

26.2.10. Limpiar token

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

  1. Crea una rama 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. Elimina 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. Elimina 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. Consigue que los cambios se combinen en la rama main. Consulta el runbook IAC-R0004 para obtener más información.

26.2.11. Sincronizar la hora con otras zonas

  1. Sigue las instrucciones del artículo NTP P0007 - Configure Multizone SyncServers (NTP P0007: Configurar SyncServers multizona) para sincronizar la hora de esta zona con la de las demás.

26.2.12. Verificar que la API global está en buen estado

Una vez completado el proceso de arranque de la API global, realiza comprobaciones de estado para confirmar que la API funciona correctamente:

  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. Comprueba la marca de tiempo de la última señal de latido de la API global:

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

    La marca de tiempo del latido se rellena en status.lastHeartbeat. La marca de tiempo se actualiza cada 30 segundos. Una API global en buen estado tiene la marca de tiempo de la última señal de actividad con una antigüedad máxima de 30 segundos.

26.2.13. Ampliar la fecha de vencimiento de la AC etcd global

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

Estas instrucciones deben aplicarse a las zonas que ya se hayan unido al universo multizona. Una vez que se hayan actualizado las zonas, la siguiente zona que vaya a unirse a este universo podrá saltarse esta sección.

26.2.13.1. Comprobar la fecha de vencimiento

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

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 es de aproximadamente un año, no es necesario que hagas nada más. Si es inferior a un año, consulta Rotar la CA con una duración mayor.

26.2.13.2. Rotar la AC 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 AC contenga el valor duration: 8760h.