You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What keywords did you search in Kubernetes issues before filing this one?
controller /etc/ssl/certs
kubeadm /etc/ssl/certs
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Kubernetes version (use kubectl version):
1.5 custom built master
I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ...
Others: deployed with Azure RM template and ansible
What happened:
controller is not able to do https, including calls to the Azure RM API
What you expected to happen:
https should work as usual
How to reproduce it (as minimally and precisely as possible):
Use kubeadm to install kubernetes on CentOS
exec into the controller and try "curl https://google.com"
Anything else do we need to know:
It looks like kubernetes/kubernetes#33681 caused this issue. On CentOS, I see these files on the host OS:
I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image.
I also tried to verify this with gcr.io/google_containers/kube-controller-manager-amd64:v1.4.4. It seems to not be based on Debian and thus gives a different error:
[devops@ma-kub8ms0 ~]$ docker run -ti --rm -v /etc/ssl/certs:/etc/ssl/certs gcr.io/google_containers/kube-controller-manager-amd64:v1.4.4 sh
/ # wget https://google.de
Connecting to google.de (172.217.21.227:443)
wget: can't execute 'ssl_helper': No such file or directory
wget: error getting response: Connection reset by peer
I see 2 possible solutions:
Instead of host mounting /etc/ssl/certs into the controller pod, the ca certificates could be installed into the image. This is already done for hyperkube and would work out of the box when the host mount would be omitted.
kubeadm could try to figure out if /etc/pki should also be host mounted and add this to the controller manifest if required.
I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
From @codablock on November 3, 2016 10:52
What keywords did you search in Kubernetes issues before filing this one?
controller /etc/ssl/certs
kubeadm /etc/ssl/certs
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Kubernetes version (use
kubectl version
):1.5 custom built master
I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ...
Environment:
uname -a
): Linux ma-kub8ms0 3.10.0-327.36.3.el7.x86_64 kubeadm join on slave node fails preflight checks #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/LinuxWhat happened:
controller is not able to do https, including calls to the Azure RM API
What you expected to happen:
https should work as usual
How to reproduce it (as minimally and precisely as possible):
Use kubeadm to install kubernetes on CentOS
exec into the controller and try "curl https://google.com"
Anything else do we need to know:
It looks like kubernetes/kubernetes#33681 caused this issue. On CentOS, I see these files on the host OS:
I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image.
I also tried to verify this with gcr.io/google_containers/kube-controller-manager-amd64:v1.4.4. It seems to not be based on Debian and thus gives a different error:
I see 2 possible solutions:
I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
Copied from original issue: kubernetes/kubernetes#36150
The text was updated successfully, but these errors were encountered: