VMware Cloud Foundation 9.1 では、従来は個別の仮想アプライアンスとして提供されていた管理コンポーネントの多くが、Kubernetes ベースの VCF Services Runtime 上で動作するコンテナ化されたサービスへと変わりました。管理画面である VCF Operations から「サービスの停止」を実行したとき、その裏側の Kubernetes 上では実際に何が起きているのでしょうか。
今回は Telemetry コンポーネントを題材に、VCF Operations の画面上での状態確認から、コントロールプレーンノードにログインしての Pod・ReplicaSet の確認、そして実際にサービスを停止した際に ReplicaSet の replicas が 0 になり Pod が停止するまでの流れを検証しました。
1. VCF Operations でコンポーネントの状態を確認する
「ビルド」→「ライフサイクル」→「コンポーネント」内から、VCF Services Runtime をクリックします。
「ノード」の項目から、コントロールプレーンノードとワーカーノードを判別できます。
また、「コンポーネント」の項目から、VCF Services Runtime 配下で動作しているコンポーネントの一覧および実行状態が確認できます。
Telemetry をクリックすると、コンポーネントが起動状態であることを確認できます。
2. コントロールプレーンノードにログインして確認する
ここからは、該当のコントロールプレーンノードに実際にログインして中身を見ていきます。ログインには vmware-system-user を使用し、その後 root に昇格します。
各ノードの状態は次のとおりです。
各コンポーネントが、それぞれ個別の namespace として作成されていることがわかります。
Telemetry のコンポーネントについては、Deployment は存在せず、ReplicaSet が直接作成されており、その配下で Pod が 1 つ動作していることがわかります。
3. ReplicaSet のマニフェストを確認する
続いて、ReplicaSet のマニフェストを確認します。
replicas が 1 となっており、Pod が 1 つ動作する設定であることがわかります。
4. VCF Operations からサービスを停止する
VCF Operations の画面に戻り、Telemetry のサービス停止を実行してみます。
実行すると、確認メッセージが表示されますので、サービスの停止をクリックします。
続いて、シャットダウンが進行中である旨のメッセージが表示されます。
「詳細表示」をクリックすると、実行中のタスクを確認できます。
7 分ほどで、タスクが完了しました。
5. 停止後の状態を確認する
再びコントロールプレーンノード側で確認すると、Pod が動作していない状態になっています。
マニフェスト上も、replicas が 0 に変更されたことが確認できました。
まとめ
VCF Operations の GUI から実行した「サービス停止」は、内部的には該当コンポーネントの ReplicaSet の replicas を 0 に更新する操作として反映されていました。その結果として Pod が停止し、コンポーネントがサービス停止状態になるという流れを、GUI と Kubernetes の両面から確認できました。
VCF 9.1 では管理コンポーネント自体が Kubernetes 上で動作しているため、GUI での操作結果を kubectl で追いかけられる点は、トラブルシューティングの際にも役立つポイントだと感じています。
