Как запустить kubectl в задании в пространстве имен?

Question

Привет, я видел эту документацию , где kubectl может работать внутри модуля в модуле по умолчанию. Можно ли запустить kubectl внутри ресурса Job в указанном пространстве имен? Не видел никакой документации или примеров для того же самого.

Когда я попытался добавить serviceAccounts в контейнер, я получил ошибку:

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:my-namespace:internal-kubectl" cannot list resource "pods" in API group "" in the namespace "my-namespace"

Это было, когда я пытался sshing в контейнер и запуск kubctl.

Редактирование вопроса .....

Как я уже упоминал ранее, на основе документации, которую я добавил, службы Accounts, ниже приводится yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: internal-kubectl  
  namespace: my-namespace   
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: modify-pods
  namespace: my-namespace
rules:
  - apiGroups: [""]
    resources:
      - pods
    verbs:
      - get
      - list
      - delete      
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: modify-pods-to-sa
  namespace: my-namespace
subjects:
  - kind: ServiceAccount
    name: internal-kubectl
roleRef:
  kind: Role
  name: modify-pods
  apiGroup: rbac.authorization.k8s.io      
---
apiVersion: batch/v1
kind: Job
metadata:
  name: testing-stuff
  namespace: my-namespace
spec:
  template:
    metadata:
      name: testing-stuff
    spec:
      serviceAccountName: internal-kubectl
      containers:
      - name: tester
        image: bitnami/kubectl
        command:
         - "bin/bash"
         - "-c"
         - "kubectl get pods"
      restartPolicy: Never 

При запуске задания выдается ошибка:

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:my-namespace:internal-kubectl" cannot list resource "pods" in API group "" in the namespace "my-namespace"

Answer 1

Можно ли запустить kubectl внутри ресурса Job в указанном пространстве имен? Не видел никакой документации или примеров для того же самого.

A Job создает один или несколько модулей и гарантирует, что указанное количество из них успешно завершится , Это означает, что аспект прав доступа такой же, как в обычном модуле, то есть да, можно запустить kubectl внутри ресурса задания.

TL; DR:

• Ваш файл yaml правильный , возможно, в вашем кластере было что-то еще, я рекомендую удалить и воссоздать эти ресурсы и попробовать еще раз.
• Также проверьте версия вашей установки Kubernetes и версия kubectl образа работы, если они отличаются более чем одной минорной версией, у вас могут быть неожиданные несовместимости

---

Безопасность Соображения:

• Область вашей рабочей роли является наилучшей практикой в ​​соответствии с документацией (указана c роль, для указания c пользователя на указанное c пространство имен ).
• Если вы используете ClusterRoleBinding с ролью cluster-admin, он будет работать, но он слишком разрешен и не рекомендуется, поскольку дает полный административный контроль над всем кластером.

---

Тест Среда:

• Я развернул вашу конфигурацию на kubernetes 1.17.3 и запустил задание с bitnami/kubectl и bitnami/kubectl:1:17.3. Это работало в обоих случаях.
• Чтобы избежать несовместимости, используйте kubectl с соответствующей версией с вашим сервером.

---

Воспроизведение:

$ cat job-kubectl.yaml 
apiVersion: batch/v1
kind: Job
metadata:
  name: testing-stuff
  namespace: my-namespace
spec:
  template:
    metadata:
      name: testing-stuff
    spec:
      serviceAccountName: internal-kubectl
      containers:
      - name: tester
        image: bitnami/kubectl:1.17.3
        command:
         - "bin/bash"
         - "-c"
         - "kubectl get pods -n my-namespace"
      restartPolicy: Never 

$ cat job-svc-account.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: internal-kubectl  
  namespace: my-namespace   
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: modify-pods
  namespace: my-namespace
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "delete"]      
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: modify-pods-to-sa
  namespace: my-namespace
subjects:
  - kind: ServiceAccount
    name: internal-kubectl
roleRef:
  kind: Role
  name: modify-pods
  apiGroup: rbac.authorization.k8s.io

• Я создал два модуля для добавления вывода в журнал get pods.

$ kubectl run curl --image=radial/busyboxplus:curl -i --tty --namespace my-namespace
the pod is running
$ kubectl run ubuntu --generator=run-pod/v1 --image=ubuntu -n my-namespace
pod/ubuntu created

• Затем я применяю job , ServiceAccount, Role и RoleBinding

$ kubectl get pods -n my-namespace
NAME                    READY   STATUS      RESTARTS   AGE
curl-69c656fd45-l5x2s   1/1     Running     1          88s
testing-stuff-ddpvf     0/1     Completed   0          13s
ubuntu                  0/1     Completed   3          63s

• Теперь давайте проверим журнал модуля тестирования, чтобы убедиться, что он записал вывод команды:

$ kubectl logs testing-stuff-ddpvf -n my-namespace
NAME                    READY   STATUS    RESTARTS   AGE
curl-69c656fd45-l5x2s   1/1     Running   1          76s
testing-stuff-ddpvf     1/1     Running   0          1s
ubuntu                  1/1     Running   3          51s

Как видите, успешно выполнено задание с пользовательской настройкой ServiceAccount.

Сообщите мне, если у вас есть дополнительные вопросы по этому делу.

Answer 2

Когда вы используете kubectl из модуля pod для любой операции, такой как получение модуля или создание ролей и привязок ролей, он будет использовать учетную запись службы по умолчанию. Эта учетная запись службы не имеет разрешения на выполнение этих операций по умолчанию. Поэтому вам нужно

1. создать учетную запись службы, роль и привязку роли с использованием более привилегированной учетной записи. У вас должен быть файл kubeconfig с привилегией администратора или привилегией администратора. Используйте этот файл kubeconfig с kubectl извне модуля для создания учетной записи службы, роли, привязки роли и т. Д. c.

2. После того, как это будет сделано, создайте модуль, указав эту учетную запись службы, и вы сможете выполнять операции, определенные в роли, из этого модуля, используя kubectl и учетную запись службы.

---

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: internal-kubectl

Answer 3

Создайте учетную запись службы следующим образом.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: internal-kubectl

Создайте ClusterRoleBinding, используя это.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: modify-pods-to-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: internal-kubectl

Теперь создайте модуль с той же конфигурацией, которая указана в Документации.