Kubernetes運用前に勉強していること基礎編03-07
注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。
はじめに
Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回は前回の引き続きで、Kubernetesのリソースカテゴリを学ぶことを目的としています。
勉強中の主な内容
- 基礎編
- クラウドネイティブとは
- Kubernetesのアーキテクチャ概要
- Kubernetesのリソース（今回の話）
Config & Storageのリソースについて
Kubernetesは、コンテナという家畜として扱うという考え方がもとにある。
このため、下記の２点が必要である。
- コンテナ自体は いつでも捨てられる
- 捨てても業務が止まらないよう 設定 と 状態 を外だしにする
先ほどの話を、Kubernetes運用では問題になりそうな主なこと４点あげる。
| 課題 | トラブル | 原因 |
|---|---|---|
| 環境変数などの設定がイメージに書き込まれる | 環境ごとに新しいイメージ作成 |
ENV DB_HOST=xxx 直書き |
| 機密がGitで漏洩 | 共同で管理しているソースコード管理ツールへtoken出力 |
.env をpushした事故 |
| 永続ストレージをホスト依存 | ノード障害でデータ消滅でPod がPending |
hostPathの利用 |
| バックアップが形骸化 | スナップショット世代が無限 | 設計漏れ |
Config & Storageのリソースとは
図のような関係になっており、「ConfigMap / Secret」、「Volumes」、「StorageClass と CSI」に分けて理解するとわかりやすい。
ConfigMap / Secret
| 資格 | ConfigMap | Secret |
|---|---|---|
| 用途 | 機密でない設定値・テンプレート | パスワード/API キー/TLSキー |
| サイズ上限 | 1 MiB／obj | 1 MiB／obj |
| デリバリ | ENV / Volume | ENV / tmpfs Volume |
| 取扱注意 | いつでも変更可能 | KMS 暗号化・RBAC 制限 |
運用ポイント
- Secret を守る３段レイヤ
- etcd 静止時暗号化（EKS + KMS）
- Sealed Secrets で Git上暗号化
- External Secrets Operator でランタイム動的取得 (Secrets Manager / Parameter Store)
Volumes
| 種別 | ライフサイクル | 主な用途 |
|---|---|---|
| emptyDir | Pod と同寿命 | キャッシュ / tmp |
| hostPath | ノード依存 | デバッグ / GPU DevFile |
| PV / PVC | クラスタレベル | 永続データ |
StorageClass と CSI
| CSI ドライバ | アクセス | 特徴 |
|---|---|---|
| EBS CSI | RWO | gp3, io2, snapshot |
| EFS CSI | RWX | マルチ AZ / NFSv4 |
設計原則
| # | ルール | Why / How |
|---|---|---|
| 1 | イメージに設定を書かない | ConfigMap / Secret 経由で注入 |
| 2 | IAM & RBAC を Pod 単位に | IRSA + Namespace‑scoped Role |
| 3 | base64以外の暗号化 | etcd→KMS、転送→TLS、Git→Sealed |
| 4 | AZ 拘束遅延 | Deployment + PVC でも Pending 無し |
| 5 | 命名で SLA を示す |
gp3-ssd-prod-rwo, efs-burst-dev
|
| 6 | オンライン拡張前提 | allowVolumeExpansion: true |
| 7 | Snapshot as Code | CronJob + VolumeSnapshot |
| 8 | Configの変化を可視化 | Argo CD diff |
所感
「ConfigMap / Secret 運用」と昔ながらの“データベース管理”は、同じ発想で動いているように思える。なぜなら やっていることは RDB やSAN （Storage Area Network）の設計と本質的に同じだから、ただ、IasCにようにコード化できていることが非常に引き続きを考えると素晴らしい仕組みに思える。
| クラシック DB / SAN の悩み | K8s Config & Storage での対応 | 共通する本質 |
|---|---|---|
| データ量と IOPS を見積もり、RAID/SSD/HDD を選ぶ |
StorageClass 名に gp3/io2/sc1 を明示し、容量・IOPS をパラメータ化 |
ハードウェア特性を抽象化し、論理名で速さ／冗長度を示す |
| スキーマ名やテーブルスペースで可視化 |
gp3-ssd-prod-rwo など “用途＋SLA” を名前に刻む |
運用者にとって直感的なリソース命名 |
| DB 権限 (GRANT/REVOKE) で行レベル保護 | Secret を RoleBinding で最小権限付与 |
「誰が何を見るか」を宣言的 ACL で縛る |
| バックアップ世代管理・WAL ローテーション |
VolumeSnapshot + Velero の世代タグ、自動削除ポリシー |
履歴を保持しつつ、容量爆発を防ぐライフサイクル管理 |
補足
過去の記事で記載していた内容を補足として追記しています。
Kubernetesのリソースカテゴリ
Kubernetesのリソースカテゴリは、『Kubernetes完全ガイド第二版』をベースとしている。
| カテゴリ | 概要 |
|---|---|
|
Workload APIs |
アプリケーション（コンテナ）の実行を管理するためのリソース |
|
Service APIs |
Pod内のコンテナをネットワーク経由で公開し、アクセスを提供するリソース |
|
Config APIs |
コンテナで利用する設定や機密情報を管理するためのリソース |
|
Storage APIs |
コンテナで利用する永続化データを管理するためのリソース |
|
Cluster APIs |
クラスタ内のリソースの運用や管理、セキュリティを制御するリソース |
|
Metadata APIs |
クラスタ内の他リソースの操作や動的なメタデータ管理を行うリソース |