В контейнере отказано в разрешении Kubernetes

Question

Моя компания купила программное обеспечение, которое мы пытаемся развернуть в облаке IBM, используя кубернеты и предоставив частный репозиторий docker. После развертывания всегда возникает ошибка Kubernetes: «Отказ от перезапуска неудачного контейнера». Я читал журналы, чтобы понять, почему контейнер перезагружается, и вот ошибка:

Caused by: java.io.FileNotFoundException: /var/yseop-log/yseop-manager.log (Permission denied)

Итак, я пришел к выводу, что мне просто нужно было изменить разрешения в файле Kubernetes. Поскольку я использую развертывание, я попробовал следующий initContainer:

initContainers:
    - name: permission-fix
      image: busybox
      command: ['sh', '-c']
      args: ['chmod -R 777 /var']
      volumeMounts:
        - mountPath: /var/yseop-engine
          name: yseop-data
        - mountPath: /var/yseop-data/yseop-manager
          name: yseop-data
        - mountPath: /var/yseop-log
          name: yseop-data

Это не сработало, потому что мне не разрешено выполнять chmod в папках, доступных только для чтения, как пользователь, не имеющий root.

Итак, я попытался перемонтировать эти тома, но это тоже не удалось, потому что я не являюсь пользователем root.

Затем я узнал о работе в качестве пользователя и группы. Чтобы узнать, какого пользователя и группу я должен был написать в моем контексте безопасности, я прочитал файл докеров, и вот пользователь и группа:

 USER 1001:0

Итак, я подумал, что могу просто написать это в моем развертывании file:

  securityContext: 
      runAsUser: 1001  
      rusAsGroup: 0

Очевидно, это тоже не сработало, потому что мне не разрешено работать как группа 0

Так что я до сих пор не знаю, что делать, чтобы правильно развернуть этот образ. Образ работает при выполнении docker pull и exe c на компьютере m, но он не работает в Kubernetes.

Вот мой полный файл тома:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    ibm.io/auto-create-bucket: "true"
    ibm.io/auto-delete-bucket: "false"
    ibm.io/bucket: ""
    ibm.io/secret-name: "cos-write-access"
    ibm.io/endpoint: https://s3.eu-de.cloud-object-storage.appdomain.cloud
  name: yseop-pvc
  namespace: ns
  labels:
    app: yseop-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: ibmc
  volumeMode: Filesystem 

И вот мой файл полного развертывания:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: yseop-manager
  namespace: ns
spec:
  selector:
    matchLabels:
      app: yseop-manager
  template:
    metadata:
      labels:
        app: yseop-manager
    spec:
      securityContext: 
          runAsUser: 1001  
          rusAsGroup: 0
      initContainers:
        - name: permission-fix
          image: busybox
          command: ['sh', '-c']
          args: ['chmod -R 777 /var']
          volumeMounts:
            - mountPath: /var/yseop-engine
              name: yseop-data
            - mountPath: /var/yseop-data/yseop-manager
              name: yseop-data
            - mountPath: /var/yseop-log
              name: yseop-data
      containers:
        - name: yseop-manager
          image:IMAGE
          imagePullPolicy: IfNotPresent
          env:
            - name: SECURITY_USERS_DEFAULT_ENABLED
              value: "true"
          ports:
            - containerPort: 8080
          volumeMounts:
            - mountPath: /var/yseop-engine
              name: yseop-data
            - mountPath: /var/yseop-data/yseop-manager
              name: yseop-data
            - mountPath: /var/yseop-log
              name: yseop-data
      imagePullSecrets:
        - name: regcred
      volumes:
        - name: yseop-data
          persistentVolumeClaim:
            claimName: yseop-pvc

Спасибо за помощь

Answer 1

Не могли бы вы попробовать включить дополнительный идентификатор группы в контекст безопасности, например

SecurityContext:
   runAsUser: 1001  
   fsGroup: 2000

По умолчанию runAsGroup равен 0, что равно root. Ссылка ниже может дать больше информации об этом. https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Рабочее содержание Yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: yseop-manager
  namespace: ns
spec:
  selector:
    matchLabels:
      app: yseop-manager
  template:
    metadata:
      labels:
        app: yseop-manager
    spec:
      securityContext: 
          fsGroup: 2000 
      initContainers:
        - name: permission-fix
          image: busybox
          command: ['sh', '-c']
          args: ['chown -R root:2000 /var']
          volumeMounts:
            - mountPath: /var/yseop-engine
              name: yseop-data
            - mountPath: /var/yseop-data/yseop-manager
              name: yseop-data
            - mountPath: /var/yseop-log
              name: yseop-data
      containers:
        - name: yseop-manager
          image:IMAGE
          imagePullPolicy: IfNotPresent
          securityContext:
             runAsUser: 1001
             runAsGroup: 2000
          env:
            - name: SECURITY_USERS_DEFAULT_ENABLED
              value: "true"
          ports:
            - containerPort: 8080
          volumeMounts:
            - mountPath: /var/yseop-engine
              name: yseop-data
            - mountPath: /var/yseop-data/yseop-manager
              name: yseop-data
            - mountPath: /var/yseop-log
              name: yseop-data
      imagePullSecrets:
        - name: regcred
      volumes:
        - name: yseop-data
          persistentVolumeClaim:
            claimName: yseop-pvc

Answer 2

Моя компания не сообщила мне, что у нас есть ограничивающие политики безопасности Pod. Из-за этого тома доступны только для чтения, и я не могу написать что-либо в этих томах.

Решение следующее:

      volumes:
    - name: yseop-data
      emptyDir: {}

Затем я должен указать путь в volumeMounts (что уже было сделано) и создайте PV C, чтобы мои данные были постоянными.