I set up Kubernetes cluster on aws using kops using this tutorial on official kubernetes github branch.
The cluster set up successfully on AWS, but when I try to run
kubectl get nodes
or
kops validate cluster
it says
[user@ip-70-0-0-7 ~]$ kubectl cluster-info
Unable to connect to the server: x509: certificate is valid for *.secure.hosting prod.com, not api.subdomain.mydomain.com
This is definitely problem with my x509 certificates. Just need a gentle push to right direction. Thank you for your precious time and help!
NOTE: I am running these commands from outside the cluster from a machine from where I did set up of cluster.
Unable to connect to the server: x509: certificate is valid for *.secure.hosting prod.com, not api.subdomain.mydomain.com
I can't tell if those names you listed are examples, or the actual values that kubectl is giving you, but I'll use them as you've written just to keep things simple
If the kubernetes cluster you installed is really accessible via api.secure.hostingprod.com, then updating your $HOME/.kube/config to say https://api.secure.hostingprod.com where it currently says https://api.subdomain.mydomain.com should get things back in order.
Alternatively, if api.secure.hosting prod.com is not an actual domain you can use (for example, if your certificate really does have a space in the hostname), then you have a couple of options.
The cheapest, but least correct, might be to just tell kubectl "I know what I'm doing, don't check the cert" by setting the insecure-skip-tls-verify option under the cluster entry in the $HOME/.kube/config file:
- cluster:
insecure-skip-tls-verify: true
The more bothersome, but also most correct, would be to re-issue the certificate for the API server using the actual hostname (apparently api.subdomain.mydomain.com). If you know how, extra-super-best is to also add "Subject Alternate Names" (abbreviated as "SAN") to the certificate, so that in-cluster members can refer to it as https://kubernetes and/or https://kubernetes.default.svc.cluster.local, along with the Service IP address assigned to the kubernetes Service in the default namespace. It's extremely likely that your current certificate has those values, which openssl x509 -in /path/to/your.crt -noout -text will show you what they currently are. If you need help with the openssl bits, CoreOS Kubernetes has a shell script they use, which might work as written or if nothing else provide very concrete guidance.
I do recognize that's a lot of words, and also a lot of work, but certificates are super important so getting them as correct as possible will really save everyone heartache down the line.