Как использовать kubectl из CronJob в GKE?

Question

Я развернул CronJob в кластере GKE для периодической репликации секретов в пространствах имен (для cert-manager), но всегда получаю следующую ошибку:

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Вот мое развертывание:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: certificate-replicator-cron-job
  namespace: default
spec:
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: default
            release: default
        spec:
          automountServiceAccountToken: false
          containers:
          - command:
            - /bin/bash
            - -c
            - for i in $(kubectl get ns -o json |jq -r ".items[].metadata.name" |grep
              "^bf-"); do kubectl get secret -o json --namespace default dev.botfront.cloud-staging-tls
              --export |jq 'del(.metadata.namespace)' |kubectl apply -n ${i}-f -;  done
            image: bitnami/kubectl:latest
            name: certificate-replicator-container
          restartPolicy: OnFailure
          serviceAccountName: sa-certificate-replicator
  schedule: '* * * * *'

Я также настроил роль для учетной записи службы:

$ kubectl describe role certificate-replicator-role                                                                                                                                 
Name:         certificate-replicator-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources   Non-Resource URLs  Resource Names  Verbs
  ---------   -----------------  --------------  -----
  secrets     []                 []              [list create get]
  namespaces  []                 []              [list get]

$ kubectl describe rolebinding certificate-replicator-role-binding                                                                                                                  git:(master|✚4…
Name:         certificate-replicator-role-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  certificate-replicator-role
Subjects:
  Kind            Name                       Namespace
  ----            ----                       ---------
  ServiceAccount  sa-certificate-replicator  default

$ kubectl describe serviceaccount sa-certificate-replicator                                                                                                                         git:(master|✚4…
Name:                sa-certificate-replicator
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   sa-certificate-replicator-token-ljsfb
Tokens:              sa-certificate-replicator-token-ljsfb
Events:              <none>

Я понимаю, что, возможно, мог бы создать другой образ Docker с предустановленной gcloud и выполнить аутентификацию с помощьюключ учетной записи службы, но я бы хотел быть независимым от облачного провайдера, а также избегать необходимости аутентификации в кластере, поскольку kubectl вызывается изнутри.

Возможно ли это?

Answer 1

Gcloud требует, чтобы вы каким-то образом проходили аутентификацию. Я использовал файл .json для проверки подлинности учетной записи службы облака Google каждый раз, когда мне хотелось запустить kubectl удаленно. Однако это довольно грязное решение.

Вместо этого я бы рекомендовал использовать kubernetes api для достижения вашей цели. Создайте роль, которая позволит вам работать с пространствами имен и ресурсами configmaps. Свяжите его с учетной записью службы, а затем сделайте завитки, чтобы сделать копию изнутри cronjob.

Вот пример для пространства имен по умолчанию.

Сначала создайте роль и свяжите ее с учетной записью службы (по умолчанию в этом примере).

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nssc-clusterrole
  namespace: default
rules:
- apiGroups: [""]
  resources: ["namespaces", "configmaps", "secrets"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nssc-clusterrolebinding
  namespace: default
roleRef:
  name: nssc-clusterrole
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
subjects:
  - name: default
    namespace: default
    kind: ServiceAccount

Во-вторых,создайте секрет для проверки.

---
apiVersion: v1
kind: Secret
metadata:
  name: secrets-test
  namespace: default
type: Opaque
stringData:
  mysecret1: abc123
  mysecret2: def456

В-третьих, сделайте запрос завитка, чтобы получить ваш секрет.

curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernet
es.io/serviceaccount/token)" -H "Accept: application/json"  https://kubernetes.default.svc/api/v1/namespaces/default/secrets/sec
rets-test

Вы получите json с содержимым вашего секрета.

{
  "kind": "Secret",
  "apiVersion": "v1",
  "metadata": {
    "name": "secrets-test",
    "namespace": "default",
    "selfLink": "/api/v1/namespaces/default/secrets/secrets-test",
    "uid": "...",
    "resourceVersion": "...",
    "creationTimestamp": "2019-10-26T01:52:29Z",
    "annotations": {
      "kubectl.kubernetes.io/last-applied-configuration": "{...}\n"
    }
  },
  "data": {
    "mysecret1": "base64value",
    "mysecret2": "base64value"
  },
  "type": "Opaque"
}

В-четвертых, создайте секрет в новом пространстве имен, изменив json и сделав новый запрос curl. Также свяжите учетную запись службы с ролью.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nssc-clusterrolebinding
  namespace: new-namespace
roleRef:
  name: nssc-handler-clusterrole
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
subjects:
  - name: default
    namespace: default
    kind: ServiceAccount

{
    "apiVersion": "v1",
    "data": {
        "mysecret1": "Y29udHJvbDEyMyE=",
        "mysecret2": "Y29udHJvbDQ1NiE="
    },
    "kind": "Secret",
    "metadata": {
        "name": "secrets-test",
        "namespace": "new-namespace"
    },
    "type": "Opaque"
}

curl -X POST -d @test.json --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /va
r/run/secrets/kubernetes.io/serviceaccount/token)" -H "Accept: application/json" -H "Content-Type: application/json" https://kub
ernetes.default.svc/api/v1/namespaces/new-namespace/secrets