Accessing Clusters [page]deterministic
This topic discusses multiple ways to interact with clusters.
## Accessing for the first time with kubectl
When accessing the Kubernetes API for the first time, we suggest using the Kubernetes CLI, `kubectl`.
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 [Getting started guide](/docs/setup/), 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:
```shell kubectl config view ```
Many of the [examples](/docs/reference/kubectl/quick-reference/) provide an introduction to using `kubectl`, and complete documentation is found in the [kubectl reference](/docs/reference/kubectl/).
## 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.
### Using kubectl proxy
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:
```shell kubectl proxy --port=8080 ```
See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details.
Then you can explore the API with curl, wget, or a browser, replacing localhost with [::1] for IPv6, like so:
```shell curl http://localhost:8080/api/ ```
The output is similar to this:
```json { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.0.1.149:443" } ] } ```
### Without kubectl proxy
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:
```shell kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: default-token annotations: kubernetes.io/service-account.name: default type: kubernetes.io/service-account-token EOF ```
Next, wait for the token controller to populate the Secret with a token:
```shell while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do echo "waiting for token..." >&2 sleep 1 done ```
Capture and use the generated token:
```shell APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ") TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure ```
The output is similar to this:
```json { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.0.1.149:443" } ] } ```
Using `jsonpath`:
```shell APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure ```
The output is similar to this:
```json { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.0.1.149:443" } ] } ```
The above examples use the ` …(trimmed)