26. 引导多区域

预计完成时间：3 小时

可操作组件所有者：MZ

技能配置文件：部署工程师

26.1. 概览

多可用区引导涉及设置根全局控制平面。一个宇宙中的第一个可用区会建立全局控制平面。其他可用区加入全球控制平面。加入全球控制平面的过程比建立控制平面更复杂，因为必须在宇宙的全球控制平面与新区域之间建立信任关系。加入全球控制平面时，会涉及两个可用区：

• 锚定可用区：已成为全球控制平面一部分的可用区。此值必须是用于将基础设施即代码 (IaC) 更改应用于 Universe 的全局 API 的 GitLab 实例所在的可用区。
• 加入区域：加入全球控制平面的区域。

您在 Initialize multi-zone 中引导了宇宙的第一个可用区。当其他地区加入宇宙时，该地区会充当锚定地区。

如果相应宇宙中已存在全局 API，并且您正在引导加入该宇宙的区域，请完成以下步骤。

26.2. 在加入宇宙的可用区中引导多可用区

请先确认您已在锚定可用区中完成多可用区引导，然后再继续操作。

26.2.1. 启动 IO 工具容器

为了确保安全性和可审核性，多可用区引导启动流程必须使用个人凭据来访问 Kubernetes（而不是管理员 Kubernetes 配置），并使用 IaC 来实现对授权请求的多方审批，以执行敏感操作。IO 工具容器中包含执行引导操作所需的所有工具。如需了解如何在 OIC 环境中启动容器，请参阅 IO 工具容器设置 OOPS-P0065 流程。加入全球控制平面的可用区需要与两个可用区进行交互，其中一个可用区（锚定可用区）不在第 0 天条件下运行，因此必须采用生产级身份验证和授权措施，以确保锚定可用区的安全性不会受到损害。

26.2.2. 初始化 GitLab 代码库

使用在将基础设施即代码设置为中配置的身份提供方 (IdP) 的凭据，并按照 OOPS-P0066 流程管理 GitLab 用户访问权限。

克隆锚定区域的 IaC 代码库：

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

将 GLOBAL_DNS_DOMAIN 替换为相应世界的 DNS 网域。

系统提示时，输入用户名和密码。

26.2.3. 添加所需角色

按照“访问权限和权限提升流程”IAM-R0005 运行手册中的说明创建必要的集群角色和角色绑定：

• 在加入区域的 root-admin 集群中添加具有 mz-bootstrap-joining-editor 集群角色的集群角色绑定。
• 在锚定区域的 root-admin 集群中添加具有 mz-bootstrap-anchor-reader 集群角色的集群角色绑定。
• 在锚定区的全局 API 中，添加一个具有 mz-bootstrap-viewer 角色的角色绑定（位于 mz-system 命名空间中）。

26.2.4. 创建令牌请求

加入全球控制平面时，加入区域和锚定区域之间会使用全局 API 引导令牌建立联系。令牌请求用于从锚定区域中的全局 API 请求令牌。

1. 为合并请求创建新分支：

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

   将 JOINING_ZONE_NAME 替换为从客户意见征询问卷中派生的可用区名称，如本部分末尾的注释中所述。

2. 登录加入的地区。如需了解详情，请参阅 gdcloud 命令行界面。这是必需的，因为下一步中的 gdcloud 命令会与加入区域中的根管理员集群互动，以获取公钥加密密钥对，从而安全地将引导令牌从锚定区域转移到加入区域。

3. 生成令牌请求 YAML 文件：

   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. 创建或更新 kustomization.yaml 文件。

   1. 打开文件：

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

   2. 如果该文件已存在，请向 resources 列表添加 mz-token-request.yaml 项。否则，请添加完整的资源 YAML：

      注意： 使用 :set paste 可防止 vim 在您粘贴预格式化文本时自动设置格式。

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

   3. 保存文件并退出 vim。

5. 将更改提交到分支：

   注意： 您需要先使用自己的姓名和电子邮件地址配置 Git，然后才能提交更改。

   git add infrastructure
   git commit
   

6. 将分支推送到 GitLab：

   git push
   

7. 将更改合并到 main 分支。如需了解详情，请参阅 IAC-R0004 运行手册。

26.2.5. 创建令牌

请按照以下步骤在加入区域中创建引导令牌：

1. 为合并请求创建新分支：

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

2. 登录锚定可用区。如需了解详情，请参阅 gdcloud 命令行界面。这是必需的，因为下一步中的 gdcloud 命令会与锚定区域中的全局 API 交互，以创建和加密引导令牌。

3. 生成令牌 YAML 文件：

   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. 创建或更新 kustomization.yaml 文件。

   1. 打开文件：

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

   2. 如果该文件已存在，请向 resources 列表添加 mz-token.yaml 项。否则，请添加完整资源 YAML：

      注意： 使用 :set paste 可防止 vim 在您粘贴预格式化文本时自动设置格式。

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

   3. 保存文件并退出 vim。

5. 将更改提交到分支：

   注意： 您需要先使用自己的姓名和电子邮件地址配置 Git，然后才能提交更改。

   git add infrastructure
   git commit
   

6. 将分支推送到 GitLab：

   git push
   

7. 将更改合并到 main 分支。如需了解详情，请参阅 IAC-R0004 运行手册。

26.2.6. 创建引导资源

请按照以下步骤在加入可用区的根管理员集群中创建引导资源：

1. 为合并请求创建新分支：

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

2. 登录锚定可用区。如需了解详情，请参阅 gdcloud 命令行界面。这是必需的，因为在加入操作期间，下一步中的 gdcloud 命令会与锚定区域中的根管理员集群进行交互，以检索与锚定区域中的全局 API 进行交互的连接信息。

3. 生成引导 YAML 文件：

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

4. 创建或更新 kustomization.yaml 文件：

   1. 打开文件：

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

   2. 如果该文件已存在，请向 resources 列表添加 mz-token.yaml 项。否则，请添加完整资源 YAML：

      注意： 使用 :set paste 可防止 vim 在您粘贴预格式化文本时自动设置格式。

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

   3. 保存文件并退出 vim。

5. 将更改提交到分支：

   注意： 您需要先使用自己的姓名和电子邮件地址配置 Git，然后才能提交更改。

   git add infrastructure
   git commit
   

6. 将分支推送到 GitLab：

   git push
   

7. 将更改合并到 main 分支。如需了解详情，请参阅 IAC-R0004 运行手册。

更改合并后，Iac 会将 Bootstrap 资源传播到新区域的根管理员集群，并在其中进行协调。这是一项异步操作，因此合并后不会立即提供全局 API。

26.2.7. 验证全局 API 是否成功部署

如需验证全局 API 的部署，请按以下步骤操作：

1. 登录加入的地区。如需了解详情，请参阅 gdcloud 命令行界面。

2. 获取根全局 API (global-api) 的 Kubernetes 配置。如需了解详情，请参阅 IAM-R0004 运行手册。

3. 验证与加入区域中的全局 API 的连接：

   kubectl version
   

26.2.8. 清理密钥对

如需删除用于将引导令牌从锚定区域转移到加入区域的密钥对，请按以下步骤操作：

1. 登录加入的地区。如需了解详情，请参阅 gdcloud 命令行界面。

2. 获取根管理员集群 (root-admin) 的 Kubernetes 配置。如需了解详情，请参阅 IAM-R0004 运行手册。

3. 运行以下命令以删除密钥对：

   kubectl delete keypair -n global-kube-system kp
   

26.2.9. 清理令牌请求

如需删除令牌请求 YAML 文件，请按以下步骤操作：

1. 为合并请求创建新分支：

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

2. 删除令牌请求 YAML 文件：

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

3. 更新 kustomization.yaml 文件。

   1. 打开文件：

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

   2. 从 resources 列表中移除 mz-token-request.yaml 项，保存文件，然后退出 vim。

4. 将更改提交到分支：

   注意： 您需要先使用自己的姓名和电子邮件地址配置 Git，然后才能提交更改。

   git add infrastructure
   git commit
   

5. 将分支推送到 GitLab：

   git push
   

6. 将更改合并到 main 分支。如需了解详情，请参阅 IAC-R0004 运行手册。

26.2.10. 清理令牌

在加入的区域中提供全局 API 后，删除令牌，因为不再需要该令牌：

1. 为合并请求创建新分支：

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

2. 删除令牌 YAML 文件：

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

3. 如果 kustomization.yaml 文件已存在，则更新该文件。

   1. 打开文件：

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

   2. 从 resources 列表中移除 mz-token.yaml 项，保存文件，然后退出 vim。

4. 将更改提交到分支：

   注意： 您需要先使用自己的姓名和电子邮件地址配置 Git，然后才能提交更改。

   git add infrastructure
   git commit
   

5. 将分支推送到 GitLab：

   git push
   

6. 将更改合并到 main 分支。如需了解详情，请参阅 IAC-R0004 运行手册。

26.2.11. 与其他时区同步时间

1. 按照 NTP P0007 - 配置多地区 SyncServer 将此地区的时间与其他地区的时间同步。

26.2.12. 验证全局 API 是否正常运行

在完成全局 API 启动过程后，执行健康状况检查以确认 API 运行正常：

1. 从根管理员集群的 API 服务器获取可用区名称：

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

2. 检查全局 API 的上次检测信号时间戳：

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

   检测信号时间戳填充在 status.lastHeartbeat 中。时间戳每 30 秒更新一次。运行正常的全局 API 的最新心跳时间戳不超过 30 秒。

26.2.13. 延长全局 etcd CA 的过期日期

全局 etcd 的证书授权机构 (CA) 的有效期为 90 天。全局 etcd 是一个 etcd 集群，其中包含部署在多个 GDC 可用区中的实例。没有用于轮替 CA 的自动化功能。

这些说明应应用于已加入多地区世界的现有地区。 在更新现有地区后，即将加入此宇宙的下一个地区可以跳过此部分。

26.2.13.1. 检查失效日期

使用任何现有区域中根管理员集群的管理员 Kubernetes 配置。检查 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 -

如果到期日期已设置为大约一年后，则无需再执行任何操作。如果小于一年，请参阅轮替时长更长的 CA。

26.2.13.2. 轮替持续时间更长的 CA

按照 MZ-T0001 轮替 CA。确保新 CA 的证书规范包含值 duration: 8760h。