-
Notifications
You must be signed in to change notification settings - Fork 23
document eks managed node groups #363
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
base: main
Are you sure you want to change the base?
Conversation
simonrw
left a comment
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.
Some suggestions and corrections, but otherwise looks good!
| --cluster-name cluster1 \ | ||
| --nodegroup-name nodegroup1 \ | ||
| --node-role arn:aws:iam::000000000000:role/eks-nodegroup-role \ | ||
| --subnets subnet-12345678 \ |
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 probably make sure to set up a proper subnet (that's associated with the VPC) as this is important for the LB controller.
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 was not thinking to mix in documentation for what is required for the controllers. It is true that enforcing valid vpc config is a natural next step in improving eks. I am happy to improve the flow in the docs here.
| awslocal eks create-cluster \ | ||
| --name cluster1 \ | ||
| --role-arn "arn:aws:iam::000000000000:role/eks-role" \ | ||
| --resources-vpc-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.
question: didn't we decide a while back that the user is going to have to provide this information now? Since we thread it through to the instances. Even if we don't require this yet, it's probably worth setting the expectation now.
| } | ||
| ``` | ||
|
|
||
| Once ready you can list the nodes in your cluster using `kubectl`: |
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.
issue: we should wait for the nodegroup to be ready with
aws eks wait nodegroup-active --nodegroup-name nodegroup1There 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.
And perhaps we can run the corresponding command when creating the cluster as well
Co-authored-by: Simon Walker <s.r.walker101@googlemail.com>
Deploying localstack-docs with
|
| Latest commit: |
a9c5fc2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://102e719c.localstack-docs.pages.dev |
| Branch Preview URL: | https://eks-managed-node-groups.localstack-docs.pages.dev |
quetzalliwrites
left a comment
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.
@cloutierMat I made my review/updates. Now you only need to finish addressing Simon's feedback. 😸
|
@simonrw here's ther change I made
The only remaining difference to make the flow identical with aws are to make the subnets public by adding an internet gateway and enabling sunbets auto-assign public IPv4 address (for AWS LB controller). Along with IAM resources. Which I don't think any of those would be relevant to add at this point. |
Adding documentation about eks managed node groups.