Kubernetes完全ガイド チートシート 第5章 Workloadsリソース

# Overview
本記事は青山真也さん著の[k8s完全ガイド](https://www.amazon.co.jp/dp/4295004804)を読んだ自分用まとめである．このまとめは以下の2点を目的として作成した．

1. 自分が困った時にどこを参照すればいいか，またどういうリソースがどういう役割を持っているかを思い出せるように
2. アウトプットを通して自分の理解度を上げる

またこのQiitaは自分が概略を思い出すためのチートシートとしての役割が強いため，細かい説明は省く．細かい説明については本を参照してほしい．

# [k8s完全ガイド](https://www.amazon.co.jp/dp/4295004804)とは
以下Amazonの説明を載せる．

> Kubernetes認定資格(Certified Kubernetes Administrator/Certified Kubernetes Application Developer)保有者直伝! プロダクション環境で培われた、Kubernetesを使い倒すための実践ノウハウが満載の一冊です。
Kubernetesはコンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのプラットフォーム(コンテナオーケストレーションエンジン)です。 本書籍では、Kubernetesを触ったことがない方でもKubernetesのコンセプトを理解し、実際にアプリケーションをコンテナ化して実行することができるようになることを目標としています。
前半の章では図をふまえながらKubernetesの各リソースについて体系的かつ網羅的に説明します。さらに後半の章では、マニフェスト管理(Helm/Ksonnet)、モニタリング(Prometheus/Datadog)、ログ集約(Fluentd/Datadog)、CI/CD(Spinnaker/JenkinsX/Scaffold)、サービスメッシュ(Istio/Conduit/Linkerd)、Service Brokerなど、Kubernetesを用いてクラウドネイティブな開発を促進させる周辺エコシステムについても紹介します。

# 第5章 Workloadsリソース
## 5.1 Workloadリソースの概要
- コンテナの実行に関するリソース． 全部で8種類．
  - Podは最小単位，それらを管理するのが他のWorkloadリソース

| Workload リソース   | 使い分け方 |
|:-----------------|:------------------|
| Pod              | デバッグ，確認用途 |
| Replication Controller | 非推奨，代わりにReplicaSetを利用 |
| ReplicaSet        | Podをスケールさせて管理，基本的にはDeployment経由で利用 |
| Deployment        | スケールさせるワークロードに利用 |
| DaemonSet         | 各ノードに1つずつPodを配置したい時に利用 |
| StatefulSet       | データの永続化などのステートを持つワークロードに利用 |
| Job               | ワークキューやタスクなどコンテナの終了が必要なワークロードに利用 |
| CronJob           | 定期的にJobを作成したい時に利用 |

- 以下，親子関係

```
 Tier 1               Tier2                  Tier 3
   Pod   <--  ReplicationController
   Pod   <--        ReplicaSet       <--   Deployment
   Pod   <--        DaemonSet
   Pod   <--       StatefulSet 
   Pod   <--           Job           <--    CronJob
```

## 5.2. Pod
- Podは1つ以上のコンテナから構成
    - 2つのコンテナが入ったPodを作成した時，2つのコンテナは同一のIPアドレスを保持
    - つまりNetwork NamespaceはPod内で共有
- Podのデザインパターン

| | 役割 |
|:-----------------|:------------------|
| サイドカーパターン | メインコンテナに機能を追加(e.g., コンフィグ変更検知によるアプリケーションの設定の動的書き換え) |
| アンバサダーパターン | 外部システムとのやり取りの代理(e.g., アプリケーションによるDBへのRead/WriteをProxyを通してCloudSQLに送信) |
| アダプタパターン | 外部からのアクセスのインターフェース(e.g. Prometheusの形式に合わせた外部との通信インターフェース) |

## 5.3. ReplicaSet/ReplicationController
- Podのレプリカを作成し，指定した数のPodを維持し続けるリソース

## 5.4. Deployment
- 複数のReplicaSetを管理することでローリングアップデートやロールバックなどを実現
    - Pod単体だとPodに障害が発生した際に自動でPodが再作成されることはない
    - ReplicaSetだけだとローリングアップデートやロールバックの機能が利用不可
- 利点
    - 新しいReplicaSet上でコンテナが起動したことや，ヘルスチェックが通っていることを確認しつつの切り替え
    - ReplicaSetの移行過程におけるPod数の細かい指定も可能

## 5.5 DaemonSet
- ReplicaSetの特殊系
- ReplicaSetでは各k8s Node上に合計N個のPodをNodeのリソース状況に合わせて配置するため．．．
    - 各Node上のPodの数が等しくなるとは限らない
    - 全てのNode上に確実に配置されるとも限らない
- DaemonSetは各ノードにPodを1つずつ配置するリソース
    - レプリカ数は指定できない
    - 1ノードに2Podずつ配置するということも出来ない
        - Podを配置したくないノードは除外できる(nodeSelector, Node Anti-Affinityを利用したスケジューリング)
- ユースケース: 全Node上で必ず動作させたいプロセス
    - 各Podが出力するログをホスト単位で収集するFluentd
    - 各Podのリソースの使用状況やノードの状態をモニタリングするDatalog

## 5.6 StatefulSet
- ReplicaSetの特殊系
- DBなどのステートフルなワークロードに対応するためのリソース
- ReplicaSetとの主な違い
    - 作成されるPodのサフィックスは数字のインデックスが付与
    - データを永続化するための仕組みがある
        - PersistentVolume(永続化領域)を利用している場合はPodの再起動時に同じ領域を利用して再作成
        - Pod名が変わらない

## 5.7. Job
- コンテナを利用して一度限りの処理を実行させるリソース
    - N並列で実行しながら指定した回数のコンテナの正常終了を保証するリソース
- ReplicaSetとの主な違い
    - 起動するPodが停止することが前提
    - Podの停止が正常終了するような用途
        - ReplicaSetではPodの終了は予期せぬエラー
- ユースケース : 長期間の実行が予想されること
    - 特定のサーバとのrsync
    - S3などのObject Storageへのアップロード

## 5.8. Cronjob
- Cronのようにスケジュールされた時間にJobを作成