cndjp第2回勉強会の発表資料です。

1. Kubernetes in プロダクション！
#cndjp2

2. 前半戦

3. 前半戦のメニュー
1. 前回の復習
2. ロギング

4. 復習

5. Kubernetesの全体像
k8sクラスター
>_
kubectl (CLI)
マシンとネットワーク

6. Kubernetes Objects
• Node
• Pod
• Service
• Label/Label Selector
• Deployment
• ReplicaSet
• DaemonSet
…

7. Node
• クラスターに属するマシン
を表すオブジェクト
• クラスターの管理を担当す
るマスターノードと、アプ
リケーションを稼働させる
メンバーノードがある
メンバーノード
マスターノード

8. Pod
• Node内で稼働するコンテ
ナのセット
• 生成/スケールアウト/破棄
等のライフサイクルの単位
• 内包する複数のコンテナは、
必ず同じノード上で稼働
• 1つのPodに1つのクラスタ
内IPが割り当てられる
ポッド
コンテナ

9. Service
• PodへのTCP/UDPアクセ
スの制御を行うオブジェク
ト
• Podへのルーティング、
ロードバランシングの役割
を持つ
• クラスター外部への公開、
クラスター内の通信など、
用途に応じて複数のタイプ
から選択可能
サービス
クラスター外から
のリクエスト

10. Label/Label Selector
• k8sオブジェクトを管理し易
いようにグルーピングする仕
組み
• Label:
• k8sオブジェクトにアタッチで
きるkey/valueペアのセット
• Label Selector:
• Labelの設定値の条件を指定す
る情報。条件に該当するものを
グループとして識別する
"labels": {
"tier" : "frontend",
"partition" : "customerA"
}
"labels": {
"tier" : “backend",
"partition" : "customerA"
}
"labels": {
"tier" : "frontend",
"partition" : "customerB"
}
Label
Label
partition = customerA
Label Selector

11. Label/Label Selector
• Serviceがルーティングの対象を識別するためにも利用される
サービス
partition = customerA
クラスター外から
のリクエスト

12. Label/Label Selector
• Serviceがルーティングの対象を識別するためにも利用される
サービス
partition = customerA
クラスター外から
のリクエスト

13. Deployment
• Podのライフサイクル（生
成/更新/破棄）を制御する
オブジェクト
• Podを起動したり、スケー
ルさせたりするときに、対
応するDeploymentに対し
て操作を行う
デプロイメント
D

14. ロギング

15. ロギングのアーキテクチャ
• 標準出力/標準エラー出力をContainer Engine(Docker)のlogging
driverがファイルとして出力[^1]
• logrotateツールがローテート
• logging agentがbackendにログを転送
• 例）agent → fluentd, backend → Elasticsearch
stdout/stderr
を書き出す
log-file.log
logrotate
ローテート
logging agent
(e.g. fluentd)
backend
(e.g. Elasticsearch)

16. システムコンポーネントのログ
• SystemコンポーネントにはContainerとして動くものと、そう
でないものがある
1. Containerとして動く→ Kubernetes Scheduler, kube-proxy…
2. Containerとして動かない→ kubelet, Docker…
• 1. のログは/var/logに出力される
• 2. のログはsystemdを使う場合はjournaldに、そうでない場合
は/var/logに出力される

17. 出力先を複数系統にしたい場合
• ファイルとして複数系統にログ出力
• sidecarコンテナを系統ごとに立て、それぞれがログファイルの
内容を標準/標準エラー出力に流す
system.log
logrotate
ローテート
logging agent
(e.g. fluentd)
backend
(e.g. Elasticsearch)
access.log

18. YAMLの記述例
kind: Pod
…
spec:
containers:
- name: count
image: busybox
args:
…
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-log-1
image: busybox
args: [/bin/sh, -c, ‘tail -n+1 -f /var/log/1.log’]
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-log-2
image: busybox
args: [/bin/sh, -c, ‘tail -n+1 -f /var/log/2.log’]
volumeMounts:
- name: varlog
mountPath: /var/log
…
var/log/配下のログファイルを
tailするコンテナ
var/log/配下のログファイルを
tailするコンテナ
アプリケーションのコンテナ。
var/log/配下に複数のログファ
イルを出力

19. 監査ログ
• kube-apiserverの起動オプションとして、監査ログの設定を指定することで、
有効になる
• --audit-log-path string
• 監査ログの出力先。 ‘-‘ を指定すると標準出力に書き出す
• --audit-log-format
• 監査ログのフォーマット
• --audit-log-maxage int
• 監査ログを保持しておく期間
• --audit-log-maxbackup
• 監査ログを保持しておく最大のファイル数
• --audit-log-maxsize
• 監査ログをローテートするまでの最大容量
• --audit-policy-file
• 監査ポリシーの設定を記述するファイルのパス。これを指定するとAdvancedAuditingが有効になる
• --audit-webhook-config-file
• 外部に監査イベントを送信するWebhook機能の設定ファイルのパス。Webhookは
‘AdvancedAuditingに含まれる機能
• --audit-webhook-mode
• Webhookの送信モードを指定するプロパティ
AdvancedAuditingはv１.9時点でBetaだが、
着実にエンハンスされている様子

20. ハンズオン (1)
manifestファイルをつかったkubectlの呼び出し方 / ロギングをやってみる

21. ハンズオンチュートリアルはこちら
•http://bit.ly/cndjp2-handson1

22. 後半戦

23. 後半戦のメニュー
1. 永続化の機能の使い方
2. コンテナのアップデート
3. セキュリティ上の考慮点

24. 永続化の機能の使い方

25. Volume
• コンテナにマウント可能なボリュームを定義する情報
• ディスクの実態をポイントする
Volumeの定義
保存領域の実態
マウント

26. YAMLでの記述例
• Podを定義するYAMLの例
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
…
volumeMounts:
- name: varlog
mountPath: /var/log
- name: config-volume
mountPath: /etc/counter-config
volumes:
- name: varlog
hostPath:
path: /var/log/counter
- name: config-volume
configMap:
name: counter-config
コンテナにマウントするVolumeと、
マウント先のパスの指定
ボリュームの定義。Volumeの名前
と保存領域の実態の指定

27. PersistentVolume/PersistentVolumeClaim
• PersistentVolumeClaimで必要なディスクの要件を指定すると、
それを満たすPersistentVolumeが自動的に選択される
Volume
PersistentVolume
Claim
Persistent
Volume

28. YAMLでの記述例
• Podを定義するYAMLの例
apiVersion: apps/v1beta1
kind: Pod
spec:
…
template:
…
spec:
containers:
- image: sample/mysql
name: mysql
…
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
Volumeを指定するところで
PersistentVolumeClaimを指定

29. YAMLの記述例
• PersistentVolume/PersistentVolumeClaimのYAMLの例
• この場合Claimの要件をPersistentVolumeを満たすので、選択される候補と
なる
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-hostpath-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
hostPath:
path: /data/mysql
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi

30. Volumeのいろいろな使い方
• 通常のディスクとして使う以外に、Containerに設定情報など
を受け渡す手段としても使われる（詳細は後述）
• secret, downwardAPI, ConfigMap
• コンテナからはKey/Valueが記述されたファイルや、環境変数
として、これらの情報を参照できる
Volume定義として
設定情報を記述

31. Volumeの種類（一部）
• 一般的なデータの保持に
利用するもの
• 設定情報等の受け渡し用
• secrets
• downwardAPI
• configMap
• Kubernetesでは様々なディスクボリュームをサポート
• お試し用？
• hostPath
• emptyDir
• 本番用
• awsElastic
BlockStore
• cephfs
• nfs
• iscsi
…
• その他
• flocker
• gitRepo
…

32. hostPath
• Podが稼働するホストのファイル/ディレクトリをコンテナにマ
ウントして利用する方式
• ストレージ領域を別で用意する必要がなく、比較的手軽に利用
できるので、デモ用途等に向く
• 他に、ホストOSのファイルシステムにアクセスする必要がある
ときにも利用する
• e.g. cAdvisorを使っているとき

33. hostPath利用時の注意点
• Volumeの設定が同じPodでも、マウントされるNode異なれば、
マウントされるファイルの内容が違う（稼働しているホストの
ファイルシステムがマウントされるため）
→特にPodをスケールアウトさせると危険
• 書き込みをするには、コンテナをroot権限で実行する
(privileged container)か、マウントされる領域に対して書込み
権限を与える必要がある

34. awsElasticBlockStore
• AWSのEBSを利用する方式
• AWS EC2でPodを稼働させているときしか使えない
• 同じEBSをマウントできるPodは一つだけ
• EC2インスタンスとEBSが同一リージョン、同一AZに配置され
る必要がある

35. iscsi/nfs
• iscsi
• iSCSIボリュームをマウントする方式
• nfs
• NFS(Network File System)ボリュームをマウントする方式

36. downwardAPI
• コンテナ内のアプリケーショ
ンが、自分自身が稼働する環
境(Container, Pod, Node)の情
報を取得するために使う
• この例では、
• /etc/labelsからlabelのキー/値
• /etc/annotationsから
annotationのキー/値を取得でき
る
apiVersion: v1
kind: Pod
metadata:
name: downwardapi-volume-example
labels:
…
annotations:
…
spec:
containers:
…
volumeMounts:
- name: podinfo
mountPath: /etc
readOnly: false
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: meta.labels
- path: "annotations"
fieldRef:
fieldPath: meta.annotations

37. downwardAPI
• 取得できる値（v1.8時点）
• Node名
• NodeのIP
• Pod名
• Podのnamespace
• PodのIP address
• Podのservice account名
• PodのUID
• ContainerのCPU limit
• ContainerのCPU request
• Containerのmemory limit
• Containerのmemory request
• Podに設定されたlabel
• Podに設定されたannotation

38. configMap
• 一般的な設定情報を受け渡すた
めに使う…。
• この例では、
• /etc/config/example.prop.1
というファイルに値”hello”が入る
• /etc/config/example.prop.1
というファイルに値”world”が入る
apiVersion: v1
kind: ConfigMap
metadata:
name: example-config
data:
example.prop.1: hello
example.prop.2: world
---
apiVersion: v1
kind: Pod
metadata:
name: pod-using-config
spec:
containers:
- name: example-container
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: example-config

39. secrets
• 機密度の高い情報を保持する際に使う
Volume
• DBなどの接続情報
• クララスター内/外のサービスのアクセストーク
ン
• SSL/TLSの証明書
…
• コンテナで利用するときはメモリ内に保持
され、不要になったら削除される（tmpfsが
使われている）
• ファイルの実態はマスターノード(etcd)に
保持される
etcd

40. secrets利用時の注意点
• etcdに平文で保持されるので、ここをしっかり守る
• etcdのデータを正しく管理する
• アクセス権制御を行う
• 秘密情報を書き込んだsecretsオブジェクトのYAML/JSON定義
を、ソースコードリポジトリに入れない
• アプリケーションが秘密情報を取得したら、それを正しく扱う
よう実装すること（Kubernetesのレイヤーでは何もできない）

41. Volumeの種類は他にも沢山…。
• ドキュメントに目を通すと良い。
• https://kubernetes.io/docs/concepts/storage/volumes/

42. PersistentVolumeの動的プロビジョニング
• PVC内でStorageClassを指定。StorageClassは性能やサービスレベ
ルに対応付けて作成するオブジェクト
• PVCが作られると、StorageClassで設定されたプロビジョナーが
Volumeを確保しにいく
Volume
PersistentVolume
Claim
StorageClass
Provisioner

43. YAMLの記述例
• Storageの速度の違いで名前を
分けた場合の例
（Google Compute Engineのサー
ビスの種類を対応付けている）
• provisionerがGCE上にストレー
ジを確保する操作を行う
• parametersはprovisioner固有の
設定値
• reclaimPoliciyで解放後に
Volumeを削除するか、残すか
を指定(Delete/Retain)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Retain
parameters:
type: pd-standard
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Retain
parameters:
type: pd-ssd

44. YAMLの記述例
• PersistentVolumeClaimでStorageClass: fastを指定
→ 対応するStorageClassに書かれたprovisionerとパラメータ
でボリュームを確保
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast
resources:
requests:
storage: 30Gi
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Retain
parameters:
type: pd-ssd

45. コンテナのアップデート

46. ローリングアップデート
• Deploymentオブジェクトを使ってコンテナを展開しておくと、
ReplicaSetが自動的にアップデート管理してくれるようになる
• コンテナイメージの変更（例えばv1 -> v2に差し替え）を支持
すると、自動的にローリングアップデートが行われる
> kubectl set image deployments/[Deployment名] [イメージ
名]

47. カナリーデプロイメント
• Label, LabelSelectorをうまく使うことで実現する。
まずは初期状態…
labels:
tier: front
app: guestbook
track: stable
Image: guestbook:v1
D

48. カナリーデプロイメント
• tierとappのLabelの値でルーティング対象となるようにService
にLabelSelectorを設定
tier = front
app = guestbook
クラスター外から
のリクエスト
D
Service
labels:
tier: front
app: guestbook
track: stable
Image: guestbook:v1

49. カナリーデプロイメント
• カナリーとして新バージョンのコンテナを追加する際、Service
のルーティング対象となるようにlabelを設定してDeployment
を作成
Service
tier = front
app = guestbook
クラスター外から
のリクエスト
D
D labels:
tier: front
app: guestbook
track: stable
Image: guestbook:v1
labels:
tier: front
app: guestbook
track: canary
Image: guestbook:v2

50. カナリーデプロイメント
• 最終的に、安定版(この例ではtrack=stable）のイメージを、新
バージョンに変更する
tier = front
app = guestbook
クラスター外から
のリクエスト
D
Service
labels:
tier: front
app: guestbook
track: stable
Image: guestbook:v2

51. セキュリティ上の考慮点

52. セキュリティ上の考慮点 – クラスターレベル
• 外部とやりとりするところの…
apiserver API呼び出し
SSHアクセス
>_
コンテナレジストリ
アプリケーションへリクエスト
kubelet API呼び出し
コンテナ取得

53. セキュリティ上の考慮点 – クラスターレベル
• それぞれで対策を講じる
apiserver API呼び出し
SSHアクセス
>_
コンテナレジストリ
アプリケーションへリクエスト
kubelet API呼び出し
コンテナ取得  APIの認証/認可機能を利用する
 Nodeへの
SSHアクセスを制限する
 コンテナ
レジストリの
クレデンシャルを保護する
 APIの認証/認可機能を利用する

54. apiserverのAPIの
認証/認可機能を利用する
• 認証方式として選択できるもの
• X.509証明書
• 固定のトークン
• LDAP連携
• OpenID Connect
…
• 要件に応じて適したものを選ぶ…。

55. apiserverのAPIの
認証/認可機能を利用する
• 以下の情報を使って制限をかけられる模様
• ユーザー
• グループ
• 認証時に設定したキー／値
• API Resourceに対する操作か否か
• リクエストのパス
• APIリクエストの種類(get, list, create…)
• HTTPリクエストの種類(GET, POST…)
• 操作しようとしているリソース／そのサブリソース
• Namespace
• APIグループ
• すいません詳細は勉強します
• https://v1-8.docs.kubernetes.io/docs/admin/authorization/

56. kubelet APIの認証/認可機能を利用する
• kubelet APIはクラスター内部で使われるInternalなもの
• kubeletのAPIはデフォルトで匿名アクセスを許可する設定になって
いるので、これを無効にする
• kubeletの起動時に--anonymous-auth=falseを設定
• 認可もデフォルトでは全て許可（認証に成功すればどの操作もでき
る）されている。
以下の設定でapiserverのAPIのポリシーを適用するように変更
• apiserverでauthorization.k8s.io/v1beta1のAPIグループを有効化
• 以下のフラグを設定してkubeletを起動
• --authorization-mode=Webhook, --kubeconfig, --require-kubeconfig

57. NodeへのSSHをアクセスを制限する
• NodeにSSH等で直接アクセスを行うと、Kubernetesの認証/認
可機構を無視して操作できてしまう。
• NodeのOSに直接アクセスする手段は、必要以上に利用せず、
“kubectl exec”コマンドで代替する。
> kubectl exec [Podの名前] [コマンド]

58. コンテナレジストリの
クレデンシャルを安全に保持する
• コンテナレジストリへのアクセス情報を保持するSecretを作成
し、Podでそれを利用するように設定する
apiVersion: v1
kind: Pod
metadata:
name: private-reg
spec:
containers:
- name: private-reg-container
image: <your-private-image>
imagePullSecrets:
- name: <secret-name>imagePullsecretsでSecretを指定

59. コンテナレジストリの
クレデンシャルを安全に保持する
• Secretの作り方
• このSecretには、docker login を実行したときに作られるDockerレ
ジストリのアクセストークンと同じデータが含まれる
> kubectl create secret docker-registry <secret-name>
--docker-server=<your-registry-server>
--docker-username=<your-name>
--docker-password=<your-password>
--docker-email=<your-email>

60. セキュリティ上の考慮点 – コンテナレベル
• コンテナ自体の安全性を確保する
• 信頼できる／メンテできるコンテナを利
用する
• コンテナ内のSWの脆弱性対策をおこな
う
• コンテナが悪さをしたときに
影響を最小限にする
• 利用リソースを制限する
• ネットワークアクセスを制限する
• 実行権限を調整する
• 稼働するノードを制限する

61. 信頼できる／メンテできるコンテナを
利用する
• イメージの生い立ち
• 誰が、いつ、どうやって作ったイメージか
• 信頼できる配布元が作成したものか
• メンテナンスが継続的に行われているか
• 不必要なパッケージが少ないこと
• 不必要なパッケージが少ないほど潜在的な注意を払う対象が減る
• 脆弱性の発見しやすさ
• 脆弱性があることを検知できるか
• 脆弱性対応状況が公開されているか
• サポート
• セキュリティパッチはどのくらいの期間提供されるか

62. コンテナ内のSWの脆弱性対策をおこなう
• 脆弱性の継続的な調査
• コンテナにセキュリティパッチを適用
＝コンテナに対しても、当たり前のことをちゃんとやる
CIツールも充実してきているので、うまく活用しましょう

63. コンテナの利用リソースを制限する
• Resource quotaを設定して大量のリソースを専有してしまうこ
とを防止する
• Resource quotaはNamespace単位で設定するのが基本
• Namespaceはクラスター内のオブジェクト群をくくる単位
（e.g. 開発者ごとにNamespaceを割り当ててクラスターを共有するなど）
• Namespaceの作り方
> kubectl create namespace mem-limited-example

64. コンテナの利用リソースを制限する
• Resource quotaのYAML定義
• メモリ量を制限する例 apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
このquotaが設定されたNamespaceの
コンテナは、デフォルトで256M割り当
てられ、512Mが上限となる

65. コンテナのネットワークアクセスを制限
する
• NetworkPolicyでPod間のアク
セスポリシーを定義する
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
run: nginx
ingress:
- from:
- podSelector:
matchLabels:
access: "true"
ポリシーを適用するPodを特定する
Label
access: “true”が設定された
オブジェクトからのアクセスのみ
受け付ける

66. コンテナ実行時の権限を調整する
• SecurityContextを
設定して、コンテナ
の実行ユーザーを指
定する
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 1000
containers:
- name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
このPod内のコンテナは
UID 1000のユーザーで実行
コンテナ毎に設定すると
Pod単位の設定をオーバー
ライドする

67. コンテナが稼働するノードを制限する
• NodeSelectorをPodに設定
• 所定のLabelが設定された
Nodeにのみデプロイされる
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssdこのPodは、disktype: ssdが設定さ
れたNodeにのみデプロイされる

68. その他のセキュリティ対策
• etcdのバックアップを暗号化する
• 各種クレデンシャルを安全に保持する
（secretsを利用する）
etcd

69. その他のセキュリティ対策
• 各種ログをちゃんと取る（やりかたは前述）
• 監査ログを有効にする
• 各ノードのログを取得する

70. ハンズオン (2)
アプリケーションを動かしてみよう！

71. ハンズオンチュートリアルはこちら
•http://bit.ly/cndjp2-handson2

72. 次回予告

73. 次回コンテンツ
• 「Kubernetes Network Deep Dive!」
• コンテンツ
• 今回取り上げられなかった、k8sネットワーク周りを深掘り
• サービス・メッシュでk8s上にインテリジェントなネットワークを

74. お疲れ様でした！
#cndjp1