見出し画像

etcd のデータ保存の仕組みとは？「論理キー」と「物理データ」の関係

toshi

Kubernetes の心臓部とも言える etcd。この etcd は、Kubernetes クラスターの状態や設定を管理するために使われていますが、「データはどこにどうやって保存されているの？」という疑問を持ったことはありませんか？

実は etcd には、「論理的なデータ」と「物理的なデータ」 という2つの保存形式が存在します。これらがどのように連携してデータを管理しているのか、身近な例え話を交えながら解説します。

論理的なデータとは？（例: /registry/secrets/web-app/database-access）

Kubernetes は etcd にデータを保存する際、論理的なキー という形で管理します。これは「データの住所」のようなもので、どこに何があるのかを示すラベルです。

例えば、web-app という Namespace にある database-access という名前の Secret は、etcd 内では次のような 論理キー で保存されます：

/registry/secrets/web-app/database-access

  • /registry: Kubernetes のデータが格納される共通のルートパス

  • secrets: リソースの種類（Secret、Pod、Service、ConfigMap など）

  • web-app: Namespace（名前空間）

  • database-access: リソース名

この「キー」があれば、Kubernetes はデータベースの中から必要なリソースの情報を見つけ出し、適切に管理・検索できます。

論理キーの例え話：図書館の目録

論理キーは、まるで図書館の「本の整理番号」や「目録」のようなものです。

図書館では、膨大な数の本が「ジャンル」「著者」「タイトル」などで整理されていますよね？例えば、ある本の情報が次のように整理されているとします：

  • ジャンル: 技術書

  • 著者: Kubernetes

  • タイトル: データ管理の基本

図書館の目録では、これを次のような「住所ラベル」として管理します：

/技術書/Kubernetes/データ管理の基本

これにより、図書館員はこの住所ラベルを頼りに目的の本を見つけられます。

Kubernetes では？
同じように、Secret などのデータは論理キー /registry/secrets/web-app/database-access という形で整理され、管理されています。

物理的なデータとは？（例: /var/lib/etcd）

論理キーで整理されたデータは、実際には etcd の物理データベース に保存されます。その保存場所が /var/lib/etcd です。

この中には、BoltDB というバイナリ形式のデータベースがあり、etcd のデータは効率的に保存・管理されています。

/var/lib/etcd の中身の例

/var/lib/etcd
  ├── member
  │   ├── snap  # データベースのスナップショット
  │   ├── wal   # Write Ahead Log（書き込みログ）
  └── ...

イメージ
「論理的なキー」がデータの住所ラベルなら、/var/lib/etcd にあるデータベースファイルは「倉庫にしまわれた物理的な箱」のようなものです。

「論理キー」と「物理データ」はどう連携している？

例えば、etcdctl コマンドを使って Secret のデータを取得する場合の流れを見てみましょう。

手順: データ取得の流れ

  1. 論理キーを指定
    ユーザーが etcdctl コマンドでデータを取得します：

    1. etcdctl get /registry/secrets/web-app/database-access

  2. etcd が物理データベースを検索
    etcd は /var/lib/etcd 内にあるデータベースファイル（バイナリ形式）を参照し、指定された「論理キー」に対応するデータを探します。

  3. JSON形式のデータを返す
    見つかったデータを JSON 形式でレスポンスとして返します：　

{
  "metadata": {
    "name": "database-access",
    "namespace": "web-app",
    "uid": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
    "creationTimestamp": "2024-06-18T00:00:00Z"
  },
  "data": {
    "username": "YWRtaW4=",
    "password": "cGFzc3dvcmQ="
  }
}


図書館と倉庫の関係

  1. 論理キー /registry/...

    • 図書館の「目録」や「整理番号」：データの場所（住所）を示すラベル。

    • 例: /registry/secrets/web-app/database-access

  2. 物理データ /var/lib/etcd

    • 図書館の「倉庫」や「本棚」に保存されている本そのもの：実際のデータが保存されているバイナリファイル。

  3. データの取り出し（etcdctl コマンド）

    • ユーザーが住所ラベルを指定すると、etcd が倉庫（データベース）から対応するデータを取り出して返します。

まとめ

  • 論理キー（/registry/secrets/web-app/database-access）
    → データの「住所ラベル」。Kubernetes がデータを検索・管理するための識別子。

  • 物理データ（/var/lib/etcd）
    → etcd が実際にデータを保存する物理的なデータベースファイル（BoltDB）。

  • データ取得の流れ

    • ユーザーは論理キーを使ってデータにアクセスする。

    • etcd は物理データベースからデータを探し、結果を返す。

Kubernetes はこの2つの仕組みを使って、効率的なデータ管理と安全なデータ保存を両立しています。図書館の目録と倉庫を思い浮かべると、その仕組みが少し身近に感じられるかもしれませんね。

いいなと思ったら応援しよう！