For more context, see the original Kubernetes bug report: kubernetes/kubernetes#40850
What version of Go are you using (go version)?
2a8c81f (1.7 minus approximately 250 commits)
What operating system and processor architecture are you using (go env)?
The kubernetes apiserver is running in a container. uname -a in the container reports Linux {hostname} 4.9.7-101.fc24.x86_64 #1 SMP Thu Feb 2 23:32:31 UTC 2017 x86_64 GNU/Linux
What did you do? / What did you expect to see? / What did you see instead?
The setup requires a bit of explanation. I'm running a Kubernetes cluster with TLS enabled with an HAProxy LB in front of it on a separate node with a floating IP attached to it.
When trying to contact the kube-apiserver using curl -vv -k https://{floating IP}:{k8s api port}, it hangs at the client hello:
* Rebuilt URL to: https://172.24.4.2:10443/
* Hostname was NOT found in DNS cache
* Trying 172.24.4.2...
* Connected to 172.24.4.2 (172.24.4.2) port 10443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1): # it sits here forever
Only this specific combination exhibits the problem. That is:
- making a request to the floating IP from the outside...
- when the FIP is attached to the LB node...
- with an apiserver built on 2a8c81f or newer listening on the other side
Things that, interestingly, do work (all done separately):
- Swapping out the apiserver for
openssl s_server allows full two-way communication
- Using an apiserver built on Go before 2a8c81f
- Making a request to etcd (non-TLS) on the same node (different port, but through the same LB, FIP, etc)
- Sending requests to the LB's floating IP from the api node
- Sending requests to the private IP of the api node from the LB node (bypassing the LB and the FIP)
- Attaching the floating IP directly to the api node (bypassing the LB) and making requests to it (works from the outside too in this case)
I am hoping that by submitting this report here, I can gain some additional insight into what the problem could be, especially because I have pinned 2a8c81f as the breaking commit.
P.S. If anyone has or could whip up a simple Go program that only listens on a port and establishes a TLS connection (two versions; at 2a8c81f and the commit before it), I could fully eliminate kubernetes from the equation. I'll try to work on it myself, but I haven't written a line of Go in my life. It would be super helpful!
HAProxy config:
(HA-Proxy version 1.5.14 2015/07/02)
global
daemon
user nobody
group nogroup
log /dev/log local0
log /dev/log local1 notice
stats socket /var/lib/octavia/7619d633-7114-4077-80fe-df8a7c9ec343.sock mode 0666 level user
defaults
log global
retries 3
option redispatch
timeout connect 5000
timeout client 50000
timeout server 50000
frontend 7619d633-7114-4077-80fe-df8a7c9ec343
option tcplog
bind 10.0.0.8:10443
mode tcp
default_backend cbfdf089-ca1c-4274-936a-592d4409b30a
backend cbfdf089-ca1c-4274-936a-592d4409b30a
mode tcp
balance roundrobin
timeout check 5
server 2d0e02a2-f638-4585-8868-36eb491fbcfb 10.0.0.15:10443 weight 1 check inter 5s fall 3 rise 5
Some HAProxy logs (more at https://gist.github.com/dragorosson/9843b863e77b316ea4128f0ee1661c73):
Mar 15 15:45:16 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38562 [15/Mar/2017:15:44:26.580] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0
Mar 15 15:46:07 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38652 [15/Mar/2017:15:45:17.584] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:46:58 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38744 [15/Mar/2017:15:46:08.589] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0
Mar 15 15:47:49 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38838 [15/Mar/2017:15:46:59.594] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:48:40 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38926 [15/Mar/2017:15:47:50.598] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:49:31 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:39018 [15/Mar/2017:15:48:41.602] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:50:22 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:39112 [15/Mar/2017:15:49:32.606] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0
For more context, see the original Kubernetes bug report: kubernetes/kubernetes#40850
What version of Go are you using (
go version)?2a8c81f (1.7 minus approximately 250 commits)
What operating system and processor architecture are you using (
go env)?The kubernetes apiserver is running in a container.
uname -ain the container reportsLinux {hostname} 4.9.7-101.fc24.x86_64 #1 SMP Thu Feb 2 23:32:31 UTC 2017 x86_64 GNU/LinuxWhat did you do? / What did you expect to see? / What did you see instead?
The setup requires a bit of explanation. I'm running a Kubernetes cluster with TLS enabled with an HAProxy LB in front of it on a separate node with a floating IP attached to it.
When trying to contact the kube-apiserver using
curl -vv -k https://{floating IP}:{k8s api port}, it hangs at the client hello:Only this specific combination exhibits the problem. That is:
Things that, interestingly, do work (all done separately):
openssl s_serverallows full two-way communicationI am hoping that by submitting this report here, I can gain some additional insight into what the problem could be, especially because I have pinned 2a8c81f as the breaking commit.
P.S. If anyone has or could whip up a simple Go program that only listens on a port and establishes a TLS connection (two versions; at 2a8c81f and the commit before it), I could fully eliminate kubernetes from the equation. I'll try to work on it myself, but I haven't written a line of Go in my life. It would be super helpful!
HAProxy config:
(HA-Proxy version 1.5.14 2015/07/02)Some HAProxy logs (more at https://gist.github.com/dragorosson/9843b863e77b316ea4128f0ee1661c73):