Cloud Native Developers JP Kubernetes応用 @hhiroshell 1

Cloud Native Developers JP お品書き • Podの起動時／終了時にできること • ポリシーを適用して制御する 2

Cloud Native Developers JP Podの起動時／終了時にできること 3

Cloud Native Developers JP Pod • 複数のコンテナを束ねる単位 • 論理的なホストのように機能する – 内包されるコンテナ群はストレージ とネットワークを共有 – ひとつのPodにClusterIPがひとつ割 当たる。コンテナ群はそれを共有 – コンテナの生成／破棄等はPod単位で 行われる • 内包される複数のコンテナは、必 ず同じNode上で稼働 Pod Container 4 Worker Node Master Node

Cloud Native Developers JP 5 Podの起動時の動き Phase: Pending Podの生成を 指示 Phase: Running Init Containerの 起動と実行 終了イベント Nodeへの配置の スケジューリング （続きは後述） PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行

Cloud Native Developers JP 6 Podの起動時の動き Phase: Pending Podの生成を 指示 Phase: Running Init Containerの 起動と実行 終了イベント Nodeへの配置の スケジューリング （続きは後述） PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行

Cloud Native Developers JP Pod生成の指示とスケジューリング • Pod生成の指示 – API Server経由でControllerを作成する。これがAcceptされることがPod生成 処理の起点になる – ControllerからPodの生成をスケジューリングする（ここでどのNodeにPodが 配置されるかが決まる） – PodのphaseはPendingからスタート • スケジューリング – Podを配置可能なNodeを識別し、Podの作成をスケジューリング（キューに 投入）する 7

Cloud Native Developers JP 8 Podの起動時の動き Phase: Pending Podの生成を 指示 Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング （続きは後述） PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行

Cloud Native Developers JP InitContainer • アプリケーションの用のコンテナが起動する前に、前処理を行うた めに利用するコンテナ – コンテナの処理が終了したら廃棄される – 複数のInitContainerを使う場合、ひとつずつシーケンシャルに実行される – 前処理でのみ必要なパッケージや権限をInitContainerに集約して、リソース の節約とセキュリティ向上を図る • 利用例 – アプリケーション用コンテナを起動するための前処理（設定ファイルの生成 など） – アプリが依存する別サービスが起動するまでの待機処理 9

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • zookeeperが配備済みの状態から説明します 10 zookeeper Kubernetesクラスター ストレージ (e.g. AWS EBS)

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • server.propertiesのテンプレートとそれを編集するスクリプトを ConfigMapオブジェクトに含めて配備する 11 zookeeper broker-config init.sh server.properties Kubernetesクラスター ストレージ (e.g. AWS EBS) ConfigMap server.propertiesのテンプレート server.propertiesを編集するスクリプト

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • brokerを動かすためのPodの配備を開始 • VolumeにConfigMap内のファイルがコピーされる 12 zookeeper broker-config init.sh server.properties init.sh server.properties Kubernetesクラスター ストレージ (e.g. AWS EBS) kafka-0 Pod ファイルをコピー Volume

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • initContanerが立ち上がり、前ページのVolumeをマウント • init.shを実行して、環境に合わせてserver.propertiesを書き換え 13 zookeeper broker-config init.sh server.properties init.sh server.properties Kubernetesクラスター ストレージ (e.g. AWS EBS) kafka-0 init-cofnig マウント init.shを実行して server.propertiesを書き換え initContainer

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • brokerを可動させるコンテナを起動 • brokerのデータを保持するためのVolumeオブジェクトをマウント 14 zookeeper kafka-0 broker-config init.sh server.properties broker init.sh server.properties Kubernetesクラスター ストレージ (e.g. AWS EBS) Container マウント

Cloud Native Developers JP InitContainerの利用例: KubernetesでKafka broker • PersistentVolumeClaim(PVC)に記述されたストレージの要件（容量、 サービスレベルなど）に従い、StorageClassがプロビジョニング 15 zookeeper kafka-0 broker-config init.sh server.properties broker init.sh server.properties Kubernetesクラスター ストレージ (e.g. AWS EBS) PersistentVolumeClaim(PVC) StorageClass PVCに記述された要件に従い、 StorageClassがストレージを プロビジョニング

Cloud Native Developers JP 16 Podの起動時の動き Phase: Pending Podの生成を 指示 Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング （続きは後述） PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行

Cloud Native Developers JP Container Lifecycle Hooks • コンテナの生成、破棄をフックして実行される処理 – PostStart hook（←こっち） • コンテナの起動直後に実行される • コンテナのENTRYPOINTが開始される前に実行されるという保証があるわけではない – PreStop hook • コンテナの破棄を開始する前に実行される • これが完了していないとのコンテナの破棄には進まない • 非同期的に実行して終了すると、即座にメインプロセスにSIGTERMが送られるので注意 • ExecとHTTPの2種類の実装を指定できる – Exec: 任意のシェルコマンドを実行 – HTTP: 任意のエンドポイントにHTTPリクエストを発行 17

Cloud Native Developers JP 18 Podの起動時の動き Phase: Pending Podの生成を 指示 Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング （続きは後述） PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行

Cloud Native Developers JP Container Probes(readiness prove/liveness probe) • readiness probe – コンテナへのトラフィックの配信を行ってよいか（起動したか）を確認する ための仕組み – 所定の間隔でrediness probeを実行し、一定時間失敗が繰り返されるとコンテ ナが再起動される（起動失敗とみなされる） • Iiveness probe – コンテナの死活監視を実装するための仕組み – 所定の間隔でliveness probeを実行し、失敗があるとコンテナが自動で再起動 される 19

Cloud Native Developers JP Container Probeの実装方法 • 以下3種類のいずれかで実装 – ExecAction: • 指定したコマンドの実行 • 終了コードが0なら成功 – HTTPGetAction: • 指定のエンドポイントにHTTP GETを送信 • 200位上400未満で成功 – TCPSocketAction: • TCP Socketのコネクションを張ることができ れば成功 • proveの成否が正しくコンテナの死 活を反映するように注意 20 … spec: containers: - name: goproxy image: k8s.gcr.io/goproxy:0.1 ports: - containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20

Cloud Native Developers JP 21 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる GracePeriodSeconds経過 （デフォルト30秒） Phase: Succeeded/Failed

Cloud Native Developers JP 22 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる GracePeriodSeconds経過 （デフォルト30秒） Phase: Succeeded/Failed

Cloud Native Developers JP Podの終了イベント • Podのアンデプロイを伴う操作の指示 – Deployment等にのreplica数を減らす – Deployment等に記述したpod templateを更新する – Podをdeleteする – etc… 注）ここには終了処理のできない死に方は含まれません – H/W障害、カーネルパニック、ネットワーク的なNodeの離脱… 23

Cloud Native Developers JP 24 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる GracePeriodSeconds経過 （デフォルト30秒） Phase: Succeeded/Failed

Cloud Native Developers JP Podの廃棄が開始されると 1. API Serverへの問い合わせ時に、Podの状態がTerminatingになる 2. 上記と同時に以下の2つの処理が開始される – 各コンテナにおいて、preStop hookが実行される – ServiceのEndpointリストから、当該Podが削除される（トラフィックが送ら れなくなる） • 注）上記1. と2. の各処理は、順序は保証されない 25

Cloud Native Developers JP Container Lifecycle Hooks（再掲） • コンテナの生成、破棄をフックして実行される処理 – PostStart hook • コンテナの起動直後に実行される • コンテナのENTRYPOINTが開始される前に実行されるという保証があるわけではない – PreStop hook（←こっち） • コンテナの破棄を開始する前に実行される • これが完了していないとのコンテナの破棄には進まない • 非同期的に実行して終了すると、即座にメインプロセスにSIGTERMが送られるので注意 • ExecとHTTPの2種類の実装を指定できる – Exec: 任意のシェルコマンドを実行 – HTTP: 任意のエンドポイントにHTTPリクエストを発行 26

Cloud Native Developers JP 27 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる gracePeriodSeconds経過 （デフォルト30秒） Phase: Succeeded/Failed

Cloud Native Developers JP コンテナのプロセスの停止 • コンテナのプロセスは、kubeletからのSIGTERMまたはSIGKILLシ グナルによって停止される • どちらのシグナルで終了するかは、gracePeriodSecondsが関係する – preStop hookがgracePeriodSeconds経過より早く終了した場合 • SIGTERMシグナルが送られる（Gracefulな終了） • preStop hookを非同期に実行して終了すると即座にSIGTERMシグナルが送信される – preStop hookがgracePeriodSecondsを経過しても終了しない場合 • SIGKILLシグナルが送られる（強制終了） 28

Cloud Native Developers JP gracePeriodSecondsの設定方法 • kubectlのオプションで指定する場合 – --grace-period オプションで指定 • manifestに記述する場合 – Podのtemplateに、 terminationGracePeriodSeconds で指定 29 $ kubectl delete deployment test --grace-period=60 apiVersion: extensions/v1beta1 kind: Deployment … template: spec: containers: - name: test image: ... terminationGracePeriodSeconds: 60

Cloud Native Developers JP ポリシーを適用して制御する 30

Cloud Native Developers JP Podに適用可能なポリシー ポリシー どんなもの？ Resource Limit / Request Pod内の各コンテナに対して設定可能な、リソー スの上限消費量(Limit)と最低要求量(Request) Resource Quota namespace単位で設定可能なリソース使用量の 制限 Pod Security Policy セキュリティ的に注意が必要な設定について、 Pod specificationで適用可能な項目を調整する 機能 Network Policy Podが他のエンドポイント（Podやクラスター外 のエンドポイント）に通信を行うときのポリ シーを設定 31

Cloud Native Developers JP Resource Limit / Request 32

Cloud Native Developers JP Resource limits / Resource requests • Pod内の各コンテナに対して、消費リソースの下限/上限を設定 • Resource limits / requestsを指定できるリソース – CPU – Memory – Local ephemeral storage(v1.10 beta) – Extended Resource 33

Cloud Native Developers JP Resource limits / requestsとNodeへのPodの配置 • Podの配置前 – 内包するコンテナ群のResource requestの合計まかなえるだけの CPU/Memory余剰がないNodeには、Podはスケジューリングされない • Podの配置後 – コンテナのメモリ使用量が設定された上限を超えると、設定された restartPolicyに基づいてコンテナが再起動される – requestsより多くのメモリを使っているContainerがあると、Nodeがメモリ 不足になったときにそのPodが排除される可能性がある – CPU利用量がlimitを超える場合もあり得るが、Podが廃棄されることはない 34

Cloud Native Developers JP Local Ephemeral Storage • Nodeのrootパーティションの利用量 に対して limit / requestを設定 – limitを超えるとPodごとNodeから排除 される – requestを満たせないNodeにはスケ ジュールされない 参考）Nodeのrootパーティション – kubeletが配置されるrootディレクトリや ログの 保存先(/var/log)として利用されている – PodからはEmptyDirのVolumeとしてマウントす ることで利用できる 35 apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - - name: wp image: wordpress resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi"

Cloud Native Developers JP Extended Resource • Kubernetesが通常サポートする以外に、独自に管理したいリソース をExtended Resourceとして追加できる • Node-levelとCluster-levelとがある – Node-level: Node毎にリソースの量を設定するもの – Cluster-level: クラスター全体としてリソース量を設定するもの 36

Cloud Native Developers JP Node-LevelのExtended Resource • Node毎にリソースの量を設定するもの • 以下の2種類がある – Device plugin managed resources • Device pluginによって管理されるリソース（GPUなど）。Device pluginの実装によって、 制限のされ方が異なる – Other Resources • 任意の名前を指定した仮想的なリソースを、リソースの総量とともに設定できる • Kubernetes API経由で設定を行う（下例） 37 curl --header "Content-Type: application/json-patch+json" ¥ --request PATCH ¥ --data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' ¥ http://localhost:8001/api/v1/nodes//status

Cloud Native Developers JP Extended Resourceのlimits/requests • Extended Resourceの limits/requestsも、他のリソース と同じようにPodに設定できる 38 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: myimage resources: requests: cpu: 2 example.com/dongle: 1 limits: example.com/dongle: 2

Cloud Native Developers JP Resource Quota 39

Cloud Native Developers JP Resource Quota • namespace単位で設定可能なリ ソース使用量の制限 • ResourceQuotaオブジェクトを 登録することで設定する • Quotaを指定可能なリソース – CPU – Memory – Extended Resources – Storage Resource – Object Count 40 apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi requests.nvidia.com/gpu: 4

Cloud Native Developers JP Pod Security Policy 41

Cloud Native Developers JP Pod Security Policy • セキュリティ的に注意が必要な設定について、Pod specificationで 適用可能な項目を調整する機能 ※ Pod単位／コンテナ単位のポリシー(PodSecuriyContext/SecurityContext)もある • Admission controllerを組み合わせて実装されており、Kubernetes APIを実行するアカウントにポリシーが適用される 制御可能な項目の例 42 全ての項目は→ https://kubernetes.io/docs/concepts/policy/pod-security-policy/ 項目 Pod specでのフィールド名 Privileged containerの利用可否 privileged ホストのファイルシステムの利用 allowedHostPaths コンテナのユーザーID、グループID runAsUser, supplementalGroups コンテナが利用するAppArmorプロファイル （annotationで設定）

Cloud Native Developers JP 参考）Admission Controllerとは • Kubernetes APIの呼び出しをフックして所定の処理を実行する仕組 み – API呼び出しのvalidation（権限チェック、フォーマット適合確認など） – API呼び出しのmutate（作成しようとするリソースに変更を加えるなど） 43 API Server Create API call kubectl Admission Webhooks 認 証 認 可 Object/Resource

Cloud Native Developers JP Pod Security Policyの利用 • Pod Security Policyを有効化するまでの流れ 1. 許可するPolicyを設定（PodSecurityPolicyオブジェクトを作成） 2. RBACでアカウントとPodSecurityPolicyを紐づけ • このアカウントでKubernetes APIを実行するとき、PodSecurityPolicyを満たさないPodが 作成できないように制御される 3. PodSecurityPolicy admission controllerを有効化 – 詳細はZ Labの@tkusumiさんの記事(https://qiita.com/tkusumi/items/6692af743ae03dc0fdcc)に詳しい • 利用例 – チームでクラスターを共有する運用で、ユーザー毎にできることを制限した いとき – pliviegedなコンテナを作成する操作はクラスター管理者のみに許可（監視系 のコンテナを各Nodeに配置するなど） 44

Cloud Native Developers JP Network Policy 45

Cloud Native Developers JP Network Policy • Podが他のエンドポイント （Podやクラスター外のエンドポ イント）に通信を行うときのポリ シーを設定 • NetworkPolicyリソースを作成す ることで有効になる • NetworkPolicyリソースには以下 を記述 – ingress/egressのポリシー – 適用対象Pod（LabelSelectorで指定） 46 kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: access-nginx spec: podSelector: matchLabels: run: nginx ingress: - from: - podSelector: matchLabels: access: "true"

Cloud Native Developers JP Network Policyを利用する上での注意点 • NetworkPolicyは、それをサポートするnetwork providerを利用する 必要がある…例えば、 – 例）Calico, Cilium, Kube-router, Romana, Weave Net • よく見かけるflunnelは単体ではサポートしていない – canalを使うとCalicoと組み合わせてflannelが使えるということらしいが… • canal: https://github.com/projectcalico/canal 47

Cloud Native Developers JP Fin. 48