Kubernetes応用

Cloud Native Developers JP
Kubernetes応用
@hhiroshell
1

View Slide

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

View Slide

Podの起動時／終了時にできること
3

View Slide

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

View Slide

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

View Slide

Phase: Pending
Podの生成を
指示
Phase: Running
Init Containerの
起動と実行
終了イベント
Nodeへの配置の

View Slide

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

View Slide

Phase: Pending
Podの生成を
指示
Phase: Running
InitContainerの
起動と実行
終了イベント
Nodeへの配置の

View Slide

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

View Slide

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

View Slide

• server.propertiesのテンプレートとそれを編集するスクリプトを
ConfigMapオブジェクトに含めて配備する
11
zookeeper
broker-config
init.sh
server.properties
(e.g. AWS EBS)
ConfigMap
server.propertiesのテンプレート
server.propertiesを編集するスクリプト

View Slide

• brokerを動かすためのPodの配備を開始
• VolumeにConfigMap内のファイルがコピーされる
12
zookeeper
broker-config
init.sh
server.properties
init.sh
server.properties
(e.g. AWS EBS)
kafka-0
Pod
ファイルをコピー
Volume

View Slide

• initContanerが立ち上がり、前ページのVolumeをマウント
• init.shを実行して、環境に合わせてserver.propertiesを書き換え
13
zookeeper
broker-config
init.sh
server.properties
init.sh
server.properties
(e.g. AWS EBS)
kafka-0
init-cofnig
マウント
init.shを実行して
server.propertiesを書き換え
initContainer

View Slide

• brokerを可動させるコンテナを起動
• brokerのデータを保持するためのVolumeオブジェクトをマウント
14
zookeeper
kafka-0
broker-config
init.sh
server.properties
broker
init.sh
server.properties
(e.g. AWS EBS)
Container
マウント

View Slide

• PersistentVolumeClaim(PVC)に記述されたストレージの要件（容量、
サービスレベルなど）に従い、StorageClassがプロビジョニング
15
zookeeper
kafka-0
broker-config
init.sh
server.properties
broker
init.sh
server.properties
(e.g. AWS EBS)
PersistentVolumeClaim(PVC) StorageClass
PVCに記述された要件に従い、
StorageClassがストレージを
プロビジョニング

View Slide

Phase: Pending
Podの生成を
指示
Phase: Running
InitContainerの
起動と実行
終了イベント
Nodeへの配置の

View Slide

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

View Slide

Phase: Pending
Podの生成を
指示
Phase: Running
InitContainerの
起動と実行
終了イベント
Nodeへの配置の

View Slide

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

View Slide

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

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

View Slide

終了イベント
SIGTEAM
Phase: Running

View Slide

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

View Slide

終了イベント
SIGTEAM
Phase: Running

View Slide

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

View Slide

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

View Slide

終了イベント
SIGTEAM
Phase: Running
gracePeriodSeconds経過

View Slide

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

View Slide

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

View Slide

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

View Slide

Resource Limit / Request
32

View Slide

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

View Slide

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

View Slide

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

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

View Slide

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

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

Resource Quota
39

View Slide

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

Pod Security Policy
41

View Slide

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

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

View Slide

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

Network Policy
45

View Slide

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

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

Fin.
48

View Slide

Kubernetes応用

Kubernetes応用

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript