Helmで展開したWordPressの確認 / AKSの基礎を理解するシリーズ Part. 9

この記事の内容

HelmでAKSに展開したWordPressとMariaDBのPod状態を確認します
StatefulSetとDeployment（ReplicaSet）の違いについて解説します
PersistentVolumeClaimとAzureディスクの関係を確認します
Helmのステータス確認コマンドと外部公開の状態を確認します
Helm環境の削除とPVCのクリーンアップ手順を紹介します

Podの状態確認

まず、HelmでデプロイしたWordPressとMariaDBのPodが正常に動作しているかを確認します。

kubectl get pods

このコマンドを実行すると、WordPressのPodとMariaDBのPodが動作していることを確認できます。

StatefulSetとDeploymentの違い

WordPressはReplicaSetとして管理されているのに対し、MariaDBはStatefulSetとして管理されています。この2つの違いは何でしょうか。

**Deployment（ReplicaSet）**は、状態を持たないステートレスなワークロードを管理します。Podを削除・再作成しても問題がない、いわゆる「使い捨て可能」なコンテナに適しています。WordPressのようなアプリケーション層がこれに該当します。

StatefulSetは、状態を持つステートフルなワークロードを管理します。データベースのように「中身が消えてはいけない」ものに使われます。MariaDBはデータを永続的に保持する必要があるため、StatefulSetとして管理されます。

Kubernetesのダッシュボードやワークロードビューでも、それぞれの分類が確認できます。

ReplicaSet（Deployment） → WordPress
StatefulSet → MariaDB

PersistentVolumeClaimの確認

MariaDBがStatefulSetである理由は「永続的なデータ保存」にあります。StatefulSetには永続ボリューム（PersistentVolume）が紐付けられており、Podが削除されてもデータが消えない仕組みになっています。

MariaDBのStatefulSetの定義を確認してみます。

kubectl get statefulset
kubectl get statefulset maria-db -o yaml > mariadb.yaml
cat mariadb.yaml

定義ファイルの中に persistentVolumeClaim という記述があります。これは「永続的に使えるボリュームをください」というリクエストです。今回は8GBのファイルシステムが要求されており、アクセスモードは ReadWriteOnce（単一ノードからの読み書き）に設定されています。

StorageClassの確認

アクセスモードに応じて、AKSは適切なAzureのストレージサービスを自動的に選択してPodに割り当てます。現在のAKSクラスターで利用可能なストレージの種類は以下のコマンドで確認できます。

kubectl get storageclass

AKS環境では Azure Files や Azure Managed Disk などのストレージクラスが利用可能です。

現在使用中のPersistentVolumeClaimは以下のコマンドで確認できます。

kubectl get pvc

今回は2つのボリュームが使用されていることが確認できます。

Azureポータルでのディスク確認

AKSのインフラストラクチャーリソースグループを確認すると、KubernetesのPVC要求に従って自動的に2つのディスクが作成されていることがわかります。これらのディスクはPodにアタッチされており、コンテナが削除されてもデータは消えない永続的なリソースです。

ディスクの「管理者」を確認すると、VMSS（Virtual Machine Scale Set）の特定のノードに紐付いていることが確認できます。この割り当ては自動的に行われます。

HelmのステータスとWordPressへのアクセス確認

Helmで展開したリソース全体の状態は以下のコマンドで確認できます。

helm ls

特定のリリースの詳細なステータスを確認したい場合は次のコマンドを使います。

helm status <リリース名>
# 例:
helm status handson-aks-wp

また、Pod・Service・その他リソースをまとめて確認するには以下のコマンドが便利です。

kubectl get all

Serviceの状態を確認すると、WordPressはポート80番と443番で外部公開されているのに対し、MariaDBはクラスター内部からのみアクセスできる ClusterIP のみの設定になっています。これはデータベースを外部に直接公開しないための適切な設計です。

LoadBalancerに外部IPが割り当てられており、80番・443番のルールが作成されていることも確認できます。このIPアドレスでWordPressブログにアクセスすると、正常に動作していることを確認できます。

Helm環境の削除とクリーンアップ

動作確認が完了したら、Helmでデプロイしたリソースを削除します。

helm delete handson-aks-wp

このコマンドを実行するだけで、HelmでデプロイしたPodやServiceなどのリソースが削除されます。

ただし、PersistentVolumeClaimはHelmの削除では消えません。残ったPVCを削除するには以下のコマンドを使います。

kubectl delete persistentvolumeclaim --all

注意: --all オプションは対象のNamespace内のすべてのPVCを削除します。本番環境や他のワークロードが存在する場合は、削除対象を慎重に確認してから実行してください。

このコマンドを実行することで、WordPressハンズオン環境のすべてのリソースが削除されます。

まとめ

今回は、HelmでAKSに展開したWordPressとMariaDBの構成を確認しました。重要なポイントを整理します。

MariaDBはStatefulSetとして管理され、データの永続性が保証されています
PersistentVolumeClaimを使うことで、AzureのManaged DiskやAzure Filesが自動的にプロビジョニングされます
**WordPressはDeployment（ReplicaSet）**として管理され、ステートレスなアプリ層として動作します
MariaDBはClusterIPのみで公開され、外部からのアクセスを遮断するセキュアな構成になっています
Helm環境を削除する際は、PVCが自動削除されないため、別途クリーンアップコマンドが必要です

AKSにおけるステートフルなワークロードの扱いと、永続ボリュームの仕組みを理解することで、より複雑なアプリケーションの展開にも応用できます。