1. 概要
既存のアプリケーションを Kubernetes で動作するように書き換えたり再設計したりすることは、手動では不可能あるいは現実的ではありません。Migrate for Anthos は、既存のアプリケーションをモダナイズし、Kubernetes で実行するのに役立ちます。この Codelab では、Migrate for Anthos を使用して、Compute Engine でホストされている既存のウェブアプリを Kubernetes Engine に移行します。
学習内容
- Migrate for Anthos を Kubernetes クラスタにデプロイする方法
- 既存の Compute Engine インスタンスからステートフル セットにコンテナを作成する方法
- コンテナを Kubernetes にデプロイし、ロードバランサを使用して構成する方法
必要なもの
- お支払い情報が設定された Google Cloud プロジェクト。アカウントがない場合は、アカウントを作成する必要があります。
2. 設定方法
この Codelab は、ローカルにインストールしたり構成したりしなくても、Google Cloud Platform 上で完全に実行できます。
API を有効にする
始める前に、Google Cloud プロジェクトで必要な API を有効にします。
Compute インスタンス ウェブサーバーを作成する
最初の nginx ウェブサーバーをホストするための Compute インスタンスを作成し、ウェブサーバーのデフォルトのランディング ページを表示できるようにするファイアウォール ルールも作成します。いくつかの方法がありますが、使いやすさを考慮して 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 インスタンスを作成し、後半では default-allow-http という名前のファイアウォール ルールを作成します。ネットワークへの HTTP トラフィックを許可します
インスタンスが正常に作成されると、インスタンスの詳細を示すテーブルが表示されます。[外部 IP] をメモしておきます。これは、後でウェブサーバーが稼働していることを確認するために必要になります。
インスタンスが起動したら、Cloud Shell からインスタンスに SSH 接続し、nginx をインストールしてウェブサーバーを起動します。
gcloud compute ssh --zone us-central1-a webserver
Compute インスタンスにログインしたら、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 クラスタにデプロイされます。デプロイが完了すると、ステータスが [OK] になります。 Kubernetes Engine アプリケーションのページに配置します。
4. Compute インスタンスからステートフル セットへ
Migrate for Anthos を実行している Kubernetes クラスタがあるので、移行プロセスを開始できます。Compute Engine インスタンスを Kubenetes クラスタにデプロイするために、Compute Engine インスタンスをシャットダウンして、ディスクのスナップショットを作成できるようにします。次に進む前にインスタンス ID をメモしておきます。この ID は後で必要になります。
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Compute インスタンスをシャットダウンします。
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 のステータスを確認します。
ステータスが「Pod が保留中です」となるのは正常です。kubectl apply を実行してから数分間待機する。ステータスが [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 によって自動的にキャプチャされる指標をいくつか確認しましょう。
プロダクト メニューの [Monitoring] リンクをクリックします。プロジェクトから初めてアクセスする場合、ワークスペースの設定に数分かかることがあります。
読み込まれたら、左側のペインの [Resources] にカーソルを合わせて、[Kubernetes Engine NEW] を選択します。を選択します。
ここに表示されるダッシュボードの各行は、Kubernetes リソースを表します。ダッシュボード上のリンクを使用して、インフラストラクチャ、ワークロード、サービスのビューを切り替えることができます。
[ワークロード] ビューで [my-gke-cluster] を展開します。デフォルトにドリルダウンする >webserver-statefulset >webserver-statefulset-0 >webserver-statefulsetwebserver-stateful set コンテナをクリックします。ここでは、メモリ使用率や CPU 使用率など、すぐに使える指標がいくつか Stackdriver によってキャプチャされています。
このダッシュボードに表示されるグラフは、カスタム ダッシュボードを作成するために使用できるものです。
カスタム ダッシュボード
Stackdriver では、利用可能な指標データのチャートやグラフを整理するために使用できるカスタム ダッシュボードを作成できます。ウェブサーバーの指標を一目で確認できるカスタム ダッシュボードを作成しましょう。
左側のペインで [ダッシュボード] にカーソルを合わせ、[ダッシュボードを作成] をクリックします。
ダッシュボードが空になったので、監視したい指標を追加できるようになりました。無題のダッシュボードに、「My Web Server Containers」のようなわかりやすい名前を付けます。[グラフを追加]ををクリックします。
すぐに使える指標を覚えていますか？コンテナの CPU 使用率のグラフを追加しましょう。[グラフのタイトル] のフィールドに「CPU 使用率」と入力します。[Find resource type and metric] ボックスに「request_utilization」と入力し、フィルタされたリストから CPU リクエスト使用率を選択します。この選択により、[Resource type] フィールドと [Metric] フィールドの両方が自動的に入力されます。
次に、project_id（複数のプロジェクトがある場合）と container_name でフィルタします。[Filter] ボックスに「project_id」と入力し、フィルタされたリストからプロジェクトを選択し、[Value] フィールドでプロジェクトを選択します。container_name でフィルタする必要もあります。[フィルタ] ボックスに「container_name」と入力し、フィルタされたリストからこのコンテナを選択し、[値] フィールドで [webserver-statefulset] を選択します。[保存] をクリックします。
これで、最初のグラフを含むダッシュボードが作成されます。
7. 稼働時間チェックとアラート ポリシー
Stackdriver では、指標が指定したしきい値に達したときに通知するアラートを設定できます。たとえば、最後のステップでの CPU 使用率が一定の時間にわたって一定のしきい値を超えたら、Stackdriver にメールで通知できます。これはアプリに問題があることを示しています。これらのアラートがどのように表示されるかを確認するために、稼働時間チェックを設定してから、サービス停止のシミュレーションを行います。
左側のペインで、[稼働時間チェック]、[稼働時間チェックの概要] の順に選択します。
[稼働時間チェック] ページで示されているように、最初の稼働時間チェックを設定しましょう。ページの右上にある [稼働時間チェックを追加] ボタンをクリックします。
続行フォームに「Endpoint Uptime」と入力します。をタイトル、ロードバランサの外部 IP アドレスをホスト名として使用します。
[保存] をクリックします。付随するアラート ポリシーを作成するように求められます。
[アラート ポリシーを作成] をクリックします。
「Endpoint Uptime Policy」という名前を付けます。[Configuration] セクションで、[Condition trigger if] を設定します。[すべての時系列の違反] を[保存] をクリックします。
まだ改善の余地はありません。次に、通知チャンネルを指定して、アラート ポリシー違反があった場合に通知を受け取るようにします。[Notification Channel Type] プルダウンで、[Email] を選択してから有効なメールアドレスを続けます。
[Add Notification Channel] をクリックします。最後に、フォームの下部でポリシーに「Web App Uptime」という名前を付けます。[保存] をクリックします。
アラートがどのように表示されるかを確認するには、Cloud コンソールで 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
ダッシュボード
ダッシュボード ページで、ページの上部にある設定アイコン 
をクリックし、[ダッシュボードを削除] を選択します。
アラート ポリシー
[Policies] ページで、作成した各ポリシーの右側にある [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 を有効にしてカスタム ダッシュボードを作成し、
- 稼働時間チェックとアラート ポリシーを構成して、ウェブサーバーがダウンしたときに通知されるようにしました