Для моих тестов e2e я запускаю отдельный кластер, в который я хотел бы импортировать свой производственный сертификат TLS. У меня проблемы с переключением контекста между двумя кластерами (экспорт / получение из одного и импорт / применение (в) к другому), потому что кластер, кажется, не виден.

Я извлек MVCE, используя Cit GitLab и следующие .gitlab-ci.yml, где я создаю секрет для демонстрационных целей:

stages:
  - main
  - tear-down

main:
  image: google/cloud-sdk
  stage: main
  script:
    - echo "$GOOGLE_KEY" > key.json
    - gcloud config set project secret-transfer
    - gcloud auth activate-service-account --key-file key.json --project secret-transfer
    - gcloud config set compute/zone us-central1-a
    - gcloud container clusters create secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID --project secret-transfer --machine-type=f1-micro
    - kubectl create secret generic secret-1 --from-literal=key=value
    - gcloud container clusters create secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID --project secret-transfer --machine-type=f1-micro
    - gcloud config set container/use_client_certificate True
    - gcloud config set container/cluster secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID
    - kubectl get secret letsencrypt-prod --cluster=secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID -o yaml > secret-1.yml
    - gcloud config set container/cluster secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID
    - kubectl apply --cluster=secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID -f secret-1.yml

tear-down:
  image: google/cloud-sdk
  stage: tear-down
  when: always
  script:
    - echo "$GOOGLE_KEY" > key.json
    - gcloud config set project secret-transfer
    - gcloud auth activate-service-account --key-file key.json
    - gcloud config set compute/zone us-central1-a
    - gcloud container clusters delete --quiet secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID
    - gcloud container clusters delete --quiet secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID

Я добавил secret-transfer-[1/2]-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID перед kubectl инструкциями, чтобы избежать error: no server found for cluster "secret-transfer-1-...-...", но это не меняет результат.

Я создал проект secret-transfer, активировал API Kubernetes и получил ключ JSON для учетной записи службы Compute Engine, которую я предоставляю в переменной среды GOOGLE_KEY. Выход после проверки

$ echo "$GOOGLE_KEY" > key.json

$ gcloud config set project secret-transfer
Updated property [core/project].

$ gcloud auth activate-service-account --key-file key.json --project secret-transfer
Activated service account credentials for: [131478687181-compute@developer.gserviceaccount.com]

$ gcloud config set compute/zone us-central1-a
Updated property [compute/zone].

$ gcloud container clusters create secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID --project secret-transfer --machine-type=f1-micro
WARNING: In June 2019, node auto-upgrade will be enabled by default for newly created clusters and node pools. To disable it, use the `--no-enable-autoupgrade` flag.
WARNING: Starting in 1.12, new clusters will have basic authentication disabled by default. Basic authentication can be enabled (or disabled) manually using the `--[no-]enable-basic-auth` flag.
WARNING: Starting in 1.12, new clusters will not have a client certificate issued. You can manually enable (or disable) the issuance of the client certificate using the `--[no-]issue-client-certificate` flag.
WARNING: Currently VPC-native is not the default mode during cluster creation. In the future, this will become the default mode and can be disabled using `--no-enable-ip-alias` flag. Use `--[no-]enable-ip-alias` flag to suppress this warning.
WARNING: Starting in 1.12, default node pools in new clusters will have their legacy Compute Engine instance metadata endpoints disabled by default. To create a cluster with legacy instance metadata endpoints disabled in the default node pool, run `clusters create` with the flag `--metadata disable-legacy-endpoints=true`.
WARNING: Your Pod address range (`--cluster-ipv4-cidr`) can accommodate at most 1008 node(s). 
This will enable the autorepair feature for nodes. Please see https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more information on node autorepairs.
Creating cluster secret-transfer-1-9b219ea8-9 in us-central1-a...
...done.
Created [https://container.googleapis.com/v1/projects/secret-transfer/zones/us-central1-a/clusters/secret-transfer-1-9b219ea8-9].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-a/secret-transfer-1-9b219ea8-9?project=secret-transfer
kubeconfig entry generated for secret-transfer-1-9b219ea8-9.
NAME                          LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE  NODE_VERSION   NUM_NODES  STATUS
secret-transfer-1-9b219ea8-9  us-central1-a  1.12.8-gke.10   34.68.118.165  f1-micro      1.12.8-gke.10  3          RUNNING

$ kubectl create secret generic secret-1 --from-literal=key=value
secret/secret-1 created

$ gcloud container clusters create secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID --project secret-transfer --machine-type=f1-micro
WARNING: In June 2019, node auto-upgrade will be enabled by default for newly created clusters and node pools. To disable it, use the `--no-enable-autoupgrade` flag.
WARNING: Starting in 1.12, new clusters will have basic authentication disabled by default. Basic authentication can be enabled (or disabled) manually using the `--[no-]enable-basic-auth` flag.
WARNING: Starting in 1.12, new clusters will not have a client certificate issued. You can manually enable (or disable) the issuance of the client certificate using the `--[no-]issue-client-certificate` flag.
WARNING: Currently VPC-native is not the default mode during cluster creation. In the future, this will become the default mode and can be disabled using `--no-enable-ip-alias` flag. Use `--[no-]enable-ip-alias` flag to suppress this warning.
WARNING: Starting in 1.12, default node pools in new clusters will have their legacy Compute Engine instance metadata endpoints disabled by default. To create a cluster with legacy instance metadata endpoints disabled in the default node pool, run `clusters create` with the flag `--metadata disable-legacy-endpoints=true`.
WARNING: Your Pod address range (`--cluster-ipv4-cidr`) can accommodate at most 1008 node(s). 
This will enable the autorepair feature for nodes. Please see https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more information on node autorepairs.
Creating cluster secret-transfer-2-9b219ea8-9 in us-central1-a...
...done.
Created [https://container.googleapis.com/v1/projects/secret-transfer/zones/us-central1-a/clusters/secret-transfer-2-9b219ea8-9].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-a/secret-transfer-2-9b219ea8-9?project=secret-transfer
kubeconfig entry generated for secret-transfer-2-9b219ea8-9.
NAME                          LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE  NODE_VERSION   NUM_NODES  STATUS
secret-transfer-2-9b219ea8-9  us-central1-a  1.12.8-gke.10   104.198.37.21  f1-micro      1.12.8-gke.10  3          RUNNING

$ gcloud config set container/use_client_certificate True
Updated property [container/use_client_certificate].

$ gcloud config set container/cluster secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID
Updated property [container/cluster].

$ kubectl get secret secret-1 --cluster=secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID -o yaml > secret-1.yml
error: no server found for cluster "secret-transfer-1-9b219ea8-9"

Я ожидаю, что kubectl get secret будет работать, потому что оба кластера существуют, а аргумент --cluster указывает на правый кластер.

kubernetes google-kubernetes-engine gcloud kubernetes-secrets
2
Kalle Richter 19 Авг 2019 в 00:11

2 ответа

Лучший ответ

Как правило, команды gcloud используются для управления gcloud ресурсами и управления тем, как вы проходите аутентификацию с помощью gcloud, тогда как команды kubectl влияют на то, как вы взаимодействуете с кластерами Kubernetes, независимо от того, происходят ли они с быть запущенным на GCP и / или созданным в GKE. Поэтому я бы не стал делать:

$ gcloud config set container/use_client_certificate True
Updated property [container/use_client_certificate].

$ gcloud config set container/cluster \
  secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID
Updated property [container/cluster].

Он не делает то, о чем вы, вероятно, думаете (а именно, что-либо изменяет, как kubectl нацеливается на кластеры), и может помешать работе будущих команд gcloud.

Еще одно следствие того, что gcloud и kubectl отделены друг от друга, и, в частности, kubectl не знает о ваших настройках gcloud, заключается в том, что имя кластера с точки зрения gcloud не так, как с точки зрения kubectl. Когда вы делаете что-то вроде gcloud config set compute/zone, kubectl ничего об этом не знает, поэтому он должен иметь возможность однозначно идентифицировать кластеры, которые могут иметь одинаковые имена, но находиться в разных проектах и зонах, и, возможно, даже в GKE (например, в миникубе или другом облачном провайдере). Вот почему kubectl --cluster=<gke-cluster-name> <some_command> не будет работать, и именно поэтому вы видите сообщение об ошибке:

error: no server found for cluster "secret-transfer-1-9b219ea8-9"

Как отметил @coderanger имя кластера, которое генерируется в вашем файле ~/.kube/config после выполнения gcloud container clusters create ..., имеет более сложное имя, которое в настоящее время имеет шаблон, похожий на gke_[project]_[region]_[name].

Таким образом, вы могли бы запускать команды с kubectl --cluster gke_[project]_[region]_[name] ... (или kubectl --context [project]_[region]_[name] ..., что было бы более идиоматично, хотя в этом случае сработает и то и другое, поскольку вы используете одну и ту же учетную запись службы для обоих кластеров), однако для этого требуется знание того, как gcloud генерирует эти строки для имен контекста и кластера.

Альтернативой было бы сделать что-то вроде:

$ KUBECONFIG=~/.kube/config1 gcloud container clusters create \
  secret-transfer-1-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID \
  --project secret-transfer --machine-type=f1-micro

$ KUBECONFIG=~/.kube/config1 kubectl create secret secret-1 --from-literal=key=value

$ KUBECONFIG=~/.kube/config2 gcloud container clusters create \
  secret-transfer-2-$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_IID \
  --project secret-transfer --machine-type=f1-micro

$ KUBECONFIG=~/.kube/config1 kubectl get secret secret-1 -o yaml > secret-1.yml

$ KUBECONFIG=~/.kube/config2 kubectl apply -f secret-1.yml

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

3
Amit Kumar Gupta 18 Авг 2019 в 22:30

Вы, вероятно, хотите использовать --context, а не --cluster. Контекст устанавливает использование кластера и пользователя. Кроме того, имена контекста и кластера (и пользователя), создаваемые GKE, - это не просто идентификатор кластера, это gke_[project]_[region]_[name].

0
coderanger 18 Авг 2019 в 21:44

Похожие вопросы

1 Узлы кластера контейнерного движка Google не готовы после работы
3 Программный запуск команд Kubernetes в новом кластере GKE
2 Ошибка аутентификации kubectl oauth2 с контейнерным движком
2 Не удается подключиться к кластеру контейнеров: переменная среды HOME или KUBECONFIG должна быть установлена ​​при запуске gcloud получить учетные данные
2 Kubernetes о секретах и о том, как их использовать в подах
1 GKE с использованием gcePersistentDisk
1 «сбой создания кластеров контейнеров gcloud» с ошибкой разрешения «container.clusters.create»
2 Kubernetes секреты шифрования
1 Аутентификация в Kubernetes API кластера GKE в рамках облачной функции Google
1 Как получить доступ к секретам хранилища из другого кластера Kubernetes, когда хранилище развернуто в выделенном кластере?
2 PERMISSION_DENIED: Недостаточная квота проекта для удовлетворения запроса: ресурс
1 Как узнать, есть ли в кластере gke автоматическое обновление
1 Как включить Kubernetes API в GCP? здесь не разобрались, следуя документу
2 Просматривайте секреты из менеджера секретов gcloud напрямую как secretGenerator с помощью kustomize.
1 использовать секрет кубернетов в другом
1 Как пройти аутентификацию в google-cloud-sdk, используя учетную запись пользователя в неинтерактивном режиме
2 Могу ли я получить секрет k8s и использовать его за пределами кластера?
1 Как создать секрет в кластере k8s из контейнера пода?
1 Использование пароля базы данных, хранящегося в Google Secrets Manager, из модуля, работающего в кластере GKE
1 Доступ к секретам в секретном менеджере GCP из POD
1 k8s Использовать секрет из другого пространства имен
💵 Получи $100 на хостинг на 60 дней.
Регистрируйся!

Новые вопросы

1 Являются ли пространства имен объектами всего кластера?
1 Доступ к API Kubelet от оператора k8s
1 Сохранение шаблонов Apache NiFi в Kubernetes с постоянными томами
1 Как найти пароль администратора кластера песочницы OpenShift?
3 Невозможно запустить оболочку внутри модуля k8s
1 я хочу удалить старое развертывание и сервис из кода конвейера в Дженкинсе
2 Шаблон Helm: индекс для подразделов
1 Многопроцессорность в Python работает локально, но работает только один раз в модуле
1 Я установил конвейер kubeflow, но в пользовательском интерфейсе нет ноутбука Jupyter.
1 Не удалось развернуть Ingress Nginx с помощью Helm
Все вопросы по теме kubernetes >

kubernetes

ВОПРОСЫ КУБЕРНЕТА ДОЛЖНЫ БЫТЬ ОТНОШЕНЫ К РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. Настройка и развертывание здесь не по теме. Хорошее эмпирическое правило: если это происходит за пределами группы, это, вероятно, не по теме. Если речь идет о коде, работающем внутри модуля, то, вероятно, все в порядке.

Подробнее про kubernetes...