Adding OWNERS for docs.
This commit is contained in:
foxish
@@ -0,0 +1,5 @@
|
||||
assignees:
|
||||
- erictune
|
||||
- janetkuo
|
||||
- satnam6502
|
||||
|
||||
@@ -1,7 +1,11 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
- mikedanese
|
||||
|
||||
* TOC
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Accessing the cluster API
|
||||
@@ -18,10 +22,10 @@ or someone else setup the cluster and provided you with credentials and a locati
|
||||
|
||||
Check the location and credentials that kubectl knows about with this command:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/kubectl).
|
||||
|
||||
@@ -29,7 +33,7 @@ kubectl and complete documentation is found in the [kubectl manual](/docs/user-g
|
||||
|
||||
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:
|
||||
curl or wget, or a browser, there are several ways to locate and authenticate:
|
||||
|
||||
- Run kubectl in proxy mode.
|
||||
- Recommended approach.
|
||||
@@ -48,29 +52,29 @@ The following command runs kubectl in a mode where it acts as a reverse proxy.
|
||||
locating the apiserver and authenticating.
|
||||
Run it like this:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl proxy --port=8080 &
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
See [kubectl proxy](/docs/user-guide/kubectl/kubectl_proxy) for more details.
|
||||
|
||||
Then you can explore the API with curl, wget, or a browser, like so:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ curl http://localhost:8080/api/
|
||||
{
|
||||
"versions": [
|
||||
"v1"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
#### Without kubectl proxy
|
||||
|
||||
It is also possible to avoid using kubectl proxy by passing an authentication token
|
||||
directly to the apiserver, like this:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
$ TOKEN=$(kubectl config view | grep token | cut -f 2 -d ":" | tr -d " ")
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
@@ -79,8 +83,8 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
"v1"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
The above example uses 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
|
||||
@@ -119,14 +123,14 @@ is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
|
||||
If available, a certificate bundle is placed into the filesystem tree of each
|
||||
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
|
||||
used to verify the serving certificate of the apiserver.
|
||||
|
||||
Finally, the default namespace to be used for namespaced API operations is placed in a file
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
|
||||
|
||||
From within a pod the recommended ways to connect to API are:
|
||||
If available, a certificate bundle is placed into the filesystem tree of each
|
||||
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
|
||||
used to verify the serving certificate of the apiserver.
|
||||
|
||||
Finally, the default namespace to be used for namespaced API operations is placed in a file
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
|
||||
|
||||
From within a pod the recommended ways to connect to API are:
|
||||
|
||||
- run a kubectl proxy as one of the containers in the pod, or as a background
|
||||
process within a container. This proxies the
|
||||
@@ -134,7 +138,7 @@ From within a pod the recommended ways to connect to API are:
|
||||
in any container of the pod can access it. See this [example of using kubectl proxy
|
||||
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
|
||||
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
|
||||
This handles locating and authenticating to the apiserver.
|
||||
This handles locating and authenticating to the apiserver.
|
||||
|
||||
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
||||
|
||||
@@ -150,7 +154,7 @@ such as your desktop machine.
|
||||
|
||||
### Ways to connect
|
||||
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
@@ -182,7 +186,7 @@ You have several options for connecting to nodes, pods and services from outside
|
||||
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
|
||||
with the `kubectl cluster-info` command:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl cluster-info
|
||||
|
||||
Kubernetes master is running at https://104.197.5.247
|
||||
@@ -191,8 +195,8 @@ $ kubectl cluster-info
|
||||
kube-dns is running at https://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/kube-dns
|
||||
grafana is running at https://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
|
||||
heapster is running at https://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/monitoring-heapster
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging/` if suitable credentials are passed, or through a kubectl proxy at, for example:
|
||||
@@ -211,7 +215,7 @@ If you haven't specified a name for your port, you don't have to specify *port_n
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy`
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: `https://104.197.5.247/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging/_cluster/health?pretty=true`
|
||||
|
||||
```json
|
||||
```json
|
||||
{
|
||||
"cluster_name" : "kubernetes_logging",
|
||||
"status" : "yellow",
|
||||
@@ -224,11 +228,11 @@ If you haven't specified a name for your port, you don't have to specify *port_n
|
||||
"initializing_shards" : 0,
|
||||
"unassigned_shards" : 5
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
#### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
@@ -241,7 +245,7 @@ The redirect capabilities have been deprecated and removed. Please use a proxy
|
||||
|
||||
## So Many Proxies
|
||||
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
|
||||
1. The [kubectl proxy](#directly-accessing-the-rest-api):
|
||||
- runs on a user's desktop or in a pod
|
||||
@@ -275,4 +279,4 @@ There are several different proxies you may encounter when using Kubernetes:
|
||||
- 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 setup correctly.
|
||||
will typically ensure that the latter types are setup correctly.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
We have [labels](/docs/user-guide/labels) for identifying metadata.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
This document is meant to highlight and consolidate in one place configuration best practices that are introduced throughout the user-guide and getting-started documentation and examples. This is a living document so if you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- dchen1107
|
||||
- pmorie
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- eparis
|
||||
- pmorie
|
||||
|
||||
---
|
||||
Many applications require configuration via some combination of config files, command line
|
||||
arguments, and environment variables. These configuration artifacts should be decoupled from image
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](/docs/user-guide/kubectl/kubectl_port-forward). Compared to [kubectl proxy](/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging.
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
You have seen the [basics](/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](/docs/user-guide/ui)) running on the Kubernetes cluster from your workstation.
|
||||
|
||||
@@ -8,11 +12,11 @@ You have seen the [basics](/docs/user-guide/accessing-the-cluster) about `kubect
|
||||
|
||||
kube-ui is deployed as a cluster add-on. To find its apiserver proxy URL,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl cluster-info | grep "KubeUI"
|
||||
KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
if this command does not find the URL, try the steps [here](/docs/user-guide/ui/#accessing-the-ui).
|
||||
|
||||
|
||||
@@ -20,9 +24,9 @@ if this command does not find the URL, try the steps [here](/docs/user-guide/ui/
|
||||
|
||||
The above proxy URL is an access to the kube-ui service provided by the apiserver. To access it, you still need to authenticate to the apiserver. `kubectl proxy` can handle the authentication.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl proxy --port=8001
|
||||
Starting to serve on localhost:8001
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Now you can access the kube-ui service on your local workstation at [http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui](http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui)
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
This document describes the environment for Kubelet managed containers on a Kubernetes node (kNode). In contrast to the Kubernetes cluster API, which provides an API for creating and managing containers, the Kubernetes container environment provides the container access to information about what else is going on in the cluster.
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- janetkuo
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
An issue that comes up rather frequently for new installations of Kubernetes is
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- caesarxuchao
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
In this doc, we introduce the Kubernetes command line for interacting with the api to docker-cli users. The tool, kubectl, is designed to be familiar to docker-cli users but there are a few necessary differences. Each section of this doc highlights a docker subcommand explains the kubectl equivalent.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- mikedanese
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
It is sometimes useful for a container to have information about itself, but we
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
This example demonstrates running pods, replication controllers, and
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
assignees:
|
||||
- quinton-hoole
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- quinton-hoole
|
||||
|
||||
---
|
||||
|
||||
This guide explains how to use Kubernetes Federated Services to deploy
|
||||
|
||||
@@ -1,26 +1,30 @@
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## WARNING: Garbage Collector is an alpha feature and is disabled by default. Use it at your own risk!
|
||||
|
||||
### What is garbage collector for
|
||||
|
||||
{:toc}
|
||||
|
||||
## WARNING: Garbage Collector is an alpha feature and is disabled by default. Use it at your own risk!
|
||||
|
||||
### What is garbage collector for
|
||||
|
||||
The garbage collector (GC) cascadingly deletes dependent API objects when the owner is deleted. One use case is if two objects have functional dependency, you can specify the dependency in their configuration file when creating them, and if one of them is deleted, the GC will delete the other one automatically. The other use case is if there is logical dependency among API objects, e.g., the pods created by a replicaset depending on the replicaset, Kubernetes will automatically set the dependency (this will be implemented in release 1.4) and the GC will delete the pods when the replicaset is deleted.
|
||||
|
||||
### How does the garbage collector work
|
||||
|
||||
### How does the garbage collector work
|
||||
|
||||
In release 1.3, there is a new `ownerReferences` field in the `metadata` of every Kubernetes API objects. The GC monitors the cluster and checks the `metadata.ownerReferences` field of each object. If none of the owners present in `metadata.ownerReferences` exists in the cluster, the GC will request the API server to delete the object.
|
||||
|
||||
Currently a user needs to manually set the `metadata.ownerReferences`. In release 1.4, controllers will automatically set the field for the objects it controls. For example, when the replicaset controller creates or adopts pods, it will automatically add the replicaset to the `metadata.ownerReferences` fields of the pods.
|
||||
|
||||
### How to request the garbage collector to not delete dependents
|
||||
|
||||
### How to request the garbage collector to not delete dependents
|
||||
|
||||
When deleting an object, you can prevent the GC from deleting that object's dependents by specifying `deleteOptions.orphanDependents=true` in the deletion request. It prevents garbage collection by removing the object from its dependents' metadata.ownerReferences field.
|
||||
|
||||
### How to enable the garbage collector
|
||||
|
||||
|
||||
### How to enable the garbage collector
|
||||
|
||||
The garbage collector is an alpha feature so it is disabled by default. To enable it, you need to start the kube-apiserver and kube-controller-manager with flag `--enable-garbage-collector`.
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases.
|
||||
|
||||
@@ -9,28 +13,28 @@ Kubernetes exposes [services](/docs/user-guide/services/#environment-variables)
|
||||
|
||||
We first create a pod and a service,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create -f examples/guestbook/redis-master-controller.yaml
|
||||
$ kubectl create -f examples/guestbook/redis-master-service.yaml
|
||||
```
|
||||
```
|
||||
wait until the pod is Running and Ready,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl get pod
|
||||
NAME READY REASON RESTARTS AGE
|
||||
redis-master-ft9ex 1/1 Running 0 12s
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
then we can check the environment variables of the pod,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl exec redis-master-ft9ex env
|
||||
...
|
||||
REDIS_MASTER_SERVICE_PORT=6379
|
||||
REDIS_MASTER_SERVICE_HOST=10.0.0.219
|
||||
...
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
We can use these environment variables in applications to find the service.
|
||||
|
||||
|
||||
@@ -39,32 +43,32 @@ We can use these environment variables in applications to find the service.
|
||||
It is convenient to use `kubectl exec` to check if the volumes are mounted as expected.
|
||||
We first create a Pod with a volume mounted at /data/redis,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
wait until the pod is Running and Ready,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY REASON RESTARTS AGE
|
||||
storage 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
we then use `kubectl exec` to verify that the volume is mounted at /data/redis,
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl exec storage ls /data
|
||||
redis
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Using kubectl exec to open a bash terminal in a pod
|
||||
|
||||
After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl exec -ti storage -- bash
|
||||
root@storage:/data#
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
This gets you a terminal.
|
||||
@@ -0,0 +1,5 @@
|
||||
assignees:
|
||||
- fgrzadkowski
|
||||
- janetkuo
|
||||
- jszczepkowski
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
|
||||
---
|
||||
|
||||
This document describes the current state of Horizontal Pod Autoscaling in Kubernetes.
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- fgrzadkowski
|
||||
- jszczepkowski
|
||||
- justinsb
|
||||
|
||||
---
|
||||
|
||||
Horizontal Pod Autoscaling automatically scales the number of pods
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
Each container in a pod has its own image. Currently, the only type of image supported is a [Docker Image](https://docs.docker.com/userguide/dockerimages/).
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- janetkuo
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
Once your application is running, you'll inevitably need to debug problems with it.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- soltysh
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- erictune
|
||||
- soltysh
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- daizuozhuo
|
||||
|
||||
---
|
||||
|
||||
JSONPath template is composed of JSONPath expressions enclosed by {}.
|
||||
|
||||
+126
-122
@@ -1,5 +1,9 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
Authentication in kubernetes can differ for different individuals.
|
||||
|
||||
@@ -22,7 +26,7 @@ http://issue.k8s.io/1755
|
||||
|
||||
### Example kubeconfig file
|
||||
|
||||
```yaml
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
@@ -60,104 +64,104 @@ users:
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
### Breakdown/explanation of components
|
||||
|
||||
#### cluster
|
||||
|
||||
```yaml
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
```
|
||||
|
||||
A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
|
||||
qualified url for the kubernetes apiserver, as well as the cluster's certificate
|
||||
authority or `insecure-skip-tls-verify: true`, if the cluster's serving
|
||||
certificate is not signed by a system trusted certificate authority.
|
||||
A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
|
||||
within this kubeconfig file. You can add or modify `cluster` entries using
|
||||
[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/).
|
||||
|
||||
#### user
|
||||
|
||||
```yaml
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
A `user` defines client credentials for authenticating to a kubernetes cluster. A
|
||||
`user` has a name (nickname) which acts as its key within the list of user entries
|
||||
after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
|
||||
`client-key`, `token`, and `username/password`. `username/password` and `token`
|
||||
are mutually exclusive, but client certs and keys can be combined with them.
|
||||
You can add or modify `user` entries using
|
||||
[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials).
|
||||
|
||||
#### context
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
```
|
||||
|
||||
A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple
|
||||
which is used to send requests to the specified cluster using the provided authentication info and
|
||||
namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`,
|
||||
`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding
|
||||
entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file)
|
||||
will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior.
|
||||
You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context).
|
||||
|
||||
#### current-context
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
```
|
||||
|
||||
`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl
|
||||
will use by default when loading config from this file. You can override any of the values in kubectl
|
||||
from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
|
||||
You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context).
|
||||
|
||||
#### miscellaneous
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
```
|
||||
|
||||
`apiVersion` and `kind` identify the version and schema for the client parser and should not
|
||||
be edited manually.
|
||||
|
||||
`preferences` specify optional (and currently unused) kubectl preferences.
|
||||
|
||||
## Viewing kubeconfig files
|
||||
|
||||
`kubectl config view` will display the current kubeconfig settings. By default
|
||||
it will show you all loaded kubeconfig settings; you can filter the view to just
|
||||
the settings relevant to the `current-context` by passing `--minify`. See
|
||||
[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options.
|
||||
|
||||
```
|
||||
|
||||
### Breakdown/explanation of components
|
||||
|
||||
#### cluster
|
||||
|
||||
```yaml
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
```
|
||||
|
||||
A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
|
||||
qualified url for the kubernetes apiserver, as well as the cluster's certificate
|
||||
authority or `insecure-skip-tls-verify: true`, if the cluster's serving
|
||||
certificate is not signed by a system trusted certificate authority.
|
||||
A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
|
||||
within this kubeconfig file. You can add or modify `cluster` entries using
|
||||
[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/).
|
||||
|
||||
#### user
|
||||
|
||||
```yaml
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
A `user` defines client credentials for authenticating to a kubernetes cluster. A
|
||||
`user` has a name (nickname) which acts as its key within the list of user entries
|
||||
after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
|
||||
`client-key`, `token`, and `username/password`. `username/password` and `token`
|
||||
are mutually exclusive, but client certs and keys can be combined with them.
|
||||
You can add or modify `user` entries using
|
||||
[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials).
|
||||
|
||||
#### context
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
```
|
||||
|
||||
A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple
|
||||
which is used to send requests to the specified cluster using the provided authentication info and
|
||||
namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`,
|
||||
`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding
|
||||
entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file)
|
||||
will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior.
|
||||
You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context).
|
||||
|
||||
#### current-context
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
```
|
||||
|
||||
`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl
|
||||
will use by default when loading config from this file. You can override any of the values in kubectl
|
||||
from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
|
||||
You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context).
|
||||
|
||||
#### miscellaneous
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
```
|
||||
|
||||
`apiVersion` and `kind` identify the version and schema for the client parser and should not
|
||||
be edited manually.
|
||||
|
||||
`preferences` specify optional (and currently unused) kubectl preferences.
|
||||
|
||||
## Viewing kubeconfig files
|
||||
|
||||
`kubectl config view` will display the current kubeconfig settings. By default
|
||||
it will show you all loaded kubeconfig settings; you can filter the view to just
|
||||
the settings relevant to the `current-context` by passing `--minify`. See
|
||||
[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options.
|
||||
|
||||
## Building your own kubeconfig file
|
||||
|
||||
NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you.
|
||||
@@ -168,11 +172,11 @@ So, lets do a quick walk through the basics of the above file so you can easily
|
||||
|
||||
The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this:
|
||||
|
||||
```conf
|
||||
```conf
|
||||
blue-user,blue-user,1
|
||||
mister-red,mister-red,2
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes).
|
||||
|
||||
- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials.
|
||||
@@ -182,7 +186,7 @@ In the above scenario, green-user would have to log in by providing certificates
|
||||
|
||||
## Loading and merging rules
|
||||
|
||||
The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order:
|
||||
The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order:
|
||||
|
||||
1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules:
|
||||
|
||||
@@ -215,12 +219,12 @@ The rules for loading and merging the kubeconfig files are straightforward, but
|
||||
1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`.
|
||||
1. If there are two conflicting techniques, fail.
|
||||
1. For any information still missing, use default values and potentially prompt for authentication information
|
||||
1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line
|
||||
they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely.
|
||||
1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line
|
||||
they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely.
|
||||
|
||||
Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself.
|
||||
|
||||
|
||||
Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself.
|
||||
|
||||
|
||||
## Manipulation of kubeconfig via `kubectl config <subcommand>`
|
||||
|
||||
In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help.
|
||||
@@ -228,18 +232,18 @@ See [kubectl/kubectl_config.md](/docs/user-guide/kubectl/kubectl_config) for hel
|
||||
|
||||
### Example
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl config set-credentials myself --username=admin --password=secret
|
||||
$ kubectl config set-cluster local-server --server=http://localhost:8080
|
||||
$ kubectl config set-context default-context --cluster=local-server --user=myself
|
||||
$ kubectl config use-context default-context
|
||||
$ kubectl config set contexts.default-context.namespace the-right-prefix
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
produces this output
|
||||
|
||||
```yaml
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -259,11 +263,11 @@ users:
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
and a kubeconfig file that looks like this
|
||||
|
||||
```yaml
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -283,11 +287,11 @@ users:
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
#### Commands for the example file
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl config set preferences.colors true
|
||||
$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1
|
||||
$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile
|
||||
@@ -297,8 +301,8 @@ $ kubectl config set-credentials green-user --client-certificate=path/to/my/clie
|
||||
$ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=black-user --namespace=saw-ns
|
||||
$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns
|
||||
$ kubectl config use-context federal-context
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
### Final notes for tying it all together
|
||||
|
||||
So, tying this all together, a quick start to creating your own kubeconfig file:
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- erictune
|
||||
- krousey
|
||||
|
||||
---
|
||||
An assortment of compact kubectl examples
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- hw-qiaolei
|
||||
|
||||
---
|
||||
|
||||
Use this overview of the `kubectl` command line interface to help you start running commands against Kubernetes clusters. This overview quickly covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/user-guide/kubectl/kubectl) reference documentation.
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- feihujiang
|
||||
- hurf
|
||||
- janetkuo
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- hurf
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- hurf
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl annotate
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
## kubectl api-versions
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl apply
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl attach
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- fgrzadkowski
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
## kubectl autoscale
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
|
||||
---
|
||||
## kubectl cluster-info
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
## kubectl config current-context
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config set-cluster
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config set-context
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config set-credentials
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config set
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config unset
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl config use-context
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- eparis
|
||||
- hurf
|
||||
|
||||
---
|
||||
## kubectl config view
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- AdoHe
|
||||
- bgrant0607
|
||||
|
||||
---
|
||||
## kubectl convert
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
## kubectl cordon
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl create
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
## kubectl create configmap
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- derekwaynecarr
|
||||
|
||||
---
|
||||
## kubectl create namespace
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
## kubectl create secret
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- derekwaynecarr
|
||||
|
||||
---
|
||||
## kubectl create secret docker-registry
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- derekwaynecarr
|
||||
|
||||
---
|
||||
|
||||
## kubectl create secret generic
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- bprashanth
|
||||
- dchen1107
|
||||
- liggitt
|
||||
|
||||
---
|
||||
|
||||
## kubectl create serviceaccount
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl delete
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- hurf
|
||||
|
||||
---
|
||||
|
||||
## kubectl describe
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- mml
|
||||
|
||||
---
|
||||
|
||||
## kubectl drain
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl edit
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl exec
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
## kubectl explain
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- AdoHe
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl expose
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- hurf
|
||||
|
||||
---
|
||||
|
||||
## kubectl get
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- hurf
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl label
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl logs
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- derekwaynecarr
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl namespace
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- caesarxuchao
|
||||
|
||||
---
|
||||
|
||||
## kubectl patch
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
## kubectl port-forward
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl proxy
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- caesarxuchao
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl replace
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- eparis
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
## kubectl rolling-update
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl rollout
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl rollout history
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl rollout pause
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl rollout resume
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl rollout undo
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- brendandburns
|
||||
- feihujiang
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl run
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
## kubectl scale
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
- hurf
|
||||
|
||||
---
|
||||
|
||||
## kubectl stop
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
## kubectl uncordon
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- eparis
|
||||
|
||||
---
|
||||
|
||||
## kubectl version
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
_Labels_ are key/value pairs that are attached to objects, such as pods.
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
This example shows two types of pod [health checks](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- anzhsoft
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
+16
-13
@@ -1,5 +1,8 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
This page is designed to help you use logs to troubleshoot issues with your Kubernetes solution.
|
||||
|
||||
@@ -11,20 +14,20 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god
|
||||
|
||||
The logs of a running container may be fetched using the command `kubectl logs`. For example, given
|
||||
this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
|
||||
output every second. (You can find different pod specifications [here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/logging-demo/).)
|
||||
|
||||
output every second. (You can find different pod specifications [here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/logging-demo/).)
|
||||
|
||||
{% include code.html language="yaml" file="counter-pod.yaml" k8slink="/examples/blog-logging/counter-pod.yaml" %}
|
||||
|
||||
we can run the pod:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create -f ./counter-pod.yaml
|
||||
pods/counter
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
and then fetch the logs:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl logs counter
|
||||
0: Tue Jun 2 21:37:31 UTC 2015
|
||||
1: Tue Jun 2 21:37:32 UTC 2015
|
||||
@@ -33,12 +36,12 @@ $ kubectl logs counter
|
||||
4: Tue Jun 2 21:37:35 UTC 2015
|
||||
5: Tue Jun 2 21:37:36 UTC 2015
|
||||
...
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
If a pod has more than one container then you need to specify which container's log files should
|
||||
be fetched e.g.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl logs kube-dns-v3-7r1l9 etcd
|
||||
2015/06/23 00:43:10 etcdserver: start to snapshot (applied: 30003, lastsnap: 20002)
|
||||
2015/06/23 00:43:10 etcdserver: compacted log at index 30003
|
||||
@@ -54,8 +57,8 @@ $ kubectl logs kube-dns-v3-7r1l9 etcd
|
||||
2015/06/23 04:51:03 etcdserver: compacted log at index 60006
|
||||
2015/06/23 04:51:03 etcdserver: saved snapshot at index 60006
|
||||
...
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Cluster level logging to Google Cloud Logging
|
||||
|
||||
The getting started guide [Cluster Level Logging to Google Cloud Logging](/docs/getting-started-guides/logging)
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user