Fix in-cluster API discovery documentation (#36691)
* Fix in-cluster API discovery documentation The documentation incorrectly describes the way that client libraries discover the Kubernetes API server. While the `kubernetes.default.svc` DNS is provided as a convenience, **all** of the officially supported API clients use environment variables to discover the address of the API server. This change updates the documentation to reflect this. Signed-off-by: Oliver Gould <ver@buoyant.io> * Review feedback * Fixup Signed-off-by: Oliver Gould <ver@buoyant.io>pull/38918/head
parent
4b741545e9
commit
b715a6713c
|
@ -42,10 +42,18 @@ securely with the API server.
|
|||
|
||||
### Directly accessing the REST API
|
||||
|
||||
While running in a Pod, the Kubernetes apiserver is accessible via a Service named
|
||||
`kubernetes` in the `default` namespace. Therefore, Pods can use the
|
||||
`kubernetes.default.svc` hostname to query the API server. Official client libraries
|
||||
do this automatically.
|
||||
While running in a Pod, your container can create an HTTPS URL for the Kubernetes API
|
||||
server by fetching the `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT_HTTPS`
|
||||
environment variables. The API server's in-cluster address is also published to a
|
||||
Service named `kubernetes` in the `default` namespace so that pods may reference
|
||||
`kubernetes.default.svc` as a DNS name for the local API server.
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes does not guarantee that the API server has a valid certificate for
|
||||
the hostname `kubernetes.default.svc`;
|
||||
however, the control plane **is** expected to present a valid certificate for the
|
||||
hostname or IP address that `$KUBERNETES_SERVICE_HOST` represents.
|
||||
{{< /note >}}
|
||||
|
||||
The recommended way to authenticate to the API server is with a
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
|
|
Loading…
Reference in New Issue