whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16

Browse Source
This commit is contained in:
simplytunde
2019-09-17 22:15:57 -05:00
parent 234ff08588 67c20b3d37
commit e95ffa68fd
34 changed files with 584 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/configuration/scheduling-framework.md
+4 -4
View File
@@ -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
content/en/docs/concepts/policy/pod-security-policy.md
+4 -4
View File
@@ -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:
content/en/docs/concepts/storage/persistent-volumes.md
+1 -1
View File
@@ -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 | ✓ | ✓ | ✓ |
content/en/docs/concepts/storage/storage-classes.md
+8 -7
View File
@@ -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
content/en/docs/concepts/storage/volumes.md
+8 -8
View File
@@ -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.
@@ -1368,14 +1368,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
@@ -1411,7 +1411,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
content/en/docs/concepts/workloads/controllers/daemonset.md
+4 -6
View File
@@ -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
content/en/docs/concepts/workloads/controllers/deployment.md
+1 -1
View File
@@ -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).