ASP.NET Core アプリを Google Kubernetes Engine の Kubernetes にデプロイする

1. 概要

ASP.NET Core は、インターネットに接続された最新のクラウドベースのアプリケーションを C# プログラミング言語を使用してビルドするための、オープンソースの新しいクロスプラットフォーム フレームワークです。

Kubernetes はオープンソースのプロジェクトで、ノートパソコンから可用性の高いマルチノード クラスタ、パブリック クラウドからオンプレミスのデプロイ、仮想マシンからベアメタルまで、さまざまな環境で実行できます。

このラボでは、Kubernetes Engine で動作する Kubernetes にシンプルな ASP.NET Core アプリをデプロイします。この Codelab は、Google Cloud Shell から ASP.NET Core アプリをビルドして起動する Codelab をベースに作成されています。このラボを実行する前に、そのラボを先に完了することをおすすめします。

このコードラボでは、既存のコード（ここではシンプルな Hello World ASP.NET Core アプリ）を変換し、複製済みのアプリケーションとして Kubernetes で実行します。自分のマシンで開発したコードを Docker コンテナ イメージに変換してから、そのイメージを Google Kubernetes Engine で実行します。

次の図はこの Codelab で利用するさまざまなパーツを示しています。全体がどのように構成されるのか理解するのに役立つでしょう。図を参照しながら進めれば、終了する頃には内容をすべて理解できるようになります（現時点で理解できなくても問題ありません）。

この Codelab では、Kubernetes Engine（Google がホストし、Compute Engine で実行される Kubernetes の 1 バージョン）などのマネージド環境を使用するため、基盤となるインフラストラクチャの設定を気にせずに Kubernetes の操作に集中できます。

Kubernetes を開発用のノートパソコンなどのローカルのマシンで実行したい場合は、Minikube について調べることをおすすめします。この機能を使うと、単一ノードの Kubernetes クラスタをシンプルな設定で構築し、開発やテストに利用できます。Minikube をこの Codelab の学習に使用することも可能です。

学習内容

• シンプルな ASP.NET Core アプリを Docker コンテナとしてパッケージ化する
• Google Kubernetes Engine（GKE）に Kubernetes クラスタを作成する方法。
• ASP.NET Core アプリをポッドにデプロイする
• ポッドへの外部トラフィックを許可する
• サービスをスケールアップし、アップグレードをロールアウトする
• Kubernetes グラフィカル ダッシュボードを実行する

必要なもの

• Chrome や Firefox などのブラウザ

このチュートリアルの利用方法をお選びください。

通読するのみ 内容を読んで演習を完了する

Google Cloud Platform のご利用経験について、いずれに該当されますか？

初心者 中級者 上級者

2. 設定と要件

セルフペース型の環境設定

1. Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

• プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この設定はいつでも変更できます。
• プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
• なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

注意: プロジェクト ID はグローバルに一意である必要があります。また、ご自身が選択したプロジェクト ID を他のユーザーが使用することはできません。その ID を使用するのはご自身のみです。プロジェクトを削除しても、その ID を再使用することはできません。

注: Gmail アカウントを使用している場合は、デフォルトの場所の設定は [組織なし] のままにしてかまいません。Google Workspace アカウントを使用している場合は、組織に適した場所を選択してください。

2. 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

Cloud Shell をアクティブにする

1. Cloud Console で、[Cloud Shell をアクティブにする] をクリックします。

Cloud Shell を初めて起動した場合は、その内容を説明する画面が（スクロールしなければ見えない位置に）表示されます。その場合は、[続行] をクリックしてください（以後表示されなくなります）。この中間画面は次のようになります。

すぐにプロビジョニングが実行され、Cloud Shell に接続されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。仮想マシンは Google Cloud で稼働し、永続的なホーム ディレクトリが 5 GB 用意されているため、ネットワークのパフォーマンスと認証が大幅に向上しています。このコードラボでの作業のほとんどは、ブラウザまたは Chromebook から実行できます。

Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自のプロジェクト ID が設定されていることがわかります。

2. Cloud Shell で次のコマンドを実行して、認証されたことを確認します。

gcloud auth list

コマンド出力

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

注: gcloud コマンドライン ツールは、Google Cloud の強力な統合型コマンドライン ツールです。このツールは Cloud Shell にあらかじめインストールされています。タブ補完にも対応しています。詳細については、gcloud コマンドライン ツールの概要をご覧ください。

3. Cloud Shell で次のコマンドを実行して、gcloud コマンドがプロジェクトを認識していることを確認します。

gcloud config list project

コマンド出力

[core]
project = <PROJECT_ID>

上記のようになっていない場合は、次のコマンドで設定できます。

gcloud config set project <PROJECT_ID>

コマンド出力

Updated property [core/project].

3. Cloud Shell で ASP.NET Core アプリを作成する

Cloud Shell のプロンプトで、バージョンを確認して dotnet コマンドライン ツールがインストール済みであることを確認できます。インストールされている dotnet コマンドライン ツールのバージョンが出力されます。

dotnet --version

次に、新しいスケルトン ASP.NET Core ウェブアプリを作成します。

dotnet new mvc -o HelloWorldAspNetCore

これでプロジェクトが作成され、そのプロジェクトの依存関係が復元されます。次のようなメッセージが表示されます。

Restore completed in 11.44 sec for HelloWorldAspNetCore.csproj.

Restore succeeded.

4. ASP.NET Core アプリを実行する

アプリを実行する準備がほぼ整いました。アプリフォルダに移動します。

cd HelloWorldAspNetCore

最後に、アプリを実行します。

dotnet run --urls=http://localhost:8080

アプリケーションがポート 8080 をリッスンします。

Hosting environment: Production
Content root path: /home/atameldev/HelloWorldAspNetCore
Now listening on: http://[::]:8080
Application started. Press Ctrl+C to shut down.

アプリが実行されていることを確認するには、右上にある「ウェブでプレビュー」ボタンをクリックし、[ポート 8080 でプレビュー] を選択します。

デフォルトの ASP.NET Core ウェブページが表示されます。

アプリが実行されていることを確認したら、Ctrl+C キーを押してアプリをシャットダウンします。

5. ASP.NET Core アプリを Docker コンテナとしてパッケージ化する

次に、アプリをコンテナとして実行できるように準備します。最初のステップとして、コンテナとその内容を定義します。

アプリのベース ディレクトリに、Docker イメージを定義する Dockerfile を作成します。

touch Dockerfile

任意のエディタ（vim,、nano,emacs、または Cloud Shell のコードエディタ）を使用して、次のコードを Dockerfile に追加します。

# Use Microsoft's official build .NET image.
# https://hub.docker.com/_/microsoft-dotnet-core-sdk/
FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
WORKDIR /app

# Install production dependencies.
# Copy csproj and restore as distinct layers.
COPY *.csproj ./
RUN dotnet restore

# Copy local code to the container image.
COPY . ./
WORKDIR /app

# Build a release artifact.
RUN dotnet publish -c Release -o out

# Use Microsoft's official runtime .NET image.
# https://hub.docker.com/_/microsoft-dotnet-core-aspnet/
FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine-amd64 AS runtime
WORKDIR /app
COPY --from=build /app/out ./

# Make sure the app binds to port 8080
ENV ASPNETCORE_URLS http://*:8080

# Run the web service on container startup.
ENTRYPOINT ["dotnet", "HelloWorldAspNetCore.dll"]

Dockerfile に含まれる重要な構成として、アプリが受信トラフィックをリッスンするために使用するポート（8080）があります。ポートを指定するには、ASPNETCORE_URLS 環境変数を設定します。ASP.NET Core アプリはこの変数を使用して、どのポートでリッスンするかを決定します。

この Dockerfile を保存します。イメージをビルドします。

docker build -t gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v1 .

これが完了すると（すべてをダウンロードして展開するには時間がかかります）、イメージがビルドされてローカルに保存されていることがわかります。

docker images

REPOSITORY                             TAG   
gcr.io/yourproject-XXXX/hello-dotnet   v1            

次のコマンドを実行して、イメージをローカルでテストします。このコマンドは、新たに作成したコンテナ イメージから Docker コンテナをローカルのポート 8080 で実行します。

docker run -p 8080:8080 gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v1

ここでも Cloud Shell のウェブ プレビュー機能を利用します。

デフォルトの ASP.NET Core ウェブページが新しいタブに表示されます。

アプリが Docker コンテナでローカルに正常に実行されていることを確認したら、Ctrl-> C を使用して実行中のコンテナを停止できます。

イメージが意図どおりに機能することを確認したので、これを Docker イメージ用の非公開リポジトリである Google Container Registry に push します。このリポジトリにはすべての Google Cloud プロジェクトからアクセスできるだけでなく、Google Cloud Platform の外部からもアクセスできます。

docker push gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v1

すべてが正常に完了すると、しばらくしてから [Container Registry] セクションにコンテナ イメージが表示されます。この時点で Docker イメージはプロジェクト全体で使用できる状態になっており、数分後に実演するとおり、Kubernetes からアクセスしてオーケストレートできます。

ここではレジストリ（gcr.io）に汎用のドメインを使用しましたが、使用するゾーンとバケットを指定して範囲を狭めることもできます。詳細については、https://cloud.google.com/container-registry/docs/#pushing_to_the_registry をご覧ください。

必要であれば、https://console.cloud.google.com/storage/browser/ をクリックして、Google Cloud Storage に保存されているコンテナ イメージを一覧表示できます。このリンクは、最終的に https://console.cloud.google.com/project/PROJECT_ID/storage/browser/ のような形式になります。

6. Kubernetes クラスタを作成する

これで GKE クラスタを作成する準備が整いました。ただし、その前にウェブ コンソールの Google Kubernetes Engine セクションに移動し、システムが初期化されるまで待ちます（数秒で完了します）。

クラスタは、Google が管理する Kubernetes マスター API サーバーと、一連のワーカーノードから構成されます。ワーカーノードは Compute Engine 仮想マシンです。

CloudShell セッションから gcloud CLI を使用してクラスタを作成しましょう。ゾーンを近くのゾーン（ゾーンのリスト）に調整します。完了するまでに数分かかります。

gcloud container clusters create hello-dotnet-cluster --cluster-version=latest --num-nodes 4 --zone europe-west1-b

最終的に、作成されたクラスタが表示されます。

Creating cluster hello-dotnet-cluster...done.
Created [https://container.googleapis.com/v1/projects/dotnet-atamel/zones/europe-west1-b/clusters/hello-dotnet-cluster].
kubeconfig entry generated for hello-dotnet-cluster.
NAME                  ZONE            MASTER_VERSION  
hello-dotnet-cluster  europe-west1-b  1.10.7-gke.6

または、上記のコンソールからこのクラスタを作成することもできます。[Compute] > [Kubernetes Engine] > [コンテナ クラスタ] > [コンテナ クラスタを作成]。

クラスタを別のゾーンに作成することもできますが、Container Registry で使用されるストレージ バケットと同じリージョンに配置することをおすすめします（前のステップを参照）。

これで、Google Kubernetes Engine を搭載した、完全版の Kubernetes クラスタが作成されました。

次に、コンテナ化されたアプリケーションを Kubernetes クラスタにデプロイします。ここからは kubectl コマンドライン（Cloud Shell 環境で設定済み）を使用します。この Codelab の残りの部分では、Kubernetes のクライアントとサーバーがどちらもバージョン 1.2 以降である必要があります。kubectl version を実行すると、コマンドの現在のバージョンが表示されます。

7. デプロイを作成する

Kubernetes ポッドは管理とネットワーキングを目的に結合されたコンテナのグループです。ポッドには 1 つのコンテナを含めることも、複数のコンテナを含めることもできます。ここでは、非公開のコンテナ レジストリに保存されている ASP.NET Core イメージで構築した 1 つのコンテナを使用します。このコンテナは、コンテンツの提供にポート 8080 を使用します。

任意のエディタ（vim, nano,emacs または Cloud Shell のコードエディタ）を使用して hello-dotnet.yaml ファイルを作成し、Pod の Kubernetes Deployment を定義します。

YOUR-PROJECT-ID は、プロジェクトの ID に置き換えてください。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: hello-dotnet
  name: hello-dotnet
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: hello-dotnet
  template:
    metadata:
      labels:
        run: hello-dotnet
    spec:
      containers:
      - name: hello-dotnet
        image: gcr.io/YOUR-PROJECT-ID/hello-dotnet:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

kubectl を使用してデフォルトの Namespace にデプロイします。

kubectl apply -f hello-dotnet.yaml

deployment.apps/hello-dotnet created

これで Deployment オブジェクトが作成されました。このオブジェクトは、Pod を作成してスケーリングするためのおすすめの方法です。ここでは、hello-dotnet:v1 イメージを実行する 1 つの Pod レプリカを新しい Deployment で管理します。

作成したデプロイを表示するには、次のコマンドを実行します。

kubectl get deployments

NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-dotnet   1         1         1            1           37s

デプロイによって作成されたポッドを表示するには、次のコマンドを実行します。

kubectl get pods

NAME                         READY     STATUS    RESTARTS   AGE
hello-dotnet-714049816-ztzrb   1/1       Running   0          57s

ここで、便利な kubectl コマンドをいくつか紹介します（いずれもクラスタの状態は変更しません。完全なドキュメントはこちらでご覧いただけます）。

kubectl get pods
kubectl cluster-info
kubectl config view
kubectl get events
kubectl logs <pod-name>

この時点から、コンテナは Kubernetes の制御の下に動作するようになりますが、外部からはまだアクセスできないので、アクセスを許可する必要があります。

8. 外部トラフィックを許可する

デフォルトでは、Pod にはクラスタ内の内部 IP からしかアクセスできません。hello-dotnet コンテナに Kubernetes 仮想ネットワークの外部からアクセスできるようにするには、Pod を Kubernetes Service として公開する必要があります。

Cloud Shell から、--type="LoadBalancer" フラグ付きの kubectl expose コマンドを実行すると、ポッドをインターネットで公開できます。外部からアクセスできる IP を作成するには、このフラグが必要です。

kubectl expose deployment hello-dotnet --type="LoadBalancer" --port=8080

このコマンドで使用しているフラグは、基盤となるインフラストラクチャで提供されるロードバランサ（この場合は Compute Engine のロードバランサ）を使うよう指定しています。ポッドを直接公開するのではなく、デプロイを公開していることに注意してください。これによって、Deployment で管理されるすべての Pod でトラフィックをロードバランスする Service が作成されます（ここでは 1 つの Pod だけですが、後でレプリカを追加します）。

Kubernetes マスターによってロードバランサ、それに関連する Compute Engine 転送ルール、ターゲット プール、ファイアウォール ルールが作成され、Google Cloud Platform の外部からこのサービスに完全にアクセスできるようになります。

サービスのパブリック IP アドレスを確認するには、kubectl をリクエストしてすべてのクラスタ サービスを一覧表示します。

kubectl get services

NAME         CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
hello-dotnet 10.3.253.62   104.155.20.69   8080/TCP    1m
kubernetes   10.3.240.1     <none>           443/TCP    5m

サービスに対して 2 つの IP アドレスが表示されます。いずれもポート 8080 を使用しています。1 つは内部 IP で、Cloud Virtual Network 内でのみ表示されます。もう 1 つは外部負荷分散 IP です。この例では、外部 IP アドレスは 104.155.20.69 です。

EXTERNAL-IP が表示され、使用できるようになるまでには数分かかることがあります。EXTERNAL-IP がない場合は、数分待ってからもう一度試してください。

ブラウザでアドレス http://<EXTERNAL_IP>:8080 を入力すれば、対象の Service にアクセスできるようになります。

この時点で、コンテナと Kubernetes を利用することで、ワークロードを実行するホストを指定する必要がない、Service のモニタリングと再起動ができるなどのメリットが得られるようになりました。それでは、新しい Kubernetes インフラストラクチャを利用することで得られるその他のメリットについて見ていきましょう。

9. サービスをスケーリングする

Kubernetes の優れた特長の一つは、アプリケーションのスケールが容易なことです。アプリケーションの容量を増やす必要が生じた場合は、レプリケーション コントローラに、Pod の新しいレプリカを管理するよう指示するだけで簡単に対応できます。

kubectl scale deployment hello-dotnet --replicas=4

kubectl get deployment
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-dotnet   4         4         4            3           16m

kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
hello-dotnet-714049816-g4azy   1/1       Running   0          1m
hello-dotnet-714049816-rk0u6   1/1       Running   0          1m
hello-dotnet-714049816-sh812   1/1       Running   0          1m
hello-dotnet-714049816-ztzrb   1/1       Running   0          16m

ここでは宣言的アプローチを使用することに注意してください。新しいインスタンスの起動や停止を行うのではなく、常に実行するインスタンスの数を宣言します。Kubernetes の調整ループは、リクエストした内容と実際の状態が一致しているかどうかが照合され、必要に応じて調整が行われます。

次の図に、Kubernetes クラスタの状態をまとめます。

サービスを簡単にスケールダウンすることもできます。4 つの Pod から 2 つの Pod にスケールダウンする方法は次のとおりです。

kubectl scale deployment hello-dotnet --replicas=2

kubectl get pods

NAME                         READY     STATUS    RESTARTS   AGE
hello-dotnet-714049816-g4azy   1/1       Running   0          1m
hello-dotnet-714049816-rk0u6   1/1       Running   0          1m

10. テストの復元性

Kubernetes（より具体的には ReplicaSet）はポッドを監視し、ポッドに問題が発生してダウンすると、すぐに新しいポッドを作成します。実際にテストして、その仕組みを確認してみましょう。

まず、Pod のリストを取得します。

kubectl get pods

NAME                         READY     STATUS    RESTARTS   AGE
hello-dotnet-714049816-g4azy   1/1       Running   0          1m
hello-dotnet-714049816-rk0u6   1/1       Running   0          1m

Pod 名を渡して、Pod のいずれかを削除します。

kubectl delete pod hello-dotnet-714049816-g4azy

Pod のリストを再度確認すると、新しい Pod が作成され、すぐに実行されていることがわかります。

kubectl get pods

NAME                         READY     STATUS           RESTARTS   AGE
hello-dotnet-714049816-abczy   1/1    ContainerCreating  0          1m
hello-dotnet-714049816-rk0u6   1/1    Running            0          1m

11. サービスへのアップグレードをロールアウトする

本番環境にデプロイしたアプリケーションは、いずれかの時点でバグ修正や追加機能の実装が必要になります。そのプロセスを見てみましょう。

まず、アプリケーションを修正しましょう。Cloud Shell からコードエディタを開きます。

HelloWorldAspNetCore > Views > Home の Index.cshtml に移動し、カルーセル メッセージの 1 つを更新します。

次の行を探します。

Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core 

これを次のように変更します。

Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core on Google Cloud

変更を保存して Cloud Shell に戻ります。HelloWorldAspNetCore, 内で Docker イメージをビルドします。

docker build -t gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v2 . 

Container Registry に push します。

docker push gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v2 

更新されたこのイメージの構築と push は、キャッシュを最大限に活用して迅速に行います。

これで、Kubernetes がレプリケーション コントローラを新しいバージョンのアプリケーションにスムーズに更新する準備が整いました。コンテナの実行中にイメージラベルを変更するには、既存の hello-dotnet deployment を編集し、イメージを gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v1 から gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v2 に変更する必要があります。

これを行うには、kubectl edit コマンドを使用します。テキスト エディタが開かれ、デプロイの yaml 構成全体が表示されます。今の時点で yaml 構成全体を理解する必要はありません。構成内で spec.template.spec.containers.image フィールドを更新し、ポッドを更新して新しいイメージを使用するようにデプロイに伝える方法を理解すれば十分です。

kubectl edit deployment hello-dotnet

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: 2017-01-06T10:05:28Z
  generation: 3
  labels:
    run: hello-dotnet
  name: hello-dotnet
  namespace: default
  resourceVersion: "151017"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/hello-dotnet
  uid: 981fe302-f1e9-11e5-9a78-42010af00005
spec:
  replicas: 4
  selector:
    matchLabels:
      run: hello-dotnet
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: hello-dotnet
    spec:
      containers:
      - image: gcr.io/PROJECT_ID/hello-dotnet:v1 # Update this line
        imagePullPolicy: IfNotPresent
        name: hello-dotnet
        ports:
        - containerPort: 8080
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30

変更を行ったら、ファイルを保存して閉じます（ここでは vi を使用しているので、Esc キーを押してから「:wq」と入力し、Enter キーを押します）。

deployment "hello-dotnet" edited

これにより、デプロイが新しいイメージで更新され、新しいイメージで新しい Pod が作成され、古い Pod は削除されます。

kubectl get deployments

NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-dotnet   4         5         4            3           1h

更新の実行中、ユーザーがサービスの利用を中断する必要はありません。しばらくすると、アプリケーションの新しいバージョンにアクセスできるようになります。

ローリング アップデートの詳細については、Kubernetes のドキュメントをご覧ください。

GKE または Kubernetes クラスタを設定すると、以上のようなデプロイ、スケーリング、更新の機能のおかげで、インフラストラクチャの管理を気にせずにアプリケーションに集中できるようになります。

12. Cloud Build

これまでは、通常の Docker コマンド（docker build ...）を使用してコンテナをビルドし、イメージを Google Cloud Platform の Container Registry に手動で push していました。両方のステップをサーバーサイドの Cloud Build に延期することもできます。これにより、Docker をローカルにインストールしなくても、コンテナ イメージをビルドして push できます。

まず、[API Manager] > [ライブラリ] で Cloud Build API を有効にします。Cloud Build を検索し、[Cloud Build API] をクリックします。

API がまだ有効になっていない場合は、[API を有効にする] をクリックします。最終的に、API が次のように有効になっているはずです。

Cloud Build API を有効にしたら、次のコマンドを実行して、Container Builder サービスからイメージをビルドして push できます。

$ gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/hello-dotnet:v3

イメージは Container Registry に自動的に保存されます。

13. Kubernetes グラフィカル ダッシュボードを実行する

Kubernetes の最新のバージョンにはグラフィカル ウェブ ユーザー インターフェース（ダッシュボード）が導入されています。このユーザー インターフェースを使用すると、システムをすぐに利用することができ、CLI にある機能をすばやく見つけて操作することができます。

Cloud Shell ウィンドウから Kubernetes クラスタ ダッシュボードへのアクセスを構成するには、次のコマンドを入力します。

gcloud container clusters get-credentials hello-dotnet-cluster \
    --zone europe-west1-b --project ${GOOGLE_CLOUD_PROJECT}

kubectl proxy --port 8081

Cloud Shell のプレビュー機能をもう一度使用して、ポート 8081 に移動します。

これによって、API エンドポイントに移動するはずです。「Unauthorized」ページが表示されることがありますが、ご心配にはおよびません。ダッシュボードを開くには、"?authuser=3" を削除し、"/ui" に置き換えます。

Kubernetes グラフィカル ダッシュボードを使用して、コンテナ化されたアプリケーションのデプロイや、クラスタのモニタリングと管理を行いましょう。

または開発用のマシンやローカルのマシンからダッシュボードにアクセスすることもできます。ウェブ コンソールで、モニタリングするクラスタの [接続] ボタンをクリックすると、同様の指示が表示されます。

ダッシュボードの操作が完了したら、Control + C を押してプロキシを停止します。Kubernetes ダッシュボードについてさらに詳しくは、ダッシュボード ツアーをご利用ください。

14. ロギング

kubectl logs コマンドを使用すると、Kubernetes 内で実行されているコンテナのログを取得できます。Google Kubernetes Engine を使用してマネージド Kubernetes クラスタを実行すると、すべてのログが自動的に転送され、Google Cloud Logging に保存されます。Google Cloud コンソールで Stackdriver → Logging → Logs に移動すると、Pod からのすべてのログ出力を確認できます。

ロギング コンソールに移動したら、[GKE コンテナ] に移動して、STDOUT から収集されたすべてのログを確認できます。

ここから、必要に応じてログを Google BigQuery にエクスポートしてログ分析をさらに進めるか、ログベースのアラートを設定できます。今日のラボでは、この操作は行いません。

15. 完了

これで ASP.NET Core と Kubernetes を使用するシンプルな入門のコードラボは完了です。ここで学んだのはこのテクノロジーのほんの一部です。ぜひご自分のポッド、レプリケーション コントローラ、サービスを使って実践を継続し、活動状況プローブ（ヘルスチェック）を確認してみてください。Kubernetes API を直接使用することもおすすめします。

クリーンアップ

これで、使用したリソースをクリーンアップします（費用とリソースの節約のため）。

Deployment（実行中の Pod も削除されます）と Service（外部ロードバランサも削除されます）を削除します。

まず、Service と Deployment を削除します。これにより、外部ロードバランサも削除されます。

kubectl delete service,deployment hello-dotnet

service "hello-dotnet" deleted
deployment "hello-dotnet" deleted

次に、クラスタを削除します。

gcloud container clusters delete hello-dotnet-cluster --zone=europe-west1-b

The following clusters will be deleted.
 - [hello-dotnet-cluster] in [europe-west1-b]
Do you want to continue (Y/n)?  Y
Deleting cluster hello-dotnet-cluster...done.                                                                                                                                                                                            
Deleted [https://container.googleapis.com/v1/projects/<PROJECT_ID>/zones/europe-west1-b/clusters/hello-dotnet-cluster].

これにより、クラスタを実行しているすべての Google Compute Engine インスタンスが削除されます。

最後に、イメージをホストしている Docker レジストリ ストレージ バケットを削除します。

gsutil ls

gs://artifacts.<PROJECT_ID>.appspot.com/

gsutil rm -r gs://artifacts.${GOOGLE_CLOUD_PROJECT}.appspot.com/
Removing gs://artifacts.<PROJECT_ID>.appspot.com/...

Removing gs://artifacts.<PROJECT_ID>.appspot.com/...

もちろん、プロジェクト全体を削除することもできますが、その場合は設定した課金設定がすべて失われます（最初にプロジェクトの課金を無効にする必要があります）。また、プロジェクトを削除しても、現在の請求期間が終了するまで、すべての課金は停止されません。

学習した内容

• シンプルな ASP.NET Core アプリを Docker コンテナとしてパッケージ化する
• Google Kubernetes Engine に Kubernetes クラスタを作成する
• ASP.NET Core アプリをポッドにデプロイする
• ポッドへの外部トラフィックを許可する
• サービスをスケールアップし、アップグレードをロールアウトする
• Kubernetes グラフィカル ダッシュボードを実行する

次のステップ

• Kubernetes の詳細（http://kubernetes.io/）を学ぶ
• Google Cloud Platform 上の Windows の詳細を学ぶ
• Google Cloud Platform での .NET の詳細を学ぶ
• Google Cloud Platform 上の SQL サーバーの詳細を学ぶ
• Cloud Tools for Visual Studio の使い方を学ぶ
• Cloud Tools for PowerShell の使い方を学ぶ

ライセンス

この作業はクリエイティブ・コモンズの表示 2.0 汎用ライセンスにより使用許諾されています。