Kubernetes や Docker で MariaDB / MySQL をコンテナ化する場合、/var/lib/mysql をどこに置くかが重要になります。Pod やコンテナは作り直される前提なので、データディレクトリは PVC などの永続領域に逃がします。ただし、外部ボリュームにした瞬間に、初期化処理が権限で止まることがあります。
この記事の位置づけ
この記事は、Kubernetes 上で MariaDB の /var/lib/mysql を永続化する時に、PVC と権限をどう見るかを確認する記事です。主題は StorageClass の選定ではなく、Pod の再作成とデータ永続化を分け、DB プロセスが実際に書ける状態を作ることです。
関連する記事
- Kubernetes に Docker / Podman のような stop/start がない理由
Pod は再作成されるものとして扱い、状態を外に出す前提を確認しています。 - Kubernetes disk-pressure で Pod が起動しない場合
ノードローカルにデータやバックアップを抱えた場合の運用トラブルを確認しています。 - Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する
まず stateless な Pod と Deployment の基本を確認できます。 - Kubernetes 運用設計ガイド
Kubernetes 関連記事全体の入口です。
次に進む
- Kubernetes disk-pressure で Pod が起動しない場合
永続データやバックアップの置き場所がノード逼迫に繋がる場合の切り分けへ進みます。 - Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する
stateless な Pod と Deployment の基本に戻って確認します。
参考書籍
書籍
Kubernetes の仕組み、リソース、ネットワーク、運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
問題になったこと
MariaDB コンテナを自作していた時、単体では正常に起動するのに、/var/lib/mysql を外部ボリュームへ出すと初期データの書き込みが途中で止まり、Pod が起動しなくなりました。
この手の問題は、Kubernetes の永続化そのものが難しいというより、DB コンテナの初期化処理、ボリュームの所有者、実行ユーザー、セキュリティコンテキストが噛み合っていない時に起きます。
原因はパーミッション
原因は複雑な Kubernetes 固有の問題ではなく、ボリューム上の所有者と権限でした。データベースコンテナは、起動時に /var/lib/mysql へ初期データを書き込みます。この時、コンテナ内の実行ユーザーがボリュームへ書けないと初期化に失敗します。
重要なのは、root で書けるかではなく、MariaDB / MySQL のプロセスが実際に動く UID / GID で書けるかです。PVC、hostPath、NFS など保存先の種類によって、所有者やパーミッションの見え方も変わります。
確認すること
- コンテナ内で MariaDB / MySQL がどの UID / GID で動くのか確認する。
- PersistentVolume / hostPath / NFS など、実際の保存先の所有者と権限を確認する。
- 初回起動時に作成されるファイルが途中で止まっていないか確認する。
- root で書けるかではなく、DB プロセスの実行ユーザーで書けるかを見る。
- 必要に応じて
securityContext、fsGroup、initContainer による権限調整を検討する。
確認コマンド
まず Pod のイベントとログを確認し、次にコンテナ内の実行ユーザーと /var/lib/mysql の所有者を見ます。
kubectl describe pod <mariadb-pod>
kubectl logs <mariadb-pod>
kubectl exec -it <mariadb-pod> -- id
kubectl exec -it <mariadb-pod> -- ls -ld /var/lib/mysql
kubectl exec -it <mariadb-pod> -- ls -la /var/lib/mysqlPod が起動直後に落ちる場合は kubectl exec できないこともあります。その場合は、イベント、ログ、PVC / PV、ストレージ側の権限を順に確認します。
Kubernetes 側で考える設定
権限問題を避けるには、イメージ側の実行ユーザー、ボリューム側の所有者、Pod の securityContext を合わせて考えます。環境によっては fsGroup でグループ書き込みを許可したり、initContainer で初回だけ所有者を調整したりします。ただし、NFS や CSI ドライバによっては期待通りに所有者変更できない場合もあるため、ストレージ側の仕様も確認します。
kubectl get pvc
kubectl describe pvc <pvc-name>
kubectl get pv
kubectl describe pv <pv-name>まとめ
Kubernetes の永続化トラブルは、StorageClass や PV / PVC の問題に見えて、実際には単純なパーミッションであることがあります。特に MariaDB / MySQL の /var/lib/mysql は初期化時に書き込みが発生するため、ボリュームの所有者、権限、実行ユーザーを最初に確認するのが近道です。
Pod は作り直されるものですが、DB のデータは作り直されてはいけません。だからこそ、Pod のライフサイクルとデータのライフサイクルを分け、PVC と権限をセットで設計する必要があります。
関連記事
Kubernetes に Docker / Podman のような stop/start がない理由
Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える
Kubernetes 運用設計ガイド
Kubernetes クラスタの初期化 – kubeadm reset の基本
Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する
Kubernetes kubectl の導入 – リモートクラスタを操作する基本
Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ
Kubernetes Helm Chart を自作する意味 – 借り物の Chart と運用責任を分けて考える