$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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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を編集するスクリプト

    View Slide

  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

    View Slide

  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

    View Slide

  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
    マウント

    View Slide

  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がストレージを
    プロビジョニング

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  32. Cloud Native Developers JP
    Resource Limit / Request
    32

    View Slide

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

    View Slide

  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

    View Slide

  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"

    View Slide

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

    View Slide

  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//status

    View Slide

  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

    View Slide

  39. Cloud Native Developers JP
    Resource Quota
    39

    View Slide

  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

    View Slide

  41. Cloud Native Developers JP
    Pod Security Policy
    41

    View Slide

  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で設定)

    View Slide

  43. Cloud Native Developers JP
    参考)Admission Controllerとは
    • Kubernetes APIの呼び出しをフックして所定の処理を実行する仕組

    – API呼び出しのvalidation(権限チェック、フォーマット適合確認など)
    – API呼び出しのmutate(作成しようとするリソースに変更を加えるなど)
    43
    API Server
    Create API call
    kubectl
    Admission
    Webhooks




    Object/Resource

    View Slide

  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

    View Slide

  45. Cloud Native Developers JP
    Network Policy
    45

    View Slide

  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"

    View Slide

  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

    View Slide

  48. Cloud Native Developers JP
    Fin.
    48

    View Slide