-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use EKS Addon to manage kube-proxy
and coredns
#1357
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. |
2c099ee
to
286d86f
Compare
@@ -39,6 +39,9 @@ const cluster2 = new eks.Cluster(`${projectName}-2`, { | |||
const cluster3 = new eks.Cluster(`${projectName}-3`, { | |||
vpcId: vpc.vpcId, | |||
publicSubnetIds: vpc.publicSubnetIds, | |||
corednsAddonOptions: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to add this to the migration guide.
nodejs/eks/cluster.ts
Outdated
@@ -627,6 +624,74 @@ export function createCore( | |||
}, | |||
); | |||
|
|||
pulumi.output(args.fargate).apply((fargate) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about lifting the addons out of the apply and always creating them?
If fargate is enabled we set the compute type config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
nodejs/eks/cluster.ts
Outdated
args.kubeProxyAddonOptions?.resolveConflictsOnCreate ?? "OVERWRITE", | ||
resolveConflictsOnUpdate: | ||
args.kubeProxyAddonOptions?.resolveConflictsOnUpdate ?? "OVERWRITE", | ||
addonVersion: kubeProxyVersion, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should set the preserve
property to true
. Otherwise this would delete the resources from the cluster when users toggle the enabled
setting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also set the tags
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That brings up a question - Is enabled a thing that only works on initial deployment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The addons can be created/deleted at any time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
@@ -1798,6 +1812,108 @@ func generateSchema() schema.PackageSpec { | |||
Required: []string{"content", "contentType"}, | |||
}, | |||
}, | |||
"eks:index:ResolveConflictsOnUpdate": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
}, | ||
}, | ||
}, | ||
"eks:index:CoreDnsAddonOptions": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add the serviceAccountRoleArn
prop as well.
I'm also wondering if we should allow users to pass configuration values and then merge those with the ones the provider sets.
Modifying the resource requests/limits or replica count of coredns is a common config for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we can exclude that from this PR here. I've added it to the VPC CNI and if we both start adding those settings we're just gonna step on each others toes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add the serviceAccountRoleArn prop as well.
I don't think either coredns
or kube-proxy
use a role. At least according to this doc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nice! Didn't know that
@@ -663,6 +663,20 @@ func generateSchema() schema.PackageSpec { | |||
Description: "The authentication mode of the cluster. Valid values are `CONFIG_MAP`, `API` or `API_AND_CONFIG_MAP`.\n\n" + | |||
"See for more details:\nhttps://docs.aws.amazon.com/eks/latest/userguide/grant-k8s-access.html#set-cam", | |||
}, | |||
"corednsAddonOptions": { | |||
TypeSpec: schema.TypeSpec{ | |||
Plain: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need Plain: true? I think what it does is make it slightly less nice for the user but supposedly easier for the implementation. Wanted to make sure it's an informed decision here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is actually nicer for the user. Otherwise previews wouldn't be accurate because this decides whether a resource is created or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, unsolved problem of conditional creates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it make it less nice for the user? I thought you use plain when it doesn't need to accept output values. Is that not the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally if I'm a user, I want to be able to call resources by passing Output<X>
values directly. If I have plain values, great, I can lift them to outputs. If I have however computed Output values, and the resource does not accept them, I'm really stuck and I can only provision inside an apply which defeats plans. So generally Plain: true is bad for users. However the fact that this property is used for conditional resource creation inside is a good reason for having Plain: true.
ObjectTypeSpec: schema.ObjectTypeSpec{ | ||
Type: "object", | ||
Properties: map[string]schema.PropertySpec{ | ||
"enabled": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Go design would be disabled
with default: false, so missing and false are the same. But perhaps we intentionally prefer the extra "enabled: true" marker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those resources are deployed by default on EKS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most people will be using it in TypeScript 😀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking Go has good style in here :) But deferring to y'all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just had a look through other settings in the provider and more are called enable...
then disable...
. Many of those are rooted in AWS settings, so I'd vote for enabled
here to stay more consistent with what the provider is already doing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah if this is what AWS users expect it's perfect.
) | ||
.apply((addonVersion) => addonVersion.version); | ||
|
||
const kubeProxyAddon = new aws.eks.Addon( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conditional resource, interesting. Good thing args.kubeProxyAddonOptions?.enabled are not outputty and cannot be unknown.
}); | ||
} | ||
return undefined; | ||
}) as any, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: disabling type-checking via any here avoids some pain perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any
is gonna get removed here when we expose the configurationValues
. That's a follow up item.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The referenced issue is pulumi/pulumi#6175
fs.writeFileSync(tmpKubeconfig.fd, JSON.stringify(kconfig)); | ||
|
||
// Determine if the CoreDNS deployment has a computeType annotation. | ||
const cmdGetAnnos = `kubectl get deployment coredns -n kube-system -o jsonpath='{.spec.template.metadata.annotations}'`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice removal.
Left some nits but looking very healthy overall! Reviewing at the low-level mostly. Trusting this is the right default we want: "creating an eks.Cluster will now also create the coredns and kube-proxy addons" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Now that the EKS addons are added we need to align them and do some cleanup. This involves: - adding the enums introduced in #1357 to the VPC CNI - exposing configurationValues for coredns and kube-proxy - removing kubectl from the provider - deeply sort addon configuration keys to guarantee stable json serialization - remove deepmerge again. It caused issues during unit tests (voodoocreation/ts-deepmerge#22) and when used on outputs. Additionally I discovered and fixed an old bug that luckily never surfaced. The VPC CNI configuration did incorrectly handle outputs and called `toString` on them in a couple of places. The increased type safety and tests around addon configuration uncovered this. Closes #1369
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes <!--Give us a brief description of what you've done and what it solves. --> This PR switches the `coredns` and `kube-proxy` addons from self-managed to managed. By default the latest compatible version will be used. This also introduces two new top level arguments to `ClusterOptions` for configuring these new addons. - `corednsAddonOptions` - `kubeProxyAddonOptions` BREAKING CHANGE: creating an `eks.Cluster` will now also create the `coredns` and `kube-proxy` addons. If you are currently already managing these you will need to disable the creation of these through the new arguments `ClusterOptions.corednsAddonOptions.enabled = false` and `ClusterOptions.kubeProxyAddonOptions.enabled = false` ### Related issues (optional) closes #1261, closes #1254
Now that the EKS addons are added we need to align them and do some cleanup. This involves: - adding the enums introduced in #1357 to the VPC CNI - exposing configurationValues for coredns and kube-proxy - removing kubectl from the provider - deeply sort addon configuration keys to guarantee stable json serialization - remove deepmerge again. It caused issues during unit tests (voodoocreation/ts-deepmerge#22) and when used on outputs. Additionally I discovered and fixed an old bug that luckily never surfaced. The VPC CNI configuration did incorrectly handle outputs and called `toString` on them in a couple of places. The increased type safety and tests around addon configuration uncovered this. Closes #1369
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes <!--Give us a brief description of what you've done and what it solves. --> This PR switches the `coredns` and `kube-proxy` addons from self-managed to managed. By default the latest compatible version will be used. This also introduces two new top level arguments to `ClusterOptions` for configuring these new addons. - `corednsAddonOptions` - `kubeProxyAddonOptions` BREAKING CHANGE: creating an `eks.Cluster` will now also create the `coredns` and `kube-proxy` addons. If you are currently already managing these you will need to disable the creation of these through the new arguments `ClusterOptions.corednsAddonOptions.enabled = false` and `ClusterOptions.kubeProxyAddonOptions.enabled = false` ### Related issues (optional) closes #1261, closes #1254
Now that the EKS addons are added we need to align them and do some cleanup. This involves: - adding the enums introduced in #1357 to the VPC CNI - exposing configurationValues for coredns and kube-proxy - removing kubectl from the provider - deeply sort addon configuration keys to guarantee stable json serialization - remove deepmerge again. It caused issues during unit tests (voodoocreation/ts-deepmerge#22) and when used on outputs. Additionally I discovered and fixed an old bug that luckily never surfaced. The VPC CNI configuration did incorrectly handle outputs and called `toString` on them in a couple of places. The increased type safety and tests around addon configuration uncovered this. Closes #1369
Proposed changes
This PR switches the
coredns
andkube-proxy
addons from self-managed to managed. By default the latest compatible version will be used.This also introduces two new top level arguments to
ClusterOptions
for configuring these new addons.corednsAddonOptions
kubeProxyAddonOptions
BREAKING CHANGE: creating an
eks.Cluster
will now also create thecoredns
andkube-proxy
addons. If you are currently already managing these you will need to disable the creation of these through the new argumentsClusterOptions.corednsAddonOptions.enabled = false
andClusterOptions.kubeProxyAddonOptions.enabled = false
Related issues (optional)
closes #1261, closes #1254