This message was deleted.

I would assume you are trying to build a Kubeconfig for a GKE cluster?

yea, I found that only the person who created the cluster had the kubeconfig added. so subsequent updates were unable to be performed

What I’ve done before is manually build the Kubeconfig using interpolation, like this:

clusterKubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: ${gke-cluster.masterAuth["clusterCaCertificate"]}
        server: https://${gke-cluster.endpoint}
      name: ${gke-cluster.name}
    contexts:
    - context:
        cluster: ${gke-cluster.name}
        user: ${gke-cluster.name}
      name: ${gke-cluster.name}
    current-context: ${gke-cluster.name}
    kind: Config
    preferences: {}
    users:
    - name: ${gke-cluster.name}
      user:
        exec:
          apiVersion: <http://client.authentication.k8s.io/v1beta1|client.authentication.k8s.io/v1beta1>
          command: gke-gcloud-auth-plugin
          provideClusterInfo: true

Here,

gke-cluster

is the name of the cluster created earlier in the YAML program. This seems to work reasonably well, although I don’t know if it would address your particular use case.

that interpolation is done as the file is written I presume? I couldn't jam that in as is and have the interpolation occur on reads of kubeconfig?

The interpolation happens when the variable is defined, which will happen after all the other resources on which it depends have been created. If you have a situation where you are creating a cluster and then deploying things to that same cluster, then…it should work, but you may have to massage the dependency graph with some explicit dependencies via

dependsOn

. Is that what you’re trying to achieve?

I'll give it a shot. This would be in instances where the cluster was already created, then other folks come in behind and make adjustments to additional k8s components within the cluster

I don’t know any of the details about your use case or anything, but you may also consider splitting the cluster and the things deployed in the cluster into separate stacks, connected by a StackReference. (I also haven’t tried that in YAML, as I generally use Go or TypeScript.) That gives you some additional flexibility in allowing folks to make changes to “additional k8s components within the cluster” while keeping the cluster itself separate. Just something to think about. 🙂

I think an Invoke should run every time, they're not part of the resource lifecycle, but they don't currently have an explicit "depends on", which makes this hard. Something like adding

# {otherResource.id}

to the end of the command string might work (I forget if command.Run is shell based or exec based)