このチュートリアルでは、Anthos clusters on bare metal と Anthos Config Management を使用して Kubernetes クラスタをエッジに大規模にデプロイするための、すぐに利用できるソリューションを紹介します。このチュートリアルは、プラットフォーム オペレータ―とデベロッパーを対象としています。次のテクノロジーとコンセプトに精通している必要があります。
- Ansible のハンドブック。
- エッジへのデプロイとその課題。
- Google Cloud プロジェクトの使用方法。
- Kubernetes クラスタにアプリケーションをデプロイする方法。
gcloudおよびkubectlコマンドライン インターフェース。
このチュートリアルでは、Compute Engine 仮想マシン（VM）を使用して、エッジにデプロイされたノードとサンプル POS アプリケーションをエッジ ワークロードとしてエミュレートします。Anthos clusters on bare metal と Anthos Config Management は、エッジクラスタの一元管理を行います。Anthos Config Management は GitHub から新しい構成を動的に pull し、これらのポリシーと構成をクラスタに適用します。
エッジ デプロイ アーキテクチャ
小売業のエッジ デプロイは、一般的な Anthos clusters on bare metal のデプロイで使用されているアーキテクチャを説明する良い方法です。
小売店の実店舗は、企業の事業部門と消費者の間の最も近い接点です。店舗内のソフトウェア システムは、企業の中央管理システムから分離して、ワークロードを実行し、更新をタイムリーに受け取り、重要な指標を報告する必要があります。さらに、これらのソフトウェア システムは将来的により多くの店舗に拡大できるように設計される必要があります。Anthos clusters on bare metal は、店舗のソフトウェア システムのこれらの要件をすべて満たしていますが、エッジ プロファイルは、小売店の店頭などのハードウェア リソースが制限された環境でのデプロイという重要なユースケースを可能にします。
次の図は、小売店のエッジ プロファイルを使用する Anthos clusters on bare metal デプロイを示しています。
上の図は、一般的な実店舗を示しています。店舗には、カードリーダー、POS マシン、カメラ、プリンタなどのスマート デバイスがあります。店舗には、3 つの物理コンピューティング ハードウェア デバイス（Node 1、Node 2、Node 3 というラベル付き）もあります。これらのデバイスはすべて中央のネットワーク スイッチに接続されています。したがって、3 つのコンピューティング デバイスはレイヤ 2 ネットワークを介して相互に接続されています。互いにネットワーク接続されたコンピューティング デバイスがベアメタル インフラストラクチャを構成します。Anthos clusters on bare metal は、3 台のコンピューティング デバイスごとに実行されます。これらのデバイスには独自のディスク ストレージがあり、高可用性のためにデバイス間でデータ レプリケーションが構成されています。
この図は、Anthos clusters on bare metal デプロイの一部である、次の主要なコンポーネントも示しています。
- MetalLB とマークされたコンポーネントは、Anthos clusters on bare metal とともにデプロイされるバンドルされたロードバランサです。
- Anthos Config Management コンポーネントを使用すると、クラスタの状態をソース リポジトリと同期できます。これは、個別のインストールと構成が必要とする、強く推奨されるオプションのアドオンです。Anthos Config Management の設定方法とさまざまな用語の詳細については、Anthos Config Management のドキュメントをご覧ください。
店舗の場所の外側にある図に表示されているルート リポジトリと名前空間リポジトリは、2 つのソース リポジトリを表します。
クラスタに対する変更は、これらの中央のソース リポジトリに push されます。さまざまなエッジ ロケーションの Anthos clusters on bare metal デプロイは、ソース リポジトリから更新を pull します。この動作は、図の 2 つのリポジトリを、デバイスで実行される Anthos on bare metal 内の Anthos Config Management コンポーネントに接続する矢印で示されています。
Anthos VM ランタイムには、クラスタの一部として示されているもう 1 つの重要なコンポーネントがあります。Anthos VM ランタイムは、コンテナ化せずに、クラスタ内で既存の VM ベースのワークロードを実行できます。Anthos VM ランタイムのドキュメントでは、この機能を有効にして、VM ワークロードをクラスタにデプロイする方法を説明しています。
アプリケーションとマークされたコンポーネントは、小売店によってクラスタにデプロイされたソフトウェアを示します。そのようなアプリケーションの例として、小売店のキオスクで見られる POS アプリケーションがあります。
図の下のボックスは、小売店内の多数のデバイス（キオスク、タブレット、カメラなど）を表しています。これらはすべて中央のネットワーク スイッチに接続されています。店舗内のローカル ネットワークを使用すると、Anthos clusters on bare metal デプロイ内で実行されているアプリケーションがこれらのデバイスにアクセスできます。
次のセクションでは、Compute Engine VM を使用して Google Cloud にこの小売店のデプロイをエミュレートする様子を説明します。このエミュレーションは、以下のチュートリアルで Anthos clusters on bare metal を試すために使用するものです。
Google Cloud でのエッジデプロイのエミュレート
次の図は、このチュートリアルで Google Cloud に設定するすべての内容を示しています。この図は、前のセクションの小売店図と相関しています。このデプロイは、POS アプリケーションがデプロイされるエミュレートされたエッジ ロケーションを表します。このアーキテクチャは、このチュートリアルで使用する簡単な POS アプリケーション ワークロードも示しています。ウェブブラウザをキオスクとして使用して、クラスタ内の POS アプリケーションにアクセスします。
上の図の 3 つの Compute Engine 仮想マシン（VM）は、一般的なエッジ ロケーションの物理ハードウェア（またはノード）を表します。このハードウェアは、互いにネットワーク スイッチに接続して、ベアメタル インフラストラクチャを構成します。Google Cloud のエミュレート環境では、これらの VM は Google Cloud プロジェクトのデフォルトの Virtual Private Cloud（VPC）ネットワークを介して相互に接続しています。
一般的な Anthos clusters on bare metal のインストールでは、独自のロードバランサを構成できます。ただし、このチュートリアルでは、外部ロードバランサを設定しません。代わりに、Anthos clusters on bare metal にインストールされたバンドルされた MetalLB ロードバランサを使用します。バンドルされた MetalLB ロードバランサには、ノード間のレイヤ 2 ネットワーク接続が必要です。したがって、Compute Engine VM 間のレイヤ 2 接続は、デフォルトの Virtual Private Cloud（VPC）ネットワーク上に VxLAN オーバーレイ ネットワークを作成することによって有効になります。
「L2 オーバーレイ ネットワーク（VxLAN）」という長方形の枠内に、3 つの Compute Engine VM 内で実行されているソフトウェア コンポーネントが表示されています。この長方形には、Anthos on bare metal クラスタとリバース プロキシが含まれています。クラスタは、Anthos clusters on bare metalの長方形で表されます。このクラスタを表す長方形には、「Kubernetes 名前空間（POS）」とマークされた別の長方形が含まれます。これは、クラスタ内の Kubernetes Namespace を表します。この Kubernetes 名前空間内のすべてのコンポーネントが、Anthos クラスタにデプロイされる POS アプリケーションを構成します。POS アプリケーションには、API サーバー、インベントリ、支払いの 3 つのマイクロサービスがあります。これらのコンポーネントは、前述のエッジ ロールアウト アーキテクチャ図に示されている 1 つの「アプリケーション」を表しています。
Anthos クラスタのバンドルされた MetalLB ロードバランサに、VM の外部から直接アクセスすることはできません。この図は、NGINX リバース プロキシが VM 内で実行されて Compute Engine VM に到達するトラフィックをロードバランサにルーティングするように構成されていることを示しています。これは、Google Cloud Compute Engine VM を使用してエッジノードをエミュレートするというこのチュートリアルの目的の回避策にすぎません。実際のエッジ ロケーションでは、これは適切なネットワーク構成で行うことができます。
目標
- Compute Engine VM を使用して、エッジ ロケーションで動作するベアメタル インフラストラクチャをエミュレートします。
- エミュレートされたエッジ インフラストラクチャで、Anthos on bare metal クラスタを作成します。
- クラスタを Google Cloud に接続して登録します。
- Anthos クラスタにサンプルの POS アプリケーションのワークロードをデプロイします。
- Google Cloud コンソールを使用して、エッジ ロケーションで動作する POS アプリケーションを確認し、モニタリングします。
- Anthos Config Management を使用して、Anthos クラスタで動作する POS アプリケーションを更新します。
始める前に
Google Cloud コンソールの [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
Anthos サンプル リポジトリをフォークしてクローンを作成する
このチュートリアルで使用するすべてのスクリプトは、anthos-samples リポジトリに保存されています。/anthos-bm-edge-deployment/acm-config-sink の下のフォルダ構造は、Anthos Config Management で想定される構造に従って編成されています。次の手順に進む前に、このリポジトリを自分の GitHub アカウントにクローンします。
アカウントを持っていない場合は、GitHub でアカウントを作成してください。
Anthos Config Management の構成で使用する個人用のアクセス トークンを作成します。これは、クラスタの Anthos Config Management コンポーネントが、新しい変更を同期しようとするときに GitHub アカウントで認証するために必要です。
public_repoスコープのみを選択します。- 作成したアクセス トークンを後で使用できるように安全な場所に保存します。
anthos-samplesリポジトリを自分の GitHub アカウントにフォークします。- anthos-samples リポジトリに移動します。
- ページの右上にある フォーク アイコンをクリックします。
- リポジトリのフォーク先の GitHub ユーザー アカウントをクリックします。anthos-samples リポジトリのフォークされたバージョンのページに自動的にリダイレクトされます。
ローカル環境でターミナルを開きます。
次のコマンドを実行して、フォークされたリポジトリのクローンを作成します。ここで、GITHUB_USERNAME は GitHub アカウントのユーザー名です。
git clone https://github.com/GITHUB_USERNAME/anthos-samples cd anthos-samples/anthos-bm-edge-deployment
ワークステーション環境を設定する
このドキュメントで説明するエッジデプロイを完了するには、インターネットにアクセスできる 1 つのワークステーションと、次のツールのインストールが必要です。
- Docker
- envsubst コマンドライン インターフェース ツール（通常は、Linux やその他の Unix 系 OS にプリインストールされています）
このチュートリアルで構成したワークステーション上のチュートリアルのすべてのコマンドを実行します。
ワークステーションで新しいシェル インスタンスの環境変数を初期化します。
export PROJECT_ID="PROJECT_ID" export REGION="us-central1" export ZONE="us-central1-a" # port on the admin Compute Engine instance you use to set up an nginx proxy # this allows to reach the workloads inside the cluster via the VM IP export PROXY_PORT="8082" # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes export GCE_COUNT="3" # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples" # this is the username used to authenticate to your fork of this repository export SCM_TOKEN_USER="GITHUB_USERNAME" # access token created in the earlier step export SCM_TOKEN_TOKEN="ACCESS_TOKEN"次の値を置き換えます。
- PROJECT_ID: Google Cloud プロジェクト ID。
- GITHUB_USERNAME: GitHub のユーザー名。
- ACCESS_TOKEN: GitHub リポジトリ用に作成した個人用アクセス トークン。
他の環境変数はデフォルト値のままにします。詳細については、以降のセクションで説明します。
ワークステーションで、Google Cloud CLI を初期化します。
gcloud config set project "${PROJECT_ID}" gcloud services enable compute.googleapis.com gcloud config set compute/region "${REGION}" gcloud config set compute/zone "${ZONE}"ワークステーションで、Compute Engine インスタンス用の Google Cloud サービス アカウントを作成します。このスクリプトは、新しい Google サービス アカウントの JSON キーファイルを
<REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.jsonに作成します。また、Cloud Key Management Service のキーリングと、SSH 秘密鍵の暗号化用の鍵も設定します。./scripts/create-primary-gsa.shスクリプトの一部を以下に示します。スクリプト全体を表示するには
View on GitHubリンクをクリックします。
Compute Engine インスタンスをプロビジョニングする
このセクションでは、Anthos clusters on bare metal をインストールする Compute Engine VM を作成します。また、インストール セクションに進む前に、これらの VM への接続を確認します。
ワークステーションで、Compute Engine インスタンス間の通信に使用する SSH 認証鍵を作成します。
ssh-keygen -f ./build-artifacts/consumer-edge-machineCloud Key Management Service を使用して SSH 秘密鍵を暗号化します。
gcloud kms encrypt \ --key gdc-ssh-key \ --keyring gdc-ce-keyring \ --location global \ --plaintext-file build-artifacts/consumer-edge-machine \ --ciphertext-file build-artifacts/consumer-edge-machine.encrypted環境構成ファイル
.envrcを生成し、これをソースにします。作成後、.envrcファイルを検査して、環境変数が正しい値に置き換えられていることを確認します。envsubst < templates/envrc-template.sh > .envrc source .envrctemplates/envrc-template.shファイルの環境変数を置き換えて生成された.envrcファイルの例を次に示します。更新された行はハイライト表示されています。Anthos on bare metal がインストールされている Compute Engine インスタンスを作成します。
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
Ansible で Anthos clusters on bare metal をインストールする
このガイドで使用するスクリプトでは、3 つの Compute Engine インスタンスのグループに Anthos on bare metal クラスタを作成します。作成されるクラスタの数は、GCE_COUNT 環境変数によって制御されます。たとえば、環境変数 GCE_COUNT を 6 に設定して、それぞれ 3 つのインスタンスを持つ Anthos on bare metal クラスタを 2 つ作成します。デフォルトでは、GCE_COUNT 環境変数は 3 に設定されています。したがって、このガイドでは、3 個の Compute Engine インスタンスを持つ 1 つのクラスタを作成します。これらの VM インスタンスには、接頭辞 cnuc- の後に数字を配置した名前が付けられています。各クラスタの最初の VM インスタンスは、インストールのトリガーとなる管理ワークステーションとして機能します。クラスタには管理ワークステーション VM と同じ名前が付けられます（例: cnuc-1、cnuc-4、cnuc-7）。
Ansible のハンドブックでは次の処理を行います。
docker、bmctl、gcloud、nomosなどの必要なツールを使用して Compute Engine インスタンスを構成します。- 構成した Compute Engine インスタンスに Anthos clusters on bare metal をインストールします。
- Anthos on bare metal のスタンドアロン クラスタを
cnuc-1という名前で作成します。 cnuc-1クラスタを Google Cloud に登録します。- Anthos Config Management を
cnuc-1クラスタにインストールします。 - フォークされたリポジトリの
anthos-bm-edge-deployment/acm-config-sinkにあるクラスタ構成と同期するように Anthos Config Management を構成します。 - クラスタの
Login tokenを生成します。
以下の設定手順を完了して、インストール プロセスを開始します。
ワークステーションで、インストールに使用する Docker イメージを作成します。このイメージには、Ansible、Python、Google Cloud CLI など、インストール プロセスに必要なすべてのツールが含まれています。
gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/ビルドが正常に実行されると、次のような出力が生成されます。
... latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498 DONE ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 2238baa2-1f41-440e-a157-c65900b7666b 2022-08-17T19:28:57+00:00 6M53S gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz gcr.io/my_project/consumer-edge-install (+1 more) SUCCESSテンプレートから Ansible インベントリ ファイルを生成します。
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml以前にビルドされたイメージから Docker コンテナを起動するインストール スクリプトを実行します。スクリプトは内部で Docker を使用して、現在の作業ディレクトリへのボリューム マウントを持つコンテナを生成します。このスクリプトが正常に完了すると、作成した Docker コンテナ内にいるはずです。このコンテナ内から Ansible のインストールをトリガーします。
./install.shスクリプトが正常に実行されると、次のような出力が生成されます。
... Check the values above and if correct, do you want to proceed? (y/N): y Starting the installation Pulling docker install image... ============================== Starting the docker container. You will need to run the following 2 commands (cut-copy-paste) ============================== 1: ./scripts/health-check.sh 2: ansible-playbook all-full-install.yaml -i inventory 3: Type 'exit' to exit the Docker shell after installation ============================== Thank you for using the quick helper script! (you are now inside the Docker shell)Docker コンテナ内から、Compute Engine インスタンスへのアクセスを確認します。
./scripts/health-check.shスクリプトが正常に実行されると、次のような出力が生成されます。
... cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}Docker コンテナ内から、Compute Engine インスタンスに Anthos clusters on bare metal をインストールするための Ansible ハンドブックを実行します。完了すると、クラスタの
Login Tokenが画面に表示されます。ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.logインストールが正常に完了すると、次のような出力が生成されます。
... TASK [abm-login-token : Display login token] ************************************************************************** ok: [cnuc-1] => { "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd 4CwanGlof6s-fbu8" } skipping: [cnuc-2] skipping: [cnuc-3] PLAY RECAP *********************************************************************************************************** cnuc-1 : ok=205 changed=156 unreachable=0 failed=0 skipped=48 rescued=0 ignored=12 cnuc-2 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2 cnuc-3 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2
Google Cloud コンソールで Anthos clusters on bare metal にログインする
Ansible ハンドブックの実行が完了すると、スタンドアロンの Anthos on bare metal クラスタが Compute Engine VM 内にインストールされます。このクラスタは、Connect Agent を介して Google Cloud にも登録されます。ただし、このクラスタの詳細を表示するには、Google Cloud コンソールからクラスタにログインする必要があります。Anthos クラスタにログインするには、次の手順に従います。
前のセクションの Ansible ハンドブックの出力からトークンをコピーします。
Google Cloud コンソールで [Kubernetes クラスタ] ページに移動し、コピーしたトークンを使用して
cnuc-1クラスタにログインします。- クラスタのリストで、
cnuc-1クラスタの横にある [アクション] をクリックし、[ログイン] をクリックします。 - [トークン] を選択し、コピーしたトークンを貼り付けます。
- [ログイン] をクリックします。
- クラスタのリストで、
Google Cloud コンソールで [構成管理] ページに移動し、[Config spec status] を確認します。ステータスが [同期済み] であることを確認します。[同期済み] のステータスは、Anthos Config Management によって GitHub 構成ファイルがデプロイ済みクラスタ
cnuc-1と正常に同期されたことを示しています。
外部トラフィック用のプロキシを構成する
前の手順でインストールした Anthos on bare metal クラスタは、MetalLB というバンドルされたロードバランサを使用します。このロードバランサ サービスには、Virtual Private Cloud（VPC）IP アドレスからのみアクセスできます。外部 IP から受信されたトラフィックをバンドルされたロードバランサにルーティングするには、管理ホスト（cnuc-1）でリバース プロキシ サービスを設定します。このリバース プロキシ サービスを使用すると、管理ホスト（cnuc-1）の外部 IPを介して POS アプリケーションの API サーバーにアクセスできます。
前の手順のインストール スクリプトでは、サンプル構成ファイルとともに NGINX が管理ホストにインストールされました。このファイルを更新してロードバランサ サービスの IP アドレスを使用し、NGINX を再起動します。
ワークステーションで、SSH を使用して管理ワークステーションにログインします。
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1管理ワークステーション内から、API サーバー ロードバランサ サービスにトラフィックをルーティングするように NGINX リバース プロキシを設定します。ロードバランサ タイプの Kubernetes サービスの IP アドレスを取得します。
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)取得した IP アドレスを使用して、テンプレート構成ファイルを更新します。
sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \ /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"NGINX を再起動して、新しい構成が適用されていることを確認します。
sudo systemctl restart nginxNGINX サーバーのステータスが「アクティブ（実行中）」になっていることを確認します。
sudo systemctl status nginxNGINX が正常に実行されると、次のような出力が生成されます。
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago Docs: man:nginx(8) Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 92573 (nginx) Tasks: 17 (limit: 72331) Memory: 13.2M CGroup: /system.slice/nginx.service ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─92574 nginx: worker process ├─92575 nginx: worker process ├─92577 nginx: .... ... ...SSH セッションを終了して管理ワークステーションに移動します。
exitシェル セッションを終了して Docker コンテナに移動します。管理インスタンスを終了しても、引き続きインストールに使用する Docker コンテナ内にいます。
exit
POS アプリケーションにアクセスする
外部プロキシを設定すると、Anthos クラスタ内部で実行されているアプリケーションにアクセスできます。サンプル POS アプリケーションにアクセスするには、次の手順を実行します。
ワークステーションで、Compute Engine の管理インスタンスの外部 IP アドレスを取得し、POS アプリケーションの UI にアクセスします。
EXTERNAL_IP=$(gcloud compute instances list \ --project ${PROJECT_ID} \ --filter="name:cnuc-1" \ --format="get(networkInterfaces[0].accessConfigs[0].natIP)") echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"スクリプトが正常に実行されると、次のような出力が生成されます。
Point the browser to: 34.134.194.84:8082ウェブブラウザを開き、前のコマンドの出力で表示された IP アドレスに移動します。次のサンプル スクリーンショットに示すように、サンプルの POS アプリケーションにアクセスしてテストできます。
Anthos Config Management を使用して API サーバーを更新する
ルート リポジトリ内の構成ファイルを更新することで、サンプル アプリケーションを新しいバージョンにアップグレードできます。Anthos Config Management は更新を検出し、クラスタを自動的に変更します。この例では、ルート リポジトリは、このガイドの最初にクローンを作成した anthos-samples リポジトリです。サンプル POS アプリケーションで新しいバージョンへのアップグレードをデプロイする方法については、次の手順をご覧ください。
ワークステーションで、
imageフィールドを更新して API Server のバージョンをv1からv2に変更します。Deployment の YAML 構成は、anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yamlのファイルにあります。フォークされたリポジトリに変更を追加して commit し、push します。
git add acm-config-sink/namespaces/pos/api-server.yaml git commit -m "chore: updated api-server version to v2" git pushGoogle Cloud コンソールで [構成管理] ページに移動し、[Config spec status] を確認します。ステータスが [同期済み] であることを確認します。
Google Cloud コンソールで Kubernetes Engine の [ワークロード] ページに移動し、[Deployment] が更新されていることを確認します。
[デプロイ] のステータスが [OK] になったら、前のセクションの IP アドレスにブラウザでアクセスして POS アプリケーションを表示します。次の例のスクリーンショットに示されているように、タイトルに記載されているバージョンは「V2」であり、アプリケーションの変更がデプロイされたことを示しています。
注: 変更を確認するには、ブラウザタブのハード更新が必要になる場合があります。
クリーンアップ
不要な Google Cloud 料金が発生しないようにするには、このチュートリアルが終了したら、このガイドで使用したリソースを削除します。これらのリソースは手動で削除できます。または、Google Cloud プロジェクトを削除すると、すべてのリソースも削除されます。また、ローカル ワークステーションで行った変更をクリーンアップすることもできます。
ローカル ワークステーション
インストール スクリプトによる変更をクリアするには、次のファイルを更新する必要があります。
/etc/hostsファイルに追加された Compute Engine VM の IP アドレスを削除します。~/.ssh/configファイルからcnuc-*の SSH 構成を削除します。- Compute Engine VM フィンガープリントを
~/.ssh/known_hostsファイルから削除します。
プロジェクトを削除する
この手順専用のプロジェクトを作成した場合は、Google Cloud コンソールから Google Cloud プロジェクトを削除します。
手動
この手順で既存のプロジェクトを使用した場合は、次の操作を行います。
- 名前が
cnuc-で始まるすべての Kubernetes クラスタの登録を解除します。 - 名前が
cnuc-で始まるすべての Compute Engine VM を削除します。 - 名前が
abm-edge-bootで始まる Cloud Storage バケットを削除します。 - ファイアウォール ルール
allow-pod-ingressとallow-pod-egressを削除します。 - Secret Manager のシークレット
install-pub-keyを削除します。
次のステップ
このガイドを拡張するには、別のエッジ ロケーションを追加します。GCE_COUNT 環境変数を 6 に設定し、前のセクションと同じ手順を再実行すると、3 つの新しい Compute Engine インスタンス（cnuc-4、cnuc-5、cnuc-6）と、cnuc-4 と呼ばれる Anthos on bare metal の新しいスタンドアロン クラスタが作成されます。
また、フォークされたリポジトリでクラスタ構成の更新を試行し、ClusterSelectors を使用して POS アプリケーションの異なるバージョンを 2 つのクラスタ（cnuc-1 と cnuc-4）に選択的に適用することもできます。
このガイドの各ステップ、関連するスクリプトの詳細については、anthos-samples リポジトリをご覧ください。