Cloud Native Developers JP Kubernetes標準のストレージ機能を おさらいしよう @hhiroshell 1

Cloud Native Developers JP • 早川 博（はやかわ ひろし） • 日本オラクル所属 – なのにOSSとコミュニティ活動ばかり やっているアレな人 • Ergodoxユーザー 2 自己紹介 @hhiroshell

Cloud Native Developers JP 宣伝 • Kubernetesを完全にガイドしてくれる本のお手伝いをさせていただ きました • 動かしながら読み進めるのがおすすめ – GKE + Cloud Shell – サンプルmanifestをclone • https://github.com/MasayaAoyama/kubernetes-perfect-guide → ブラウザさえあればいつでも k8s 学べます 3

Cloud Native Developers JP お品書き • Kubernetesでストレージを利用する方法 • いろいろなストレージタイプ • What’ new in Kubernetes 1.12 4

Cloud Native Developers JP Kubernetesでストレージを利用する方法 5

Cloud Native Developers JP Kubernetesでストレージを利用する方法 • Volumeを直接指定してContainerにマウントする • Volumeの要件を指定して、満たすものを自動的にマウントする • Volumeの要件を指定して、満たすストレージを動的にプロビジョニ ングしてマウントする 6

Cloud Native Developers JP Volume • コンテナにマウント可能なボリュームを定義する情報 • ストレージの実態をポイントする 7 Volume（たとえばNFSのストレージ） ストレージの実態 マウント Pod

Cloud Native Developers JP Volumeの最もシンプルな使い方 • spec.volumes: – このPodで参照可能な Volumeを定義 • spec.containers.volumeMounts: – コンテナにマウントする Volumeと、マウント先のパ スを指定 • Deploymentsなどで、 templatesに書くときも同 様 8 apiVersion: v1 kind: Pod metadata: name: welcome-nfs spec: containers: - name: welcome-nfs image: busybox args: [/bin/sh, -c, 'tail -f /mnt/ngs/hello.txt'] volumeMounts: - name: nfs-example mountPath: "/mnt/nfs" volumes: - name: nfs-example nfs: server: 10.0.40.8 path: "/nfs-example" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP PersistentVolume(PV)/PersistentVolumeClaim(PVC) • PVでストレージの実態をポイントする • PVCで必要なディスクの要件（容量／書き込み権限の有無など）を指 定しておき、それをVolumeから参照する • PVCの要件を満たすPVが自動的に選択され、使用される Volume PVC PV 9 Pod

Cloud Native Developers JP PersistentVolume(PV) • ストレージの実態をポイントする • 右はgcePersistentDisk（Google Cloud のストレージサービス）を利用する 例 • PVはクラスターレベルのリソー スであり、クラスター内のどの Namespaceからも利用することが できる 10 apiVersion: v1 kind: PersistentVolume metadata: name: sample-pv labels: type: gce-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain gcePersistentDisk: pdName: sample-gce-pv fsType: ext4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP PersistentVolumeClaim(PVC) • PVCで必要なディスクの要件（容 量／書き込み権限の有無など）を 指定 • Podから参照可能なvolumeとして、 PVCを指定する • PVCの要件を満たすPVがクラス ター内にあれば、それが利用され る 11 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: sample-pvc spec: resources: requests: storage: 4Gi accessModes: - ReadWriteOnce --- apiVersion: v1 kind: Pod metadata: name: sample-pvc-pod spec: containers: … volumeMounts: - mountPath: "/usr/share/nginx/html" name: nginx-pvc volumes: - name: nginx-pvc persistentVolumeClaim: claimName: sample-pvc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Cloud Native Developers JP StorageClassを使ったPVCの動的プロビジョニング • PVCでPVの代わりにStorageClassを指定 • 上記PVCをKubernetes内に作ると、StorageClassで設定されたProvisionerがス トレージをプロビジョニングし、それが利用される • StorageClassでは、ディスク速度やサービスレベル等のパラメータを指定 Volume PVC PV GCEPersistentDisk（例） 12 Pod SC SP Provisioner StorageClass

Cloud Native Developers JP StorageClass • StorageClassでProvisionerを指定 • 指定されたProvisionerがストレー ジをプロビジョニングしてくれる • Provisionerによって設定できるパ ラメータが異なる • 右はGoogle Cloudのストレージ サービスのProvisionerを使う例 13 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: sample-storageclass parameters: type: pd-ssd provisioner: kubernetes.io/gce-pd reclaimPolicy: Delete 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP PVC（StorageClass利用） • PVCのannotationでクラ スターに登録されてい るStorageClassを指定 14 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: sample-pvc-provisioner annotations: volume.beta.kubernetes.io/storage-class: sample-storageclass spec: accessModes: - ReadWriteOnce resources: requests: storage: 3Gi --- apiVersion: v1 kind: Pod metadata: name: sample-pvc-provisioner-pod spec: containers: … volumeMounts: - mountPath: "/usr/share/nginx/html" name: nginx-pvc volumes: - name: nginx-pvc persistentVolumeClaim: claimName: sample-pvc-provisioner 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Cloud Native Developers JP PVやPVCでよく使う設定 • Reclaim Policy – PVが削除されたときのディスクボリュームの挙動を指定する設定 • Delete: ディスクボリュームが削除される • Retain: ディスクボリュームが削除されない。別のPV/PVCからの再利用はできない • Recycle: ディスクボリューム内のデータだけが削除され、別のPV/PVCから再利用される 将来的に廃止予定。StorageClassへの移行が推奨されている • Access Mode – ボリュームに対するアクセス制御の設定 • ReadWriteOnce: 1つのノードから読み込み、書き込みアクセスが可能 • ReadOnlyMeny: 複数のノードから読み込み可能。書き込み不可 • ReadWriteMeny: 複数のノードから読み込み、書き込みアクセスが可能 15

Cloud Native Developers JP いろいろなストレージタイプ 16

Cloud Native Developers JP Volumeの種類（抜粋） • Kubernetesでは様々なディスクボリュームをサポートしている • 秘匿情報を安全に保持するなど、単なるデータの永続化だけの用途 以外でもVolumeが使われる • いわゆるストレージ – nfs – iscsi – gcePersistentDisk • テンポラリな保存領域として – emptyDir – hostPath • 設定情報等の受け渡し用 – configMap – secret – downwardAPI • 他 – flocker – gitRepo 17 https://kubernetes.io/docs/concepts/storage/volumes/

Cloud Native Developers JP nfs • NFSをマウントします （あたりまえ） 18 apiVersion: v1 kind: Pod metadata: name: welcome-fss spec: containers: - name: welcome-fss image: busybox args: [/bin/sh, -c, 'tail -f /mnt/fss/hello.txt'] volumeMounts: - name: nfs-example mountPath: "/mnt/nfs" volumes: - name: nfs-example nfs: server: 10.0.40.8 path: "/nfs-example" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP gcePersistentDisk • Google Cloudのストレー ジサービスを利用 19 apiVersion: v1 kind: PersistentVolume metadata: name: sample-pv labels: type: gce-pv environment: stg spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: manual gcePersistentDisk: pdName: sample-gce-pv fsType: ext4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP サポートされるアクセスモードの違い Volume Plugin ReadWriteOnce ReadOnlyMany ReadWriteMany AWSElasticBlockStore ✓ AzureFile ✓ ✓ ✓ AzureDisk ✓ GCEPersistentDisk ✓ ✓ HostPath ✓ iSCSI ✓ ✓ NFS ✓ ✓ ✓ 20 • （なにか一言説明を） https://kubernetes.io/docs/concepts/storage/persistent-volumes/ より抜粋

Cloud Native Developers JP ConfigMap • コンテナに設定情報を渡すために使う • ConfigMapに記述した設定情報を、大きく分けて以下の2通りの方法 で渡すことができる – コンテナの環境変数として渡す – 設定情報が記述されたファイルとして渡す 21

Cloud Native Developers JP • キーを指定して1つずつ参照 • ConfigMapの内容を一括参照 • キー名はConfigMap内のキー名が 使われる 22 ConfigMapの内容を参照する方法いろいろ – 環境変数 apiVersion: v1 kind: Pod … spec: containers: … env: - name: CONNECTION_MAX valueFrom: configMapKeyRef: name: sample-configmap key: connection.max 1 2 3 4 5 6 7 8 9 10 11 12 apiVersion: v1 kind: Pod … spec: containers: … envFrom: - configMapRef: name: sample-configmap 1 2 3 4 5 6 7 8 9 ConfigMapに記述された設定をコンテナの環境変数として読み込む

Cloud Native Developers JP • キーを指定して1つずつ参照 23 ConfigMapの内容を参照する方法いろいろ – Volume spec: containers: … volumeMounts: - name: config-volume mountPath: /config volumes: - name: config-volume configMap: name: sample-configmap items: - key: nginx.conf path: nginx-sample.conf 1 2 3 4 5 6 7 8 9 10 11 12 13 ConfigMapに記述された設定をVolumeとしてマウント。コンテナから は設定が記述されたファイルとして参照する • ConfigMapの内容を一括参照 spec: containers: … volumeMounts: - name: config-volume mountPath: /config volumes: - name: config-volume configMap: name: sample-configmap 1 2 3 4 5 6 7 8 9 10 11 12 13

Cloud Native Developers JP Secret • 機密度の高いデータを保持する際に使うVolume。大きく4種類がある – 一般的な機密度の高い設定情報（e.g. DB接続情報） – TLSの証明書 – Dockerレジストリの接続情報 – クララスター内/外のサービスのアクセストークン • データの実態はマスターノード(etcd)に平文で保持される • Secretのmanifestにはbase64エンコードして記述するだけなので、 コードリポジトリへのアップロードは不可 → kubescなどのツールを利用する 24

Cloud Native Developers JP ConfigMapとSecretの違い • コンテナでSecretのデータを読み込むと、必ずメモリ内に保持され、 不要になったら削除される（tmpfsが使われている） 25

Cloud Native Developers JP downwardAPI • コンテナ内のアプリケー ションが、自分自身が稼働 する環境(Container, Pod, Node) の情報を取得するために使 う • この例では、 – /etc/labelsからlabelのキー/値 – /etc/annotationsからannotation のキー/値を取得できる 26 apiVersion: v1 kind: Pod metadata: name: downwardapi-volume-example … 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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Cloud Native Developers JP downwardAPIで取得できる値 • 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 27 https://kubernetes.io/docs/tasks/inject-data-application/downward-api- volume-expose-pod-information/#capabilities-of-the-downward-api

Cloud Native Developers JP • emptyDir – Pod用の一時的なディスク領域を確 保して利用する方式 – データの実体がどこにあるかは隠蔽 されており、Node上のファイルに アクセスすることもできない – Podが停止すると、データも削除さ れる • hostPath – Podが稼働するNodeのファイル/ ディレクトリをコンテナにマウント して利用する方式 – 書き込みをするには、マウントされ る領域に対して然るべき権限を与え る必要がある – Pod停止後にデータを保持するかど うかはReclaim Policyの設定に従う 28 hostPathとemptyDir 外部のストレージが用意できない／用意するほどの用途ではないとき に使う

Cloud Native Developers JP What’s New in Kubernetes 1.12 29

Cloud Native Developers JP 1.12で追加/promoteされたVolume周りの機能 • Mount Propagation (beta -> GA) • Volume Binding Mode (alpha -> beta) • Volume Snapshots (new / alpha) 30

Cloud Native Developers JP Mount Propagation (beta -> GA) • マウントされたVolume配下に更に追加のマウントが行われたときに、 Pod/Nodeでそれを共有できるかどうかを決める設定 – None: 追加のマウントは互いに参照できない（デフォルト） – HostToContainer: オリジナルにマウントされたものがContainerから参照できる 逆は不可 – Bidirectional: 追加のマウントが互いに参照できる • NodeのOSによっては、Dockerのsystemd service fileに以下のフラグを 付ける必要あり（CoreOS, RedHat/Centos, Ubuntuは該当するらしい） – MountFlags=shared （要Docker daemon再起動） 31

Cloud Native Developers JP • None – お互いに追加でマウント された結果は反映されな い • HostToContainer – Nodeでの追加マウントが Containerに反映される 32 • Bidirectional – お互いの追加マウントが 反省される – Dangerous Mount Propagation (beta -> GA) Node Container Node Container Node Container

Cloud Native Developers JP Mount Propagation (beta -> GA) • manifestの記述例 33 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: local-test-reader spec: … template: … spec: containers: - image: gcr.io/google_containers/busybox:1.24 name: reader volumeMounts: - mountPath: /usr/test-pod mountPropagation: Bidirectional name: local-vol volumes: … 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP Mount Propagation (beta -> GA) • 参考文献 – Kubernetesのドキュメント • https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation – 有志のブログ（これが良かった） • https://medium.com/kokster/kubernetes-mount-propagation-5306c36a4a2d 34

Cloud Native Developers JP Volume Binding Mode (alpha -> beta) • 動的プロビジョニングやPVとVolumeの結合(Bind)が実行されるタイミ ングを制御するモード(volumeBindingMode)の追加 – Immediate: PVCが作成されたタイミングで上記の処理が実行される（デフォルト） – WaitForFirstConsumer: PVCを利用するPodが作成されたタイミングで上記の処理が実行される • StorageClassに設定する属性 • Podの配置制御と同様の設定を適用できる → Podと同じZoneやNodeにVolumeが作成されるように制御できる 35

Cloud Native Developers JP Volume Binding Mode (alpha -> beta) • もう一度絵を見てみる…。 – デフォルトではPVCが作成されたタイミングで、ストレージがプロビジョニン グされる(Immediate) → このタイミングをPod作成時にする(WaitForFirstConsumer) 36 Volume PVC PV GCEPersistentDisk（例） Pod SC SP Provisioner StorageClass

Cloud Native Developers JP Volume Binding Mode (alpha -> beta) • WaitForFirstConsumerモードで使用できる配置制御の属性 (These include, but are not limited to) – resource requirements – node selectors • サポートされるProvisioner – AWSElasticBlockStore（動的／PV事前作成） – GCEPersistentDisk（動的／PV事前作成） – AzureDisk（動的／PV事前作成） – Local（PV事前作成） 37 – pod affinity / anti-affinity – taints and tolerations.

Cloud Native Developers JP Volume Binding Mode (alpha -> beta) • manifestの記述例 38 kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/gce-pd parameters: type: pd-standard volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: failure-domain.beta.kubernetes.io/zone values: - us-central1-a - us-central1-b 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP Volume Binding Mode (alpha -> beta) • 参考文献 – Kubernetesのドキュメント • https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode • https://kubernetes.io/docs/concepts/storage/storage-classes/#allowed-topologies 39

Cloud Native Developers JP Volume Snapshots (new / alpha) • PVのSnapshotの取得／リストアを行う機能 • Kubernetes 1.8でprototypeとしてリリースされていた • 関係するリソース – VolumeSnapshotContent : 取得されたSnapshot。動的Snapshotでは自動生成 – VolumeSnapshot : Snapshot取得のリクエストを表現するリソース – VolumeSnapshotClass: : Snapshotの実体（どのようにストレージに保持する か）を定義するリソース • CRDベースのAPI拡張でこれらのリソースが実現されている 40

Cloud Native Developers JP Volume Snapshots (new / alpha) • PV/PVC/StorageClassに似た関係性 – VolumeSnapshotContent → PersistentVolume – VolumeSnapshot → PersistentVolumeClaim – VolumeSnapshotClass: → StorageClass 41 PVC GCEPersistentDisk（例） VsClass snapshotter VolumeSnapshotContent Vs

Cloud Native Developers JP Volume Snapshots (new / alpha) • manifestの記述例 42 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass snapshotter: csi-hostpath --- apiVersion:snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: snapshot-demo spec: snapshotClassName: csi-hostpath-snapclass source: name: hpvc kind: PersistentVolumeClaim 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Cloud Native Developers JP • external-snapshotter – VolumeSnapshotに対するController。VolumeSnapshotリソースをウォッチして、 Snapshotの作成や削除をトリガーする – CSIドライバーのsidecarコンテナとしてクラスターにデプロイされる – external-snapshotterのリポジトリに行くと、hostPathのドライバーでセット アップするための一式がある（リンクは後述） Volume Snapshots (new / alpha) 43 etcd Master S VolumeSnapshot external snapshotter CSI driver sanpshotter(Pod) ※VolumeSnapshotClassに紐付い たsnapshotterが仕事をする

Cloud Native Developers JP Volume Snapshots (new / alpha) - 実際使えるのか？ • CSI v0.3.0が実装されているCSIドライバーがあるストレージでのみ Snapshotを利用可能 – CSIドライバー経由のSnapshot作成のみをサポート – Snapshot関連の仕様が追加されたのはCSI v0.3.0から • 上に照らすと以下のCSIドライバーは使えるはず（他は未確認。まと まった情報がない） – hostPath – gcp-compute-persistent-disk-csi-driver • 前述のexternal-snapshotterのコードで、CSIドライバーの部分を変更 すればgcpで動く…のか？（要検証。そのまえにGKEで1.12が出ないと） 44

Cloud Native Developers JP Volume Snapshots (new / alpha) • 参考文献 – Kubernetesのドキュメント • https://kubernetes.io/docs/concepts/storage/volume-snapshots/ • https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/ – Design Proposal • https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi- snapshot.md – CSIのスペック(v0.3.0) • https://github.com/container-storage-interface/spec/tree/v0.3.0 – external-snapshotterのリポジトリ • https://github.com/kubernetes-csi/external-snapshotter – GCPのCSIドライバーのリポジトリ • https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver 45

Cloud Native Developers JP 46 Fin