<p>I have a Kubernetes cluster running in High Availability mode with 3 master nodes. When I try to run the DNS cluster add-on as-is, the <code>kube2sky</code> application errors with an x509 signed by unknown certificate authority message for the API Server service address (which in my case is 10.100.0.1). Reading through some of the GitHub issues, it looked like Tim Hockin had fixed this type of issue via using the default service account  tokens available.</p>

<p>All 3 of my master nodes generate their own certificates for the secured API port, so is there something special I need to do configuration-wise on the API servers to get the CA certificate included in the default service account token?</p>

<p>It would be ideal to have the service IP of the API in the SAN field of all your server certificates.</p>

<p>If this is not possible in your setup, set the <code>clusters{}.cluster.insecure-skip-tls-verify</code> field to <code>true</code> in your <a href="http://kubernetes.io/docs/user-guide/kubeconfig-file/" rel="nofollow" title="kubeconfig">kubeconfig file</a>, or the pass the <code>--insecure-skip-tls-verify</code> flag to <code>kubectl</code>.</p>

<p>If you are trying to reach the API from within a pod you could use the secrets mounted via the <a href="http://kubernetes.io/docs/user-guide/service-accounts/" rel="nofollow" title="service accounts">Service Account</a>. By default, if you use the default secret, the CA certificate and a signed token are mounted to <code>/var/run/secrets/kubernetes.io/serviceaccount/</code> in every pod, and any client can use them from within the pod to communicate with the API. This would help you solving the <code>unknown certificate authority</code> error and provide you with an easy way to authenticate against your API servers at the same time.</p>
