Help us understand the problem. What is going on with this article?

Kubernetes の各リソースに対するメモ

More than 1 year has passed since last update.

(追記): この記事は 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 移行の大きなモチベーション

http://kubernetes.io/docs/user-guide/pods/

PodTemplate

  • Pod を生成するための設定であり直接生成できるリソースではない
  • ReplicaSet, Deployment, Job, ReplicationController などの定義に含まれる

ReplicationController

  • Pod が replicas プロパティで指定された数動いていることを保証する
  • Rolling Update や Blue Green Deployment 等をする際は外から API を叩いて操作する
    • kubectl を通してクライアントから行う
  • ほぼ同等の概念である ReplicaSet によって置き換えられる予定

http://kubernetes.io/docs/user-guide/replication-controller/

Service

  • Label ベースの Pod の集合の特定ポートをサービスとしてアクセス可能にする
  • Kubernetes 内部には環境変数もしくは DNS を通してアクセス可能
    • 環境変数は Docker の link 互換だが動的に更新されないので非推奨
    • DNS は動的に更新される
  • 外部には下記の 2 通りの方法でアクセス可能
    • NodePort: 各 Node の特定ポートを使用
    • LoadBalancer: GCP や AWS などのクラウドプロバイダのロードバランサを自動的に生成

http://kubernetes.io/docs/user-guide/services/

Endpoints

  • Service に内部的に使われる IP アドレスとポートの対の集合

Node

  • Kubernetes クラスタに参加するワーカー
    • 物理マシン
    • VM
  • Pod を動作させるための下記リソースを管理する
    • CPU
    • メモリ
    • GPU
  • ラベルを設定することで Pod の動作対象 Node を絞ることが可能
  • ノード上のエージェントである kubelet からの登録もしくは手動の登録で生成される

http://kubernetes.io/docs/admin/node/

Binding

  • 特定のリソースに対して参照するためのリソースで直接は扱わない

Event

  • Kubernetes 内のイベントで通常扱わない

LimitRange

  • CPU, memory 等、Pod に割り当てられるリソースを制限する
  • デフォルトだと使えるだけ使うので max を指定する
  • min を確保できないと Pod は生成されない

http://kubernetes.io/docs/admin/limitrange/

ResourceQuota

  • Namespace ごとに使用するリソース上限を設定
    • CPU, Memory 等の計算リソース
    • ConfigMap, Pod, Service 等の Kubernetes 上のオブジェクトリソースの数

http://kubernetes.io/docs/admin/resourcequota/

Namespace

  • リソース名の属する名前空間
    • 一部のリソース名は名前空間には属さないので注意
  • DNS で Service を指定する場合は Namespace はサブドメインとして表現
    • Pod の属する Namespace と別の Namespace の Service は FQDN で指定可

http://kubernetes.io/docs/user-guide/namespaces/

Secret

  • 環境によって異なる情報、特に機密情報を扱う
  • 使用方法
    • Pod の環境変数に設定
    • Volume 内のファイルとしてマウント
    • imagePullSecret としてコンテナイメージの pull に使用
  • yaml でマニフェストとして書かなくてもファイルやディレクトリから直接生成可能
  • etcd や API server レベルだと平文なので Kubernetes API へのアクセス権には注意

http://kubernetes.io/docs/user-guide/secrets/

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 としてマウント可能

http://kubernetes.io/docs/user-guide/persistent-volumes/

PersistentVolumeClaim

  • Kubernetes から動的にストレージのリソースを確保するリクエストを表現するリソース
    • CPU やメモリのリソースを動的に確保する Pod に対応する概念
  • GCE の永続ディスクや AWS の EBS を動的に確保できる
  • Pod から Volume としてマウント可能

http://kubernetes.io/docs/user-guide/persistent-volumes/

DeleteOptions

TODO

ComponentStatus

TODO

ConfigMap

  • 環境によって異なる情報で見えても良いものを扱う
  • 使用方法
    • Pod の環境変数に設定
    • Volume 内のファイルとしてマウント

Autoscaling API

HorizontalPodAutoscaler

  • CPU 等のメトリクスに応じて Deployment 等の replicas パラメータを調整することで Pod をオートスケーリング
    • GKE の Node のオートスケーリングとは別 ( こちらは GCE インスタンスグループマネージャによる )
  • cAdvisor を使ってカスタムメトリクスを定義できる

http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/

Batch API

Job

  • 終わることが想定されている仕事をする Pod の集合
    • Pod を保ち続ける ReplicaSet と同レベルの API
  • Pod に含まれるコンテナ内のプロセスが正常終了すると共に終了する
    • 正常終了しなかった場合 Pod を再生成して再試行するので Pod の行う処理は要冪等性
  • 並列ジョブも扱える
  • 1.4 で cron と同様の定期ジョブを扱える ScheduledJob が追加予定

http://kubernetes.io/docs/user-guide/jobs/

Extensions API

Deployment

  • ReplicaSet より高レベルの API として、更新可能な Pod 集合を扱う
    • 通常のサービスの提供を目的とした Pod の生成は主にこれを通して行う
    • 旧 ReplicationController を操作するための kubectl rolling-update 等の宣言的な代替
  • 例として Pod の定義をする template プロパティを変更すると、内部的に新旧の2つの ReplicaSet でローリングアップデート

http://kubernetes.io/docs/user-guide/deployments/

DeploymentRollback

  • Deployment のロールバック時に Deployment 名と Deployment のrevision を持つリソース

HorizontalPodAutoscaler

  • Autoscaling API に移動

Job

  • Batch API に移動

Scale

  • HorizontalAutoScaling の内部で使用?

ThirdPartyResource

  • Kubernetes に機能拡張する際に標準でないリソースタイプを定義
  • 定義したものは Kind に指定可能

https://github.com/kubernetes/kubernetes/blob/master/docs/design/extending-api.md

DaemonSet

  • 全ての Node で動くべき Pod を定義
    • nodeSelector で対象の Node を限定可
  • 対象の例
    • New Relic や Prometheus 等の監視用のエージェント
    • glusterd 等のクラスタストレージのデーモン
    • fluentdlogstash 等のログ収集デーモン

http://kubernetes.io/docs/admin/daemons/

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 がある

http://kubernetes.io/docs/user-guide/replicasets/

NetworkPolicy

  • Pod 間の通信可否を制御する
    • Namespace 内での通信をデフォルトで禁止することが可能
    • Label で指定された特定の Pod 集合ごとにインバウンドに対するホワイトリストが可能

http://kubernetes.io/docs/user-guide/networkpolicies/

Apps(Alpha) API

PetSet

http://kubernetes.io/docs/user-guide/petset/

apstndb
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away