1. 概要
既存のアプリケーションを Kubernetes で動作するように書き直したり、再設計したりすることは、手動では常に可能または実現可能とは限りません。Migrate for Anthos を使用すると、既存のアプリケーションをモダナイズして Kubernetes で実行できます。この Codelab では、Migrate for Anthos を使用して、Compute Engine でホストされている既存のウェブアプリを Kubernetes Engine に移行します。
学習内容
- Kubernetes クラスタに Migrate for Anthos をデプロイする方法
- 既存の Compute Engine インスタンスからステートフル セットにコンテナを作成する方法
- コンテナを Kubernetes にデプロイし、ロードバランサで構成する方法
必要なもの
- 課金が設定されている Google Cloud プロジェクト。お持ちでない場合は、作成する必要があります。
2. 設定方法
この Codelab は、ローカルでのインストールや構成を行わずに、Google Cloud Platform 上で完全に実行できます。
API を有効にする
開始する前に、Google Cloud プロジェクトで必要な API を有効にしてください。
Compute インスタンスのウェブサーバーを作成する
最初の nginx ウェブサーバーをホストするために使用するコンピューティング インスタンスと、ウェブサーバーのデフォルトのランディング ページを表示できるようにするファイアウォール ルールを作成しましょう。これを行う方法はいくつかありますが、使いやすさを考慮して Cloud Shell を使用します。
Cloud Shell で次のコマンドを実行します。
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
このコマンドの前半では、us-central1-a ゾーンに Google Cloud インスタンスが作成されます。後半では、ネットワークへの http トラフィックを許可する「default-allow-http」という名前のファイアウォール ルールが作成されます。
インスタンスが正常に作成されると、インスタンスの詳細を含むテーブルが表示されます。外部 IP をメモします。これは、後でウェブサーバーが実行されていることを確認するために必要になります。
インスタンスが起動して実行されたら、Cloud Shell からインスタンスに SSH 接続して nginx をインストールし、ウェブサーバーを起動します。
gcloud compute ssh --zone us-central1-a webserver
コンピューティング インスタンスにログインしたら、nginx をインストールします。
sudo apt install nginx
logout コマンドを使用して SSH セッションからログアウトする
先ほど取得したインスタンスの外部 IP をブラウザに入力して、ウェブサーバーが実行されていることを確認します。デフォルトの nginx ウェルカム画面が表示されます。
このウェブサーバーは、Migrate for Anthos を使用して Kubernetes に移行するレガシー ウェブアプリとして機能します。
3. Migrate for Anthos を使用した Kubernetes クラスタ
次に、GKE クラスタを作成します。このクラスタに、最終的に Compute Engine ウェブサーバーを移行します。Cloud コンソールで、次のコマンドを実行します。
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
このコマンドが完了するまで数分待ちます。クラスタが作成されると、その詳細を含む出力が表示されます。
次に、GCP Marketplace に移動して Migrate for Anthos をデプロイします。
Migrate for Anthos の Marketplace ページで、[構成] をクリックし、プロンプトが表示されたら、リストからプロジェクトを選択します。次のページには、デフォルト値が入力されたフォームが表示されます。選択したクラスタが先ほど作成したクラスタであることを確認し、[デプロイ] をクリックします。
これで、Migrate for Anthos が Kubernetes クラスタにデプロイされます。デプロイが完了すると、 Kubernetes Engine アプリケーション ページにステータス「OK」が表示されます。
4. コンピューティング インスタンスからステートフル セットへ
Migrate for Anthos を実行する Kubernetes クラスタが用意できたので、移行プロセスを開始できます。コンピューティング インスタンスを Kubernetes クラスタにデプロイするには、ディスクのスナップショットを作成できるように、コンピューティング エンジン インスタンスをシャットダウンします。次に進む前に、後で必要になるインスタンス ID をメモしておきます。
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
コンピューティング インスタンスをシャットダウンしましょう。
gcloud compute instances stop webserver --zone us-central1-a
インスタンスが停止したので、次のスクリプトを実行してディスクのスナップショットを安全に作成できます。必ずプロジェクト ID とインスタンス ID を挿入してください。
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
これらのフラグを指定すると、clone_vm_disks.py は次の処理を行います。
- GCE インスタンスがオフになっていることを確認する
- インスタンスの各ディスクからスナップショットを作成する
- 各スナップショットから新しいディスクを作成する
- 作成したスナップショットを削除する
- 現在の作業ディレクトリに、ウェブサーバーをホストするステートフル セットをデプロイするための YAML ファイルを生成します。
生成された yaml ファイルは、Kubernetes クラスタに ステートフル セットをプロビジョニングします。また、コピーされたディスクをウェブサーバー コンテナにマウントするために必要な永続ボリューム クレームもプロビジョニングします。これらの変更は kubectl で適用できます。
kubectl apply -f containerized-webserver.yaml
[ワークロード] ページで webserver-statefulset のステータスを確認します。
kubectl apply の実行後、数分間ステータスが「Pods are pending」と表示されるのは正常です。ステータスが「OK」と表示されたら、次に進みます。
5. クラスタをロードバランサに公開する
この時点で、Kubenetes クラスタはステートフル セットとしてウェブサーバーを実行しているはずですが、外部 IP アドレスを介してウェブサーバーにアクセスするには、コンテナをロードバランサに公開する必要があります。Cloud Shell で、次の内容を含む loadbalancer.yaml という名前の新しいファイルを作成します。
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
次に、kubectl を使用して適用します。
kubectl apply -f loadbalancer.yaml
kubectl を使用して、webserver-container サービスの外部 IP アドレスを取得できます。
kubectl get services
ブラウザに外部 IP アドレスを入力すると、先ほどと同じデフォルトの nginx ウェルカム画面が表示されます。
やった！これで、GCE ウェブサーバーが Kubernetes でホストされるようになりました。すばらしいですね！
6. Stackdriver Monitoring
指標
マネージド Kubernetes サービスである Kubernetes Engine は、Stackdriver を使用したロギングとモニタリングの両方で自動的に計測されます。Stackdriver が自動的に取得する指標をいくつか見てみましょう。
プロダクト メニューの [モニタリング] リンクをクリックします。プロジェクトから初めてアクセスする場合は、ワークスペースの設定に数分かかることがあります。
読み込みが完了したら、左側のペインで [リソース] にカーソルを合わせ、メニューから [Kubernetes Engine NEW] を選択します。
ここに示されているダッシュボードの各行は、Kubernetes リソースを表しています。ダッシュボードの上にあるリンクを使用して、インフラストラクチャ、ワークロード、サービスのビューを切り替えることができます。
[ワークロード] ビューで、「my-gke-cluster」を開き、default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset の順にドリルダウンします。webserver-stateful set コンテナをクリックします。ここでは、メモリ使用率や CPU 使用率など、Stackdriver によってキャプチャされたすぐに使用できる指標を確認できます。
このダッシュボードに表示されるグラフは、カスタム ダッシュボードの作成に使用できるグラフです。
カスタム ダッシュボード
Stackdriver を使用すると、利用可能な指標データのグラフやグラフを整理するために使用できるカスタム ダッシュボードを作成できます。ウェブサーバーの指標の概要を表示するカスタム ダッシュボードを作成しましょう。
左側のペインで [ダッシュボード] にカーソルを合わせ、[ダッシュボードの作成] をクリックします。
空のダッシュボードが作成されたので、モニタリングする指標を追加できます。[Untitled Dashboard] に「My Web Server Containers」などのわかりやすい名前を付け、右上の [Add Chart] をクリックします。
すぐに使える指標を思い出してください。コンテナの CPU 使用率のグラフを追加しましょう。[グラフのタイトル] フィールドに「CPU 使用率」と入力します。[Find resource type and metric] ボックスに「request_utilization」と入力し、フィルタされたリストから [CPU request utilization] を選択します。この選択により、[Resource type] フィールドと [Metric] フィールドの両方が自動的に入力されます。
次に、project_id（複数のプロジェクトがある場合）と container_name でフィルタします。[フィルタ] ボックスに「project_id」と入力し、フィルタされたリストから選択して、[値] フィールドでプロジェクトを選択します。また、container_name でフィルタリングする必要があります。[フィルタ] ボックスに「container_name」と入力し、フィルタされたリストから選択して、[値] フィールドで webserver-statefulset を選択します。[保存] をクリックします。
これで、最初のグラフを含むダッシュボードが作成されました。
7. 稼働時間チェックとアラート ポリシー
Stackdriver を使用すると、指定したしきい値に指標が達したときに通知するアラートを設定できます。たとえば、前の手順の CPU 使用率が一定のしきい値を一定期間超えた場合に、Stackdriver からメールで通知を受け取ることができます。これは、アプリに問題があることを示している可能性があります。このようなアラートの例を示すため、アップタイム チェックを設定してから、停止をシミュレートしてみましょう。
左側のペインで、[稼働時間チェック]、[稼働時間チェックの概要] の順に選択します。
[稼働時間チェック] ページに表示されているように、最初の稼働時間チェックを設定しましょう。ページの右上にある [Add Uptime Check] ボタンをクリックします。
次のフォームで、タイトルに「Endpoint Uptime」、ホスト名にロードバランサの外部 IP アドレスを入力します。
[保存] をクリックすると、関連するアラート ポリシーの作成を求めるメッセージが表示されます。
[アラート ポリシーを作成] をクリックします。
このポリシーに「Endpoint Uptime Policy」という名前を付けます。[Configuration] セクションで、[Condition triggers if] を [Any time series violates] に設定し、[save] をクリックします。
まだ完了していません。次に、アラート ポリシーに違反した場合に通知されるように、通知チャネルを指定します。[Notification Channel Type] プルダウンで [Email] を選択し、有効なメールアドレスを入力します。
[Add Notification Channel] をクリックします。最後に、フォームの下部でポリシーに「Web App Uptime」という名前を付けて、[保存] をクリックします。
アラートがどのように表示されるかを確認するには、Cloud Console で Cloud Shell をもう一度開きます。次のコマンドは、ウェブサーバー Pod で実行されている nginx サービスを停止します。
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
数分後、停止を知らせるメールが届きます。
元に戻しましょう。Cloud Shell に戻って、nginx を再起動します。
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
数分後、Stackdriver から別のメールが届きます。今回は、前回よりも良いニュースです。
8. クリーンアップ
Migrate for Anthos を使用して GCE から GKE に移行したので、作成したすべてのリソースをプロジェクトから削除しましょう。
プロジェクトを削除する
必要に応じて、プロジェクト全体を削除することもできます。GCP Console で、[Cloud Resource Manager] ページに移動します。
プロジェクト リストで、目的のプロジェクトを選択し、[削除] をクリックします。プロジェクト ID を入力するように求められます。入力して [シャットダウン] をクリックします。
さまざまなコンポーネントを 1 つずつ削除する場合は、次のセクションに進んでください。
Stackdriver
ダッシュボード
ダッシュボード ページで、ページ上部の設定アイコン 
をクリックし、[ダッシュボードを削除] を選択します。
アラート ポリシー
[ポリシー] ページで、作成した各ポリシーの右側にあるアクション メニュー 
から [削除] を選択します。
稼働時間チェック
[Uptime Checks] ページで、作成した各チェックの右側にある [Actions] メニューから [Delete] を選択します。
GCE と Kubernetes
Google Compute Engine インスタンス
gcloud compute instances delete webserver --zone=us-central1-a
Kubernetes クラスタ（Migrate for Anthos、ステートフル セット、ロードバランサ サービスを含む）
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
ディスク
ステートフル セットは、作成したディスクを使用しました。名前を取得するには、次のようにします。
gcloud compute disks list --filter=webserver
ディスク名を自分のディスク名に置き換えて、次のコマンドで削除します。
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
すべて消去しました。
9. 完了
お疲れさまでした。Migrate for Anthos を使用して、ウェブサーバーを GCE インスタンスから Kubernetes クラスタに移行しました。
学習した内容
- Migrate for Anthos を使用して、ウェブサーバーを GCE から Kubernetes クラスタに移行しました
- Kubernetes ロードバランサ サービスを介して公開することで、ステートフル セット ウェブサーバーを世界に公開しました。
- Stackdriver を有効にしてカスタム ダッシュボードを作成しました
- ウェブサーバーがダウンしたときに通知されるように、アラート ポリシーとともに稼働時間チェックを構成しました。