-
Notifications
You must be signed in to change notification settings - Fork 87
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
Enable logs/exec for EKS 1.19+ #120
Comments
fixed by #139 |
This is more complicated than I thought.
aws/containers-roadmap#1604 (comment) We must use that signer because this is the only one trusted by the API server when it calls logs/exec endpoints. Currently, Admiralty creates and self-approves a CSR for the Admiralty controller-manager/agent pod IP, and the Node object representing each target specifies that IP as their address. The pod exposes logs/exec endpoints at port 10250, the default kubelet port. Here's a trick I thought of: we could expose those endpoints with hostPort at a port different than the default (because the default is already taken by the kubelet of the node hosting the Admiralty pod), change the virtual node objects to use the Admiralty pod's hosting node IP as their address ( Let's first confirm whether the EKS control plane would sign such a CSR... cc @fakeburst |
@adrienjt I'll try this approach in my environment |
Any update on this? I am trying to get an eks cluster version 1.29 and seeing the pod logs/exec error in the controller logs.
I am running the Admiralty helm chart version 0.16.0. Thank you |
EKS stopped signing node server certs with the certificates.k8s.io/v1beta1 API, but would sign them with the v1? (Other distributions,e.g., AKS and GKE, continue to sign node server certs with the certificates.k8s.io/v1beta1 API until 1.21 included, so EKS's behavior is surprising.)
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.19
The text was updated successfully, but these errors were encountered: