问题
I am running the open source kube version 1.9, getting TLS handshake timeout error while running the kubectl logs command, other kubectl commands are working fine.
#:/etc/kubernetes/pki> kubectl get pods
NAME READY STATUS RESTARTS AGE
app1-9 1/1 Running 0 2d
#:/etc/kubernetes/pki> kubectl logs counter
Error from server: Get https://XX.XX.XX.XXXX:10250/containerLogs/default/counter/count: net/http: TLS handshake timeout
kubectl version is:
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T20:55:30Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I see the apiserver is running on 10250. How to make kubectl connect to apiserver over the SSL?
回答1:
I see the apiserver is running on 10250. How to make kubectl connect to apiserver over the SSL?
It's actually not the apiserver running on 10250, that's kubelet's port on the Node upon which the counter Pod has been scheduled. When asking for the logs, the apiserver redirects kubectl over to the actual Node in order to stream the logs directly out of kubelet (rather than streaming the logs from kubelet through the apiserver down to you).
Experiencing a connection timeout smells very much like misconfigured security groups between your machine and the Node. I don't know off-hand if one can pin the kubelet port to a specific one, in order to statically whitelist it, but it seems like a problem someone would have experienced before.
回答2:
I had the same issue on my cluster and it has been plagiung me for the past few months. I ran the command curl -v8 showed my it wasn't a tls/cert issue (really bad error message.)
This lead me to look at other issues, such as the API server/gateway, nodes and so forth. It turns out that the the error --on my cluster-- was caused by mismatch API's. This was due to my adding a new node. After doing some digging I found a command that would allow me to see what API version/s my cluster was running and then guide me to an updated version.
I updated my cluster using 'kubeadm upgrade plan'. The command advised I could update the cluster to version 10.1.5 or 10.1.11, however I would need to updated Kubeadm first. I updated Kubeadm and then updated my kube components on all the other nodes. Once the nodes had been updates, I used the kubeadm init join command to add all the nodes to the new cluster set. NB at this point I would like to say that none of my PODS dropped.
Everything had rejoined the cluster and now, I can browse the logs across the cluster through all PODS.
I hope this helps anyone who's looking for an answer.
来源：https://stackoverflow.com/questions/48328851/kubernetes-logs-command-tls-handshake-timeout