Kubernetesオブジェクトメモ.md

名前空間

Namespace

• 多様なリソースをグループ分けする機能
• 同じ kind/name の組み合わせのリソースが異なる namespace に存在することができる
  • つまり、 kind/name/namespace の3つ組が unique ならよい
• namespace を階層化する機能は検討中らしい？

計算リソース

Pod

• k8s における処理主体の最小単位。
• 1つのPodは1つ以上のコンテナで構成される。
• 配置されたPodにはPod用のアドレスプールからアドレスが付与される。
  • Podが配置されているノードのアドレスを代わりに使いたい場合は hostNetwork: true とする。ある種のPodではこの設定が必須である（CNIとか）
  • Podが終了した（が、削除されていない）場合に、このアドレスが解放されるかどうかは調べていない（されないってことはないと思うが…）
• 一度作成したら spec を（一部の項目を除き）変更することはできない。配置されたら移動もできない。

ReplicaSet

• 同じ内容のPodを複数個作って維持する機能。Podが何らかの理由で「消えた」場合、新しいPodを作成する
• 同じかどうかの判定は .spec.template.metadata.labels と .spec.selector によって行われる。
  • なのでPodのラベルを変更したらReplicaSetの管理下から外れて「消えた」扱いになる。これはPodのquarantineの手法としても使われる
• ReplicaSet内のPodのtemplateをeditしても既存のPodの方が更新されたり再作成されたりするわけではない。新たに作成されるPodはeditした結果の通りになる。
• replicas を増減した場合、その数に合わせるようにPodを作成/削除する。
• 作成されたPodのnameは、ReplicaSetのnameの後ろに "-ランダムな5桁以下の英数字" を付けたものになる

ReplicationController

• ReplicaSet をいい感じにコントロールする機能。
• 現在は Deployment の方を使ってね、という感じであるらしい。それ以上は調べてない。

Deployment

• Pod のデプロイをいい感じにやってくれる機能
• 実際には ReplicaSet を制御することで実現している。
• Deployment 内のPodのtemplateをeditすると、変更後の内容でPodを起動する新しいReplicaSetを作り、新しいReplicaSetのreplicasを増やしながら古いReplicaSetのreplicasを減らしていき、最終的に全部入れ替える。
  • この少しずつ入れ替える動作は、設定によっては速すぎて（kubectlの手打ちでは）観測できないかもしれない。replicasを増やすとかminReadySecondsを増やすとかmaxSurgeやmaxUnavailableを減らすとかすると観測できる
  • 古いReplicaSetは.spec.revisionHistoryLimit のぶんだけ置いておかれて、それ以上は削除される
• 単なるPodの設定の移行だけでなく、世代管理もしている。つまりrevertができる。
• 作成されたReplicaSet のnameは、Deploymentのnameの後ろに "-podのtemplateのhash値である10桁以下の英数字" を付けたものになる。つまり、Podのnameは "-podのtemplateのhash値である10桁以下の英数字-ランダムな5桁以下の英数字" を付けたものになる。

DaemonSet

• 全ての（正確には、label selector によってマッチする全ての）ノードに1個ずつPodを配置する機能
  • 複数個ずつ配置する機能は無いので、3個ずつ配置したかったら3個のDaemonSetを書く必要がある。
• ノードが新たにクラスタに参加した時に自動でPodを作成してくれる
• Deploymentと同様の更新/世代管理もする。

StatefulSet

• 「ステートフルな」アプリケーションを管理する機能
• かなりの部分は Deployment と同じ
• Serviceとの結びつけが必須
• 作成されたPodのnameはStatefulSetのnameの後ろに0オリジンの順序数を付けたものになる
• pod を増やす時はインデックスの小さい順に作成する。減らす時はインデックスの大きい順に削除する
• stable な netword id と persistent storage が割り当てられる（注：ちゃんとドキュメント読んでない）

Job

• Podを作って実行して終了させる機能。（余計分かりにくい）
• JobのためのPodのcontainerのcommandは処理し終わったら終了するものであるべきである（daemonではない、ということ）
• Podが正常終了（成功）しかた異常終了（失敗）したかにかかわらず、終了したPodはそのままになる（削除されない）。
• 合計の実行回数（成功回数）と並行実行個数を指定できる
• 失敗した場合は（別のPodを作って）再実行される
  • 失敗し続けたらJob自体が失敗として終了するが、Podが失敗している/Jobが最終的に失敗したことは kubectl get job -o wide では分からない（-o yaml で status を見るか、describeする必要がある）

CronJob

• 処理の定期的な実行をする機能
• Job を定期的に作成することにより実現している
• 作成されるJobのnameはCronJobのnameの後ろに "-Jobの起動時刻のunixtimeの10進表記" を付けたものにになる。
• デフォルトでは、前のJobが終了していなくても新しいJobを起動する（concurrencyPolicy: Allow）。
• .spec.startingDeadlineSeconds を設定すると、Jobの開始時刻が指定したぶんまで遅れることを許容する。それより遅れた場合はJobを作成するのをあきらめる。設定しなかった場合（nilの場合）は無制限に遅れることを許容する。
  • あまり小さすぎるとちょっと遅れただけであきらめて全然実行できないという状態になるので、minutelyであっても30sぐらいの設定にはしておく必要がありそう。
• Job の作成があまりにも（100回を超えて）失敗し続けた場合、以降は起動しないようにする機能が入っている
  • やっぱり -o wide では分からない。CronJob の場合は -o yaml でも分からなくて、 describe してイベントを見る必要がある。
  • 「以降は起動しない」フラグを直接的にクリアする方法は見つからなかった
  • startingDeadlineSeconds には、この失敗回数をカウントする時間範囲を制限するという副作用(?)がある。なので、小さい値を設定すると、この機能が発動しなくなる
• Jobが（作成はできているが）失敗し続けた場合は別に起動しなくなったりはしない（command: [ "false" ] とした jobTemplate で確認）