From 276c2a0adb1fbe77eafad438d755a71494990c43 Mon Sep 17 00:00:00 2001 From: HITMAN <112652819+ayushpatil2122@users.noreply.github.com> Date: Sat, 21 Sep 2024 22:48:12 +0530 Subject: [PATCH 01/40] Update garbage-collection.md --- content/zh-cn/docs/concepts/architecture/garbage-collection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh-cn/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md index 5b3441a5de..acce3462e1 100644 --- a/content/zh-cn/docs/concepts/architecture/garbage-collection.md +++ b/content/zh-cn/docs/concepts/architecture/garbage-collection.md @@ -369,7 +369,7 @@ downgrade `MaxPerPodContainer` to `1` and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. --> -除以上变量之外,kubelet 还会垃圾收集除无标识的以及已删除的容器,通常从最近未使用的容器开始。 +除以上变量之外,kubelet 还会垃圾收集除无标识的以及已删除的容器,通常从最长时间未使用的容器开始。 当保持每个 Pod 的最大数量的容器(`MaxPerPodContainer`)会使得全局的已死亡容器个数超出上限 (`MaxContainers`)时,`MaxPerPodContainer` 和 `MaxContainers` 之间可能会出现冲突。 From 20720a89365f563140711991365a5b964e8e6150 Mon Sep 17 00:00:00 2001 From: Kensei Nakada Date: Wed, 25 Oct 2023 22:57:57 +0900 Subject: [PATCH 02/40] KEP-4247(blog): QueueingHint --- .../index.md | 113 ++++++++++++++++++ .../queueinghint1.svg | 4 + .../queueinghint2.svg | 4 + 3 files changed, 121 insertions(+) create mode 100644 content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md create mode 100644 content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg create mode 100644 content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md new file mode 100644 index 0000000000..b1ad7ab2b6 --- /dev/null +++ b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md @@ -0,0 +1,113 @@ +--- +layout: blog +title: "Kubernetes v1.32: QueueingHint Brings a New Possibility to Optimize Pod Scheduling" +date: 2024-xx-xxT00:00:00-08:00 +slug: scheduler-queueinghint +--- + +**Author:** [Kensei Nakada](https://github.com/sanposhiho) (Tetrate.io) + +The Kubernetes [scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) is the core +component that decides which node any new Pods should run on. +Basically, it schedules Pods **one by one**, +and thus the larger your cluster is, the more crucial the throughput of the scheduler is. + +For the Kubernetes project, the throughput of the scheduler has been an eternal challenge +over the years, SIG Scheduling have been putting effort to improve the scheduling throughput by many enhancements. + +In this blog post, I'll introduce a recent major improvement in the scheduler: a new +[scheduling context element](/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points) +named _QueueingHint_. +We'll go through the explanation of the basic background knowledge of the scheduler, +and how QueueingHint improves our scheduling throughput. + +## Scheduling queue + +The scheduler stores all unscheduled Pods in an internal component that we - SIG Scheduling - +call the _scheduling queue_. + +The scheduling queue is composed of three data structures: _ActiveQ_, _BackoffQ_ and _Unschedulable Pod Pool_. +- ActiveQ: It holds newly created Pods or Pods which are ready to be retried for scheduling. +- BackoffQ: It holds Pods which are ready to be retried, but are waiting for a backoff period, which depends on the number of times the scheduled attempted to schedule the Pod. +- Unschedulable Pod Pool: It holds Pods which should not be scheduled for now, because they have a Scheduling Gate or because the scheduler attempted to schedule them and nothing has changed in the cluster that could make the Pod schedulable. + +## Scheduling framework and plugins + +The Kubernetes scheduler is implemented following the Kubernetes +[scheduling framework](/docs/concepts/scheduling-eviction/scheduling-framework/). + +And, each scheduling requirements are implemented as a plugin. +(e.g., [Pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) +is implemented in the `PodAffinity` plugin.) + +The first phase, called the _scheduling cycle_, takes Pods from activeQ **one by one**, runs all plugins' logic, +and lastly decides in which Node to run the Pod, or concludes that the Pod cannot go to anywhere for now. + +If the scheduling is successful, the second phase, called the _binding cycle_, binds the Pod with +the Node by communicating the decision to the API server. +But, if it turns out that the Pod cannot go to anywhere during the scheduling cycle, +the binding cycle isn't executed; instead the Pod is moved back to the scheduling queue. +Although there are some exceptions, unscheduled Pods enter the _unschedulable pod pool_. + +Pods in Unschedulable Pod Pool are moved to ActiveQ/BackoffQ +only when Scheduling Queue identifies changes in the cluster that might be schedulable if we retry the scheduling. + +That is a crucial step because scheduling cycle is performed for Pods one by one - +if we didn't have Unschedulable Pod Pool and kept retrying the scheduling of any Pods, +multiple scheduling cycles would be wasted for Pods that have no chance to be scheduled. + +Then, how do they decide when to move a Pod back into the ActiveQ? How do they notice that Pods might be schedulable now? +Here QueueingHints come into play. + +## QueueingHint + +QueueingHint is callback function per plugin to notice an object addition/update/deletion in the cluster (we call them cluster events) +that may make Pods schedulable. + +Let's say the Pod `pod-a` has a required Pod affinity, and got rejected in scheduling cycle by the `PodAffinity` plugin +because no Node has any Pod matching the Pod affinity specification for `pod-a`. + +![pod-a got rejected by PodAffinity](./queueinghint1.svg) + +When an unscheduled Pod is put into the unschedulable pod pool, the scheduling queue +records which plugins caused the scheduling failure of the Pod. +In this example, scheduling queue notes that `pod-a` was rejected by `PodAffinity`. + +`pod-a` will never be schedulable until the PodAffinity failure is resolved somehow. +The scheduling queue uses the queueing hints from plugins that rejected the Pod, which is `PodAffinity` in the example. + +A QueueingHint subscribes to a particular kind of cluster event and make a decision whether an incoming event could make the Pod schedulable. +Thinking about when PodAffinity failure could be resolved, +one possible scenario is that an existing Pod gets a new label which matches with `pod-a`'s PodAffinity. + +The `PodAffinity` plugin's `QueueingHint` callback checks on all Pod updates happening in the cluster, +and when it catches such update, the scheduling queue moves `pod-a` to either ActiveQ or BackoffQ. + +![pod-a is moved by PodAffinity QueueingHint](./queueinghint2.svg) + +We actually already had a similar functionality (called `preCheck`) inside the scheduling queue, +which filters out cluster events based on Kubernetes core scheduling constraints - +for example, filtering out node related events when nodes aren't ready. + +But, it's not ideal because this hard-coded `preCheck` refers to in-tree plugins logic, +and it causes issues for custom plugins (for example: [#110175](https://github.com/kubernetes/kubernetes/issues/110175)). + +## What's new in v1.29 + +Within SIG Scheduling, we have been working on the development of QueueingHint since +Kubernetes v1.28. +In v1.28, only one alpha plugin (DRA) supported QueueingHint, +and in v1.29, some stable plugins started to implement QueueingHints. + +QueueingHint is not something user-facing, but we have a feature gate (`SchedulerQueueingHints`) as a safety net +because QueueingHint changes a critical path of the scheduler and adds some memory overhead, depending on how busy a cluster is. + +## Getting involved + +These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling). + +Please join us and share your feedback. + +## How can I learn more? + +- [KEP-4247: Per-plugin callback functions for efficient requeueing in the scheduling queue](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/4247-queueinghint/README.md) \ No newline at end of file diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg new file mode 100644 index 0000000000..d2dd2a6cb9 --- /dev/null +++ b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg @@ -0,0 +1,4 @@ + + + +
unsched
unsched
FailedBy:
PodAffinity
FailedBy:...
Queueing Hint    
Queueing Hint    
EventHandler
EventHandl...
ActiveQ
ActiveQ
BackoffQ
BackoffQ
Cluster events
Cluster events
PreEnqueue   
PreEnqueue   
Scheduling Queue
Scheduling Queue
Cluster events
Cluster events
Cluster events
Cluster events
PodAffinity
"I'm in charge of requeueing pod-a"
PodAffinity...
Go to the scheduling cycle
Go to the...
Text is not SVG - cannot display
\ No newline at end of file diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg new file mode 100644 index 0000000000..9f7c65682f --- /dev/null +++ b/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg @@ -0,0 +1,4 @@ + + + +
unsched
unsched
FailedBy:
PodAffinity
FailedBy:...
Queueing Hint    
Queueing Hint    
EventHandler
EventHandl...
ActiveQ
ActiveQ
BackoffQ
BackoffQ
PodUpdated
PodUpdated
PreEnqueue   
PreEnqueue   
Scheduling Queue
Scheduling Queue
PodAffinity
"Oh, this event shows that an existing Pod gets a new label which matches with PodA's PodAffinity!"
PodAffinity...
Go to the scheduling cycle
Go to the...
Text is not SVG - cannot display
\ No newline at end of file From 5283c024e5f1e5a5f8b0fc77151019167ecc2483 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 11 Nov 2024 17:05:10 +0800 Subject: [PATCH 03/40] [zh] Add an API doc: resource-slice-v1alpha3.md --- .../resource-slice-v1alpha3.md | 996 ++++++++++++++++++ 1 file changed, 996 insertions(+) create mode 100644 content/zh-cn/docs/reference/kubernetes-api/workload-resources/resource-slice-v1alpha3.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/workload-resources/resource-slice-v1alpha3.md b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/resource-slice-v1alpha3.md new file mode 100644 index 0000000000..e95516bca2 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/resource-slice-v1alpha3.md @@ -0,0 +1,996 @@ +--- +api_metadata: + apiVersion: "resource.k8s.io/v1alpha3" + import: "k8s.io/api/resource/v1alpha3" + kind: "ResourceSlice" +content_type: "api_reference" +description: "ResourceSlice 表示一个或多个资源,这些资源位于同一个驱动所管理的、彼此相似的资源构成的资源池。" +title: "ResourceSlice v1alpha3" +weight: 18 +--- + + +`apiVersion: resource.k8s.io/v1alpha3` + +`import "k8s.io/api/resource/v1alpha3"` + + +## ResourceSlice {#ResourceSlice} + +ResourceSlice 表示一个或多个资源,这些资源位于同一个驱动所管理的、彼此相似的资源构成的资源池。 +一个池可以包含多个 ResourceSlice,一个池包含多少个 ResourceSlice 由驱动确定。 + +目前,所支持的资源只能是具有属性和容量的设备。 +给定池中的每个设备,无论有多少个 ResourceSlice,必须具有唯一名称。 +发布设备的 ResourceSlice 可能会随着时间的推移而变化。 +设备的唯一标识符是元组 \<驱动名称\>、\<池名称\>、\<设备名称\>。 + + +每当驱动需要更新池时,pool.spec.pool.generation 编号加一, +并用新的编号和新的资源定义来更新所有 ResourceSlice。 +资源用户必须仅使用 generation 编号最大的 ResourceSlice,并忽略所有其他 ResourceSlice。 + +从池中分配符合某些条件的所有资源或在多个不同分配方案间寻找最佳方案时, +资源用户应检查池中的 ResourceSlice 数量(包含在每个 ResourceSlice 中), +以确定其对池的视图是否完整,如果不完整,则应等到驱动完成对池的更新。 + + +对于非某节点本地的资源,节点名称不会被设置。 +驱动可以使用节点选择算符来给出设备的可用位置。 + +此特性为 Alpha 级别,需要启用 DynamicResourceAllocation 特性门控。 + +
+ +- **apiVersion**: resource.k8s.io/v1alpha3 + +- **kind**: ResourceSlice + + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据。 + +- **spec** (}}">ResourceSliceSpec),必需 + + 包含驱动所发布的信息。 + + 更改 spec 会自动让 metadata.generation 编号加一。 + +## ResourceSliceSpec {#ResourceSliceSpec} + + +ResourceSliceSpec 包含驱动在一个 ResourceSlice 中所发布的信息。 + +
+ + +- **driver** (string),必需 + + driver 标明提供容量信息的 DRA 驱动。可以使用字段选择算符仅列举具有特定驱动名称的 ResourceSlice 对象。 + + 字段值必须是 DNS 子域名并且应以驱动供应商所拥有的 DNS 域结尾。此字段是不可变更的。 + + +- **pool** (ResourcePool),必需 + + pool 描述 ResourceSlice 所属的池。 + + + **ResourcePool 描述 ResourceSlice 所属的池。** + + + + - **pool.generation** (int64),必需 + + generation 跟踪池中随时间发生的变化。每当驱动更改池中一个或多个资源的某些内容时, + 它必须为所有属于该池的 ResourceSlice 更改 generation。 + ResourceSlice 的使用者应仅考虑池中 generation 编号最大的资源。 + generation 可以被驱动重置,这对于使用者来说应该没问题, + 前提是池中的所有 ResourceSlice 都已被更新以匹配,或都已被删除。 + + 结合 resourceSliceCount,此机制让使用者能够检测资源池包含多个 + ResourceSlice 且处于不完整状态的情况。 + + + + - **pool.name** (string),必需 + + name 用作池的标识符。对于节点本地设备,字段值通常是节点名称,但这不是必须的。 + + 此字段不得超过 253 个字符,并且必须由一个或多个用斜杠分隔的 DNS 子域组成。此字段是不可变更的。 + + + + - **pool.resourceSliceCount** (int64),必需 + + resourceSliceCount 是池中带有对应 generation 编号的 ResourceSlice 的总数。必须大于零。 + + 资源用户可以使用此字段检查他们是否能看到属于同一池的所有 ResourceSlice。 + + +- **allNodes** (boolean) + + allNodes 表示所有节点都可以访问池中的资源。 + + nodeName、nodeSelector 和 allNodes 之一必须被设置。 + + +- **devices** ([]Device) + + **原子性:将在合并期间被替换** + + devices 列举池中的部分或全部设备。 + + 列表大小不得超过 128 个条目。 + + + **Device 表示可以基于其属性进行选择的一个单独硬件实例。name 之外,必须且只能设置一个字段。** + + + + - **devices.name** (string),必需 + + name 是池中由驱动所管理的设备的标识符,在所有设备中唯一。此字段值必须是 DNS 标签。 + + - **devices.basic** (BasicDevice) + + basic 定义一个设备实例。 + + + **BasicDevice 定义一个设备实例。** + + + + - **devices.basic.attributes** (map[string]DeviceAttribute) + + attributes 定义设备的属性集。在该集合中每个属性的名称必须唯一。 + + attributes 和 capacities 两个映射合起来,最多包含 32 个属性。 + + + **DeviceAttribute 必须设置一个字段。** + + + + - **devices.basic.attributes.bool** (boolean) + + bool 字段值是 true/false。 + + - **devices.basic.attributes.int** (int64) + + int 字段值是一个整数。 + + - **devices.basic.attributes.string** (string) + + string 字段值是一个字符串。不得超过 64 个字符。 + + - **devices.basic.attributes.version** (string) + + version 字段值是符合 semver.org 2.0.0 规范的语义版本。不得超过 64 个字符。 + + + + - **devices.basic.capacity** (map[string]}}">Quantity) + + capacity 定义设备的容量集。在该集合中每个容量的名称必须唯一。 + + attributes 和 capacities 两个映射合起来,最多包含 32 个属性。 + + +- **nodeName** (string) + + nodeName 标明提供池中资源的某个节点。可以使用字段选择算符仅列举属于特定节点的 ResourceSlice 对象。 + + 此字段可用于限制节点只能访问具有相同节点名称的 ResourceSlice。 + 此字段还向负责添加相同类型节点的自动扩缩容程序指明,某些旧节点也能够提供新资源供访问。 + + nodeName、nodeSelector 和 allNodes 三个字段必须设置其一。此字段是不可变更的。 + + +- **nodeSelector** (NodeSelector) + + nodeSelector 定义当池所涉及的节点不止一个时,在哪些节点上可以访问到资源。 + + 此字段中只能设置一个判定条件。 + + nodeName、nodeSelector 和 allNodes 三个字段必须设置其一。 + + + **NodeSelector 表示在一组节点上一个或多个标签查询结果的并集; + 也就是说,它表示由节点选择算符条件所表示的选择算符的逻辑或计算结果。** + + + + - **nodeSelector.nodeSelectorTerms** ([]NodeSelectorTerm),必需 + + **原子性:将在合并期间被替换** + + 必需。节点选择算符条件的列表。这些条件最终会被按照逻辑或操作组合起来。 + + + **未指定或空的节点选择算符条件不会匹配任何对象。各个条件最少是按逻辑与运算组合到一起的。 + TopologySelectorTerm 类型实现了 NodeSelectorTerm 的一个子集。** + + + + - **nodeSelector.nodeSelectorTerms.matchExpressions** ([]}}">NodeSelectorRequirement) + + **原子性:将在合并期间被替换** + + 基于节点标签的节点选择算符要求的列表。 + + - **nodeSelector.nodeSelectorTerms.matchFields** ([]}}">NodeSelectorRequirement) + + **原子性:将在合并期间被替换** + + 基于节点字段的节点选择算符要求的列表。 + +## ResourceSliceList {#ResourceSliceList} + + +ResourceSliceList 是 ResourceSlice 的集合。 + +
+ +- **apiVersion**: resource.k8s.io/v1alpha3 + +- **kind**: ResourceSliceList + + +- **items** ([]}}">ResourceSlice),必需 + + items 是 ResourceSlice 资源的列表。 + +- **metadata** (}}">ListMeta) + + 标准的列表元数据。 + + +## 操作 {#Operations} + +
+ +### `get` 读取指定的 ResourceSlice + +#### HTTP 请求 + +GET /apis/resource.k8s.io/v1alpha3/resourceslices/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + ResourceSlice 的名称。 + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ResourceSlice): OK + +401: Unauthorized + + +### `list` 列举或监视类别为 ResourceSlice 的对象 + +#### HTTP 请求 + +GET /apis/resource.k8s.io/v1alpha3/resourceslices + + +#### 参数 + +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + + }}">continue + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **sendInitialEvents** (**查询参数**): boolean + + }}">sendInitialEvents + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 + +200 (}}">ResourceSliceList): OK + +401: Unauthorized + + +### `create` 创建 ResourceSlice + +#### HTTP 请求 + +POST /apis/resource.k8s.io/v1alpha3/resourceslices + + +#### 参数 + +- **body**: }}">ResourceSlice,必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ResourceSlice): OK + +201 (}}">ResourceSlice): Created + +202 (}}">ResourceSlice): Accepted + +401: Unauthorized + + +### `update` 替换指定的 ResourceSlice + +#### HTTP 请求 + +PUT /apis/resource.k8s.io/v1alpha3/resourceslices/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + ResourceSlice 的名称。 + +- **body**: }}">ResourceSlice,必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ResourceSlice): OK + +201 (}}">ResourceSlice): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 ResourceSlice + +#### HTTP 请求 + +PATCH /apis/resource.k8s.io/v1alpha3/resourceslices/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + ResourceSlice 的名称。 + +- **body**: }}">Patch,必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ResourceSlice): OK + +201 (}}">ResourceSlice): Created + +401: Unauthorized + + +### `delete` 删除 ResourceSlice + +#### HTTP 请求 + +DELETE /apis/resource.k8s.io/v1alpha3/resourceslices/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + ResourceSlice 的名称。 + +- **body**: }}">DeleteOptions + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + + +#### 响应 + +200 (}}">ResourceSlice): OK + +202 (}}">ResourceSlice): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 ResourceSlice 的集合 + +#### HTTP 请求 + +DELETE /apis/resource.k8s.io/v1alpha3/resourceslices + + +#### 参数 + +- **body**: }}">DeleteOptions + +- **continue** (**查询参数**): string + + }}">continue + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **sendInitialEvents** (**查询参数**): boolean + + }}">sendInitialEvents + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + + +#### 响应 + +200 (}}">Status): OK + +401: Unauthorized From 950a9dfdb69828237e74ee82f73c0faa93794b0f Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Sun, 29 Sep 2024 22:18:50 +0100 Subject: [PATCH 04/40] Improve admission control reference - Change page title. The reference is about admission control (as a concept) as well as providing a list of all admission controllers. - Expand the intro section to provide more of an explanation of admission control. - Emphasize that ValidatingAdmissionPolicy, along with mutating and validating webhooks, are extension points. --- .../admission-controllers.md | 69 +++++++++++-------- 1 file changed, 39 insertions(+), 30 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 7e67e94cf0..de2c6f447a 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -6,41 +6,62 @@ reviewers: - erictune - janetkuo - thockin -title: Admission Controllers Reference -linkTitle: Admission Controllers +title: Admission Control in Kubernetes +linkTitle: Admission Control content_type: concept weight: 40 --- -This page provides an overview of Admission Controllers. +This page provides an overview of _admission controllers_. +An admission controller is a piece of code that intercepts requests to the +Kubernetes API server prior to persistence of the resource, but after the request +is authenticated and authorized. + +Several important features of Kubernetes require an admission controller to be enabled in order +to properly support the feature. As a result, a Kubernetes API server that is not properly +configured with the right set of admission controllers is an incomplete server that will not +support all the features you expect. ## What are they? -An _admission controller_ is a piece of code that intercepts requests to the -Kubernetes API server prior to persistence of the object, but after the request -is authenticated and authorized. +Admission controllers are code within the Kubernetes +{{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} that check the +data arriving in a request to modify a resource. -Admission controllers may be _validating_, _mutating_, or both. Mutating -controllers may modify objects related to the requests they admit; validating controllers may not. +Admission controllers apply to requests that create, delete, or modify objects. +Admission controllers can also block custom verbs, such as a request to connect to a +pod via an API server proxy. Admission controllers do _not_ (and cannot) block requests +to read (**get**, **watch** or **list**) objects, because reads bypass the admission +control layer. -Admission controllers limit requests to create, delete, modify objects. Admission -controllers can also block custom verbs, such as a request connect to a Pod via -an API server proxy. Admission controllers do _not_ (and cannot) block requests -to read (**get**, **watch** or **list**) objects. +Admission control mechanisms may be _validating_, _mutating_, or both. Mutating +controllers may modify the data for the resource being modified; validating controllers may not. The admission controllers in Kubernetes {{< skew currentVersion >}} consist of the [list](#what-does-each-admission-controller-do) below, are compiled into the `kube-apiserver` binary, and may only be configured by the cluster -administrator. In that list, there are two special controllers: -MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the -mutating and validating (respectively) -[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) -which are configured in the API. +administrator. -## Admission control phases +### Admission control extension points + +Within the full [list](#what-does-each-admission-controller-do), there are three +special controllers: +[MutatingAdmissionWebhook](#mutatingadmissionwebhook), +[ValidatingAdmissionWebhook](#validatingadmissionwebhook), and +[ValidatingAdmissionPolicy](#validatingadmissionpolicy). +The two webhook controllers execute the mutating and validating (respectively) +[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) +which are configured in the API. ValidatingAdmissionPolicy provides a way to embed +declarative validation code within the API, without relying on any external HTTP +callouts. + +You can use these three admission controllers to customize cluster behavior at +admission time. + +### Admission control phases The admission control process proceeds in two phases. In the first phase, mutating admission controllers are run. In the second phase, validating @@ -58,12 +79,7 @@ corresponding reclamation or reconciliation process, as a given admission controller does not know for sure that a given request will pass all of the other admission controllers. -## Why do I need them? -Several important features of Kubernetes require an admission controller to be enabled in order -to properly support the feature. As a result, a Kubernetes API server that is not properly -configured with the right set of admission controllers is an incomplete server and will not -support all the features you expect. ## How do I turn on an admission controller? @@ -105,13 +121,6 @@ In Kubernetes {{< skew currentVersion >}}, the default ones are: CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook ``` -{{< note >}} -The [`ValidatingAdmissionPolicy`](#validatingadmissionpolicy) admission plugin is enabled -by default, but is only active if you enable the `ValidatingAdmissionPolicy` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) **and** -the `admissionregistration.k8s.io/v1alpha1` API. -{{< /note >}} - ## What does each admission controller do? ### AlwaysAdmit {#alwaysadmit} From 7189bfe794ecd1f13d251da020caa1b8cf9a0148 Mon Sep 17 00:00:00 2001 From: Kensei Nakada Date: Sun, 24 Nov 2024 23:33:47 +0900 Subject: [PATCH 05/40] fix: update the content for v1.32 --- .../index.md | 27 +++++++++++++------ .../queueinghint1.svg | 0 .../queueinghint2.svg | 0 3 files changed, 19 insertions(+), 8 deletions(-) rename content/en/blog/_posts/{2024-xx-xx-scheduler-queueinghint => 2024-12-12-scheduler-queueinghint}/index.md (86%) rename content/en/blog/_posts/{2024-xx-xx-scheduler-queueinghint => 2024-12-12-scheduler-queueinghint}/queueinghint1.svg (100%) rename content/en/blog/_posts/{2024-xx-xx-scheduler-queueinghint => 2024-12-12-scheduler-queueinghint}/queueinghint2.svg (100%) diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md b/content/en/blog/_posts/2024-12-12-scheduler-queueinghint/index.md similarity index 86% rename from content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md rename to content/en/blog/_posts/2024-12-12-scheduler-queueinghint/index.md index b1ad7ab2b6..3fe63b38e9 100644 --- a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/index.md +++ b/content/en/blog/_posts/2024-12-12-scheduler-queueinghint/index.md @@ -1,12 +1,13 @@ --- layout: blog title: "Kubernetes v1.32: QueueingHint Brings a New Possibility to Optimize Pod Scheduling" -date: 2024-xx-xxT00:00:00-08:00 +date: 2024-12-12 slug: scheduler-queueinghint +draft: true +Author: > + [Kensei Nakada](https://github.com/sanposhiho) (Tetrate.io) --- -**Author:** [Kensei Nakada](https://github.com/sanposhiho) (Tetrate.io) - The Kubernetes [scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) is the core component that decides which node any new Pods should run on. Basically, it schedules Pods **one by one**, @@ -92,15 +93,25 @@ for example, filtering out node related events when nodes aren't ready. But, it's not ideal because this hard-coded `preCheck` refers to in-tree plugins logic, and it causes issues for custom plugins (for example: [#110175](https://github.com/kubernetes/kubernetes/issues/110175)). -## What's new in v1.29 +## QueueingHint's history and what's new in v1.32 Within SIG Scheduling, we have been working on the development of QueueingHint since Kubernetes v1.28. -In v1.28, only one alpha plugin (DRA) supported QueueingHint, -and in v1.29, some stable plugins started to implement QueueingHints. -QueueingHint is not something user-facing, but we have a feature gate (`SchedulerQueueingHints`) as a safety net -because QueueingHint changes a critical path of the scheduler and adds some memory overhead, depending on how busy a cluster is. +QueueingHint is not something user-facing, but we implemented a feature gate (`SchedulerQueueingHints`) as a safety net, +...which actually saved our life soon. + +In v1.28, we implemented QueueingHints with a few in-tree plugins experimentally, +and made the feature gate enabled by default. + +But, users reported the memory leak issue, and consequently we disabled the feature gate in the patch release of v1.28. + +In v1.28 - v1.31, we kept working on the QueueingHint implementation within the rest of in-tree plugins, +and having bug fixes. + +And, at v1.32, we will make this feature enabled by default again; +we finished implementing QueueingHints with all plugins, +and also identified the cause of the memory leak, finally! ## Getting involved diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg b/content/en/blog/_posts/2024-12-12-scheduler-queueinghint/queueinghint1.svg similarity index 100% rename from content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint1.svg rename to content/en/blog/_posts/2024-12-12-scheduler-queueinghint/queueinghint1.svg diff --git a/content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg b/content/en/blog/_posts/2024-12-12-scheduler-queueinghint/queueinghint2.svg similarity index 100% rename from content/en/blog/_posts/2024-xx-xx-scheduler-queueinghint/queueinghint2.svg rename to content/en/blog/_posts/2024-12-12-scheduler-queueinghint/queueinghint2.svg From b714ba0d97949044a17fb4d8a4677f4e96f0c56b Mon Sep 17 00:00:00 2001 From: Yoshiya Maki Date: Fri, 29 Nov 2024 02:51:27 +0900 Subject: [PATCH 06/40] [ja] Translate docs/reference/glossary/jwt.md --- content/ja/docs/reference/glossary/jwt.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/ja/docs/reference/glossary/jwt.md diff --git a/content/ja/docs/reference/glossary/jwt.md b/content/ja/docs/reference/glossary/jwt.md new file mode 100644 index 0000000000..825ee65e58 --- /dev/null +++ b/content/ja/docs/reference/glossary/jwt.md @@ -0,0 +1,18 @@ +--- +title: JSON Web Token (JWT) +id: jwt +date: 2023-01-17 +full_link: https://www.rfc-editor.org/rfc/rfc7519 +short_description: > + 2つの通信主体間で送受信されるクレームを表現する手段。 + +aka: +tags: +- security +- architecture +--- + 2つの通信主体間で送受信されるクレームを表現する手段。 + + + +JWTはデジタル署名と暗号化をすることが可能です。Kubernetesはクラスター内で何らかの操作を実行したいエンティティの身元を確認するため、認証トークンとしてJWTを使用します。 From c4b11bbea91bf6b52979d3b0baa5ca4dac9ab3a5 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 28 Nov 2024 15:58:11 -0500 Subject: [PATCH 07/40] [pt-br] Sync pt-br l18n strings with the English version. * Sync the l18n strings in the Brazilian Portuguese localization with the current English version. * Add small updates to `content/pt-br/community/_index.html` and `content/pt-br/docs/_index.md`. * Fix case studies title (was "Casos de Estudo", but correct translation in Portuguese is "Estudos de Caso"). --- content/pt-br/case-studies/_index.md | 6 +- content/pt-br/community/_index.html | 7 +- content/pt-br/docs/_index.md | 11 +- data/i18n/pt-br/pt-br.toml | 221 ++++++++++++++++++++++++--- 4 files changed, 208 insertions(+), 37 deletions(-) diff --git a/content/pt-br/case-studies/_index.md b/content/pt-br/case-studies/_index.md index 386dea7e0e..ee9a300844 100644 --- a/content/pt-br/case-studies/_index.md +++ b/content/pt-br/case-studies/_index.md @@ -1,7 +1,7 @@ --- -title: Casos de estudo -linkTitle: Casos de estudo -bigheader: Casos de estudo utilizando Kubernetes +title: Estudos de caso +linkTitle: Estudos de caso +bigheader: Estudos de caso utilizando Kubernetes abstract: Alguns usuários que estão executando o Kubernetes em produção. layout: basic class: gridPage diff --git a/content/pt-br/community/_index.html b/content/pt-br/community/_index.html index 11cf8b1160..f990a69ca8 100644 --- a/content/pt-br/community/_index.html +++ b/content/pt-br/community/_index.html @@ -1,6 +1,7 @@ --- title: Comunidade layout: basic +body_class: community cid: community community_styles_migrated: true menu: @@ -15,8 +16,8 @@ menu: alt="foto de uma conferência do Kubernetes">
-

A comunidade do Kubernetes - usuários, contribuidores, e a cultura que nós - construímos juntos - é uma das maiores razões para a ascensão meteórica deste +

A comunidade do Kubernetes — usuários, contribuidores, e a cultura que nós + construímos juntos — é uma das maiores razões para a ascensão meteórica deste projeto de código aberto. Nossa cultura e valores continuam crescendo e mudando conforme o projeto cresce e muda. Todos nós trabalhamos juntos em direção a constantes melhorias do projeto e da forma com que trabalhamos nele.

@@ -31,7 +32,7 @@ menu: