Skip to content
Published on

etcdとKubernetes: API Server統合分析

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

etcdとKubernetes: API Server統合分析

Kubernetes API Serverはetcdを唯一のデータストアとして使用します。この記事ではAPI ServerがetcdをどのUF活用するか、キー構造、Watch Cache、サイジング、暗号化などを分析します。

1. kube-apiserverのetcd使用

1.1 Storage Backend

kube-apiserverはetcd v3 APIを使用してすべてのKubernetesリソースを保存します。Create、Delete、Get、List、Watch、GuaranteedUpdate操作をサポートするストレージインターフェースを通じて操作します。

1.2 Codec（シリアライゼーション）

Kubernetesリソースはetcdに保存される前にシリアライズされます:

  • protobuf: デフォルト保存形式（効率的なバイナリ）
  • JSON: 代替形式（デバッグ容易）

1.3 Transformer（暗号化）

Transformerはetcd保存前/後にデータを変換します: Identity（変換なし）、AES-CBC、AES-GCM、KMS、Secretbox暗号化をサポートします。

2. etcdキー階層構造

2.1 /registry/プレフィックス

すべてのKubernetesリソースは/registry/プレフィックスの下に保存されます:

/registry/pods/default/my-pod
/registry/services/specs/default/kubernetes
/registry/deployments/default/my-deployment
/registry/secrets/default/my-secret
/registry/namespaces/default
/registry/nodes/node-1

2.2 キー構造パターン

ネームスペースリソース: /registry/RESOURCE_TYPE/NAMESPACE/NAME クラスターリソース: /registry/RESOURCE_TYPE/NAME

3. Watch Cache

3.1 Watch Cacheが必要な理由

Watch Cacheなしではすべてのリクエストが直接etcdに送られ、過度な負荷、帯域幅の無駄、スケーラビリティの制限が発生します。

3.2 Cacher構造

type Cacher struct {
    storage     storage.Interface
    watchCache  *watchCache
    reflector   *cache.Reflector
    watchers    indexedWatchers
}

3.3 動作方式

  1. Reflector: API Server起動時に各リソースタイプに対してetcd Watchを設定
  2. Watch Cache: etcdから受信したイベントをリングバッファにキャッシュ
  3. クライアントWatch: クライアントのWatchリクエストはキャッシュからサービス
etcd --[watch]--> Reflector --[events]--> Watch Cache --[events]--> Client Watchers

4. etcdサイジング

クラスター規模ノード数Pod数推奨etcdディスク
小規模10-501000以下3ノード、2CPU、8GB50GB SSD
中規模50-2005000以下3ノード、4CPU、16GB100GB SSD
大規模200-100050000以下5ノード、8CPU、32GB200GB SSD

5. Encryption at Rest

5.1 EncryptionConfiguration

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: BASE64_ENCODED_KEY
      - identity: {}

5.2 プロバイダー優先順位

providers配列の最初のプロバイダーが書き込みに使用され、すべてのプロバイダーが読み取りに使用されます。これによりキーローテーションが可能です。

5.3 KMSプロバイダー（v2）

KMS v2はより効率的なキー管理を提供: ローカルDEK生成/キャッシュ、リモートKEK管理、ローテーション時APIサーバー再起動不要。

5.4 暗号化状態確認

etcdctl get /registry/secrets/default/my-secret | hexdump -C | head
# 暗号化済み: 'k8s:enc:aescbc:v1:key1'プレフィックスが見える
# 未暗号化: 'k8s' protobufプレフィックスが見える

6. API Serverとetcd接続設定

kube-apiserver \
  --etcd-servers=https://etcd1:2379,https://etcd2:2379,https://etcd3:2379 \
  --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \
  --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
  --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key \
  --etcd-compaction-interval=5m \
  --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

7. まとめ

Kubernetes API Serverとetcdの統合はクラスター運用の核心です。Watch Cacheによる効率的なキャッシング、適切なキー構造の理解、Encryption at Rest設定、etcdサイジングは安定的なクラスター運用に不可欠です。etcdの健全性を継続的にモニタリングし、定期的なバックアップとメンテナンスを実行することが重要です。

Discuss on Twitter • View on GitHub