logo标签列表

Kubernetes在init容器和容器中使用相同的volumeMount。

kubernetes
7
我正在尝试以非root用户身份挂载卷到其中一个容器中。我正在尝试此 SO帖子的方法，使用initContainer来设置正确的用户，但是当我尝试启动配置时，出现了“unbound immediate PersistentVolumneClaims”错误。 我怀疑这是因为该卷在我的initContainer和container中都被挂载了，但我不确定为什么会出现这个问题：我可以看到initContainer获取了声明，但我原本认为当它退出时，它会释放它，让正常的容器获取声明。有什么想法或其他方法可以将目录挂载为非root用户吗？我确实尝试过使用securityContext / fsGroup，但似乎没有效果。下面的/var/rdf4j目录是作为root挂载的目录。
apiVersion: v1
kind: PersistentVolume
metadata:
  name: triplestore-data-storage-dir
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  storageClassName: local-storage
  volumeMode: Filesystem
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /run/desktop/mnt/host/d/workdir/k8s-data/triplestore
    type: DirectoryOrCreate
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: triplestore-data-storage
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-storage
  volumeName: "triplestore-data-storage-dir"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: triplestore
  labels:
    app: demo
    role: triplestore
spec:
  selector:
    matchLabels:
      app: demo
      role: triplestore
  replicas: 1
  template:
    metadata:
      labels:
        app: demo
        role: triplestore
    spec:
      containers:
        - name: triplestore
          image: eclipse/rdf4j-workbench:amd64-3.5.0
          imagePullPolicy: Always
          ports:
            - name: http
              protocol: TCP
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 200Mi
          volumeMounts:
            - name: storage
              mountPath: /var/rdf4j
      initContainers:
        - name: take-data-dir-ownership
          image: eclipse/rdf4j-workbench:amd64-3.5.0
          command:
            - chown
            - -R
            - 100:65533
            - /var/rdf4j
          volumeMounts:
            - name: storage
              mountPath: /var/rdf4j
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: "triplestore-data-storage"

kubectl get pvc

NAME                       STATUS   VOLUME                         CAPACITY   ACCESS MODES   STORAGECLASS    AGE
triplestore-data-storage   Bound    triplestore-data-storage-dir   10Gi       RWX            local-storage   13s

kubectl get pv

NAME                           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                              STORAGECLASS    REASON   AGE
triplestore-data-storage-dir   10Gi       RWX            Delete           Bound    default/triplestore-data-storage   local-storage            17s

kubectl get events

LAST SEEN   TYPE      REASON              OBJECT                             MESSAGE
21s         Warning   FailedScheduling    pod/triplestore-6d6876f49-2s84c    0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
19s         Normal    Scheduled           pod/triplestore-6d6876f49-2s84c    Successfully assigned default/triplestore-6d6876f49-2s84c to docker-desktop
3s          Normal    Pulled              pod/triplestore-6d6876f49-2s84c    Container image "eclipse/rdf4j-workbench:amd64-3.5.0" already present on machine
3s          Normal    Created             pod/triplestore-6d6876f49-2s84c    Created container take-data-dir-ownership
3s          Normal    Started             pod/triplestore-6d6876f49-2s84c    Started container take-data-dir-ownership
2s          Warning   BackOff             pod/triplestore-6d6876f49-2s84c    Back-off restarting failed container
46m         Normal    Pulled              pod/triplestore-6d6876f49-9n5kt    Container image "eclipse/rdf4j-workbench:amd64-3.5.0" already present on machine
79s         Warning   BackOff             pod/triplestore-6d6876f49-9n5kt    Back-off restarting failed container
21s         Normal    SuccessfulCreate    replicaset/triplestore-6d6876f49   Created pod: triplestore-6d6876f49-2s84c
21s         Normal    ScalingReplicaSet   deployment/triplestore             Scaled up replica set triplestore-6d6876f49 to 1

请描述 pods/triplestore-6d6876f49-tw8r8。

Name:         triplestore-6d6876f49-tw8r8
Namespace:    default
Priority:     0
Node:         docker-desktop/192.168.65.4
Start Time:   Mon, 17 Jan 2022 10:17:20 -0500
Labels:       app=demo
              pod-template-hash=6d6876f49
              role=triplestore
Annotations:  <none>
Status:       Pending
IP:           10.1.2.133
IPs:
  IP:           10.1.2.133
Controlled By:  ReplicaSet/triplestore-6d6876f49
Init Containers:
  take-data-dir-ownership:
    Container ID:  docker://89e7b1e3ae76c30180ee5083624e1bf5f30b55fd95bf1c24422fabe41ae74408
    Image:         eclipse/rdf4j-workbench:amd64-3.5.0
    Image ID:      docker-pullable://registry.com/publicrepos/docker_cache/eclipse/rdf4j-workbench@sha256:14621ad610b0d0269dedd9939ea535348cc6c147f9bd47ba2039488b456118ed
    Port:          <none>
    Host Port:     <none>
    Command:
      chown
      -R
      100:65533
      /var/rdf4j
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 17 Jan 2022 10:22:59 -0500
      Finished:     Mon, 17 Jan 2022 10:22:59 -0500
    Ready:          False
    Restart Count:  6
    Environment:    <none>
    Mounts:
      /var/rdf4j from storage (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-s8wdv (ro)
Containers:
  triplestore:
    Container ID:
    Image:          eclipse/rdf4j-workbench:amd64-3.5.0
    Image ID:
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        100m
      memory:     200Mi
    Environment:  <none>
    Mounts:
      /var/rdf4j from storage (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-s8wdv (ro)
Conditions:
  Type              Status
  Initialized       False
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  storage:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  triplestore-data-storage
    ReadOnly:   false
  kube-api-access-s8wdv:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason            Age                    From               Message
  ----     ------            ----                   ----               -------
  Warning  FailedScheduling  6m24s                  default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Normal   Scheduled         6m13s                  default-scheduler  Successfully assigned default/triplestore-6d6876f49-tw8r8 to docker-desktop
  Normal   Pulled            4m42s (x5 over 6m12s)  kubelet            Container image "eclipse/rdf4j-workbench:amd64-3.5.0" already present on machine
  Normal   Created           4m42s (x5 over 6m12s)  kubelet            Created container take-data-dir-ownership
  Normal   Started           4m42s (x5 over 6m12s)  kubelet            Started container take-data-dir-ownership
  Warning  BackOff           70s (x26 over 6m10s)   kubelet            Back-off restarting failed container

解决方案

问题在于initContainer未以root身份运行，而是以容器的默认用户身份运行，因此没有权限运行chown命令。在链接的SO评论中，这是答案的第一条评论，回复中指出initContainer以root身份运行 - 在较新版本的kubernetes中已经发生了改变。但是有一个解决方案，您可以在容器上设置securityContext以root身份运行，从而允许它有权限运行chown命令，并成功地将卷作为非root用户挂载。下面是initContainer的最终配置。

initContainers:
  - name: take-data-dir-ownership
    image: eclipse/rdf4j-workbench:amd64-3.5.0
    securityContext:
      runAsUser: 0
    command:
      - chown
      - -R
      - 100:65533
      - /var/rdf4j
    volumeMounts:
      - name: storage
        mountPath: /var/rdf4j
“未绑定的即时PersistentVolumeClaim”听起来像是您的PVC没有绑定到卷上。如果您在问题中包含一些诊断信息，将会有所帮助。kubectl get pvc的输出是什么？kubectl get pv呢？kubectl get events显示了什么？ - larsks
增加了一些输出 - pv/pvc 似乎已绑定。 - Matt McMinn
1个回答
3

1个pod有未绑定的立即PersistentVolumeClaims。 - 这个错误意味着pod无法绑定到其被调度运行的节点上的PVC。当PVC绑定到引用在pod所调度运行的节点上无效的位置的PV时，就会发生这种情况。如果您能发布kubectl get nodes -o wide，kubectl describe pvc triplestore-data-storage，kubectl describe pv triplestore-data-storage-dir的完整输出到问题中，将会很有帮助。

同时，使用hostPath时，PVC/PV是可选的。您可以尝试以下规范，看看pod是否能够上线：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: triplestore
  labels:
    app: demo
    role: triplestore
spec:
  selector:
    matchLabels:
      app: demo
      role: triplestore
  replicas: 1
  template:
    metadata:
      labels:
        app: demo
        role: triplestore
    spec:
      containers:
      - name: triplestore
        image: eclipse/rdf4j-workbench:amd64-3.5.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          protocol: TCP
          containerPort: 8080
        resources:
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: storage
          mountPath: /var/rdf4j
      initContainers:
      - name: take-data-dir-ownership
        image: eclipse/rdf4j-workbench:amd64-3.5.0
        imagePullPolicy: IfNotPresent
        securityContext:
          runAsUser: 0
        command:
          - chown
          - -R
          - 100:65533
          - /var/rdf4j
        volumeMounts:
          - name: storage
            mountPath: /var/rdf4j
      volumes:
        - name: storage
          hostPath:
            path: /run/desktop/mnt/host/d/workdir/k8s-data/triplestore
            type: DirectoryOrCreate
我使用这个规范得到了相同的结果，但是在混合中没有PV/PVC描述pod时，实际上显示chown正在运行并返回错误代码。这导致我发现initContainer正在以非root用户身份运行。我已经在问题中添加了一个解决方案，并将其标记为正确答案，因为它导致了答案。谢谢！ - Matt McMinn
请注意，提供的答案将容器“take-data-dir-ownership”作为root运行。您的更新解决方案与答案相同。为什么会看到“initContainer正在以非root用户身份运行”，使用此规范时的“chown”错误代码是什么？ - gohm'c
很奇怪 - 我最初运行时可能是复制/粘贴错误，因为结果是相同的，但我可以看到来自chown的响应代码。不过你说得对，现在你的代码对我有效。 - Matt McMinn
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接