This message was deleted.

cc @breezy-hamburger-69619

Need something like this

const privateSubnetIds = pulumi.output(this.vpc.privateSubnetIds);
    const publicSubnetIds = pulumi.output(this.vpc.publicSubnetIds);
    const subnetIds = pulumi.all([privateSubnetIds, publicSubnetIds]).apply(([publicIds, privateIds]) => {
      return [...publicIds, ...privateIds];
    });

You should look at the Crosswalk for Kubernetes playbooks which are updated: • https://www.pulumi.com/docs/guides/crosswalk/kubernetes/managed-infra/#networking • https://www.pulumi.com/docs/guides/crosswalk/kubernetes/control-plane/#networking

Kind of seems the equivalent example doesn’t exist there haha

We moved towards splitting out public and private subnets rather than concat’ing them given that they tend to be managed independently. Also made for more deterministic placement of the nodes into subnets, rather than guessing which were private vs public as we had it prior

You need to provide all of them to

new  eks.Cluster

though

Correct

It would be great if the examples on this page showed actually creating a cluster from the new VPC like the old examples did

I believe you landed on the Crosswalk for AWS guides which are separate from the Crosswalk for Kubernetes guides which have been updated. The latter has the updated example: https://www.pulumi.com/docs/guides/crosswalk/kubernetes/control-plane/#managed-infrastructure, which links in the opening paragraph to https://www.pulumi.com/docs/guides/crosswalk/kubernetes/managed-infra/

Yeah I mean it’s all there, but it’s a slight mental jump to link the two pieces together potentially.

Understood and thank you for the feedback. We can do better. This may help to understand why we segmented it this way: https://www.pulumi.com/docs/guides/crosswalk/kubernetes/playbooks/

Yeah I think it’s probably good from a wholistic standpoint but if you end up on a page not starting from the beginning its less clear, but I understand the balance is tough

providerCredentialOpts

is a new required opt if bringing in your own provider, as prior the provider was not fully being plumbed through and not being used in the kubectl exec auth command: • https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/eks/index.html#ClusterOptions-providerCredentialOpts • Here’s an updated example: https://github.com/pulumi/pulumi-eks/blob/master/nodejs/eks/examples/aws-profile/index.ts • PR: https://github.com/pulumi/pulumi-eks/pull/367/commits/d06850ed470155779b0e205c7e30e6d8b1708954 • The full list of changes that came into v0.19.0 for p/eks is here: https://github.com/pulumi/pulumi-eks/blob/master/CHANGELOG.md#0190-released-april-20-2020

Ah, thanks!

providerCredentialOpts

is to properly create the kubeconfig per: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html As you can see region does not get used there, and is only for the AWS resources. Since you’re only setting the region and not using credential name profiles or roles, you’re better off using the pulumi config system to set the region using

pulumi config set aws:region <your-region>

Here’s the full scope of

aws

config options in pulumi: https://www.pulumi.com/docs/intro/cloud-providers/aws/#configuration

Yeah, I’m setting the region dynamically here as its a parameter to a module I have written, so I think I’ll just have to do

providerCredentialOpts: {}

, seems to work correctly

Ah, that makes sense. It seems that

providerCrendentialOpts

for your use case isn’t a true requirement. For context, we have no great way in p/eks of knowing how the provider is configured given its variance in configurations (e.g. AWS_PROFILE envvar, an AWS provider instance as you’re using, or using the config setting

aws:profile)

so

providerCrendentialOpts

was primarily aimed at solving the kubeconfig issues to scope it to the options in https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html

Yeah makes sense, not a big deal to just give it the blank map now that I know that’s what I need