Merge remote-tracking branch 'upstream/master' into merged-master-release-1.15
This commit is contained in:
simplytunde
@@ -139,7 +139,7 @@ happens before the scheduler actually binds the Pod to the Node, and it exists
|
||||
to prevent race conditions while the scheduler waits for the bind to succeed.
|
||||
|
||||
This is the last step in a scheduling cycle. Once a Pod is in the reserved
|
||||
state, it will either trigger [Un-reserve](#un-reserve) plugins (on failure) or
|
||||
state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
|
||||
[Post-bind](#post-bind) plugins (on success) at the end of the binding cycle.
|
||||
|
||||
*Note: This concept used to be referred to as "assume".*
|
||||
@@ -154,13 +154,13 @@ can do one of three things.
|
||||
|
||||
1. **deny** \
|
||||
If any permit plugin denies a Pod, it is returned to the scheduling queue.
|
||||
This will trigger [Un-reserve](#un-reserve) plugins.
|
||||
This will trigger [Unreserve](#unreserve) plugins.
|
||||
|
||||
1. **wait** (with a timeout) \
|
||||
If a permit plugin returns "wait", then the Pod is kept in the permit phase
|
||||
until a [plugin approves it](#frameworkhandle). If a timeout occurs, **wait**
|
||||
becomes **deny** and the Pod is returned to the scheduling queue, triggering
|
||||
[un-reserve](#un-reserve) plugins.
|
||||
[Unreserve](#unreserve) plugins.
|
||||
|
||||
**Approving a Pod binding**
|
||||
|
||||
@@ -175,7 +175,7 @@ These plugins are used to perform any work required before a Pod is bound. For
|
||||
example, a pre-bind plugin may provision a network volume and mount it on the
|
||||
target node before allowing the Pod to run there.
|
||||
|
||||
If any pre-bind plugin returns an error, the Pod is [rejected](#un-reserve) and
|
||||
If any pre-bind plugin returns an error, the Pod is [rejected](#unreserve) and
|
||||
returned to the scheduling queue.
|
||||
|
||||
### Bind
|
||||
|
||||
@@ -34,7 +34,7 @@ administrator to control the following:
|
||||
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
|
||||
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
|
||||
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
|
||||
| White list of Flexvolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
|
||||
| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
|
||||
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
|
||||
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
|
||||
| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
|
||||
@@ -463,12 +463,12 @@ to effectively limit access to the specified `pathPrefix`.
|
||||
**ReadOnlyRootFilesystem** - Requires that containers must run with a read-only
|
||||
root filesystem (i.e. no writable layer).
|
||||
|
||||
### Flexvolume drivers
|
||||
### FlexVolume drivers
|
||||
|
||||
This specifies a whitelist of Flexvolume drivers that are allowed to be used
|
||||
This specifies a whitelist of FlexVolume drivers that are allowed to be used
|
||||
by flexvolume. An empty list or nil means there is no restriction on the drivers.
|
||||
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
|
||||
`flexVolume` volume type; no Flexvolume driver is allowed otherwise.
|
||||
`flexVolume` volume type; no FlexVolume driver is allowed otherwise.
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
@@ -351,7 +351,7 @@ In the CLI, the access modes are abbreviated to:
|
||||
| Cinder | ✓ | - | - |
|
||||
| CSI | depends on the driver | depends on the driver | depends on the driver |
|
||||
| FC | ✓ | ✓ | - |
|
||||
| Flexvolume | ✓ | ✓ | depends on the driver |
|
||||
| FlexVolume | ✓ | ✓ | depends on the driver |
|
||||
| Flocker | ✓ | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ |
|
||||
|
||||
@@ -72,7 +72,7 @@ for provisioning PVs. This field must be specified.
|
||||
| CephFS | - | - |
|
||||
| Cinder | ✓ | [OpenStack Cinder](#openstack-cinder)|
|
||||
| FC | - | - |
|
||||
| Flexvolume | - | - |
|
||||
| FlexVolume | - | - |
|
||||
| Flocker | ✓ | - |
|
||||
| GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) |
|
||||
| Glusterfs | ✓ | [Glusterfs](#glusterfs) |
|
||||
@@ -92,14 +92,15 @@ alongside Kubernetes). You can also run and specify external provisioners,
|
||||
which are independent programs that follow a [specification](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)
|
||||
defined by Kubernetes. Authors of external provisioners have full discretion
|
||||
over where their code lives, how the provisioner is shipped, how it needs to be
|
||||
run, what volume plugin it uses (including Flex), etc. The repository [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage)
|
||||
run, what volume plugin it uses (including Flex), etc. The repository
|
||||
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
|
||||
houses a library for writing external provisioners that implements the bulk of
|
||||
the specification plus various community-maintained external provisioners.
|
||||
the specification. Some external provisioners are listed under the repository
|
||||
[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
|
||||
|
||||
For example, NFS doesn't provide an internal provisioner, but an external provisioner
|
||||
can be used. Some external provisioners are listed under the repository [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
|
||||
There are also cases when 3rd party storage vendors provide their own external
|
||||
provisioner.
|
||||
For example, NFS doesn't provide an internal provisioner, but an external
|
||||
provisioner can be used. There are also cases when 3rd party storage
|
||||
vendors provide their own external provisioner.
|
||||
|
||||
### Reclaim Policy
|
||||
|
||||
|
||||
@@ -1205,16 +1205,16 @@ several media types.
|
||||
|
||||
## Out-of-Tree Volume Plugins
|
||||
The Out-of-tree volume plugins include the Container Storage Interface (CSI)
|
||||
and Flexvolume. They enable storage vendors to create custom storage plugins
|
||||
and FlexVolume. They enable storage vendors to create custom storage plugins
|
||||
without adding them to the Kubernetes repository.
|
||||
|
||||
Before the introduction of CSI and Flexvolume, all volume plugins (like
|
||||
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.
|
||||
|
||||
Both CSI and Flexvolume allow volume plugins to be developed independent of
|
||||
Both CSI and FlexVolume allow volume plugins to be developed independent of
|
||||
the Kubernetes code base, and deployed (installed) on Kubernetes clusters as
|
||||
extensions.
|
||||
|
||||
@@ -1371,14 +1371,14 @@ provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
|
||||
In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
|
||||
are listed in the "Types of Volumes" section above.
|
||||
|
||||
### Flexvolume {#flexVolume}
|
||||
### FlexVolume {#flexVolume}
|
||||
|
||||
Flexvolume is an out-of-tree plugin interface that has existed in Kubernetes
|
||||
FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes
|
||||
since version 1.2 (before CSI). It uses an exec-based model to interface with
|
||||
drivers. Flexvolume driver binaries must be installed in a pre-defined volume
|
||||
drivers. FlexVolume driver binaries must be installed in a pre-defined volume
|
||||
plugin path on each node (and in some cases master).
|
||||
|
||||
Pods interact with Flexvolume drivers through the `flexvolume` in-tree plugin.
|
||||
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/sig-storage/flexvolume.md).
|
||||
|
||||
## Mount propagation
|
||||
@@ -1414,7 +1414,7 @@ Its values are:
|
||||
In addition, all volume mounts created by the Container will be propagated
|
||||
back to the host and to all Containers of all Pods that use the same volume.
|
||||
|
||||
A typical use case for this mode is a Pod with a Flexvolume or CSI driver or
|
||||
A typical use case for this mode is a Pod with a FlexVolume or CSI driver or
|
||||
a Pod that needs to mount something on the host using a `hostPath` volume.
|
||||
|
||||
This mode is equal to `rshared` mount propagation as described in the
|
||||
|
||||
@@ -194,14 +194,12 @@ You can modify the Pods that a DaemonSet creates. However, Pods do not allow al
|
||||
fields to be updated. Also, the DaemonSet controller will use the original template the next
|
||||
time a node (even with the same name) is created.
|
||||
|
||||
|
||||
You can delete a DaemonSet. If you specify `--cascade=false` with `kubectl`, then the Pods
|
||||
will be left on the nodes. You can then create a new DaemonSet with a different template.
|
||||
The new DaemonSet with the different template will recognize all the existing Pods as having
|
||||
matching labels. It will not modify or delete them despite a mismatch in the Pod template.
|
||||
You will need to force new Pod creation by deleting the Pod or deleting the node.
|
||||
will be left on the nodes. If you subsequently create a new DaemonSet with the same selector,
|
||||
the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces
|
||||
them according to its `updateStrategy`.
|
||||
|
||||
In Kubernetes version 1.6 and later, you can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
|
||||
You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
|
||||
|
||||
## Alternatives to DaemonSet
|
||||
|
||||
|
||||
@@ -229,7 +229,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
Next time you want to update these Pods, you only need to update the Deployment's Pod template again.
|
||||
|
||||
Deployment ensures that only a certain number of Pods are down while they are being updated. By default,
|
||||
it ensures that at least 25% of the desired number of Pods are up (25% max unavailable).
|
||||
it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).
|
||||
|
||||
Deployment also ensures that only a certain number of Pods are created above the desired number of Pods.
|
||||
By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge).
|
||||
|
||||
@@ -94,7 +94,7 @@ following cases (not an exhaustive list):
|
||||
- The code is not generic enough for users to try out. As an example, you can
|
||||
embed the YAML
|
||||
file for creating a Pod which depends on a specific
|
||||
[Flexvolume](/docs/concepts/storage/volumes#flexvolume) implementation.
|
||||
[FlexVolume](/docs/concepts/storage/volumes#flexvolume) implementation.
|
||||
- The code is an incomplete example because its purpose is to highlight a
|
||||
portion of a larger file. For example, when describing ways to
|
||||
customize the [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
|
||||
|
||||
@@ -89,10 +89,10 @@ To see which admission plugins are enabled:
|
||||
kube-apiserver -h | grep enable-admission-plugins
|
||||
```
|
||||
|
||||
In 1.14, they are:
|
||||
In 1.15, they are:
|
||||
|
||||
```shell
|
||||
NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota
|
||||
NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota, StorageObjectInUseProtection
|
||||
```
|
||||
|
||||
## What does each admission controller do?
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
---
|
||||
title: Flexvolume
|
||||
title: FlexVolume
|
||||
id: flexvolume
|
||||
date: 2018-06-25
|
||||
full_link: /docs/concepts/storage/volumes/#flexvolume
|
||||
short_description: >
|
||||
Flexvolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with Flexvolumes.
|
||||
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
|
||||
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- storage
|
||||
---
|
||||
Flexvolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with Flexvolumes.
|
||||
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Flexvolumes enable users to write their own drivers and add support for their volumes in Kubernetes. FlexVolume driver binaries and dependencies must be installed on host machines. This requires root access. The Storage SIG suggests implementing a {{< glossary_tooltip text="CSI" term_id="csi" >}} driver if possible since it addresses the limitations with Flexvolumes.
|
||||
FlexVolumes enable users to write their own drivers and add support for their volumes in Kubernetes. FlexVolume driver binaries and dependencies must be installed on host machines. This requires root access. The Storage SIG suggests implementing a {{< glossary_tooltip text="CSI" term_id="csi" >}} driver if possible since it addresses the limitations with FlexVolumes.
|
||||
|
||||
* [Flexvolume in the Kubernetes documentation](/docs/concepts/storage/volumes/#flexvolume)
|
||||
* [More information on Flexvolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)
|
||||
* [FlexVolume in the Kubernetes documentation](/docs/concepts/storage/volumes/#flexvolume)
|
||||
* [More information on FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)
|
||||
* [Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)
|
||||
|
||||
@@ -37,7 +37,7 @@ Can be used to create all required certificates by kubeadm.
|
||||
|
||||
## kubeadm init phase kubeconfig {#cmd-phase-kubeconfig}
|
||||
|
||||
You can create all required kubeconfig files by calling the `all` subcommand or call then individually.
|
||||
You can create all required kubeconfig files by calling the `all` subcommand or call them individually.
|
||||
|
||||
{{< tabs name="tab-kubeconfig" >}}
|
||||
{{< tab name="kubeconfig" include="generated/kubeadm_init_phase_kubeconfig.md" />}}
|
||||
|
||||
@@ -203,7 +203,7 @@ If the majority of etcd members have permanently failed, the etcd cluster is con
|
||||
|
||||
As of Kubernetes v1.13.0, etcd2 is no longer supported as a storage backend for
|
||||
new or existing Kubernetes clusters. The timeline for Kubernetes support for
|
||||
etcd2 and etcd3 is as follows:
|
||||
etcd2 and etcd3 is as follows:
|
||||
|
||||
- Kubernetes v1.0: etcd2 only
|
||||
- Kubernetes v1.5.1: etcd3 support added, new clusters still default to etcd2
|
||||
@@ -219,11 +219,23 @@ v1.13.x, etcd v2 data MUST by migrated to the v3 storage backend, and
|
||||
kube-apiserver invocations changed to use `--storage-backend=etcd3`.
|
||||
|
||||
The process for migrating from etcd2 to etcd3 is highly dependent on how the
|
||||
etcd cluster was deployed and configured, as well as how the Kubernetes
|
||||
etcd cluster was deployed and configured, as well as how the Kubernetes
|
||||
cluster was deployed and configured. We recommend that you consult your cluster
|
||||
provider's documentation to see if there is a predefined solution.
|
||||
|
||||
If your cluster was created via `kube-up.sh` and is still using etcd2 as its
|
||||
storage backend, please consult the [Kubernetes v1.12 etcd cluster upgrade docs](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters)
|
||||
|
||||
## Known issue: etcd client balancer with secure endpoints
|
||||
|
||||
The etcd v3 client, released in etcd v3.3.13 or earlier, has a [critical bug](https://github.com/kubernetes/kubernetes/issues/72102) which affects the kube-apiserver and HA deployments. The etcd client balancer failover does not properly work against secure endpoints. As a result, etcd servers may fail or disconnect briefly from the kube-apiserver. This affects kube-apiserver HA deployments.
|
||||
|
||||
The fix was made in [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) (and backported to v3.3.14 or later): the new client now creates its own credential bundle to correctly set authority target in dial function.
|
||||
|
||||
Because the fix requires gRPC dependency upgrade (to v1.23.0), downstream Kubernetes [did not backport etcd upgrades](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978). Which means the [etcd fix in kube-apiserver](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) is only available from Kubernetes 1.16.
|
||||
|
||||
To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-apiserver. You can make local changes to [`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) with [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab).
|
||||
|
||||
See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+1
-1
@@ -286,7 +286,7 @@ to 1 second. Minimum value is 1.
|
||||
considered successful after having failed. Defaults to 1. Must be 1 for
|
||||
liveness. Minimum value is 1.
|
||||
* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
|
||||
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the Pod. In case of readiness probe the Pod will be marked Unready.
|
||||
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
|
||||
[HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
|
||||
|
||||
@@ -323,7 +323,7 @@ Administrators should be aware that allowing write access to this feature grants
|
||||
|
||||
Currently, this feature has performance implications for the apiserver in the form of increased cpu and memory usage. This should be nominal for a small number of sinks, and performance impact testing will be done to understand its scope before the API progresses to beta.
|
||||
|
||||
## Multi-cluster setup
|
||||
## Setup for multiple API servers
|
||||
|
||||
If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also
|
||||
set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the
|
||||
|
||||
Reference in New Issue
Block a user