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

2021-12-06 08:55:54 -05:00
parent 3d07786e5d b904695d10
commit 584421fe11
152 changed files with 1691 additions and 942 deletions
@@ -45,6 +45,11 @@ This page lists some of the available add-ons and links to their respective inst
 ## Infrastructure

 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
+* The
+  [node problem detector](https://github.com/kubernetes/node-problem-detector)
+  runs on Linux nodes and reports system issues as either
+  [Events](/docs/reference/kubernetes-api/cluster-resources/event-v1/) or
+  [Node conditions](/docs/concepts/architecture/nodes/#condition).

 ## Legacy Add-ons

@@ -26,6 +26,10 @@ fair queuing technique so that, for example, a poorly-behaved
 {{< glossary_tooltip text="controller" term_id="controller" >}} need not
 starve others (even at the same priority level).

+This feature is designed to work well with standard controllers, which
+use informers and react to failures of API requests with exponential
+back-off, and other clients that also work this way.
+
 {{< caution >}}
 Requests classified as "long-running" — primarily watches — are not
 subject to the API Priority and Fairness filter. This is also true for
@@ -102,6 +106,8 @@ name of the matching FlowSchema plus a _flow distinguisher_ — which
 is either the requesting user, the target resource's namespace, or nothing — and the
 system attempts to give approximately equal weight to requests in different
 flows of the same priority level.
+To enable distinct handling of distinct instances, controllers that have
+many instances should authenticate with distinct usernames

 After classifying a request into a flow, the API Priority and Fairness
 feature then may assign the request to a queue.  This assignment uses
@@ -169,49 +169,6 @@ 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.

-### Google Compute Engine (GCE)
-
-For the Google Compute Engine cluster configuration scripts, [advanced
-routing](https://cloud.google.com/vpc/docs/routes) is used to
-assign each VM a subnet (default is `/24` - 254 IPs).  Any traffic bound for that
-subnet will be routed directly to the VM by the GCE network fabric.  This is in
-addition to the "main" IP address assigned to the VM, which is NAT'ed for
-outbound internet access.  A linux bridge (called `cbr0`) is configured to exist
-on that subnet, and is passed to docker's `--bridge` flag.
-
-Docker is started with:
-
-```shell
-DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
-```
-
-This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
-flag) according to the `Node`'s `.spec.podCIDR`.
-
-Docker will now allocate IPs from the `cbr-cidr` block.  Containers can reach
-each other and `Nodes` over the `cbr0` bridge.  Those IPs are all routable
-within the GCE project network.
-
-GCE itself does not know anything about these IPs, though, so it will not NAT
-them for outbound internet traffic.  To achieve that an iptables rule is used
-to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
-itself) traffic that is bound for IPs outside the GCE project network
-(10.0.0.0/8).
-
-```shell
-iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
-```
-
-Lastly IP forwarding is enabled in the kernel (so the kernel will process
-packets for bridged containers):
-
-```shell
-sysctl net.ipv4.ip_forward=1
-```
-
-The result of all this is that all `Pods` can reach each other and can egress
-traffic to the internet.
-
 ### 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.