ベアメタル版 Anthos を使用して大規模にクラスタをロールアウトする

この記事では、ベアメタル版 AnthosAnthos Config Management を使用して Kubernetes クラスタを大規模にエッジにデプロイする、プラットフォームのオペレータとデベロッパーのための、直ちに使用可能な高度なソリューションを紹介します。このガイドは、読者が次の内容を理解していることを前提としています。

  • Ansible のハンドブック
  • エッジへのデプロイとその課題。
  • Google Cloud プロジェクトの使用方法。
  • gcloud および kubectl コマンドライン インターフェース。

ベアメタル インフラストラクチャを設定するスクリプトは、anthos-samples リポジトリにあります。スクリプトを使用してこのデプロイを独自に複製し、独自の要件に合わせてカスタマイズできます。エッジ ワークロードを構成するアプリケーションのソースコードは、POS リポジトリにホストされています。

エッジデプロイについて

大規模に運用するための主な特徴として、プラットフォームのすべての部分に一元管理プレーンがあることが挙げられます。しかし、従来のデータセンターを越えてエッジ ロケーションにまで拡大している企業には、独自の要件があります。エッジデプロイでは、ワークロードを独立して実行し、タイムリーに更新を受信して、重要な指標を報告する必要があります。また、今後より多くのエッジ ロケーションに拡張できるように設計されている必要があります。ベアメタル版 Anthos は、このような大規模なエッジデプロイ要件に対する Google の回答です。

バージョン 1.8 以降、ベアメタル版 Anthos クラスタにはシステム プロファイルが付属しています。このプロファイルにより、システム リソースの要件が最小限に抑えられます。リソースに大きな制約があるエッジデバイスにおすすめです。エッジ プロファイルはスタンドアロン クラスタでのみ使用できます。スタンドアロン クラスタは、ワークロードを実行する自己管理クラスタです。リソースが制限されたシナリオで別の管理クラスタを実行する必要性を排除するため、他のクラスタは管理しません。エッジ プロファイルは、ユーザー ワークロードを除く、vCPU と RAM のリソースの最小要件を指定します。ベアメタル版 Anthos のエッジ プロファイルには、次の利点があります。

  • 2 ノード × 4 vCPU から 1 ノード × 2 vCPU へと、CPU 要件が 75% 削減されます。
  • Ubuntu 用のメモリ要件が、2 ノード × 32 GiB から 1 ノード × 4 GiB へと 90% 削減されます。

エッジ プロファイルを使用したクラスタの構成の詳細については、スタンドアロン クラスタの作成をご覧ください。次の表に、エッジデバイスをサポートするフットプリントを小さくするために、ベアメタル版 Anthos の最小システム要件をどのように引き下げたかを示します。

Anthos 1.7 Anthos 1.8 以降 エッジ プロファイルを備えた Anthos 1.8 以降
CPU 2 ノード x (4 vCPU) 1 ノード x (vCPU 4 個) 1 ノード x(vCPU 2 個)
RAM 2 ノード x(32 GiB RAM) 1 ノード x(16 GiB RAM) 1 ノード x(4 GiB RAM Ubuntu)
1 ノード x(6 GiB RAM RHEL/CentOS)
ストレージ 2 ノード x(128 GiB) 1 ノード x(128 GiB) 1 ノード x(128 GiB)

以降のセクションでは、エッジにデプロイされたノードをエミュレートするために、Compute Engine VM とサンプルの POS アプリケーションをエッジ ワークロードとして使用します。ベアメタル版 Anthos クラスタと Anthos Config Management は、エッジクラスタの一元管理を行います。Anthos Config Management は GitHub から新しい構成を動的に pull し、これらのポリシーと構成をクラスタに適用します。

エッジ ロールアウトのアーキテクチャ図

次の図は、エッジデプロイのアーキテクチャを示しています。アプリケーションがベアメタル版 Anthos で実行され、Anthos Config Management によって管理される方法を示しています。この図では、ABM はベアメタル版 Anthos を、ACM は Anthos Config Management を意味します。

アプリケーションをベアメタル版 Anthos で実行し、Anthos Config Management によって管理する方法を示しています。
Anthos Config Management によって管理されるベアメタル版 Anthos エッジデプロイのアーキテクチャ

エッジ ワークロードのアーキテクチャ図

次の図は、このガイドで使用するシンプルな POS アプリケーションのワークロード アーキテクチャを示しています。また、エミュレートしたエッジ ロケーションのベアメタル版 Anthos クラスタにアプリケーションをデプロイする方法についても説明します。Compute Engine VM は、エッジで実行中のノードと類似しています。

POS アプリケーションのアーキテクチャとデプロイ
POS アプリケーションのアーキテクチャ(クリックして拡大)

ソリューションのワークフロー

このソリューションでは、次のことを行います。

  • Compute Engine VM を使用して、エッジ ロケーションで実行されているベアメタル インフラストラクチャをエミュレートします。
  • エミュレートされたエッジ インフラストラクチャに、ベアメタル版 Anthos クラスタをデプロイします。
  • ベアメタル版 Anthos クラスタを Google Cloud に接続して登録します。
  • Anthos on bare metal クラスタにサンプル POS アプリケーションのワークロードをデプロイします。
  • エッジで動作しているアプリケーションをコンソールで検証し、モニタリングします。
  • Anthos Config Management を使用して Anthos on bare metal クラスタで実行されているアプリケーションを更新します。

すべての前提条件(次の始める前にセクションに記載されています)をすでに設定されている場合がある場合は、このガイドを完了するまでの所要時間は最長で 55~60 分です。

始める前に

このガイドで説明するエッジデプロイを完了するには、次の要件を満たしていることが必要です。

ワークステーション環境を設定する

  1. anthos-edge-usecases リポジトリをフォークして、このエッジ デプロイ ソリューションのソースコードのコピーを作成します。リポジトリのフォークの手順など、フォークの詳細については、リポジトリをフォークするをご覧ください。

  2. フォークされたリポジトリに個人用のアクセス トークンを作成します。詳しくは、GitHub ドキュメントの個人用のアクセス トークンの作成をご覧ください。

    • public_repo スコープのみを選択します。
    • 作成したアクセス トークンは、後で必要になるため、安全な場所に保管します。
  3. フォークされたリポジトリのクローンをワークステーションに作成します。

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
    cd anthos-samples/anthos-bm-edge-deployment
    
    • GITHUB_USERNAME は GitHub ユーザー名で置き換えます。
  4. 新しいシェル インスタンスで環境変数を初期化します。

    export PROJECT_ID="PROJECT_ID"
    export REGION="us-central1"
    export ZONE="us-central1-a"
    
    # path to which the Google Service Account key file is downloaded to
    export LOCAL_GSA_FILE="$(pwd)/remote-gsa-key.json"
    
    # port on the admin Compute Engine instance we use to set up an nginx proxy to allow traffic into the Anthos on bare metal cluster
    export PROXY_PORT="8082"
    
    # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
    export MACHINE_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 リポジトリ用に作成した個人用アクセス トークン。
  5. 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}"
    
  6. Compute Engine インスタンスで使用する Google Cloud サービス アカウントを作成します。

    # when prompted "Create a new key for GSA? [y/n]" type "y" and press the return key
    # the service account key file is downloaded to the path referred to by $LOCAL_GSA_FILE
    ./scripts/create-primary-gsa.sh
    

Compute Engine インスタンスをプロビジョニングする

  1. ベアメタル版 Anthos がインストールされている SSH 認証鍵と Compute Engine インスタンスを作成します。

    # press the return key when asked for a passphrase for the SSH key (i.e. empty string)
    ./scripts/cloud/easy-install.sh
    
  2. Compute Engine インスタンスへの SSH 接続をテストします。

    # If the checks fail the first time with errors like
    # "sh: connect to host cnuc-1 port 22: Connection refused",
    # then wait a few seconds and retry
    for i in `seq $MACHINE_COUNT`; do
        HOSTNAME="cnuc-$i"
        ssh abm-admin@${HOSTNAME} 'ping -c 3 google.com'
    done
    

    スクリプトが正常に実行されると、次のような出力が生成されます。

    PING google.com (74.125.124.113) 56(84) bytes of data.
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=1 ttl=115 time=1.10 ms
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=2 ttl=115 time=1.10 ms
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=3 ttl=115 time=0.886 ms
    
    --- google.com ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2003ms
    rtt min/avg/max/mdev = 0.886/1.028/1.102/0.100 ms
    PING google.com (108.177.112.139) 56(84) bytes of data.
    ...
    ...
    

Ansible でベアメタル版 Anthos をインストールする

このガイドで使用するスクリプトでは、3 つの Compute Engine インスタンスのグループにベアメタル版 Anthos クラスタを作成します。たとえば、環境変数 MACHINE_COUNT6 に設定して、それぞれ 3 つのインスタンスを持つベアメタル版 Anthos クラスタを 2 つ作成します。これらのインスタンスには、接頭辞 cnuc- の後に数字を配置した名前が付けられています。各クラスタの最初のインスタンスは、ベアメタル版 Anthos のインストールをトリガーする管理インスタンスとして機能します。また、ベアメタル版 Anthos ユーザー クラスタには、これらの管理インスタンス(例: cnuc-1cnuc-4cnuc-7)の名前が付けられます。

Ansible のハンドブックでは次の処理を行います。

  • dockerbmctlgcloudnomos などの必要なツールを使用して Compute Engine インスタンスを構成します。
  • 構成した Compute Engine インスタンスにベアメタル版 Anthos をインストールします。
  • ベアメタル版 Anthos のユーザー クラスタを cnuc-1 という名前で作成します。
  • cnuc-1 クラスタを Google Cloud に登録します。
  • Anthos Config Management を cnuc-1 クラスタにインストールします。
  • フォークされたリポジトリの anthos-bm-edge-deployment/acm-config-sink にあるクラスタ構成と同期するように Anthos Config Management を構成します。

手順に沿ってインストール プロセスを設定し、開始します。

  1. テンプレートから Ansible インベントリ ファイルを生成します。

    # replace environment variables in the template
    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml
    
  2. ワークステーションの設定と Compute Engine ホストへのアクセスを確認します。

    # verify workstation environment setup
    ./scripts/verify-pre-installation.sh
    
    # verify access to hosts
    ./scripts/health-check.sh
    

    スクリプトが正常に実行されると、次のような出力が生成されます。

    Proceed!!
    
    cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
    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"}
    
    SUCCESS!!
    
  3. Compute Engine インスタンスにベアメタル版 Anthos をインストールするための Ansible プレイブックを実行します。

    ansible-playbook -i inventory cloud-full-install.yaml
    

    スクリプトが正常に実行されると、次のような出力が生成されます。

    ...
    ...
    PLAY RECAP ********************************************************************************************************
    cnuc-1                     : ok=136  changed=106  unreachable=0    failed=0    skipped=33   rescued=0    ignored=8
    cnuc-2                     : ok=86   changed=67   unreachable=0    failed=0    skipped=71   rescued=0    ignored=2
    cnuc-3                     : ok=86   changed=67   unreachable=0    failed=0    skipped=71   rescued=0    ignored=2
    

コンソールで Anthos on bare metal クラスタにログインする

  1. ユーティリティ スクリプトを管理者 Compute Engine インスタンスにコピーして Kubernetes サービス アカウント トークンを生成するには、次のスクリプトとコマンドを実行します。

    # Copy the utility script into the admin node of the cluster
    scp -i ~/.ssh/cnucs-cloud scripts/cloud/cnuc-k8s-login-setup.sh abm-admin@cnuc-1:
    
    # Use SSH to connect to the admin node of the cluster
    ssh -i ~/.ssh/cnucs-cloud abm-admin@cnuc-1
    
    # execute the script and copy token that is printed out
    ./cnuc-k8s-login-setup.sh
    

    スクリプトが正常に実行されると、次のような出力が生成されます。

    ...
    ...
    💡 Retrieving Kubernetes Service Account Token
    
    🚀 ------------------------------TOKEN-------------------------------- 🚀
    eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eyJpc3MiOiJrdW
    mljZS1hY2NvdW50LnVpZCI6IjQwYWQxNDk2LWM2MzEtNDhiNi05YmUxLWY5YzgwODJjYzgzOSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYW
    iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3Nl
    cnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2Vyd
    4CwanGlof6s-fbu8IUy1_bTgCminylNKb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXuaP-hDEKURb5O6IxulTXWH6dxYxg66x
    Njb3VudDpkZWZhdWx0OmVkZ2Etc2EifQ.IXqXwX5pg9RIyNHJZTM6cBKTEWOMfQ4IQQa398f0qwuYlSe12CA1l6P8TInf0S1aood7NJWx
    xe-5ojRvcG8pdOuINq2yHyQ5hM7K7R4h2qRwUznRwuzOp_eXC0z0Yg7VVXCkaqnUR1_NzK7qSu4LJcuLzkCYkFdSnvKIQABHSvfvZMrJP
    Jlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3V
    MgyLOd9FJyhZgjbf-a-3cbDci5YABEzioJlHVnV8GOX_q-MnIagA9-t1KpHA
    🚀 ------------------------------------------------------------------- 🚀
    
  2. 出力からトークンをコピーします。

  3. コンソールで [Kubernetes クラスタ] ページに移動し、コピーしたトークンを使用して cnuc-1 クラスタにログインします。

    [Kubernetes クラスタ] ページに移動

    1. クラスタのリストで、cnuc-1 クラスタの横にある [アクション] をクリックし、[ログイン] をクリックします。
    2. [トークン] を選択し、コピーしたトークンを貼り付けます。
    3. [ログイン] をクリックします。
  4. コンソールで [構成管理] ページに移動し、[Config spec status] を確認します。ステータスが「同期済み」であることを確認します。[同期済み] のステータスは、Anthos Config Management によって GitHub 構成ファイルがデプロイ済みクラスタ cnuc-1 と正常に同期されたことを示しています。

    [構成管理] ページに移動

    Anthos Config Management をソース リポジトリと同期しました。

外部トラフィック用のプロキシを構成する

前の手順でインストールしたベアメタル版 Anthos は、MetalLB というバンドル型ロードバランサを使用します。このロードバランサ サービスには、Virtual Private Cloud(VPC)IP アドレスからのみアクセスできます。そのため、管理ホスト(cnuc-1)にリバース プロキシ サービスを設定して、外部 IP を介して着信するトラフィックをバンドルされたロードバランサに転送します。これにより、管理ホスト(cnuc-1)の外部 IP を介して POS アプリケーションの API サーバーにアクセスできます。

前の手順のインストール スクリプトでは、サンプル構成ファイルとともに管理ホストに nginx がすでにインストールされていました。このファイルを更新してロードバランサ サービスの IP アドレスを使用し、nginx を再起動します。

  1. nginx リバース プロキシを構成して、トラフィックを API サーバーのロードバランサ サービスに転送します。

    # get the IP address of the Load balancer type Kubernetes service
    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
    
    # update the template configuration file with the fetched IP address
    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"
    
    # restart nginx to ensure the new configuration is picked up
    sudo systemctl restart nginx
    
    # check and verify the status of the nginx server to be "active (running)"
    sudo systemctl status nginx
    

    スクリプトが正常に実行されると、次のような出力が生成されます。

    ● 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: ....
                ...
                ...
    
  2. SSH セッションを終了して管理インスタンスに移動します。

    exit
    

POS アプリケーションにアクセスする

次のコマンドは、ローカル ワークステーションで実行されます。

  1. 管理 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
    
    POS アプリケーションのバージョン 1 をデプロイしました。

API サーバーのバージョンを更新して変更を確認する

  1. image フィールドを更新して、API Server のバージョンを v1 から v2 に変更します。Deployment の YAML 構成は、anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml のファイルにあります。

    containers:
    - name: api-server
      image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
  2. フォークされたリポジトリに変更を push します。

    git add acm-config-sink/namespaces/pos/api-server.yaml
    git commit -m "chore: updated api-server version to v2"
    git push
    
  3. コンソールで [構成管理] ページに移動し、[Config spec status] を確認します。ステータスが「同期済み」であることを確認します。

    [構成管理] ページに移動

  4. コンソールで Kubernetes Engine の [ワークロード] ページに移動し、Deployment が更新されていることを確認します。

    Kubernetes Engine の [ワークロード] ページに移動

  5. [デプロイ] のステータスが [OK] になったら、前のセクションの IP アドレスにブラウザでアクセスして POS アプリケーションを表示します。タイトルに記載されているバージョンは「V2」であり、アプリの変更がデプロイされたことを示しています。

    POS アプリケーションのバージョン 2 をデプロイしました。

クリーンアップ

不要な Google Cloud 料金が発生しないようにするには、このチュートリアルが終了したら、このガイドで使用したリソースを削除します。これらのリソースは手動で削除できます。または、Google Cloud プロジェクトを削除すると、すべてのリソースも削除されます。また、ローカル ワークステーションで行った変更をクリーンアップすることもできます。

ローカル ワークステーション

インストール スクリプトによる変更をクリアするには、次のファイルを更新する必要があります。

  • /etc/hosts ファイルに追加された Compute Engine VM の IP アドレスを削除します。
  • ~/.ssh/config ファイルから cnuc-* の SSH 構成を削除します。
  • Compute Engine VM フィンガープリントを ~/.ssh/known_hosts ファイルから削除します。

プロジェクトを削除する

この手順専用のプロジェクトを作成した場合は、コンソールから Google Cloud プロジェクトを削除します。

  • コンソールで [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  • プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  • ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
  • 手動

    この手順で既存のプロジェクトを使用した場合は、次の操作を行います。

    • 名前が cnuc- で始まるすべての Kubernetes クラスタの登録を解除します。
    • 名前が cnuc- で始まるすべての Compute Engine VM を削除します。
    • 名前が abm-edge-boot で始まる Cloud Storage バケットを削除します。
    • ファイアウォール ルール allow-pod-ingressallow-pod-egress を削除します。
    • Secret Manager のシークレット install-pub-key を削除します。

    次のステップ

    このガイドを拡張するには、別のエッジ ロケーションを追加します。MACHINE_COUNT 環境変数を 6 に設定し、前のセクションと同じ手順を再実行すると、3 つの新しい Compute Engine インスタンス(cnuc-4cnuc-5cnuc-6)と、cnuc-4 と呼ばれるベアメタル版 Anthos の新しいユーザー クラスタが作成されます。

    また、フォークされたリポジトリでクラスタ構成の更新を試行し、ClusterSelector を使用して POS アプリケーションの異なるバージョンの 2 つのクラスタ(cnuc-1cnuc-4)に選択的に適用することもできます。

    このガイドの各ステップ、関連するスクリプトの詳細については、anthos-samples リポジトリをご覧ください。