Merge remote-tracking branch 'refs/remotes/kubernetes/master'
This commit is contained in:
Chris Marino
@@ -6,6 +6,8 @@ toc:
|
||||
section:
|
||||
- title: Defining Environment Variables for a Container
|
||||
path: /docs/tasks/configure-pod-container/define-environment-variable-container/
|
||||
- title: Defining a Command and Arguments for a Container
|
||||
path: /docs/tasks/configure-pod-container/define-command-argument-container/
|
||||
- title: Accessing Applications in a Cluster
|
||||
section:
|
||||
- title: Using Port Forwarding to Access Applications in a Cluster
|
||||
|
||||
@@ -36,7 +36,11 @@ Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a
|
||||
|
||||
### CNI
|
||||
|
||||
The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads the first CNI configuration file from `--network-plugin-dir` and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md), and any required CNI plugins referenced by the configuration must be present in `/opt/cni/bin`.
|
||||
The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`).
|
||||
|
||||
If there are multiple CNI configuration files in the directory, the first one in lexicographic order of file name is used.
|
||||
|
||||
In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI `lo` plugin, at minimum version 0.2.0
|
||||
|
||||
### kubenet
|
||||
|
||||
@@ -44,7 +48,7 @@ The Linux-only kubenet plugin provides functionality similar to the `--configure
|
||||
|
||||
The plugin requires a few things:
|
||||
|
||||
* The standard CNI `bridge` and `host-local` plugins are required. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect.
|
||||
* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect.
|
||||
* Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
|
||||
* Kubelet must also be run with the `--reconcile-cidr` argument to ensure the IP subnet assigned to the node by configuration or the controller-manager is propagated to the plugin
|
||||
* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
|
||||
@@ -66,6 +70,6 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
||||
## Usage Summary
|
||||
|
||||
* `--network-plugin=exec` specifies that we use the `exec` plugin, with executables located in `--network-plugin-dir`.
|
||||
* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `/opt/cni/bin` and CNI plugin configuration located in `network-plugin-dir`, config location defaults to `/etc/cni/net.d`.
|
||||
* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
|
||||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `network-plugin-dir`.
|
||||
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
|
||||
@@ -176,8 +176,8 @@ Once a pod network has been installed, you can confirm that it is working by che
|
||||
As an example, install a sample microservices application, a socks shop, to put your cluster through its paces.
|
||||
To learn more about the sample microservices app, see the [GitHub README](https://github.com/microservices-demo/microservices-demo).
|
||||
|
||||
# git clone https://github.com/microservices-demo/microservices-demo
|
||||
# kubectl apply -f microservices-demo/deploy/kubernetes/manifests/sock-shop-ns.yml -f microservices-demo/deploy/kubernetes/manifests
|
||||
# kubectl create namespace sock-shop
|
||||
# kubectl apply -n sock-shop -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true"
|
||||
|
||||
You can then find out the port that the [NodePort feature of services](/docs/user-guide/services/) allocated for the front-end service by running:
|
||||
|
||||
@@ -215,7 +215,7 @@ See the [list of add-ons](/docs/admin/addons/) to explore other add-ons, includi
|
||||
|
||||
## Cleanup
|
||||
|
||||
* To uninstall the socks shop, run `kubectl delete -f microservices-demo/deploy/kubernetes/manifests` on the master.
|
||||
* To uninstall the socks shop, run `kubectl delete namespace sock-shop` on the master.
|
||||
|
||||
* To undo what `kubeadm` did, simply delete the machines you created for this tutorial, or run the script below and then start over or uninstall the packages.
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
@@ -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/)
|
||||
|
||||
Reference in New Issue
Block a user