26. マルチゾーンをブートストラップする

完了までの推定時間: 3 時間

操作可能なコンポーネントのオーナー: MZ

スキル プロファイル: デプロイ エンジニア

26.1. 概要

マルチゾーンのブートストラップには、ルート グローバル コントロール プレーンの設定が含まれます。ユニバースの最初のゾーンは、グローバル コントロール プレーンを確立します。追加のゾーンがグローバル コントロール プレーンに参加します。グローバル コントロール プレーンへの参加は、コントロール プレーンの確立よりも複雑なプロセスです。これは、ユニバースのグローバル コントロール プレーンと新しいゾーンの間に信頼を確立する必要があるためです。グローバル コントロール プレーンに参加する場合、次の 2 つのゾーンが関係します。

• アンカーゾーン: グローバル コントロール プレーンにすでに含まれているゾーン。これは、GitLab インスタンスを使用して、ユニバースのグローバル API に Infrastructure as Code（IaC）の変更を適用するゾーンである必要があります。
• 参加ゾーン: グローバル コントロール プレーンに参加するゾーン。

マルチゾーンの初期化で、ユニバースの最初のゾーンをブートストラップしました。このゾーンは、他のゾーンがユニバースに参加する際のアンカー ゾーンとして機能します。

ユニバースにグローバル API がすでに存在し、ユニバースに参加するゾーンをブートストラップする場合は、次の手順を行います。

26.2. ユニバースに参加するゾーンでマルチゾーンをブートストラップする

続行する前に、アンカー ゾーンでマルチゾーンをブートストラップしたことを確認します。

26.2.1. IO ツール コンテナを起動する

セキュリティと監査可能性を確保するため、マルチゾーン ブートストラップ プロセスは、Kubernetes にアクセスするための個人用認証情報（管理者 Kubernetes 構成ではない）と、機密性の高い操作を実行するための承認リクエストに対する複数者による承認のための IaC を使用して実行する必要があります。ブートストラップ アクションを実行するために必要なツールはすべて、IO ツール コンテナに含まれています。OIC 環境でコンテナを起動する方法については、IO Tool Container Setup OOPS-P0065 プロセスをご覧ください。グローバル コントロール プレーンに参加するゾーンは 2 つのゾーンとやり取りします。そのうちの 1 つ（アンカー ゾーン）は day-0 条件で動作していないため、アンカー ゾーンのセキュリティが損なわれないように、本番環境レベルの認証と認可の対策を講じる必要があります。

26.2.2. GitLab リポジトリを初期化する

Infrastructure as code の設定で構成された ID プロバイダ（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 ランブックの手順に沿って、必要な cluster-role と role binding を作成します。

• 参加ゾーンの root-admin クラスタに mz-bootstrap-joining-editor クラスタロールを含むクラスタロール バインディングを追加します。
• アンカー ゾーンの root-admin クラスタに mz-bootstrap-anchor-reader クラスタロールを含むクラスタロール バインディングを追加します。
• アンカー ゾーンのグローバル API の mz-system Namespace に mz-bootstrap-viewer ロールを含むロール バインディングを追加します。

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. ブランチに変更を commit します。

   注: 変更を commit する前に、名前とメールアドレスを使用して git を構成する必要があります。

   git add infrastructure
   git commit
   

6. ブランチを GitLab に push します。

   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. ブランチに変更を commit します。

   注: 変更を commit する前に、名前とメールアドレスを使用して git を構成する必要があります。

   git add infrastructure
   git commit
   

6. ブランチを GitLab に push します。

   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. ブランチに変更を commit します。

   注: 変更を commit する前に、名前とメールアドレスを使用して git を構成する必要があります。

   git add infrastructure
   git commit
   

6. ブランチを GitLab に push します。

   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. ルート管理クラスタの Kubernetes 構成を取得します（root-admin）。詳細については、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. ブランチに変更を commit します。

   注: 変更を commit する前に、名前とメールアドレスを使用して git を構成する必要があります。

   git add infrastructure
   git commit
   

5. ブランチを GitLab に push します。

   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. ブランチに変更を commit します。

   注: 変更を commit する前に、名前とメールアドレスを使用して git を構成する必要があります。

   git add infrastructure
   git commit
   

5. ブランチを GitLab に push します。

   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 は、複数の GDC ゾーンにインスタンスがデプロイされている etcd クラスタです。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 -

有効期限がすでに 1 年程度に設定されている場合は、これ以上の対応は必要ありません。1 年未満の場合は、有効期間の長い CA をローテーションするをご覧ください。

26.2.13.2. 期間の長い CA をローテーションする

MZ-T0001 に沿って CA をローテーションします。新しい CA の証明書仕様に duration: 8760h の値が含まれていることを確認します。