-
Notifications
You must be signed in to change notification settings - Fork 578
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
✨ Add EKS control plane #1724
✨ Add EKS control plane #1724
Conversation
Hi @richardcase. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@richardcase We will be interested in using this functionality soon. Is there anything we can do to help get this merged? |
@dthorsen - i have another PR that i want to get merged first and then i will focis on this and push the additional changes i have made. |
hi @richardcase 👋, any updates for this PR? are there any TODO pieces of this that could perhaps be split into separate issues? we (at New Relic) are looking to start work on the worker node aspect next week and would love to help get this controlplane support merged in any way we can. |
@rudoi - been distracted by something else. Will pick it up again today and try and get it into a place where it can be used. |
/ok-to-test |
config/crd/bases/exp.infrastructure.cluster.x-k8s.io_awsmanagedclusters.yaml
Outdated
Show resolved
Hide resolved
ok, i think we're good to go, can we clean up the commit history (either squashed into one, or 'tell the story'), and then can lgtm. |
This is work in progress to add support for an EKS control plane. Its enabled via a feature flag.
Initialized when cluster creation was started Ready when cluster is active
A small number of changes needed after the rebase and added controller name when creating managed scope so that metrics are reported correctly. Also fixed some linting issues.
This change enables AWSManagedCluster. The api types for AWSManagedCluster and AWSmanagedControlPlane have been updated and their corresponding controllers. Conditions have also been introduced. The managed template has also been updated in light of field changes to AWSmanagedCluster and AWSManagedControlPlane .
A few changes as a result of tesing. Also changed the control plane logging so that the log types are listed.
The AWSManagedCluster has had most of its fields moved to the AWSManagedControlPlane so that the reconciliiation logic is cleaner. This follows the pattern used by CAPZ for the AKS implementation. The controller for AWSManagedCluster just reports back the control plane endpoint, ready and failure domains to CAPI from the managed control plane. In the kubeconfig generation we support both aws-iam-authenticator and also aws cli for generating the auth token. This is available as an option on the AWSManagedControlPlane with the default being to use aws-iam-authenticator. Tags reconcilation has been added so that if the only things that changes is the tags then these changes will be realised in the EKS related resources. The API group name has been changed to remove the `exp` prefix.
The AWSManagedControlPlane has been changed so that the EKS cluster name can be specified as part of the Spec. If its not specified then a defaulting admission webhook will create it. The default name will be created using the follwoing rules: - EKS cluster will be named [namespace]_[name] where namespace is the name namespace of the AWSManagedControlPlane CRD instance and name is the name of the AWSManagedControlPlane CRD instance. - If there are any . in the cluster name then these will be replaced with a _ -If the namespace/name combination is over 100 chars then a name will be created from a hash. Changes to security group service so that it can be reused between managed and unmanaged clusters. Changed the managed control plane so that it reconciles the LB and bastion SG. The automatically created security group for the EKS control plane is looked up and added to the status of the managed control plane. The kubeconfig reconcilation has been changed in 2 ways. The kubeconfig expected by CAPI has been changed to use a token that is based on a presign URL. This token is only valid for a maximum of 15 minutes so on every sync it updates the kubeconfig with a new token and this means we check that the --sync-period isn't above 10 mins if EKS is enabled. We also generate an additional kubeconfig that a use can use that will utilize aws-iam-authenticator or the AWS cli to get the token and this is what the user will need to get to connect to a cluster.
For now, this at least lets `--flavor managed` work. Also remove `kustomization.yaml`s.
A new field called `KubernetesClusterName` has been added to the scopes. For a non-managed (i.e. not EKS) cluster this will return the sample as the Name(). But for a managed cluster (i.e. EKS) this will return the name of the EKS cluster.
Remove patch, add "v" prefix Drop patch from version as a workaround to support `clusterctl config cluster --kubernetes-version X.Y.Z`, which requires a patch version. This includes checking that the version is not decreased Tolerate patch versions in the controller
The EKSClusterName field has been removed from the managed scope and dependent code has been updated to use the new KubernetesClusterName field. Additionally, the load balancer security group has been removed from the control plane reconcilation.
Fixed a couple of typos in the name of an error and the message of an error in the eks package after review.
@randomvariable Cleaned up now to where it "tells the story" pretty well |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: randomvariable The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
Add support for EKS. This is WIP.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1787