Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes標準のストレージ機能をおさらいしよう

36bb9dcd778d2a9621d44e92425d0907?s=47 hhiroshell
October 04, 2018

 Kubernetes標準のストレージ機能をおさらいしよう

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

36bb9dcd778d2a9621d44e92425d0907?s=128

hhiroshell

October 04, 2018
Tweet

Transcript

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

  2. Cloud Native Developers JP • 早川 博(はやかわ ひろし) • 日本オラクル所属

    – なのにOSSとコミュニティ活動ばかり やっているアレな人 • Ergodoxユーザー 2 自己紹介 @hhiroshell
  3. Cloud Native Developers JP 宣伝 • Kubernetesを完全にガイドしてくれる本のお手伝いをさせていただ きました • 動かしながら読み進めるのがおすすめ

    – GKE + Cloud Shell – サンプルmanifestをclone • https://github.com/MasayaAoyama/kubernetes-perfect-guide → ブラウザさえあればいつでも k8s 学べます 3
  4. Cloud Native Developers JP お品書き • Kubernetesでストレージを利用する方法 • いろいろなストレージタイプ •

    What’ new in Kubernetes 1.12 4
  5. Cloud Native Developers JP Kubernetesでストレージを利用する方法 5

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

    Volumeの要件を指定して、満たすストレージを動的にプロビジョニ ングしてマウントする 6
  7. Cloud Native Developers JP Volume • コンテナにマウント可能なボリュームを定義する情報 • ストレージの実態をポイントする 7

    Volume(たとえばNFSのストレージ) ストレージの実態 マウント Pod
  8. 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
  9. Cloud Native Developers JP PersistentVolume(PV)/PersistentVolumeClaim(PVC) • PVでストレージの実態をポイントする • PVCで必要なディスクの要件(容量/書き込み権限の有無など)を指 定しておき、それをVolumeから参照する

    • PVCの要件を満たすPVが自動的に選択され、使用される Volume PVC PV 9 Pod
  10. 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
  11. 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
  12. Cloud Native Developers JP StorageClassを使ったPVCの動的プロビジョニング • PVCでPVの代わりにStorageClassを指定 • 上記PVCをKubernetes内に作ると、StorageClassで設定されたProvisionerがス トレージをプロビジョニングし、それが利用される

    • StorageClassでは、ディスク速度やサービスレベル等のパラメータを指定 Volume PVC PV GCEPersistentDisk(例) 12 Pod SC SP Provisioner StorageClass
  13. 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
  14. 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
  15. Cloud Native Developers JP PVやPVCでよく使う設定 • Reclaim Policy – PVが削除されたときのディスクボリュームの挙動を指定する設定

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

  17. 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/
  18. 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
  19. 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
  20. 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/ より抜粋
  21. Cloud Native Developers JP ConfigMap • コンテナに設定情報を渡すために使う • ConfigMapに記述した設定情報を、大きく分けて以下の2通りの方法 で渡すことができる

    – コンテナの環境変数として渡す – 設定情報が記述されたファイルとして渡す 21
  22. 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に記述された設定をコンテナの環境変数として読み込む
  23. 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
  24. Cloud Native Developers JP Secret • 機密度の高いデータを保持する際に使うVolume。大きく4種類がある – 一般的な機密度の高い設定情報(e.g. DB接続情報)

    – TLSの証明書 – Dockerレジストリの接続情報 – クララスター内/外のサービスのアクセストークン • データの実態はマスターノード(etcd)に平文で保持される • Secretのmanifestにはbase64エンコードして記述するだけなので、 コードリポジトリへのアップロードは不可 → kubescなどのツールを利用する 24
  25. Cloud Native Developers JP ConfigMapとSecretの違い • コンテナでSecretのデータを読み込むと、必ずメモリ内に保持され、 不要になったら削除される(tmpfsが使われている) 25

  26. 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
  27. 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
  28. Cloud Native Developers JP • emptyDir – Pod用の一時的なディスク領域を確 保して利用する方式 –

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

  30. Cloud Native Developers JP 1.12で追加/promoteされたVolume周りの機能 • Mount Propagation (beta ->

    GA) • Volume Binding Mode (alpha -> beta) • Volume Snapshots (new / alpha) 30
  31. 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
  32. Cloud Native Developers JP • None – お互いに追加でマウント された結果は反映されな い

    • HostToContainer – Nodeでの追加マウントが Containerに反映される 32 • Bidirectional – お互いの追加マウントが 反省される – Dangerous Mount Propagation (beta -> GA) Node Container Node Container Node Container
  33. 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
  34. 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
  35. 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
  36. Cloud Native Developers JP Volume Binding Mode (alpha -> beta)

    • もう一度絵を見てみる…。 – デフォルトではPVCが作成されたタイミングで、ストレージがプロビジョニン グされる(Immediate) → このタイミングをPod作成時にする(WaitForFirstConsumer) 36 Volume PVC PV GCEPersistentDisk(例) Pod SC SP Provisioner StorageClass
  37. 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.
  38. 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
  39. 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
  40. Cloud Native Developers JP Volume Snapshots (new / alpha) •

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

    PV/PVC/StorageClassに似た関係性 – VolumeSnapshotContent → PersistentVolume – VolumeSnapshot → PersistentVolumeClaim – VolumeSnapshotClass: → StorageClass 41 PVC GCEPersistentDisk(例) VsClass snapshotter VolumeSnapshotContent Vs
  42. 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
  43. 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が仕事をする
  44. 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
  45. 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
  46. Cloud Native Developers JP 46 Fin