$30 off During Our Annual Pro Sale. View Details »

Kubernetes応用

 Kubernetes応用

「隅からスミまでKubernetes総復習 - cndjpシーズン1まとめ」の前半分の発表資料です。
当日手元で閲覧するためのものです。あとでセクションごとに分けた形にしてアップロードし直すと思います。

hhiroshell

June 14, 2018
Tweet

More Decks by hhiroshell

Other Decks in Technology

Transcript

  1. Cloud Native Developers JP Kubernetes応用 @hhiroshell 1

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

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

  4. Cloud Native Developers JP Pod • 複数のコンテナを束ねる単位 • 論理的なホストのように機能する –

    内包されるコンテナ群はストレージ とネットワークを共有 – ひとつのPodにClusterIPがひとつ割 当たる。コンテナ群はそれを共有 – コンテナの生成/破棄等はPod単位で 行われる • 内包される複数のコンテナは、必 ず同じNode上で稼働 Pod Container 4 Worker Node Master Node
  5. Cloud Native Developers JP 5 Podの起動時の動き Phase: Pending Podの生成を 指示

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

    Phase: Running Init Containerの 起動と実行 終了イベント Nodeへの配置の スケジューリング (続きは後述) PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行
  7. Cloud Native Developers JP Pod生成の指示とスケジューリング • Pod生成の指示 – API Server経由でControllerを作成する。これがAcceptされることがPod生成

    処理の起点になる – ControllerからPodの生成をスケジューリングする(ここでどのNodeにPodが 配置されるかが決まる) – PodのphaseはPendingからスタート • スケジューリング – Podを配置可能なNodeを識別し、Podの作成をスケジューリング(キューに 投入)する 7
  8. Cloud Native Developers JP 8 Podの起動時の動き Phase: Pending Podの生成を 指示

    Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング (続きは後述) PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行
  9. Cloud Native Developers JP InitContainer • アプリケーションの用のコンテナが起動する前に、前処理を行うた めに利用するコンテナ – コンテナの処理が終了したら廃棄される

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

    zookeeper Kubernetesクラスター ストレージ (e.g. AWS EBS)
  11. 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を編集するスクリプト
  12. 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
  13. 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
  14. 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 マウント
  15. 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がストレージを プロビジョニング
  16. Cloud Native Developers JP 16 Podの起動時の動き Phase: Pending Podの生成を 指示

    Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング (続きは後述) PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行
  17. Cloud Native Developers JP Container Lifecycle Hooks • コンテナの生成、破棄をフックして実行される処理 –

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

    Phase: Running InitContainerの 起動と実行 終了イベント Nodeへの配置の スケジューリング (続きは後述) PostStart hookの実行 readiness proveによる起動確認 liveness proveによる死活監視 コンテナの起動とENTRYPOINTの処理開始 PostStart hookの実行
  19. Cloud Native Developers JP Container Probes(readiness prove/liveness probe) • readiness

    probe – コンテナへのトラフィックの配信を行ってよいか(起動したか)を確認する ための仕組み – 所定の間隔でrediness probeを実行し、一定時間失敗が繰り返されるとコンテ ナが再起動される(起動失敗とみなされる) • Iiveness probe – コンテナの死活監視を実装するための仕組み – 所定の間隔でliveness probeを実行し、失敗があるとコンテナが自動で再起動 される 19
  20. 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
  21. Cloud Native Developers JP 21 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop

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

    hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる GracePeriodSeconds経過 (デフォルト30秒) Phase: Succeeded/Failed
  23. Cloud Native Developers JP Podの終了イベント • Podのアンデプロイを伴う操作の指示 – Deployment等にのreplica数を減らす –

    Deployment等に記述したpod templateを更新する – Podをdeleteする – etc… 注)ここには終了処理のできない死に方は含まれません – H/W障害、カーネルパニック、ネットワーク的なNodeの離脱… 23
  24. Cloud Native Developers JP 24 Podの廃棄時の動き 終了イベント PreStop hookの実行 PreStop

    hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる GracePeriodSeconds経過 (デフォルト30秒) Phase: Succeeded/Failed
  25. Cloud Native Developers JP Podの廃棄が開始されると 1. API Serverへの問い合わせ時に、Podの状態がTerminatingになる 2. 上記と同時に以下の2つの処理が開始される

    – 各コンテナにおいて、preStop hookが実行される – ServiceのEndpointリストから、当該Podが削除される(トラフィックが送ら れなくなる) • 注)上記1. と2. の各処理は、順序は保証されない 25
  26. Cloud Native Developers JP Container Lifecycle Hooks(再掲) • コンテナの生成、破棄をフックして実行される処理 –

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

    hookの実行 SIGKILL SIGTEAM Phase: Running ServiceのEndpointリストから除外 トラフィックが送られなくなる gracePeriodSeconds経過 (デフォルト30秒) Phase: Succeeded/Failed
  28. Cloud Native Developers JP コンテナのプロセスの停止 • コンテナのプロセスは、kubeletからのSIGTERMまたはSIGKILLシ グナルによって停止される • どちらのシグナルで終了するかは、gracePeriodSecondsが関係する

    – preStop hookがgracePeriodSeconds経過より早く終了した場合 • SIGTERMシグナルが送られる(Gracefulな終了) • preStop hookを非同期に実行して終了すると即座にSIGTERMシグナルが送信される – preStop hookがgracePeriodSecondsを経過しても終了しない場合 • SIGKILLシグナルが送られる(強制終了) 28
  29. 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
  30. Cloud Native Developers JP ポリシーを適用して制御する 30

  31. Cloud Native Developers JP Podに適用可能なポリシー ポリシー どんなもの? Resource Limit /

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

  33. Cloud Native Developers JP Resource limits / Resource requests •

    Pod内の各コンテナに対して、消費リソースの下限/上限を設定 • Resource limits / requestsを指定できるリソース – CPU – Memory – Local ephemeral storage(v1.10 beta) – Extended Resource 33
  34. 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
  35. 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"
  36. Cloud Native Developers JP Extended Resource • Kubernetesが通常サポートする以外に、独自に管理したいリソース をExtended Resourceとして追加できる

    • Node-levelとCluster-levelとがある – Node-level: Node毎にリソースの量を設定するもの – Cluster-level: クラスター全体としてリソース量を設定するもの 36
  37. 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/<your-node-name>/status
  38. 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
  39. Cloud Native Developers JP Resource Quota 39

  40. 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
  41. Cloud Native Developers JP Pod Security Policy 41

  42. 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で設定)
  43. Cloud Native Developers JP 参考)Admission Controllerとは • Kubernetes APIの呼び出しをフックして所定の処理を実行する仕組 み

    – API呼び出しのvalidation(権限チェック、フォーマット適合確認など) – API呼び出しのmutate(作成しようとするリソースに変更を加えるなど) 43 API Server Create API call kubectl Admission Webhooks 認 証 認 可 Object/Resource
  44. 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
  45. Cloud Native Developers JP Network Policy 45

  46. 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"
  47. 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
  48. Cloud Native Developers JP Fin. 48