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

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-01-17 09:46:19 -08:00
parent c8c474d07d c870be11cb
commit 015825f608
65 changed files with 5670 additions and 411 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/cri.md
+1 -1
View File
@@ -15,7 +15,7 @@ each Node in your cluster, so that the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
{{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="container-runtime-interface" length="all" >}}
<!-- body -->
content/en/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -33,7 +33,7 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP
1. The kubelet on a node self-registers to the control plane
2. You (or another human user) manually add a Node object
After you create a Node object, or the kubelet on a node self-registers, the
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the
control plane checks whether the new Node object is valid. For example, if you
try to create a Node from the following JSON manifest:
content/en/docs/concepts/cluster-administration/networking.md
+5 -5
View File
@@ -79,7 +79,7 @@ addressing, and it can be used in combination with other CNI plugins.
### CNI-Genie from Huawei
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
@@ -104,10 +104,6 @@ network complexity required to deploy Kubernetes at scale within AWS.
[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
### Contiv
[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases.
### Contrail / Tungsten Fabric
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
@@ -130,6 +126,10 @@ With this toolset DANM is able to provide multiple separated network interfaces,
network that satisfies the Kubernetes requirements. Many
people have reported success with Flannel and Kubernetes.
### Hybridnet
[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity.
### Jaguar
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+14 -11
View File
@@ -1,7 +1,6 @@
---
reviewers:
title: Device Plugins
description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup.
description: Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory.
content_type: concept
weight: 20
---
@@ -48,12 +47,14 @@ For example, after a device plugin registers `hardware-vendor.example/foo` with
and reports two healthy devices on a node, the node status is updated
to advertise that the node has 2 "Foo" devices installed and available.
Then, users can request devices in a
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
specification as they request other types of resources, with the following limitations:
Then, users can request devices as part of a Pod specification
(see [`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)).
Requesting extended resources is similar to how you manage requests and limits for
other resources, with the following differences:
* Extended resources are only supported as integer resources and cannot be overcommitted.
* Devices cannot be shared among Containers.
* Devices cannot be shared between containers.
### Example {#example-pod}
Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo`
on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:
@@ -174,7 +175,7 @@ a Kubernetes release with a newer device plugin API version, upgrade your device
to support both versions before upgrading these nodes. Taking that approach will
ensure the continuous functioning of the device allocations during the upgrade.
## Monitoring Device Plugin Resources
## Monitoring device plugin resources
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
@@ -310,7 +311,7 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
## Device Plugin integration with the Topology Manager
## Device plugin integration with the Topology Manager
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -319,7 +320,7 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin
```gRPC
message TopologyInfo {
repeated NUMANode nodes = 1;
repeated NUMANode nodes = 1;
}
message NUMANode {
@@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
## Device plugin examples {#examples}
{{% thirdparty-content %}}
Here are some examples of device plugin implementations:
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
@@ -357,5 +360,5 @@ Here are some examples of device plugin implementations:
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
content/en/docs/concepts/overview/working-with-objects/common-labels.md
+2 -1
View File
@@ -42,9 +42,10 @@ on every resource object.
| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string |
| `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string |
To illustrate these labels in action, consider the following StatefulSet object:
To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object:
```yaml
# This is an excerpt
apiVersion: apps/v1
kind: StatefulSet
metadata:
content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+4 -4
View File
@@ -106,7 +106,7 @@ description: "This priority class should be used for XYZ service pods only."
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue
Pods with `preemptionPolicy: Never` will be placed in the scheduling queue
ahead of lower-priority pods,
but they cannot preempt other pods.
A non-preempting pod waiting to be scheduled will stay in the scheduling queue,
@@ -122,16 +122,16 @@ allowing other pods with lower priority to be scheduled before them.
Non-preempting pods may still be preempted by other,
high-priority pods.
`PreemptionPolicy` defaults to `PreemptLowerPriority`,
`preemptionPolicy` defaults to `PreemptLowerPriority`,
which will allow pods of that PriorityClass to preempt lower-priority pods
(as is existing default behavior).
If `PreemptionPolicy` is set to `Never`,
If `preemptionPolicy` is set to `Never`,
pods in that PriorityClass will be non-preempting.
An example use case is for data science workloads.
A user may submit a job that they want to be prioritized above other workloads,
but do not wish to discard existing work by preempting running pods.
The high priority job with `PreemptionPolicy: Never` will be scheduled
The high priority job with `preemptionPolicy: Never` will be scheduled
ahead of other queued pods,
as soon as sufficient cluster resources "naturally" become free.
content/en/docs/concepts/storage/storage-classes.md
+2 -2
View File
@@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
parameters:
server: nfs-server.example.com
path: /share
readOnly: false
readOnly: "false"
```
* `server`: Server is the hostname or IP address of the NFS server.
@@ -797,7 +797,7 @@ parameters:
storagePool: sp1
storageMode: ThinProvisioned
secretRef: sio-secret
readOnly: false
readOnly: "false"
fsType: xfs
```
content/en/docs/concepts/workloads/controllers/job.md
+1 -1
View File
@@ -615,7 +615,7 @@ spec:
```
The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting
`manualSelector: true` tells the system to that you know what you are doing and to allow this
`manualSelector: true` tells the system that you know what you are doing and to allow this
mismatch.
### Job tracking with finalizers
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -229,7 +229,7 @@ when both the following statements apply:
* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
`False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`.
## Container probes