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

Adjust wrapping of long lines

Browse Source
This commit is contained in:
Qiming Teng
2022-03-14 20:49:36 +08:00
parent 1159c42559
commit e3bace5282
1 changed files with 47 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/nodes.md
+42 -24
View File
@@ -33,9 +33,9 @@ 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 1. The kubelet on a node self-registers to the control plane
2. You (or another human user) manually add a Node object 2. You (or another human user) manually add a Node object
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the After you create a Node {{< glossary_tooltip text="object" term_id="object" >}},
control plane checks whether the new Node object is valid. For example, if you or the kubelet on a node self-registers, the control plane checks whether the new Node object is
try to create a Node from the following JSON manifest: valid. For example, if you try to create a Node from the following JSON manifest:
```json ```json
{ {
@@ -86,18 +86,22 @@ register itself with the API server. This is the preferred pattern, used by mos
For self-registration, the kubelet is started with the following options: For self-registration, the kubelet is started with the following options:
- `--kubeconfig` - Path to credentials to authenticate itself to the API server. - `--kubeconfig` - Path to credentials to authenticate itself to the API server.
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself. - `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}}
to read metadata about itself.
- `--register-node` - Automatically register with the API server. - `--register-node` - Automatically register with the API server.
- `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`). - `--register-with-taints` - Register the node with the given list of
{{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
No-op if `register-node` is false. No-op if `register-node` is false.
- `--node-ip` - IP address of the node. - `--node-ip` - IP address of the node.
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} 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)). - `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} 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)).
- `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server. - `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server.
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and 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, [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
kubelets are only authorized to create/modify their own Node resource. are enabled, kubelets are only authorized to create/modify their own Node resource.
{{< note >}} {{< note >}}
As mentioned in the [Node name uniqueness](#node-name-uniqueness) section, As mentioned in the [Node name uniqueness](#node-name-uniqueness) section,
@@ -168,8 +172,10 @@ Each section of the output is described below.
The usage of these fields varies depending on your cloud provider or bare metal configuration. The usage of these fields varies depending on your cloud provider or bare metal configuration.
* HostName: The hostname as reported by the node's kernel. Can be overridden via the kubelet `--hostname-override` parameter. * HostName: The hostname as reported by the node's kernel. Can be overridden via the kubelet
* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster). `--hostname-override` parameter.
* ExternalIP: Typically the IP address of the node that is externally routable (available from
outside the cluster).
* InternalIP: Typically the IP address of the node that is routable only within the cluster. * InternalIP: Typically the IP address of the node that is routable only within the cluster.
@@ -289,7 +295,6 @@ and for updating their related Leases.
updates to the Node's `.status`. If the Lease update fails, the kubelet retries, updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
using exponential backoff that starts at 200 milliseconds and capped at 7 seconds. using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
## Node controller ## Node controller
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
@@ -306,6 +311,7 @@ controller deletes the node from its list of nodes.
The third is monitoring the nodes' health. The node controller is The third is monitoring the nodes' health. The node controller is
responsible for: responsible for:
- In the case that a node becomes unreachable, updating the NodeReady condition - In the case that a node becomes unreachable, updating the NodeReady condition
of within the Node's `.status`. In this case the node controller sets the of within the Node's `.status`. In this case the node controller sets the
NodeReady condition to `ConditionUnknown`. NodeReady condition to `ConditionUnknown`.
@@ -327,6 +333,7 @@ The node eviction behavior changes when a node in a given availability zone
becomes unhealthy. The node controller checks what percentage of nodes in the zone becomes unhealthy. The node controller checks what percentage of nodes in the zone
are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
the same time: the same time:
- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold` - If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
(default 0.55), then the eviction rate is reduced. (default 0.55), then the eviction rate is reduced.
- If the cluster is small (i.e. has less than or equal to - If the cluster is small (i.e. has less than or equal to
@@ -391,7 +398,9 @@ for more information.
The kubelet attempts to detect node system shutdown and terminates pods running on the node. The kubelet attempts to detect node system shutdown and terminates pods running on the node.
Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown. Kubelet ensures that pods follow the normal
[pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
during the node shutdown.
The Graceful node shutdown feature depends on systemd since it takes advantage of The Graceful node shutdown feature depends on systemd since it takes advantage of
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to
@@ -404,18 +413,26 @@ enabled by default in 1.21.
Note that by default, both configuration options described below, Note that by default, both configuration options described below,
`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero, `shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero,
thus not activating Graceful node shutdown functionality. thus not activating Graceful node shutdown functionality.
To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values. To activate the feature, the two kubelet config settings should be configured appropriately and
set to non-zero values.
During a graceful shutdown, kubelet terminates pods in two phases: During a graceful shutdown, kubelet terminates pods in two phases:
1. Terminate regular pods running on the node. 1. Terminate regular pods running on the node.
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node. 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
running on the node.
Graceful node shutdown feature is configured with two
[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
* `shutdownGracePeriod`: * `shutdownGracePeriod`:
* Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). * Specifies the total duration that the node should delay the shutdown by. This is the total
grace period for pod termination for both regular and
[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
* `shutdownGracePeriodCriticalPods`: * `shutdownGracePeriodCriticalPods`:
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `shutdownGracePeriod`. * Specifies the duration used to terminate
[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
during a node shutdown. This value should be less than `shutdownGracePeriod`.
For example, if `shutdownGracePeriod=30s`, and For example, if `shutdownGracePeriod=30s`, and
`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by `shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
@@ -443,8 +460,8 @@ To provide more flexibility during graceful node shutdown around the ordering
of pods during shutdown, graceful node shutdown honors the PriorityClass for of pods during shutdown, graceful node shutdown honors the PriorityClass for
Pods, provided that you enabled this feature in your cluster. The feature Pods, provided that you enabled this feature in your cluster. The feature
allows cluster administers to explicitly define the ordering of pods allows cluster administers to explicitly define the ordering of pods
during graceful node shutdown based on [priority during graceful node shutdown based on
classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass). [priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described
above, shuts down pods in two phases, non-critical pods, followed by critical above, shuts down pods in two phases, non-critical pods, followed by critical
@@ -457,8 +474,8 @@ graceful node shutdown in multiple phases, each phase shutting down a
particular priority class of pods. The kubelet can be configured with the exact particular priority class of pods. The kubelet can be configured with the exact
phases and shutdown time per phase. phases and shutdown time per phase.
Assuming the following custom pod [priority Assuming the following custom pod
classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) [priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
in a cluster, in a cluster,
|Pod priority class name|Pod priority class value| |Pod priority class name|Pod priority class value|
@@ -492,7 +509,7 @@ shutdownGracePeriodByPodPriority:
shutdownGracePeriodSeconds: 60 shutdownGracePeriodSeconds: 60
``` ```
The above table implies that any pod with priority value >= 100000 will get The above table implies that any pod with `priority` value >= 100000 will get
just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180 just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180
seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop. seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop.
Finally, all other pods will get 60 seconds to stop. Finally, all other pods will get 60 seconds to stop.
@@ -507,8 +524,8 @@ example, you could instead use these settings:
| 0 |60 seconds | | 0 |60 seconds |
In the above case, the pods with custom-class-b will go into the same bucket In the above case, the pods with `custom-class-b` will go into the same bucket
as custom-class-c for shutdown. as `custom-class-c` for shutdown.
If there are no pods in a particular range, then the kubelet does not wait If there are no pods in a particular range, then the kubelet does not wait
for pods in that priority range. Instead, the kubelet immediately skips to the for pods in that priority range. Instead, the kubelet immediately skips to the
@@ -577,3 +594,4 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document. section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).