Accessing Clusters

    When accessing the Kubernetes API for the first time, we suggest using the Kubernetes CLI, .

    To access a cluster, you need to know the location of the cluster and have credentials to access it. Typically, this is automatically set-up when you work through a , or someone else set up the cluster and provided you with credentials and a location.

    Check the location and credentials that kubectl knows about with this command:

    Many of the examples provide an introduction to using kubectl, and complete documentation is found in the .

    Directly accessing the REST API

    Kubectl handles locating and authenticating to the apiserver. If you want to directly access the REST API with an http client like curl or wget, or a browser, there are several ways to locate and authenticate:

    • Run kubectl in proxy mode.
      • Recommended approach.
      • Uses stored apiserver location.
      • Verifies identity of apiserver using self-signed cert. No MITM possible.
      • Authenticates to apiserver.
      • In future, may do intelligent client-side load-balancing and failover.
    • Provide the location and credentials directly to the http client.
      • Alternate approach.
      • Works with some types of client code that are confused by using a proxy.
      • Need to import a root cert into your browser to protect against MITM.

    The following command runs kubectl in a mode where it acts as a reverse proxy. It handles locating the apiserver and authenticating. Run it like this:

    1. kubectl proxy --port=8080

    See kubectl proxy for more details.

    Then you can explore the API with curl, wget, or a browser, replacing localhost with [::1] for IPv6, like so:

    1. curl http://localhost:8080/api/

    The output is similar to this:

    Use kubectl apply and kubectl describe secret... to create a token for the default service account with grep/cut:

    First, create the Secret, requesting a token for the default ServiceAccount:

    1. kubectl apply -f - <<EOF
    2. apiVersion: v1
    3. kind: Secret
    4.   name: default-token
    5.   annotations:
    6.     kubernetes.io/service-account.name: default
    7. type: kubernetes.io/service-account-token
    1. while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
    2.   echo "waiting for token..." >&2
    3.   sleep 1
    4. done

    Capture and use the generated token:

    The output is similar to this:

    1. {
    2.   "kind": "APIVersions",
    3.   "versions": [
    4.     "v1"
    5.   ],
    6.   "serverAddressByClientCIDRs": [
    7.     {
    8.       "clientCIDR": "0.0.0.0/0",
    9.       "serverAddress": "10.0.1.149:443"
    11.   ]
    12. }

    Using jsonpath:

    1. APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
    2. TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
    4. curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

    The output is similar to this:

    The above examples use the --insecure flag. This leaves it subject to MITM attacks. When kubectl accesses the cluster it uses a stored root certificate and client certificates to access the server. (These are installed in the ~/.kube directory). Since cluster certificates are typically self-signed, it may take special configuration to get your http client to use root certificate.

    On some clusters, the apiserver does not require authentication; it may serve on localhost, or be protected by a firewall. There is not a standard for this. Controlling Access to the API describes how a cluster admin can configure this.

    Kubernetes officially supports Go and client libraries.

    • To get the library, run the following command: go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, see for detailed installation instructions. See https://github.com/kubernetes/client-go to see which versions are supported.
    • Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., import "k8s.io/client-go/kubernetes" is correct.

    The Go client can use the same as the kubectl CLI does to locate and authenticate to the apiserver. See this example.

    If the application is deployed as a Pod in the cluster, please refer to the .

    To use , run the following command: pip install kubernetes. See Python Client Library page for more installation options.

    The Python client can use the same as the kubectl CLI does to locate and authenticate to the apiserver. See this example.

    Accessing the API from a Pod

    When accessing the API from a pod, locating and authenticating to the API server are somewhat different.

    Please check for more details.

    The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see .

    Requesting redirects

    The redirect capabilities have been deprecated and removed. Please use a proxy (see below) instead.

    There are several different proxies you may encounter when using Kubernetes:

    1. The apiserver proxy:

      • is a bastion built into the apiserver
      • connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
      • runs in the apiserver processes
      • client to proxy uses HTTPS (or http if apiserver so configured)
      • proxy to target may use HTTP or HTTPS as chosen by proxy using available information
      • can be used to reach a Node, Pod, or Service
      • does load balancing when used to reach a Service

    2. The :

      • runs on each node
      • proxies UDP and TCP
      • does not understand HTTP
      • provides load balancing
      • is only used to reach services

    3. A Proxy/Load-balancer in front of apiserver(s):

      • existence and implementation varies from cluster to cluster (e.g. nginx)
      • sits between all clients and one or more apiservers
      • acts as load balancer if there are several apiservers.

    4. Cloud Load Balancers on external services:

      • are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
      • are created automatically when the Kubernetes service has type LoadBalancer
      • implementation varies by cloud provider.

    Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin will typically ensure that the latter types are set up correctly.