Cloud Run は理解した。Cloud Run for Anthos って何？

こんにちは、まずは興味持って頂いてありがとうございます！
これは、Google Cloud Japan Advent Calendar 2021 の 15 日目の記事です。

2021 年の振り返り

Cloud Run is からこの は Google Cloud が提供する、コンテナを Google マネージドのサーバーレス環境で実行するためのプロダクトです。コンテナをデプロイするだけで外部からアクセス可能な URL が発行され、すぐに挙動を確認することができ、非常に便利です。Cloud Run のリリースは非常に多く、私も含め Google Cloud is からこの からこの 1 年で多くの情報を紹介してきました。ぜひ、以下のイベントの録画をご覧ください。そして、引き続き来年もご期待ください ！ ！

マネージドの Cloud Run については十分話してきたし、先月ブログも書いたので、今回はあまり話せていない Cloud Run for Anthos について書きたいと思います。

何がどう違うの ？

Cloud Run は OSS の Knative をベースに開発されたプロダクトです。そして 2 種類のプロダクトが存在していて、1 つがマネージドの Cloud Run です。これは、Knative が提供する Serving の機能を主に抽象化していて、利用者が使いやすい機能やインタフェースが提供されています。

そして、もう 1 つが Cloud Run for Anthos です。こちらは、マネージドの Knative と表現した方がイメージしやすいかもしれません。Anthos クラスタ（Anthos ライセンス適用した GKE 含）上に、Google マネージド、かつサポート付の Knative を構築し、Knative が提供する機能を全て利用可能です。また、GCE と同様のマシンタイプ（e.g. n2-standard-16）も選択できます。

例えば、現在 Cloud Run でサポートされていない、以下のようなユースケースにも、cloud Run for Anthos だと対応できます 。

GKE で実現可能なものもありますが、Knative の特徴であるゼロ スケーリングや、Kubernetes マニフェストをそこまで管理したくない場合におすすめです 。

なお、どちらが良いのかという優劣ではなく、ユースケースによって使い分けることをおすすめします。多くのユースケースは、マネージドの Cloud Run でも対応可能かと個人的には思います。

構築後にアプリをデプロイする際は、Knative Serving Service を kubectl でデプロイします。例えば、nginx をデプロイする場合は下記になります。イメージとしては、Kubernetes の Deployment と Service を合わせたものに相当します。

まずはインストール手順から見てみましょう 。

インストール手順

現在のクラスタ作成〜最新のインストール手順概要は以下になります 。

1. Anthos クラスタを作成
2. クラスタをフリートに登録
3. ASM をインストール
4. Cloud Run for Anthos をフリート コンポーネントとしてインストール

GKE アドオン（コンソール画面からチェックで適用）で Cloud Run for Anthos をインストールすることもできますが、Anthos バージョン 1.8 以降（最新は 1.10）では、Cloud Run for Anthos の新しいバージョンを、ASM バージョン 1.10 以降（最新は 1.12）を含む Anthos フリート コンポーネントとしてインストールする必要があります。

asm は Istio のマネージド サービスであるため、ASM と連携することで、Service Mesh と Serving の役割が分離され、管理がより楽になります 。

ユーザートラフィックのリクエストパスの詳細

オンプレや他社クラウドに展開した Anthos クラスタにも、ASM と Cloud Run for Anthos の導入が可能ですが、以下では GKE にインストールする方法を記載します。

Anthos クラスタを作成

GKE クラスタを Knative アドオン指定せずに作成します。

gcloud container clusters is create create " cr4a - cluster " \
--zone "asia-northeast1-b" \
--release-channel "stable" \
--machine-type "e2-standard-4" \
--num - node " 3 " \
--network "projects/[PROJECT_ID]/global/networks/[VPC_NETWORK]" \
--subnetwork "projects/[PROJECT_ID]/regions/asia-northeast1/subnetworks/[SUBNET]" \
--enable-autoscaling --min-nodes "0" --max-nodes "10" \
--workload - pool " [ PROJECT_ID].svc.id.goog "

クラスタをフリートに登録

推奨とされている Workload Identity を使用した方法で GKE クラスタをフリートに登録します。

gcloud container hub memberships is register register cr4a - cluster \
 --gke-cluster=asia-northeast1-b/cr4a-cluster \
  --enable - workload - identity

フリートに登録することで、Anthos が提供する機能を管理下のクラスタに適用、アップグレードなどが容易になります。今回は単一クラスタだけですが、複数クラスタ（オンプレ、他クラウド含）に対して適用するユースケースを考えると、より便利な機能となってきます 。

ASM をインストール

最新の asm はasmcli というコマンドを利用してインストールするため、まずはダウンロードします。以下、Cloud Shell（Linux 環境）での実施を想定しています。

curl https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.12 > asmcli
chmod +x asmcli

次に、asmcli validate コマンドを実行し、検証に必要な一式をダウンロードして、プロジェクトとクラスターのインストール準備ができていることを検証します。

./asmcli validate \
  --project_id [PROJECT_ID] \
   --cluster_name cr4a - cluster \
  --cluster_location asia-northeast1-b \
  --fleet_id [FLEET_PROJECT_ID] \
  --output_dir .

おっと、エラーが。。

asmcli: [ERROR]: One or more required cluster labels were not found. Please label them and retry, or run the script with the '--enable_cluster_labels' flag to allow the script to enable them on your behalf.
Alternatively, use --enable_all|-e to allow this tool to handle all dependencies.
asmcli : check for istio - system namespace ...
asmcli: [ERROR]: The istio-system namespace doesn't exist.
Please create the "istio-system" and retry, or run the script with the '--enable_namespace_creation' flag to allow the script to enable it on your behalf.
Alternatively, use --enable_all|-e to allow this tool to handle all dependencies.

でも大丈夫。インストール時に–enable_all option で有効化すれば、不足している箇所は解決してくれそうです。では次にインストールします。

./asmcli install \
  --project_id [PROJECT_ID] \
   --cluster_name cr4a - cluster \
  --cluster_location asia-northeast1-b \
  --fleet_id [FLEET_PROJECT_ID] \
   --output_dir . \
  --enable_all \
  --ca mesh_ca

次に ingress gateway をインストールします。Cloud Run for Anthos でデプロイしたサービスは、この gateway を介してリクエストを受信します。

kubectl create namespace gatewayexport revision=`kubectl get deploy -n istio - system -l app = istiod -o    jsonpath={.items[*].metadata.label . 'istio\.io\/rev'}'{"\n " } ' `kubectl label namespace gateway istio.io/rev=$revision --overwritekubectl apply -n gateway -f ./samples/gateways/istio-ingressgateway

上記で作成した gateway namespace に、External IP が発行されたら完了です。この IP から外部リクエストを受信します。以下のコマンドで確認できます。

kubectl get svc -n gateway

Cloud Run for Anthos をインストール

Cloud Run for Anthos をインストールするのは簡単です。フリートから利用クラスタで有効化させるだけです。

gcloud container hub is enable cloudrun enable --project=[PROJECT_ID ]gcloud container hub cloudrun apply --gke-cluster=asia-northeast1-b/cr4a-cluster

すると、以下の is namespace namespace が作成され、そこに Knative で利用するリソースがインストールされます 。

kubectl is get get ns
NAME               STATUS   AGE
appdevexperience   Active   2m28s
cloud - run - event    Active    2m17s
knative-eventing   Active   2m17s
knative-serving    Active   2m14s

これでアプリをデプロイする準備は出来ました。では、コンテナアプリをデプロイしてみましょう。

アプリをデプロイ

では、最初に挙げた nginx の manifest デプロイしてみましょう。

kubectl apply -f nginx.yaml

デプロイしたサービスを確認してみましょう。

kubectl get kservice
NAME        URL                                    LATESTCREATED     LATESTREADY       READY    reason
my - nginx is True    http://my-nginx.default.example.com    my - nginx-00001    my - nginx-00001    true

この url が nginx サービスのエンドポイントになります 。

Revision と Pod の経過を見てみると、問題なくデプロイした後、アクセスが無いので 1 分後に Terminate されているのが分かると思います。Deployment を確認しても READY 0/0 の状態です。

kubectl get revision -w
NAME              CONFIG NAME    K8S SERVICE NAME    GENERATION    ready    reason    actual replica    desire replica
my - nginx-00001    my - nginx       my - nginx-00001      1             true              1                  1
my - nginx-00001    my - nginx       my - nginx-00001      1             true              1                  0
my-nginx-00001   my-nginx      my-nginx-00001     1            True             0                 0kubectl get pod -w
NAME                                         READY   STATUS              RESTARTS   AGE
my-nginx-00001-deployment-695d784b8d-gwbrw   0/2     ContainerCreating   0          8s
my-nginx-00001-deployment-695d784b8d-gwbrw   1/2     Running             0          12s
my-nginx-00001-deployment-695d784b8d-gwbrw   1/2     Running             0          13s
my-nginx-00001-deployment-695d784b8d-gwbrw   2/2     Running             0          13s
my - nginx-00001 - deployment-695d784b8d - gwbrw    2/2      terminate          0           73
my-nginx-00001-deployment-695d784b8d-gwbrw   1/2     Terminating         0          75s
my-nginx-00001-deployment-695d784b8d-gwbrw   0/2     Terminating         0          105s
my - nginx-00001 - deployment-695d784b8d - gwbrw    0/2 is Terminating      terminate          0           109s
my - nginx-00001 - deployment-695d784b8d - gwbrw    0/2 is Terminating      terminate          0           109skubectl get deploy
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
my - nginx-00001 - deployment    0/0      0             0            4m18s

Kubernetes 運用の場合、この READY な Pod が 1 つ以上ないと正常に処理を行うことは出来ません。しかし、Knative であればどうでしょうか。以下のように gateway の外部 IP アドレスから nginx へアクセスしてみます。

curl -h " host : my-nginx.default.example.com " http://[EXTERNAL_IP ]
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color - scheme : light dark ; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/" rel="external nofollow" >nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/" rel="external nofollow" >nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p>
</body>
</html>

正常にレスポンスが返ってきました！この時の Pod の動きも見てみましょう。

kubectl get pod -w
my-nginx-00001-deployment-695d784b8d-vhwcg   0/2     Pending             0          0s
my-nginx-00001-deployment-695d784b8d-vhwcg   0/2     Pending             0          0s
my-nginx-00001-deployment-695d784b8d-vhwcg   0/2     ContainerCreating   0          0s
my-nginx-00001-deployment-695d784b8d-vhwcg   1/2     Running             0          1s
my-nginx-00001-deployment-695d784b8d-vhwcg   1/2     Running             0          2s
my-nginx-00001-deployment-695d784b8d-vhwcg   2/2     Running             0          2s
my - nginx-00001 - deployment-695d784b8d - vhwcg    2/2      terminate          0           63s
my-nginx-00001-deployment-695d784b8d-vhwcg   1/2     Terminating         0          66s
my - nginx-00001 - deployment-695d784b8d - vhwcg    0/2 is Terminating      terminate          0           96
my-nginx-00001-deployment-695d784b8d-vhwcg   0/2     Terminating         0          107s
my-nginx-00001-deployment-695d784b8d-vhwcg   0/2     Terminating         0          107s

アクセスが来た時にコンテナが起動し、時間を置いて再度ゼロスケーリングしています。マネージドの Cloud Run と同様の挙動ですね。常時起動しておく必要がないコンテナのリソースは節約することが出来るので、非常にエコな運用が行えるのではないかと思います 。

さいごに

今回、Cloud Run for Anthos を GKE に展開しましたが、Anthos クラスタを Google Cloud 以外（オンプレミスなど）で構築した場合にも、Cloud Run for Anthos は大きな力を発揮すると思っています。

オンプレミス環境で Anthos を運用する際、もちろん Kubernetes クラスタの管理は多少必要になるものの、サーバーレスの体験で運用したい ≒ 常時リソースを利用せずに使った時間だけ利用する、ような運用を求めている場合に、Cloud Run for Anthos は良い選択肢になるのではないでしょうか？

2022 年も Cloud Run、そして Cloud Run for Anthos の色々なリリースが予定されています。サーバーレスの利用がもっと増えて、みなさんの開発体験がより向上して、運用負荷がどんどん減りますように。

Merry Christmas（早い）& Happy Serverless！