-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Moving forward with v5 of EKS Blueprints #1421
Comments
Do you have any ambitions when it comes to migrating from v4 to v5? It seems it will get complicated given the goals 🤔 That said, great initiative! We've been bothered by the same issues you describe and it seems like the correct way forward. Edit: Did not get any direct answer but we can see an |
Any idea how long it will take for v5 to be production ready ? and how long you guys will maintain / patch / update v4 ? |
FAQ for v5When will v5 be GA and ready for production? How long you guys will v4 be maintained and updated? What examples are being moved and where are they going?
|
@bryantbiggs Hi, I have one question about v5. |
This should’ve been communicated more clearly. I just have set up a new cluster using your control plane module. |
@ManuelMueller1st Do you have suggestions on what that might have looked like - how we could have communicated the changes better? |
@bryantbiggs do you have target date for v5? month or quarter? |
A bullet point of major changes to the project on the first README page. Potential Breaking Changes could mean anything. I realized that the cluster module was discontinued after reading the v5 article. |
Thanks! Updated link to Motivation for v5 of EKS Blueprints |
@bryantbiggs I think a markdown doc should be created walking thru migrating a basic v4 cluster with a couple addons updated to v5. This is a very popular tool for deploying eks, a lot of customers will need this information. Im thinking these terraform state modifications will be quite complex. |
excellent! thanks! |
The team is still working on the guidance for migrating addons and teams which is why those doc pages are currently empty |
Starting assumption: most infrastructure people want to abstract the underlying cloud from resources running inside the cluster. Security people want to see the scope Kubernetes permissions being a subset of cloud permissions and want to reduce access to privileged accounts during run time. This means they want to orchestrate the creation of AWS resources outside of the cluster and not make use of something like ACK (AWS Controllers for Kubernetes). So, this generally leads to creating resources in a pipeline using something like Terraform that uses an elevated user at install time. With these assumptions, I don't think that the current motivation clearly outlines the following:
|
@bryantbiggs Is this the migration guide? I started migrating the addons from v4 repo to the new one. ( The eks cluster is already setup the new way, using the eks module ). One add-on ( aws_load_balancer_controller ) I migrated already by deleting it first in the old module and adding it in a second TF apply in the new module:
|
I also happened to have just implemented a new EKS model repository that depended on this module. |
@nmindz we had a notice on the main README for several months It was only recently removed when we unveiled the changes for v5 |
I also began works with that module back in Feb, but I didn't realize the README had changed since then and just today I was trying to figure out the options for the AWS Load Balancer plugin since that was not deployed by default in our internal template. I've been having several mixed search results (such as the missing When I visited the v4 branch just now I realized the notice was there, but has recently been removed from the main branch, which was the one I checked before commenting, so first and foremost please excuse my lack of attention when replying today. I know the addons/plugins guides are still WIP, but are there any pointers/common naming/config schemes already defined for v5 or are they still subject to change? (see snippets below) I got some indications for the
And re-reading @frank-bee's comment I also realized he had a similar config for AWS Load Balancer:
Also, not sure if I clearly understood but according to @fcarta29 FAQ comment, only examples are being moved away from this repository, is that correct? |
in v5, the Terraform modules are removed from this repository and only examples/blueprints will remain. You can see the new home of addons here https://github.com/aws-ia/terraform-aws-eks-blueprints-addons which has its own documentation https://aws-ia.github.io/terraform-aws-eks-blueprints-addons/main/ The new addons are 1.x and stable for use today |
It would be good to get some examples of migration scripts. While the full path of the resources and data in the terraform state of an individual deployment will obviously differ a lot between users individual terraform deployments, overall there will be significant similarity in the paths inside the modules that we need to migrate from v4 to v5 with new external addons/modules. So ideally we should be able to get documentation that outlines what we need to run to migrate the terraform state, otherwise everyone will have to individually work out how they need to perform the dozens of commands like the ones I'll put below and a lot of duplicate work could be saved if this was documented as part of the migration to v5. terraform state mv '"${v4_module_name}"/${example_eks_blueprints_v4_component}/example_resource_one' '"${v5_module_name}"/${example_eks_blueprints_v5_separated_component}/example_resource_one'
terraform state mv '"${v4_module_name}"/${example_eks_blueprints_v4_component}/example_resource_two' '"${v5_module_name}"/${example_eks_blueprints_v5_separated_component}/example_resource_two'
terraform state mv '"${v4_module_name}"/${example_eks_blueprints_v4_component}/example_resource_three' '"${v5_module_name}"/${example_eks_blueprints_v5_separated_component}/example_resource_three'
terraform state mv '"${v4_module_name}"/${example_eks_blueprints_v4_component}/example_submodule/example_subresource_one' '"${v5_module_name}"/${example_eks_blueprints_v5_separated_component}/example_submodule_with_a_new_name/example_subresource_one' The v4 and v5 structures are known and it should be possible to provide some level of assistance to the many users who are currently stuck trying to build a huge list of Edit: (In case someone just says to replace the module and use the documentation to our own settings in the new way to each addon...) |
the changes for v5 are now complete - please see our docs section on v4 to v5 for details on the motivation, context, and migration paths https://aws-ia.github.io/terraform-aws-eks-blueprints/main/v4-to-v5/motivation/ |
@bryantbiggs Does this mean v5 work is 100% complete and ready to use? |
yes, the v5 approach has been available for some time now - we left this open for questions/concerns while updating docs/messaging/etc. |
Community Note
This issue is being created to provide community notice and to help track the work and cutover to v5 of EKS Blueprints. More details of the changes can be found here:
Direction for v5 of EKS BlueprintsMotivation for v5 of EKS Blueprints
The text was updated successfully, but these errors were encountered: