merge master to 1.10, with fixes (#7682)
This commit is contained in:
Jennifer Rondeau
committed by
zacharysarah
zacharysarah
parent
7f40782850
commit
3d79703d23
@@ -147,9 +147,16 @@ For examples of device plugin implementations, see:
|
||||
* The official [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
|
||||
* it requires using [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers
|
||||
* The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
|
||||
<<<<<<< HEAD
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
||||||| merged common ancestors
|
||||
|
||||
=======
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -1,5 +1,13 @@
|
||||
---
|
||||
<<<<<<< HEAD
|
||||
reviewers:
|
||||
||||||| merged common ancestors
|
||||
approvers:
|
||||
- crassirostris
|
||||
=======
|
||||
reviewers:
|
||||
- crassirostris
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
- piosz
|
||||
- x13n
|
||||
title: Logging Architecture
|
||||
|
||||
@@ -55,7 +55,13 @@ deployment "nginx-deployment" created
|
||||
Resource creation isn't the only operation that `kubectl` can perform in bulk. It can also extract resource names from configuration files in order to perform other operations, in particular to delete the same resources you created:
|
||||
|
||||
```shell
|
||||
<<<<<<< HEAD
|
||||
$ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml
|
||||
||||||| merged common ancestors
|
||||
$ kubectl delete -f docs/user-guide/nginx/
|
||||
=======
|
||||
$ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx/
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
deployment "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx-deployment
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-nginx
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
@@ -59,6 +59,7 @@ The following controllers have cloud provider dependencies:
|
||||
* Service Controller: For creating, updating and deleting cloud provider load balancers
|
||||
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
|
||||
|
||||
<<<<<<< HEAD
|
||||
## Node Components
|
||||
|
||||
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
|
||||
@@ -77,6 +78,28 @@ network rules on the host and performing connection forwarding.
|
||||
The container runtime is the software that is responsible for running containers. Kubernetes supports several runtimes: [Docker](http://www.docker.com), [rkt](https://coreos.com/rkt/), [runc](https://github.com/opencontainers/runc) and any OCI [runtime-spec](https://github.com/opencontainers/runtime-spec) implementation.
|
||||
|
||||
## Addons
|
||||
||||||| merged common ancestors
|
||||
### addons
|
||||
=======
|
||||
## Node Components
|
||||
|
||||
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
|
||||
|
||||
### kubelet
|
||||
|
||||
{% glossary_definition term_id="kubelet" length="all" %}
|
||||
|
||||
### kube-proxy
|
||||
|
||||
[kube-proxy](/docs/admin/kube-proxy/) enables the Kubernetes service abstraction by maintaining
|
||||
network rules on the host and performing connection forwarding.
|
||||
|
||||
### Container Runtime
|
||||
|
||||
The container runtime is the software that is responsible for running containers. Kubernetes supports two runtimes: [Docker](http://www.docker.com) and [rkt](https://coreos.com/rkt/).
|
||||
|
||||
## Addons
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
Addons are pods and services that implement cluster features. The pods may be managed
|
||||
by Deployments, ReplicationControllers, and so on. Namespaced addon objects are created in
|
||||
|
||||
@@ -25,8 +25,16 @@ Resource quotas work like this:
|
||||
status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
|
||||
- If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
|
||||
requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use
|
||||
<<<<<<< HEAD
|
||||
the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements.
|
||||
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
|
||||
||||||| merged common ancestors
|
||||
the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
|
||||
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example to avoid this problem.
|
||||
=======
|
||||
the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
|
||||
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
Examples of policies that could be created using namespaces and quotas are:
|
||||
|
||||
@@ -42,8 +50,16 @@ Neither contention nor changes to quota will affect already created resources.
|
||||
|
||||
## Enabling Resource Quota
|
||||
|
||||
<<<<<<< HEAD
|
||||
Resource Quota support is enabled by default for many Kubernetes distributions. It is
|
||||
enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as
|
||||
||||||| merged common ancestors
|
||||
Resource Quota support is enabled by default for many Kubernetes distributions. It is
|
||||
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
|
||||
=======
|
||||
Resource quota support is enabled by default for many Kubernetes distributions. It is
|
||||
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
one of its arguments.
|
||||
|
||||
A resource quota is enforced in a particular namespace when there is a
|
||||
@@ -235,6 +251,7 @@ NAME AGE
|
||||
compute-resources 30s
|
||||
object-counts 32s
|
||||
|
||||
<<<<<<< HEAD
|
||||
kubectl describe quota compute-resources --namespace=myspace
|
||||
Name: compute-resources
|
||||
Namespace: myspace
|
||||
@@ -249,6 +266,33 @@ requests.nvidia.com/gpu 0 4
|
||||
|
||||
|
||||
kubectl describe quota object-counts --namespace=myspace
|
||||
||||||| merged common ancestors
|
||||
$ kubectl describe quota compute-resources --namespace=myspace
|
||||
Name: compute-resources
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
-------- ---- ----
|
||||
limits.cpu 0 2
|
||||
limits.memory 0 2Gi
|
||||
pods 0 4
|
||||
requests.cpu 0 1
|
||||
requests.memory 0 1Gi
|
||||
|
||||
$ kubectl describe quota object-counts --namespace=myspace
|
||||
=======
|
||||
kubectl describe quota compute-resources --namespace=myspace
|
||||
Name: compute-resources
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
-------- ---- ----
|
||||
limits.cpu 0 2
|
||||
limits.memory 0 2Gi
|
||||
pods 0 4
|
||||
requests.cpu 0 1
|
||||
requests.memory 0 1Gi
|
||||
|
||||
kubectl describe quota object-counts --namespace=myspace
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
Name: object-counts
|
||||
Namespace: myspace
|
||||
Resource Used Hard
|
||||
|
||||
@@ -175,8 +175,26 @@ The `Retain` reclaim policy allows for manual reclamation of the resource. When
|
||||
1. Manually clean up the data on the associated storage asset accordingly.
|
||||
1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new `PersistentVolume` with the storage asset definition.
|
||||
|
||||
<<<<<<< HEAD
|
||||
#### Delete
|
||||
|
||||
For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
|
||||
||||||| merged common ancestors
|
||||
#### Recycling
|
||||
=======
|
||||
#### Delete
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
<<<<<<< HEAD
|
||||
#### Recycle
|
||||
|
||||
**Warning:** The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
|
||||
{: .warning}
|
||||
|
||||
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
||||||| merged common ancestors
|
||||
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.
|
||||
=======
|
||||
For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
|
||||
|
||||
#### Recycle
|
||||
@@ -185,6 +203,7 @@ For volume plugins that support the `Delete` reclaim policy, deletion removes bo
|
||||
{: .warning}
|
||||
|
||||
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
However, an administrator can configure a custom recycler pod template using the Kubernetes controller manager command line arguments as described [here](/docs/admin/kube-controller-manager/). The custom recycler pod template must contain a `volumes` specification, as shown in the example below:
|
||||
|
||||
@@ -242,8 +261,16 @@ parameters:
|
||||
allowVolumeExpansion: true
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
Once both feature gate and the aforementioned admission plug-in are turned on, a user can request larger volume for their `PersistentVolumeClaim`
|
||||
by simply editing the claim and requesting a larger size. This in turn will trigger expansion of the volume that is backing the underlying `PersistentVolume`.
|
||||
||||||| merged common ancestors
|
||||
Once both feature gate and aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
|
||||
by simply editing the claim and requesting bigger size. This in turn will trigger expansion of volume that is backing underlying `PersistentVolume`.
|
||||
=======
|
||||
Once both feature gate and the aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
|
||||
by simply editing the claim and requesting a larger size. This in turn will trigger expansion of the volume that is backing the underlying `PersistentVolume`.
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
Under no circumstances will a new `PersistentVolume` be created to satisfy the claim. Kubernetes will instead attempt to resize the existing volume.
|
||||
|
||||
|
||||
@@ -211,12 +211,50 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`"
|
||||
Note that this path is derived from the volume's `mountPath` and the `path`
|
||||
keyed with `log_level`.
|
||||
|
||||
<<<<<<< HEAD
|
||||
**Important:** You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
|
||||
{: .caution}
|
||||
|
||||
**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
|
||||
receive ConfigMap updates.
|
||||
{: .note}
|
||||
||||||| merged common ancestors
|
||||
### csi
|
||||
|
||||
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
|
||||
a specification attempting to establish an industry standard interface that
|
||||
Container Orchestration Systems (COs) can use to expose arbitrary storage systems
|
||||
to their container workloads.
|
||||
For more information about the details, please check the
|
||||
[design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md).
|
||||
|
||||
<!-- TODO: add link to the kubernetes extension section -->
|
||||
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
|
||||
with external CSI volume drivers running on the same node.
|
||||
After having deployed a CSI compatible volume driver, users can use `csi` as the
|
||||
volume type to mount the storage provided by the driver.
|
||||
|
||||
CSI persistent volume support is introduced in Kubernetes v1.9 as an alpha feature
|
||||
which has to be explicitly enabled by the cluster administrator. In other words,
|
||||
the cluster administrator needs to add "`CSIPersistentVolume=true`" to the
|
||||
"`--feature-gates=`" flag for the apiserver, the controller-manager and the kubelet
|
||||
components.
|
||||
|
||||
A CSI persistent volume has the following fields for users to specify:
|
||||
|
||||
- `driver`: A string value that specifies the name of the volume driver to use.
|
||||
It has to be less than 63 characters and starts with a character. The driver
|
||||
name can have '`.`', '`-`', '`_`' or digits in it.
|
||||
- `volumeHandle`: A string value that uniquely identify the volume name returned
|
||||
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
|
||||
used in all subsequent calls to the the volume driver for referencing the volume.
|
||||
- `readOnly`: An optional boolean value indicating whether the volume is to be
|
||||
published as read only. Default is false.
|
||||
=======
|
||||
**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
|
||||
receive ConfigMap updates.
|
||||
{: .note}
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
### downwardAPI
|
||||
|
||||
@@ -1020,15 +1058,72 @@ specification, and to select the type of media to use, for clusters that have
|
||||
several media types.
|
||||
|
||||
## Out-of-Tree Volume Plugins
|
||||
<<<<<<< HEAD
|
||||
The Out-of-tree volume plugins include the Container Storage Interface (`CSI`)
|
||||
and `FlexVolume`. They enable storage vendors to create custom storage plugins
|
||||
without adding them to the Kubernetes repository.
|
||||
||||||| merged common ancestors
|
||||
In addition to the previously listed volume types, storage vendors may create
|
||||
custom plugins without adding it to the Kubernetes repository. This can be
|
||||
achieved by using the `FlexVolume` plugin.
|
||||
=======
|
||||
In addition to the previously listed volume types, storage vendors may create
|
||||
custom plugins without adding it to the Kubernetes repository. This can be
|
||||
achieved by using either the `CSI` plugin or the `FlexVolume` plugin.
|
||||
|
||||
For storage vendors looking to create an out-of-tree volume plugin, [please refer to this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for choosing between the plugin options.
|
||||
|
||||
### CSI
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
<<<<<<< HEAD
|
||||
Before the introduction of `CSI` and `FlexVolume`, all volume plugins (like
|
||||
volume types listed above) were "in-tree" meaning they were built, linked,
|
||||
compiled, and shipped with the core Kubernetes binaries and extend the core
|
||||
Kubernetes API. This meant that adding a new storage system to Kubernetes (a
|
||||
volume plugin) required checking code into the core Kubernetes code repository.
|
||||
||||||| merged common ancestors
|
||||
`FlexVolume` enables users to mount vendor volumes into a pod. The vendor plugin
|
||||
is implemented using a driver, an executable supporting a list of volume commands
|
||||
defined by the `FlexVolume` API. Drivers must be installed in a pre-defined
|
||||
volume plugin path on each node.
|
||||
=======
|
||||
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
|
||||
a specification attempting to establish an industry standard interface that
|
||||
container orchestration systems can use to expose arbitrary storage systems
|
||||
to their container workloads.
|
||||
Please read
|
||||
[CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for further information.
|
||||
|
||||
<!-- TODO: add link to the kubernetes extension section -->
|
||||
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
|
||||
with external CSI volume drivers running on the same node.
|
||||
After having deployed a CSI compatible volume driver, users can use `csi` as the
|
||||
volume type to mount the storage provided by the driver.
|
||||
|
||||
CSI persistent volume support is an alpha feature in Kubernetes v1.9 and requires a
|
||||
cluster administrator to enable it. To enable CSI persistent volume support, the
|
||||
cluster administrator adds `CSIPersistentVolume=true` to the `--feature-gates` flag
|
||||
for apiserver, controller-manager, and kubelet.
|
||||
|
||||
The following fields are available to storage administrators to configure a CSI
|
||||
persistent volume:
|
||||
|
||||
- `driver`: A string value that specifies the name of the volume driver to use.
|
||||
It has to be less than 63 characters and starts with a character. The driver
|
||||
name can have '`.`', '`-`', '`_`' or digits in it.
|
||||
- `volumeHandle`: A string value that uniquely identify the volume name returned
|
||||
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
|
||||
used in all subsequent calls to the volume driver for referencing the volume.
|
||||
- `readOnly`: An optional boolean value indicating whether the volume is to be
|
||||
published as read only. Default is false.
|
||||
|
||||
### FlexVolume
|
||||
`FlexVolume` enables users to mount vendor volumes into a pod. The vendor plugin
|
||||
is implemented using a driver, an executable supporting a list of volume commands
|
||||
defined by the `FlexVolume` API. Drivers must be installed in a pre-defined
|
||||
volume plugin path on each node. Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
|
||||
Both `CSI` and `FlexVolume` allow volume plugins to be developed independent of
|
||||
the Kubernetes code base, and deployed (installed) on Kubernetes clusters as
|
||||
@@ -1047,6 +1142,7 @@ Kubernetes) to expose arbitrary storage systems to their container workloads.
|
||||
|
||||
Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information.
|
||||
|
||||
<<<<<<< HEAD
|
||||
CSI support was introduced as alpha in Kubernetes v1.9 and moved to beta in
|
||||
Kubernets v1.10.
|
||||
|
||||
@@ -1114,6 +1210,10 @@ plugin path on each node (and in some cases master).
|
||||
Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
|
||||
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).
|
||||
|
||||
||||||| merged common ancestors
|
||||
|
||||
=======
|
||||
>>>>>>> merge master to 1.10, with fixes (#7682)
|
||||
## Mount propagation
|
||||
|
||||
{% assign for_k8s_version="v1.10" %}{% include feature-state-beta.md %}
|
||||
|
||||
Reference in New Issue
Block a user