当該コンテンツは、ローカリゼーションサービスを準備しております。早急にローカライズサービスをご提供できるよう、努めております。

ブロックストレージCSI利用ガイド

始める前に

すべてのコンテナは、ビルド時点に追加されたファイルで駆動されます。 その後コンテナのファイルシステム内に新たに追加されたファイルは、 プロセスが終了するか、Kubernetesのliveness Probeの状態チェックが失敗してコンテナが再起動する場合、すべて除去されます。

コンテナが再起動する場合でも、前述の追加ファイルが引き続き維持されることを希望する場合、配布時に生成できる PersistentVolumeClaim(PVC)を通じてデータを保存するために生成できる永久リポジトリであるブロックストレージを利用できます。

NAVERクラウドプラットフォームのKubernetes Serviceは、ボリュームドライバとしてContainer Storage Interface(CSI)を提供します。 このボリュームドライバーは Kubernetesと連動して、ブロックストレージ生成と削除およびattaching、detaching、resizingのような作業を支援します。

制約事項

サポート·バージョン

NAVERクラウドプラットフォームのKubernetes Serviceは、ブロックストレージボリュームドライバとしてCSIを提供します。 CSIドライバとKubernetes間の連携のためには、互換性のあるバージョンを確認する必要があります。

現在、NAVERクラウドプラットフォームで提供しているCSIバージョンと互換Kubernetesバージョンは以下のとおりです。

Ncloud CSI Driver\Kubernetes Version 1.16+
v1.2.x yes

Kubernetesバージョンでサポートするストレージサービスは以下のとおりです。

Service\Kubernetes Version 1.16
ボリューム生成 支援
ボリューム削除 支援
ボリューム拡張(リサイズ) 支援
サーバへのボリューム割り当て 支援
サーバーにボリューム解除 支援
スナップショット作成 支援
スナップショット削除 支援

NAVERクラウドプラットフォームのブロックストレージは、オフラインボリュームリサイズを提供しています。 ボリュームリサイズのためには、PodのReplica数を0に変更する作業が必要で、場合によってはサービス中断が発生するため、PVC生成時に十分な大きさのボリューム割り当てを推奨します。

割り当て可能な容量

ブロックストレージは、CSIを通じて10GB単位で割り当てることができます。 10GB未満のボリュームサイズを要請した場合、最小サイズの10GBで生成されます。 必要なボリュームサイズを定義しない場合は、デフォルト値の20GBで生成されます。 ブロックストレージの割り当て可能な最小容量と最大容量は以下の通りです。

  • 最小: 10GB
  • 最大: 2000GB

CSI Driver Object

Kubernetesクラスタで永久データ(Persistent data)を読み書きする作業が必要なとき、CSIドライバを利用してブロックストレージをコンテナにマウントできます。 必要なストレージサイズをPersistentVolumeClaim(PVC)で要請することができます。 CSIドライバは、生成されたPVCを確認し、ブロックストレージを生成後、割り当てを要請したコンテナにマウントさせます。

Storage Class

Kubernetesにおける StorageClassは、性能や目的に応じて様々なストレージを抽象化した概念です。 これにより各ストレージに対して任意のポリシーやタイプなどを設定できます。 NAVERクラウドプラットフォームでは、ブロックストレージを使用する基本Storage Classを提供しています。

ネームスペース kube-system 内のStorage Classで nks-block-storageという名前のオブジェクトを確認できます。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: nks-block-storage
  namespace: kube-system
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: blk.csi.ncloud.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
  type: SSD

① Default Storage Classは、annotationの storageclass.kubernetes.io/is-default-class 値を trueに持ちます。 他の値やannotationがない場合は、 falseとして適用されます。

volumeBindingMode 値でボリュームバインディングと動的プロビジョニング(Dynamic Provisioning)がどの時点で動作するかを制御することができます。 定義されていない場合、デフォルト値はImmediateです。

PersistentVolumeClaim通じて、設定に従って必要に応じて PersistentVolumeを自動的に生成することができます。 これを動的プロビジョニング(Dynamic Provisioning)といいます。

Mode Description
Immediate ボリュームバインディングと動的プロビジョニングがPVCが生成される時点で動作します。
WaitForFirstConsumer ボリュームバインディングと動的プロビジョニングがPVCを利用するPodが生成される時点で動作します。

reclaimPolicyを通じて使用済みPVCが削除される際に使用中だったPersistentVolume(PV)に対する再確保(Reclaim)ポリシーを設定することができます。 定義されていない場合、デフォルト値は Deleteです。

Policy Description
Retain PVC が削除されると、使用中の PV は再利用可能な状態に変更されます。 ストレージ内部のデータはそのまま維持されます。
Delete PVC が削除されると、使用中の PV も削除されます。連携していたブロックストレージも返却されます。

動的プロビジョニング(Dynamic Provisioning)によって生成されたブロックストレージが自動的に返却されるのを防ぐため、再確保ポリシーの reclaimPolicyRetainに設定する必要があります。 この場合、 PersistentVolumeClaimが削除されても、ブロックストレージは一緒に返却されず、存在する間は料金が請求されます。 このブロックストレージはコンソールやAPIを通じて手動で返却する必要があります。

allowVolumeExpansion フィールドが trueの場合、PVC(PersistentVolumeClaim)を拡張できます。

⑤ parametersのタイプを通して生成されるブロックストレージのタイプを SSDHDD のうち選択すると使用できます。 定義されていない場合、デフォルト値は SSDです。

Type Description
SSD ストレージタイプで高性能Iに対応するSSDを使用します。 素早いデータ処理が必要な場合に適しています。
HDD ストレージタイプでHDDを使用します。

作成されたStorage Class Objectのdefault storage class 内容を変更するには、次の文書を参照してください。

[Changing the default StorageClass]

CSI Controller

ボリュームの作成、削除、割り当て、割り当ての解除、スナップショットなどのコントロールと管理を担当します。 Namespacekube-system 内のstatefulsetで確認することができます。

$ kubectl --kubeconfig $KUBE_CONFIG get statefulset -n kube-system
NAME                 DESIRED   CURRENT   AGE
csi-nks-controller   1         1         37d

CSI Node

Kubernetesワーカーのノードごとに1つずつ動作しており、ボリュームのフォーマット、マウント、アンマウントなどの動作を担当します。 Namespace kube-system 内のdaemonsetで確認することができます。

$ kubectl --kubeconfig $KUBE_CONFIG get daemonset -n kube-system
NAME           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
csi-nks-node   3         3         3       3            3           <none>                        44d

CSIを利用したブロックストレージ割り当て

PersistentVolumeClaim

必要な PersistentVolume(PV) リソースは PersistentVolumeClaim(PVC)を通じて要請することができます。 CSI Driverは、PVCを確認して必要なPersistentVolume(PV)を自動的に生成します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage

AccessMode

NAVERクラウドプラットフォームのブロックストレージがサポートするAccess Modeは以下のとおりです。

  • ReadWriteOnce: 単一ノードがボリュームの読み込み書き込みを可能にマウントされることがあります。

このほか、アクセスモードで複数のノードによる読み取り専用にマウントする ReadOnlyManyや、複数のノードによる読み取り書き込みモードでマウントするReadWriteManyがあります。 NAVERクラウドプラットフォームのブロックストレージは、これらのAccess Modeに対応していません。

Resources

必要なストレージのサイズを入力します。 入力しない場合、デフォルト値20GBに適用されます。 ストレージサイズは10GB単位で入力でき、最小10GBから最大2000GBの間の値が許容されます。

Podへの単一新規ボリューム割り当て

新しいブロックストレージを1つ生成し、これをボリュームでマウントします。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: csi-pod-pvc

Pod

Podのspec.volumesにコンテナとバインディングされるストレージを定義できます。 配列の要素として入力し、ストレージ名と生成されたPVCの名前をpersistentVolumeClaimclaimNameに入力します。

コンテナで定義されたストレージをマウントできます。spec.containerPersistentVolume必要なコンテナがあれば、volumeMountsに定義されたストレージ名を入力します。 マウントされるパスは mountPathに入力します。

作成済みのブロックストレージをPodにマウント

この方式は、ユーザが PersistentVolumeClaimを生成して必要なストレージボリュームを自動生成する方法ではなく、 すでに生成されたブロックストレージを利用して PersistentVolume(PV)を作る機能です。

作成済みのブロックストレージインスタンスIDを利用して PersistentVolume(PV)を作ります。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: volume-existing-01
  annotations:
    pv.kubernetes.io/provisioned-by: blk.csi.ncloud.com # ブロックストレージと連動するprovisoner名
spec:
  storageClassName: nks-block-storage # ブロックストレージのストレージクラス名
  persistentVolumeReclaimPolicy: Retain
  capacity:
    storage: 10Gi # ブロックストレージサイズ
  accessModes:
    - ReadWriteOnce
  csi:
    driver: blk.csi.ncloud.com
    fsType: ext4
    volumeHandle: "952814" # Block Storage Instance ID
    volumeAttributes:
      blk.csi.ncloud.com/noformat: "true" # ブロックストレージをフォーマットしない
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
  volumeName: "volume-existing-01"
---
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: csi-pod-pvc

PersistentVolume

すでに存在するブロックストレージをKubernetesクラスタで使用するためには、PersistentVolume を作成する際にその情報を入力します。

  • storageClassNameにNAVERクラウドプラットフォームのストレージクラスである nks-block-storageを入力します。
  • capacity.storageにすでに存在するブロックストレージの大きさを入力します。
  • accessModesReadWriteOnceを入力します。 ブロックストレージをサポートするストレージクラスは当該設定のみをサポートします。
  • csidriverにストレージクラスドライバ名の「blk.csi.ncloud.com」を入力します。
  • csivolumeHandleに生成されているブロックストレージのインスタンスIDを入力します。
  • csivolumeAttributesblk.csi.ncloud.com/noformat: "true"を入力します。 この設定は、フォーマットを進行しないという意味であり、既存の内容を維持した状態でマウントします。

PersistentVolumeClaim

生成された PersistentVolume(PV)とバインディングされる PersistentVolumeClaim(PVC)を生成します。

  • resourcesstorageにすでに存在するブロックストレージの大きさを入力します。
  • storageClassNameにブロックストレージクラス名のnks-block-storageを入力します。
  • volumeNameに生成した PersistentVolume(PV)の名前を入力します。

Pod

Pod生成時にボリューム要請である PersistentVolumeClaim(PVC)を指定して使用するボリュームをマウントします。

  • specvolumesの要素として使用する claimNameを入力します

Kubernetesでは、Deployment、Statefulset、DaemonSet、ReplicaSet、Jobなどのコントローラが管理しないPodは、終了しても再び生成されません。 これらのPodがある場合は、 kubectl drain コマンドはこれを保護するために動作しません。kubectl drain コマンドを --force オプションで実行する場合、これらのPodはクラスターから除去されます。

ボリューム割当追加例題

Podに複数のボリュームを割り当て

2つの新規ブロックストレージを生成してPodにマウントします。 作成を要請するボリュームについてそれぞれPersistentVolumeClaimを作成します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-2
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-csi-app
      image: busybox
      volumeMounts:
      - mountPath: "/data/pod-1/"
        name: my-volume-1
      - mountPath: "/data/pod-2/"
        name: my-volume-2
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-volume-1
      persistentVolumeClaim:
        claimName: csi-pod-1
    - name: my-volume-2
      persistentVolumeClaim:
        claimName: csi-pod-2

DeploymentでPersistentVolumeを利用する

PersistentVolumeClaim(PVC)を生成して新規ボリュームの生成を要請します。DeploymenttemplateclaimNameを明示することで、生成されたボリュームをマウントすることができます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-deployment-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-csi-app
spec:
  selector:
    matchLabels:
      app: my-csi-app
  replicas: 1
  template:
    metadata:
      labels:
        app: my-csi-app
    spec:
      containers:
        - name: my-frontend
          image: busybox
          volumeMounts:
          - mountPath: "/data"
            name: my-volume
          command: [ "sleep", "1000000" ]
      volumes:
        - name: my-volume
          persistentVolumeClaim:
            claimName: csi-deployment-pvc

StatefulsetでPersistentVolumeを利用する

Statefulsetでは、 volumeClaimTemplatesを定義し、各 replicaごとに新しい PersistentVolumeClaim(PVC)を自動的に生成することができます。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-csi-app
spec:
  serviceName: my-csi-app
  selector:
    matchLabels:
      app: my-csi-app
  replicas: 1
  template:
    metadata:
      labels:
        app: my-csi-app
    spec:
      containers:
        - name: my-frontend
          image: busybox
          volumeMounts:
          - mountPath: "/data"
            name: my-volume
          command: [ "sleep", "1000000" ]
  volumeClaimTemplates:
    - metadata:
        name: my-volume
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

PersistentVolumeClaim 除去

Kubernetesでは、 PersistentVolumeClaim(PVC)は要求されたDeployment、Stateful Set、Replica Set、Podなどのリソースを削除しても一緒に削除されません。

PersistentVolumeClaim(PVC)削除のためのコマンドは次のとおりです。

# pvc 照会
$ kubectl --kubeconfig $KUBE_CONFIG get pvc
NAME          STATUS   VOLUME                           CAPACITY   ACCESS MODES   STORAGECLASS        AGE
csi-pod-pvc   Bound    pvc-084a811bac4211e9842bf220cd   10Gi       RWO            nks-block-storage   2m8s

# pvc 削除
$ kubectl --kubeconfig $KUBE_CONFIG delete pvc csi-pod-pvc
persistentvolumeclaim "csi-pod-pvc" deleted

CSIを利用したボリュームリサイズ

NAVERクラウドプラットフォームのブロックストレージは、以前に生成されていたボリュームのオフラインリサージング(Offline Resizing)を提供します。

ご注意
ボリュームリサイズは、運用中のPodを制御するControllerでReplicaの数を0に調整することが必要です。 このプロセスは、運営中のアプリの瞬断が発生するので、初期ボリュームを生成する際に十分な大きさで生成することをお勧めします。

① アプリケーション配布

次のように10GiBサイズの新規ブロックストレージボリュームの生成を要請します。

各リソースの名前は次のとおりです。

  • Deployment: my-csi-app
  • PersistentVolumeClaim: csi-deployment-pvc
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-deployment-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-csi-app
spec:
  selector:
    matchLabels:
      app: my-csi-app
  replicas: 1
  template:
    metadata:
      labels:
        app: my-csi-app
    spec:
      containers:
        - name: my-frontend
          image: busybox
          volumeMounts:
          - mountPath: "/data"
            name: my-volume
          command: [ "sleep", "1000000" ]
      volumes:
        - name: my-volume
          persistentVolumeClaim:
            claimName: csi-deployment-pvc

② Replica数を0に調整

生成したDeploymentであるmy-csi-appのReplica数を0に変更します。

$ kubectl --kubeconfig $KUBE_CONFIG scale --replicas=0 deployment/my-csi-app
deployment.apps/my-csi-app scaled

PersistentVolumeClaimのVolume Requestサイズ調整

生成した PersistentVolumeClaimであるcsi-deployment-pvcのリクエストボリュームサイズを10Giから20Giに変更します。

kubectl --kubeconfig $KUBE_CONFIG patch pvc csi-deployment-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'

④ レプリカスワン服

生成した Deploymentであるmy-csi-appのReplica数を従来使っていた値である1に変更します。

$ kubectl --kubeconfig $KUBE_CONFIG scale --replicas=1 deployment/my-csi-app
deployment.apps/my-csi-app scaled

ボリュームリサイズ完了後、PodのSTATUSがRunningに変更されます。

$ kubectl --kubeconfig $KUBE_CONFIG get po
NAME                          READY   STATUS    RESTARTS   AGE
my-csi-app-6dc78bf856-dzrhf   1/1     Running   0          24s

CSIを利用してSnapshot作成及びボリューム復旧

ボリュームSnapshot生成

VolumeSnapshotはCSIで定義したユーザ指定リソース(Custom Resource Definition, CRD)です。 詳細については、下記のリンク先をご参照ください。 [Snapshot-Restore-Feature]

PersistentVolume(PV)バインディングされた PersistentVolumeClaim(PVC)を利用して VolumeSnapshotを生成します。

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  name: csi-nks-test-snapshot # 新規生成されるVolumeSnapShotが使用する名前を入力
spec:
  source:
    name: csi-pod-pvc # Snapshotを生成するPVとバインディングされているPVCの名前を入力
    kind: PersistentVolumeClaim
  • metadatanameに新しく生成されるVolumeSnapShotが使用する名前を入力します。
  • specsource.nameにsnapshotを生成するPVとバインディングされているPVCの名前を入力します。
  • specsource.kindには PersistentVolumeClaimを入力します。

生成されたボリュームsnapshot確認

生成されたボリュームのsnapshotを確認するために、次の kubectl コマンドを利用します。 ボリュームsnapshotのresource名は VolumeSnapShotです。

$ kubectl --kubeconfig $KUBE_CONFIG get volumesnapshot
NAME                    AGE
csi-nks-test-snapshot   17h

生成されたボリュームsnapshot削除

生成されたボリュームのsnapshotを確認するために、次の kubectl コマンドを利用します。 削除するボリュームsnapshotの名前を利用して該当resourceを削除します。

$ kubectl --kubeconfig $KUBE_CONFIG get volumesnapshot
NAME                    AGE
csi-nks-test-snapshot   17h

$ kubectl --kubeconfig $KUBE_CONFIG delete volumesnapshot csi-nks-test-snapshot
volumesnapshot.snapshot.storage.k8s.io "csi-nks-test-snapshot" deleted

生成されたボリュームsnapshotからボリューム復旧

ボリュームsnapshotを利用して新規ボリュームの生成を要請します。 生成されたsnapshotの内容が新規ボリュームで複製されます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-nks-test-pvc-restore
spec:
  dataSource:
    name: csi-nks-test-snapshot # 復旧するボリュームsnapshotの名前
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
  name: csi-restore-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
        - mountPath: "/data"
          name: my-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: csi-nks-test-pvc-restore

PersistentVolumeClaim

ボリュームsnapshotからボリュームを復旧するためには、 spec.dataSourceに対象情報を入力します。

  • dataSource.nameに復旧するボリュームsnapshotの名前を入力します。
  • dataSource.kindに復旧対象のresource名である VolumeSnapshotを入力します。
  • dataSource.apiGroupにsnapshotのapiGroupである snapshot.storage.k8s.ioを入力します。
  • resources.requests.storageにボリュームsnapshotのサイズと同じ値を入力します。

Pod

要請したボリューム情報である PersistentVolumeClaim(PVC)の名前を claimNameに入力します。


問題解決

次節では、CSI が削除されたか、新規の場合にインストールする方法を説明します。

CSI開始(未設置クラスタ用)

この節は、Container Storage Interface(CSI)をKubernetesクラスタにインストールする方法を扱います。 CSIが既にインストールされている場合には、以下の作業を行う必要はありません。

要求事項

  • Kubernetesクラスタのバージョンと互換性のあるCSIドライバ配布
  • 各ワーカーノードのkubeletに --allow-privileged フラグをtrueに設定
  • 各ワーカーノードのkubeletに --feature-gates=VolumeSnapshotDataSource=true 値のフィーチャーゲートフラグを設定

KubernetesクラスタにCSI Driverを配布する

認証のためのトークン獲得

認証トークンの発行を受けるためのページに移動します。

  • APIGateway商品へ移動します。
  • APIGateway商品のPublished APIsを選択します。
  • Product名が Kubernetes Serviceである行を選択します。
  • テーブルの上に有効な Catalog ボタンを押します。
  • token``token行をクリックし、API説明書の下のv1ボタンをクリックします。

トークン発行には認証キーが必要です。 認証キーは、ポータル > マイページ > 認証キー管理 で確認することができます。

  1. トークン発行ページ上段のAuthorizeボタンをクリックします。
  2. ポータルから発行された認証キーを Access Key,Secret Key フィールドに入力します。 API Keyフィールドは空白にしておきます。 入力後、下のAuthorizeボタンをクリックします。 認証キーが入力されていることを確認したら、Done'をクリックします。
  3. 認証キーを入力し、authtokenissue 項目をクリックします。 次の画面でTry it outをクリックします。
  4. 下の"endpoint"のkeyに該当するvalueに、Kubernetes Serviceで駆動中のクラスタのendpointを入力します。 endpoint値は、Kubernetes Serviceのページで駆動中のクラスター項目をクリックすると確認できます。
  5. endpoint 入力後、Executeボタンをします。 作業が成功したら、以下のResponseで発行されたトークンを確認できます。
  6. 発行されたトークンが有効かどうかはauthtokenvalidateの項目で確認することが、

CSI Driver配布

① 発行されたトークンで Secretを作成します。 下の Secret 例題の access-token keyのvalueに発行されたトークンを入力し、secret.ymlという名前で保存します。

apiVersion: v1
kind: Secret
metadata:
  name: nks-access-token
  namespace: kube-system
stringData:
  access-token: "eyJhbGciO__REPLACE_ME____f9hJtQa4rb7A"

保存したファイルと kubectl コマンドで Secretを生成します。

$ kubectl --kubeconfig $KUBE_CONFIG create -f ./secret.yml
secret "nks-access-token" created

Namespace kube-systemに生成された Secertを確認することができます。

$ kubectl --kubeconfig $KUBE_CONFIG get secrets -n kube-system
NAME                  TYPE                                  DATA      AGE
nks-access-token      Opaque                                1         1m

② CSI駆動のための configmap 生成

次のコマンドで、 kube-system namespaceに ncloud-config 名前を持つconfigmapを照会します。

$ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system
NAME            DATA   AGE
ncloud-config   9      131m

$ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: ncloud-config
  namespace: kube-system
data:
  acgNo: "12345"
  apiUrl: https://nks.apigw.ntruss.com
  basePath: /ncloud-api/v1
  lbSubnetNo: "12345"
  regionCode: FKR
  regionNo: "11"
  vpcNo: "12345"
  zoneNo: "110"

上記コマンドの ncloud-config 名前を持つ configmapが照会されていなければ、以下の内容を ncloud-config.yml名前のファイルで作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ncloud-config
  namespace: kube-system
data:
  acgNo: "12345"
  apiUrl: https://nks.apigw.ntruss.com
  basePath: /ncloud-api/v1
  lbSubnetNo: "12345"
  regionCode: FKR
  regionNo: "11"
  vpcNo: "12345"
  zoneNo: "110"
  • data.acgNo: クバネティスワーカーノードのeth0インターフェイスに割り当てられたacgのインスタンスIDを入力します。
  • data.apiUrl: https://nks.apigw.ntruss.comと入力します。
  • data.basePath: /ncloud-api/v1と入力します。
  • data.lbSubnetNo: クバネティスワーカーノードが割り当てられたVPC内のロードバランサ専用サブネットのSubnetIDを入力します。
  • data.regionCode: クバネティスワーカーノードが位置するリージョンコードを入力します。 (例:"FKR")
  • data.regionNo: クバネティス·ワーカーノードのリージョン番号を入力しようとします。 (例:"11")
  • data.vpcNo: クバネティスワーカーノードが割り当てられたVPCのVPC IDを入力します。
  • data.zoneNo: クバネティスワーカーノードが位置するゾーン番号を入力します。 (例:"110")

一部のフィールドは、cloud-controller-managerのための値として使用されます。 下記リンクから関連内容をご確認いただけます。 [cloud controller manager]

入力完了後、 ncloud-config.yml 名前で保存します。 以下のコマンドを入力して、configmapを生成します。

kubectl --kubeconfig $KUBE_CONFIG apply -f ncloud-config.yml

CSIドライバおよびSidecar配布

  1. CSIドライバおよびSidecarを配布します。 運営されているKubernetes Clusterと互換性のあるバージョンのCSIドライバを配布する必要があります。 互換性のあるバージョンの一覧は 制約事項で確認することができます。

k8s 1.16 バージョンで配布

kubernetes 1.16バージョンはCSI v1.2と互換性があります。

$ kubectl --kubeconfig $KUBE_CONFIG apply -f https://nks.apigw.ntruss.com/static/v1/csi/pub/1.2/latest/csi-nks-driver.yaml

これらのファイルは最新の安定バージョンを示しています。 インストール中に問題が生じた場合は、 kubectl apply -f コマンドを再び実行して、抜けていたリソースが再び反映されるようにします。

に対する検索結果は~件です。 ""

    に対する検索結果がありません。 ""

    処理中...