K8s (Kubernetes) 学習 (7) - k8s 永続ストレージ: emptyDir、local、nfs、PV&&PVC 静的供給と動的供給、configMap、secret

第 7 章 保管

• ボリュームボリュームとは何ですか
• 一般的に使用されるボリュームの種類
• 使用法
• Persistent Volume と Persistent Volume Claim
• 静的電源
• 動的供給
• 構成マップ
• 秘密

1 ボリュームボリューム

公式 Web サイトのアドレス: https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/

コンテナ内のファイルは一時的にディスクに保存されるため、コンテナ内で実行されているより重要なアプリケーションにいくつかの問題が発生します。問題の 1 つは、コンテナーがクラッシュするとファイルが失われることです。kubelet はコンテナーを再起動しますが、コンテナーはクリーンな状態で再起動されます。2 番目の問題は、Pod同じコンテナ内で複数のコンテナを実行し、ファイルを共有するときに発生します。Kubernetes Volume 这一抽象概念能够解决这两个问题。

2種類のボリューム

Kubernetes は多くの種類のボリュームをサポートしています。ポッドは、任意の数のボリューム タイプを同時に使用できます。一時ボリュームタイプの存続期間はポッドの存続期間と同じですが、永続ボリュームはポッドよりも存続する可能性があります。Kubernetes は、Pod が存在しなくなった場合にも一時ボリュームを破棄しますが、Kubernetes は永続ボリュームを破棄しません。特定のポッド内のどのタイプのボリュームでも、コンテナーの再起動中にデータが失われることはありません。

ボリュームのコアは、データを含む可能性があり、ポッド内のコンテナーからアクセスできるディレクトリです。使用されるさまざまなタイプのボリュームによって、ディレクトリの形成方法、データの保存にどのメディアが使用されるか、ディレクトリに何が保存されるかが決まります。一般的に使用されるボリューム タイプには、configMap、emptyDir、local、nfs、secretなどが含まれます。

• ConfigMap: 構成ファイルはキーと値のペアの形式で ConfigMap に保存でき、Pod でファイルまたは環境変数として使用できます。ConfigMap は、アプリケーション構成ファイルなどの機密性の低い構成情報を保存するために使用できます。
• EmptyDir: ポッドに一時データを保存するために使用できる空のディレクトリです。ポッドが削除されると、ディレクトリも削除されます。
• ローカル: ローカル ファイル システム内のディレクトリまたはファイルをポッド内のボリュームにマップし、ポッド内のファイルまたはデータを共有するために使用できます。
• NFS: ネットワーク上の 1 つ以上の NFS 共有ディレクトリをポッドのボリュームにマウントします。これを使用して、複数のポッド間でデータを共有できます。
• Secret: 機密情報を暗号文の形式で Secret に保存し、Pod 内でファイルまたは環境変数として使用できます。Secret は、ユーザー名、パスワード、証明書などの機密情報を保存するために使用できます。

3 使用方法

ボリュームを使用する場合は、.spec.volumesPodに提供するボリュームをフィールドに設定し、.spec.containers[*].volumeMountsコンテナ内のボリュームの実装位置をフィールドで宣言します。コンテナ内のプロセスによって表示されるファイル システムのビューは、コンテナ イメージの初期コンテンツと、コンテナにマウントされたボリューム (定義されている場合) で構成されます。ルート ファイル システムはコンテナ イメージの内容と一致します。このファイル システムでの書き込み操作は許可されている場合、コンテナー内の後続のプロセスがファイル システムにアクセスするときに表示される内容に影響します。

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      volumeMounts:
     		..........
  volumes:
  	............

一般的な4種類

4.1 空のディレクトリ

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-example
spec:
  containers:
    - name: writer
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello World!' > /data/hello.txt ; sleep 3600"]
      volumeMounts:
        - name: shared-data
          mountPath: /data
    - name: reader
      image: busybox
      command: ["/bin/sh", "-c", "cat /data/hello.txt ; sleep 3600"]
      volumeMounts:
        - name: shared-data
          mountPath: /data
  volumes:
    - name: shared-data
      emptyDir: {
    
    }

总结: emptyDir 是 Host 上创建的临时目录，其优点是能够方便地为 Pod 中的容器提供共享存储，不需要额外的配置。它不具备持久性，如果Pod 不存在了，emptyDir 也就没有了。根据这个特性，emptyDir 特别适合 Pod 中的容器需要临时共享存储空间的场景，比如前面的生产者消费者用例。

4.2 ホストパス

apiVersion: v1
kind: Pod
metadata:
  name: busybox-hostpath
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh", "-c", "echo 'hello' > /data/data.txt && sleep 3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    hostPath:
      path: /data/hostpath

总结: 如果 Pod 被销毀了，hostPath 对应的目录还是会被保留，从这一点来看，hostPath 的持久性比emptyDir 强。不过一旦Host 崩溃，hostPath 也就无法访问了。但是这种方式也带来另外一个问题增加了 pod 与节点的耦合。

4.3 nfs

nfs: ネットワーク ファイルシステム: ネットワーク ファイル ストレージ システム

apiVersion: v1
kind: Pod
metadata:
  name: nfs-test
spec:
  containers:
  - name: busybox
    image: busybox
    command: [ "/bin/sh", "-c", "while true; do sleep 3600; done" ]
    volumeMounts:
    - name: nfs-volume
      mountPath: /mnt/nfs
  volumes:
  - name: nfs-volume
    nfs:
      server: <NFS_SERVER_IP>
      path: /path/to/nfs/share

总结: 相对于 emptyDir 和 hostPath，这种 volume 类型的最大特点就是不依赖 Kuberees Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。当然，运维这样的存储系统通常不是一项简单的工作，特别是对可靠性、可用性和扩展性 有较高要求的时候。

5 PV&PVC

5.1 質問

Volume は非常に優れたデータ永続化ソリューションを提供しますが、管理しやすさにはまだ欠点があります。前の nfs の例では、ボリュームを使用するには、ポッドは次の情報を事前に知っている必要があります。

• 現在のボリュームのタイプと、ボリュームが作成されたことを確認します。
• ボリュームの特定のアドレス情報を知っている必要があります。

ただし、ポッドは通常、アプリケーション開発者によって保守され、ボリュームは通常、ストレージ システム管理者によって保守されます。上記の情報を取得するには、開発者は管理者に問い合わせるか、自分自身が管理者になる必要があります。これは、アプリケーション開発者とシステム管理者の責任が一緒になるという管理上の問題を引き起こします。システム規模が小さい場合や開発環境であればこの状況でも問題ありませんが、特に本番環境などでクラスタサイズが大きくなると、効率やセキュリティを考慮して解決すべき問題となります。

5.2 PV と PVC

Kubernetes が提供する解決策は ですPersistent Volume 和 Persistent Volume Claim。

PersistentVolume (PV) は、管理者によって作成および維持される外部ストレージ システム内のストレージ スペースです。ボリュームと同様に、PV は永続的であり、そのライフサイクルはポッドから独立しています。

Persistent Volume Claim (PVC) は PV に対するクレームです。通常、PVC は一般ユーザーによって作成および保守されます。Podにストレージリソースを割り当てる必要がある場合、ユーザーはPVCを作成し、ストレージリソースの容量やアクセスモード（読み取り専用など）などの情報を指定すると、Kubernetesが条件を満たすPVを検索して提供します。PersistentVolumeClaim を使用すると、ユーザーは実際のスペースが割り当てられる場所やアクセス方法などの基本的な詳細を気にすることなく、必要なストレージ リソースを Kubernetes に伝えるだけで済みます。これらのストレージ プロバイダーの基礎となる情報は管理者に任されており、管理者のみが Persistent Volume の作成の詳細に注意する必要があります。

5.3 基本的な使い方

• PVの作成

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 1Gi #指定容量大小
  accessModes: # 访问模式 
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /{
    
    nfs-server目录名称}
    server: {
    
    nfs-server IP 地址}

• accessModes:サポートされているアクセス モードは 3 つあります。

  • ReadWriteOnce は、PV を読み取り書き込みモードで単一ノードにマウントできることを意味します
    • この PV は、特定のノードによって読み取り/書き込みモードでのみマウントできます。つまり、この PV はポッドによって特定のノードにのみマウントでき、このポッドはこの PV に対して読み取りおよび書き込み操作を実行できます。この PV を他のノードにマウントしようとすると、失敗します。
  • ReadOnlyMany は、PV を読み取り専用モードで複数のノードにマウントできることを意味します。
    • この PV は複数のノードによって読み取り専用モードでマウントできます。つまり、この PV は複数のポッドによって複数のノードにマウントできます。
  • ReadWriteMany は、PV を読み取り/書き込みモードで複数のノードにマウントできることを意味します。
    • この PV は、読み取り/書き込みモードで複数のノードによってマウントできます。つまり、この PV は複数のノード上の複数のポッドによってマウントできます。

• persistentVolumeReclaimPolicy: PV のリサイクル ポリシーが 3 つの戦略をサポートすることを指定します。

  • 保持: PVC が削除された後、PV とそのデータを保持し、PV 内のデータを手動でクリーンアップします。

  • 削除: PVC が削除された後、PV とそのデータが自動的に削除されます。

  • リサイクル: PVC を削除した後、PV 内のデータを削除して PV を再利用できるように準備します。

    值得注意的是，永続的なボリューム再利用ポリシー 只适用于一些类型的 PV，如 NFS、HostPath、iSCSI 等。对于一些云平台提供的存储，如 AWS EBS 和 Azure Disk，由于底层提供商会自动处理 PV 的回收问题，因此该属性不适用。

• storageClassName: PV クラスを nfs として指定します。これは PV のカテゴリを設定することに相当し、PVC は該当クラスの PV に適用するクラスを指定できます。

• PVCの作成

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs # 通过名字进行选择
  #selector:  通过标签形式
  #  matchLabels:
  #    pv-name: nfs-pv

• PVCを使用

apiVersion: v1
kind: Pod
metadata:
  name: busybox-nfs
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo 'Hello NFS!' >> /data/index.html; sleep 1; done"]
    volumeMounts:
    - name: nfs-volume
      mountPath: /data
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: nfs-pvc

5.4 動的供給

前の例では、PV を事前に作成し、PVC 経由で PV を申請し、Pod で使用しました。この方法は静的プロビジョニング (Static Provision) と呼ばれ、これに相当するのが動的プロビジョニング (Dynamical Provision) です。つまり、要件が満たされていない場合、PVC 条件の PV が動的に作成されます。静的プロビジョニングと比較して、動的プロビジョニングには明らかな利点があります。事前に PV を作成する必要がないため、管理者
の作業負荷が軽減され、効率が高くなります。動的プロビジョニングは、StorageClass を通じて実装されます。StorageClass は PV の作成方法を定義しますが、各 StorageClass には、PV を準備するためにどのボリューム プラグインを使用するかを決定するために使用されるプリペアラー (プロビジョナー) があることに注意してください。このフィールドは必ず指定する必要があります。(https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/) を使用して動的作成を実現します。例として NFS を見てみましょう。

• NFSプロバイダーの定義

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nfs-client-provisioner
    labels:
      app: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: kube-system
  spec:
    replicas: 1
    strategy:
      type: Recreate
    selector:
      matchLabels:
        app: nfs-client-provisioner
    template:
      metadata:
        labels:
          app: nfs-client-provisioner
      spec:
        serviceAccountName: nfs-client-provisioner
        containers:
          - name: nfs-client-provisioner
            image: chronolaw/nfs-subdir-external-provisioner:v4.0.2
            volumeMounts:
              - name: nfs-client-root
                mountPath: /persistentvolumes
            env:
              - name: PROVISIONER_NAME
                value: k8s-sigs.io/nfs-subdir-external-provisioner
              - name: NFS_SERVER
                value: 10.15.0.25
              - name: NFS_PATH
                value: /root/nfs/data
        volumes:
          - name: nfs-client-root
            nfs:
              server: 10.15.0.25
              path: /root/nfs/data
  

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: kube-system
  ---
  kind: ClusterRole
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: nfs-client-provisioner-runner
  rules:
    - apiGroups: [""]
      resources: ["nodes"]
      verbs: ["get", "list", "watch"]
    - apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
    - apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
    - apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
    - apiGroups: [""]
      resources: ["events"]
      verbs: ["create", "update", "patch"]
  ---
  kind: ClusterRoleBinding
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: run-nfs-client-provisioner
  subjects:
    - kind: ServiceAccount
      name: nfs-client-provisioner
      # replace with namespace where provisioner is deployed
      namespace: kube-system
  roleRef:
    kind: ClusterRole
    name: nfs-client-provisioner-runner
    apiGroup: rbac.authorization.k8s.io
  ---
  kind: Role
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: leader-locking-nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: kube-system
  rules:
    - apiGroups: [""]
      resources: ["endpoints"]
      verbs: ["get", "list", "watch", "create", "update", "patch"]
  ---
  kind: RoleBinding
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: leader-locking-nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: kube-system
  subjects:
    - kind: ServiceAccount
      name: nfs-client-provisioner
      # replace with namespace where provisioner is deployed
      namespace: kube-system
  roleRef:
    kind: Role
    name: leader-locking-nfs-client-provisioner
    apiGroup: rbac.authorization.k8s.io
  

• ストレージクラスの定義

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: mysql-nfs-sc
  provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
  parameters:
    onDelete: "remain"
  

• StorageClass を使用して動的に作成する

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: mysql
    labels:
      app: mysql
  spec:
    serviceName: mysql #headless 无头服务  保证网络标识符唯一  必须存在
    replicas: 1
    template:
      metadata:
        name: mysql
        labels:
          app: mysql
      spec:
        containers:
          - name: mysql
            image: mysql/mysql-server:8.0
            imagePullPolicy: IfNotPresent
            env:
              - name: MYSQL_ROOT_PASSWORD
                value: root
            volumeMounts:
              - mountPath: /var/lib/mysql #自己容器写入数据目录
                name: data    #保存到指定一个变量中 变量名字就是 data
            ports:
              - containerPort: 3306
        restartPolicy: Always
    volumeClaimTemplates:  #声明动态创建数据卷模板
      - metadata:
          name: data      # 数据卷变量名称
        spec:
          accessModes:    # 访问模式
            - ReadWriteMany
          storageClassName: mysql-nfs-sc # 使用哪个 storage class 模板存储数据
          resources:
            requests:
              storage: 2G
    selector:
      matchLabels:
        app: mysql
  

6 構成マップ

6.1 はじめに

Kubernetes では、ConfigMap は非機密情報を保存するために使用される Kubernetes オブジェクトです。これは、キーと値のペア、構成ファイル全体、または JSON データなどの構成データを保存するために使用されます。ConfigMap は通常、コンテナー イメージ内の構成ファイル、コマンド ライン パラメーター、環境変数などに使用されます。

ConfigMap は、次の 3 つの方法で構成データを挿入できます。

1. 環境変数の注入: Pod 内のコンテナ環境変数に構成データを注入します。
2. 設定ファイルの挿入: 設定データをポッドのコンテナ ファイル システムに挿入すると、コンテナはこれらのファイルを読み取ることができます。
3. コマンド ライン パラメーターの挿入: 構成データをコンテナーのコマンド ライン パラメーターに挿入します。

6.2 利点

1. ハードコーディングを避け、構成データをアプリケーションコードから分離します。
2. 保守と更新が簡単で、ConfigMap はイメージを再構築せずに個別に変更できます。
3. 構成データはさまざまな方法で挿入できるため、より柔軟になります。
4. ConfigMap は、Kubernetes の自動化メカニズムを通じてバージョン管理およびロールバックできます。
5. ConfigMap は複数の Pod で共有できるため、構成データの重複ストレージが削減されます。

6.3 ConfigMap の定義

• 基本操作

  # 查看 configmap
  $ kubectl get configmap/cm  
  
  # 查看详细
  $ kubectl describe configmap/cm my-config
  
  # 删除 cm
  $ kubectl delete cm my-config
  

• コマンドラインの作成:

  • kubectl create configmapコマンドを使用して configmap を作成できます。具体的なコマンドは次のとおりです。

  • $ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
    

• 設定ファイル経由で作成:推奨

  • configmap の内容は、YAML ファイルを作成することで定義できます。たとえば、my-config次のような名前の構成マップを作成します。

  • apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-config
    data:
      key1: value1
      key2: value2
    

  • apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config
    data:
      application.yml: |
        name: xiaochen
    

  • 次に、kubectl apply -fコマンドを使用して構成マップを作成します。

• ファイルから作成:

  • $ echo -n admin >./username
    $ echo -n 123456 > ./password
    $ kubectl create configmap myconfigmap --from-file=./username --from-file=./password
    

• フォルダーから作成:

  • 複数の構成ファイルを同じフォルダーに配置し、kubectl create configmapコマンドを使用して構成マップを作成できます。次に例を示します。

  • $ kubectl create configmap my-config --from-file=config-files/
    

  • これにより、フォルダー内のすべてのファイルの内容をキーと値のペアとしてmy-config含む configmapという名前の構成マップが作成されます。config-files/

• 環境変数を介して作成:

  • 環境変数の値は configmap に変換できます。たとえば、次のコマンドを使用して、現在の環境変数の値を configmap に変換します。

  • $ kubectl create configmap my-config --from-env-file=<(env)
    

6.4 使用方法

• 環境変数で使用される

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: busybox
    command: ["/bin/sh", "-c", "echo $BUSY_NAME ; sleep 3600;"]
    env:
    # name: 是容器需要环境变量名称
    - name: BUSY_NAME
    # valueForm: value 来源与什么
      valueFrom:
        configMapKeyRef:  # 值来源与 configmap  来源与哪个 configmap 来源与哪个 configmap 中 key
          name: app-cm
          key: name
    # 一次性注入这个 configmap
    envFrom:
    - configMapRef:
        name: my-config

注意: env 是指定 configmap 中某个 key 进行注入 envForm 将 configmap 中内容全部注入

• ボリューム経由の構成の使用

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: myapp-container
      image: busybox
      command: ["/bin/sh","-c","sleep 3600"]
      volumeMounts:
        - name: data-volume
          mountPath: /data
  volumes:
    - name: data-volume
      configMap:
        name: application-cm

7 秘密

7.1 シークレットの概要

Kubernetes では、Secret は、パスワード、API キー、証明書などの機密情報を保存および管理するために使用されるオブジェクト タイプです。これらは ConfigMap に似ていますが、機密情報を扱う場合、シークレットはより優れたセキュリティと機密性を提供します。

シークレットを使用すると、この機密情報をコンテナーに挿入し、実行時にこの情報が誤って漏洩したり他人に公開されたりしないようにすることができます。シークレットは、直接定義、ファイルからのロード、環境変数からのロードなど、さまざまな方法で定義および使用できます。

Kubernetes では、シークレットは通常、次のシナリオで使用されます。

• 証明書やキーなどの機密ファイルを保存するボリュームとしてポッドにマウントされます。
• ポッドで環境変数を使用してユーザー名やパスワードなどの機密情報を保存する
• Docker イメージ リポジトリのログイン情報を保存するために使用されます。
• 外部サービスを保存するための API キー

シークレットは、ボリュームと環境変数を介してポッドの仕様で参照できます。コンテナーがボリュームを使用してシークレットを参照する場合、シークレットはファイルの形式でコンテナーにマウントされます。コンテナーが環境変数を使用して Secret を参照する場合、Secret 内のデータは Base64 でエンコードされ、キーと値のペアの形式でコンテナーの環境変数に挿入されます。

需要注意的是，Secret 并不提供强大的安全保证，只是简单地将数据存储在 base64 编码的形式下，并不提供加密或其他安全措施，因此不要将高度敏感的信息存储在 Secret 中。在处理高度敏感的信息时，需要使用更高级别的保护机制，如使用加密数据的 Volume 类型，或者使用第三方加密解决方案等。

7.2 シークレットの定義

• コマンドラインを使用して作成します。

  • kubectl create secret コマンドを使用してシークレットを作成できます。次に例を示します。

  • $ kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=admin123
    

• YAML ファイル定義を使用します。

  • YAML ファイルを作成して Secret オブジェクトを定義できます。次に例を示します。

  • apiVersion: v1
    kind: Secret
    metadata:
      name: my-secret
    type: Opaque
    data:
      username: YWRtaW4= # base64 编码后的用户名 admin
      password: MWYyZDFlMmU2N2Rm # base64 编码后的密码 1f2d1e2e67df
    

  • 注意: 这个 YAML 文件定义了一个名为 my-secret 的 Secret 对象，其中包含了两个 base64 编码后的 key-value 对：username 和 password。

• ファイルを使用して作成します:

  • $ echo -n admin >./username
    $ echo -n 123456 > ./password
    $ kubectl create secret generic mysecret --from-file=./username --from-file=./password
    

• 環境変数を介して作成:

  • 環境変数の値はシークレットに変換できます。たとえば、次のコマンドを使用して、現在の環境変数の値をシークレットに変換します。

  • $ kubectl create secret generic  my-config --from-env-file=<(env)
    

7.3 シークレットの使用

• 環境変数、コマンドラインパラメータはSecretを使用します

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: myapp-container
      image: busybox
      command: ["/bin/sh","-c","sleep 3600"]
      env:
        - name: USERNAME
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: username
        - name: PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password
      # 一次性注入这个 secret
      envFrom:
        - secretRef:
        	  name: my-secret
  restartPolicy: Never

• ボリュームの使用

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: myapp-container
      image: busybox
      command: ["/bin/sh","-c","sleep 3600"]
      volumeMounts:
        - name: secret-volume
          mountPath: /data
  volumes:
    - name: secret-volume
      secret:
        secretName: aaa