Merge branch 'master' into master
This commit is contained in:
John Torres
@@ -71,6 +71,7 @@ title: Community
|
||||
<a href="http://kubernetes.io/docs/getting-started-guides/dcos/"><img src="/images/community_logos/mesosphere_logo.png"></a>
|
||||
<a href="http://docs.datadoghq.com/integrations/kubernetes/"><img src="/images/community_logos/datadog_logo.png"></a>
|
||||
<a href="https://apprenda.com/kubernetes-support/"><img src="/images/community_logos/apprenda_logo.png"></a>
|
||||
<a href="http://www.ibm.com/cloud-computing/"><img src="/images/community_logos/ibm_logo.png"></a>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
@@ -116,7 +116,7 @@ rejects, then the request is immediately rejected.
|
||||
In addition to rejecting objects, admission controllers can also set complex defaults for
|
||||
fields.
|
||||
|
||||
The available Admission Control Modules are described [here](docs/admin/admission-controllers/).
|
||||
The available Admission Control Modules are described [here](/docs/admin/admission-controllers/).
|
||||
|
||||
Once a request passes all admission controllers, it is validated using the validation routines
|
||||
for the corresponding API object, and then written to the object store (shown as step **4**).
|
||||
|
||||
@@ -36,8 +36,8 @@ it to [support other log format](/docs/admin/node-problem/#support-other-log-for
|
||||
|
||||
## Enable/Disable in GCE cluster
|
||||
|
||||
Node problem detector is running as a cluster
|
||||
[addon](docs/admin/cluster-large/#addon-resources) enabled by default in the
|
||||
Node problem detector is [running as a cluster
|
||||
addon](/docs/admin/cluster-large/#addon-resources) enabled by default in the
|
||||
gce cluster.
|
||||
|
||||
You can enable/disable it by setting the environment variable
|
||||
|
||||
@@ -50,7 +50,7 @@ export MASTER_SIZE=m3.medium
|
||||
export NODE_SIZE=m3.medium
|
||||
export AWS_S3_REGION=eu-west-1
|
||||
export AWS_S3_BUCKET=mycompany-kubernetes-artifacts
|
||||
export INSTANCE_PREFIX=k8s
|
||||
export KUBE_AWS_INSTANCE_PREFIX=k8s
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ monitoring-heapster-v1-20ej 0/1 Running 9 32
|
||||
|
||||
Here is the same information in a picture which shows how the pods might be placed on specific nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
This diagram shows four nodes created on a Google Compute Engine cluster with the name of each VM node on a purple background. The internal and public IPs of each node are shown on gray boxes and the pods running in each node are shown in green boxes. Each pod box shows the name of the pod and the namespace it runs in, the IP address of the pod and the images which are run as part of the pod's execution. Here we see that every node is running a fluentd-cloud-logging pod which is collecting the log output of the containers running on the same node and sending them to Google Cloud Logging. A pod which provides the
|
||||
[cluster DNS service](/docs/admin/dns) runs on one of the nodes and a pod which provides monitoring support runs on another node.
|
||||
@@ -52,7 +52,7 @@ This step may take a few minutes to download the ubuntu:14.04 image during which
|
||||
|
||||
One of the nodes is now running the counter pod:
|
||||
|
||||
|
||||
|
||||
|
||||
When the pod status changes to `Running` we can use the kubectl logs command to view the output of this counter pod.
|
||||
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ In the reference section, you can find reference documentation for Kubernetes AP
|
||||
|
||||
## Glossary
|
||||
|
||||
Explore the glossary of essential Kubernetes concepts. Some good starting points are the entries for [Pods](/docs/user-guide/pods/), [Nodes](/docs/admin/nodes/), [Services](/docs/user-guide/services/), and [Replication Controllers](/docs/user-guide/replication-controller/).
|
||||
Explore the glossary of essential Kubernetes concepts. Some good starting points are the entries for [Pods](/docs/user-guide/pods/), [Nodes](/docs/admin/node/), [Services](/docs/user-guide/services/), and [Replication Controllers](/docs/user-guide/replication-controller/).
|
||||
|
||||
## Design Docs
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ container needs. When containers have their resource requests specified, the sc
|
||||
able to make better decisions about which nodes to place pods on; and when containers have their
|
||||
limits specified, contention for resources on a node can be handled in a specified manner. For
|
||||
more details about the difference between requests and limits, please refer to
|
||||
[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/resource-qos.md).
|
||||
[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resource-qos.md).
|
||||
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit. CPU is specified
|
||||
in units of cores. Memory is specified in units of bytes.
|
||||
|
||||
@@ -51,7 +51,7 @@ Here are examples for these rules in table format
|
||||
|
||||
## Capabilities
|
||||
|
||||
By default, Docker containers are "unprivileged" and cannot, for example, run a Docker daemon inside a Docker container. We can have fine grain control over the capabilities using cap-add and cap-drop.More details [here](https://docs.docker.com/reference/run/#runtime-privilege-linux-capabilities-and-lxc-configuration).
|
||||
By default, Docker containers are "unprivileged" and cannot, for example, run a Docker daemon inside a Docker container. We can have fine grain control over the capabilities using cap-add and cap-drop. More details [here](https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities).
|
||||
|
||||
The relationship between Docker's capabilities and [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)
|
||||
|
||||
@@ -93,4 +93,4 @@ The relationship between Docker's capabilities and [Linux capabilities](http://m
|
||||
| LEASE | CAP_LEASE |
|
||||
| SETFCAP | CAP_SETFCAP |
|
||||
| WAKE_ALARM | CAP_WAKE_ALARM |
|
||||
| BLOCK_SUSPEND | CAP_BLOCK_SUSPEND |
|
||||
| BLOCK_SUSPEND | CAP_BLOCK_SUSPEND |
|
||||
|
||||
@@ -46,40 +46,40 @@ kubectl
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [kubectl annotate](kubectl_annotate.md) - Update the annotations on a resource
|
||||
* [kubectl api-versions](kubectl_api-versions.md) - Print the supported API versions on the server, in the form of "group/version".
|
||||
* [kubectl apply](kubectl_apply.md) - Apply a configuration to a resource by filename or stdin
|
||||
* [kubectl attach](kubectl_attach.md) - Attach to a running container.
|
||||
* [kubectl autoscale](kubectl_autoscale.md) - Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
||||
* [kubectl cluster-info](kubectl_cluster-info.md) - Display cluster info
|
||||
* [kubectl completion](kubectl_completion.md) - Output shell completion code for the given shell (bash or zsh)
|
||||
* [kubectl config](kubectl_config.md) - config modifies kubeconfig files
|
||||
* [kubectl convert](kubectl_convert.md) - Convert config files between different API versions
|
||||
* [kubectl cordon](kubectl_cordon.md) - Mark node as unschedulable
|
||||
* [kubectl create](kubectl_create.md) - Create a resource by filename or stdin
|
||||
* [kubectl delete](kubectl_delete.md) - Delete resources by filenames, stdin, resources and names, or by resources and label selector.
|
||||
* [kubectl describe](kubectl_describe.md) - Show details of a specific resource or group of resources
|
||||
* [kubectl drain](kubectl_drain.md) - Drain node in preparation for maintenance
|
||||
* [kubectl edit](kubectl_edit.md) - Edit a resource on the server
|
||||
* [kubectl exec](kubectl_exec.md) - Execute a command in a container.
|
||||
* [kubectl explain](kubectl_explain.md) - Documentation of resources.
|
||||
* [kubectl expose](kubectl_expose.md) - Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service
|
||||
* [kubectl get](kubectl_get.md) - Display one or many resources
|
||||
* [kubectl label](kubectl_label.md) - Update the labels on a resource
|
||||
* [kubectl logs](kubectl_logs.md) - Print the logs for a container in a pod.
|
||||
* [kubectl namespace](kubectl_namespace.md) - SUPERSEDED: Set and view the current Kubernetes namespace
|
||||
* [kubectl patch](kubectl_patch.md) - Update field(s) of a resource using strategic merge patch.
|
||||
* [kubectl port-forward](kubectl_port-forward.md) - Forward one or more local ports to a pod.
|
||||
* [kubectl proxy](kubectl_proxy.md) - Run a proxy to the Kubernetes API server
|
||||
* [kubectl replace](kubectl_replace.md) - Replace a resource by filename or stdin.
|
||||
* [kubectl rolling-update](kubectl_rolling-update.md) - Perform a rolling update of the given ReplicationController.
|
||||
* [kubectl rollout](kubectl_rollout.md) - rollout manages a deployment
|
||||
* [kubectl run](kubectl_run.md) - Run a particular image on the cluster.
|
||||
* [kubectl scale](kubectl_scale.md) - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job.
|
||||
* [kubectl set](kubectl_set.md) - Set specific features on objects
|
||||
* [kubectl taint](kubectl_taint.md) - Update the taints on one or more nodes
|
||||
* [kubectl uncordon](kubectl_uncordon.md) - Mark node as schedulable
|
||||
* [kubectl version](kubectl_version.md) - Print the client and server version information.
|
||||
* [kubectl annotate](../kubectl_annotate/) - Update the annotations on a resource
|
||||
* [kubectl api-versions](../kubectl_api-versions/) - Print the supported API versions on the server, in the form of "group/version".
|
||||
* [kubectl apply](../kubectl_apply/) - Apply a configuration to a resource by filename or stdin
|
||||
* [kubectl attach](../kubectl_attach/) - Attach to a running container.
|
||||
* [kubectl autoscale](../kubectl_autoscale/) - Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
||||
* [kubectl cluster-info](../kubectl_cluster-info/) - Display cluster info
|
||||
* [kubectl completion](../kubectl_completion/) - Output shell completion code for the given shell (bash or zsh)
|
||||
* [kubectl config](../kubectl_config/) - config modifies kubeconfig files
|
||||
* [kubectl convert](../kubectl_convert/) - Convert config files between different API versions
|
||||
* [kubectl cordon](../kubectl_cordon/) - Mark node as unschedulable
|
||||
* [kubectl create](../kubectl_create/) - Create a resource by filename or stdin
|
||||
* [kubectl delete](../kubectl_delete/) - Delete resources by filenames, stdin, resources and names, or by resources and label selector.
|
||||
* [kubectl describe](../kubectl_describe/) - Show details of a specific resource or group of resources
|
||||
* [kubectl drain](../kubectl_drain/) - Drain node in preparation for maintenance
|
||||
* [kubectl edit](../kubectl_edit/) - Edit a resource on the server
|
||||
* [kubectl exec](../kubectl_exec/) - Execute a command in a container.
|
||||
* [kubectl explain](../kubectl_explain/) - Documentation of resources.
|
||||
* [kubectl expose](../kubectl_expose/) - Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service
|
||||
* [kubectl get](../kubectl_get/) - Display one or many resources
|
||||
* [kubectl label](../kubectl_label/) - Update the labels on a resource
|
||||
* [kubectl logs](../kubectl_logs/) - Print the logs for a container in a pod.
|
||||
* [kubectl namespace](../kubectl_namespace/) - SUPERSEDED: Set and view the current Kubernetes namespace
|
||||
* [kubectl patch](../kubectl_patch/) - Update field(s) of a resource using strategic merge patch.
|
||||
* [kubectl port-forward](../kubectl_port-forward/) - Forward one or more local ports to a pod.
|
||||
* [kubectl proxy](../kubectl_proxy/) - Run a proxy to the Kubernetes API server
|
||||
* [kubectl replace](../kubectl_replace/) - Replace a resource by filename or stdin.
|
||||
* [kubectl rolling-update](../kubectl_rolling-update/) - Perform a rolling update of the given ReplicationController.
|
||||
* [kubectl rollout](../kubectl_rollout/) - rollout manages a deployment
|
||||
* [kubectl run](../kubectl_run/) - Run a particular image on the cluster.
|
||||
* [kubectl scale](../kubectl_scale/) - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job.
|
||||
* [kubectl set](../kubectl_set/) - Set specific features on objects
|
||||
* [kubectl taint](../kubectl_taint/) - Update the taints on one or more nodes
|
||||
* [kubectl uncordon](../kubectl_uncordon/) - Mark node as schedulable
|
||||
* [kubectl version](../kubectl_version/) - Print the client and server version information.
|
||||
|
||||
###### Auto generated by spf13/cobra on 12-Aug-2016
|
||||
|
||||
|
||||
@@ -8,19 +8,28 @@
|
||||
## Overview
|
||||
|
||||
When creating a service, you have the option of automatically creating a
|
||||
network load balancer. This provides an
|
||||
cloud network load balancer. This provides an
|
||||
externally-accessible IP address that sends traffic to the correct port on your
|
||||
cluster nodes.
|
||||
cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_.
|
||||
|
||||
## External Load Balancer Providers
|
||||
|
||||
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
|
||||
|
||||
When the service type is set to `LoadBalancer`, Kubernetes provides functionality equivalent to type=`ClusterIP` to pods within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes VMs. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object.
|
||||
|
||||
## Configuration file
|
||||
|
||||
To create an external load balancer, add the following line to your
|
||||
[service configuration file](/docs/user-guide/services/operations/#service-configuration-file):
|
||||
|
||||
```json
|
||||
"type": "LoadBalancer"
|
||||
```
|
||||
|
||||
Your configuration file might look like:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
@@ -38,14 +47,17 @@ Your configuration file might look like:
|
||||
"type": "LoadBalancer"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Using kubectl
|
||||
|
||||
You can alternatively create the service with the `kubectl expose` command and
|
||||
its `--type=LoadBalancer` flag:
|
||||
|
||||
```bash
|
||||
$ kubectl expose rc example --port=8765 --target-port=9376 \
|
||||
--name=example-service --type=LoadBalancer
|
||||
```
|
||||
|
||||
This command creates a new service using the same selectors as the referenced
|
||||
resource (in the case of the example above, a replication controller named
|
||||
@@ -59,6 +71,7 @@ For more information, including optional flags, refer to the
|
||||
You can find the IP address created for your service by getting the service
|
||||
information through `kubectl`:
|
||||
|
||||
```bash
|
||||
$ kubectl describe services example-service
|
||||
Name: example-service
|
||||
Selector: app=example
|
||||
@@ -70,5 +83,70 @@ information through `kubectl`:
|
||||
Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
|
||||
Session Affinity: None
|
||||
No events.
|
||||
```
|
||||
|
||||
The IP address is listed next to `LoadBalancer Ingress`.
|
||||
|
||||
## Loss of client source IP for external traffic
|
||||
|
||||
Due to the implementation of this feature, the source IP for sessions as seen in the target container will *not be the original source IP* of the client. This is the default behavior as of Kubernetes v1.4. However, starting in v1.4, an optional alpha feature has been added
|
||||
that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases.
|
||||
|
||||
## Annotation to modify the LoadBalancer behavior for preservation of Source IP
|
||||
In 1.4, an Alpha feature has been added that changes the behavior of the external LoadBalancer feature.
|
||||
|
||||
This feature can be activated by adding the alpha annotation below to the metadata section of the Service Configuration file.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "example-service",
|
||||
"annotations": {
|
||||
"service.alpha.kubernetes.io/external-traffic": "OnlyLocal"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"ports": [{
|
||||
"port": 8765,
|
||||
"targetPort": 9376
|
||||
}],
|
||||
"selector": {
|
||||
"app": "example"
|
||||
},
|
||||
"type": "LoadBalancer"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Alpha Feature Gate for the 'service.alpha.kubernetes.io/external-traffic' annotation
|
||||
|
||||
Alpha features are not enabled by default, they must be enabled using the release gate command line flags
|
||||
for kube-controller-manager and kube-proxy.
|
||||
See [https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/runtimeconfig.md](Runtime feature flags proposal) for more details on feature gate flags.
|
||||
|
||||
If this feature is not enabled in your cluster, this annotation in your service configuration will be rejected.
|
||||
|
||||
### Implementation across different cloudproviders/environments
|
||||
|
||||
Note that this feature is not currently implemented for all cloudproviders/environments.
|
||||
This feature does not work for nodePorts yet, so environments/cloud providers with proxy-style load-balancers cannot use it yet.
|
||||
|
||||
### Caveats and Limitations when preserving source IPs
|
||||
|
||||
GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB
|
||||
kube-proxy rules which would correctly balance across all endpoints.
|
||||
|
||||
With the new functionality, the external traffic will not be equally load balanced across pods, but rather
|
||||
equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability
|
||||
for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
|
||||
pods on each node).
|
||||
|
||||
We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal
|
||||
distribution will be seen, even without weights.
|
||||
|
||||
Once the external load balancers provide weights, this functionality can be added to the LB programming path.
|
||||
*Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date*
|
||||
|
||||
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
|
||||
|
||||
@@ -20,6 +20,21 @@ A `PersistentVolume` (PV) is a piece of networked storage in the cluster that ha
|
||||
|
||||
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).
|
||||
|
||||
While `PersistentVolumeClaims` allow a user to consume abstract storage
|
||||
resources, it is common that users need `PersistentVolumes` with varying
|
||||
properties, such as performance, for different problems. Cluster administrators
|
||||
need to be able to offer a variety of `PersistentVolumes` that differ in more
|
||||
ways than just size and access modes, without exposing users to the details of
|
||||
how those volumes are implemented. For these needs there is the `StorageClass`
|
||||
resource.
|
||||
|
||||
A `StorageClass` provides a way for administrators to describe the "classes" of
|
||||
storage they offer. Different classes might map to quality-of-service levels,
|
||||
or to backup policies, or to arbitrary policies determined by the cluster
|
||||
administrators. Kubernetes itself is unopinionated about what classes
|
||||
represent. This concept is sometimes called "profiles" in other storage
|
||||
systems.
|
||||
|
||||
Please see the [detailed walkthrough with working examples](/docs/user-guide/persistent-volumes/walkthrough/).
|
||||
|
||||
|
||||
@@ -29,11 +44,17 @@ PVs are resources in the cluster. PVCs are requests for those resources and als
|
||||
|
||||
### Provisioning
|
||||
|
||||
A cluster administrator will create a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
|
||||
There are two ways PVs may be provisioned: statically or dynamically.
|
||||
|
||||
#### Static
|
||||
A cluster administrator creates a number of PVs. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
|
||||
|
||||
#### Dynamic
|
||||
When none of the static PVs the administrator created matches a user's `PersistentVolumeClaim`, the cluster may try to dynamically provision a volume specially for the PVC. This provisioning is based on `StorageClasses`: the PVC must request a class and the administrator must have created and configured that class in order for dynamic provisioning to occur. Claims that request the class `""` effectively disable dynamic provisioning for themselves.
|
||||
|
||||
### Binding
|
||||
|
||||
A user creates a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. The user will always get at least what they asked for, but the volume may be in excess of what was requested.
|
||||
A user creates, or has already created in the case of dynamic provisioning, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of the mode used to bind them.
|
||||
|
||||
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
||||
|
||||
@@ -49,7 +70,7 @@ When a user is done with their volume, they can delete the PVC objects from the
|
||||
|
||||
### Reclaiming
|
||||
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted. If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
|
||||
## Types of Persistent Volumes
|
||||
|
||||
@@ -78,6 +99,8 @@ Each PV contains a spec and status, which is the specification and status of the
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: pv0003
|
||||
annotations:
|
||||
volume.beta.kubernetes.io/storage-class: "slow"
|
||||
spec:
|
||||
capacity:
|
||||
storage: 5Gi
|
||||
@@ -130,6 +153,16 @@ In the CLI, the access modes are abbreviated to:
|
||||
| RDB | x | x | - |
|
||||
| VsphereVolume | x | - | - |
|
||||
|
||||
### Class
|
||||
|
||||
A PV can have a class, which is specified by setting the
|
||||
`volume.beta.kubernetes.io/storage-class` annotation to the name of a
|
||||
`StorageClass`. A PV of a particular class can only be bound to PVCs requesting
|
||||
that class. A PV with no annotation or its class annotation set to `""` has no
|
||||
class and can only be bound to PVCs that request no particular class.
|
||||
|
||||
In the future after beta, the `volume.beta.kubernetes.io/storage-class`
|
||||
annotation will become an attribute.
|
||||
|
||||
### Recycling Policy
|
||||
|
||||
@@ -161,6 +194,8 @@ kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: myclaim
|
||||
annotations:
|
||||
volume.beta.kubernetes.io/storage-class: "slow"
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
@@ -191,6 +226,41 @@ Claims can specify a [label selector](/docs/user-guide/labels/#label-selectors)
|
||||
|
||||
All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together – they must all be satisfied in order to match.
|
||||
|
||||
### Class
|
||||
|
||||
A claim can request a particular class by specifying the name of a
|
||||
`StorageClass`using the annotation `volume.beta.kubernetes.io/storage-class`.
|
||||
Only PVs of the requested class, ones with the same annotation as the PVC, can
|
||||
be bound to the PVC.
|
||||
|
||||
PVCs don't necessarily have to request a class. A PVC with its annotation set
|
||||
equal to `""` is always interpreted to be requesting a PV with no class, so it
|
||||
can only be bound to PVs with no class (no annotation or one set equal to
|
||||
`""`). A PVC with no annotation is not quite the same and is treated differently
|
||||
by the cluster depending on whether the
|
||||
[`DefaultStorageClass` admission plugin](docs/admin/admission-controllers/#defaultstorageclass)
|
||||
is turned on.
|
||||
|
||||
* If the admission plugin is turned on, the administrator may specify a
|
||||
default `StorageClass`. All PVCs that have no annotation can be bound only to
|
||||
PVs of that default. Specifying a default `StorageClass` is done by setting the
|
||||
annotation `storageclass.beta.kubernetes.io/is-default-class` equal to "true" in
|
||||
a `StorageClass` object. If the administrator does not specify a default, the
|
||||
cluster responds to PVC creation as if the admission plugin were turned off. If
|
||||
more than one default is specified, the admission plugin forbids the creation of
|
||||
all PVCs.
|
||||
* If the admission plugin is turned off, there is no notion of a default
|
||||
`StorageClass`. All PVCs that have no annotation can be bound only to PVs that
|
||||
have no class. In this case the PVCs that have no annotation are treated the
|
||||
same way as PVCs that have their annotation set to `""`.
|
||||
|
||||
When a PVC specifies a `selector` in addition to requesting a `StorageClass`,
|
||||
the requirements are ANDed together: only a PV of the requested class and with
|
||||
the requested labels may be bound to the PVC.
|
||||
|
||||
In the future after beta, the `volume.beta.kubernetes.io/storage-class`
|
||||
annotation will become an attribute.
|
||||
|
||||
## Claims As Volumes
|
||||
|
||||
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod's namespace and uses it to get the `PersistentVolume` backing the claim. The volume is then mounted to the host and into the pod.
|
||||
@@ -212,3 +282,120 @@ spec:
|
||||
persistentVolumeClaim:
|
||||
claimName: myclaim
|
||||
```
|
||||
|
||||
### A Note on Namespaces
|
||||
|
||||
`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
|
||||
|
||||
## StorageClasses
|
||||
|
||||
Each `StorageClass` contains the fields `provisioner` and `parameters`, which
|
||||
are used when a `PersistentVolume` belonging to the class needs to be
|
||||
dynamically provisioned.
|
||||
|
||||
The name of a `StorageClass` object is significant, and is how users can
|
||||
request a particular class. Administrators set the name and other parameters
|
||||
of a class, all of which are opaque to users, when first creating
|
||||
`StorageClass` objects, and the objects cannot be updated once they are
|
||||
created.
|
||||
|
||||
Administrators can specify a default `StorageClass` just for PVCs that don't
|
||||
request any particular class to bind to: see the
|
||||
[`PersistentVolumeClaim` section](docs/user-guide/persistent-volumes/#class-1)
|
||||
for details.
|
||||
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: extensions/v1beta1
|
||||
metadata:
|
||||
name: standard
|
||||
provisioner: kubernetes.io/aws-ebs
|
||||
parameters:
|
||||
type: gp2
|
||||
```
|
||||
|
||||
### Provisioner
|
||||
Storage classes have a provisioner that determines what volume plugin is used
|
||||
for provisioning PVs. This field must be specified. During beta, the available
|
||||
provisioner types are `kubernetes.io/aws-ebs` and `kubernetes.io/gce-pd`.
|
||||
|
||||
### Parameters
|
||||
Storage classes have parameters that describe volumes belonging to the storage
|
||||
class. Different parameters may be accepted depending on the `provisioner`. For
|
||||
example, the value `io1`, for the parameter `type`, and the parameter
|
||||
`iopsPerGB` are specific to EBS. When a parameter is omitted, some default is
|
||||
used.
|
||||
|
||||
#### AWS
|
||||
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: extensions/v1beta1
|
||||
metadata:
|
||||
name: slow
|
||||
provisioner: kubernetes.io/aws-ebs
|
||||
parameters:
|
||||
type: io1
|
||||
zone: us-east-1d
|
||||
iopsPerGB: "10"
|
||||
```
|
||||
|
||||
* `type`: `io1`, `gp2`, `sc1`, `st1`. See [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) for details. Default: `gp2`.
|
||||
* `zone`: AWS zone. If not specified, a random zone from those where Kubernetes cluster has a node is chosen.
|
||||
* `iopsPerGB`: only for `io1` volumes. I/O operations per second per GiB. AWS volume plugin multiplies this with size of requested volume to compute IOPS of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see [AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html). A string is expected here, i.e. `"10"`, not `10`.
|
||||
* `encrypted`: denotes whether the EBS volume should be encrypted or not. Valid values are `"true"` or `"false"`. A string is expected here, i.e. `"true"`, not `true`.
|
||||
* `kmsKeyId`: optional. The full Amazon Resource Name of the key to use when encrypting the volume. If none is supplied but `encrypted` is true, a key is generated by AWS. See AWS docs for valid ARN value.
|
||||
|
||||
#### GCE
|
||||
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: extensions/v1beta1
|
||||
metadata:
|
||||
name: slow
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
parameters:
|
||||
type: pd-standard
|
||||
zone: us-central1-a
|
||||
```
|
||||
|
||||
* `type`: `pd-standard` or `pd-ssd`. Default: `pd-ssd`
|
||||
* `zone`: GCE zone. If not specified, a random zone in the same region as controller-manager will be chosen.
|
||||
|
||||
#### GLUSTERFS
|
||||
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: slow
|
||||
provisioner: kubernetes.io/glusterfs
|
||||
parameters:
|
||||
endpoint: "glusterfs-cluster"
|
||||
resturl: "http://127.0.0.1:8081"
|
||||
restauthenabled: "true"
|
||||
restuser: "admin"
|
||||
restuserkey: "password"
|
||||
```
|
||||
|
||||
* `endpoint`: `glusterfs-cluster` is the endpoint/service name which includes GlusterFS trusted pool IP addresses and this parameter is mandatory.
|
||||
* `resturl` : Gluster REST service url which provision gluster volumes on demand. The format should be `IPaddress:Port` and this is a mandatory parameter for GlusterFS dynamic provisioner.
|
||||
* `restauthenabled` : Gluster REST service authentication boolean is required if the authentication is enabled on the REST server. If this value is 'true', 'restuser' and 'restuserkey' have to be filled.
|
||||
* `restuser` : Gluster REST service user who has access to create volumes in the Gluster Trusted Pool.
|
||||
* `restuserkey` : Gluster REST service user's password which will be used for authentication to the REST server.
|
||||
|
||||
#### OpenStack Cinder
|
||||
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: extensions/v1beta1
|
||||
metadata:
|
||||
name: gold
|
||||
provisioner: kubernetes.io/cinder
|
||||
parameters:
|
||||
type: fast
|
||||
availability: nova
|
||||
```
|
||||
|
||||
* `type`: [VolumeType](http://docs.openstack.org/admin-guide/dashboard-manage-volumes.html) created in Cinder. Default is empty.
|
||||
* `availability`: Availability Zone. Default is empty.
|
||||
|
||||
@@ -83,7 +83,7 @@ Example workloads for Pet Set:
|
||||
Before you start deploying applications as Pet Sets, there are a few limitations you should understand.
|
||||
|
||||
* Pet Set is an *alpha* resource, not available in any Kubernetes release prior to 1.3.
|
||||
* As with all alpha/beta resources, it can be disable through the `--runtime-config` option passed to the apiserver, and in fact most likely will be disabled on hosted offerings of Kubernetes.
|
||||
* As with all alpha/beta resources, it can be disabled through the `--runtime-config` option passed to the apiserver, and in fact most likely will be disabled on hosted offerings of Kubernetes.
|
||||
* The only updatable field on a Pet Set is `replicas`
|
||||
* The storage for a given pet must either be provisioned by a [dynamic storage provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that dynamic volume provisioning is also currently in alpha.
|
||||
* Deleting the Pet Set *will not* delete any pets. You will either have to manually scale it down to 0 pets first, or delete the pets yourself.
|
||||
@@ -145,7 +145,7 @@ Cluster Domain | Service (ns/name) | Pet Set (ns/name) | Pet Set Domain | Pet DN
|
||||
|
||||
Note that Cluster Domain will be set to `cluster.local` unless [otherwise configured](http://releases.k8s.io/{{page.githubbranch}}/build/kube-dns/README.md#how-do-i-configure-it).
|
||||
|
||||
Lets verify our assertion with a simple test.
|
||||
Let's verify our assertion with a simple test.
|
||||
|
||||
```shell
|
||||
$ kubectl get svc
|
||||
@@ -154,7 +154,7 @@ nginx None <none> 80/TCP 12m
|
||||
...
|
||||
```
|
||||
|
||||
First, the PetSet gives provides a stable hostname:
|
||||
First, the PetSet provides a stable hostname:
|
||||
|
||||
```shell
|
||||
$ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
||||
@@ -181,7 +181,7 @@ Name: web-1.nginx
|
||||
Address 1: 10.180.0.9
|
||||
```
|
||||
|
||||
The containers are running nginx webservers, which by default will look for an index.html file in `/usr/share/nginx/html/index.html`. That directory is backed by a `PersistentVolume` created by the Pet Set. So lets write our hostname there:
|
||||
The containers are running nginx webservers, which by default will look for an index.html file in `/usr/share/nginx/html/index.html`. That directory is backed by a `PersistentVolume` created by the Pet Set. So let's write our hostname there:
|
||||
|
||||
```shell
|
||||
$ for i in 0 1; do
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.3 KiB |
Reference in New Issue
Block a user