# 読書会 9章 Podの管理

## おもったこと
まとめ作るの大変なので、
20分：概要
20分：議論タイム
とかで分けませんか？

ざっくりよんでくる前提になりますが・・・

## 目次
- 9.1 Label
- 9.1.1 Labelとはなにか
- 9.1.2 セレクタ
- 9.1.3 セレクタの高度な使い方
- 9.1.4 Labelのその他の使い方
- 9.1.5 LabelとAnnotation

- 9.2 Node Affinity
- 9.2.1 ハードAffinity
- 9.2.2 ソフトAffinity

- 9.3 PodのAffinityとAnti-Affinity
- 9.3.1 Podの同居
- 9.3.2 Podの分離
- 9.3.3 ソフトAnti-Affinity
- 9.3.4 Pod Affinityを使っても良い場合

- 9.4 TaintとToleration

- 9.5 Podコントローラ
- 9.5.1 DeamonSet
- 9.5.2 StatefulSet
- 9.5.3 Job
- 9.5.4 CronJob
- 9.5.5 Horizontal Pod Autoscaler
- 9.5.6 PodPreset
- 9.5.7 Operator とCuston Resource Definition（CRD）

- 9.6 Ingressリソース
- 9.6.1 Ingress ルール
- 9.6.2 IngressによるTLS終端
- 9.6.3 Ingressコントローラ

- 9.7 Istio

- 9.8 Envoy

- 9.9 まとめ

## 9.1 Label
Podに名前（というか属性？）をつける。
例：アプリ名とか。devかProductionとか。

selector:
    app: demo
    environment: produciont

**メリット：**
* Serviceリソースのリクエストの転送先をLabelを使って選べること。
* kubectlのセレクタでLabelをつかって適用先を選べる。

その他、canarydeproyのためにラベルを使ったりする。（`track:stable`と`track canary`とかで分けるとか）

## 9.2 Node Affinity
プリエンプティブノード（安いけど消えちゃうかも）を有効活用するために使われた利したり。
選好性（好み、嗜好）を表現するために使う。

名前はイケてないらしいｗ
* `requiredDuringSchedulingIgnoredDuringEection` -> ハード
* `preferrdDuringSchedulingIgnoredDuringExection` -> ソフト

required（必須）はこのルールを**満足しなければならない**
preferrd（優先）はこのルールを満足することが**望ましい**
って覚える。

### 9.2.1 ハードAffinity

apiVersion: v1
kind: Pod
...
spec:
    affinity:
        nodeAffinity:
            requiredDuringSchedulingIgnoredDuringEection:
                nodeSelectorTerms:
                - matchExpressions:
                    -key: "failure-domain.beta.kubernetes.io/zone"
                    operator: In
                    values: ["us-centrall-a"]

"us-centrall-a"というAzに作られる

### 9.2.2 ソフトAffinity

preferredDuringSchedulingIgnoredDuringEection:
- weight: 10
    preference:
        matchExpressions:
        - key: "failure-domain.beta.kubernetes.io/zone"
          operator: In
          values: ["us-centrall-a"]

- weight: 100
    preference:
        matchExpressions:
        - key: "failure-domain.beta.kubernetes.io/zone"
          operator: In
          values: ["us-centrall-b"]

us-centrall-bは10倍の優先度！

## 9.3 PodのAffinityとAnti-Affinity
ノード上で他にどのようなPodがすでに実行されているかに基づいて、スケジューリングの決定に及ぼすことができるのか！！
-> これらを支持できるのがPod Affinity

例：
* Webサーバとコンテンツキャッシュは同じノード上に置きたい
* 同じ種類のものは別のノードでレプリカしたい
とか

Podのどうきょ -> pod Affinity
Podの分離 -> podAntiAffinity

podAffinityとPodAntiAffinityはソフトaffinity設定もできるよ。

**気をつけること**
NodeAffintyとPodAffinityはkuberntesのスケジュール機能を制限するもの。なので、ほんとうにAffinityでしかどうしようもないときに使おう！

## 9.4 TaintとToleration
nodeAffinityとTaintの違いは？？

## 9.5 Podコントローラ
DeploymentでReplicaSetを管理したよね。
単純なアプリケーションだと、必要になるのはDeploymentoだけだけど、他にもPodコントローラーは有用なものがあるので概観します。

### 9.5.1 DeamonSet
ログを取るときとかのサイドカーパターンを実施する用。

### 9.5.2 StatefulSet
Podを特定の順序で起動および終了する機能。
Redis、MongoDB、Cassandraとかの分散アプリケーションはクラスタリーダを識別する必要がある。

StatefulSetではersistentVolumeClaimを自動的に作成するVoluemClaimTemplatesを使用してPodのディスクストレージも管理可能。

### 9.5.3 Job
回数を指定しただけPodが起動するもの。（Deploymentoは必要に応じて継続的に再起動される。）

### 9.5.4 CronJob
Jobのなかでも定期実行するものはLinuxのcronに習い、CronJobオブジェクトがある。

### 9.5.5 Horizontal Pod Autoscaler
水平（Horizontal） -> サービスのレプリカ数を調整
垂直（vertical） -> ここのレブ理科自体を大きくしたり小さくしたり。

Horizontal Pod Autoscalerは指定されたDeploymentを関しし、与えられたメトリクスを監視して、レプリカの数を増減させるか判断する。

最も一般的なメトリクスはCPU使用率。
**スケールで対象するメトリクス**
* システムメトリクス：CPU使用率やメモリ使用率
* サービスメトリクス：アプリからエキスポートされる独自のもの。（例えばアプリのエラー率とか）

### 9.5.7 OperatorとCustom Resource Definition（CRD)
アプリによっては複数の連携して機能するPodを特定の順序で初期化が必要になったりする。
StatefulSetより複雑な管理を実施する場合はCustom Resource Definitionという新しいタイプのオブジェクトが作成できる。

で、CRDを作ったあとにCRDに具体的になにかしてもらう際にはKubernetesAPIとの通信するプログラムが必要になり、これを**Operator**という。

## 9.6 Ingressリソース
IngressはServiceの前に配置されるロードバランサと考えることができる。

### 9.6.1 Ingressルール
URLに応じてことなる場所へルーティングする（ファンアウト）のため
### 9.6.2 IngressによるTLS終端
TLS証明書への接続をIngressで一括管理！！！

## 9.7 Istio
サービスメッシュのいちりえ。
複数のアプリケーションやサービスが相互に通信し合う環境にとって有用。
サービス感におけるネットワークとフラフィックのルーティングや暗号化を処理し、メトリクス、ログ、ロードバランシングなどを提供する。
https://istio.io/latest/docs/concepts/what-is-istio/
まずここを読めとのこと。

## 9.8 Envoy

マネージドkubernetesなら、ほとんどクラウドがたLBが統合されている。（例えば、GKEでLoadBalancerというService、
IngressならGoogle Clooud Load Balancerとか。

もっと高度なLBを使いたいならEnvoyを使う。
（kubernetesの一部じゃないけど一緒に使われるのが一般的。）
EnvoyはC++で書かれた高性能なプロキシで、単一のサービスやアプリケーションを対象とした設計になっていますが、サービスメッシュ型のアーキテクチャの一部としても利用可能。

https://blog.markvincze.com/how-to-use-envoy-as-a-load-balancer-in-kubernetes/
ここが優れたBlog記事らしい。