-
Notifications
You must be signed in to change notification settings - Fork 321
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
[EKS] [Windows] Invalid Hostname override passed to kube-proxy #273
Comments
Hostname in Start-EKSBootstrap.ps1 script should represent internal private DNS name of your EC2 instance. You can verify that by running Invoke-RestMethod 'http://169.254.169.254/latest/meta-data/local-hostname' . This should return private DNS name (This is what Get-EC2Metadata call returns in Register-KubernetesServices). You shouldn't hardcode the Hostname as above. Let us know if you need additional information. |
I agree, I am not sure where the difference in the host name comes from. The host name returned from the metadata endpoint does not contain the There is an interesting thing though: In the AWS console UI, the private dns does have the correct suffix, but the meta data endpoint does not. I'll look into why that is as well. The VPC does have the dns resolution and hostnames flags set. edit; Could be related to kubernetes/kubernetes#11543, need to dig more |
Interesting. can you run ipconfig /all on this instance and send it to me? |
Couold this be related? #236 |
|
Sorry for the big delay in responding, but I am back on the project now. Seems that having kube-proxy lookup the IP with a different method is a design choice: kubernetes/kubernetes#71851
|
There seems to be an issue with kube-proxy on windows containers receiving the wrong Hostname Override parameter from the bootstrap script. Looking at kube-proxy logs, it fails to lookup the ip (from the kubernetes api) for the node and falls back to 127.0.0.1, causing issues.
From there there are errors creating the proxy endpoints. The nodes do appear to work, until you create a deployment with a service and more then 1 replica. With a single replica, everything works, but adding a second (or more) all pods fail.
I can see what causes the error, and have a patch for my specific cluster configuration, but I am not sure why it is necessary for this cluster vs others not having the issues. One guess - this is an older cluster that has been upgraded from 1.10 all the way to current 1.11
Start-EKSBootstrap.ps1
has a$HostName
variable from calling the metadata endpoint. The value of that, for an example node, isip-10-20-66-170
. That value is then passed as an arg to kubelet and kube-proxy. The issue comes from the nodes actual nameip-10-20-66-170.ec2.internal
.That value is then used by kube-proxy to lookup the IP here. Using
ip-10-20-66-170
returns nil, because that lookup is by name. Usingip-10-20-66-170.ec2.internal
works as expected, returning the correct id.As a quick patch, I added this script block to patch the Bootstrap script to use the "correct" hostname for kube-proxy
I didn't see the repo for the AMI, so I wasn't sure if there was more documentation for the Bootstrap that would help explain some of this.
AMI -
ami-032bdf5292844295a
EKS -
1.11
-eks.2
- Updated from 1.10 to 1.11Kubelet -
v1.11.5
Kube-Proxy -
v1.11.5
aws-node -
amazon-k8s-cni:v1.3.3
Example windows node:
The text was updated successfully, but these errors were encountered: