内部での CA の移行
メッシュ内に複数のクラスタがあり、ワークロードが他のクラスタにリクエストを送信している場合は、すべてのクラスタについて、このガイドのすべての手順を行います。
このガイドでは、次のユースケースについて説明します。
- Mesh CA を使用するクラスタ内の Cloud Service Mesh v1.13 以降のコントロール プレーンを Certificate Authority Service に移行する。
- Mesh CA を使用し、v1.13 以降にマッピングされたリリース チャネルのマネージド Cloud Service Mesh コントロール プレーンを Certificate Authority Service に移行する。
制限事項
CA のインプレース移行とアップグレードは、Cloud Service Mesh v1.13 以降でのみサポートされます。マネージド コントロール プレーンを移行する場合は、選択したチャネルが v1.13 以降にマッピングされていることを確認します。
前提条件
このガイドの手順に進む前に、次のことを確認してください。
また、現在 Cloud Service Mesh v1.13 以降を使用していることも確認してください。
必要なツール
移行中に、Google 提供のツール（migrate_ca）を実行します。このツールには次の依存関係があります。
awkgrepjqkubectlheadsedtryq
migrate_ca ツールをダウンロードする前に、移行の準備の手順を行ってください。
移行の概要
移行プロセス中は、以前の CA を使用するワークロードと新しい CA を使用するワークロードの間で、認証と認可が完全に機能します。
migrate_ca 移行ツールは、インストールされている Cloud Service Mesh のリビジョン / チャネルごとに CA 移行のステータスを追跡する Kubernetes 構成マップを作成します。これは、istio-system 名前空間にインストールされる特権リソースです。
apiVersion: v1
kind: ConfigMap
metadata:
Name: asm-ca-migration-<revision>
Data:
revision:
start_time:
state_update_time:
current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
old_ca:
target_ca:
移行ツールは、修正する前に Istio MeshConfig 構成マップをバックアップします。また、可能であれば ProxyConfig CRD を使用して CA 構成の移行を試みます。
CA の移行の概要は次のとおりです。
移行を準備する
migrate_cabash ツールをダウンロードします。curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_caツールを実行可能にします。
chmod +x migrate_ca作業ディレクトリを設定します。
./migrate_ca setup --output_dir OUTPUT_DIR作業ディレクトリを前の手順で指定した OUTPUT_DIR に変更します。
cd OUTPUT_DIR次のコマンドを実行して、すべての前提条件が満たされていることを確認します。
./migrate_ca check-prerequisites移行する以前の CA に関連付けられているコントロール プレーンのリビジョン（
ASM_REVISION）をメモします。必要な手順は、コントロール プレーンの種類（クラスタ内またはマネージド）によって異なります。クラスタ内
asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \ "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")マネージド
すでにインストールされているチャネルをご覧ください。
インプレース CA 移行では、ワークロードを再起動する必要があります。このため、Pod 停止予算が正しく構成されていることと、CA の移行が必要なすべてのアプリケーションに、実行中の Pod が複数存在することを確認してください。
クラスタがすでにフリートに登録されていることと、Workload Identity がクラスタで有効になっていることを確認します。以降の手順で使用できるようにフリート プロジェクト ID（
FLEET_ID）をメモします。このツールは、
kubeConfigとkubeContextを受け入れ、オペレーションが実行されるクラスタを選択します。これらの引数を渡さない場合、デフォルトのコンテキストと構成が使用されます。GKE クラスタの認証情報を
kubeConfigに追加するには、次のコマンドを使用します。gcloud container clusters get-credentials CLUSTER_NAME現在の
kubectlコンテキストを変更するか、コンテキストをツールに渡すには、次のコマンドを使用します。kubectl config get-contexts kubectl config use-context CLUSTER_NAME
新しい CA を初期化する
新しい CA の初期化に必要な手順は、移行先の新しい CA によって異なります。CA を移行するすべてのフリート クラスタで次の操作を行います。
Mesh CA
ユーティリティ ツールの
initializeサブコマンドを呼び出します。Kubernetes カスタム構成を指定する場合:
./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISIONそれ以外の場合:
./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISION ```CA Service
a. Certificate Authority Service の初期化に必要な手順を行います。
CA_POOLをメモします。b. ユーティリティ ツールの
initializeサブコマンドを呼び出します。Kubernetes カスタム構成を指定する場合:
./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISIONそれ以外の場合:
./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISION
フリート内のすべてのクラスタにメッシュ全体の trustAnchors を追加する
フリートに含まれるすべてのクラスタで、新しい CA と古い CA の両方に対して以下の手順を繰り返します。
CA の trustAnchors をダウンロードします。
Mesh CA
./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pemCA Service
CA 証明書をファイルに保存します。
gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pemCA の trustAnchors を追加します。
./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pemtrustAnchors がフリート内のすべてのワークロードで受信されていることを確認します。namespaces 引数で、ワークロードがデプロイされているすべての名前空間を渡します。
./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES予想される出力:
Check the CA cert in namespace nsa-1-24232 a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
CA を移行する
CA 構成を移行します。必要なコマンドは、移行先の新しい CA によって異なります。
Mesh CA
./migrate_ca migrate-ca --ca mesh_caCA Service
./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOLすべてのワークロードを再起動します。
TLS トラフィックのダウンタイム リスクを最小限に抑えるため、この手順で最初に影響を受けるワークロードの数を最小限にとどめる必要があります。再起動するのは、コントロール プレーンのリビジョン ASM_REVISION に関連付けられているワークロードのみです。たとえば、kubernetes Namespace NAMESPACE 内のすべてのワークロードが同じ Cloud Service Mesh コントロール プレーンに関連付けられているとします。
kubectl rollout restart deployment -n NAMESPACE再起動した名前空間のワークロードと他のワークロードの間で mTLS 接続が機能することを確認してから、すべての名前空間とフリート内のすべてのクラスタに対して手順 1 と 2 を繰り返します。新しいワークロードが起動し、メッシュ トラフィックが中断されていない場合は、フリートの一部であるすべての名前空間とクラスタで手順 1 と 2 を繰り返します。それ以外の場合は、ロールバックを実行して、新しい CA 構成をロールバックします。
すべてのワークロードで新しい CA 構成が使用されていることを確認します。
./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES予想される出力:
Check the CA configuration in namespace nsb-2-76095 b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
ロールバックを実行する
CA 構成をロールバックし、新しく構成した trustAnchors を削除します。
./migrate-ca rollbackすべてのワークロードを再起動します。コントロール プレーンのリビジョン ASM_REVISION に関連付けられているワークロードのみを再起動してください。たとえば、kubernetes Namespace NAMESPACES 内のすべてのワークロードが同じ Cloud Service Mesh コントロール プレーンに関連付けられているとします。
kubectl rollout restart deployment -n NAMESPACES（省略可）古い CA 構成がすべてのワークロードで使用されていることを確認します。
./migrate-ca verify-ca --ca_cert older-root-cert.pemワークロードが ASM_REVISION コントロール プレーンを使用するフリート内のすべてのクラスタに対して、手順 1～3 を繰り返します。
これで完了です。インプレース CA 移行が正常に完了しました。