Kubernetesのetcdに保存されるデータの構造ってどうなってるの？
Kubernetesのリソース情報って、実際のところどこにどうやって保存されているんだろう？普段 kubectl get pods なんてコマンドを叩いてリソースを確認するけれど、その裏ではKubernetesのAPIサーバーが etcd というデータストアにアクセスしている。
そして、そのデータは 「特定のパスの形式」 で保存されているんです。
例えば、あるPodの情報は次のようなパスに格納されています。
/registry/pods/default/my-pod
このパスが何を意味しているのか、もう少し詳しく見ていきましょう！
etcdのデータ保存パスの構造
Kubernetesは etcd という分散キーバリューストアを使って、クラスタの状態を保存・管理しています。リソースの情報は特定のキー（パス）の形式で保存されており、それが次のようになっています。
/registry/{リソースの種類}/{名前空間}/{リソース名}
それぞれの部分の意味を見てみましょう。
/registry → すべてのKubernetesリソースが格納されるトップディレクトリ
{リソースの種類} → pods, deployments, services, configmaps など
{名前空間} → default, kube-system, my-namespace など
{リソース名} → 実際のリソースの名前
イメージとしては、ファイルシステムのディレクトリ構造に似ています。たとえば、会社の書類をフォルダで管理するとしたら、こんな感じの整理方法になりますよね。
/documents/contracts/2025/client-a.pdf
このフォーマットがあるおかげで、「どの種類のリソースが、どの名前空間に、どの名前であるのか」 が一目でわかるようになっています。
具体例でイメージしてみよう
(1) Podのデータ保存パス
もし default 名前空間に my-pod というPodがある場合、そのデータは次のパスに保存されます。
/registry/pods/default/my-pod
(2) ConfigMapのデータ保存パス
my-namespace という名前空間に app-config というConfigMapがある場合、こんな感じ。
/registry/configmaps/my-namespace/app-config
(3) ClusterRoleのデータ保存パス
ClusterRole のような「クラスタ全体のリソース」は名前空間に属さないため、{名前空間} の部分が省略されます。
/registry/clusterroles/my-cluster-role
このパスが役に立つ場面
この etcd のパスを直接操作することはあまりないですが、Kubernetesの内部動作を理解したり、トラブルシューティングをするときに役立ちます。
etcdctl で直接データを確認してみよう
もし etcd に直接アクセスできる環境なら、etcdctl を使ってデータを確認することができます。
例えば、default 名前空間にある my-pod のデータを取得するには、次のコマンドを実行します。
etcdctl get /registry/pods/default/my-pod --prefix -w json
これを実行すると、my-pod の情報が JSON形式 で表示されます。
「Kubernetes APIサーバーが裏でどんなデータをやり取りしているのか？」 を知ることで、トラブルが発生したときに kubectl のコマンドだけではわからない問題を発見できるかもしれません。
参考サイト
kubernetesのドキュメント
まとめ
/registry/{リソースの種類}/{名前空間}/{リソース名} という形式で、Kubernetesのリソース情報が etcd に保存されている
名前空間に属するリソース (Pods, ConfigMaps など) は {名前空間} を含むが、クラスタ全体のリソース (ClusterRoles など) は名前空間なしで保存される
etcdctl を使えば、内部のデータ構造を直接確認できる
普段意識することは少ないかもしれませんが、この仕組みを知っておくと 「Kubernetesが裏でどう動いているのか？」 が見えてきて、より深い理解につながりますよ！ 😊