業務で携わったことは無いですが個人的にコンテナ技術に興味があり、Kubernetesについて学習したので、本記事にまとめてみました。記載内容は概要的なものです。（前記事の続きで。）
Kubernetesのリソースは沢山あるので、複数記事に分割して記載します。
①Kubernetesの概要 ←前記事記載
②Kubernetesで出来ること ←前記事記載
③Kubernetesの基本知識を知る ←前記事記載
④Kubernetesのリソースを知る ←本記事記載
（１）Workloads APIsカテゴリ ←本記事記載
（２）ServiceAPIカテゴリ ←別記事記載予定
（３）Config & Storage APIsカテゴリ ←別記事記載予定
（４）Cluster APIsカテゴリ ←別記事記載予定
（５）Metadata APIsカテゴリ ←別記事記載予定
⑤Kubernetesアーキテクチャを知る ←別記事記載予定
⑥Kubernetesのまとめ ←別記事記載予定
④Kubernetesのリソースを知る
Workloads APIsカテゴリ
Pod
Kubernetesリソースの最小単位です。Podは中に1つ以上のコンテナを含んでいます。PodにはNICが1つ付いていて、複数のコンテナがPod内に存在している場合は、NICを各コンテナは共用します。特に理由が無い場合、「Podの中のコンテナは１つ」が推奨されています。
ReplicaSet
ReplicaSetはPodを複数デプロイする場合に使用するリソースです。ReplicaSetに定義した数のコンテナをスケジューリングしてNode上にデプロイします。仮にNodeに障害が発生してそのNode上のコンテナが無くなっても、ReplicaSetに定義したコンテナ数になるように、オートヒーリングで別のNodeに自動復旧します。
Deployment
複数のReplicaSetを管理するのがDeploymentリソースです。Deploymentはローリングアップデートに利用されます。以下ような手順でDeploymentは古いReplicaSetAのPodを新しいReplicaSetBのPodへローリングアップデートします。
１.(新)ReplicaSetBを作成する
２.(新)ReplicaSetB上のPod数を1つ増やす
３.(古)ReplicaSetA上のPod数を1つ減らす
４.手順2と手順3を繰り返す
５.(古)ReplicasetAのPod数は0で維持する
DaemonSet
DaemonSetを使用すると各Nodeに１つずつ均等にPodを配置します。ReplicasetのようにPodの数を指定することは出来ませんし、リソースに応じてスケジューリングによってコンテナを配置する動作はしません。用途としてはdatadog agentなどのメトリクスエージェントの実行や、fluentdのようなログ収集デーモンを実行する際などに利用されます。
StatefulSet
データベースなどのステートフルなアプリケーションをデプロイ・管理するためのリソースです。ワークロードに永続性を持たせるために同じPod名を維持する仕組みがあります。新たにPodを作成する場合は[Pod名]-[Nunber]のように命名します。例えば、web-0,web-1,web-2のようになります。
Job
コンテナを利用して一度限りの処理を実行させるリソースです。JobとRepicaSetとの大きな違いは、「起動するPodが停止することを前提にして作られているかどうか」です。基本的にReplicaSetでは、Podの停止は予期せぬエラーです。一方、Jobの場合は、Podの停止が正常終了ち期待されるようとに向いています。例えば、「特定のサーバとのrsync」や「S3などのObject Storageへのアップロード」などが挙げられます。ReplicaSetなどでは正常終了の数をカウントしているわけではないため、バッチ的な処理の場合はJobを積極的に利用しましょう。
CronJob
Cronのようにスケジュールされた時間にJobを作成するためのリソースです。
CronJobがJobを管理して、JobがPodを管理するような３層の親子関係になっています。
この記事は以下の情報を参考にして執筆しました。
Kubernetes公式ドキュメント
Kubernetes完全ガイド 第2版