Merge branch 'master' into update-generated-docs
This commit is contained in:
@@ -169,6 +169,12 @@ Follow the "With Linux Bridge devices" section of [this very nice
|
||||
tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
|
||||
Lars Kellogg-Stedman.
|
||||
|
||||
### Nuage Networks VCS (Virtualized Cloud Services)
|
||||
|
||||
[Nuage](www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage’s policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform’s real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
[OpenVSwitch](/docs/admin/ovs-networking) is a somewhat more mature but also
|
||||
|
||||
@@ -80,6 +80,12 @@ site where you can verify that your changes have rendered correctly.
|
||||
If needed, revise your pull request by committing changes to your
|
||||
new branch in your fork.
|
||||
|
||||
The staging site for the upcoming Kubernetes release is here:
|
||||
[http://kubernetes-io-vnext-staging.netlify.com/](http://kubernetes-io-vnext-staging.netlify.com/).
|
||||
The staging site reflects the current state of what's been merged in the
|
||||
release branch, or in other words, what the docs will look like for the
|
||||
next upcoming release. It's automatically updated as new PRs get merged.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
@@ -33,16 +33,18 @@ the master branch.
|
||||
|
||||
### Staging a pull request
|
||||
|
||||
When you create pull request against the Kubernetes documentation
|
||||
repository, you can see your changes on a staging server.
|
||||
When you create a pull request, either against the master or <vnext>
|
||||
branch, your changes are staged in a custom subdomain on Netlify so that
|
||||
you can see your changes in rendered form before the pull request is merged.
|
||||
|
||||
1. In your GitHub account, in your new branch, submit a pull request to the
|
||||
kubernetes/kubernetes.github.io repository. This opens a page that shows the
|
||||
status of your pull request.
|
||||
|
||||
1. Click **Show all checks**. Wait for the **deploy/netlify** check to complete.
|
||||
To the right of **deploy/netlify**, click **Details**. This opens a staging
|
||||
site where you see your changes.
|
||||
1. Scroll down to the list of automated checks. Click **Show all checks**.
|
||||
Wait for the **deploy/netlify** check to complete. To the right of
|
||||
**deploy/netlify**, click **Details**. This opens a staging site where you
|
||||
can see your changes.
|
||||
|
||||
### Staging locally using Docker
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ is the best fit for your content:
|
||||
<td>A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
</table>
|
||||
|
||||
Each page type has a
|
||||
[template](/docs/contribute/page-templates/)
|
||||
@@ -72,6 +72,50 @@ Depending page type, create an entry in one of these files:
|
||||
* /_data/tutorials.yaml
|
||||
* /_data/concepts.yaml
|
||||
|
||||
### Including code from another file
|
||||
|
||||
To include a code file in your topic, place the code file in the Kubernetes
|
||||
documentation repository, preferably in the same directory as your topic
|
||||
file. In your topic file, use the `include` tag:
|
||||
|
||||
<pre>{% include code.html language="<LEXERVALUE>" file="<RELATIVEPATH>" ghlink="/<PATHFROMROOT>" %}</pre>
|
||||
|
||||
where:
|
||||
|
||||
* `<LEXERVALUE>` is the language in which the file was written. This must be
|
||||
[a value supported by Rouge](https://github.com/jneen/rouge/wiki/list-of-supported-languages-and-lexers).
|
||||
* `<RELATIVEPATH>` is the path to the file you're including, relative to the current file, for example, `gce-volume.yaml`.
|
||||
* `<PATHFROMROOT>` is the path to the file relative to root, for example, `docs/tutorials/stateful-application/gce-volume.yaml`.
|
||||
|
||||
Here's an example of using the `include` tag:
|
||||
|
||||
<pre>{% include code.html language="yaml" file="gce-volume.yaml" ghlink="/docs/tutorials/stateful-application/gce-volume.yaml" %}</pre>
|
||||
|
||||
### Showing how to create an API object from a configuration file
|
||||
|
||||
If you need to show the reader how to create an API object based on a
|
||||
configuration file, place the configuration file in the Kubernetes documentation
|
||||
repository, preferably in the same directory as your topic file.
|
||||
|
||||
In your topic, show this command:
|
||||
|
||||
kubectl create -f http://k8s.io/<PATHFROMROOT>
|
||||
|
||||
where `<PATHFROMROOT>` is the path to the configuration file relative to root,
|
||||
for example, `docs/tutorials/stateful-application/gce-volume.yaml`.
|
||||
|
||||
Here's an example of a command that creates an API object from a configuration file:
|
||||
|
||||
kubectl create -f http://k8s.io/docs/tutorials/stateful-application/gce-volume.yaml
|
||||
|
||||
For an example of a topic that uses this technique, see
|
||||
[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
|
||||
|
||||
### Adding images to a topic
|
||||
|
||||
Put image files in the `/images` directory. The preferred
|
||||
image format is SVG.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to configure a Pod to use a Volume for storage.
|
||||
|
||||
A Container's file system lives only as long as the Container does, so when a
|
||||
Container terminates and restarts, changes to the filesystem are lost. For more
|
||||
consistent storage that is independent of the Container, you can use a
|
||||
[Volume](/docs/user-guide/volumes). This is especially important for stateful
|
||||
applications, such as key-value stores and databases. For example, Redis is a
|
||||
key-value cache and store.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
### Configuring a volume for a Pod
|
||||
|
||||
In this exercise, you create a Pod that runs one Container. This Pod has a
|
||||
Volume of type
|
||||
[emptyDir](/docs/user-guide/volumes/#emptydir)
|
||||
that lasts for the life of the Pod, even if the Container terminates and
|
||||
restarts. Here is the configuration file for the Pod:
|
||||
|
||||
{% include code.html language="yaml" file="pod-redis.yaml" ghlink="/docs/tasks/configure-pod-container/pod-redis.yaml" %}
|
||||
|
||||
1. Create the Pod:
|
||||
|
||||
kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml
|
||||
|
||||
1. Verify that the Pod's Container is running, and then watch for changes to
|
||||
the Pod:
|
||||
|
||||
kubectl get --watch pod redis
|
||||
|
||||
The output looks like this:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis 1/1 Running 0 13s
|
||||
|
||||
1. In another terminal, get a shell to the running Container:
|
||||
|
||||
kubectl exec -it redis -- /bin/bash
|
||||
|
||||
1. In your shell, go to `/data/redis`, and create a file:
|
||||
|
||||
root@redis:/data/redis# echo Hello > test-file
|
||||
|
||||
1. In your shell, list the running processes:
|
||||
|
||||
root@redis:/data/redis# ps aux
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
|
||||
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
|
||||
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
|
||||
|
||||
1. In your shell, kill the redis process:
|
||||
|
||||
root@redis:/data/redis# kill <pid>
|
||||
|
||||
where `<pid>` is the redis process ID (PID).
|
||||
|
||||
1. In your original terminal, watch for changes to the redis Pod. Eventually,
|
||||
you will see something like this:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis 1/1 Running 0 13s
|
||||
redis 0/1 Completed 0 6m
|
||||
redis 1/1 Running 1 6m
|
||||
|
||||
At this point, the Container has terminated and restarted. This is because the
|
||||
redis Pod has a
|
||||
[restartPolicy](http://kubernetes.io/docs/api-reference/v1/definitions#_v1_podspec)
|
||||
of `Always`.
|
||||
|
||||
1. Get a shell into the restarted Container:
|
||||
|
||||
kubectl exec -it redis -- /bin/bash
|
||||
|
||||
1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* See [Volume](/docs/api-reference/v1/definitions/#_v1_volume).
|
||||
|
||||
* See [Pod](http://kubernetes.io/docs/api-reference/v1/definitions#_v1_pod).
|
||||
|
||||
* In addition to the local disk storage provided by `emptyDir`, Kubernetes
|
||||
supports many different network-attached storage solutions, including PD on
|
||||
GCE and EBS on EC2, which are preferred for critical data, and will handle
|
||||
details such as mounting and unmounting the devices on the nodes. See
|
||||
[Volumes](/docs/user-guide/volumes) for more details.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,14 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: redis
|
||||
spec:
|
||||
containers:
|
||||
- name: redis
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: redis-storage
|
||||
mountPath: /data/redis
|
||||
volumes:
|
||||
- name: redis-storage
|
||||
emptyDir: {}
|
||||
Reference in New Issue
Block a user