Official 1.13 Release Docs (#11401)
* Update metadata.generation behaviour for custom resources (#10705) * update docs promoting plugins to beta (#10796) * docs update to promote TaintBasedEvictions to beta (#10765) * First Korean l10n work for dev-1.13 (#10719) * Update outdated l10n(ko) contents (#10689) fixes #10686 * Translate concepts/overview/what-is-kubernetes in Korean (#10690) * Translate concepts/overview/what-is-kubernetes in Korean * Feedback from ClaudiaJKang * Translate concepts/overview/components in Korean (#10882) * Translate concepts/overview/components in Korean #10717 * Translate concepts/overview/components in Korean * Translate concepts/overview/components in Korean * Apply Korean glossary: 서비스 어카운트 * Translate concepts/overview/kubernetes-api in Korean (#10773) * Translate concepts/overview/kubernetes-api in Korean * Applied feedback from ianychoi * kubeadm: update the configuration docs to v1beta1 (#10959) * kubeadm: add small v1beta1 related updates (#10988) * ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md (#11031) * ADD content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md * ADD content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md * Update content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md Accepted Co-Authored-By: YouthLab <tsui@highyouth.com> * do not change 'master' or 'worker' nodes to '主从' * Doc updates for volume scheduling GA (#10743) * Doc updates for volume scheduling GA * Make trivial change to kick build * Document nodelease feature (#10699) * advanced audit doc for ModeBlockingStrict (#10203) * Rename EncryptionConfig to EncryptionConfiguration (#11080) EncryptionConfig was renamed to EncryptedConfiguration and added to the `apiserver.config.k8s.io` API group in Kubernetes 1.13. The feature was previously in alpha and was not handling versions properly, which lead to an originally unnoticed `v1` in the docs. * content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md * trsanlate create-cluster-kubeadm.md to chinese (#11041) * trsanlate create-cluster-kubeadm.md to chinese * Update create-cluster-kubeadm.md * update the feature stage in v1.13 (#11307) * update new feature gates to document (#11295) * refresh controller role list on rbac description page (#11290) * node labeling restriction docs (#10944) * Update 1.13 docs for CSI GA (#10893) * dynamic audit documentation (#9947) * adds dynamic audit documentation * Copyedit for clarity See also inline question/s * Fix feature state shortcode * Update feature state * changes wording for dynamic audit flag behavior * Minor copyedit * fix dynamic audit yaml * adds api enablement command to dynamic audit docs * change ordering dynamic audit appears in * add references to dynamic audit in webhook backend * reword dynamic audit reference * updates stages field for audit sink object * changes audit sink api definition; rewords policy * kubeadm: remove kube-proxy workaround (#11162) * zh-trans content/en/docs/setup/independent/install-kubeadm.md (#11338) * zh-trans content/en/docs/setup/independent/install-kubeadm.md * Update install-kubeadm.md * Update dry run feature to beta (#11140) * vSphere volume raw block support doc update (#10932) * Add docs for Windows DNS configurations (#10036) * Update docs for fields allowed at root of CRD schema (#9973) * Add docs for Windows DNS configurations * add device monitoring documentation (#9945) * kubeadm: adds upgrade instructions for 1.13 (#11138) * kubeadm: adds upgrade instructions for 1.13 Signed-off-by: Chuck Ha <ha.chuck@gmail.com> * add minor copyedits Addressed a couple of copyedit comments a bit more cleanly. * kubeadm: add improvements to HA docs (#11094) * kubeadm: add information and diagrams for HA topologies * kubeadm: update HA doc with simplified steps * kubeadm: update HA doc with simplified steps * edit ha, add new topology topic, reorder by weight * troubleshoot markdown * fix more markdown, fix links * more markdown * more markdown * more markdown * changes after reviewer comments * add steps about Weave * update note about stacked topology * kubeadm external etcd HA upgrade 1.13 (#11364) * kubeadm external etcd HA upgrade 1.13 Signed-off-by: Ruben Orduz <rubenoz@gmail.com> * Update stacked controlplane steps * kubeadm cert documentation (#11093) * kubeadm certificate API and CSR documentation * copyedits * fix typo * PR for diff docs (#10789) * Empty commit against dev-1.13 for diff documentation * Complete Declarative maangement with diff commands * Second Korean l10n work for dev-1.13. (#11030) * Update outdated l10n(ko) contents (#10915) * Translate main menu for l10n(ko) docs (#10916) * Translate tasks/run-application/horizontal-pod-autoscale-walkthrough (#10980) * Translate content/ko/docs/concepts/overview/working-with-objects/kubernetes-object in Korean #11104 (#11332) * Pick-right-solution page translates into Korean. (#11340) * ko-trans: add jd/..., sap/..., ebay/..., homeoffice/... (#11336) * Translate concept/workloads/pods/pod-overview.md (#11092) Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: zerobig <38598117+zer0big@users.noreply.github.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: lIuDuI <1693291525@qq.com> Co-authored-by: Woojin Na(Eddie) <cheapluv@gmail.com> * Rename encryption-at-rest related objects (#11059) EncryptionConfig was renamed to EncryptedConfiguration and added to the `apiserver.config.k8s.io` API group in Kubernetes 1.13. The feature was previously in alpha and was not handling versions properly, which lead to an originally unnoticed `v1` in the docs. Also, the `--experimental-encryption-provider-config` flag is now called just `--encryption-provider-config`. * Documenting FlexVolume Resize alpha feature. (#10097) * CR webhook conversion documentation (#10986) * CR Conversion * Addressing comments * Addressing more comments * Addressing even more comments * Addressing even^2 more comments * Remove references to etcd2 in v1.13 since support has been removed (#11414) * Remove etcd2 references as etcd2 is deprecated Link back to the v1.12 version of the etcd3 doc for the etcd2->etcd3 migration instructions. I updated the kube-apiserver reference manually, unsure if that is auto-generated somehow. The federation-apiserver can still potentially support etcd2 so I didn't touch that. * Remove outdated {master,node}.yaml files There are master/node yaml files that reference etcd2.service that are likely highly out of date. I couldn't find any docs that actually reference these templates so I removed them * Address review comments * Final Korean l10n work for dev-1.13 (#11440) * Update outdated l10n(ko) contents (#11425) fixes #11424 * Remove references to etcd2 in content/ko (#11416) * Resolve conflicts against master for /ko contents (#11438) * Fix unopened caution shortcode * kubeadm: update the reference docs for 1.13 (#10960) * docs update to promote TaintBasedEvictions to beta (#10765) * First Korean l10n work for dev-1.13 (#10719) * Update outdated l10n(ko) contents (#10689) fixes #10686 * Translate concepts/overview/what-is-kubernetes in Korean (#10690) * Translate concepts/overview/what-is-kubernetes in Korean * Feedback from ClaudiaJKang * Translate concepts/overview/components in Korean (#10882) * Translate concepts/overview/components in Korean #10717 * Translate concepts/overview/components in Korean * Translate concepts/overview/components in Korean * Apply Korean glossary: 서비스 어카운트 * Translate concepts/overview/kubernetes-api in Korean (#10773) * Translate concepts/overview/kubernetes-api in Korean * Applied feedback from ianychoi * kubeadm: update the configuration docs to v1beta1 (#10959) * kubeadm: add small v1beta1 related updates (#10988) * update new feature gates to document (#11295) * Update dry run feature to beta (#11140) * kubeadm: add improvements to HA docs (#11094) * kubeadm: add information and diagrams for HA topologies * kubeadm: update HA doc with simplified steps * kubeadm: update HA doc with simplified steps * edit ha, add new topology topic, reorder by weight * troubleshoot markdown * fix more markdown, fix links * more markdown * more markdown * more markdown * changes after reviewer comments * add steps about Weave * update note about stacked topology * kubeadm: update reference docs - add section about working with phases under kubeadm-init.md - update GA / beta status of features - kubeadm alpha phase was moved to kubeadm init phase - new commands were added under kubeadm alpha - included new CoreDNS usage examples * Generate components and tools reference * Add generated federation API Reference (#11491) * Add generated federation API Reference * Add front matter to federation reference * Remove whitespace from federation front matter * Remove more whitespace from federation front matter * Remove superfluous kubefed reference * Add frontmatter to generated kubefed reference * Fix kubefed reference page frontmatter * Generate kubectl reference docs 1.13 (#11487) * Generate kubectl reference docs 1.13 * Fix links in kubectl reference * Add 1.13 API reference (#11489) * Update config.toml (#11486) * Update config.toml Preparing for 1.13 release, updating the config.toml and dropping the 1.8 docs reference. * update dot releases and docsbranch typo * adding .Site. to Params.currentUrl (#11503) see https://github.com/kubernetes/website/pull/11502 for context * Add 1.13 Release notes (#11499)
This commit is contained in:
committed by
Kubernetes Prow Robot
parent
b1dde5578c
commit
27b7b453a9
@@ -158,6 +158,20 @@ to be unreachable. (The default timeouts are 40s to start reporting
|
||||
ConditionUnknown and 5m after that to start evicting pods.) The node controller
|
||||
checks the state of each node every `--node-monitor-period` seconds.
|
||||
|
||||
In versions of Kubernetes prior to 1.13, NodeStatus is the heartbeat from the
|
||||
node. Starting from Kubernetes 1.13, node lease feature is introduced as an
|
||||
alpha feature (feature gate `NodeLease`,
|
||||
[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
When node lease feature is enabled, each node has an associated `Lease` object in
|
||||
`kube-node-lease` namespace that is renewed by the node periodically, and both
|
||||
NodeStatus and node lease are treated as heartbeats from the node. Node leases
|
||||
are renewed frequently while NodeStatus is reported from node to master only
|
||||
when there is some change or enough time has passed (default is 1 minute, which
|
||||
is longer than the default timeout of 40 seconds for unreachable nodes). Since
|
||||
node lease is much more lightweight than NodeStatus, this feature makes node
|
||||
heartbeat significantly cheaper from both scalability and performance
|
||||
perspectives.
|
||||
|
||||
In Kubernetes 1.4, we updated the logic of the node controller to better handle
|
||||
cases when a large number of nodes have problems with reaching the master
|
||||
(e.g. because the master has networking problem). Starting with 1.4, the node
|
||||
@@ -212,11 +226,12 @@ For self-registration, the kubelet is started with the following options:
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - Labels to add when registering the node in the cluster.
|
||||
- `--node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
|
||||
Currently, any kubelet is authorized to create/modify any node resource, but in practice it only creates/modifies
|
||||
its own. (In the future, we plan to only allow a kubelet to modify its own node resource.)
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
|
||||
#### Manual Node Administration
|
||||
|
||||
|
||||
@@ -17,30 +17,32 @@ kubeadm has configuration options to specify configuration information for cloud
|
||||
in-tree cloud provider can be configured using kubeadm as shown below:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1alpha3
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
kind: InitConfiguration
|
||||
nodeRegistration:
|
||||
kubeletExtraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
---
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
kind: ClusterConfiguration
|
||||
apiVersion: kubeadm.k8s.io/v1alpha3
|
||||
kubernetesVersion: v1.12.0
|
||||
apiServerExtraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
apiServerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
controllerManagerExtraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
controllerManagerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
kubernetesVersion: v1.13.0
|
||||
apiServer:
|
||||
extraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
extraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cloud-provider: "openstack"
|
||||
cloud-config: "/etc/kubernetes/cloud.conf"
|
||||
extraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "/etc/kubernetes/cloud.conf"
|
||||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
```
|
||||
|
||||
The in-tree cloud providers typically need both `--cloud-provider` and `--cloud-config` specified in the command lines
|
||||
|
||||
@@ -92,6 +92,21 @@ For example, the value of `kubernetes.io/hostname` may be the same as the Node n
|
||||
and a different value in other environments.
|
||||
{{< /note >}}
|
||||
|
||||
## Node isolation/restriction
|
||||
|
||||
Adding labels to Node objects allows targeting pods to specific nodes or groups of nodes.
|
||||
This can be used to ensure specific pods only run on nodes with certain isolation, security, or regulatory properties.
|
||||
When using labels for this purpose, choosing label keys that cannot be modified by the kubelet process on the node is strongly recommended.
|
||||
This prevents a compromised node from using its kubelet credential to set those labels on its own Node object,
|
||||
and influencing the scheduler to schedule workloads to the compromised node.
|
||||
|
||||
The `NodeRestriction` admission plugin prevents kubelets from setting or modifying labels with a `node-restriction.kubernetes.io/` prefix.
|
||||
To make use of that label prefix for node isolation:
|
||||
|
||||
1. Ensure you are using the [Node authorizer](/docs/reference/access-authn-authz/node/) and have enabled the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
|
||||
2. Add labels under the `node-restriction.kubernetes.io/` prefix to your Node objects, and use those labels in your node selectors.
|
||||
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
|
||||
|
||||
## Affinity and anti-affinity
|
||||
|
||||
`nodeSelector` provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity
|
||||
|
||||
@@ -223,9 +223,7 @@ certain condition is true. The following taints are built in:
|
||||
as unusable. After a controller from the cloud-controller-manager initializes
|
||||
this node, the kubelet removes this taint.
|
||||
|
||||
When the `TaintBasedEvictions` alpha feature is enabled (you can do this by
|
||||
including `TaintBasedEvictions=true` in `--feature-gates` for Kubernetes controller manager,
|
||||
such as `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
|
||||
In version 1.13, the `TaintBasedEvictions` feature is promoted to beta and enabled by default, hence the taints are automatically
|
||||
added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
|
||||
based on the Ready NodeCondition is disabled.
|
||||
|
||||
@@ -236,7 +234,7 @@ in a rate-limited way. This prevents massive pod evictions in scenarios such
|
||||
as the master becoming partitioned from the nodes.
|
||||
{{< /note >}}
|
||||
|
||||
This alpha feature, in combination with `tolerationSeconds`, allows a pod
|
||||
This beta feature, in combination with `tolerationSeconds`, allows a pod
|
||||
to specify how long it should stay bound to a node that has one or both of these problems.
|
||||
|
||||
For example, an application with a lot of local state might want to stay
|
||||
@@ -246,7 +244,7 @@ The toleration the pod would use in that case would look like
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "node.alpha.kubernetes.io/unreachable"
|
||||
- key: "node.kubernetes.io/unreachable"
|
||||
operator: "Exists"
|
||||
effect: "NoExecute"
|
||||
tolerationSeconds: 6000
|
||||
@@ -257,9 +255,9 @@ Note that Kubernetes automatically adds a toleration for
|
||||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.kubernetes.io/not-ready`.
|
||||
Likewise it adds a toleration for
|
||||
`node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300`
|
||||
`node.kubernetes.io/unreachable` with `tolerationSeconds=300`
|
||||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`.
|
||||
by the user already has a toleration for `node.kubernetes.io/unreachable`.
|
||||
|
||||
These automatically-added tolerations ensure that
|
||||
the default pod behavior of remaining bound for 5 minutes after one of these
|
||||
@@ -270,7 +268,7 @@ admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/default
|
||||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
|
||||
`NoExecute` tolerations for the following taints with no `tolerationSeconds`:
|
||||
|
||||
* `node.alpha.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/not-ready`
|
||||
|
||||
This ensures that DaemonSet pods are never evicted due to these problems,
|
||||
|
||||
@@ -136,6 +136,36 @@ a Kubernetes release with a newer device plugin API version, upgrade your device
|
||||
to support both versions before upgrading these nodes to
|
||||
ensure the continuous functioning of the device allocations during the upgrade.
|
||||
|
||||
## Monitoring Device Plugin Resources
|
||||
|
||||
In order to monitor resources provided by device plugins, monitoring agents need to be able to
|
||||
discover the set of devices that are in-use on the node and obtain metadata to describe which
|
||||
container the metric should be associated with. Prometheus metrics exposed by device monitoring
|
||||
agents should follow the
|
||||
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md),
|
||||
which requires identifying containers using `pod`, `namespace`, and `container` prometheus labels.
|
||||
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
|
||||
for these devices:
|
||||
|
||||
```gRPC
|
||||
// PodResources is a service provided by the kubelet that provides information about the
|
||||
// node resources consumed by pods and containers on the node
|
||||
service PodResources {
|
||||
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
|
||||
}
|
||||
```
|
||||
|
||||
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
|
||||
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
|
||||
The cannonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
|
||||
agents must run in a privileged security context. If a device monitoring agent is running as a
|
||||
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
|
||||
[Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
|
||||
in the plugin's
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
|
||||
|
||||
Support for the "PodResources service" is still in alpha.
|
||||
|
||||
## Examples
|
||||
|
||||
For examples of device plugin implementations, see:
|
||||
|
||||
@@ -9,7 +9,8 @@ Kubernetes objects can be created, updated, and deleted by storing multiple
|
||||
object configuration files in a directory and using `kubectl apply` to
|
||||
recursively create and update those objects as needed. This method
|
||||
retains writes made to live objects without merging the changes
|
||||
back into the object configuration files.
|
||||
back into the object configuration files. `kubectl diff` also gives you a
|
||||
preview of what changes `apply` will make.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -67,6 +68,14 @@ Here's an example of an object configuration file:
|
||||
|
||||
{{< codenew file="application/simple_deployment.yaml" >}}
|
||||
|
||||
Run `kubectl diff` to print the object that will be created:
|
||||
```shell
|
||||
kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
|
||||
```
|
||||
{{< note >}}
|
||||
**Note:** `diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run), which needs to be enabled on `kube-apiserver`.
|
||||
{{< /note >}}
|
||||
|
||||
Create the object using `kubectl apply`:
|
||||
|
||||
```shell
|
||||
@@ -130,6 +139,7 @@ if those objects already exist. This approach accomplishes the following:
|
||||
2. Clears fields removed from the configuration file in the live configuration.
|
||||
|
||||
```shell
|
||||
kubectl diff -f <directory>/
|
||||
kubectl apply -f <directory>/
|
||||
```
|
||||
|
||||
@@ -262,6 +272,7 @@ Update the `simple_deployment.yaml` configuration file to change the image from
|
||||
Apply the changes made to the configuration file:
|
||||
|
||||
```shell
|
||||
kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml
|
||||
```
|
||||
|
||||
@@ -977,5 +988,3 @@ template:
|
||||
- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -144,16 +144,19 @@ API operation to replace the entire object configuration.
|
||||
|
||||
### Examples
|
||||
|
||||
Process all object configuration files in the `configs` directory, and
|
||||
create or patch the live objects:
|
||||
Process all object configuration files in the `configs` directory, and create or
|
||||
patch the live objects. You can first `diff` to see what changes are going to be
|
||||
made, and then apply:
|
||||
|
||||
```sh
|
||||
kubectl diff -f configs/
|
||||
kubectl apply -f configs/
|
||||
```
|
||||
|
||||
Recursively process directories:
|
||||
|
||||
```sh
|
||||
kubectl diff -R -f configs/
|
||||
kubectl apply -R -f configs/
|
||||
```
|
||||
|
||||
@@ -181,5 +184,3 @@ Disadvantages compared to imperative object configuration:
|
||||
{{< comment >}}
|
||||
{{< /comment >}}
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -192,6 +192,7 @@ the following types of volumes:
|
||||
* Azure File
|
||||
* Azure Disk
|
||||
* Portworx
|
||||
* FlexVolumes
|
||||
|
||||
You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true.
|
||||
|
||||
@@ -227,16 +228,25 @@ kubectl describe pvc <pvc_name>
|
||||
|
||||
If the `PersistentVolumeClaim` has the status `FileSystemResizePending`, it is safe to recreate the pod using the PersistentVolumeClaim.
|
||||
|
||||
#### Resizing an in-use PersistentVolumeClaim
|
||||
FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to true.
|
||||
The FlexVolume can be resized on pod restart.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="alpha" >}}
|
||||
|
||||
#### Resizing an in-use PersistentVolumeClaim
|
||||
|
||||
Expanding in-use PVCs is an alpha feature. To use it, enable the `ExpandInUsePersistentVolumes` feature gate.
|
||||
In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC.
|
||||
Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded.
|
||||
This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod which
|
||||
uses the PVC before the expansion can complete.
|
||||
|
||||
Expanding in-use PVCs for FlexVolumes is added in release 1.13. To enable this feature use `ExpandInUsePersistentVolumes` and `ExpandPersistentVolumes` feature gates. The `ExpandPersistentVolumes` feature gate is already enabled by default. If the `ExpandInUsePersistentVolumes` is set, FlexVolume can be resized online without pod restart.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** FlexVolume resize is possible only when the underlying driver supports resize.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
|
||||
{{< /note >}}
|
||||
@@ -553,6 +563,7 @@ applicable.
|
||||
* iSCSI
|
||||
* Local volume
|
||||
* RBD (Ceph Block Device)
|
||||
* VsphereVolume (alpha)
|
||||
|
||||
{{< note >}}
|
||||
Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
|
||||
|
||||
@@ -121,13 +121,6 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
|
||||
|
||||
### Volume Binding Mode
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
This feature requires the `VolumeScheduling` feature gate to be
|
||||
enabled.
|
||||
{{< /note >}}
|
||||
|
||||
The `volumeBindingMode` field controls when [volume binding and dynamic
|
||||
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
|
||||
|
||||
@@ -159,12 +152,6 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
|
||||
* [Local](#local)
|
||||
|
||||
### Allowed Topologies
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
This feature requires the `VolumeScheduling` feature gate to be
|
||||
enabled.
|
||||
{{< /note >}}
|
||||
|
||||
When a cluster operactor specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary
|
||||
to restrict provisioning to specific topologies in most situations. However,
|
||||
|
||||
@@ -1139,16 +1139,25 @@ to [this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/vo
|
||||
|
||||
### CSI
|
||||
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
[Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI)
|
||||
defines a standard interface for container orchestration systems (like
|
||||
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.
|
||||
|
||||
CSI support was introduced as alpha in Kubernetes v1.9 and moved to beta in
|
||||
Kubernetes v1.10.
|
||||
CSI support was introduced as alpha in Kubernetes v1.9, moved to beta in
|
||||
Kubernetes v1.10, and is GA in Kubernetes v1.13.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes
|
||||
v1.13 and will be removed in a future release.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** CSI drivers may not be compatible across all Kubernetes releases.
|
||||
Please check the specific CSI driver's documentation for supported
|
||||
deployments steps for each Kubernetes release and a compatibility matrix.
|
||||
{{< /note >}}
|
||||
|
||||
Once a CSI compatible volume driver is deployed on a Kubernetes cluster, users
|
||||
may use the `csi` volume type to attach, mount, etc. the volumes exposed by the
|
||||
@@ -1224,6 +1233,10 @@ Kubernetes component using the following feature gate flags:
|
||||
Learn how to
|
||||
[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
|
||||
|
||||
#### Developer resources
|
||||
For more information on how to develop a CSI driver, refer to the [kubernetes-csi
|
||||
documentation](https://kubernetes-csi.github.io/docs/)
|
||||
|
||||
### Flexvolume
|
||||
|
||||
Flexvolume is an out-of-tree plugin interface that has existed in Kubernetes
|
||||
|
||||
@@ -161,14 +161,14 @@ Although Daemon Pods respect
|
||||
the following tolerations are added to DaemonSet Pods automatically according to
|
||||
the related features.
|
||||
|
||||
| Toleration Key | Effect | Alpha Features | Version | Description |
|
||||
| ---------------------------------------- | ---------- | ------------------------------------------------------------ | ------- | ------------------------------------------------------------ |
|
||||
| `node.kubernetes.io/not-ready` | NoExecute | `TaintBasedEvictions` | 1.8+ | When `TaintBasedEvictions` is enabled, they will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/unreachable` | NoExecute | `TaintBasedEvictions` | 1.8+ | When `TaintBasedEvictions` is enabled, they will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/disk-pressure` | NoSchedule | | 1.8+ | |
|
||||
| `node.kubernetes.io/memory-pressure` | NoSchedule | | 1.8+ | |
|
||||
| `node.kubernetes.io/unschedulable` | NoSchedule | | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
|
||||
| `node.kubernetes.io/network-unavailable` | NoSchedule | | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
|
||||
| Toleration Key | Effect | Version | Description |
|
||||
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
|
||||
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
|
||||
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user