投射磁碟區

本文件說明 Kubernetes 中的投射磁碟區。建議您先熟悉磁碟區。

簡介

projected 磁碟區會將多個現有的磁碟區來源對應到同一個目錄中。

目前，可以投射下列類型的磁碟區來源

所有來源都必須與 Pod 位於相同的命名空間中。如需更多詳細資訊，請參閱all-in-one 磁碟區設計文件。

包含密鑰、downwardAPI 與 configMap 的範例組態

pods/storage/projected-secret-downwardapi-configmap.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config

範例組態：具有非預設權限模式的密鑰集

pods/storage/projected-secrets-nondefault-permission-mode.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

每個投射磁碟區來源都會在規格中的 sources 下列出。參數幾乎相同，但有兩個例外

  • 對於密鑰，secretName 欄位已變更為 name，以與 ConfigMap 命名一致。
  • defaultMode 只能在投射層級指定，而不能針對每個磁碟區來源指定。但是，如上所示，您可以明確設定每個個別投射的 mode。

serviceAccountToken 投射磁碟區

您可以將目前服務帳戶的權杖注入 Pod 中指定的路徑。例如

pods/storage/projected-service-account-token.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

範例 Pod 具有一個 projected volume，其中包含注入的服務帳戶權杖。此 Pod 中的容器可以使用該權杖來訪問 Kubernetes API 伺服器，並使用Pod 的 ServiceAccount身分進行身份驗證。audience 欄位包含權杖的預期受眾。權杖的接收者必須使用權杖受眾中指定的識別符來識別自己，否則應拒絕該權杖。此欄位為選填，預設值為 API 伺服器的識別符。

expirationSeconds 是服務帳戶權杖的預期有效期限。預設值為 1 小時，且必須至少為 10 分鐘（600 秒）。管理員也可以透過為 API 伺服器指定 --service-account-max-token-expiration 選項來限制其最大值。path 欄位指定 projected volume 掛載點的相對路徑。

clusterTrustBundle projected volume

功能狀態： Kubernetes v1.29 [alpha]

clusterTrustBundle projected volume 來源會將一或多個 ClusterTrustBundle 物件的內容注入為容器檔案系統中自動更新的檔案。

ClusterTrustBundle 可以透過名稱或簽署者名稱來選取。

若要依名稱選取，請使用 name 欄位來指定單個 ClusterTrustBundle 物件。

若要依簽署者名稱選取，請使用 signerName 欄位（以及選用的 labelSelector 欄位）來指定一組使用給定簽署者名稱的 ClusterTrustBundle 物件。如果 labelSelector 不存在，則會選取該簽署者的所有 ClusterTrustBundle。

kubelet 會對選取的 ClusterTrustBundle 物件中的憑證進行去重複資料刪除、正規化 PEM 表示法（捨棄註解和標頭）、重新排序憑證，並將它們寫入由 path 命名的檔案中。隨著選取的 ClusterTrustBundle 集合或其內容變更，kubelet 會保持檔案為最新狀態。

預設情況下，如果找不到指定的 ClusterTrustBundle，或者 signerName / labelSelector 與任何 ClusterTrustBundle 都不符，kubelet 將阻止 Pod 啟動。如果您不希望這種行為，請將 optional 欄位設定為 true，Pod 將在 path 啟動一個空檔案。

pods/storage/projected-clustertrustbundle.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: sa-ctb-name-test
spec:
  containers:
  - name: container-test
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/root-certificates"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - clusterTrustBundle:
          name: example
          path: example-roots.pem
      - clusterTrustBundle:
          signerName: "example.com/mysigner"
          labelSelector:
            matchLabels:
              version: live
          path: mysigner-roots.pem
          optional: true

SecurityContext 互動

在 projected service account volume 增強功能中，關於檔案權限處理的提案，引入了 projected 檔案具有正確的擁有者權限設定。

Linux

在 Linux Pod 中，若 projected volume 和 Pod SecurityContext 中設定了 RunAsUser，則 projected 檔案會設定正確的擁有權，包括容器使用者擁有權。

當 Pod 中的所有容器在其 PodSecurityContext 或容器 SecurityContext 中設定了相同的 runAsUser 時，kubelet 會確保 serviceAccountToken 卷宗的內容由該使用者擁有，並且權杖檔案的權限模式設定為 0600。

Windows

在 Windows Pod 中，若 projected volume 和 Pod SecurityContext 中設定了 RunAsUsername，則由於 Windows 管理使用者帳戶的方式，因此不會強制執行擁有權。Windows 在名為安全性帳戶管理器 (SAM) 的資料庫檔案中儲存和管理本機使用者和群組帳戶。每個容器都維護自己的 SAM 資料庫執行個體，主機在容器執行時無法查看該執行個體。Windows 容器旨在將作業系統的使用者模式部分與主機隔離執行，因此需要維護虛擬 SAM 資料庫。因此，在主機上執行的 kubelet 無法動態設定虛擬化容器帳戶的主機檔案擁有權。建議如果主機上的檔案要與容器共用，則應將它們放入 C:\ 以外的獨立卷宗掛載中。

預設情況下，projected 檔案將具有以下擁有權，如下例 projected volume 檔案所示

PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List

Path   : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner  : BUILTIN\Administrators
Group  : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)

這表示所有管理員使用者（如 ContainerAdministrator）將具有讀取、寫入和執行權限，而非管理員使用者將具有讀取和執行權限。

上次修改時間：2023 年 10 月 19 日下午 8:21 PST：ClusterTrustBundles：文件 projected volume (6dd3091e55)