1.2 additions for user-guide/
This commit is contained in:
@@ -1,6 +1,8 @@
|
||||
---
|
||||
---
|
||||
|
||||
## Kubectl CLI and Pods
|
||||
|
||||
For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers
|
||||
|
||||
In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
|
||||
@@ -74,6 +76,7 @@ Delete the pod by name:
|
||||
$ kubectl delete pod nginx
|
||||
```
|
||||
|
||||
|
||||
#### Volumes
|
||||
|
||||
That's great for a simple static web server, but what about persistent storage?
|
||||
@@ -106,15 +109,15 @@ Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](
|
||||
|
||||
Notes:
|
||||
|
||||
- The volume mount name is a reference to a specific empty dir volume.
|
||||
- The volume mount path is the path to mount the empty dir volume within the container.
|
||||
- The `volumeMounts` `name` is a reference to a specific `volumes` `name`.
|
||||
- The `volumeMounts` `mountPath` is the path to mount the volume within the container.
|
||||
|
||||
##### Volume Types
|
||||
|
||||
- **EmptyDir**: Creates a new directory that will persist across container failures and restarts.
|
||||
- **EmptyDir**: Creates a new directory that will exist as long as the Pod is running on the node, but it can persist across container failures and restarts.
|
||||
- **HostPath**: Mounts an existing directory on the node's file system (e.g. `/var/logs`).
|
||||
|
||||
See [volumes](/docs/user-guide/volumes) for more details.
|
||||
See [volumes](/docs/user-guide/volumes/) for more details.
|
||||
|
||||
|
||||
#### Multiple Containers
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
---
|
||||
|
||||
## Labels, Replication Controllers, Services and Health Checking
|
||||
|
||||
If you went through [Kubernetes 101](/docs/user-guide/walkthrough/), you learned about kubectl, pods, volumes, and multiple containers.
|
||||
For Kubernetes 201, we will pick up where 101 left off and cover some slightly more advanced topics in Kubernetes, related to application productionization, deployment and
|
||||
@@ -11,6 +12,7 @@ In order for the kubectl usage examples to work, make sure you have an examples
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
|
||||
## Labels
|
||||
|
||||
Having already learned about Pods and how to create them, you may be struck by an urge to create many, many pods. Please do! But eventually you will need a system to organize these pods into groups. The system for achieving this in Kubernetes is Labels. Labels are key-value pairs that are attached to each object in Kubernetes. Label selectors can be passed along with a RESTful `list` request to the apiserver to retrieve a list of objects which match that label selector.
|
||||
@@ -18,7 +20,7 @@ Having already learned about Pods and how to create them, you may be struck by a
|
||||
To add a label, add a labels section under metadata in the pod definition:
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
labels:
|
||||
app: nginx
|
||||
```
|
||||
|
||||
@@ -44,7 +46,7 @@ They are a core concept used by two additional Kubernetes building blocks: Repli
|
||||
|
||||
## Replication Controllers
|
||||
|
||||
OK, now you know how to make awesome, multi-container, labeled pods and you want to use them to build an application, you might be tempted to just start building a whole bunch of individual pods, but if you do that, a whole host of operational concerns pop up. For example: how will you scale the number of pods up or down and how will you ensure that all pods are homogenous?
|
||||
OK, now you know how to make awesome, multi-container, labeled pods and you want to use them to build an application, you might be tempted to just start building a whole bunch of individual pods, but if you do that, a whole host of operational concerns pop up. For example: how will you scale the number of pods up or down and how will you ensure that all pods are homogeneous?
|
||||
|
||||
Replication controllers are the objects to answer these questions. A replication controller combines a template for pod creation (a "cookie-cutter" if you will) and a number of desired replicas, into a single Kubernetes object. The replication controller also contains a label selector that identifies the set of objects managed by the replication controller. The replication controller constantly measures the size of this set relative to the desired size, and takes action by creating or deleting pods.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user