diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index c74c490004cf2..59adee7f59f57 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -119,6 +119,7 @@ aliases: - atoato88 - bells17 - kakts + - Okabe-Junya - t-inu sig-docs-ko-owners: # Admins for Korean content - gochist diff --git a/content/en/community/code-of-conduct.md b/content/en/community/code-of-conduct.md index 976bbbb55780e..df9071b739fb0 100644 --- a/content/en/community/code-of-conduct.md +++ b/content/en/community/code-of-conduct.md @@ -7,7 +7,7 @@ cid: code-of-conduct _Kubernetes follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). The text of the CNCF CoC is replicated below, as of -[commit c79711b51](https://github.com/cncf/foundation/blob/c79711b5127e2d963107bc1be4a41975c8791acc/code-of-conduct.md)._ +[commit 71412bb02](https://github.com/cncf/foundation/blob/71412bb029090d42ecbeadb39374a337bfb48a9c/code-of-conduct.md)._
{{< include "static/cncf-code-of-conduct.md" >}} diff --git a/content/en/community/static/cncf-code-of-conduct.md b/content/en/community/static/cncf-code-of-conduct.md index b80a0e95d78ff..1120103eb772c 100644 --- a/content/en/community/static/cncf-code-of-conduct.md +++ b/content/en/community/static/cncf-code-of-conduct.md @@ -9,9 +9,9 @@ an open and welcoming community, we pledge to respect all people who participate through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, attending conferences or events, or engaging in other community or project activities. -We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of age, body size, caste, disability, ethnicity, level of experience, family status, gender, gender identity and expression, marital status, military or veteran status, nationality, personal appearance, race, religion, sexual orientation, socieconomic status, tribe, or any other dimension of diversity. +We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of age, body size, caste, disability, ethnicity, level of experience, family status, gender, gender identity and expression, marital status, military or veteran status, nationality, personal appearance, race, religion, sexual orientation, socioeconomic status, tribe, or any other dimension of diversity. -## Scope +## Scope This code of conduct applies: * within project and community spaces, @@ -35,7 +35,7 @@ Examples of behavior that contributes to a positive environment include but are * Focusing on what is best not just for us as individuals, but for the overall community * Using welcoming and inclusive language - + Examples of unacceptable behavior include but are not limited to: @@ -50,29 +50,29 @@ Examples of unacceptable behavior include but are not limited to: * Unwelcome sexual or romantic attention or advances * Other conduct which could reasonably be considered inappropriate in a professional setting - + The following behaviors are also prohibited: * Providing knowingly false or misleading information in connection with a Code of Conduct investigation or otherwise intentionally tampering with an investigation. * Retaliating against a person because they reported an incident or provided information about an incident as a witness. -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect -of managing a CNCF project. +of managing a CNCF project. Project maintainers who do not follow or enforce the Code of Conduct may be temporarily or permanently removed from the project team. -## Reporting +## Reporting For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via . You can expect a response within three business days. -For other projects, or for incidents that are project-agnostic or impact multiple CNCF projects, please contact the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) via conduct@cncf.io. Alternatively, you can contact any of the individual members of the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) to submit your report. For more detailed instructions on how to submit a report, including how to submit a report anonymously, please see our [Incident Resolution Procedures](https://www.cncf.io/conduct/procedures/). You can expect a response within three business days. +For other projects, or for incidents that are project-agnostic or impact multiple CNCF projects, please contact the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) via . Alternatively, you can contact any of the individual members of the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) to submit your report. For more detailed instructions on how to submit a report, including how to submit a report anonymously, please see our [Incident Resolution Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md). You can expect a response within three business days. -For incidents ocurring at CNCF event that is produced by the Linux Foundation, please contact eventconduct@cncf.io. +For incidents occurring at CNCF event that is produced by the Linux Foundation, please contact . -## Enforcement +## Enforcement -Upon review and investigation of a reported incident, the CoC response team that has jurisdiction will determine what action is appropriate based on this Code of Conduct and its related documentation. +Upon review and investigation of a reported incident, the CoC response team that has jurisdiction will determine what action is appropriate based on this Code of Conduct and its related documentation. -For information about which Code of Conduct incidents are handled by project leadership, which incidents are handled by the CNCF Code of Conduct Committee, and which incidents are handled by the Linux Foundation (including its events team), see our [Jurisdiction Policy](https://www.cncf.io/conduct/jurisdiction/). +For information about which Code of Conduct incidents are handled by project leadership, which incidents are handled by the CNCF Code of Conduct Committee, and which incidents are handled by the Linux Foundation (including its events team), see our [Jurisdiction Policy](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md). ## Amendments @@ -82,4 +82,4 @@ Consistent with the CNCF Charter, any substantive changes to this Code of Conduc This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 2.0 available at -http://contributor-covenant.org/version/2/0/code_of_conduct/ +http://contributor-covenant.org/version/2/0/code_of_conduct/ \ No newline at end of file diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 636dfac5c878c..4f8bc9e8b7e7c 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -291,260 +291,6 @@ the kubelet can use topology hints when making resource assignment decisions. See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/) for more information. -## Graceful node shutdown {#graceful-node-shutdown} - -{{< feature-state feature_gate_name="GracefulNodeShutdown" >}} - -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. During node shutdown, the kubelet does not accept new -Pods (even if those Pods are already bound to the node). - -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 -delay the node shutdown with a given duration. - -Graceful node shutdown is controlled with the `GracefulNodeShutdown` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is -enabled by default in 1.21. - -Note that by default, both configuration options described below, -`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero, -thus not activating the graceful node shutdown functionality. -To activate the feature, the two kubelet config settings should be configured appropriately and -set to non-zero values. - -Once systemd detects or notifies node shutdown, the kubelet sets a `NotReady` condition on -the Node, with the `reason` set to `"node is shutting down"`. The kube-scheduler honors this condition -and does not schedule any Pods onto the affected node; other third-party schedulers are -expected to follow the same logic. This means that new Pods won't be scheduled onto that node -and therefore none will start. - -The kubelet **also** rejects Pods during the `PodAdmission` phase if an ongoing -node shutdown has been detected, so that even Pods with a -{{< glossary_tooltip text="toleration" term_id="toleration" >}} for -`node.kubernetes.io/not-ready:NoSchedule` do not start there. - -At the same time when kubelet is setting that condition on its Node via the API, -the kubelet also begins terminating any Pods that are running locally. - -During a graceful shutdown, kubelet terminates pods in two phases: - -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. - -Graceful node shutdown feature is configured with two -[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: - -* `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). -* `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`. - -{{< note >}} - -There are cases when Node termination was cancelled by the system (or perhaps manually -by an administrator). In either of those situations the Node will return to the `Ready` state. -However, Pods which already started the process of termination will not be restored by kubelet -and will need to be re-scheduled. - -{{< /note >}} - -For example, if `shutdownGracePeriod=30s`, and -`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by -30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved -for gracefully terminating normal pods, and the last 10 seconds would be -reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). - -{{< note >}} -When pods were evicted during the graceful node shutdown, they are marked as shutdown. -Running `kubectl get pods` shows the status of the evicted pods as `Terminated`. -And `kubectl describe pod` indicates that the pod was evicted because of node shutdown: - -``` -Reason: Terminated -Message: Pod was terminated in response to imminent node shutdown. -``` - -{{< /note >}} - -### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown} - -{{< feature-state feature_gate_name="GracefulNodeShutdownBasedOnPodPriority" >}} - -To provide more flexibility during graceful node shutdown around the ordering -of pods during shutdown, graceful node shutdown honors the PriorityClass for -Pods, provided that you enabled this feature in your cluster. The feature -allows cluster administers to explicitly define the ordering of pods -during graceful node shutdown based on -[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass). - -The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described -above, shuts down pods in two phases, non-critical pods, followed by critical -pods. If additional flexibility is needed to explicitly define the ordering of -pods during shutdown in a more granular way, pod priority based graceful -shutdown can be used. - -When graceful node shutdown honors pod priorities, this makes it possible to do -graceful node shutdown in multiple phases, each phase shutting down a -particular priority class of pods. The kubelet can be configured with the exact -phases and shutdown time per phase. - -Assuming the following custom pod -[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) -in a cluster, - -|Pod priority class name|Pod priority class value| -|-------------------------|------------------------| -|`custom-class-a` | 100000 | -|`custom-class-b` | 10000 | -|`custom-class-c` | 1000 | -|`regular/unset` | 0 | - -Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) -the settings for `shutdownGracePeriodByPodPriority` could look like: - -|Pod priority class value|Shutdown period| -|------------------------|---------------| -| 100000 |10 seconds | -| 10000 |180 seconds | -| 1000 |120 seconds | -| 0 |60 seconds | - -The corresponding kubelet config YAML configuration would be: - -```yaml -shutdownGracePeriodByPodPriority: - - priority: 100000 - shutdownGracePeriodSeconds: 10 - - priority: 10000 - shutdownGracePeriodSeconds: 180 - - priority: 1000 - shutdownGracePeriodSeconds: 120 - - priority: 0 - shutdownGracePeriodSeconds: 60 -``` - -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 -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. - -One doesn't have to specify values corresponding to all of the classes. For -example, you could instead use these settings: - -|Pod priority class value|Shutdown period| -|------------------------|---------------| -| 100000 |300 seconds | -| 1000 |120 seconds | -| 0 |60 seconds | - -In the above case, the pods with `custom-class-b` will go into the same bucket -as `custom-class-c` for shutdown. - -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 -next priority class value range. - -If this feature is enabled and no configuration is provided, then no ordering -action will be taken. - -Using this feature requires enabling the `GracefulNodeShutdownBasedOnPodPriority` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), -and setting `ShutdownGracePeriodByPodPriority` in the -[kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/) -to the desired configuration containing the pod priority class values and -their respective shutdown periods. - -{{< note >}} -The ability to take Pod priority into account during graceful node shutdown was introduced -as an Alpha feature in Kubernetes v1.23. In Kubernetes {{< skew currentVersion >}} -the feature is Beta and is enabled by default. -{{< /note >}} - -Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds` -are emitted under the kubelet subsystem to monitor node shutdowns. - -## Non-graceful node shutdown handling {#non-graceful-node-shutdown} - -{{< feature-state feature_gate_name="NodeOutOfServiceVolumeDetach" >}} - -A node shutdown action may not be detected by kubelet's Node Shutdown Manager, -either because the command does not trigger the inhibitor locks mechanism used by -kubelet or because of a user error, i.e., the ShutdownGracePeriod and -ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above -section [Graceful Node Shutdown](#graceful-node-shutdown) for more details. - -When a node is shutdown but not detected by kubelet's Node Shutdown Manager, the pods -that are part of a {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} -will be stuck in terminating status on the shutdown node and cannot move to a new running node. -This is because kubelet on the shutdown node is not available to delete the pods so -the StatefulSet cannot create a new pod with the same name. If there are volumes used by the pods, -the VolumeAttachments will not be deleted from the original shutdown node so the volumes -used by these pods cannot be attached to a new running node. As a result, the -application running on the StatefulSet cannot function properly. If the original -shutdown node comes up, the pods will be deleted by kubelet and new pods will be -created on a different running node. If the original shutdown node does not come up, -these pods will be stuck in terminating status on the shutdown node forever. - -To mitigate the above situation, a user can manually add the taint `node.kubernetes.io/out-of-service` -with either `NoExecute` or `NoSchedule` effect to a Node marking it out-of-service. -If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -is enabled on {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}, -and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted -if there are no matching tolerations on it and volume detach operations for the pods terminating on -the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly -on a different node. - -During a non-graceful shutdown, Pods are terminated in the two phases: - -1. Force delete the Pods that do not have matching `out-of-service` tolerations. -2. Immediately perform detach volume operation for such pods. - -{{< note >}} -- Before adding the taint `node.kubernetes.io/out-of-service`, it should be verified - that the node is already in shutdown or power off state (not in the middle of restarting). -- The user is required to manually remove the out-of-service taint after the pods are - moved to a new node and the user has checked that the shutdown node has been - recovered since the user was the one who originally added the taint. -{{< /note >}} - -### Forced storage detach on timeout {#storage-force-detach-on-timeout} - -In any situation where a pod deletion has not succeeded for 6 minutes, kubernetes will -force detach volumes being unmounted if the node is unhealthy at that instant. Any -workload still running on the node that uses a force-detached volume will cause a -violation of the -[CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md#controllerunpublishvolume), -which states that `ControllerUnpublishVolume` "**must** be called after all -`NodeUnstageVolume` and `NodeUnpublishVolume` on the volume are called and succeed". -In such circumstances, volumes on the node in question might encounter data corruption. - -The forced storage detach behaviour is optional; users might opt to use the "Non-graceful -node shutdown" feature instead. - -Force storage detach on timeout can be disabled by setting the `disable-force-detach-on-timeout` -config field in `kube-controller-manager`. Disabling the force detach on timeout feature means -that a volume that is hosted on a node that is unhealthy for more than 6 minutes will not have -its associated -[VolumeAttachment](/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/) -deleted. - -After this setting has been applied, unhealthy pods still attached to a volumes must be recovered -via the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure mentioned above. - -{{< note >}} -- Caution must be taken while using the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure. -- Deviation from the steps documented above can result in data corruption. -{{< /note >}} - ## Swap memory management {#swap-memory} {{< feature-state feature_gate_name="NodeSwap" >}} @@ -610,6 +356,7 @@ Learn more about the following: * [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. +* [Graceful/non-graceful node shutdown](/docs/concepts/cluster-administration/node-shutdown/). * [Cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/) to manage the number and size of nodes in your cluster. * [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). diff --git a/content/en/docs/concepts/cluster-administration/node-shutdown.md b/content/en/docs/concepts/cluster-administration/node-shutdown.md new file mode 100644 index 0000000000000..275311b9ee3e7 --- /dev/null +++ b/content/en/docs/concepts/cluster-administration/node-shutdown.md @@ -0,0 +1,274 @@ +--- +title: Node Shutdowns +content_type: concept +weight: 10 +--- + + +In a Kubernetes cluster, a {{< glossary_tooltip text="node" term_id="node" >}} +can be shutdown in a planned graceful way or unexpectedly because of reasons such +as a power outage or something else external. A node shutdown could lead to workload +failure if the node is not drained before the shutdown. A node shutdown can be +either **graceful** or **non-graceful**. + + +## Graceful node shutdown {#graceful-node-shutdown} + +{{< feature-state feature_gate_name="GracefulNodeShutdown" >}} + +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. During node shutdown, the kubelet does not accept new +Pods (even if those Pods are already bound to the node). + +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 +delay the node shutdown with a given duration. + +Graceful node shutdown is controlled with the `GracefulNodeShutdown` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is +enabled by default in 1.21. + +Note that by default, both configuration options described below, +`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero, +thus not activating the graceful node shutdown functionality. +To activate the feature, the two kubelet config settings should be configured appropriately and +set to non-zero values. + +Once systemd detects or notifies node shutdown, the kubelet sets a `NotReady` condition on +the Node, with the `reason` set to `"node is shutting down"`. The kube-scheduler honors this condition +and does not schedule any Pods onto the affected node; other third-party schedulers are +expected to follow the same logic. This means that new Pods won't be scheduled onto that node +and therefore none will start. + +The kubelet **also** rejects Pods during the `PodAdmission` phase if an ongoing +node shutdown has been detected, so that even Pods with a +{{< glossary_tooltip text="toleration" term_id="toleration" >}} for +`node.kubernetes.io/not-ready:NoSchedule` do not start there. + +At the same time when kubelet is setting that condition on its Node via the API, +the kubelet also begins terminating any Pods that are running locally. + +During a graceful shutdown, kubelet terminates pods in two phases: + +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. + +Graceful node shutdown feature is configured with two +[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: + +* `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). +* `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`. + +{{< note >}} + +There are cases when Node termination was cancelled by the system (or perhaps manually +by an administrator). In either of those situations the Node will return to the `Ready` state. +However, Pods which already started the process of termination will not be restored by kubelet +and will need to be re-scheduled. + +{{< /note >}} + +For example, if `shutdownGracePeriod=30s`, and +`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by +30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved +for gracefully terminating normal pods, and the last 10 seconds would be +reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). + +{{< note >}} +When pods were evicted during the graceful node shutdown, they are marked as shutdown. +Running `kubectl get pods` shows the status of the evicted pods as `Terminated`. +And `kubectl describe pod` indicates that the pod was evicted because of node shutdown: + +``` +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. +``` + +{{< /note >}} + +### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown} + +{{< feature-state feature_gate_name="GracefulNodeShutdownBasedOnPodPriority" >}} + +To provide more flexibility during graceful node shutdown around the ordering +of pods during shutdown, graceful node shutdown honors the PriorityClass for +Pods, provided that you enabled this feature in your cluster. The feature +allows cluster administers to explicitly define the ordering of pods +during graceful node shutdown based on +[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass). + +The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described +above, shuts down pods in two phases, non-critical pods, followed by critical +pods. If additional flexibility is needed to explicitly define the ordering of +pods during shutdown in a more granular way, pod priority based graceful +shutdown can be used. + +When graceful node shutdown honors pod priorities, this makes it possible to do +graceful node shutdown in multiple phases, each phase shutting down a +particular priority class of pods. The kubelet can be configured with the exact +phases and shutdown time per phase. + +Assuming the following custom pod +[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) +in a cluster, + +|Pod priority class name|Pod priority class value| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`regular/unset` | 0 | + +Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) +the settings for `shutdownGracePeriodByPodPriority` could look like: + +|Pod priority class value|Shutdown period| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +The corresponding kubelet config YAML configuration would be: + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +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 +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. + +One doesn't have to specify values corresponding to all of the classes. For +example, you could instead use these settings: + +|Pod priority class value|Shutdown period| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +In the above case, the pods with `custom-class-b` will go into the same bucket +as `custom-class-c` for shutdown. + +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 +next priority class value range. + +If this feature is enabled and no configuration is provided, then no ordering +action will be taken. + +Using this feature requires enabling the `GracefulNodeShutdownBasedOnPodPriority` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), +and setting `ShutdownGracePeriodByPodPriority` in the +[kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/) +to the desired configuration containing the pod priority class values and +their respective shutdown periods. + +{{< note >}} +The ability to take Pod priority into account during graceful node shutdown was introduced +as an Alpha feature in Kubernetes v1.23. In Kubernetes {{< skew currentVersion >}} +the feature is Beta and is enabled by default. +{{< /note >}} + +Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds` +are emitted under the kubelet subsystem to monitor node shutdowns. + +## Non-graceful node shutdown handling {#non-graceful-node-shutdown} + +{{< feature-state feature_gate_name="NodeOutOfServiceVolumeDetach" >}} + +A node shutdown action may not be detected by kubelet's Node Shutdown Manager, +either because the command does not trigger the inhibitor locks mechanism used by +kubelet or because of a user error, i.e., the ShutdownGracePeriod and +ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above +section [Graceful Node Shutdown](#graceful-node-shutdown) for more details. + +When a node is shutdown but not detected by kubelet's Node Shutdown Manager, the pods +that are part of a {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +will be stuck in terminating status on the shutdown node and cannot move to a new running node. +This is because kubelet on the shutdown node is not available to delete the pods so +the StatefulSet cannot create a new pod with the same name. If there are volumes used by the pods, +the VolumeAttachments will not be deleted from the original shutdown node so the volumes +used by these pods cannot be attached to a new running node. As a result, the +application running on the StatefulSet cannot function properly. If the original +shutdown node comes up, the pods will be deleted by kubelet and new pods will be +created on a different running node. If the original shutdown node does not come up, +these pods will be stuck in terminating status on the shutdown node forever. + +To mitigate the above situation, a user can manually add the taint `node.kubernetes.io/out-of-service` +with either `NoExecute` or `NoSchedule` effect to a Node marking it out-of-service. +If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +is enabled on {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}, +and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted +if there are no matching tolerations on it and volume detach operations for the pods terminating on +the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly +on a different node. + +During a non-graceful shutdown, Pods are terminated in the two phases: + +1. Force delete the Pods that do not have matching `out-of-service` tolerations. +2. Immediately perform detach volume operation for such pods. + +{{< note >}} +- Before adding the taint `node.kubernetes.io/out-of-service`, it should be verified + that the node is already in shutdown or power off state (not in the middle of restarting). +- The user is required to manually remove the out-of-service taint after the pods are + moved to a new node and the user has checked that the shutdown node has been + recovered since the user was the one who originally added the taint. +{{< /note >}} + +### Forced storage detach on timeout {#storage-force-detach-on-timeout} + +In any situation where a pod deletion has not succeeded for 6 minutes, kubernetes will +force detach volumes being unmounted if the node is unhealthy at that instant. Any +workload still running on the node that uses a force-detached volume will cause a +violation of the +[CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md#controllerunpublishvolume), +which states that `ControllerUnpublishVolume` "**must** be called after all +`NodeUnstageVolume` and `NodeUnpublishVolume` on the volume are called and succeed". +In such circumstances, volumes on the node in question might encounter data corruption. + +The forced storage detach behaviour is optional; users might opt to use the "Non-graceful +node shutdown" feature instead. + +Force storage detach on timeout can be disabled by setting the `disable-force-detach-on-timeout` +config field in `kube-controller-manager`. Disabling the force detach on timeout feature means +that a volume that is hosted on a node that is unhealthy for more than 6 minutes will not have +its associated +[VolumeAttachment](/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/) +deleted. + +After this setting has been applied, unhealthy pods still attached to a volumes must be recovered +via the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure mentioned above. + +{{< note >}} +- Caution must be taken while using the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure. +- Deviation from the steps documented above can result in data corruption. +{{< /note >}} + + +## {{% heading "whatsnext" %}} + +Learn more about the following: +* Blog: [Non-Graceful Node Shutdown](/blog/2023/08/16/kubernetes-1-28-non-graceful-node-shutdown-ga/). +* Cluster Architecture: [Nodes](/docs/concepts/architecture/nodes/). diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index bd09e179f2aa9..a8d4d82c1bda6 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -990,7 +990,7 @@ to control how Kubernetes routes traffic to healthy (“ready”) backends. See [Traffic Policies](/docs/reference/networking/virtual-ips/#traffic-policies) for more details. -### Trafic distribution +### Traffic distribution {{< feature-state feature_gate_name="ServiceTrafficDistribution" >}} diff --git a/content/en/docs/reference/tools/map-crictl-dockercli.md b/content/en/docs/reference/tools/map-crictl-dockercli.md index 03dd3f865b2d4..e7e101ea789d2 100644 --- a/content/en/docs/reference/tools/map-crictl-dockercli.md +++ b/content/en/docs/reference/tools/map-crictl-dockercli.md @@ -4,13 +4,12 @@ content_type: reference weight: 10 --- - {{< note >}} This page is being directed to https://v1-24.docs.kubernetes.io/docs/reference/tools/map-crictl-dockercli/ because of the [removal of dockershim from crictl in v1.24](https://github.com/kubernetes-sigs/cri-tools/issues/870). As per our community policy, deprecated documents are not maintained beyond next three versions. -The reason for deprecation is explained in [Dockershim-FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). +The reason for deprecation is explained in [Dockershim-FAQ](/blog/2020/12/02/dockershim-faq/). {{}} diff --git a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md index 4b7da012098e1..455b1a672c427 100644 --- a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md @@ -38,6 +38,7 @@ The configuration file must be a JSON or YAML representation of the parameters in this struct. Make sure the kubelet has read permissions on the file. Here is an example of what this file might look like: + ```yaml apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration @@ -54,9 +55,10 @@ evictionHard: In this example, the kubelet is configured with the following settings: 1. `address`: The kubelet will serve on IP address `192.168.0.8`. -2. `port`: The kubelet will serve on port `20250`. -3. `serializeImagePulls`: Image pulls will be done in parallel. -4. `evictionHard`: The kubelet will evict Pods under one of the following conditions: +1. `port`: The kubelet will serve on port `20250`. +1. `serializeImagePulls`: Image pulls will be done in parallel. +1. `evictionHard`: The kubelet will evict Pods under one of the following conditions: + - When the node's available memory drops below 100MiB. - When the node's main filesystem's available space is less than 10%. - When the image filesystem's available space is less than 15%. @@ -119,10 +121,9 @@ stored internally in the kubelet. This offers you flexibility in how you manage and combine kubelet configuration that comes from different sources. However, it's important to note that the behavior varies based on the data type of the configuration fields. -Different data types in the kubelet configuration structure merge differently. -See the [reference -document](/docs/reference/node/kubelet-config-directory-merging.md) for more -information. +Different data types in the kubelet configuration structure merge differently. See the +[reference document](/docs/reference/node/kubelet-config-directory-merging.md) +for more information. ### Kubelet configuration merging order @@ -135,8 +136,9 @@ On startup, the kubelet merges configuration from: {{< note >}} The config drop-in dir mechanism for the kubelet is similar but different from how the `kubeadm` tool allows you to patch configuration. -The `kubeadm` tool uses a specific [patching strategy](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) for its configuration, -whereas the only patch strategy for kubelet configuration drop-in files is `replace`. The kubelet determines the order of merges based on sorting the **suffixes** alphanumerically, +The `kubeadm` tool uses a specific [patching strategy](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) +for its configuration, whereas the only patch strategy for kubelet configuration drop-in files is `replace`. +The kubelet determines the order of merges based on sorting the **suffixes** alphanumerically, and replaces every field present in a higher priority file. {{< /note >}} @@ -147,144 +149,144 @@ they can follow these steps to inspect the kubelet configuration: 1. Start a proxy server using [`kubectl proxy`](/docs/reference/kubectl/generated/kubectl-commands#proxy) in your terminal. -```bash -kubectl proxy -``` - -Which gives output like: - -```bash -Starting to serve on 127.0.0.1:8001 - -``` -2. Open another terminal window and use `curl` to fetch the kubelet configuration. -Replace `` with the actual name of your node: - -```bash -curl -X GET http://127.0.0.1:8001/api/v1/nodes//proxy/configz | jq . -``` - -```bash -{ - "kubeletconfig": { - "enableServer": true, - "staticPodPath": "/var/run/kubernetes/static-pods", - "syncFrequency": "1m0s", - "fileCheckFrequency": "20s", - "httpCheckFrequency": "20s", - "address": "192.168.1.16", - "port": 10250, - "readOnlyPort": 10255, - "tlsCertFile": "/var/lib/kubelet/pki/kubelet.crt", - "tlsPrivateKeyFile": "/var/lib/kubelet/pki/kubelet.key", - "rotateCertificates": true, - "authentication": { - "x509": { - "clientCAFile": "/var/run/kubernetes/client-ca.crt" - }, - "webhook": { - "enabled": true, - "cacheTTL": "2m0s" - }, - "anonymous": { - "enabled": true - } - }, - "authorization": { - "mode": "AlwaysAllow", - "webhook": { - "cacheAuthorizedTTL": "5m0s", - "cacheUnauthorizedTTL": "30s" - } - }, - "registryPullQPS": 5, - "registryBurst": 10, - "eventRecordQPS": 50, - "eventBurst": 100, - "enableDebuggingHandlers": true, - "healthzPort": 10248, - "healthzBindAddress": "127.0.0.1", - "oomScoreAdj": -999, - "clusterDomain": "cluster.local", - "clusterDNS": [ - "10.0.0.10" - ], - "streamingConnectionIdleTimeout": "4h0m0s", - "nodeStatusUpdateFrequency": "10s", - "nodeStatusReportFrequency": "5m0s", - "nodeLeaseDurationSeconds": 40, - "imageMinimumGCAge": "2m0s", - "imageMaximumGCAge": "0s", - "imageGCHighThresholdPercent": 85, - "imageGCLowThresholdPercent": 80, - "volumeStatsAggPeriod": "1m0s", - "cgroupsPerQOS": true, - "cgroupDriver": "systemd", - "cpuManagerPolicy": "none", - "cpuManagerReconcilePeriod": "10s", - "memoryManagerPolicy": "None", - "topologyManagerPolicy": "none", - "topologyManagerScope": "container", - "runtimeRequestTimeout": "2m0s", - "hairpinMode": "promiscuous-bridge", - "maxPods": 110, - "podPidsLimit": -1, - "resolvConf": "/run/systemd/resolve/resolv.conf", - "cpuCFSQuota": true, - "cpuCFSQuotaPeriod": "100ms", - "nodeStatusMaxImages": 50, - "maxOpenFiles": 1000000, - "contentType": "application/vnd.kubernetes.protobuf", - "kubeAPIQPS": 50, - "kubeAPIBurst": 100, - "serializeImagePulls": true, - "evictionHard": { - "imagefs.available": "15%", - "memory.available": "100Mi", - "nodefs.available": "10%", - "nodefs.inodesFree": "5%" - }, - "evictionPressureTransitionPeriod": "1m0s", - "enableControllerAttachDetach": true, - "makeIPTablesUtilChains": true, - "iptablesMasqueradeBit": 14, - "iptablesDropBit": 15, - "featureGates": { - "AllAlpha": false - }, - "failSwapOn": false, - "memorySwap": {}, - "containerLogMaxSize": "10Mi", - "containerLogMaxFiles": 5, - "configMapAndSecretChangeDetectionStrategy": "Watch", - "enforceNodeAllocatable": [ - "pods" - ], - "volumePluginDir": "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/", - "logging": { - "format": "text", - "flushFrequency": "5s", - "verbosity": 3, - "options": { - "json": { - "infoBufferSize": "0" - } - } - }, - "enableSystemLogHandler": true, - "enableSystemLogQuery": false, - "shutdownGracePeriod": "0s", - "shutdownGracePeriodCriticalPods": "0s", - "enableProfilingHandler": true, - "enableDebugFlagsHandler": true, - "seccompDefault": false, - "memoryThrottlingFactor": 0.9, - "registerNode": true, - "localStorageCapacityIsolation": true, - "containerRuntimeEndpoint": "unix:///var/run/crio/crio.sock" - } -} -``` + ```bash + kubectl proxy + ``` + + Which gives output like: + + ```none + Starting to serve on 127.0.0.1:8001 + ``` + +1. Open another terminal window and use `curl` to fetch the kubelet configuration. + Replace `` with the actual name of your node: + + ```bash + curl -X GET http://127.0.0.1:8001/api/v1/nodes//proxy/configz | jq . + ``` + + ```json + { + "kubeletconfig": { + "enableServer": true, + "staticPodPath": "/var/run/kubernetes/static-pods", + "syncFrequency": "1m0s", + "fileCheckFrequency": "20s", + "httpCheckFrequency": "20s", + "address": "192.168.1.16", + "port": 10250, + "readOnlyPort": 10255, + "tlsCertFile": "/var/lib/kubelet/pki/kubelet.crt", + "tlsPrivateKeyFile": "/var/lib/kubelet/pki/kubelet.key", + "rotateCertificates": true, + "authentication": { + "x509": { + "clientCAFile": "/var/run/kubernetes/client-ca.crt" + }, + "webhook": { + "enabled": true, + "cacheTTL": "2m0s" + }, + "anonymous": { + "enabled": true + } + }, + "authorization": { + "mode": "AlwaysAllow", + "webhook": { + "cacheAuthorizedTTL": "5m0s", + "cacheUnauthorizedTTL": "30s" + } + }, + "registryPullQPS": 5, + "registryBurst": 10, + "eventRecordQPS": 50, + "eventBurst": 100, + "enableDebuggingHandlers": true, + "healthzPort": 10248, + "healthzBindAddress": "127.0.0.1", + "oomScoreAdj": -999, + "clusterDomain": "cluster.local", + "clusterDNS": [ + "10.0.0.10" + ], + "streamingConnectionIdleTimeout": "4h0m0s", + "nodeStatusUpdateFrequency": "10s", + "nodeStatusReportFrequency": "5m0s", + "nodeLeaseDurationSeconds": 40, + "imageMinimumGCAge": "2m0s", + "imageMaximumGCAge": "0s", + "imageGCHighThresholdPercent": 85, + "imageGCLowThresholdPercent": 80, + "volumeStatsAggPeriod": "1m0s", + "cgroupsPerQOS": true, + "cgroupDriver": "systemd", + "cpuManagerPolicy": "none", + "cpuManagerReconcilePeriod": "10s", + "memoryManagerPolicy": "None", + "topologyManagerPolicy": "none", + "topologyManagerScope": "container", + "runtimeRequestTimeout": "2m0s", + "hairpinMode": "promiscuous-bridge", + "maxPods": 110, + "podPidsLimit": -1, + "resolvConf": "/run/systemd/resolve/resolv.conf", + "cpuCFSQuota": true, + "cpuCFSQuotaPeriod": "100ms", + "nodeStatusMaxImages": 50, + "maxOpenFiles": 1000000, + "contentType": "application/vnd.kubernetes.protobuf", + "kubeAPIQPS": 50, + "kubeAPIBurst": 100, + "serializeImagePulls": true, + "evictionHard": { + "imagefs.available": "15%", + "memory.available": "100Mi", + "nodefs.available": "10%", + "nodefs.inodesFree": "5%" + }, + "evictionPressureTransitionPeriod": "1m0s", + "enableControllerAttachDetach": true, + "makeIPTablesUtilChains": true, + "iptablesMasqueradeBit": 14, + "iptablesDropBit": 15, + "featureGates": { + "AllAlpha": false + }, + "failSwapOn": false, + "memorySwap": {}, + "containerLogMaxSize": "10Mi", + "containerLogMaxFiles": 5, + "configMapAndSecretChangeDetectionStrategy": "Watch", + "enforceNodeAllocatable": [ + "pods" + ], + "volumePluginDir": "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/", + "logging": { + "format": "text", + "flushFrequency": "5s", + "verbosity": 3, + "options": { + "json": { + "infoBufferSize": "0" + } + } + }, + "enableSystemLogHandler": true, + "enableSystemLogQuery": false, + "shutdownGracePeriod": "0s", + "shutdownGracePeriodCriticalPods": "0s", + "enableProfilingHandler": true, + "enableDebugFlagsHandler": true, + "seccompDefault": false, + "memoryThrottlingFactor": 0.9, + "registerNode": true, + "localStorageCapacityIsolation": true, + "containerRuntimeEndpoint": "unix:///var/run/crio/crio.sock" + } + } + ``` @@ -294,4 +296,4 @@ curl -X GET http://127.0.0.1:8001/api/v1/nodes//proxy/configz | jq . [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) reference. - Learn more about kubelet configuration merging in the - [reference document](/docs/reference/node/kubelet-config-directory-merging.md). \ No newline at end of file + [reference document](/docs/reference/node/kubelet-config-directory-merging.md). diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md deleted file mode 100644 index d59da126ad253..0000000000000 --- a/content/id/docs/concepts/cluster-administration/federation.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -title: Federation -content_type: concept -weight: 80 ---- - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen -klaster Kubernetes. - - - -## Kenapa _Federation_ ? - -_Federation_ membuat proses manajemen klaster multipel menjadi lebih mudah. -_Federation_ mencapai hal ini dengan cara menyediakan 2 buah fondasi: - - * Melakukan sinkronisasi _resource_ di seluruh klaster: _Federation_ - menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_ - klaster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama - tersedia pada klaster multipel. - * _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan - konfigurasi otomatis server DNS dan _load balancer_ dari semua klaster. - Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan - untuk mengakses _backend_ dari klaster multipel. - -Beberapa penggunaan _federation_ adalah sebagai berikut: - -* _High Availability_: Melakukan _load balance_ di seluruh klaster serta - melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_ - meminimalisasi dampak yang terjadi apabila terjadi kegagalan klaster. -* Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah - proses migrasi antar klaster. - - -Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa klaster. -Beberapa alasan kenapa kamu butuh beberapa klaster adalah: - -* _Latency_ yang rendah: Memiliki klaster yang berada di _region_ yang berbeda - meminimalisasi _latency_ dengan cara menyajikan konten ke pengguna - berdasarkan _region_ yang paling dekat dengan pengguna tersebut. -* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa klaster kecil - dibandingkan sebuah klaster besar untuk melakukan isolasi _fault_ (misalnya saja - klaster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_ - yang berbeda). -* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah klaster Kubernetes, - hal ini sebenarnya tidak menjadi masalah bagi sebagian besar pengguna. Untuk informasi - lebih lanjut kamu bisa membaca - [_Kubernetes Scaling_ dan Perencanaan Performa](https://git.k8s.io/community/sig-scalability/goals.md)). -* [_Hybrid cloud_](#hybrid-cloud-capabilities): Kamu dapat memiliki _multiple_ klsuter - pada penyedia layanan _cloud_ yang berbeda ataupun menggunakan _on-premsie_. - -### Kekurangan - -Meskipun terdapat banyak kelebihan dari penggunaan _federation_, -terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut: - -* Peningkatan _bandwidth_ dan biaya untuk jaringan: _control plane_ _federation_ bertugas mengawasi semua - kulster yang ada untuk menjamin _state_ yang ada saat ini sesuai dengan _state_ yang diinginkan. Hal ini dapat menyebabkan - peningkatan biaya jaringan apabila klaster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia - layanan _cloud_ yang sama maupun berbeda. -* Berkurangnya isolasi antar klaster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat - berdampak pada semua klaster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_ - seminimum mungkin. -* Kematangan: Proyek _federation_ ini tergolong baru dan belum cukup matang. - Tidak semua _resource_ yang ada tersedia dan masih banyak feature _alpha_. [_Issue_ - 88](https://github.com/kubernetes/federation/issues/88) memberikan detail - isu-isu terkait sistem yang masih berusaha dicari solusinya. - -### Kemampuan _Hybrid_ Penggunaan Layanan Penyedian _Cloud_ - -_Federation_ pada Kubernetes memungkinkan klaster untuk dijalankan -pada penyedia layanan _cloud_ yang berbeda (misalnya Google Cloud, AWS), dan _on-premise_ -(misalnya OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/) -adalah salah satu cara yang direkomendasikan untuk melakukan proses _deploy_ -klaster _federation_. - -Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki -dapat berada di klaster atau bahkan penyedia layanan _cloud_ yang berbeda. - -## Mengaktifkan _Federation_ - -Untuk bisa melakukan _federation_ pada klaster yang berbeda, -pertama kamu harus mengaktifkan _control plane_ _federation_. -Ikuti [petunjuk mengaktifkan _control plane_ _federation_](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) -untuk informasi lebih lanjut. - -## `Resources` API - -Setelah kamu mengaktifkan _control plane_, kamu dapat menggunakan _resource_ API _federation_. -Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara mendetail: - -* [Cluster](/docs/tasks/administer-federation/cluster/) -* [ConfigMap](/docs/tasks/administer-federation/configmap/) -* [DaemonSets](/docs/tasks/administer-federation/daemonset/) -* [Deployment](/docs/tasks/administer-federation/deployment/) -* [Events](/docs/tasks/administer-federation/events/) -* [Hpa](/docs/tasks/administer-federation/hpa/) -* [Ingress](/docs/tasks/administer-federation/ingress/) -* [Jobs](/docs/tasks/administer-federation/job/) -* [Namespaces](/docs/tasks/administer-federation/namespaces/) -* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) -* [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/) - - -[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar -_resources_ yang disediakan _apiserver_ _federation_. - -## Penghapusan Berantai - -Kubernetes versi 1.6 menyediakan mekanisme penghapusan berantai -untuk _resource_ yang ada pada _federation_. Dengan penghapusan berantai, -ketika kamu menghapus sebuah _resource_ dari _control plane_ _federation_, -kamu juga akan menghapus segala _resource_ tersebut pada semua klaster yang ada. - -Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_ -ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi -`DeleteOptions.orphanDependents=false` ketika kamu menghapus sebuah _resource_ -dari _control plane_ _federation_ dengan menggunakan REST API. -Penggunaan `kubectl delete`mengaktifkan penhapusan berantai secara _default_. -Kamu dapat menonaktifkannya dengan menggunakan `kubectl delete --cascade=false` - -Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai -untuk sebagian _resource_ _federation_. - -## Cakupan dari Sebuah Klaster - -Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam -[zona](https://cloud.google.com/compute/docs/zones) atau [_availability -zone_](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). -Kami menyarankan agar semua VM pada klaster Kubernetes berada pada _availability_ zona yang sama, karena: - - - dibandingkan dengan sebuah klaster global Kubernetes, terdapat lebih sedikit _single-points of failure_. - - dibandingkan dengan sebuah klaster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah - klaster yang berada pada satu zona. - - ketika pengembang Kubernetes mendesain sistem (misalnya, memperkirakan _latency_, _bandwidth_, atau - _failure_ yang mungkin terjadi) pengembang tersebut memperkirakan semua mesin akan berada pada sebuah _data center_ yang sama, atau setidaknya masih terdapat pada satu wilayah. - -Sangat direkomendasikan untuk menjalankan sedikit klaster dengan lebih banyak VM pada setiap _availability_ zona; -meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan klaster multipel -pada setiap _availability_ zona. - -Alasan kenapa menjalankan lebih sedikit klaster pada setiap _availability_ zona lebih dianjurkan: - - - meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah klaster (mengurangi terjadinya _fragmentation_ _resource_). - - mengurangi _overhead_ operasional (meskipun keuntungan ini akan berkurang seiring bertambah matangnya proses dan _tooling_ operasional). - - mengurangi biaya _resource_ tetap per klaster, misalnya VM _apiserver_. - -Alasan untuk memiliki klaster multipel: - - - _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Klaster di bawah). - - melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu klaster. - -## Memilih jumlah klaster yang tepat - -Pemilihan jumlah klaster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu. -Sebaliknya, jumlah _node_ dan _pod_ dalam suatu _service_ dapat berubah secara cepat seiring bertambahnya _workload_. - -Untuk memilih jumlah klaster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu -(jika kamu menggunakan _Content Distribution Network_, kebutuhan informasi nilai _latency_ CDN tidak perlu diperhatikan). -Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih klaster di _region_ -US, EU, AP, dan SA. Jumlah _region_ ini dimisalkan dengan `R`. - -Kedua, pilih berapa banyak klaster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_. -Misalkan jumlah klaster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong -dapat diterima. - -Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada klaster, -maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` klaster. Jika tidak (misalnya, kamu -ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada klaster) maka kamu membutuhkan `R * (U + 1)` klaster -(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu klaster - pada zona yang berbeda. - -Terakhir, jika klaster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah klaster Kubernetes, -maka kamu membutuhkan lebih banyak klaster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap klaster. Kubernetes v1.8 -mampu menangani hingga 5000 node untuk tiap klaster. Baca [Membangun Klaster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut. - - - -## {{% heading "whatsnext" %}} - -* Pelajari lebih lanjut tentang [proposal - _Federation_](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md). -* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) klaster _federation_. -* Lihat [seminar tentang _federation_ pada Kubecon2016](https://www.youtube.com/watch?v=pq9lbkmxpS8) -* Lihat [_update_ _federation_ pada Kubecon2017 Eropa](https://www.youtube.com/watch?v=kwOvOLnFYck) -* Lihat [_update_ _sig-multicluster_ pada Kubecon2018 Eropa](https://www.youtube.com/watch?v=vGZo5DaThQU) -* Lihat [presentasi prototipe _Federation-v2_ pada Kubecon2018 Eropa](https://youtu.be/q27rbaX5Jis?t=7m20s) -* Lihat [petunjuk penggunaan _Federation-v2_](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) - diff --git a/content/ja/blog/_posts/2024-03-12-mid-cycle-1.30.md b/content/ja/blog/_posts/2024-03-12-mid-cycle-1.30.md new file mode 100644 index 0000000000000..6b6aca0a24ea0 --- /dev/null +++ b/content/ja/blog/_posts/2024-03-12-mid-cycle-1.30.md @@ -0,0 +1,88 @@ +--- +layout: blog +title: 'Kubernetes v1.30をそっと覗く' +date: 2024-03-12 +--- + +**著者:** Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko + +## Kubernetes v1.30のおもしろい変更点をざっと見る + +新しい年であり、新しいKubernetesのリリースです。 +リリースサイクルの半分が終了し、v1.30ではかなりの数の興味深くおもしろい機能強化が行われます。 +アルファ版の真新しい機能から、安定版へと進む既存の機能、そして待望の改良まで、このリリースには誰もが注目するものがあります！ + +正式リリースまでのつなぎとして、このリリースで我々がもっとも期待している機能強化をそっと覗いてみましょう！ + +## Kubernetes v1.30の主な変更点 + +### 動的なリソース割り当てのための構造化パラメーター ([KEP-4381](https://kep.k8s.io/4381)) + +[動的なリソース割り当て(DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)はv1.26でアルファ機能としてKubernetesに追加されました。 +これは、サードパーティリソースへのアクセスを要求するための従来のデバイスプラグインAPIに代わるものを定義しています。 +設計上、動的なリソース割り当て(DRA)では、Kubernetesの中心部に完全に不透明なリソースのパラメーターが使用されます。 +このアプローチは、クラスターオートスケーラーや、Podのグループ(Jobスケジューラーなど)に対して決定を下す必要がある上位コントローラーにとって問題となります。 +時間経過に伴う要求(claim)の割り当てや割り当て解除の効果をシミュレートできないのです。 +これを行うための情報は、サードパーティのDRAドライバーのみが保有しています。 + +動的なリソース割り当て(DRA)の構造化パラメーターは、これらの要求(claim)パラメーターの不透明さがより少ないフレームワークを構築することによって、この問題に対処するための従来の実装の拡張になります。 +すべての要求(claim)パラメーターのセマンティクスを自分で処理する代わりに、ドライバーはKubernetesによって事前定義された特定の"構造化モデル"を使用してリソースを記述し、管理できます。 +これにより、この"構造化モデル"を認識しているコンポーネントは、サードパーティのコントローラーに委託することなく、これらのリソースに関する意思決定を行えます。 +たとえば、スケジューラーは動的なリソース割り当て(DRA)ドライバーとやり取りを行うことなく、要求(claim)を迅速に割り当てることができます。 +今回のリリースでは、さまざまな"構造化モデル"を実現するために必要なフレームワークの定義と"名前付きリソース"モデルの実装を中心に作業が行われました。 +このモデルでは、個々のリソース・インスタンスをリストアップすることができ、従来のデバイスプラグインAPIと比較して、属性によってそれらのインスタンスを個別に選択する機能が追加されています。 + +### Nodeのメモリスワップのサポート ([KEP-2400](https://kep.k8s.io/2400)) + +Kubernetes v1.30では、Linux Nodeにおけるメモリスワップのサポートが、システムの安定性を向上させることに重点を置いて、その動作方法に大きな変更が加えられました。 +以前のKubernetesバージョンでは、`NodeSwap`フィーチャーゲートはデフォルトで無効化されており、有効化された場合、デフォルトの動作として`UnlimitedSwap`動作が使用されていました。 +より良い安定性を達成するために、(Nodeの安定性を損なう可能性のある)`UnlimitedSwap`動作はv1.30で削除されます。 + +更新された、まだベータ版のLinux Nodeでのスワップのサポートは、デフォルトで利用できるようになります。 +ただし、デフォルトの動作は、`NoSwap`(`UnlimitedSwap`ではない)モードに設定されたNodeを実行することになります。 +`NoSwap`モードでは、kubeletはスワップ領域が有効化されたNodeでの実行をサポートしますが、Podはページファイルを一切使用しません。 +そのNodeでkubeletを実行するには、`--fail-swap-on=false`を設定する必要があります。 +ただ、大きな変更とはこのことではなく、もう1つのモードである`LimitedSwap`です。 +このモードでは、kubeletは実際にそのNodeのページファイルを使用し、Podが仮想メモリの一部をページアウトできるようにします。 +コンテナ(およびその親Pod)はメモリ制限を超えてスワップにアクセスすることはできませんが、利用可能な場合はスワップ領域を使用できます。 + +KubernetesのNode Special Interest Group (SIG Node)は、エンドユーザー、貢献者、およびより広いKubernetesコミュニティからのフィードバックに基づいて、改訂された実装の使用方法を理解できるようにドキュメントも更新します。 + +KubernetesにおけるLinux Nodeのスワップ・サポートの詳細については、前回の[ブログ記事](/blog/2023/08/24/swap-linux-beta/)または[Nodeのスワップ・ドキュメント](/ja/docs/concepts/architecture/nodes/#swap-memory)を読んでください。 + +### Podでユーザー名前空間のサポート ([KEP-127](https://kep.k8s.io/127)) + +[ユーザー名前空間](/docs/concepts/workloads/pods/user-namespaces)は、2024年1月に公開された[CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)を含むHigh/Criticalと評価された複数のCVEを防止、または緩和するために、Podをより適切に分離するLinux専用の機能です。 +Kubernetes 1.30では、ユーザー名前空間のサポートがベータ版に移行し、ボリュームのあるPodとないPod、カスタムUID/GID範囲などがサポートされるようになりました！ + +### 構造化された認可設定 ([KEP-3221](https://kep.k8s.io/3221)) + +[構造化された認可設定](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file)のサポートはベータ版に移行し、デフォルトで有効になります。 +この機能は、失敗時に明示的に拒否するなどのきめ細かな制御を可能にしたり、特定の順序でリクエストを検証する明確に定義されたパラメーターを持つ複数のWebhookによる認可チェーンの作成を可能にします。 +設定ファイルのアプローチでは、リクエストがWebhookへ渡される前に[CEL](/docs/reference/using-api/cel/)ルールを指定して事前にフィルタリングすることも可能で、不要なリクエストを防ぐのに役立ちます。 +また、設定ファイルが変更されると、APIサーバーは自動的に認可チェーンを再読み込みします。 + +`--authorization-config`コマンドライン引数を使用して、その認可設定へのパスを指定する必要があります。 +設定ファイルの代わりにコマンドラインフラグを使い続けたい場合、そのまま機能し続けます。 +複数のWebhook、失敗ポリシー、事前フィルタールールなどの新しい認可Webhook機能にアクセスするには、`--authorization-config`ファイルにオプションを記述するように切り替えます。 +Kubernetes 1.30からは、設定ファイルのフォーマットがベータ段階であり、フィーチャーゲートがデフォルトで有効になっているため、`--authorization-config`を指定する必要があるだけです。 +すべての可能な値を含む設定例は、[認可ドキュメント](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file)で提供されています。 +詳細については、[認可ドキュメント](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file)を読んでください。 + +### コンテナリソースをもとにしたPodの自動スケーリング ([KEP-1610](https://kep.k8s.io/1610)) + +`ContainerResource`メトリクスに基づく水平Pod自動スケーリングは、v1.30で安定版に移行します。 +HorizontalPodAutoscalerのこの新しい動作により、Pod全体のリソース使用量ではなく、個々のコンテナのリソース使用量に基づいて自動スケーリングを設定できるようになります。 +詳細については[以前の記事](/blog/2023/05/02/hpa-container-resource-metric/)を参照するか、[コンテナリソースメトリクス](/ja/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics)を読んでください。 + + +### アドミッション・コントロールに対するCEL ([KEP-3488](https://kep.k8s.io/3488)) + +Kubernetesのアドミッション・コントロールにCommon Expression Language (CEL)を統合することで、アドミッション・リクエストを評価するよりダイナミックで表現力豊かな方法が導入されます。 +この機能により、複雑できめ細かなポリシーがKubernetes APIを通じて直接定義・適用できるようになり、パフォーマンスや柔軟性を損なうことなく、セキュリティとガバナンスの機能が強化されます。 + +CELがKubernetesのアドミッション・コントロールに追加されたことで、クラスター管理者はWebhookベースのアクセス・コントローラーに頼ることなく、クラスターの望ましい状態やポリシーに対してAPIリクエストの内容を評価できる複雑なルールを作成できます。 +このレベルの制御は、クラスター運用の効率性、セキュリティ、整合性を維持するために極めて重要であり、Kubernetes環境をより堅牢にし、さまざまなユースケースや要件へ適応できるようにします。 +アドミッション・コントロールにCELを使用する詳細については、ValidatingAdmissionPolicyの[APIドキュメント](/docs/reference/access-authn-authz/validating-admission-policy/)を参照してください。 + +私たちと同じようにこのリリースを楽しみにしていただければ幸いです。数週間後の公式のリリース記事で、さらなるハイライトをお見逃しなく！ diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index e237742df1193..b4435c705f6d9 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -31,7 +31,7 @@ weight: 30 IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 -Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。 +Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#type-nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。 ## Ingressを使用する上での前提条件 @@ -473,7 +473,7 @@ Events: Ingressリソースを直接含まずにサービスを公開する方法は複数あります。 * [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer) -* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport) +* [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#type-nodeport) ## {{% heading "whatsnext" %}} diff --git a/content/zh-cn/community/static/cncf-code-of-conduct.md b/content/zh-cn/community/static/cncf-code-of-conduct.md index 316dbb05525d5..c796ec5b6ab57 100644 --- a/content/zh-cn/community/static/cncf-code-of-conduct.md +++ b/content/zh-cn/community/static/cncf-code-of-conduct.md @@ -143,7 +143,7 @@ For incidents occurring in the Kubernetes community, contact the [Kubernetes Cod 对于其他项目、或与项目无关或影响到多个 CNCF 项目的事件，请通过 联系 [CNCF 行为准则委员会](https://www.cncf.io/conduct/committee/)。 diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index 039ca181adac9..db4ac045f49bd 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -553,464 +553,6 @@ for more information. `kubelet` 可以在作出资源分配决策时使用拓扑提示。 参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 - -## 节点体面关闭 {#graceful-node-shutdown} - -{{< feature-state feature_gate_name="GracefulNodeShutdown" >}} - - -kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的所有 Pod。 - -在节点终止期间，kubelet 保证 Pod 遵从常规的 -[Pod 终止流程](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)， -且不接受新的 Pod（即使这些 Pod 已经绑定到该节点）。 - - -节点体面关闭特性依赖于 systemd，因为它要利用 -[systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)机制， -在给定的期限内延迟节点关闭。 - - -节点体面关闭特性受 `GracefulNodeShutdown` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)控制， -在 1.21 版本中是默认启用的。 - - -注意，默认情况下，下面描述的两个配置选项，`shutdownGracePeriod` 和 -`shutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活节点体面关闭功能。 -要激活此功能特性，这两个 kubelet 配置选项要适当配置，并设置为非零值。 - - -一旦 systemd 检测到或通知节点关闭，kubelet 就会在节点上设置一个 -`NotReady` 状况，并将 `reason` 设置为 `"node is shutting down"`。 -kube-scheduler 会重视此状况，不将 Pod 调度到受影响的节点上； -其他第三方调度程序也应当遵循相同的逻辑。这意味着新的 Pod 不会被调度到该节点上， -因此不会有新 Pod 启动。 - - -如果检测到节点关闭过程正在进行中，kubelet **也会**在 `PodAdmission` -阶段拒绝 Pod，即使是该 Pod 带有 `node.kubernetes.io/not-ready:NoSchedule` -的{{< glossary_tooltip text="容忍度" term_id="toleration" >}}。 - - -同时，当 kubelet 通过 API 在其 Node 上设置该状况时，kubelet -也开始终止在本地运行的所有 Pod。 - - -在体面关闭节点过程中，kubelet 分两个阶段来终止 Pod： - -1. 终止在节点上运行的常规 Pod。 -2. 终止在节点上运行的[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 - - -节点体面关闭的特性对应两个 -[`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项： - -* `shutdownGracePeriod`： - * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod - 还是[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 -* `shutdownGracePeriodCriticalPods`： - * 在节点关闭期间指定用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) - 的持续时间。该值应小于 `shutdownGracePeriod`。 - -{{< note >}} - -在某些情况下，节点终止过程会被系统取消（或者可能由管理员手动取消）。 -无论哪种情况下，节点都将返回到 `Ready` 状态。然而，已经开始终止进程的 -Pod 将不会被 kubelet 恢复，需要被重新调度。 -{{< /note >}} - - -例如，如果设置了 `shutdownGracePeriod=30s` 和 `shutdownGracePeriodCriticalPods=10s`， -则 kubelet 将延迟 30 秒关闭节点。 -在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod， -而保留最后 10 秒用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 - -{{< note >}} - -当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为关闭。 -运行 `kubectl get pods` 时，被驱逐的 Pod 的状态显示为 `Terminated`。 -并且 `kubectl describe pod` 表示 Pod 因节点关闭而被驱逐： - -``` -Reason: Terminated -Message: Pod was terminated in response to imminent node shutdown. -``` -{{< /note >}} - - -### 基于 Pod 优先级的节点体面关闭 {#pod-priority-graceful-node-shutdown} - -{{< feature-state feature_gate_name="GracefulNodeShutdownBasedOnPodPriority" >}} - - -为了在节点体面关闭期间提供更多的灵活性，尤其是处理关闭期间的 Pod 排序问题， -节点体面关闭机制能够关注 Pod 的 PriorityClass 设置，前提是你已经在集群中启用了此功能特性。 -此功能特性允许集群管理员基于 Pod -的[优先级类（Priority Class）](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) -显式地定义节点体面关闭期间 Pod 的处理顺序。 - - -前文所述的[节点体面关闭](#graceful-node-shutdown)特性能够分两个阶段关闭 Pod， -首先关闭的是非关键的 Pod，之后再处理关键 Pod。 -如果需要显式地以更细粒度定义关闭期间 Pod 的处理顺序，需要一定的灵活度， -这时可以使用基于 Pod 优先级的体面关闭机制。 - - -当节点体面关闭能够处理 Pod 优先级时，节点体面关闭的处理可以分为多个阶段， -每个阶段关闭特定优先级类的 Pod。kubelet 可以被配置为按确切的阶段处理 Pod， -且每个阶段可以独立设置关闭时间。 - - -假设集群中存在以下自定义的 Pod -[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 - -| Pod 优先级类名称 | Pod 优先级类数值 | -|-------------------------|------------------------| -|`custom-class-a` | 100000 | -|`custom-class-b` | 10000 | -|`custom-class-c` | 1000 | -|`regular/unset` | 0 | - - -在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中， -`shutdownGracePeriodByPodPriority` 可能看起来是这样： - -| Pod 优先级类数值 | 关闭期限 | -|------------------------|-----------| -| 100000 | 10 秒 | -| 10000 | 180 秒 | -| 1000 | 120 秒 | -| 0 | 60 秒 | - - -对应的 kubelet 配置 YAML 将会是： - -```yaml -shutdownGracePeriodByPodPriority: - - priority: 100000 - shutdownGracePeriodSeconds: 10 - - priority: 10000 - shutdownGracePeriodSeconds: 180 - - priority: 1000 - shutdownGracePeriodSeconds: 120 - - priority: 0 - shutdownGracePeriodSeconds: 60 -``` - - -上面的表格表明，所有 `priority` 值大于等于 100000 的 Pod 会得到 10 秒钟期限停止， -所有 `priority` 值介于 10000 和 100000 之间的 Pod 会得到 180 秒钟期限停止， -所有 `priority` 值介于 1000 和 10000 之间的 Pod 会得到 120 秒钟期限停止， -所有其他 Pod 将获得 60 秒的时间停止。 - -用户不需要为所有的优先级类都设置数值。例如，你也可以使用下面这种配置： - -| Pod 优先级类数值 | 关闭期限 | -|------------------------|-----------| -| 100000 | 300 秒 | -| 1000 | 120 秒 | -| 0 | 60 秒 | - - -在上面这个场景中，优先级类为 `custom-class-b` 的 Pod 会与优先级类为 `custom-class-c` -的 Pod 在关闭时按相同期限处理。 - -如果在特定的范围内不存在 Pod，则 kubelet 不会等待对应优先级范围的 Pod。 -kubelet 会直接跳到下一个优先级数值范围进行处理。 - - -如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。 - -使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， -并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) -中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置， -其中包含 Pod 的优先级类数值以及对应的关闭期限。 - -{{< note >}} - -在节点体面关闭期间考虑 Pod 优先级的能力是作为 Kubernetes v1.23 中的 Alpha 功能引入的。 -在 Kubernetes {{< skew currentVersion >}} 中该功能是 Beta 版，默认启用。 -{{< /note >}} - - -kubelet 子系统中会生成 `graceful_shutdown_start_time_seconds` 和 -`graceful_shutdown_end_time_seconds` 度量指标以便监视节点关闭行为。 - - -## 处理节点非体面关闭 {#non-graceful-node-shutdown} - -{{< feature-state feature_gate_name="NodeOutOfServiceVolumeDetach" >}} - - -节点关闭的操作可能无法被 kubelet 的节点关闭管理器检测到， -是因为该命令不会触发 kubelet 所使用的抑制锁定机制，或者是因为用户错误的原因， -即 ShutdownGracePeriod 和 ShutdownGracePeriodCriticalPod 配置不正确。 -请参考以上[节点体面关闭](#graceful-node-shutdown)部分了解更多详细信息。 - - -当某节点关闭但 kubelet 的节点关闭管理器未检测到这一事件时， -在那个已关闭节点上、属于 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} -的 Pod 将停滞于终止状态，并且不能移动到新的运行节点上。 -这是因为已关闭节点上的 kubelet 已不存在，亦无法删除 Pod， -因此 StatefulSet 无法创建同名的新 Pod。 -如果 Pod 使用了卷，则 VolumeAttachments 不会从原来的已关闭节点上删除， -因此这些 Pod 所使用的卷也无法挂接到新的运行节点上。 -所以，那些以 StatefulSet 形式运行的应用无法正常工作。 -如果原来的已关闭节点被恢复，kubelet 将删除 Pod，新的 Pod 将被在不同的运行节点上创建。 -如果原来的已关闭节点没有被恢复，那些在已关闭节点上的 Pod 将永远滞留在终止状态。 - - -为了缓解上述情况，用户可以手动将具有 `NoExecute` 或 `NoSchedule` 效果的 -`node.kubernetes.io/out-of-service` 污点添加到节点上，标记其无法提供服务。 -如果在 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} -上启用了 `NodeOutOfServiceVolumeDetach` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， -并且节点被通过污点标记为无法提供服务，如果节点 Pod 上没有设置对应的容忍度， -那么这样的 Pod 将被强制删除，并且该在节点上被终止的 Pod 将立即进行卷分离操作。 -这样就允许那些在无法提供服务节点上的 Pod 能在其他节点上快速恢复。 - - -在非体面关闭期间，Pod 分两个阶段终止： - -1. 强制删除没有匹配的 `out-of-service` 容忍度的 Pod。 -2. 立即对此类 Pod 执行分离卷操作。 - -{{< note >}} - -- 在添加 `node.kubernetes.io/out-of-service` 污点之前， - 应该验证节点已经处于关闭或断电状态（而不是在重新启动中）。 -- 将 Pod 移动到新节点后，用户需要手动移除停止服务的污点， - 并且用户要检查关闭节点是否已恢复，因为该用户是最初添加污点的用户。 -{{< /note >}} - - -### 存储超时强制解除挂接 {#storage-force-detach-on-timeout} - -当任何 Pod 未能在 6 分钟内被成功删除时，如果节点当时不健康， -Kubernetes 将强制解除挂接正在被卸载的卷。 -在启用了强制解除挂接卷的节点上仍在运行的所有工作负载都将导致违反 -[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#controllerunpublishvolume)， -该规范指出 `ControllerUnpublishVolume` "**必须**在调用卷上的所有 `NodeUnstageVolume` -和 `NodeUnpublishVolume` 执行且成功后被调用"。在这种情况下，相关节点上的卷可能会遇到数据损坏。 - - -强制存储解除挂接行为是可选的；用户可以选择使用"非体面节点关闭"特性。 - - -可以通过在 `kube-controller-manager` 中设置 `disable-force-detach-on-timeout` -配置字段来禁用超时时存储强制解除挂接。 -禁用超时强制解除挂接特性意味着托管在不正常运行时间超过 6 分钟的节点上的卷将不会删除其关联的 -[VolumeAttachment](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/)。 - - -应用此设置后，仍关联到某卷的不健康 Pod 必须通过上述[非体面节点关闭](#non-graceful-node-shutdown)过程进行恢复。 - -{{< note >}} - -- 使用[非体面节点关闭](#non-graceful-node-shutdown)过程时必须小心。 -- 偏离上述步骤可能会导致数据损坏。 -{{< /note >}} - diff --git a/content/zh-cn/docs/concepts/storage/persistent-volumes.md b/content/zh-cn/docs/concepts/storage/persistent-volumes.md index 9cf0132c0b041..aec58ab232504 100644 --- a/content/zh-cn/docs/concepts/storage/persistent-volumes.md +++ b/content/zh-cn/docs/concepts/storage/persistent-volumes.md @@ -1,5 +1,8 @@ --- title: 持久卷 +api_metadata: +- apiVersion: "v1" + kind: "PersistentVolume" feature: title: 存储编排 description: > @@ -15,6 +18,9 @@ reviewers: - msau42 - xing-yang title: Persistent Volumes +api_metadata: +- apiVersion: "v1" + kind: "PersistentVolume" feature: title: Storage orchestration description: > @@ -862,54 +868,71 @@ PV 持久卷是用插件的形式来实现的。Kubernetes 目前支持以下插 mounted on nodes. * [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage --> -* [`csi`](/zh-cn/docs/concepts/storage/volumes/#csi) - 容器存储接口 (CSI) -* [`fc`](/zh-cn/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 存储 +* [`csi`](/zh-cn/docs/concepts/storage/volumes/#csi) - 容器存储接口（CSI） +* [`fc`](/zh-cn/docs/concepts/storage/volumes/#fc) - Fibre Channel（FC）存储 * [`hostPath`](/zh-cn/docs/concepts/storage/volumes/#hostpath) - HostPath 卷 （仅供单节点测试使用；不适用于多节点集群；请尝试使用 `local` 卷作为替代） -* [`iscsi`](/zh-cn/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 存储 +* [`iscsi`](/zh-cn/docs/concepts/storage/volumes/#iscsi) - iSCSI（IP 上的 SCSI）存储 * [`local`](/zh-cn/docs/concepts/storage/volumes/#local) - 节点上挂载的本地存储设备 -* [`nfs`](/zh-cn/docs/concepts/storage/volumes/#nfs) - 网络文件系统 (NFS) 存储 +* [`nfs`](/zh-cn/docs/concepts/storage/volumes/#nfs) - 网络文件系统（NFS）存储 -以下的持久卷已被弃用。这意味着当前仍是支持的，但是 Kubernetes 将来的发行版会将其移除。 +以下的持久卷已被弃用但仍然可用。 +如果你使用除 `flexVolume`、`cephfs` 和 `rbd` 之外的卷类型，请安装相应的 CSI 驱动程序。 -* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) - Azure File - （于 v1.21 **弃用**） -* [`flexVolume`](/zh-cn/docs/concepts/storage/volumes/#flexVolume) - FlexVolume （于 v1.23 **弃用**） +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic 块存储（EBS） + （从 v1.23 开始**默认启用迁移**） +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure 磁盘 + （从 v1.23 开始**默认启用迁移**） +* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) - Azure 文件 + （从 v1.24 开始**默认启用迁移**） +* [`cephfs`](/zh-cn/docs/concepts/storage/volumes/#cephfs) - CephFS 卷 + （从 v1.28 开始**弃用**，没有迁移计划，未来版本将移除支持） +* [`cinder`](/zh-cn/docs/concepts/storage/volumes/#cinder) - Cinder（OpenStack 块存储） + （从 v1.21 开始**默认启用迁移**） +* [`flexVolume`](/zh-cn/docs/concepts/storage/volumes/#flexVolume) - FlexVolume + （从 v1.23 开始**弃用**，没有迁移计划，没有移除支持的计划） +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcePersistentDisk) - GCE 持久磁盘 + （从 v1.23 开始**默认启用迁移**） * [`portworxVolume`](/zh-cn/docs/concepts/storage/volumes/#portworxvolume) - Portworx 卷 - （于 v1.25 **弃用**） + （从 v1.25 开始**弃用**） * [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷 （于 v1.19 **弃用**） * [`cephfs`](/zh-cn/docs/concepts/storage/volumes/#cephfs) - CephFS 卷 （于 v1.28 **弃用**） -* [`rbd`](/zh-cn/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 卷 - （于 v1.28 **弃用**） +* [`rbd`](/zh-cn/docs/concepts/storage/volumes/#rbd) - Rados Block Device（RBD）卷 + （从 v1.28 开始**弃用**，没有迁移计划，未来版本将移除支持） +* [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷 + （从 v1.25 开始**默认启用迁移**） 旧版本的 Kubernetes 仍支持这些“树内（In-Tree）”持久卷类型： -* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) - （v1.27 开始**不可用**） -* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk) - Azure Disk - （v1.27 开始**不可用**） -* [`cinder`](/zh-cn/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) - （v1.27 开始**不可用**） * `photonPersistentDisk` - Photon 控制器持久化盘。（从 v1.15 版本开始将**不可用**） * `scaleIO` - ScaleIO 卷（v1.21 之后**不可用**） -* `flocker` - Flocker 存储 （v1.25 之后**不可用**） -* `quobyte` - Quobyte 卷 （v1.25 之后**不可用**） -* `storageos` - StorageOS 卷 （v1.25 之后**不可用**） +* `flocker` - Flocker 存储（v1.25 之后**不可用**） +* `quobyte` - Quobyte 卷（v1.25 之后**不可用**） +* `storageos` - StorageOS 卷（v1.25 之后**不可用**） 每个 PVC 对象都有 `spec` 和 `status` 部分，分别对应申领的规约和状态。 PersistentVolumeClaim 对象的名称必须是合法的 -[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 ```yaml apiVersion: v1 @@ -1574,7 +1591,7 @@ it won't be supported in a future Kubernetes release. -#### 可追溯的默认 StorageClass 赋值 {#retroactive-default-storageclass-assignment} +#### 可追溯的默认 StorageClass 赋值 {#retroactive-default-storageclass-assignment} {{< feature-state for_k8s_version="v1.28" state="stable" >}} @@ -1840,7 +1857,7 @@ Alpha 发行版本中仅支持静态制备的卷。 -## 对卷快照及从卷快照中恢复卷的支持 {#volume-snapshot-and-restore-volume-from-snapshot-support} +## 对卷快照及从卷快照中恢复卷的支持 {#volume-snapshot-and-restore-volume-from-snapshot-support} {{< feature-state for_k8s_version="v1.20" state="stable" >}} diff --git a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md index 778f3566687ee..2fdec0257d7d6 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,5 +1,8 @@ --- title: CronJob +api_metadata: +- apiVersion: "batch/v1" + kind: "CronJob" content_type: concept description: >- CronJob 通过重复调度启动一次性的 Job。 @@ -12,6 +15,9 @@ reviewers: - soltysh - janetkuo title: CronJob +api_metadata: +- apiVersion: "batch/v1" + kind: "CronJob" content_type: concept description: >- A CronJob starts one-time Jobs on a repeating schedule. @@ -310,18 +316,28 @@ When `.spec.suspend` changes from `true` to `false` on an existing CronJob witho ### 任务历史限制 {#jobs-history-limits} -`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 字段是可选的。 -这两个字段指定应保留多少已完成和失败的 Job。 -默认设置分别为 3 和 1。将限制设置为 `0` 代表相应类型的 Job 完成后不会保留。 +`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` +字段指定应保留多少已完成和失败的 Job。这两个字段都是可选的。 + +* `.spec.successfulJobsHistoryLimit`：此字段指定要保留多少成功完成的 Job。默认值为 `3`。 + 将此字段设置为 `0` 意味着不会保留任何成功的 Job。 + +* `.spec.failedJobsHistoryLimit`：此字段指定要保留多少失败完成的 Job。默认值为 `1`。 + 将此字段设置为 `0` 意味着不会保留任何失败的 Job。 有关自动清理 Job 的其他方式， 请参见[自动清理完成的 Job](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)。 @@ -362,7 +378,7 @@ Go 标准库中的时区数据库包含在二进制文件中，并用作备用 ### Unsupported TimeZone specification --> -## CronJob 的限制 {#cronjob-limitations} +## CronJob 的限制 {#cron-job-limitations} ### 不支持的时区规范 {#unsupported-timezone-spec} diff --git a/content/zh-cn/docs/contribute/localization.md b/content/zh-cn/docs/contribute/localization.md index e630d6cfcb7df..ebdebb92ca7be 100644 --- a/content/zh-cn/docs/contribute/localization.md +++ b/content/zh-cn/docs/contribute/localization.md @@ -621,15 +621,15 @@ Releases | [All heading and subheading URLs](/releases) Translated documents must reside in their own `content/**/` subdirectory, but otherwise, follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, -create a subfolder under the `content/de/` folder and copy the English source: +create a subdirectory under the `content/de/` directory and copy the English source or directory: --> 翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 例如，要准备将 [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/)教程翻译为德语， -请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： +请在 `content/de/` 目录下创建一个子目录，并复制英文源文件或目录： ```shell mkdir -p content/de/docs/tutorials -cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md +cp -ra content/en/docs/tutorials/kubernetes-basics/ content/de/docs/tutorials/ ``` -此页面提供准入控制器（Admission Controllers）的概述。 +此页面提供准入控制器（Admission Controller）的概述。 @@ -69,7 +69,7 @@ Kubernetes {{< skew currentVersion >}} 并编译进 `kube-apiserver` 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置， -分别执行变更和验证[准入控制 webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 +分别执行变更和验证[准入控制 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 -**类别**：验证。 - -{{< feature-state for_k8s_version="v1.27" state="deprecated" >}} - -{{< caution >}} - -Kubernetes 项目建议你**不要使用** `SecurityContextDeny` 准入控制器。 - -`SecurityContextDeny` 准入控制器插件已被弃用，并且默认处于禁用状态。 -此插件将在后续的版本中被移除。如果你选择启用 `SecurityContextDeny` 准入控制器插件， -也必须同时启用 `SecurityContextDeny` 特性门控。 - - -`SecurityContextDeny` 准入插件已被弃用，因为它已经过时且不完整； -它可能无法使用或无法达到你的预期。该插件实现之时，就无法限制 Pod API 的所有与安全相关的属性。 -例如，`privileged` 和 `ephemeralContainers` 字段就从未受过此插件的限制。 - - -采用 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)中的 `Restricted` -方案的 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)插件， -能以更好和最新的方式来表述此插件所要实现的目标。 -{{< /caution >}} - - -此准入控制器将拒绝任何尝试设置以下 -[SecurityContext](/zh-cn/docs/tasks/configure-pod-container/security-context/) -字段的 Pod： - -- `.spec.securityContext.supplementalGroups` -- `.spec.securityContext.seLinuxOptions` -- `.spec.securityContext.runAsUser` -- `.spec.securityContext.fsGroup` -- `.spec.(init)Containers[*].securityContext.seLinuxOptions` -- `.spec.(init)Containers[*].securityContext.runAsUser` - - -有关此插件的更多历史背景，请参阅 Kubernetes 博客中这篇有关 PodSecurityPolicy 及其移除的文章： -[The birth of PodSecurityPolicy](/blog/2022/08/23/podsecuritypolicy-the-historical-context/#the-birth-of-podsecuritypolicy)。 -这篇文章详细地介绍了 PodSecurityPolicy 的历史背景以及 Pod 的 `securityContext` 字段的诞生。 - ### ServiceAccount {#serviceaccount} @@ -93,8 +93,8 @@ In the following, we describe how to quickly experiment with admission webhooks. ### 先决条件 {#prerequisites} * 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。 - [这里](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use) - 是一组推荐的 admission 控制器，通常可以启用。 + [这里](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)是一组推荐的准入控制器， + 通常可以启用。 * 确保启用了 `admissionregistration.k8s.io/v1` API。 @@ -110,8 +110,8 @@ that is validated in a Kubernetes e2e test. The webhook handles the as an `AdmissionReview` object in the same version it received. --> 请参阅 Kubernetes e2e 测试中的 -[Admission Webhook 服务器](https://github.com/kubernetes/kubernetes/blob/release-1.21/test/images/agnhost/webhook/main.go) -的实现。Webhook 处理由 API 服务器发送的 `AdmissionReview` 请求，并且将其决定作为 +[Admission Webhook 服务器](https://github.com/kubernetes/kubernetes/blob/release-1.21/test/images/agnhost/webhook/main.go)的实现。 +Webhook 处理由 API 服务器发送的 `AdmissionReview` 请求，并且将其决定作为 `AdmissionReview` 对象以相同版本发送回去。 ### 匹配请求：`matchConditions` {#matching-requests-matchConditions} -{{< feature-state state="beta" for_k8s_version="v1.28" >}} +{{< feature-state feature_gate_name="AdmissionWebhookMatchConditions" >}} +允许对类型为 `LoadBalancer` 以外的 Service 设置 `.status.ingress.loadBalancer`。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-managed-by.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-managed-by.md new file mode 100644 index 0000000000000..d08d52a01c3b2 --- /dev/null +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-managed-by.md @@ -0,0 +1,18 @@ +--- +title: JobManagedBy +content_type: feature_gate + +_build: + list: never + render: false + +stages: + - stage: alpha + defaultValue: false + fromVersion: "1.30" +--- + + +允许将 Job 对象的调和委托给外部控制器。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-success-policy.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-success-policy.md new file mode 100644 index 0000000000000..21c5285b7cd48 --- /dev/null +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/job-success-policy.md @@ -0,0 +1,18 @@ +--- +title: JobSuccessPolicy +content_type: feature_gate + +_build: + list: never + render: false + +stages: + - stage: alpha + defaultValue: false + fromVersion: "1.30" +--- + + +允许用户基于一组成功的 Pod 来声明这组 Pod 所属的 Job 为成功。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/kubelet-pod-resources-dynamice-resources.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/kubelet-pod-resources-dynamice-resources.md new file mode 100644 index 0000000000000..5d20f979ac334 --- /dev/null +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/kubelet-pod-resources-dynamice-resources.md @@ -0,0 +1,23 @@ +--- +title: KubeletPodResourcesDynamicResources +content_type: feature_gate +_build: + list: never + render: false + +stages: + - stage: alpha + defaultValue: false + fromVersion: "1.27" +--- + + +扩展 kubelet 的 Pod 资源 gRPC 端点，通过 `DynamicResourceAllocation` API 把已分配的资源算入 `ResourceClaims` 中。 +有关更多细节，参见[资源分配报告](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)。 +使用可分配资源的信息，使客户端能够正确跟踪节点上的空闲计算资源。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/name-generation-retries.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/name-generation-retries.md new file mode 100644 index 0000000000000..5e2a05ba20e27 --- /dev/null +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/name-generation-retries.md @@ -0,0 +1,24 @@ +--- +title: NameGenerationRetries +content_type: feature_gate + +_build: + list: never + render: false + +stages: + - stage: alpha + defaultValue: false + fromVersion: "1.30" +--- + + +当 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}要生成[名称](/zh-cn/docs/concepts/overview/working-with-objects/names/#names)时， +允许重试对象创建。当此特性被启用时，如果控制平面检测到与某个现有对象存在名称冲突， +则使用 `generateName` 的请求将被自动重试，最多重试 8 次。 diff --git a/content/zh-cn/docs/reference/node/kubelet-config-directory-merging.md b/content/zh-cn/docs/reference/node/kubelet-config-directory-merging.md new file mode 100644 index 0000000000000..07d3b60b2b398 --- /dev/null +++ b/content/zh-cn/docs/reference/node/kubelet-config-directory-merging.md @@ -0,0 +1,223 @@ +--- +content_type: "reference" +title: kubelet 配置目录合并 +weight: 50 +--- + + + +当使用 kubelet 的 `--config-dir` 标志来指定存放配置的目录时，不同类型的配置会有一些特定的行为。 + +以下是在配置合并过程中不同数据类型的一些行为示例： + + +### 结构字段 {#structure-fields} + +在 YAML 结构中有两种结构字段：独立（标量类型）和嵌入式（此结构包含标量类型）。 +配置合并过程将处理独立构造字段和嵌入式构造字段的重载，以创建最终的 kubelet 配置。 + + +例如，你可能想要为所有节点设置一个基准 kubelet 配置，但希望自定义 `address` 和 `authorization` 字段。 +这种情况下，你可以按以下方式完成： + +kubelet 主配置文件内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +authorization: + mode: Webhook + webhook: + cacheAuthorizedTTL: "5m" + cacheUnauthorizedTTL: "30s" +serializeImagePulls: false +address: "192.168.0.1" +``` + + +`--config-dir` 目录中文件的内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +authorization: + mode: AlwaysAllow + webhook: + cacheAuthorizedTTL: "8m" + cacheUnauthorizedTTL: "45s" +address: "192.168.0.8" +``` + + +生成的配置如下所示： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +serializeImagePulls: false +authorization: + mode: AlwaysAllow + webhook: + cacheAuthorizedTTL: "8m" + cacheUnauthorizedTTL: "45s" +address: "192.168.0.8" +``` + + +### 列表 {#lists} + +你可以重载 kubelet 配置的切片/列表值。 +但在合并过程中整个列表将被重载。 +例如，你可以按以下方式重载 `clusterDNS` 列表： + +kubelet 主配置文件的内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +serializeImagePulls: false +clusterDNS: + - "192.168.0.9" + - "192.168.0.8" +``` + + +`--config-dir` 目录中文件的内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +clusterDNS: + - "192.168.0.2" + - "192.168.0.3" + - "192.168.0.5" +``` + + +生成的配置如下所示： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +serializeImagePulls: false +clusterDNS: + - "192.168.0.2" + - "192.168.0.3" + - "192.168.0.5" +``` + + +### 含嵌套结构的映射 {#maps-including-nested-structures} + +映射中的各个字段（无论其值类型是布尔值、字符串等）都可以被选择性地重载。 +但对于 `map[string][]string` 类型来说，与特定字段关联的整个列表都将被重载。 +让我们通过一个例子更好地理解这一点，特别是 `featureGates` 和 `staticPodURLHeader` 这类字段： + +kubelet 主配置文件的内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +serializeImagePulls: false +featureGates: + AllAlpha: false + MemoryQoS: true +staticPodURLHeader: + kubelet-api-support: + - "Authorization: 234APSDFA" + - "X-Custom-Header: 123" + custom-static-pod: + - "Authorization: 223EWRWER" + - "X-Custom-Header: 456" +``` + + +`--config-dir` 目录中文件的内容： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +featureGates: + MemoryQoS: false + KubeletTracing: true + DynamicResourceAllocation: true +staticPodURLHeader: + custom-static-pod: + - "Authorization: 223EWRWER" + - "X-Custom-Header: 345" +``` + + +生成的配置如下所示： + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +port: 20250 +serializeImagePulls: false +featureGates: + AllAlpha: false + MemoryQoS: false + KubeletTracing: true + DynamicResourceAllocation: true +staticPodURLHeader: + kubelet-api-support: + - "Authorization: 234APSDFA" + - "X-Custom-Header: 123" + custom-static-pod: + - "Authorization: 223EWRWER" + - "X-Custom-Header: 345" +``` diff --git a/content/zh-cn/docs/reference/tools/map-crictl-dockercli.md b/content/zh-cn/docs/reference/tools/map-crictl-dockercli.md index 25fa564e4b6fd..7801599fb9ab6 100644 --- a/content/zh-cn/docs/reference/tools/map-crictl-dockercli.md +++ b/content/zh-cn/docs/reference/tools/map-crictl-dockercli.md @@ -17,13 +17,13 @@ This page is being directed to https://v1-24.docs.kubernetes.io/docs/reference/tools/map-crictl-dockercli/ because of the [removal of dockershim from crictl in v1.24](https://github.com/kubernetes-sigs/cri-tools/issues/870). As per our community policy, deprecated documents are not maintained beyond next three versions. -The reason for deprecation is explained in [Dockershim-FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). +The reason for deprecation is explained in [Dockershim-FAQ](/blog/2020/12/02/dockershim-faq/). --> 此页面被重定向到 https://v1-24.docs.kubernetes.io/zh-cn/docs/reference/tools/map-crictl-dockercli/ ，原因是 [dockershim 在 v1.24 中被从 crictl 中移除](https://github.com/kubernetes-sigs/cri-tools/issues/870)。 根据我们的社区政策，弃用的文档超过三个版本后不再维护。 -弃用的原因在 [Dockershim-FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/) 中进行了说明。 +弃用的原因在 [Dockershim-FAQ](/zh-cn/docs/blog/2020/12/02/dockershim-faq/) 中进行了说明。 {{}} diff --git a/content/zh-cn/docs/reference/using-api/api-concepts.md b/content/zh-cn/docs/reference/using-api/api-concepts.md index e1d1e02dfb781..196e35094b7c4 100644 --- a/content/zh-cn/docs/reference/using-api/api-concepts.md +++ b/content/zh-cn/docs/reference/using-api/api-concepts.md @@ -381,7 +381,7 @@ the API server will send any `BOOKMARK` event even when requested. --> ## 流式列表 {#streaming-lists} -{{< feature-state for_k8s_version="v1.27" state="alpha" >}} +{{< feature-state feature_gate_name="WatchList" >}} ## 响应压缩 {#response-compression} -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state feature_gate_name="APIResponseCompression" >}} ## 分块检视大体量结果 {#retrieving-large-results-sets-in-chunks} -{{< feature-state for_k8s_version="v1.29" state="stable" >}} +{{< feature-state feature_gate_name="APIListChunking" >}} 与 **watch** 操作类似，`continue` 令牌也会在很短的时间（默认为 5 分钟）内过期， @@ -1252,7 +1252,7 @@ These situations are: --> ### 检查无法识别或重复的字段 {#setting-the-field-validation-level} -{{< feature-state for_k8s_version="v1.27" state="stable" >}} +{{< feature-state feature_gate_name="ServerSideFieldValidation" >}} ## 试运行 {#dry-run} -{{< feature-state for_k8s_version="v1.18" state="stable" >}} +{{< feature-state feature_gate_name="DryRun" >}} {{< table caption="CEL 表达式例子和每个表达式的用途" >}} @@ -109,6 +111,8 @@ CEL 表达式示例： | `self.metadata.name == 'singleton'` | 验证某对象的名称与特定的值匹配（使其成为一个特例） | | `self.set1.all(e, !(e in self.set2))` | 验证两个 listSet 不相交 | | `self.names.size() == self.details.size() && self.names.all(n, n in self.details)` | 验证 'details' 映射是由 'names' listSet 中的各项键入的 | +| `self.details.all(key, key.matches('^[a-zA-Z]*$')` | 验证 'details' 映射的主键 | +| `self.details.all(key, self.details[key].matches('^[a-zA-Z]*$')` | 验证 'details' 映射的值 | {{< /table >}} -**v1.29** 发行版本将停止提供以下已弃用的 API 版本： +**v1.29** 发行版本停止支持以下已弃用的 API 版本： -**flowcontrol.apiserver.k8s.io/v1beta2** API 版本的 FlowSchema -和 PriorityLevelConfiguration 将不会在 v1.29 中提供。 +从 v1.29 版本开始不再提供 **flowcontrol.apiserver.k8s.io/v1beta2** API 版本的 +FlowSchema 和 PriorityLevelConfiguration。 * 迁移清单和 API 客户端使用 **flowcontrol.apiserver.k8s.io/v1** API 版本（自 v1.29 版本开始可用）， 或 **flowcontrol.apiserver.k8s.io/v1beta3** API 版本（自 v1.26 起可用）； @@ -111,13 +111,13 @@ The **v1.27** release stopped serving the following deprecated API versions: #### CSIStorageCapacity {#csistoragecapacity-v127} -**storage.k8s.io/v1beta1** API 版本的 CSIStorageCapacity 将不会在 v1.27 提供。 +从 v1.27 版本开始不再提供 **storage.k8s.io/v1beta1** API 版本的 CSIStorageCapacity。 * 自 v1.24 版本起，迁移清单和 API 客户端使用 **storage.k8s.io/v1** API 版本 * 所有现有的持久化对象都可以通过新的 API 访问 @@ -138,15 +138,14 @@ The **v1.26** release stopped serving the following deprecated API versions: 从 v1.26 版本开始不再提供 **flowcontrol.apiserver.k8s.io/v1beta1** API 版本的 FlowSchema 和 PriorityLevelConfiguration。 -* 迁移清单和 API 客户端使用 **flowcontrol.apiserver.k8s.io/v1beta3** API 版本， - 此 API 从 v1.26 版本开始可用； +* 迁移清单和 API 客户端使用 **flowcontrol.apiserver.k8s.io/v1beta2** API 版本； * 所有的已保存的对象都可以通过新的 API 来访问； * 没有需要额外注意的变更。 @@ -157,6 +156,8 @@ The **autoscaling/v2beta2** API version of HorizontalPodAutoscaler is no longer * Migrate manifests and API clients to use the **autoscaling/v2** API version, available since v1.23. * All existing persisted objects are accessible via the new API +* Notable changes: + * `targetAverageUtilization` is replaced with `target.averageUtilization` and `target.type: Utilization`. See [Autoscaling on multiple metrics and custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics). --> 从 v1.26 版本开始不再提供 **autoscaling/v2beta2** API 版本的 HorizontalPodAutoscaler。 @@ -164,6 +165,9 @@ HorizontalPodAutoscaler。 * 迁移清单和 API 客户端使用 **autoscaling/v2** API 版本， 此 API 从 v1.23 版本开始可用； * 所有的已保存的对象都可以通过新的 API 来访问。 +* 值得注意的变更： + * `targetAverageUtilization` 被替换为 `target.averageUtilization` 和 `target.type: Utilization`。 + 请参阅[基于多项度量指标和自定义度量指标自动扩缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)。 ### v1.25 @@ -263,12 +267,17 @@ The **autoscaling/v2beta1** API version of HorizontalPodAutoscaler is no longer * Migrate manifests and API clients to use the **autoscaling/v2** API version, available since v1.23. * All existing persisted objects are accessible via the new API +* Notable changes: + * `targetAverageUtilization` is replaced with `target.averageUtilization` and `target.type: Utilization`. See [Autoscaling on multiple metrics and custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics). --> 从 v1.25 版本开始不再提供 **autoscaling/v2beta1** API 版本的 HorizontalPodAutoscaler。 * 迁移清单和 API 客户端使用 **autoscaling/v2** API 版本，此 API 从 v1.23 版本开始可用； * 所有的已保存的对象都可以通过新的 API 来访问。 +* 值得注意的变更： + * `targetAverageUtilization` 被替换为 `target.averageUtilization` 和 `target.type: Utilization`。 + 请参阅[基于多项度量指标和自定义度量指标自动扩缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)。 #### PodDisruptionBudget {#poddisruptionbudget-v125} diff --git a/content/zh-cn/docs/reference/using-api/health-checks.md b/content/zh-cn/docs/reference/using-api/health-checks.md index a62840b2efb72..241b04de2d369 100644 --- a/content/zh-cn/docs/reference/using-api/health-checks.md +++ b/content/zh-cn/docs/reference/using-api/health-checks.md @@ -131,12 +131,13 @@ healthz check passed 每个单独的健康检查都会公开一个 HTTP 端点，并且可以单独检查。 -单个运行状况检查的模式为 `/livez/`，其中 `livez` 和 `readyz` 表明你要检查的是 API 服务器是否存活或就绪。 +单个运行状况检查的模式为 `/livez/` 或 `/readyz/`， +其中 `livez` 和 `readyz` 分别表明你要检查的是 API 服务器是否存活或就绪。 `` 的路径可以通过上面的 `verbose` 参数发现 ，并采用 `[+]` 和 `ok` 之间的路径。 这些单独的健康检查不应由机器使用，但对于操作人员调试系统而言，是有帮助的： diff --git a/content/zh-cn/docs/reference/using-api/server-side-apply.md b/content/zh-cn/docs/reference/using-api/server-side-apply.md index 8eedbe818b1cf..8ae947541d004 100644 --- a/content/zh-cn/docs/reference/using-api/server-side-apply.md +++ b/content/zh-cn/docs/reference/using-api/server-side-apply.md @@ -16,7 +16,7 @@ weight: 25 -{{< feature-state for_k8s_version="v1.22" state="stable" >}} +{{< feature-state feature_gate_name="ServerSideApply" >}} 不管你提交的是 JSON 数据还是 YAML 数据， 都要使用 `application/apply-patch+yaml` 作为 `Content-Type` 的值。 -所有的 JSON 文档 都是合法的 YAML。 +所有的 JSON 文档都是合法的 YAML。不过，Kubernetes 存在一个缺陷， +即它使用的 YAML 解析器没有完全实现 YAML 规范。 +某些 JSON 转义可能无法被识别。 {{< /note >}} +## {{% heading "prerequisites" %}} + + +此页面中的某些步骤使用 `jq` 工具。如果你没有 `jq`，你可以通过操作系统的软件源安装它，或者从 +[https://jqlang.github.io/jq/](https://jqlang.github.io/jq/) 中获取它。 + +某些步骤还涉及安装 `curl`，它可以通过操作系统的软件源安装。 + ## kubelet 配置文件的插件目录 {#kubelet-conf-d} -自 Kubernetes v1.28.0 起，kubelet 被扩展以支持一个插件配置目录。 -该目录的位置可以使用 `--config-dir` 标志来指定，默认为 `""`，也就是被禁用状态。 +{{}} -只有在为 kubelet 进程设置环境变量 `KUBELET_CONFIG_DROPIN_DIR_ALPHA` -（该变量的值无关紧要）时才可以设置 `--config-dir`。对于 Kubernetes v{{< skew currentVersion >}}， -如果你未设置该变量而指定了 `--config-dir`，kubelet 将返回错误并且启动失败。 -你不能使用 kubelet 配置文件指定插件配置目录；只能使用 CLI 参数 `--config-dir` 进行设置。 +你可以为 kubelet 指定一个插件配置目录。默认情况下，kubelet +不会在任何地方查找插件配置文件 - 你必须指定路径。 +例如：`--config-dir=/etc/kubernetes/kubelet.conf.d` -你可以以类似于 kubelet 配置文件的方式使用 kubelet 配置目录。 +对于 Kubernetes v1.28 到 v1.29，如果你还为 kubelet +进程设置了环境变量 `KUBELET_CONFIG_DROPIN_DIR_ALPHA`（该变量的值无关紧要）， +则只能指定 `--config-dir`。 {{< note >}} -合法的 kubelet 插件配置文件的后缀必须为 `.conf`。例如 `99-kubelet-address.conf`。 +合法的 kubelet 插件配置文件的后缀**必须**为 `.conf`。例如 `99-kubelet-address.conf`。 {{< /note >}} -例如，你可能想要为所有节点设置一个基准的 kubelet 配置，但你可能想要自定义 `address` 字段。 -可以按如下方式操作： +kubelet 通过按字母数字顺序对**整个文件名**进行排序来处理其配置插件目录中的文件。 +例如，首先处理 `00-kubelet.conf`，然后用名为 `01-kubelet.conf` 的文件覆盖。 -kubelet 配置文件的主要内容如下： - -```yaml -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -port: 20250 -serializeImagePulls: false -evictionHard: - memory.available: "200Mi" -``` + +这些文件可能包含部分配置，并且它们本身可能不是有效的配置文件。 +仅对 kubelet 内部存储的、最终生成的配置结构执行验证。 +这让你能够灵活管理和组合不同来源的 kubelet 配置。 +但是，请务必注意，产生的行为会根据配置字段的数据类型而有所不同。 -`--config-dir` 目录中某个文件的内容如下： +kubelet 配置结构中不同数据类型的合并方式不同。 +有关详细信息，请参阅[参考文档](/zh-cn/docs/reference/node/kubelet-config-directory-merging.md)。 -```yaml -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -address: "192.168.0.8" -``` + +### kubelet 配置合并顺序 {#kubelet-configuration-merging-order} 在启动时，kubelet 会合并来自以下几部分的配置： -* 命令行参数（优先级最低）。 +* 在命令行中指定的特性门控（优先级最低）。 * kubelet 配置文件。 * 排序的插件配置文件。 -* 在命令行中指定的特性门控（优先级最高）。 +* 不包括特性门控的命令行参数（优先级最高）。 + +{{< note >}} + +kubelet 的配置插件目录机制类似，但与 `kubeadm` 工具允许 patch 配置的方式不同。 +`kubeadm` 工具使用特定的[补丁策略](/zh-cn/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches)， +而 kubelet 配置插件文件的唯一补丁策略是 `replace`。kubelet 根据字母数字对**后缀**进行排序来确定合并顺序， +并替换更高优先级文件中存在的每个字段。 +{{< /note >}} + + +## 查看 kubelet 配置 + + +由于现在可以使用此特性将配置分布在多个文件中，因此如果有人想要检查最终启动的配置， +他们可以按照以下步骤检查 kubelet 配置： + + +1. 在终端中使用 [`kubectl proxy`](/docs/reference/kubectl/generated/kubectl-commands#proxy) 启动代理服务器。 + + ```bash + kubectl proxy + ``` + + + 其输出如下： + + ```none + Starting to serve on 127.0.0.1:8001 + ``` -这将产生与之前示例中使用的[单个配置文件](#create-the-config-file)相同的结果。 +2. 打开另一个终端窗口并使用 `curl` 来获取 kubelet 配置。 + 将 `` 替换为节点的实际名称： + + ```bash + curl -X GET http://127.0.0.1:8001/api/v1/nodes//proxy/configz | jq . + ``` + + ```json + { + "kubeletconfig": { + "enableServer": true, + "staticPodPath": "/var/run/kubernetes/static-pods", + "syncFrequency": "1m0s", + "fileCheckFrequency": "20s", + "httpCheckFrequency": "20s", + "address": "192.168.1.16", + "port": 10250, + "readOnlyPort": 10255, + "tlsCertFile": "/var/lib/kubelet/pki/kubelet.crt", + "tlsPrivateKeyFile": "/var/lib/kubelet/pki/kubelet.key", + "rotateCertificates": true, + "authentication": { + "x509": { + "clientCAFile": "/var/run/kubernetes/client-ca.crt" + }, + "webhook": { + "enabled": true, + "cacheTTL": "2m0s" + }, + "anonymous": { + "enabled": true + } + }, + "authorization": { + "mode": "AlwaysAllow", + "webhook": { + "cacheAuthorizedTTL": "5m0s", + "cacheUnauthorizedTTL": "30s" + } + }, + "registryPullQPS": 5, + "registryBurst": 10, + "eventRecordQPS": 50, + "eventBurst": 100, + "enableDebuggingHandlers": true, + "healthzPort": 10248, + "healthzBindAddress": "127.0.0.1", + "oomScoreAdj": -999, + "clusterDomain": "cluster.local", + "clusterDNS": [ + "10.0.0.10" + ], + "streamingConnectionIdleTimeout": "4h0m0s", + "nodeStatusUpdateFrequency": "10s", + "nodeStatusReportFrequency": "5m0s", + "nodeLeaseDurationSeconds": 40, + "imageMinimumGCAge": "2m0s", + "imageMaximumGCAge": "0s", + "imageGCHighThresholdPercent": 85, + "imageGCLowThresholdPercent": 80, + "volumeStatsAggPeriod": "1m0s", + "cgroupsPerQOS": true, + "cgroupDriver": "systemd", + "cpuManagerPolicy": "none", + "cpuManagerReconcilePeriod": "10s", + "memoryManagerPolicy": "None", + "topologyManagerPolicy": "none", + "topologyManagerScope": "container", + "runtimeRequestTimeout": "2m0s", + "hairpinMode": "promiscuous-bridge", + "maxPods": 110, + "podPidsLimit": -1, + "resolvConf": "/run/systemd/resolve/resolv.conf", + "cpuCFSQuota": true, + "cpuCFSQuotaPeriod": "100ms", + "nodeStatusMaxImages": 50, + "maxOpenFiles": 1000000, + "contentType": "application/vnd.kubernetes.protobuf", + "kubeAPIQPS": 50, + "kubeAPIBurst": 100, + "serializeImagePulls": true, + "evictionHard": { + "imagefs.available": "15%", + "memory.available": "100Mi", + "nodefs.available": "10%", + "nodefs.inodesFree": "5%" + }, + "evictionPressureTransitionPeriod": "1m0s", + "enableControllerAttachDetach": true, + "makeIPTablesUtilChains": true, + "iptablesMasqueradeBit": 14, + "iptablesDropBit": 15, + "featureGates": { + "AllAlpha": false + }, + "failSwapOn": false, + "memorySwap": {}, + "containerLogMaxSize": "10Mi", + "containerLogMaxFiles": 5, + "configMapAndSecretChangeDetectionStrategy": "Watch", + "enforceNodeAllocatable": [ + "pods" + ], + "volumePluginDir": "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/", + "logging": { + "format": "text", + "flushFrequency": "5s", + "verbosity": 3, + "options": { + "json": { + "infoBufferSize": "0" + } + } + }, + "enableSystemLogHandler": true, + "enableSystemLogQuery": false, + "shutdownGracePeriod": "0s", + "shutdownGracePeriodCriticalPods": "0s", + "enableProfilingHandler": true, + "enableDebugFlagsHandler": true, + "seccompDefault": false, + "memoryThrottlingFactor": 0.9, + "registerNode": true, + "localStorageCapacityIsolation": true, + "containerRuntimeEndpoint": "unix:///var/run/crio/crio.sock" + } + } + ``` @@ -242,6 +431,9 @@ This produces the same outcome as if you used the [single configuration file](#c - Learn more about kubelet configuration by checking the [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) reference. +- Learn more about kubelet configuration merging in the + [reference document](/docs/reference/node/kubelet-config-directory-merging.md). ---> - 参阅 [`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 进一步学习 kubelet 的配置。 +- 在[参考文档](/zh-cn/docs/reference/node/kubelet-config-directory-merging.md)中了解有关 kubelet 配置合并的更多信息。 diff --git a/content/zh-cn/docs/tasks/job/pod-failure-policy.md b/content/zh-cn/docs/tasks/job/pod-failure-policy.md index f23269c8d41b7..76cabddaafff5 100644 --- a/content/zh-cn/docs/tasks/job/pod-failure-policy.md +++ b/content/zh-cn/docs/tasks/job/pod-failure-policy.md @@ -11,7 +11,7 @@ min-kubernetes-server-version: v1.25 weight: 60 --> -{{< feature-state for_k8s_version="v1.26" state="beta" >}} +{{< feature-state feature_gate_name="JobPodFailurePolicy" >}}