2

私の e2e テストでは、実稼働 TLS 証明書をインポートしたい別のクラスターをスピンアップしています。クラスターが表示されていないように見えるため、2 つのクラスター間でコンテキストを切り替えるのに問題があります (1 つのクラスターからのエクスポート/取得と、別のクラスターへのインポート/適用)。

GitLab CI を使用して MVCE を抽出し、次のよう.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_IIDbeforeステートメントを追加しましたが、結果は変わりません。kubectlerror: no server found for cluster "secret-transfer-1-...-..."

プロジェクトを作成しsecret-transfer、Kubernetes API を有効にして、環境変数で提供している Compute Engine サービス アカウントの JSON キーを取得しました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引数が正しいクラスターを指しているため、動作することを期待しています。

4

2 に答える 2

4

通常gcloud、コマンドはgcloudリソースを管理し、 での認証方法を処理gcloudするために使用されます。コマンドはkubectl、GCP で実行されているか、GKE で作成されているかどうかに関係なく、Kubernetes クラスタとのやり取りに影響を与えます。そのため、次のことは避けます。

$ 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が分離していることのもう 1 つの結果、特にkubectl自分の設定について詳しく知らないということgcloudは、パースペクティブから見たクラスター名がgcloudパースペクティブから見たものと同じではないということkubectlです。のようなことをするときgcloud config set compute/zone、kubectlはそれについて何も知らないので、同じ名前を持っていても別のプロジェクトやゾーンにあり、おそらく GKE (minikube やその他のようなもの) にさえないクラスタを一意に識別できる必要があります。クラウド プロバイダー)。が機能しないのはそのため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設定すると、その特定のファイルに設定されているコンテキストが確実に使用されます。KUBECONFIGkubectlkubectl

于 2019-08-18T22:30:56.410 に答える