Kubernetesオブジェクトざっくりまとめ
取り上げる Kubernetes オブジェクト
- Node
- Namespace
- Resouce Quota
- Pod
- Controller
- Service
- Volume
- Persistent Volume
- Persistent Volume Claim
- Secret
- Config Map
Node
- Kubernetes が動作するホスト
- Kubernetes のコントロールプレーンで管理される
Pod
- Kubernetes が管理するユニットの最小単位
- Pod はコンテナを複数個持てる
- Pod 内に定義されたコンテナは同じ Node で動作する
- Pod にどのようなコンテナを含めるかはコンテナデザインパターンとか参考にすると良さそう
(Label)
- 各オブジェクトに付与できるキーバリューペア (複数付与可)
- 管理者(使用者)が任意で付与できる、以下例
- 環境ごと分ける (テスト環境・本番環境)
- バージョンで分ける
- ティア(階層)ごと分ける
(Annotation)
各オブジェクトに付与できるメタデータ。
Label は Selector によって検索できるが、Annotation はできない。
(Selector)
- Label を指定してオブジェクトを検索できる
- equality-based selector
-
=
,!=
で Label を指定する- 例:
version = 1.0
- 例:
version = 1.0, env != test
(AND になる)
- 例:
-
- set-based selector
-
in
を利用して、指定した集合から検索する- 例:
version in (1.0, 1,1)
- 例:
env notin (test, production)
- 例:
-
Controller
ポッドを管理するオブジェクト。
複数の Type がある。
- Replication Controller
- ReplicaSet
- Deployment Controller
- StatefulSet
- Job
- DaemonSet
Replication Controller
- 指定した数だけ Pod を複製するオブジェクト
- Pod が少なくても多くても、指定した数になるよう削除・作成する
- 1 つしか Pod を起動しないとしても、Replication Controller 経由で起動すること推奨
- Pod がトラブルによって停止した場合に自動で再起動できるため
- 今は ReplicaSet を使用することが推奨されている?
ReplicaSet
- 次世代の ReplicationController
- Replication Controller は equality-based selector しかサポートしていない
- ReplicaSet は set-based selector を使用できる
Deployment Controller
- ReplicaSet と Pod を管理するオブジェクト
- ReplicaSet(Pod?)のバージョン管理を行える
- ロールアウトアップデートや、ロールバックを実現できる
StatefulSet
- 一意で永続的な ID/名前を Pod に提供するオブジェクト
- 例:
mysql-1
,mysql-2
- 例:
- 作成は 0 から N(指定数)まで行われ、削除は N から 0 まで順に行われる
- 使う意義
- graceful deployment/scaling を提供する (ホットデプロイメント)
- 安定したネットワーク上の識別子を持つ (Pod のホスト名を特定できる)
- PersistentVolume を使用する場合、Pod を再起動しても同じディスクを利用する
Job
- 一つもしくは複数の Pod の開始から終了まで保証する
- type がある
- non-parallel jobs
- paralell jobs with a fixed completion count
- pararell jobs with a work queue
- cron jobs
Daemon Set
全ての Node で指定した Pod を起動する。
(通常の Pod は、どの Node に Pod がデプロイされるか指定できない。)
ログの収集用 Pod などに使用できる。
Service
Podへアクセスするエンドポイントを提供する。
- Type:
- ClusterIP
- NodePort
- LoadBalancer
- ExternalName
ClusterIP
クラスタ内部からのみアクセス可能な IP アドレスを割り当てる
NodePort
各 Node の 30000 から 32767 ポートのどれかを利用して、外部からのアクセスを受け付ける。
ポート番号は各 Node で共通。
アクセス先は1つの Node だが、Service が各 Node にある Pod にアクセスを割り振る。
LoadBalancer
外部のノードバランサを利用する。
(例:GCP や Azure,AWS のロードバランサ)
ExternalName
アクセスを外部のサービスにリダイレクトする。
Volume
- Pod 単位で定義する (Pod 内のコンテナ間で共有)
- Pod と同じライフサイクル (Pod が消えるときに Volume も消える)
- Volume Plugin の特徴に依存する
Volume Plugin
- IaaS
- AWS EBS
- Azure Volume
- vSphere Volume
- GCE Persistent Disk
- Storage Platform
- CephFS
- iSCSI
- RDB
- NFS
- Flocker
- GlusterFS
- 他
- Empty Dir
- Secret
- Host Path
- PVC
- Git Repo
- Downward API
Persistent Volume
- 永続ボリューム
- API によってストレージバックエンド実装を抽象化する
- インフラ上の実ストレージを利用する
- Persistent Volume Plugin によってアクセスモードが異なる
- ReadWriteOnce: 1 つのノードからしか読み書き可
- ReadOnlyMany: 複数のノードから読みのみ
- ReadWriteMany: 複数のノードから読み書き可
Persistent Volume Plugin
- IaaS
- OpenStack Cinder
- AWS EBS
- vSphere Volumes
- Azure File
- GCE Persistent Disk
- Storage Platform
- CephFS
- RDB
- Fibre Channel
- FlexVolume
- GlusterFS
- iSCSI
- NFS
- Host Path
Persistent Volume Claim
- ストレージの要求量とアクセスモードの指定を定義する
- Kubernetes が条件に合う Persistent Volume を見つけて Claim に割り当てる
- (要求量ピッタリのストレージが割り当てられるわけではなく、近い容量のストレージが割り当てられる)
Secret
- Kubernetes に秘密情報を渡す
- パスワード・認証トークン・SSH キーとか
- コンテナは以下の方法で Secret を参照できる
- 環境変数として
- Volume として
ConfigMap
- 設定パラメータをコンテナ外部に配置できる
- キーバリューペア
- ディレクトリ
- 単一ファイル
- コンテナは以下の方法で Secret を参照できる
- 環境変数として
- Volume として
Namespaces
- Kubernetes のほとんどのオブジェクトの名前空間を分離できる
- 各 Namespace に対して Quota を設定できる
Resource Quota
Napespace ごとに以下のリソースを制限できる
- CPU
- Memory
- Storage
- オブジェクトの数