(追記): この記事は Kubernetes 1.3 世代という大昔に自分自身の学習過程のメモとして書いたので、現在は全く推奨しません。1.9 準拠の入門 Kubernetes などを足がかりにした上で最新のドキュメントを参照するのがオススメです。
Kubernetes の Glossary について大体目を通したので、これからリソースごとに概要をまとめていく。
この記事は自分自身が API の更新を把握して説明するための資料として API 一覧を軸にまとめる。
別の軸でまとめた Glossary の要約には下記などがあり。
http://qiita.com/t-yotsu/items/f565b2d788a3b98fe762
手始めに Kubernetes 1.3 の API Definitions からトップレベルかつ *List でないものだけ抽出した。
- あるもの
- 各 API 上のリソースに対応するドキュメントへの参照
- 独断と偏見と無知に基づくメモ
- ないもの
- API の使い方
Kubernetes API
Pod
- 処理を行うものとして Kubernetes が扱う最小単位のリソース
- 同じ Node で動作する1つ以上のコンテナで下記を共有
- IP アドレス
- ポート空間
- IPC 空間(セマフォ、共有メモリ)
- 基本的には直接生成せず、ReplicaSet, DaemonSet, Job を通して使用
- 余談として、 Docker では Pod をネイティブにサポートしていないことが rkt 移行の大きなモチベーション
PodTemplate
- Pod を生成するための設定であり直接生成できるリソースではない
- ReplicaSet, Deployment, Job, ReplicationController などの定義に含まれる
ReplicationController
- Pod が replicas プロパティで指定された数動いていることを保証する
- Rolling Update や Blue Green Deployment 等をする際は外から API を叩いて操作する
- kubectl を通してクライアントから行う
- ほぼ同等の概念である ReplicaSet によって置き換えられる予定
Service
- Label ベースの Pod の集合の特定ポートをサービスとしてアクセス可能にする
- Kubernetes 内部には環境変数もしくは DNS を通してアクセス可能
- 環境変数は Docker の link 互換だが動的に更新されないので非推奨
- DNS は動的に更新される
- 外部には下記の 2 通りの方法でアクセス可能
- NodePort: 各 Node の特定ポートを使用
- LoadBalancer: GCP や AWS などのクラウドプロバイダのロードバランサを自動的に生成
Endpoints
- Service に内部的に使われる IP アドレスとポートの対の集合
Node
- Kubernetes クラスタに参加するワーカー
- 物理マシン
- VM
- Pod を動作させるための下記リソースを管理する
- CPU
- メモリ
- GPU
- ラベルを設定することで Pod の動作対象 Node を絞ることが可能
- ノード上のエージェントである kubelet からの登録もしくは手動の登録で生成される
Binding
- 特定のリソースに対して参照するためのリソースで直接は扱わない
Event
- Kubernetes 内のイベントで通常扱わない
LimitRange
- CPU, memory 等、Pod に割り当てられるリソースを制限する
- デフォルトだと使えるだけ使うので max を指定する
- min を確保できないと Pod は生成されない
ResourceQuota
- Namespace ごとに使用するリソース上限を設定
- CPU, Memory 等の計算リソース
- ConfigMap, Pod, Service 等の Kubernetes 上のオブジェクトリソースの数
Namespace
- リソース名の属する名前空間
- 一部のリソース名は名前空間には属さないので注意
- DNS で Service を指定する場合は Namespace はサブドメインとして表現
- Pod の属する Namespace と別の Namespace の Service は FQDN で指定可
Secret
- 環境によって異なる情報、特に機密情報を扱う
- Twelve-Factor App の Config に対応
- 後に認証情報以外の見えても良い情報を扱うための ConfigMap が追加
- 使用方法
- Pod の環境変数に設定
- Volume 内のファイルとしてマウント
-
imagePullSecretとしてコンテナイメージの pull に使用
- yaml でマニフェストとして書かなくてもファイルやディレクトリから直接生成可能
- etcd や API server レベルだと平文なので Kubernetes API へのアクセス権には注意
ServiceAccount
- 人間に結び付けられるユーザアカウントとは違い Pod が属するアイデンティティ
- API への権限設定、コンテナイメージの pull 権限に使われる
- AWS ECS における IAM Roles for Tasks と同等のことに使うには GCP の Service Account と結びつけたいが標準では方法なし？
http://kubernetes.io/docs/admin/service-accounts-admin/
http://kubernetes.io/docs/user-guide/service-accounts/
PersistentVolume
- 確保済のネットワークストレージを表現するリソース
- 予め定義した PersistentVolume を Pod から Volume としてマウント可能
PersistentVolumeClaim
- Kubernetes から動的にストレージのリソースを確保するリクエストを表現するリソース
- CPU やメモリのリソースを動的に確保する Pod に対応する概念
- GCE の永続ディスクや AWS の EBS を動的に確保できる
- Pod から Volume としてマウント可能
DeleteOptions
TODO
ComponentStatus
TODO
ConfigMap
- 環境によって異なる情報で見えても良いものを扱う
- Twelve-Factor App の Config に対応
- 認証情報は Secret で扱う
- 使用方法
- Pod の環境変数に設定
- Volume 内のファイルとしてマウント
Autoscaling API
HorizontalPodAutoscaler
- CPU 等のメトリクスに応じて Deployment 等の replicas パラメータを調整することで Pod をオートスケーリング
- GKE の Node のオートスケーリングとは別 ( こちらは GCE インスタンスグループマネージャによる )
- cAdvisor を使ってカスタムメトリクスを定義できる
Batch API
Job
- 終わることが想定されている仕事をする Pod の集合
- Pod を保ち続ける ReplicaSet と同レベルの API
- Pod に含まれるコンテナ内のプロセスが正常終了すると共に終了する
- 正常終了しなかった場合 Pod を再生成して再試行するので Pod の行う処理は要冪等性
- 並列ジョブも扱える
- 1.4 で cron と同様の定期ジョブを扱える ScheduledJob が追加予定
Extensions API
Deployment
- ReplicaSet より高レベルの API として、更新可能な Pod 集合を扱う
- 通常のサービスの提供を目的とした Pod の生成は主にこれを通して行う
- 旧 ReplicationController を操作するための
kubectl rolling-update等の宣言的な代替
- 例として Pod の定義をする template プロパティを変更すると、内部的に新旧の2つの ReplicaSet でローリングアップデート
DeploymentRollback
- Deployment のロールバック時に Deployment 名と Deployment のrevision を持つリソース
HorizontalPodAutoscaler
- Autoscaling API に移動
Job
- Batch API に移動
Scale
- HorizontalAutoScaling の内部で使用？
ThirdPartyResource
- Kubernetes に機能拡張する際に標準でないリソースタイプを定義
- 定義したものは Kind に指定可能
DaemonSet
- 全ての Node で動くべき Pod を定義
- nodeSelector で対象の Node を限定可
- 対象の例
- New Relic や Prometheus 等の監視用のエージェント
- glusterd 等のクラスタストレージのデーモン
-
fluentdやlogstash等のログ収集デーモン
Ingress
- Service への inbound の経路を扱うリソース
- アドオンにより LB や Proxy 等を Kubernetes の外に作ることが可能
- GCE では Service の type=LoadBalance は L4 LB だが Ingress により L7 LB が生成可能
- バーチャルホストやパスベースの Service への振り分けに対応
GCE 対応について https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md
ReplicaSet
- 一定数の Pod の集合を宣言的に定義
-
.spec.templateで定義した Pod が.spec.replicas個動いている状態が保たれる
-
- 名前が適切でないとされる ReplicationController を置き換える
- 単なるリネームではなくラベルを元にした集合演算ベースのラベルセレクタをサポート
-
kubectl rolling-updateをサポートしない以外は上位互換- 代わりに Deployment がある
NetworkPolicy
- Pod 間の通信可否を制御する
- Namespace 内での通信をデフォルトで禁止することが可能
- Label で指定された特定の Pod 集合ごとにインバウンドに対するホワイトリストが可能
Apps(Alpha) API
PetSet
- Pod の アイデンティティを重要としない ReplicaSet と異なり、アイデンティティを保つ Pod の集合を定義
- アイデンティティの構成要素は DNS から扱えるホスト名と不変の序数、個別に割り当てられるストレージ
- ストレージは PersistentVolumeClaim で動的に割り当て