kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #2289 from steveperry-53/user-guide-to-tasks 

Remove 3 User Guide topics, redirect to Tasks.
pull/2184/merge
Steve Perry 2017-01-18 15:45:39 -08:00 committed by GitHub
parent b4eb739023 ee02a66f12
commit 8ac30e7b35
5 changed files with 6 additions and 320 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
_data/guides.yml
View File

@ -65,11 +65,8 @@ toc:
- title: Containers and Pods
section:
- docs/user-guide/simple-nginx.md
- docs/user-guide/pods/single-container.md
- docs/user-guide/pods/multi-container.md
- docs/user-guide/pods/init-container.md
- docs/user-guide/configuring-containers.md
- docs/user-guide/pod-templates.md
- docs/user-guide/containers.md
- docs/user-guide/environment-guide/index.md

6
docs/tasks/index.md
View File

@ -3,6 +3,12 @@ title: Tasks
redirect_from:
- "/docs/user-guide/production-pods/"
- "/docs/user-guide/production-pods.html"
- "/docs/user-guide/simple-nginx/"
- "/docs/user-guide/simple-nginx.html"
- "/docs/user-guide/pods/single-container/"
- "/docs/user-guide/pods/single-container.html"
- "/docs/user-guide/configuring-containers/"
- "/docs/user-guide/configuring-containers.html"
---
This section of the Kubernetes documentation contains pages that

162
docs/user-guide/configuring-containers.md
View File

@ -1,162 +0,0 @@
---
assignees:
- caesarxuchao
- thockin
title: Configuring Containers
---
* TOC
{:toc}
## Configuration in Kubernetes
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](/docs/user-guide/quick-start), Kubernetes supports declarative configuration. Oftentimes, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
In the declarative style, all configuration is stored in YAML or JSON configuration files using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently `v1`?), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation.
## Launching a container using a configuration file
Kubernetes executes containers in [*Pods*](/docs/user-guide/pods). A pod containing a simple Hello World container can be specified in YAML as follows:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-world
spec: # specification of the pod's contents
restartPolicy: Never
containers:
- name: hello
image: "ubuntu:14.04"
command: ["/bin/echo", "hello", "world"]
```
The value of `metadata.name`, `hello-world`, will be the name of the pod resource created, and must be unique within the cluster, whereas `containers[0].name` is just a nickname for the container within that pod. `image` is the name of the Docker image, which Kubernetes expects to be able to pull from a registry, the [Docker Hub](https://registry.hub.docker.com/) by default.
`restartPolicy: Never` indicates that we just want to run the container once and then terminate the pod.
The [`command`](/docs/user-guide/containers/#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows:
```yaml
command: ["/bin/echo"]
args: ["hello","world"]
```
This pod can be created using the `create` command:
```shell
$ kubectl create -f ./hello-world.yaml
pods/hello-world
```
`kubectl` prints the resource type and name of the resource created when successful.
## Validating configuration
We enable validation by default in `kubectl` since v1.1.
Let's say you specified `entrypoint` instead of `command`. You'd see output as follows:
```shell
error validating "./hello-world.yaml": error validating data: found invalid field Entrypoint for v1.Container; if you choose to ignore these errors, turn validation off with --validate=false
```
Using `kubectl create --validate=false` to turn validation off, it creates the resource anyway, unless a required field is absent or a field value is invalid. Unknown API fields are ignored, so be careful. This pod was created, but with no `command`, which is an optional field, since the image may specify an `Entrypoint`.
View the [Pod API
object](/docs/api-reference/v1/definitions/#_v1_pod)
to see the list of valid fields.
## Environment variables and variable expansion
Kubernetes [does not automatically run commands in a shell](https://github.com/kubernetes/kubernetes/wiki/User-FAQ#use-of-environment-variables-on-the-command-line) (not all images contain shells). If you would like to run your command in a shell, such as to expand environment variables (specified using `env`), you could do the following:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-world
spec: # specification of the pod's contents
restartPolicy: Never
containers:
- name: hello
image: "ubuntu:14.04"
env:
- name: MESSAGE
value: "hello world"
command: ["/bin/sh","-c"]
args: ["/bin/echo \"${MESSAGE}\""]
```
However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/expansion.md):
```yaml
command: ["/bin/echo"]
args: ["$(MESSAGE)"]
```
## Viewing pod status
You can see the pod you created (actually all of your cluster's pods) using the `get` command.
If you're quick, it will look as follows:
```shell
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world 0/1 Pending 0 0s
```
Initially, a newly created pod is unscheduled -- no node has been selected to run it. Scheduling happens after creation, but is fast, so you normally shouldn't see pods in an unscheduled state unless there's a problem.
After the pod has been scheduled, the image may need to be pulled to the node on which it was scheduled, if it hadn't been pulled already. After a few seconds, you should see the container running:
```shell
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world 1/1 Running 0 5s
```
The `READY` column shows how many containers in the pod are running.
Almost immediately after it starts running, this command will terminate. `kubectl` shows that the container is no longer running and displays the exit status:
```shell
$ kubectl get pods --show-all
NAME READY STATUS RESTARTS AGE
hello-world 0/1 ExitCode:0 0 15s
```
## Viewing pod output
You probably want to see the output of the command you ran. As with [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/), `kubectl logs` will show you the output:
```shell
$ kubectl logs hello-world
hello world
```
## Deleting pods
When you're done looking at the output, you should delete the pod:
```shell
$ kubectl delete pod hello-world
pods/hello-world
```
As with `create`, `kubectl` prints the resource type and name of the resource deleted when successful.
You can also use the resource/name format to specify the pod:
```shell
$ kubectl delete pods/hello-world
pods/hello-world
```
Terminated pods aren't currently automatically deleted, so that you can observe their final status, so be sure to clean up your dead pods.
On the other hand, containers and their logs are eventually deleted automatically in order to free up disk space on the nodes.
## What's next?
[Learn about deploying continuously running applications.](/docs/user-guide/deploying-applications)

94
docs/user-guide/pods/single-container.md
View File

@ -1,94 +0,0 @@
---
assignees:
- janetkuo
title: Creating Single-Container Pods
---
* TOC
{:toc}
A pod is a group of containers that are scheduled
onto the same host. Pods serve as units of scheduling, deployment, and
horizontal scaling/replication. Pods share fate, and share some resources, such
as storage volumes and IP addresses.
## Creating a pod
Single-container pods can be created with the `run` command. The
pod's properties are specified with flags on the command line.
The `run` command creates a Deployment to monitor the pod(s).
The Deployment watches for failed pods and will start up new pods as required
to maintain the specified number.
Note: If you don't want a Deployment to monitor your pod (e.g. your pod
is writing non-persistent data which won't survive a restart, or your pod is
intended to be very short-lived), you can
[create a pod directly with the `create` command](/docs/user-guide/pods/multi-container/).
To create a pod using the `run` command:
```shell
$ kubectl run NAME
--image=image
[--port=port]
[--replicas=replicas]
[--labels=key=value,key=value,...]
```
Where:
* `kubectl run` creates a Deployment named "nginx" on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details.
* `NAME` (required) is the name of the container to create. This value is also
applied as the name of the Deployment, and as the prefix of the
pod name. For example:
```shell
$ kubectl run example --image=nginx
deployment "example" created
$ kubectl get pods -l run=example
NAME READY STATUS RESTARTS AGE
example-1934187764-scau1 1/1 Running 0 13s
```
* `--image=IMAGE` (required) is the Docker container image to use for this
container.
* `--port=PORT` is the port to expose on the container.
* `--replicas=NUM` is the number of replicated pods to create. If not specified,
one pod will be created.
* `--labels=key=value` specifies one or more labels to attach to the pod. In
addition to any labels specified here, `run` attaches a label of
the format `run=NAME`. This is used by the Deployment
to target the pods created by the command.
![image](/images/docs/pods/single-container_1.svg)
There are additional flags that can be specified. For a complete list, run:
$ kubectl run --help
## Viewing a pod
{% include_relative _viewing-a-pod.md %}
## Deleting a pod
If your pod was created using the `run` command, Kubernetes creates a
[Deployment](/docs/user-guide/deployments/)
to manage the pod. Pods managed by a Deployment are rescheduled if
they go away, including being deleted by `kubectl delete pod`. To permanently
delete the pod, delete its Deployment.
First, find the Deployment's name:
```shell
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
example 1 1 1 1 1m
```
Then, `delete` the Deployment:
```shell
$ kubectl delete deployment DEPLOYMENT_NAME
```

61
docs/user-guide/simple-nginx.md
View File

@ -1,61 +0,0 @@
---
assignees:
- mikedanese
title: Running Your First Containers
---
Ok, you've run one of the [getting started guides](/docs/getting-started-guides/) and you have
successfully turned up a Kubernetes cluster. Now what? This guide will help you get oriented
to Kubernetes and running your first containers on the cluster.
### Running a container (simple version)
From this point onwards, it is assumed that `kubectl` is on your path from one of the getting started guides.
The [`kubectl run`](/docs/user-guide/kubectl/kubectl_run) line below will create a [`Deployment`](/docs/user-guide/deployments) named `my-nginx`, and
two [nginx](https://registry.hub.docker.com/_/nginx/) [pods](/docs/user-guide/pods) listening on port 80. The `Deployment` will ensure that there are
always exactly two pods running as specified in its spec.
```shell
kubectl run my-nginx --image=nginx --replicas=2 --port=80
```
Once the pods are created, you can list them to see what is up and running:
```shell
kubectl get pods
```
You can also see the Deployment that was created:
```shell
kubectl get deployments
```
To stop the two replicated containers, delete the Deployment:
```shell
kubectl delete deployment 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](/docs/user-guide/services/#external-services) for the pods,
to do this run:
```shell
kubectl expose deployment my-nginx --port=80 --type=LoadBalancer
```
This should print the service that has been created, and map an external IP address to the service. Where to find this external IP address will depend on the environment you run in. For instance, for Google Compute Engine the external IP address is listed as part of the newly created service and can be retrieved by running
```shell
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](/docs/user-guide/deploying-applications/)
is given in a different document.