Fix capitalization of Kubernetes in the documentation.
This commit is contained in:
@@ -44,7 +44,7 @@ Documentation for other releases can be found at
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](../../docs/admin/README.md). The [Developer Guide](../../docs/devel/README.md) is for anyone wanting to either write code which directly accesses the kubernetes API, or to contribute directly to the kubernetes project.
|
||||
The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](../../docs/admin/README.md). The [Developer Guide](../../docs/devel/README.md) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
|
||||
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs.md).
|
||||
|
||||
|
@@ -60,7 +60,7 @@ Documentation for other releases can be found at
|
||||
### Accessing for the first time with kubectl
|
||||
|
||||
When accessing the Kubernetes API for the first time, we suggest using the
|
||||
kubernetes CLI, `kubectl`.
|
||||
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
|
||||
@@ -172,7 +172,7 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
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
|
||||
kubernetes API to the localhost interface of the pod, so that other processes
|
||||
Kubernetes API to the localhost interface of the pod, so that other processes
|
||||
in any container of the pod can access it. See this [example of using kubectl proxy
|
||||
in a pod](../../examples/kubectl-container/).
|
||||
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
|
||||
@@ -183,7 +183,7 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In kubernetes, the
|
||||
connecting to other services running on Kubernetes cluster. In Kubernetes, the
|
||||
[nodes](../admin/node.md), [pods](pods.md) and [services](services.md) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
@@ -280,10 +280,10 @@ 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
|
||||
- proxies from a localhost address to the kubernetes apiserver
|
||||
- proxies from a localhost address to the Kubernetes apiserver
|
||||
- client to proxy uses HTTP
|
||||
- proxy to apiserver uses HTTPS
|
||||
- locates apiserver
|
||||
@@ -308,7 +308,7 @@ There are several different proxies you may encounter when using kubernetes:
|
||||
- acts as load balancer if there are several apiservers.
|
||||
1. 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`
|
||||
- are created automatically when the Kubernetes service has type `LoadBalancer`
|
||||
- use UDP/TCP only
|
||||
- implementation varies by cloud provider.
|
||||
|
||||
|
@@ -103,7 +103,7 @@ spec:
|
||||
|
||||
## How Pods with Resource Limits are Scheduled
|
||||
|
||||
When a pod is created, the kubernetes scheduler selects a node for the pod to
|
||||
When a pod is created, the Kubernetes scheduler selects a node for the pod to
|
||||
run on. Each node has a maximum capacity for each of the resource types: the
|
||||
amount of CPU and memory it can provide for pods. The scheduler ensures that,
|
||||
for each resource type (CPU and memory), the sum of the resource limits of the
|
||||
|
@@ -33,7 +33,7 @@ Documentation for other releases can be found at
|
||||
|
||||
# kubectl for docker users
|
||||
|
||||
In this doc, we introduce the kubernetes command line to 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.
|
||||
In this doc, we introduce the Kubernetes command line to 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.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
@@ -163,7 +163,7 @@ $ kubectl logs -f nginx-app-zibvs
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
```
|
||||
|
||||
Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their process's exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated but for Kubernetes, each invokation is separate. To see the output from a prevoius run in kubernetes, do this:
|
||||
Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their process's exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated but for Kubernetes, each invokation is separate. To see the output from a prevoius run in Kubernetes, do this:
|
||||
|
||||
```console
|
||||
$ kubectl logs --previous nginx-app-zibvs
|
||||
|
@@ -37,7 +37,7 @@ It is sometimes useful for a container to have information about itself, but we
|
||||
want to be careful not to over-couple containers to Kubernetes. The downward
|
||||
API allows containers to consume information about themselves or the system and
|
||||
expose that information how they want it, without necessarily coupling to the
|
||||
kubernetes client or REST API.
|
||||
Kubernetes client or REST API.
|
||||
|
||||
An example of this is a "legacy" app that is already written assuming
|
||||
that a particular environment variable will hold a unique identifier. While it
|
||||
|
@@ -38,7 +38,7 @@ services on top of both. Accessing the frontend pod will return
|
||||
environment information about itself, and a backend pod that it has
|
||||
accessed through the service. The goal is to illuminate the
|
||||
environment metadata available to running containers inside the
|
||||
Kubernetes cluster. The documentation for the kubernetes environment
|
||||
Kubernetes cluster. The documentation for the Kubernetes environment
|
||||
is [here](../../../docs/user-guide/container-environment.md).
|
||||
|
||||

|
||||
@@ -102,7 +102,7 @@ First the frontend pod's information is printed. The pod name and
|
||||
[namespace](../../../docs/design/namespaces.md) are retreived from the
|
||||
[Downward API](../../../docs/user-guide/downward-api.md). Next, `USER_VAR` is the name of
|
||||
an environment variable set in the [pod
|
||||
definition](show-rc.yaml). Then, the dynamic kubernetes environment
|
||||
definition](show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
service, named `backend-srv`. Finally, the frontend pod queries the
|
||||
backend service and prints the information returned. Again the backend
|
||||
|
@@ -35,7 +35,7 @@ Documentation for other releases can be found at
|
||||
|
||||
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/).
|
||||
|
||||
You create your Docker image and push it to a registry before referring to it in a kubernetes pod.
|
||||
You create your Docker image and push it to a registry before referring to it in a Kubernetes pod.
|
||||
|
||||
The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags.
|
||||
|
||||
@@ -267,7 +267,7 @@ common use cases and suggested solutions.
|
||||
- may be hosted on the [Docker Hub](https://hub.docker.com/account/signup/), or elsewhere.
|
||||
- manually configure .dockercfg on each node as described above
|
||||
- Or, run an internal private registry behind your firewall with open read access.
|
||||
- no kubernetes configuration required
|
||||
- no Kubernetes configuration required
|
||||
- Or, when on GCE/GKE, use the project's Google Container Registry.
|
||||
- will work better with cluster autoscaling than manual node configuration
|
||||
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
|
||||
|
@@ -68,7 +68,7 @@ These are just examples; you are free to develop your own conventions.
|
||||
## Syntax and character set
|
||||
|
||||
_Labels_ are key value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
|
||||
If the prefix is omitted, the label key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. The `kubernetes.io/` prefix is reserved for kubernetes core components.
|
||||
If the prefix is omitted, the label key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. The `kubernetes.io/` prefix is reserved for Kubernetes core components.
|
||||
|
||||
Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
|
||||
|
||||
|
@@ -115,7 +115,7 @@ running in containers. The guide [Collecting log files within containers with Fl
|
||||
|
||||
## Known issues
|
||||
|
||||
Kubernetes does log rotation for kubernetes components and docker containers. The command `kubectl logs` currently only read the latest logs, not all historical ones.
|
||||
Kubernetes does log rotation for Kubernetes components and docker containers. The command `kubectl logs` currently only read the latest logs, not all historical ones.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
@@ -59,13 +59,13 @@ The Kubelet acts as a bridge between the Kubernetes master and the nodes. It man
|
||||
|
||||
### InfluxDB and Grafana
|
||||
|
||||
A Grafana setup with InfluxDB is a very popular combination for monitoring in the open source world. InfluxDB exposes an easy to use API to write and fetch time series data. Heapster is setup to use this storage backend by default on most kubernetes clusters. A detailed setup guide can be found [here](https://github.com/GoogleCloudPlatform/heapster/blob/master/docs/influxdb.md). InfluxDB and Grafana run in Pods. The pod exposes itself as a Kubernetes service which is how Heapster discovers it.
|
||||
A Grafana setup with InfluxDB is a very popular combination for monitoring in the open source world. InfluxDB exposes an easy to use API to write and fetch time series data. Heapster is setup to use this storage backend by default on most Kubernetes clusters. A detailed setup guide can be found [here](https://github.com/GoogleCloudPlatform/heapster/blob/master/docs/influxdb.md). InfluxDB and Grafana run in Pods. The pod exposes itself as a Kubernetes service which is how Heapster discovers it.
|
||||
|
||||
The Grafana container serves Grafana’s UI which provides an easy to configure dashboard interface. The default dashboard for Kubernetes contains an example dashboard that monitors resource usage of the cluster and the pods inside of it. This dashboard can easily be customized and expanded. Take a look at the storage schema for InfluxDB [here](https://github.com/GoogleCloudPlatform/heapster/blob/master/docs/storage-schema.md#metrics).
|
||||
|
||||
Here is a video showing how to monitor a kubernetes cluster using heapster, InfluxDB and Grafana:
|
||||
Here is a video showing how to monitor a Kubernetes cluster using heapster, InfluxDB and Grafana:
|
||||
|
||||
[](http://www.youtube.com/watch?v=SZgqjMrxo3g)
|
||||
[](http://www.youtube.com/watch?v=SZgqjMrxo3g)
|
||||
|
||||
Here is a snapshot of the default Kubernetes Grafana dashboard that shows the CPU and Memory usage of the entire cluster, individual pods and containers:
|
||||
|
||||
|
@@ -37,7 +37,7 @@ This example shows how to assign a [pod](../pods.md) to a specific [node](../../
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes that you have a basic understanding of kubernetes pods and that you have [turned up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#documentation).
|
||||
This example assumes that you have a basic understanding of Kubernetes pods and that you have [turned up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#documentation).
|
||||
|
||||
### Step One: Attach label to the node
|
||||
|
||||
|
@@ -522,7 +522,7 @@ Pod level](#use-case-two-containers).
|
||||
run a pod which exposes the secret.
|
||||
If multiple replicas of etcd are run, then the secrets will be shared between them.
|
||||
By default, etcd does not secure peer-to-peer communication with SSL/TLS, though this can be configured.
|
||||
- It is not possible currently to control which users of a kubernetes cluster can
|
||||
- It is not possible currently to control which users of a Kubernetes cluster can
|
||||
access a secret. Support for this is planned.
|
||||
- Currently, anyone with root on any node can read any secret from the apiserver,
|
||||
by impersonating the kubelet. It is a planned feature to only send secrets to
|
||||
|
@@ -33,7 +33,7 @@ Documentation for other releases can be found at
|
||||
|
||||
# Sharing Cluster Access
|
||||
|
||||
Client access to a running kubernetes cluster can be shared by copying
|
||||
Client access to a running Kubernetes cluster can be shared by copying
|
||||
the `kubectl` client config bundle ([.kubeconfig](kubeconfig-file.md)).
|
||||
This config bundle lives in `$HOME/.kube/config`, and is generated
|
||||
by `cluster/kube-up.sh`. Sample steps for sharing `kubeconfig` below.
|
||||
|
@@ -55,7 +55,7 @@ The Kubernetes UI can be used to introspect your current cluster, such as checki
|
||||
### Node Resource Usage
|
||||
|
||||
After accessing Kubernetes UI, you'll see a homepage dynamically listing out all nodes in your current cluster, with related information including internal IP addresses, CPU usage, memory usage, and file systems usage.
|
||||

|
||||

|
||||
|
||||
### Dashboard Views
|
||||
|
||||
@@ -64,18 +64,18 @@ Click on the "Views" button in the top-right of the page to see other views avai
|
||||
#### Explore View
|
||||
|
||||
The "Explore" view allows your to see the pods, replication controllers, and services in current cluster easily.
|
||||

|
||||

|
||||
The "Group by" dropdown list allows you to group these resources by a number of factors, such as type, name, host, etc.
|
||||

|
||||

|
||||
You can also create filters by clicking on the down triangle of any listed resource instances and choose which filters you want to add.
|
||||

|
||||

|
||||
To see more details of each resource instance, simply click on it.
|
||||

|
||||

|
||||
|
||||
### Other Views
|
||||
|
||||
Other views (Pods, Nodes, Replication Controllers, Services, and Events) simply list information about each type of resource. You can also click on any instance for more details.
|
||||

|
||||

|
||||
|
||||
## More Information
|
||||
|
||||
|
@@ -220,7 +220,7 @@ For more information, see [Services](../services.md).
|
||||
|
||||
## Health Checking
|
||||
|
||||
When I write code it never crashes, right? Sadly the [kubernetes issues list](https://github.com/GoogleCloudPlatform/kubernetes/issues) indicates otherwise...
|
||||
When I write code it never crashes, right? Sadly the [Kubernetes issues list](https://github.com/GoogleCloudPlatform/kubernetes/issues) indicates otherwise...
|
||||
|
||||
Rather than trying to write bug-free code, a better approach is to use a management system to perform periodic health checking
|
||||
and repair of your application. That way, a system, outside of your application itself, is responsible for monitoring the
|
||||
|
@@ -36,7 +36,7 @@ Documentation for other releases can be found at
|
||||
*This document is aimed at users who have worked through some of the examples,
|
||||
and who want to learn more about using kubectl to manage resources such
|
||||
as pods and services. Users who want to access the REST API directly,
|
||||
and developers who want to extend the kubernetes API should
|
||||
and developers who want to extend the Kubernetes API should
|
||||
refer to the [api conventions](../devel/api-conventions.md) and
|
||||
the [api document](../api.md).*
|
||||
|
||||
|
Reference in New Issue
Block a user