Merge branch 'master' into download_kubectl
This commit is contained in:
Justin Santa Barbara
@@ -0,0 +1,12 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: command-demo
|
||||
labels:
|
||||
purpose: demonstrate-command
|
||||
spec:
|
||||
containers:
|
||||
- name: command-demo-container
|
||||
image: debian
|
||||
command: ["printenv"]
|
||||
args: ["HOSTNAME", "KUBERNETES_PORT"]
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to define commands and arguments when you run a container
|
||||
in a Kubernetes Pod.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
### Defining a command and arguments when you create a Pod
|
||||
|
||||
When you create a Pod, you can define a command and arguments for the
|
||||
containers that run in the Pod. To define a command, include the `command`
|
||||
field in the configuration file. To define arguments for the command, include
|
||||
the `args` field in the configuration file. The command and arguments that
|
||||
you define cannot be changed after the Pod is created.
|
||||
|
||||
The command and arguments that you define in the configuration file
|
||||
override the default command and arguments provided by the container image.
|
||||
If you define args, but do not define a command, the default command is used
|
||||
with your new arguments. For more information, see
|
||||
[Commands and Capabilities](/docs/user-guide/containers/).
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines a command and two arguments:
|
||||
|
||||
{% include code.html language="yaml" file="commands.yaml" ghlink="/docs/tasks/configure-pod-container/commands.yaml" %}
|
||||
|
||||
1. Create a Pod based on the YAML configuration file:
|
||||
|
||||
export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master
|
||||
kubectl create -f $REPO/docs/tasks/configure-pod-container/commands.yaml
|
||||
|
||||
1. List the running Pods:
|
||||
|
||||
kubectl get pods
|
||||
|
||||
The output shows that the container that ran in the command-demo Pod has
|
||||
completed.
|
||||
|
||||
1. To see the output of the command that ran in the container, view the logs
|
||||
from the Pod:
|
||||
|
||||
kubectl logs command-demo
|
||||
|
||||
The output shows the values of the HOSTNAME and KUBERNETES_PORT environment
|
||||
variables:
|
||||
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
|
||||
### Using environment variables to define arguments
|
||||
|
||||
In the preceding example, you defined the arguments directly by
|
||||
providing strings. As an alternative to providing strings directly,
|
||||
you can define arguments by using environment variables:
|
||||
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "hello world"
|
||||
command: ["/bin/echo"]
|
||||
args: ["$(MESSAGE)"]
|
||||
|
||||
This means you can define an argument for a Pod using any of
|
||||
the techniques available for defining environment variables, including
|
||||
[ConfigMaps](/docs/user-guide/configmap/)
|
||||
and
|
||||
[Secrets](/docs/user-guide/secrets/).
|
||||
|
||||
NOTE: The environment variable appears in parentheses, `"$(VAR)"`. This is
|
||||
required for the variable to be expanded in the `command` or `args` field.
|
||||
|
||||
### Running a command in a shell
|
||||
|
||||
In some cases, you need your command to run in a shell. For example, your
|
||||
command might consist of several commands piped together, or it might be a shell
|
||||
script. To run your command in a shell, wrap it like this:
|
||||
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* Learn more about [containers and commands](/docs/user-guide/containers/).
|
||||
* Learn more about [configuring containers](/docs/user-guide/configuring-containers/).
|
||||
* Learn more about [running commands in a container](/docs/user-guide/getting-into-containers/).
|
||||
* See [Container](/docs/api-reference/v1/definitions/#_v1_container).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to define environment variables when you run a container
|
||||
in a Kubernetes Pod.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
### Defining an environment variable for a container
|
||||
|
||||
When you create a Pod, you can set environment variables for the containers
|
||||
that run in the Pod. To set environment variables, include the `env` field in
|
||||
the configuration file.
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines an environment variable with name `DEMO_GREETING` and
|
||||
value `"Hello from the environment"`. Here is the configuration file for the
|
||||
Pod:
|
||||
|
||||
{% include code.html language="yaml" file="envars.yaml" ghlink="/docs/tasks/configure-pod-container/envars.yaml" %}
|
||||
|
||||
1. Create a Pod based on the YAML configuration file:
|
||||
|
||||
export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master
|
||||
kubectl create -f $REPO/docs/tasks/configure-pod-container/envars.yaml
|
||||
|
||||
1. List the running Pods:
|
||||
|
||||
kubectl get pods
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
|
||||
1. Get a shell to the container running in your Pod:
|
||||
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
|
||||
1. In your shell, run the `printenv` command to list the environment variables.
|
||||
|
||||
root@envar-demo:/# printenv
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
|
||||
1. To exit the shell, enter `exit`.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* Learn more about [environment variables](/docs/user-guide/environment-guide/).
|
||||
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
|
||||
* See [EnvVarSource](/docs/api-reference/v1/definitions/#_v1_envvarsource).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: envar-demo
|
||||
labels:
|
||||
purpose: demonstrate-envars
|
||||
spec:
|
||||
containers:
|
||||
- name: envar-demo-container
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
env:
|
||||
- name: DEMO_GREETING
|
||||
value: "Hello from the environment"
|
||||
@@ -3,6 +3,11 @@
|
||||
|
||||
The Tasks section of the Kubernetes documentation is a work in progress
|
||||
|
||||
#### Configuring Pods and Containers
|
||||
|
||||
* [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/)
|
||||
* [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/)
|
||||
|
||||
#### Accessing Applications in a Cluster
|
||||
|
||||
* [Using Port Forwarding to Access Applications in a Cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
|
||||
@@ -374,6 +374,6 @@ driver, and then cleans up.
|
||||
An advantage of this approach is that the overall process gets the completion guarantee of a Job
|
||||
object, but complete control over what pods are created and how work is assigned to them.
|
||||
|
||||
## Future work
|
||||
## Scheduled Jobs
|
||||
|
||||
Support for creating Jobs at specified times/dates (i.e. cron) is expected in [1.4](https://github.com/kubernetes/kubernetes/pull/11980).
|
||||
Support for creating Jobs at specified times/dates (i.e. cron) is available in Kubernetes [1.4](https://github.com/kubernetes/kubernetes/pull/11980). More information is available in the [scheduled job documents](http://kubernetes.io/docs/user-guide/scheduled-jobs/)
|
||||
|
||||
@@ -166,7 +166,7 @@ We will use the `amqp-consume` utility to read the message
|
||||
from the queue and run our actual program. Here is a very simple
|
||||
example program:
|
||||
|
||||
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-1/worker.py" %}
|
||||
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-1/worker.py" %}
|
||||
|
||||
Now, build an image. If you are working in the source
|
||||
tree, then change directory to `examples/job/work-queue-1`.
|
||||
@@ -204,7 +204,7 @@ Here is a job definition. You'll need to make a copy of the Job and edit the
|
||||
image to match the name you used, and call it `./job.yaml`.
|
||||
|
||||
|
||||
{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-1/job.yaml" %}
|
||||
{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-1/job.yaml" %}
|
||||
|
||||
In this example, each pod works on one item from the queue and then exits.
|
||||
So, the completion count of the Job corresponds to the number of work items
|
||||
@@ -258,12 +258,12 @@ want to consider one of the other [job patterns](/docs/user-guide/jobs/#job-patt
|
||||
|
||||
This approach creates a pod for every work item. If your work items only take a few seconds,
|
||||
though, creating a Pod for every work item may add a lot of overhead. Consider another
|
||||
[example](/docs/user-guide/job/work-queue-2), that executes multiple work items per Pod.
|
||||
[example](/docs/user-guide/jobs/work-queue-2/), that executes multiple work items per Pod.
|
||||
|
||||
In this example, we used use the `amqp-consume` utility to read the message
|
||||
from the queue and run our actual program. This has the advantage that you
|
||||
do not need to modify your program to be aware of the queue.
|
||||
A [different example](/docs/user-guide/job/work-queue-2), shows how to
|
||||
A [different example](/docs/user-guide/jobs/work-queue-2/), shows how to
|
||||
communicate with the work queue using a client library.
|
||||
|
||||
## Caveats
|
||||
|
||||
@@ -108,7 +108,7 @@ called rediswq.py ([Download](rediswq.py?raw=true)).
|
||||
The "worker" program in each Pod of the Job uses the work queue
|
||||
client library to get work. Here it is:
|
||||
|
||||
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-2/worker.py" %}
|
||||
{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-2/worker.py" %}
|
||||
|
||||
If you are working from the source tree,
|
||||
change directory to the `examples/job/work-queue-2` directory.
|
||||
@@ -147,7 +147,7 @@ gcloud docker push gcr.io/<project>/job-wq-2
|
||||
|
||||
Here is the job definition:
|
||||
|
||||
{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-2/job.yaml" %}
|
||||
{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-2/job.yaml" %}
|
||||
|
||||
Be sure to edit the job template to
|
||||
change `gcr.io/myproject` to your own path.
|
||||
|
||||
@@ -44,9 +44,11 @@ metadata:
|
||||
|
||||
To configure the annotation via `kubectl`:
|
||||
|
||||
```shell{% raw %}
|
||||
```shell
|
||||
{% raw %}
|
||||
kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"
|
||||
{% endraw %}```
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
See the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) for an example.
|
||||
|
||||
|
||||
@@ -226,7 +226,8 @@ Here is a toy example:
|
||||
|
||||
The message is recorded along with the other state of the last (i.e., most recent) termination:
|
||||
|
||||
```shell{% raw %}
|
||||
```shell
|
||||
{% raw %}
|
||||
$ kubectl create -f ./pod-w-message.yaml
|
||||
pod "pod-w-message" created
|
||||
$ sleep 70
|
||||
@@ -234,7 +235,8 @@ $ kubectl get pods/pod-w-message -o go-template="{{range .status.containerStatus
|
||||
Sleep expired
|
||||
$ kubectl get pods/pod-w-message -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.exitCode}}{{end}}"
|
||||
0
|
||||
{% endraw %}```
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
## What's next?
|
||||
|
||||
|
||||
@@ -59,12 +59,14 @@ On most providers, the pod IPs are not externally accessible. The easiest way to
|
||||
|
||||
Provided the pod IP is accessible, you should be able to access its http endpoint with wget on port 80:
|
||||
|
||||
```shell{% raw %}
|
||||
```shell
|
||||
{% raw %}
|
||||
$ kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')"
|
||||
u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container
|
||||
u@busybox$ exit # Exit the busybox container
|
||||
$ kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
|
||||
{% endraw %}```
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
Delete the pod by name:
|
||||
|
||||
|
||||
@@ -136,7 +136,8 @@ On most providers, the service IPs are not externally accessible. The easiest wa
|
||||
|
||||
Provided the service IP is accessible, you should be able to access its http endpoint with wget on the exposed port:
|
||||
|
||||
```shell{% raw %}
|
||||
```shell
|
||||
{% raw %}
|
||||
$ export SERVICE_IP=$(kubectl get service nginx-service -o go-template='{{.spec.clusterIP}}')
|
||||
$ export SERVICE_PORT=$(kubectl get service nginx-service -o go-template='{{(index .spec.ports 0).port}}')
|
||||
$ echo "$SERVICE_IP:$SERVICE_PORT"
|
||||
@@ -144,7 +145,8 @@ $ kubectl run busybox --generator=run-pod/v1 --image=busybox --restart=Never --
|
||||
u@busybox$ wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run in the busybox container
|
||||
u@busybox$ exit # Exit the busybox container
|
||||
$ kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
|
||||
{% endraw %}```
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
To delete the service by name:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user