Merge pull request #11452 from thockin/docs-munge-headerlines
Munge headerlines
This commit is contained in:
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications
|
||||
|
||||
**Table of Contents**
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# User Guide to Accessing the Cluster
|
||||
|
||||
**Table of Contents**
|
||||
@@ -55,7 +56,9 @@ Documentation for other releases can be found at
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Accessing the cluster API
|
||||
|
||||
### Accessing for the first time with kubectl
|
||||
|
||||
When accessing the Kubernetes API for the first time, we suggest using the
|
||||
kubernetes CLI, `kubectl`.
|
||||
|
||||
@@ -74,6 +77,7 @@ Many of the [examples](../../examples/) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](kubectl/kubectl.md).
|
||||
|
||||
### 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:
|
||||
@@ -112,6 +116,7 @@ $ curl http://localhost:8080/api/
|
||||
```
|
||||
|
||||
#### Without kubectl proxy
|
||||
|
||||
It is also possible to avoid using kubectl proxy by passing an authentication token
|
||||
directly to the apiserver, like this:
|
||||
|
||||
@@ -176,6 +181,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
|
||||
[nodes](../admin/node.md), [pods](pods.md) and [services](services.md) all have
|
||||
@@ -184,6 +190,7 @@ routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
||||
### Ways to connect
|
||||
|
||||
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
|
||||
@@ -233,12 +240,14 @@ at `https://104.197.5.247/api/v1/proxy/namespaces/default/services/elasticsearch
|
||||
(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
|
||||
|
||||
#### Manually constructing apiserver proxy URLs
|
||||
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you simply append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/`*`service_path`*`/`*`service_name`*`/`*`service_endpoint-suffix-parameter`*
|
||||
<!--- TODO: update this part of doc because it doesn't seem to be valid. What
|
||||
about namespaces? 'proxy' verb? -->
|
||||
|
||||
##### Examples
|
||||
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/proxy/namespaces/default/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/default/services/elasticsearch-logging/_cluster/health?pretty=true`
|
||||
|
||||
@@ -258,6 +267,7 @@ about namespaces? 'proxy' verb? -->
|
||||
```
|
||||
|
||||
#### 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:
|
||||
- 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.
|
||||
@@ -265,9 +275,11 @@ You may be able to put an apiserver proxy url into the address bar of a browser.
|
||||
way that is unaware of the proxy path prefix.
|
||||
|
||||
## Requesting redirects
|
||||
|
||||
The redirect capabilities have been deprecated and removed. Please use a proxy (see below) instead.
|
||||
|
||||
## So Many Proxies
|
||||
|
||||
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
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Annotations
|
||||
|
||||
We have [labels](labels.md) for identifying metadata.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Application Troubleshooting
|
||||
|
||||
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
|
||||
@@ -55,9 +56,11 @@ This is *not* a guide for people who want to debug their cluster. For that you
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## FAQ
|
||||
|
||||
Users are highly encouraged to check out our [FAQ](https://github.com/GoogleCloudPlatform/kubernetes/wiki/User-FAQ)
|
||||
|
||||
## Diagnosing the problem
|
||||
|
||||
The first step in troubleshooting is triage. What is the problem? Is it your Pods, your Replication Controller or
|
||||
your Service?
|
||||
* [Debugging Pods](#debugging-pods)
|
||||
@@ -65,6 +68,7 @@ your Service?
|
||||
* [Debugging Services](#debugging-services)
|
||||
|
||||
### Debugging Pods
|
||||
|
||||
The first step in debugging a Pod is taking a look at it. Check the current state of the Pod and recent events with the following command:
|
||||
|
||||
```sh
|
||||
@@ -76,6 +80,7 @@ Look at the state of the containers in the pod. Are they all ```Running```? Ha
|
||||
Continue debugging depending on the state of the pods.
|
||||
|
||||
#### My pod stays pending
|
||||
|
||||
If a Pod is stuck in ```Pending``` it means that it can not be scheduled onto a node. Generally this is because
|
||||
there are insufficient resources of one type or another that prevent scheduling. Look at the output of the
|
||||
```kubectl describe ...``` command above. There should be messages from the scheduler about why it can not schedule
|
||||
@@ -90,6 +95,7 @@ scheduled. In most cases, ```hostPort``` is unnecessary, try using a Service ob
|
||||
|
||||
|
||||
#### My pod stays waiting
|
||||
|
||||
If a Pod is stuck in the ```Waiting``` state, then it has been scheduled to a worker node, but it can't run on that machine.
|
||||
Again, the information from ```kubectl describe ...``` should be informative. The most common cause of ```Waiting``` pods is a failure to pull the image. There are three things to check:
|
||||
* Make sure that you have the name of the image correct
|
||||
@@ -131,6 +137,7 @@ but this should generally not be necessary given tools in the Kubernetes API. Th
|
||||
feature request on GitHub describing your use case and why these tools are insufficient.
|
||||
|
||||
### Debugging Replication Controllers
|
||||
|
||||
Replication controllers are fairly straightforward. They can either create Pods or they can't. If they can't
|
||||
create pods, then please refer to the [instructions above](#debugging-pods) to debug your pods.
|
||||
|
||||
@@ -138,6 +145,7 @@ You can also use ```kubectl describe rc ${CONTROLLER_NAME}``` to introspect even
|
||||
controller.
|
||||
|
||||
### Debugging Services
|
||||
|
||||
Services provide load balancing across a set of pods. There are several common problems that can make Services
|
||||
not work properly. The following instructions should help debug Service problems.
|
||||
|
||||
@@ -154,6 +162,7 @@ For example, if your Service is for an nginx container with 3 replicas, you woul
|
||||
IP addresses in the Service's endpoints.
|
||||
|
||||
#### My service is missing endpoints
|
||||
|
||||
If you are missing endpoints, try listing pods using the labels that Service uses. Imagine that you have
|
||||
a Service where the labels are:
|
||||
|
||||
@@ -180,6 +189,7 @@ selected don't have that port listed, then they won't be added to the endpoints
|
||||
Verify that the pod's ```containerPort``` matches up with the Service's ```containerPort```
|
||||
|
||||
#### Network traffic is not forwarded
|
||||
|
||||
If you can connect to the service, but the connection is immediately dropped, and there are endpoints
|
||||
in the endpoints list, it's likely that the proxy can't contact your pods.
|
||||
|
||||
@@ -190,6 +200,7 @@ check:
|
||||
* Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the ```containerPort``` field needs to be 8080.
|
||||
|
||||
#### More information
|
||||
|
||||
If none of the above solves your problem, follow the instructions in [Debugging Service document](debugging-services.md) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
|
||||
|
||||
You may also visit [troubleshooting document](../troubleshooting.md) for more information.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Compute Resources
|
||||
|
||||
** Table of Contents**
|
||||
@@ -150,6 +151,7 @@ then pod resource usage can be retrieved from the monitoring system.
|
||||
## Troubleshooting
|
||||
|
||||
### My pods are pending with event message failedScheduling
|
||||
|
||||
If the scheduler cannot find any node where a pod can fit, then the pod will remain unscheduled
|
||||
until a place can be found. An event will be produced each time the scheduler fails to find a
|
||||
place for the pod, like this:
|
||||
@@ -177,6 +179,7 @@ to limit the total amount of resources that can be consumed. If used in conjunc
|
||||
with namespaces, it can prevent one team from hogging all the resources.
|
||||
|
||||
### My container is terminated
|
||||
|
||||
Your container may be terminated because it's resource-starved. To check if a container is being killed because it is hitting a resource limit, call `kubectl describe pod`
|
||||
on the pod you are interested in:
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Tips and tricks when working with config
|
||||
|
||||
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.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Configuring and launching containers
|
||||
|
||||
**Table of Contents**
|
||||
@@ -178,6 +179,7 @@ hello world
|
||||
```
|
||||
|
||||
## Deleting pods
|
||||
|
||||
When you’re done looking at the output, you should delete the pod:
|
||||
|
||||
```bash
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Connecting applications
|
||||
|
||||
**Table of Contents**
|
||||
@@ -162,6 +163,7 @@ You should now be able to curl the nginx Service on `10.0.116.146:80` from any n
|
||||
Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [kube-dns cluster addon](../../cluster/addons/dns/README.md).
|
||||
|
||||
### Environment Variables
|
||||
|
||||
When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods:
|
||||
|
||||
```shell
|
||||
@@ -187,6 +189,7 @@ NGINXSVC_SERVICE_PORT=80
|
||||
```
|
||||
|
||||
### DNS
|
||||
|
||||
Kubernetes offers a DNS cluster addon Service that uses skydns to automatically assign dns names to other Services. You can check if it’s running on your cluster:
|
||||
|
||||
```shell
|
||||
|
@@ -30,7 +30,8 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
#Connecting to applications: kubectl port-forward
|
||||
|
||||
# Connecting to applications: kubectl port-forward
|
||||
|
||||
kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward.md). Compared to [kubectl proxy](accessing-the-cluster.md#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.
|
||||
|
||||
@@ -51,6 +52,7 @@ redis-master 2/2 Running 0 41s
|
||||
|
||||
|
||||
## Connecting to the Redis master[a]
|
||||
|
||||
The Redis master is listening on port 6397, to verify this,
|
||||
|
||||
```
|
||||
|
@@ -30,11 +30,14 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
#Connecting to applications: kubectl proxy and apiserver proxy
|
||||
|
||||
# Connecting to applications: kubectl proxy and apiserver proxy
|
||||
|
||||
You have seen the [basics](accessing-the-cluster.md) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui.md)) running on the Kubernetes cluster from your workstation.
|
||||
|
||||
|
||||
##Getting the apiserver proxy URL of kube-ui
|
||||
## Getting the apiserver proxy URL of kube-ui
|
||||
|
||||
kube-ui is deployed as a cluster add-on. To find its apiserver proxy URL,
|
||||
|
||||
```
|
||||
@@ -45,7 +48,8 @@ KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system
|
||||
if this command does not find the URL, try the steps [here](ui.md#accessing-the-ui).
|
||||
|
||||
|
||||
##Connecting to the kube-ui service from your local workstation
|
||||
## Connecting to the kube-ui service from your local workstation
|
||||
|
||||
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.
|
||||
|
||||
```
|
||||
|
@@ -51,6 +51,7 @@ Documentation for other releases can be found at
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
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.
|
||||
|
||||
This cluster information makes it possible to build applications that are *cluster aware*.
|
||||
@@ -62,14 +63,17 @@ Another important part of the container environment is the file system that is a
|
||||
The following sections describe both the cluster information provided to containers, as well as the hooks and life-cycle that allows containers to interact with the management system.
|
||||
|
||||
## Cluster Information
|
||||
|
||||
There are two types of information that are available within the container environment. There is information about the container itself, and there is information about other objects in the system.
|
||||
|
||||
### Container Information
|
||||
|
||||
Currently, the only information about the container that is available to the container is the Pod name for the pod in which the container is running. This ID is set as the hostname of the container, and is accessible through all calls to access the hostname within the container (e.g. the hostname command, or the [gethostname][1] function call in libc). Additionally, user-defined environment variables from the pod definition, are also available to the container, as are any environment variables specified statically in the Docker image.
|
||||
|
||||
In the future, we anticipate expanding this information with richer information about the container. Examples include available memory, number of restarts, and in general any state that you could get from the call to GET /pods on the API server.
|
||||
|
||||
### Cluster Information
|
||||
|
||||
Currently the list of all services that are running at the time when the container was created via the Kubernetes Cluster API are available to the container as environment variables. The set of environment variables matches the syntax of Docker links.
|
||||
|
||||
For a service named **foo** that maps to a container port named **bar**, the following variables are defined:
|
||||
@@ -82,11 +86,13 @@ FOO_SERVICE_PORT=<the port the service is running on>
|
||||
Services have dedicated IP address, and are also surfaced to the container via DNS (If [DNS addon](../../cluster/addons/dns/) is enabled). Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery.
|
||||
|
||||
## Container Hooks
|
||||
|
||||
*NB*: Container hooks are under active development, we anticipate adding additional hooks as the Kubernetes container management system evolves.*
|
||||
|
||||
Container hooks provide information to the container about events in its management lifecycle. For example, immediately after a container is started, it receives a *PostStart* hook. These hooks are broadcast *into* the container with information about the life-cycle of the container. They are different from the events provided by Docker and other systems which are *output* from the container. Output events provide a log of what has already happened. Input hooks provide real-time notification about things that are happening, but no historical log.
|
||||
|
||||
### Hook Details
|
||||
|
||||
There are currently two container hooks that are surfaced to containers, and two proposed hooks:
|
||||
|
||||
*PreStart - ****Proposed***
|
||||
@@ -115,11 +121,13 @@ Eventually, user specified reasons may be [added to the API](https://github.com/
|
||||
|
||||
|
||||
### Hook Handler Execution
|
||||
|
||||
When a management hook occurs, the management system calls into any registered hook handlers in the container for that hook. These hook handler calls are synchronous in the context of the pod containing the container. Note:this means that hook handler execution blocks any further management of the pod. If your hook handler blocks, no other management (including [health checks](production-pods.md#liveness-and-readiness-probes-aka-health-checks)) will occur until the hook handler completes. Blocking hook handlers do *not* affect management of other Pods. Typically we expect that users will make their hook handlers as lightweight as possible, but there are cases where long running commands make sense (e.g. saving state prior to container stop)
|
||||
|
||||
For hooks which have parameters, these parameters are passed to the event handler as a set of key/value pairs. The details of this parameter passing is handler implementation dependent (see below).
|
||||
|
||||
### Hook delivery guarantees
|
||||
|
||||
Hook delivery is "at least one", which means that a hook may be called multiple times for any given event (e.g. "start" or "stop") and it is up to the hook implementer to be able to handle this
|
||||
correctly.
|
||||
|
||||
@@ -128,6 +136,7 @@ We expect double delivery to be rare, but in some cases if the ```kubelet``` res
|
||||
Likewise, we only make a single delivery attempt. If (for example) an http hook receiver is down, and unable to take traffic, we do not make any attempts to resend.
|
||||
|
||||
### Hook Handler Implementations
|
||||
|
||||
Hook handlers are the way that hooks are surfaced to containers. Containers can select the type of hook handler they would like to implement. Kubernetes currently supports two different hook handler types:
|
||||
|
||||
* Exec - Executes a specific command (e.g. pre-stop.sh) inside the cgroup and namespaces of the container. Resources consumed by the command are counted against the container. Commands which print "ok" to standard out (stdout) are treated as healthy, any other output is treated as container failures (and will cause kubelet to forcibly restart the container). Parameters are passed to the command as traditional linux command line flags (e.g. pre-stop.sh --reason=HEALTH)
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Containers with Kubernetes
|
||||
|
||||
## Containers and commands
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# My Service is not working - how to debug
|
||||
|
||||
An issue that comes up rather frequently for new installations of Kubernetes is
|
||||
@@ -551,6 +552,7 @@ Contact us on
|
||||
[GitHub](https://github.com/GoogleCloudPlatform/kubernetes).
|
||||
|
||||
## More information
|
||||
|
||||
Visit [troubleshooting document](../troubleshooting.md) for more information.
|
||||
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Deploying continuously running applications
|
||||
|
||||
**Table of Contents**
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# 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.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Downward API
|
||||
|
||||
It is sometimes useful for a container to have information about itself, but we
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Downward API example
|
||||
|
||||
Following this example, you will create a pod with a containers that consumes the pod's name and
|
||||
|
@@ -33,7 +33,8 @@ Documentation for other releases can be found at
|
||||
#Getting into containers: kubectl exec
|
||||
Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases.
|
||||
|
||||
##Using kubectl exec to check the environment variables of a container
|
||||
## Using kubectl exec to check the environment variables of a container
|
||||
|
||||
Kubernetes exposes [services](services.md#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`.
|
||||
|
||||
|
||||
@@ -66,6 +67,7 @@ We can use these environment variables in applications to find the service.
|
||||
|
||||
|
||||
## Using kubectl exec to check the mounted volumes
|
||||
|
||||
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,
|
||||
|
||||
@@ -89,6 +91,7 @@ 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
|
||||
|
||||
```
|
||||
|
@@ -30,15 +30,19 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Identifiers
|
||||
|
||||
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
|
||||
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](labels.md) and [annotations](annotations.md).
|
||||
|
||||
## Names
|
||||
|
||||
Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name. Names are the used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions. See the [identifiers design doc](../design/identifiers.md) for the precise syntax rules for names.
|
||||
|
||||
## UIDs
|
||||
|
||||
UID are generated by Kubernetes. Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique).
|
||||
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Images
|
||||
|
||||
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/).
|
||||
@@ -252,6 +253,7 @@ You can use this in conjunction with a per-node `.dockerfile`. The credentials
|
||||
will be merged. This approach will work on Google Container Engine (GKE).
|
||||
|
||||
### Use Cases
|
||||
|
||||
There are a number of solutions for configuring private registries. Here are some
|
||||
common use cases and suggested solutions.
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Application Introspection and Debugging
|
||||
|
||||
Once your application is running, you’ll inevitably need to debug problems with it.
|
||||
|
@@ -30,12 +30,15 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# kubeconfig files
|
||||
|
||||
In order to easily switch between multiple clusters, a kubeconfig file was defined. This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
||||
|
||||
Multiple kubeconfig files are allowed. At runtime they are loaded and merged together along with override options specified from the command line (see rules below).
|
||||
|
||||
## Related discussion
|
||||
|
||||
https://github.com/GoogleCloudPlatform/kubernetes/issues/1755
|
||||
|
||||
## Example kubeconfig file
|
||||
@@ -81,6 +84,7 @@ users:
|
||||
```
|
||||
|
||||
## 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:
|
||||
1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules:
|
||||
|
||||
@@ -115,6 +119,7 @@ The rules for loading and merging the kubeconfig files are straightforward, but
|
||||
1. For any information still missing, use default values and potentially prompt for authentication information
|
||||
|
||||
## 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.
|
||||
See [kubectl/kubectl_config.md](kubectl/kubectl_config.md) for help.
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl
|
||||
|
||||
kubectl controls the Kubernetes cluster manager
|
||||
@@ -76,6 +77,7 @@ kubectl
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl api-versions](kubectl_api-versions.md) - Print available API versions.
|
||||
* [kubectl cluster-info](kubectl_cluster-info.md) - Display cluster info
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl api-versions
|
||||
|
||||
Print available API versions.
|
||||
@@ -79,6 +80,7 @@ kubectl api-versions
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959722426 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl cluster-info
|
||||
|
||||
Display cluster info
|
||||
@@ -79,6 +80,7 @@ kubectl cluster-info
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959601452 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config
|
||||
|
||||
config modifies kubeconfig files
|
||||
@@ -85,6 +86,7 @@ kubectl config SUBCOMMAND
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
* [kubectl config set](kubectl_config_set.md) - Sets an individual value in a kubeconfig file
|
||||
* [kubectl config set-cluster](kubectl_config_set-cluster.md) - Sets a cluster entry in kubeconfig
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config set-cluster
|
||||
|
||||
Sets a cluster entry in kubeconfig
|
||||
@@ -94,6 +95,7 @@ $ kubectl config set-cluster e2e --insecure-skip-tls-verify=true
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.95861887 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config set-context
|
||||
|
||||
Sets a context entry in kubeconfig
|
||||
@@ -87,6 +88,7 @@ $ kubectl config set-context gce --user=cluster-admin
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.958911281 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config set-credentials
|
||||
|
||||
Sets a user entry in kubeconfig
|
||||
@@ -107,6 +108,7 @@ $ kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admi
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.958785654 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config set
|
||||
|
||||
Sets an individual value in a kubeconfig file
|
||||
@@ -81,6 +82,7 @@ kubectl config set PROPERTY_NAME PROPERTY_VALUE
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959031072 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config unset
|
||||
|
||||
Unsets an individual value in a kubeconfig file
|
||||
@@ -80,6 +81,7 @@ kubectl config unset PROPERTY_NAME
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959148086 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config use-context
|
||||
|
||||
Sets the current-context in a kubeconfig file
|
||||
@@ -79,6 +80,7 @@ kubectl config use-context CONTEXT_NAME
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959263442 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl config view
|
||||
|
||||
displays Merged kubeconfig settings or a specified kubeconfig file.
|
||||
@@ -99,6 +100,7 @@ $ kubectl config view -o template --template='{{range .users}}{{ if eq .name "e2
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.958490153 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl create
|
||||
|
||||
Create a resource by filename or stdin
|
||||
@@ -92,6 +93,7 @@ $ cat pod.json | kubectl create -f -
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 22:39:16.132575015 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl delete
|
||||
|
||||
Delete a resource by filename, stdin, resource and name, or by resources and label selector.
|
||||
@@ -114,6 +115,7 @@ $ kubectl delete pods --all
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 05:13:00.190175769 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl describe
|
||||
|
||||
Show details of a specific resource or group of resources
|
||||
@@ -110,6 +111,7 @@ $ kubectl describe pods frontend
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 08:21:33.374469932 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl exec
|
||||
|
||||
Execute a command in a container.
|
||||
@@ -97,6 +98,7 @@ $ kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956874128 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl expose
|
||||
|
||||
Take a replicated application and expose it as Kubernetes Service
|
||||
@@ -113,6 +114,7 @@ $ kubectl expose rc streamer --port=4100 --protocol=udp --name=video-stream
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-17 01:17:57.020108348 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl get
|
||||
|
||||
Display one or many resources
|
||||
@@ -121,6 +122,7 @@ $ kubectl get rc/web service/frontend pods/web-pod-13je7
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.955450097 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl label
|
||||
|
||||
Update the labels on a resource
|
||||
@@ -111,6 +112,7 @@ $ kubectl label pods foo bar-
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.958329854 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl logs
|
||||
|
||||
Print the logs for a container in a pod.
|
||||
@@ -96,6 +97,7 @@ $ kubectl logs -f 123456-7890 ruby-container
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956443079 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl namespace
|
||||
|
||||
SUPERCEDED: Set and view the current Kubernetes namespace
|
||||
@@ -82,6 +83,7 @@ kubectl namespace [namespace]
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956297427 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl patch
|
||||
|
||||
Update field(s) of a resource by stdin.
|
||||
@@ -90,6 +91,7 @@ kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956026887 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl port-forward
|
||||
|
||||
Forward one or more local ports to a pod.
|
||||
@@ -97,6 +98,7 @@ $ kubectl port-forward -p mypod 0:5000
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.957000233 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl proxy
|
||||
|
||||
Run a proxy to the Kubernetes API server
|
||||
@@ -114,6 +115,7 @@ $ kubectl proxy --api-prefix=/k8s-api
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.957150329 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl replace
|
||||
|
||||
Replace a resource by filename or stdin.
|
||||
@@ -99,6 +100,7 @@ kubectl replace --force -f ./pod.json
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 22:39:16.132838722 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl rolling-update
|
||||
|
||||
Perform a rolling update of the given ReplicationController.
|
||||
@@ -113,6 +114,7 @@ $ kubectl rolling-update frontend --image=image:v2
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956605022 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl run
|
||||
|
||||
Run a particular image on the cluster.
|
||||
@@ -108,6 +109,7 @@ $ kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { .
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.957298888 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl scale
|
||||
|
||||
Set a new size for a Replication Controller.
|
||||
@@ -97,6 +98,7 @@ $ kubectl scale --current-replicas=2 --replicas=3 replicationcontrollers foo
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.956739933 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl stop
|
||||
|
||||
Gracefully shut down a resource by name or filename.
|
||||
@@ -104,6 +105,7 @@ $ kubectl stop -f path/to/resources
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.957441942 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## kubectl version
|
||||
|
||||
Print the client and server version information.
|
||||
@@ -80,6 +81,7 @@ kubectl version
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.959846454 +0000 UTC
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Labels
|
||||
|
||||
_Labels_ are key/value pairs that are attached to objects, such as pods.
|
||||
|
@@ -30,7 +30,9 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## Overview
|
||||
|
||||
This example shows two types of pod [health checks](../production-pods.md#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
|
||||
The [exec-liveness.yaml](exec-liveness.yaml) demonstrates the container execution check.
|
||||
@@ -72,6 +74,7 @@ The Kubelet sends a HTTP request to the specified path and port to perform the h
|
||||
This [guide](../walkthrough/k8s201.md#health-checking) has more information on health checks.
|
||||
|
||||
## Get your hands dirty
|
||||
|
||||
To show the health check is actually working, first create the pods:
|
||||
|
||||
```
|
||||
|
@@ -30,7 +30,9 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Elasticsearch/Kibana Logging Demonstration
|
||||
|
||||
This directory contains two [pod](../../../docs/user-guide/pods.md) specifications which can be used as synthetic
|
||||
logging sources. The pod specification in [synthetic_0_25lps.yaml](synthetic_0_25lps.yaml)
|
||||
describes a pod that just emits a log message once every 4 seconds. The pod specification in
|
||||
|
@@ -30,12 +30,15 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Logging
|
||||
|
||||
## Logging by Kubernetes Components
|
||||
|
||||
Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library. Developer conventions for logging severity are described in [docs/devel/logging.md](../devel/logging.md).
|
||||
|
||||
## Examining the logs of running containers
|
||||
|
||||
The logs of a running container may be fetched using the command `kubectl logs`. For example, given
|
||||
this pod specification [counter-pod.yaml](../../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](logging-demo/).)
|
||||
@@ -95,15 +98,18 @@ $ kubectl logs kube-dns-v3-7r1l9 etcd
|
||||
```
|
||||
|
||||
## Cluster level logging to Google Cloud Logging
|
||||
|
||||
The getting started guide [Cluster Level Logging to Google Cloud Logging](../getting-started-guides/logging.md)
|
||||
explains how container logs are ingested into [Google Cloud Logging](https://cloud.google.com/logging/docs/)
|
||||
and shows how to query the ingested logs.
|
||||
|
||||
## Cluster level logging with Elasticsearch and Kibana
|
||||
|
||||
The getting started guide [Cluster Level Logging with Elasticsearch and Kibana](../getting-started-guides/logging-elasticsearch.md)
|
||||
describes how to ingest cluster level logs into Elasticsearch and view them using Kibana.
|
||||
|
||||
## Ingesting Application Log Files
|
||||
|
||||
Cluster level logging only collects the standard output and standard error output of the applications
|
||||
running in containers. The guide [Collecting log files within containers with Fluentd](../../contrib/logging/fluentd-sidecar-gcp/README.md) explains how the log files of applications can also be ingested into Google Cloud logging.
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Managing deployments
|
||||
|
||||
You’ve deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we’ll discuss in more depth are [configuration files](configuring-containers.md#configuration-in-kubernetes) and [labels](deploying-applications.md#labels).
|
||||
@@ -437,6 +438,7 @@ $ rm $TMP
|
||||
```
|
||||
|
||||
The system ensures that you don’t clobber changes made by other users or components by confirming that the `resourceVersion` doesn’t differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don’t use your original configuration file as the source since additional fields most likely were set in the live state.
|
||||
|
||||
## Disruptive updates
|
||||
|
||||
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may just want to make a recursive change immediately, such as to fix broken pods created by a replication controller. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can simply modify your original configuration file:
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Resource Usage Monitoring in Kubernetes
|
||||
|
||||
Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](pods.md), [services](services.md), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/GoogleCloudPlatform/heapster), a project meant to provide a base monitoring platform on Kubernetes.
|
||||
@@ -55,6 +56,7 @@ On most Kubernetes clusters, cAdvisor exposes a simple UI for on-machine contain
|
||||
The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from cAdvisor. It then exposes the aggregated pod resource usage statistics via a REST API.
|
||||
|
||||
## Storage Backends
|
||||
|
||||
### 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.
|
||||
@@ -82,6 +84,7 @@ Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wi
|
||||

|
||||
|
||||
## Try it out!
|
||||
|
||||
Now that you’ve learned a bit about Heapster, feel free to try it out on your own clusters! The [Heapster repository](https://github.com/GoogleCloudPlatform/heapster) is available on GitHub. It contains detailed instructions to setup Heapster and its storage backends. Heapster runs by default on most Kubernetes clusters, so you may already have it! Feedback is always welcome. Please let us know if you run into any issues. Heapster and Kubernetes developers hang out in the [#google-containers](http://webchat.freenode.net/?channels=google-containers) IRC channel on freenode.net. You can also reach us on the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers).
|
||||
|
||||
***
|
||||
|
@@ -74,6 +74,7 @@ The Namespace provides a unique scope for:
|
||||
Look [here](namespaces/) for an in depth example of namespaces.
|
||||
|
||||
### Viewing namespaces
|
||||
|
||||
You can list the current namespaces in a cluster using:
|
||||
|
||||
```sh
|
||||
@@ -187,6 +188,7 @@ kubectl delete namespaces <insert-some-namespace-name>
|
||||
This delete is asynchronous, so for a time you will see the namespace in the ```Terminating``` state.
|
||||
|
||||
## Namespaces and DNS
|
||||
|
||||
When you create a [Service](services.md), it creates a corresponding [DNS entry](../admin/dns.md)1.
|
||||
This entry is of the form ```<service-name>.<namespace-name>.cluster.local```, which means
|
||||
that if a container just uses ```<service-name>``` it will resolve to the service which
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## Kubernetes Namespaces
|
||||
|
||||
Kubernetes _[namespaces](../namespaces.md)_ help different projects, teams, or customers to share a Kubernetes cluster.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## Node selection example
|
||||
|
||||
This example shows how to assign a [pod](../pods.md) to a specific [node](../../admin/node.md) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes Overview
|
||||
|
||||
Kubernetes is an open-source system for managing containerized applications across multiple hosts in a cluster. It provides mechanisms for application deployment, scheduling, updating, maintenance, and scaling. A key feature of Kubernetes is that it actively manages the containers to ensure that the state of the cluster continually matches the user's intentions.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Persistent Volumes and Claims
|
||||
|
||||
This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](volumes.md) is suggested.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# How To Use Persistent Volumes
|
||||
|
||||
The purpose of this guide is to help you become familiar with [Kubernetes Persistent Volumes](../persistent-volumes.md). By the end of the guide, we'll have
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# The life of a pod
|
||||
|
||||
Updated: 4/14/2015
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Pods
|
||||
|
||||
In Kubernetes, rather than individual application containers, _pods_ are the smallest deployable units that can be created, scheduled, and managed.
|
||||
|
@@ -30,10 +30,13 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Prerequisites
|
||||
|
||||
To deploy and manage applications on Kubernetes, you’ll use the Kubernetes command-line tool, [kubectl](kubectl/kubectl.md). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.
|
||||
|
||||
##Install kubectl
|
||||
## Install kubectl
|
||||
|
||||
You can find it in the [release](https://github.com/GoogleCloudPlatform/kubernetes/releases) tar bundle, under platforms/<os>/<arch>;
|
||||
or if you build from source, kubectl should be either under _output/local/bin/<os>/<arch> or _output/dockerized/bin/<os>/<arch>.
|
||||
|
||||
@@ -47,7 +50,8 @@ export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
|
||||
```
|
||||
|
||||
##Configure kubectl
|
||||
## Configure kubectl
|
||||
|
||||
In order for kubectl to find and access the Kubernetes cluster, it needs a [kubeconfig file](kubeconfig-file.md), which is created automatically when creating a cluster using kube-up.sh (see the [getting started guides](../../docs/getting-started-guides/) for more about creating clusters). If you need access to a cluster you didn’t create, see the [Sharing Cluster Access document](sharing-clusters.md).
|
||||
|
||||
#### Installing Kubectl
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Working with pods and containers in production
|
||||
|
||||
**Table of Contents**
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Guide: Managing Applications: Quick start
|
||||
|
||||
**Table of Contents**
|
||||
@@ -68,7 +69,9 @@ my-nginx-q7jo3 1/1 Running 0 29m
|
||||
```
|
||||
|
||||
Kubernetes will ensure that your application keeps running, by automatically restarting containers that fail, spreading containers across nodes, and recreating containers on new nodes when nodes fail.
|
||||
|
||||
## Exposing your application to the Internet
|
||||
|
||||
Through integration with some cloud providers (for example Google Compute Engine and AWS EC2), Kubernetes enables you to request that it provision a public IP address for your application. To do this run:
|
||||
|
||||
```bash
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Replication Controller
|
||||
|
||||
**Table of Contents**
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Secrets
|
||||
|
||||
Objects of type `secret` are intended to hold sensitive information, such as
|
||||
@@ -158,7 +159,9 @@ whichever is convenient.
|
||||
See another example of creating a secret and a pod that consumes that secret in a volume [here](secrets/).
|
||||
|
||||
### Manually specifying an imagePullSecret
|
||||
|
||||
Use of imagePullSecrets is desribed in the [images documentation](images.md#specifying-imagepullsecrets-on-a-pod)
|
||||
|
||||
### Automatic use of Manually Created Secrets
|
||||
|
||||
*This feature is planned but not implemented. See [issue
|
||||
@@ -170,7 +173,9 @@ Then, pods which use that service account will have
|
||||
The secrets will be mounted at **TBD**.
|
||||
|
||||
## Details
|
||||
|
||||
### Restrictions
|
||||
|
||||
Secret volume sources are validated to ensure that the specified object
|
||||
reference actually points to an object of type `Secret`. Therefore, a secret
|
||||
needs to be created before any pods that depend on it.
|
||||
@@ -462,6 +467,7 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
|
||||
```
|
||||
|
||||
### Use-case: Secret visible to one container in a pod
|
||||
|
||||
<a name="use-case-two-containers"></a>
|
||||
|
||||
Consider a program that needs to handle HTTP requests, do some complex business
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Secrets example
|
||||
|
||||
Following this example, you will create a [secret](../secrets.md) and a [pod](../pods.md) that consumes that secret in a [volume](../volumes.md). See [Secrets design document](../../design/secrets.md) for more information.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Security Contexts
|
||||
|
||||
A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](../design/security_context.md) for more details.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Service Accounts
|
||||
|
||||
A service account provides an identity for processes that run in a Pod.
|
||||
@@ -121,6 +122,7 @@ $ kubectl delete serviceaccount/build-robot
|
||||
<!-- TODO: describe how to create a pod with no Service Account. -->
|
||||
|
||||
## Adding Secrets to a service account.
|
||||
|
||||
TODO: Test and explain how to use additional non-K8s secrets with an existing service account.
|
||||
|
||||
TODO explain:
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Services and Firewalls
|
||||
|
||||
Many cloud providers (e.g. Google Compute Engine) define firewalls that help keep prevent inadvertent
|
||||
@@ -39,6 +40,7 @@ well as any provider specific details that may be necessary.
|
||||
|
||||
|
||||
### Google Compute Engine
|
||||
|
||||
When using a Service with `spec.type: LoadBalancer`, the firewall will be
|
||||
opened automatically. When using `spec.type: NodePort`, however, the firewall
|
||||
is *not* opened by default.
|
||||
@@ -77,6 +79,7 @@ the wilds of the internet.
|
||||
This will be fixed in an upcoming release of Kubernetes.
|
||||
|
||||
### Other cloud providers
|
||||
|
||||
Coming soon.
|
||||
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Services in Kubernetes
|
||||
|
||||
**Table of Contents**
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Sharing Cluster Access
|
||||
|
||||
Client access to a running kubernetes cluster can be shared by copying
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## Running your first containers in Kubernetes
|
||||
|
||||
Ok, you've run one of the [getting started guides](../../docs/getting-started-guides/) and you have
|
||||
@@ -65,6 +66,7 @@ kubectl stop rc my-nginx
|
||||
```
|
||||
|
||||
### Exposing your pods to the internet.
|
||||
|
||||
On some platforms (for example Google Compute Engine) the kubectl command can integrate with your cloud provider to add a [public IP address](services.md#external-services) for the pods,
|
||||
to do this run:
|
||||
|
||||
@@ -81,6 +83,7 @@ kubectl get services
|
||||
In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a firewall to allow traffic on port 80.
|
||||
|
||||
### Next: Configuration files
|
||||
|
||||
Most people will eventually want to use declarative configuration files for creating/modifying their applications. A [simplified introduction](simple-yaml.md)
|
||||
is given in a different document.
|
||||
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
## Getting started with config files.
|
||||
|
||||
In addition to the imperative style commands described [elsewhere](simple-nginx.md), Kubernetes
|
||||
@@ -74,6 +75,7 @@ kubectl delete pods nginx
|
||||
```
|
||||
|
||||
### Running a replicated set of containers from a configuration file
|
||||
|
||||
To run replicated containers, you need a [Replication Controller](replication-controller.md).
|
||||
A replication controller is responsible for ensuring that a specific number of pods exist in the
|
||||
cluster.
|
||||
|
@@ -30,10 +30,13 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes User Interface
|
||||
|
||||
Kubernetes has a web-based user interface that displays the current cluster state graphically.
|
||||
|
||||
## Accessing the UI
|
||||
|
||||
By default, the Kubernetes UI is deployed as a cluster addon. To access it, visit `https://<kubernetes-master>/ui`, which redirects to `https://<kubernetes-master>/api/v1/proxy/namespaces/kube-system/services/kube-ui/#/dashboard/`.
|
||||
|
||||
If you find that you're not able to access the UI, it may be because the kube-ui service has not been started on your cluster. In that case, you can start it manually with:
|
||||
@@ -46,16 +49,20 @@ kubectl create -f cluster/addons/kube-ui/kube-ui-svc.yaml --namespace=kube-syste
|
||||
Normally, this should be taken care of automatically by the [`kube-addons.sh`](../../cluster/saltbase/salt/kube-addons/kube-addons.sh) script that runs on the master.
|
||||
|
||||
## Using the UI
|
||||
|
||||
The Kubernetes UI can be used to introspect your current cluster, such as checking how resources are used, or looking at error messages. You cannot, however, use the UI to modify your cluster.
|
||||
|
||||
### 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
|
||||
|
||||
Click on the "Views" button in the top-right of the page to see other views available, which include: Explore, Pods, Nodes, Replication Controllers, Services, and Events.
|
||||
|
||||
#### 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.
|
||||
@@ -66,10 +73,12 @@ 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
|
||||
|
||||
For more information, see the [Kubernetes UI development document](../../www/README.md) in the www directory.
|
||||
|
||||
|
||||
|
@@ -46,7 +46,9 @@ See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
-->
|
||||
|
||||
# Rolling update example
|
||||
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update.md) on a running group of [pods](../../../docs/user-guide/pods.md). See [here](../managing-deployments.md#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](../../design/simple-rolling-update.md) for more information.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
@@ -74,6 +76,7 @@ I0218 15:18:31.623279 67480 proxy.go:36] Starting to serve on localhost:8001
|
||||
Now visit the the [demo website](http://localhost:8001/static). You won't see anything much quite yet.
|
||||
|
||||
### Step Two: Run the replication controller
|
||||
|
||||
Now we will turn up two replicas of an [image](../images.md). They all serve on internal port 80.
|
||||
|
||||
```bash
|
||||
@@ -93,6 +96,7 @@ $ kubectl scale rc update-demo-nautilus --replicas=4
|
||||
If you go back to the [demo website](http://localhost:8001/static/index.html) you should eventually see four boxes, one for each pod.
|
||||
|
||||
### Step Four: Update the docker image
|
||||
|
||||
We will now update the docker image to serve a different image by doing a rolling update to a new Docker image.
|
||||
|
||||
```bash
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Volumes
|
||||
|
||||
On-disk files in a container are ephemeral, which presents some problems for
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes 101 - Kubectl CLI and Pods
|
||||
|
||||
For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers
|
||||
@@ -60,6 +61,7 @@ For more info about kubectl, including its usage, commands, and parameters, see
|
||||
If you haven't installed and configured kubectl, finish the [prerequisites](../prereqs.md) before continuing.
|
||||
|
||||
## Pods
|
||||
|
||||
In Kubernetes, a group of one or more containers is called a _pod_. Containers in a pod are deployed together, and are started, stopped, and replicated as a group.
|
||||
|
||||
See [pods](../../../docs/user-guide/pods.md) for more details.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Kubernetes 201 - Labels, Replication Controllers, Services and Health Checking
|
||||
|
||||
If you went through [Kubernetes 101](README.md), you learned about kubectl, pods, volumes, and multiple containers.
|
||||
|
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
# Working with Resources
|
||||
|
||||
*This document is aimed at users who have worked through some of the examples,
|
||||
@@ -40,6 +41,7 @@ refer to the [api conventions](../devel/api-conventions.md) and
|
||||
the [api document](../api.md).*
|
||||
|
||||
## Resources are Automatically Modified
|
||||
|
||||
When you create a resource such as pod, and then retrieve the created
|
||||
resource, a number of the fields of the resource are added.
|
||||
You can see this at work in the following example:
|
||||
@@ -78,6 +80,7 @@ The system adds fields in several ways:
|
||||
The API will generally not modify fields that you have set; it just sets ones which were unspecified.
|
||||
|
||||
## <a name="finding_schema_docs"></a>Finding Documentation on Resource Fields
|
||||
|
||||
You can browse auto-generated API documentation at the [project website](http://kubernetes.io/third_party/swagger-ui/) or directly from your cluster, like this:
|
||||
- Run `kubectl proxy --api-prefix=/`
|
||||
- Go to `http://localhost:8001/swagger-ui` in your browser.
|
||||
|
Reference in New Issue
Block a user