If you are using a released version of Kubernetes, you should refer to the docs that go with that version.
The latest 1.0.x release of this document can be found [here](http://releases.k8s.io/release-1.0/docs/admin/accessing-the-api.md).Documentation for other releases can be found at releases.k8s.io.
This document describes what ports the Kubernetes apiserver may serve on and how to reach them. The audience is cluster administrators who want to customize their cluster or understand the details.
Most questions about accessing the cluster are covered in Accessing the cluster.
The Kubernetes API is served by the Kubernetes apiserver process. Typically, there is one of these running on a single kubernetes-master node.
By default the Kubernetes APIserver serves HTTP on 2 ports:
- Localhost Port
- serves HTTP
- default is port 8080, change with
--insecure-port
flag. - defaults IP is localhost, change with--insecure-bind-address
flag. - no authentication or authorization checks in HTTP - protected by need to have host access - Secure Port
- default is port 6443, change with
--secure-port
flag. - default IP is first non-localhost network interface, change with--bind-address
flag. - serves HTTPS. Set cert with--tls-cert-file
and key with--tls-private-key-file
flag. - uses token-file or client-certificate based authentication. - uses policy-based authorization. - Removed: ReadOnly Port - For security reasons, this had to be removed. Use the service account feature instead.
Additionally, in some configurations there is a proxy (nginx) running on the same machine as the apiserver process. The proxy serves HTTPS protected by Basic Auth on port 443, and proxies to the apiserver on localhost:8080. In these configurations the secure port is typically set to 6443.
A firewall rule is typically configured to allow external HTTPS access to port 443.
The above are defaults and reflect how Kubernetes is deployed to Google Compute Engine using kube-up.sh. Other cloud providers may vary.
There are three differently configured serving ports because there are a variety of uses cases:
- Clients outside of a Kubernetes cluster, such as human running
kubectl
on desktop machine. Currently, accesses the Localhost Port via a proxy (nginx) running on thekubernetes-master
machine. The proxy can use cert-based authentication or token-based authentication. - Processes running in Containers on Kubernetes that need to read from the apiserver. Currently, these can use a service account.
- Scheduler and Controller-manager processes, which need to do read-write API operations, using service accounts to avoid the need to be co-located.
- Kubelets, which need to do read-write API operations and are necessarily on different machines than the apiserver. Kubelet uses the Secure Port to get their pods, to find the services that a pod can see, and to write events. Credentials are distributed to kubelets at cluster setup time. Kubelet and kube-proxy can use cert-based authentication or token-based authentication.
- Policy will limit the actions kubelets can do via the authed port.