Question: The Dashboard UI is not deployed by default. To deploy it, run the following command: ``` <del> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml </del> <ins> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml </ins> ``` ## Accessing the Dashboard UI

Please update page, it should be instead of
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: <ins> --- layout: blog title: "Kubernetes 1.24：gRPC 容器探针功能进入 Beta 阶段" date: 2022-05-13 slug: grpc-probes-now-in-beta --- <!-- layout: blog title: "Kubernetes 1.24: gRPC container probes in beta" date: 2022-05-13 slug: grpc-probes-now-in-beta --> <!-- **Author**: Sergey Kanzhelev (Google) --> **作者**：Sergey Kanzhelev (Google) <!-- With Kubernetes 1.24 the gRPC probes functionality entered beta and is available by default. Now you can configure startup, liveness, and readiness probes for your gRPC app without exposing any HTTP endpoint, nor do you need an executable. Kubernetes can natively connect to your your workload via gRPC and query its status. --> 在 Kubernetes 1.24 中，gRPC 探针（probe）功能进入了 beta 阶段，默认情况下可用。 现在，你可以为 gRPC 应用程序配置启动、活跃和就绪探测，而无需公开任何 HTTP 端点， 也不需要可执行文件。Kubernetes 可以通过 gRPC 直接连接到你的工作负载并查询其状态。 <!-- ## Some history It's useful to let the system managing your workload check that the app is healthy, has started OK, and whether the app considers itself good to accept traffic. Before the gRPC support was added, Kubernetes already allowed you to check for health based on running an executable from inside the container image, by making an HTTP request, or by checking whether a TCP connection succeeded. --> ## 一些历史 让管理你的工作负载的系统检查应用程序是否健康、启动是否正常，以及应用程序是否认为自己可以接收流量，是很有用的。 在添加 gRPC 探针支持之前，Kubernetes 已经允许你通过从容器镜像内部运行可执行文件、发出 HTTP 请求或检查 TCP 连接是否成功来检查健康状况。 <!-- For most apps, those checks are enough. If your app provides a gRPC endpoint for a health (or readiness) check, it is easy to repurpose the `exec` probe to use it for gRPC health checking. In the blog article [Health checking gRPC servers on Kubernetes](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/), Ahmet Alp Balkan described how you can do that — a mechanism that still works today. --> 对于大多数应用程序来说，这些检查就足够了。如果你的应用程序提供了用于运行状况（或准备就绪）检查的 gRPC 端点，则很容易重新调整 `exec` 探针的用途，将其用于 gRPC 运行状况检查。 在博文[在 Kubernetes 上对 gRPC 服务器进行健康检查](/zh-cn/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)中， Ahmet Alp Balkan 描述了如何做到这一点 —— 这种机制至今仍在工作。 <!-- There is a commonly used tool to enable this that was [created](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d) on August 21, 2018, and with the first release at [Sep 19, 2018](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1). --> 2018 年 8 月 21 日所[创建](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)的一种常用工具可以启用此功能， 工具于 [2018 年 9 月 19 日](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1)首次发布。 <!-- This approach for gRPC apps health checking is very popular. There are [3,626 Dockerfiles](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code) with the `grpc_health_probe` and [6,621 yaml](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code) files that are discovered with the basic search on GitHub (at the moment of writing). This is good indication of the tool popularity and the need to support this natively. --> 这种 gRPC 应用健康检查的方法非常受欢迎。使用 GitHub 上的基本搜索，发现了带有 `grpc_health_probe` 的 [3,626 个 Dockerfile 文件](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)和 [6,621 个 yaml 文件](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code)（在撰写本文时）。 这很好地表明了该工具的受欢迎程度，以及对其本地支持的需求。 <!-- Kubernetes v1.23 introduced an alpha-quality implementation of native support for querying a workload status using gRPC. Because it was an alpha feature, this was disabled by default for the v1.23 release. --> Kubernetes v1.23 引入了一个 alpha 质量的实现，原生支持使用 gRPC 查询工作负载状态。 因为这是一个 alpha 特性，所以在 1.23 版中默认是禁用的。 <!-- ## Using the feature We built gRPC health checking in similar way with other probes and believe it will be [easy to use](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) if you are familiar with other probe types in Kubernetes. The natively supported health probe has many benefits over the workaround involving `grpc_health_probe` executable. --> ## 使用该功能 我们用与其他探针类似的方式构建了 gRPC 健康检查，相信如果你熟悉 Kubernetes 中的其他探针类型， 它会[很容易使用](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 与涉及 `grpc_health_probe` 可执行文件的解决办法相比，原生支持的健康探针有许多好处。 <!-- With the native gRPC support you don't need to download and carry `10MB` of an additional executable with your image. Exec probes are generally slower than a gRPC call as they require instantiating a new process to run an executable. It also makes the checks less sensible for edge cases when the pod is running at maximum resources and has troubles instantiating new processes. --> 有了原生 gRPC 支持，你不需要在镜像中下载和携带 `10MB` 的额外可执行文件。 Exec 探针通常比 gRPC 调用慢，因为它们需要实例化一个新进程来运行可执行文件。 当 Pod 在最大资源下运行并且在实例化新进程时遇到困难时，它还使得对边界情况的检查变得不那么智能。 <!-- There are a few limitations though. Since configuring a client certificate for probes is hard, services that require client authentication are not supported. The built-in probes are also not checking the server certificates and ignore related problems. --> 不过有一些限制。由于为探针配置客户端证书很难，因此不支持依赖客户端身份验证的服务。 内置探针也不检查服务器证书，并忽略相关问题。 <!-- Built-in checks also cannot be configured to ignore certain types of errors (`grpc_health_probe` returns different exit codes for different errors), and cannot be "chained" to run the health check on multiple services in a single probe. --> 内置检查也不能配置为忽略某些类型的错误（`grpc_health_probe` 针对不同的错误返回不同的退出代码）， 并且不能“串接”以在单个探测中对多个服务运行健康检查。 <!-- But all these limitations are quite standard for gRPC and there are easy workarounds for those. --> 但是所有这些限制对于 gRPC 来说都是相当标准的，并且有简单的解决方法。 <!-- ## Try it for yourself ### Cluster-level setup You can try this feature today. To try native gRPC probes, you can spin up a Kubernetes cluster yourself with the `GRPCContainerProbe` feature gate enabled, there are many [tools available](/docs/tasks/tools/). --> ## 自己试试 ### 集群级设置 你现在可以尝试这个功能。要尝试原生 gRPC 探针，你可以自己启动一个启用了 `GRPCContainerProbe` 特性门控的 Kubernetes 集群，可用的[工具](/zh-cn/docs/tasks/tools/)有很多。 <!-- Since the feature gate `GRPCContainerProbe` is enabled by default in 1.24, many vendors will have this functionality working out of the box. So you may just create an 1.24 cluster on platform of your choice. Some vendors allow to enable alpha features on 1.23 clusters. --> 由于特性门控 `GRPCContainerProbe` 在 1.24 版本中是默认启用的，因此许多供应商支持此功能开箱即用。 因此，你可以在自己选择的平台上创建 1.24 版本集群。一些供应商允许在 1.23 版本集群上启用 alpha 特性。 <!-- For example, at the moment of writing, you can spin up the test cluster on GKE for a quick test. Other vendors may also have similar capabilities, especially if you are reading this blog post long after the Kubernetes 1.24 release. --> 例如，在编写本文时，你可以在 GKE 上运行测试集群来进行快速测试。 其他供应商可能也有类似的功能，尤其是当你在 Kubernetes 1.24 版本发布很久后才阅读这篇博客时。 <!-- On GKE use the following command (note, version is `1.23` and `enable-kubernetes-alpha` are specified). --> 在 GKE 上使用以下命令（注意，版本是 `1.23`，并且指定了 `enable-kubernetes-alpha`）。 ```shell gcloud container clusters create test-grpc  --enable-kubernetes-alpha  --no-enable-autorepair  --no-enable-autoupgrade  --release-channel=rapid  --cluster-version=1.23 ``` <!-- You will also need to configure `kubectl` to access the cluster: --> 你还需要配置 kubectl 来访问集群： ```shell gcloud container clusters get-credentials test-grpc ``` <!-- ### Trying the feature out Let's create the pod to test how gRPC probes work. For this test we will use the `agnhost` image. This is a k8s maintained image with that can be used for all sorts of workload testing. For example, it has a useful [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) module that exposes two ports - one is serving health checking service, another - http port to react on commands `make-serving` and `make-not-serving`. --> ### 试用该功能 让我们创建 Pod 来测试 gRPC 探针是如何工作的。对于这个测试，我们将使用 `agnhost` 镜像。 这是一个 k8s 维护的镜像，可用于各种工作负载测试。例如，它有一个有用的 [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) 模块，该模块暴露了两个端口：一个是提供健康检查服务的端口，另一个是对 `make-serving` 和 `make-not-serving` 命令做出反应的 http 端口。 <!-- Here is an example pod definition. It starts the `grpc-health-checking` module, exposes ports `5000` and `8080`, and configures gRPC readiness probe: --> 下面是一个 Pod 定义示例。它启用 `grpc-health-checking` 模块，暴露 5000 和 8080 端口，并配置 gRPC 就绪探针： ``` yaml --- apiVersion: v1 kind: Pod metadata: name: test-grpc spec: containers: - name: agnhost image: k8s.gcr.io/e2e-test-images/agnhost:2.35 command: ["/agnhost", "grpc-health-checking"] ports: - containerPort: 5000 - containerPort: 8080 readinessProbe: grpc: port: 5000 ``` <!-- If the file called `test.yaml`, you can create the pod and check it's status. The pod will be in ready state as indicated by the snippet of the output. --> 如果文件名为 `test.yaml`，你可以用以下命令创建 Pod，并检查它的状态。如输出片段所示，Pod 将处于就绪状态。 ```shell kubectl apply -f test.yaml kubectl describe test-grpc ``` <!-- The output will contain something like this: --> 输出将包含如下内容： ``` Conditions: Type              Status Initialized       True Ready             True ContainersReady   True PodScheduled      True ``` <!-- Now let's change the health checking endpoint status to NOT_SERVING. In order to call the http port of the Pod, let's create a port forward: --> 现在让我们将健康检查端点状态更改为 `NOT_SERVING`。为了调用 Pod 的 http 端口，让我们创建一个端口转发： ```shell kubectl port-forward test-grpc 8080:8080 ``` <!-- You can `curl` to call the command... --> 你可以用 `curl` 来调用这个命令。 ```shell curl http://localhost:8080/make-not-serving ``` <!-- ... and in a few seconds the port status will switch to not ready. --> 几秒钟后，端口状态将切换到未就绪。 ```shell kubectl describe pod test-grpc ``` <!-- The output now will have: --> 现在的输出将显示： ``` Conditions: Type              Status Initialized       True Ready             False ContainersReady   False PodScheduled      True ... Warning  Unhealthy  2s (x6 over 42s)  kubelet            Readiness probe failed: service unhealthy (responded with "NOT_SERVING") ``` <!-- Once it is switched back, in about one second the Pod will get back to ready status: --> 一旦切换回来，Pod 将在大约一秒钟后恢复到就绪状态： ``` bsh curl http://localhost:8080/make-serving kubectl describe test-grpc ``` <!-- The output indicates that the Pod went back to being `Ready`: --> 输出表明 Pod 恢复为 `Ready`： ``` Conditions: Type              Status Initialized       True Ready             True ContainersReady   True PodScheduled      True ``` <!-- This new built-in gRPC health probing on Kubernetes makes implementing a health-check via gRPC much easier than the older approach that relied on using a separate `exec` probe. Read through the official [documentation](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) to learn more and provide feedback before the feature will be promoted to GA. --> Kubernetes 上这种新的内置 gRPC 健康探测，使得通过 gRPC 实现健康检查比依赖使用额外的 `exec` 探测的旧方法更容易。请阅读官方 [文档](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) 了解更多信息并在该功能正式发布（GA）之前提供反馈。 <!-- ## Summary Kubernetes is a popular workload orchestration platform and we add features based on feedback and demand. Features like gRPC probes support is a minor improvement that will make life of many app developers easier and apps more resilient. Try it today and give feedback, before the feature went into GA. --> ## 总结 Kubernetes 是一个流行的工作负载编排平台，我们根据反馈和需求添加功能。 像 gRPC 探针支持这样的特性是一个小的改进，它将使许多应用程序开发人员的生活更容易，应用程序更有弹性。 在该功能 GA（正式发布）之前，现在就试试，并给出反馈。 </ins>

This is a Feature Request This page blog/2022/05/13/grpc-probes-in- has no Chinese version What would you like to be Translate Chinese version for blog/2022/05/13/grpc-probes-in- Comments /language zh /assign
/triage accepted


Question: <ins> --- title: Pod QoS 类 content_type: concept weight: 85 --- <!-- title: Pod Quality of Service Classes content_type: concept weight: 85 --> <!-- overview --> <!-- This page introduces _Quality of Service (QoS) classes_ in Kubernetes, and explains how Kubernetes assigns a QoS class to each Pods as a consequence of the resource constraints that you specify for the containers in that Pod. Kubernetes relies on this classification to make decisions about which Pods to evict when there are not enough available resources on a Node. --> 本页介绍 Kubernetes 中的 **服务质量（Quality of Service，QoS）** 类， 阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。 Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。 <!-- body --> <!-- ## Quality of Service classes --> ## QoS 类   {#qos-class} <!-- Kubernetes classifies the Pods that you run and allocates each Pod into a specific _quality of service (QoS) class_. Kubernetes uses that classification to influence how different pods are handled. Kubernetes does this classification based on the [resource requests](/docs/concepts/configuration/manage-resources-containers/) of the {{< glossary_tooltip text="Containers" term_id="container" >}} in that Pod, along with how those requests relate to resource limits. This is known as {{< glossary_tooltip text="Quality of Service" term_id="qos-class" >}} (QoS) class. Kubernetes assigns every Pod a QoS class based on the resource requests and limits of its component Containers. QoS classes are used by Kubernetes to decide which Pods to evict from a Node experiencing [Node Pressure](/docs/concepts/scheduling-eviction/node-pressure-eviction/). The possible QoS classes are `Guaranteed`, `Burstable`, and `BestEffort`. When a Node runs out of resources, Kubernetes will first evict `BestEffort` Pods running on that Node, followed by `Burstable` and finally `Guaranteed` Pods. When this eviction is due to resource pressure, only Pods exceeding resource requests are candidates for eviction. --> Kubernetes 对你运行的 Pod 进行分类，并将每个 Pod 分配到特定的 **QoS 类**中。 Kubernetes 使用这种分类来影响不同 Pod 被处理的方式。Kubernetes 基于 Pod 中{{< glossary_tooltip text="容器" term_id="container" >}}的[资源请求](/zh-cn/docs/concepts/configuration/manage-resources-containers/)进行分类， 同时确定这些请求如何与资源限制相关。 这称为{{< glossary_tooltip text="服务质量" term_id="qos-class" >}} (QoS) 类。 Kubernetes 基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类。Kubernetes 使用 QoS 类来决定从遇到[节点压力](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)的 Node 中驱逐哪些 Pod。可选的 QoS 类有 `Guaranteed`、`Burstable` 和 `BestEffort`。 当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 `BestEffort` Pod， 然后是 `Burstable` Pod，最后是 `Guaranteed` Pod。当这种驱逐是由于资源压力时， 只有超出资源请求的 Pod 才是被驱逐的候选对象。 ### Guaranteed <!-- Pods that are `Guaranteed` have the strictest resource limits and are least likely to face eviction. They are guaranteed not to be killed until they exceed their limits or there are no lower-priority Pods that can be preempted from the Node. They may not acquire resources beyond their specified limits. These Pods can also make use of exclusive CPUs using the [`static`](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy) CPU management policy. --> `Guaranteed` Pod 具有最严格的资源限制，并且最不可能面临驱逐。 在这些 Pod 超过其自身的限制或者从 Node 上没有可以抢占的低优先级 Pod 之前， 这些 Pod 保证不会被杀死。这些 Pod 不可以获得超出其指定 limit 的资源。这些 Pod 也可以使用 [`static`](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/#static-policy) CPU 管理策略来使用独占的 CPU。 <!-- #### Criteria For a Pod to be given a QoS class of `Guaranteed`: --> #### 判据 Pod 被赋予 `Guaranteed` QoS 类的几个判据： <!-- * Every Container in the Pod must have a memory limit and a memory request. * For every Container in the Pod, the memory limit must equal the memory request. * Every Container in the Pod must have a CPU limit and a CPU request. * For every Container in the Pod, the CPU limit must equal the CPU request. --> * Pod 中的每个容器必须有内存 limit 和内存 request。 * 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。 * Pod 中的每个容器必须有 CPU limit 和 CPU request。 * 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。 ### Burstable <!-- Pods that are `Burstable` have some lower-bound resource guarantees based on the request, but do not require a specific limit. If a limit is not specified, it defaults to a limit equivalent to the capacity of the Node, which allows the Pods to flexibly increase their resources if resources are available. In the event of Pod eviction due to Node resource pressure, these Pods are evicted only after all `BestEffort` Pods are evicted. Because a `Burstable` Pod can include a Container that has no resource limits or requests, a Pod that is `Burstable` can try to use any amount of node resources. --> `Burstable` Pod 有一些基于 request 的资源下限保证，但不需要特定的 limit。 如果未指定 limit，则默认为其 limit 等于 Node 容量，这允许 Pod 在资源可用时灵活地增加其资源。 在由于 Node 资源压力导致 Pod 被驱逐的情况下，只有在所有 `BestEffort` Pod 被驱逐后 这些 Pod 才会被驱逐。因为 `Burstable` Pod 可以包括没有资源 limit 或资源 request 的容器， 所以 `Burstable` Pod 可以尝试使用任意数量的节点资源。 <!-- #### Criteria A Pod is given a QoS class of `Burstable` if: * The Pod does not meet the criteria for QoS class `Guaranteed`. * At least one Container in the Pod has a memory or CPU request or limit. --> #### 判据 Pod 被赋予 `Burstable` QoS 类的几个判据： * Pod 不满足针对 QoS 类 `Guaranteed` 的判据。 * Pod 中至少一个容器有内存或 CPU request 或 limit。 ### BestEffort <!-- Pods in the `BestEffort` QoS class can use node resources that aren't specifically assigned to Pods in other QoS classes. For example, if you have a node with 16 CPU cores available to the kubelet, and you assign 4 CPU cores to a `Guaranteed` Pod, then a Pod in the `BestEffort` QoS class can try to use any amount of the remaining 12 CPU cores. The kubelet prefers to evict `BestEffort` Pods if the node comes under resource pressure. --> `BestEffort` QoS 类中的 Pod 可以使用未专门分配给其他 QoS 类中的 Pod 的节点资源。 例如若你有一个节点有 16 核 CPU 可供 kubelet 使用，并且你将 4 核 CPU 分配给一个 `Guaranteed` Pod， 那么 `BestEffort` QoS 类中的 Pod 可以尝试任意使用剩余的 12 核 CPU。 如果节点遇到资源压力，kubelet 将优先驱逐 `BestEffort` Pod。 <!-- #### Criteria A Pod has a QoS class of `BestEffort` if it doesn't meet the criteria for either `Guaranteed` or `Burstable`. In other words, a Pod is `BestEffort` only if none of the Containers in the Pod have a memory limit or a memory request, and none of the Containers in the Pod have a CPU limit or a CPU request. Containers in a Pod can request other resources (not CPU or memory) and still be classified as `BestEffort`. --> #### 判据 如果 Pod 不满足 `Guaranteed` 或 `Burstable` 的判据，则它的 QoS 类为 `BestEffort`。 换言之，只有当 Pod 中的所有容器没有内存 limit 或内存 request，也没有 CPU limit 或 CPU request 时，Pod 才是 `BestEffort`。Pod 中的容器可以请求（除 CPU 或内存之外的） 其他资源并且仍然被归类为 `BestEffort`。 <!-- ## Some behavior is independent of QoS class {#class-independent-behavior} Certain behavior is independent of the QoS class assigned by Kubernetes. For example: --> ## 某些行为独立于 QoS 类 {#class-independent-behavior} 某些行为独立于 Kubernetes 分配的 QoS 类。例如： <!-- * Any Container exceeding a resource limit will be killed and restarted by the kubelet without affecting other Containers in that Pod. * If a Container exceeds its resource request and the node it runs on faces resource pressure, the Pod it is in becomes a candidate for [eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). If this occurs, all Containers in the Pod will be terminated. Kubernetes may create a replacement Pod, usually on a different node. --> * 所有超过资源 limit 的容器都将被 kubelet 杀死并重启，而不会影响该 Pod 中的其他容器。 * 如果一个容器超出了自身的资源 request，且该容器运行的节点面临资源压力，则该容器所在的 Pod 就会成为被[驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)的候选对象。 如果出现这种情况，Pod 中的所有容器都将被终止。Kubernetes 通常会在不同的节点上创建一个替代的 Pod。 <!-- * The resource request of a Pod is equal to the sum of the resource requests of its component Containers, and the resource limit of a Pod is equal to the sum of the resource limits of its component Containers. * The kube-scheduler does not consider QoS class when selecting which Pods to [preempt](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption). Preemption can occur when a cluster does not have enough resources to run all the Pods you defined. --> * Pod 的资源 request 等于其成员容器的资源 request 之和，Pod 的资源 limit 等于其组成容器的资源 limit 之和。 * kube-scheduler 在选择要[抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption)的 Pod 时不考虑 QoS 类。当集群没有足够的资源来运行你所定义的所有 Pod 时，就会发生抢占。 ## {{% heading "whatsnext" %}} <!-- * Learn about [resource management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers/). * Learn about [Node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). * Learn about [Pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/). * Learn about [Pod disruptions](/docs/concepts/workload/pods/disruptions/). * Learn how to [assign memory resources to containers and pods](/docs/tasks/configure-pod-container/assign-memory-resource/). * Learn how to [assign CPU resources to containers and pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). * Learn how to [configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/). --> * 进一步了解[为 Pod 和容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 * 进一步了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 * 进一步了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 * 进一步了解 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)。 * 进一步了解如何[为容器和 Pod 分配内存资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)。 * 进一步了解如何[为容器和 Pod 分配 CPU 资源](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/)。 * 进一步了解如何[配置 Pod 的服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)。 </ins>

This page has no zh-cn version now. I will localize it. To avoid any possible conflicts, this issue is opened. /assign /language zh
/triage accepted


Question: <ins> --- title: 新しいコンテンツの貢献 weight: 20 --- </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <del> --- title: Contributing new content overview linktitle: Overview content_type: concept main_menu: true weight: 5 --- <!-- overview --> This section contains information you should know before contributing new content. <!-- body --> ## Contributing basics - Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). - The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. - In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. - Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. - For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). ## Before you begin {#before-you-begin} ### Sign the CNCF CLA {#sign-the-cla} All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA. ### Choose which Git branch to use When opening a pull request, you need to know in advance which branch to base your work on. Scenario | Branch :---------|:------------ Existing or new English language content for the current release | `main` Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch. Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information. If you're still not sure which branch to choose, ask in `#sig-docs` on Slack. {{< note >}} If you already submitted your pull request and you know that the base branch was wrong, you (and only you, the submitter) can change it. {{< /note >}} ### Languages per PR Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. ## Tools for contributors The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly. </del>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Copy the page contents from into Redirect to (edit ) Delete Why is this needed The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. Comments /language en /good-first-issue /sig contributor-experience
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --- Copy the page contents from into Redirect to The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. /language en /good-first-issue /sig contributor-experience Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Please try some other alternatives. Let's be cautious when moving pages. Every relocation has to be replicated into all localizations. It may look straightforward for English to add a redirect entry. The fact is we may need to a dozen of redirect entries for all localizations. I don't see a compelling reason to move pages like this.
Perhaps it'd help to have some tooling to make it easy to copy redirects to a localization? Would that toil reduction change your mind
hello i want to work on this issue.
/assign
Hi , Happy to take care of this, but to be safe... Was there a consensus on how to handle the redirects for this issue? Thank you.
/triage accepted what would you like to know about redirects?
/assign
/assign
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
is this issue still open? if yes, can I contribute to this?


Question: labels: app: cassandra spec: <del> terminationGracePeriodSeconds: 1800 </del> <ins> terminationGracePeriodSeconds: 500 </ins> containers: - name: cassandra image: gcr.io/google-samples/cassandra:v13

When running this command: The grace period it was going to sleep was 1800s (30m), so after all resources were deleted (about 5-6s), I hit Ctrl-C, then manually ran the line after the sleep: kubectl delete persistentvolumeclaim -l app=cassandra Recommend adding a note to avoid having the student wait 30m for a command to finish that might only take a few seconds.
Related page: /language en
I think we can improve the advice, or change the grace period to be quite a bit shorter. Not sure which is better.
/triage accepted either way
/retitle [Unclear] example: Deploying Cassandra with a StatefulSet
I have tried to reproduce the issue with a grace period of 300 seconds. And I observed that all my related resources were deleted in under 10 seconds. It will be better if we reduce the to some shorter value like or .
I would like to work on this issue. /assign /sig apps /sig storage
/assign


Question: labels: app: cassandra spec: <del> terminationGracePeriodSeconds: 1800 </del> <ins> terminationGracePeriodSeconds: 500 </ins> containers: - name: cassandra image: gcr.io/google-samples/cassandra:v13

When running this command: The grace period it was going to sleep was 1800s (30m), so after all resources were deleted (about 5-6s), I hit Ctrl-C, then manually ran the line after the sleep: kubectl delete persistentvolumeclaim -l app=cassandra Recommend adding a note to avoid having the student wait 30m for a command to finish that might only take a few seconds.
Related page: /language en
I think we can improve the advice, or change the grace period to be quite a bit shorter. Not sure which is better.
/triage accepted either way
/retitle [Unclear] example: Deploying Cassandra with a StatefulSet
I have tried to reproduce the issue with a grace period of 300 seconds. And I observed that all my related resources were deleted in under 10 seconds. It will be better if we reduce the to some shorter value like or .
I would like to work on this issue. /assign /sig apps /sig storage
/assign


Question: ## kind [`kind`](https://kind.sigs.k8s.io/) lets you run Kubernetes on <del> your local computer. This tool requires that you have [Docker](https://docs.docker.com/get-docker/) installed and configured. </del> <ins> your local computer. This tool requires that you have either [Docker](https://www.docker.com/) or [Podman](https://podman.io/) installed. </ins> The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page shows you what you need to do to get up and running with kind.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: states that kind requires Docker. This isn't right as I understand it; you can actually use with Podman, even if you don't have Docker installed at all. Proposed Solution: check what's right update the docs to match the truth Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en
/assign
according to my knowledge we can use Buildah for managing container images and Podman for managing containers if someone is looking for an alternative to docker. But these can be used only on Linux, so for windows or mac a Linux VM will be used to run these and I am thinking to put this in a note. Your suggestions?
(yes) Also see Kubernetes itself doesn't require any of the listed tools (Podman, Docker, Buildah); for example, you might use CRI-O and runsc and the kubelet, but no Docker Engine.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
Podman now has documentation on how to work with the and plug-ins: https://podman-
/assign


Question: The `NodeRestriction` admission plugin would ignore requests from these kubelets, since the default node identifier implementation would not consider that a node identity. <del> ### Upgrades from previous versions using RBAC Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist. If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin to limit node access to the API, that can be done non-disruptively: 1. Enable the `Node` authorization mode (`--authorization-mode=Node,RBAC`) and the `NodeRestriction` admission plugin 2. Ensure all kubelets' credentials conform to the group/username requirements 3. Audit apiserver logs to ensure the `Node` authorizer is not rejecting requests from kubelets (no persistent `NODE DENY` messages logged) 4. Delete the `system:node` cluster role binding ### RBAC Node Permissions In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/). In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated because the node authorizer accomplishes the same purpose with the benefit of additional restrictions on secret and configmap access. If the `Node` and `RBAC` authorization modes are both enabled, the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7. In 1.8, the binding will not be created at all. When using RBAC, the `system:node` cluster role will continue to be created, for compatibility with deployment methods that bind other users or groups to that role. </del>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --2 sections below may include too old content, mentioning v1.6 ~ v1.8. They should be removed or updated. Upgrades from previous versions using RBAC RBAC Node Permissions Why is this needed Too old content may not be needed or should not be included in the latest document. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language en /kind cleanup
/triage accepted /sig auth I think
/assign
Rather than remove those sections, let's update them to clarify why they remain valid.
/kind documentation
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
/remove-kind feature /kind bug /priority backlog
Those labels are not set on the issue: <detailsIn response to : /remove-kind feature /kind bug /priority backlog Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/lifecycle rotten [1]:
/lifecycle frozen The update needed is to delete the page content from onwards (including that heading) /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /lifecycle frozen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted


Question: --> 可以组合使用 2 个拓扑分布约束来控制 Pod 在节点和可用区两个维度上的分布： <del> {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} </del> <ins> {{% code file="pods/topology-spread-constraints/two-constraints.yaml" %}} </ins> <!-- In this case, to match the first constraint, the incoming Pod can only be placed onto

the Chinese translation is wrong, "" should be "" see from English site:
/language zh
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language zh-cn </details
/language zh
/sig docs
/triage accepted
/assign


Question: - bsalamat title: Assigning Pods to Nodes content_template: templates/concept <del> weight: 30 </del> <ins> weight: 50 </ins> ---

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be write a new concept page: (or possibly ) If the does not work as the page overview, consider tweaking the glossary entry so that it does. Then use a Hugo shortcode. Why is this needed ConfigMap is a core object type for Kubernetes; as such, it needs documenting properly. Comments Consider using as an example for page structure. It's better to put Task-style documentation in task pages such as and then hyperlink to those from the Concept page. Also see: /docs/user-guide/configmap need more details on ConfigMap updates Actionable user-guide/configmap does not document self-updating It's unclear what happens when ConfigMap is changed Need doc on using ConfigMap updates Wanted: ConfigMap Rollout Options Doc
/language en /sig apps
/priority important-longterm
This is worth prioritizing /priority important-soon
/remove-priority important-longterm
/project Doc Sprints
/assign
/unassign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Still worth documenting /remove-lifecycle stale
/reopen let's collaborate on this!


Question: You can [download Kubernetes](/releases/download/) to deploy a Kubernetes cluster on a local machine, into the cloud, or for your own datacenter. <ins> Several [Kubernetes components](/docs/concepts/overview/components/) such as `kube-apiserver` or `kube-proxy` can also be deployed as [container images](/releases/download/#container-images) within the cluster. It is **recommended** to run Kubernetes components as container images wherever that is possible, and to have Kubernetes manage those components. Components that run containers - notably, the kubelet - can't be included in this category. </ins> If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including [certified platforms](/docs/setup/production-environment/turnkey-solutions/). There are also other standardized and custom solutions across a wide range of cloud and

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Tell readers where they can find container images for components of Kubernetes. Why is this needed It's possible to run components of Kubernetes using containers; in fact, as a project we recommend this. However if you try to find where those images are using a search engine and plausible search queries, you don't find that information. Comments Relevant to and to /sig release
/triage accepted
Extra credit: update to link to the new text.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
is somewhat relevant.
/assign


Question:
ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.

NodePort - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>. Superset of ClusterIP.

LoadBalancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.

ExternalName - Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns.

ExternalName - Maps the Service to the contents of the externalName field (e.g. `foo.bar.example.com`), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or CoreDNS version 0.0.8 or higher.

More information about the different types of Services can be found in the Using Source IP tutorial. Also see Connecting Applications with Services.

Additionally, note that there are some use cases with Services that involve not defining selector in the spec. A Service created without selector will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using type: ExternalName.

In this document () service type External name is explained as follows: ExternalName - Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns. This is misleading. The correct explanation could be (from ) as follows: ExternalName: Maps the Service to the contents of the externalName field (e.g. ), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or coreDNS version 0.0.8 or higher.
/sig network /kind cleanup /triage accepted
Thanks - that's worth fixing /priority backlog
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale


Question: border: 5px solid white; } <ins> body.cid-training #get-certified .col-nav { flex-flow: column nowrap; justify-content: space-between; } body.cid-training #get-certified .col-nav > * { flex-grow: 0; flex-shrink: 0; flex-basis: auto; } body.cid-training #get-certified .col-nav > br { flex-grow: 1; display: block; min-height: 2em; } body.cid-training #get-certified .col-nav a.button { flex: initial; width: auto; margin-left: auto; margin-right: auto; } </ins> @media only screen and (max-width: 840px) { <del> section.call-to-action .main-section .cta-image.cta-image-before, section.call-to-action .main-section .cta-image.cta-image-after { order: 0; } section.call-to-action .main-section .cta-image > img { </del> <ins> body.cid-training   section.call-to-action .main-section .cta-image > img { </ins> margin: 0; } <del> section.call-to-action .main-section .cta-image > img { </del> <ins> body.cid-training   section.call-to-action .main-section .cta-image > img { </ins> width: 7rem; } <del> section.call-to-action .main-section > div.call-to-action > div { </del> <ins> body.cid-training section.call-to-action .main-section > div.call-to-action > div { </ins> padding: 0 2rem 0 2rem; } <del> section.call-to-action .main-section .cta-text { flex: 2 0 75vw; max-width: initial; padding: 5vw 0 0 0; } </del> } /*  GO FULL WIDTH AT LESS THAN 480 PIXELS */ @media only screen and (max-width: 480px) { <del> .col { margin: 1% 0 1% 0%;} .col-container { flex-direction: column; } </del> <ins> body.cid-training .col { margin: 1% 0 1% 0%;} body.cid-training .col-container { flex-direction: column; } body.cid-training #logo-cks { order: initial; } </ins> } @media only screen and (max-width: 650px) { <del> .col-nav { </del> <ins> body.cid-training .col-nav { </ins> display: block; width: 100%; } <del> .col-container { flex-direction: column; } </del> <ins> body.cid-training .col-container { flex-direction: column; } </ins> } <del> .button{ </del> <ins> body.cid-training .button { </ins> max-width: 100%; box-sizing: border-box; margin: 1em 0;

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to mention the new Kubernetes Security Specialist Certification Why is this needed There is a Kubernetes Security Specialist Certification, coming in November 2020. Comments /kind feature /language en
/priority important-soon
let's collaborate to put everything in place to make this into a Good First Issue.
Design-wise, it's much easier to place 2 certification logos than 3. do you have any thoughts on how to adjust things design-wise to incorporate the 3rd certification?
/sig security
/triage accepted
/cc


Question: allocates resources for a pod based on its `requests`, and restricts the pod's resource usage based on the `limits` specified in the pod's containers. <ins> Changing the resource allocation for a running Pod requires the `InPlacePodVerticalScaling` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. The alternative is to delete the Pod and let the [workload controller](/docs/concepts/workloads/controllers/) make a replacement Pod that has a different resource requirement. </ins> For in-place resize of pod resources: - Container's resource `requests` and `limits` are _mutable_ for CPU and memory resources.

Not able to find which alpha feature gates for
/kind feature /triage accepted // +featureGate=InPlacePodVerticalScaling // +optional ResizePolicy []ContainerResizePolicy This field is controlled by the feature gate . It looks like we need to add a feature gate description. Does anyone want to help? /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /kind feature /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
There is a blog under review. I do concur that some docs are needed for such an important feature.
We should mention within didn't cover this detail.
InPlacePodVerticalScaling in also missing in
Fix coming in
Hi , as I am unable see the changes can I add it to the page?
The feature gate issue has been fixed but the feature description needs some more formal documentation. Please feel free to provide some inputs.
sure so we need to add the featureGate thing? here
It is not limited to the feature gate. It is about the feature. We are supposed to provide some brief introduction to this feature. Currently we have some texts on it, but those texts are provided as a blog (see ). Some of the blogs could have been part of the docs task page ().
thanks for clarifying
Note that this is the same issue as


Question: title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> <ins> aliases: [ '/zh/dockershim' ] </ins> --- <!-- layout: blog

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The link at the top of the homepage () seems to currently redirect to I assume this is the same issue as Proposed Solution: Remove the /dockershim alias from the ZH blog page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Same symptoms, different PR. /triage accepted Thanks. /priority important-soon
/assign


Question: To enable the rolling update feature of a DaemonSet, you must set its `.spec.updateStrategy.type` to `RollingUpdate`. <del> You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) </del> <ins> You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) </ins> (default to 1), <del> [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) and </del> <ins> [`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (default to 0) and </ins> [`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (a beta feature and defaults to 0) as well.

In , the para says that But after I click the page, I find no and I can only see . I also try in my env, the updateStrategy` does not. error: error validating "dep-": error validating data: ValidationError(): unknown field "updateStrategy" in ; if you choose to ignore these errors, turn validation off with --validate=false Is this document outdated? I can make a fix if it is.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi Both DaemonSet and Deployment use these 3 fields, linking to the deployment creates some confusion or misleading. I think we could link and to , same as refer to this similar issue for more info: see the reference api for
/good-first-issue
/remove-good-first-issue We only add that label for issues that have a barrier to entry that is zero or close to it. I'd expect to see at least: a link to the page that needs fixing a language label on the issue clear advice on the route to a fix / no concerns that there might be different options and the person working on it must choose /language en
Thanks, for this information. Actually, I forgot to mention the page in my comment, This is the page we have to update:
Yeah. I agree the new link will be better.
/assign


Question: $ kubectl config view ``` <del> Many of the [examples](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/) provide an introduction to using kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index). </del> <ins> Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview). </ins> ### Directly accessing the REST API

The URL can not access at the doc use the Go client library, and create a client using the rest.InClusterConfig() and kubernetes.NewForConfig()functions. They handle locating and authenticating to the apiserver. I think we should change this URL to
I can help fix it
This is fixed now and can be closed.


Question: Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false.  ### Not allowed - **ports** ([]ContainerPort) *Patch strategy: merge on key `containerPort`* *Map: unique values on keys `containerPort, protocol` will be kept during a merge* Ports are not allowed for ephemeral containers.  *ContainerPort represents a network port in a single container.* - **ports.containerPort** (int32), required Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536. - **ports.hostIP** (string) What host IP to bind the external port to. - **ports.hostPort** (int32) Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - **ports.name** (string) If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - **ports.protocol** (string) Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". Possible enum values: - `"SCTP"` is the SCTP protocol. - `"TCP"` is the TCP protocol. - `"UDP"` is the UDP protocol. - **resources** (ResourceRequirements) Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod.  *ResourceRequirements describes the compute resource requirements.* - **resources.limits** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity) Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **resources.requests** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity) Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **lifecycle** (Lifecycle) Lifecycle is not allowed for ephemeral containers.  *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - **lifecycle.postStart** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler) PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **lifecycle.preStop** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler) PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **livenessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe) Probes are not allowed for ephemeral containers. - **readinessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe)   ### Security context   Probes are not allowed for ephemeral containers.  - **securityContext** (SecurityContext)

This is a Bug Report <!--Required Information--Problem: Setting for ephemeral containers is allowed as of Kubernetes 1.22, but it's still showing up as a "not allowed" field here: Proposed Solution: This page looks to be autogenerated based on the API definition, but I'm not sure how it's detecting not allowed fields. If it's automatic we'll correct the metadata or if it's curated then just reclassify the field in docs. Page to Update:
/assign
The fix is likely to happen within
is autogenerated. I don't think received field updates for v1.22
Track the update of the documentation as an issue in this repository. /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Looks like this is still happening, and also is showing up under the alpha heading even though its description says (correctly) that it's beta. This dropped off my radar, but I'll take a look at it in the next few days. /remove-lifecycle stale
/priority critical-urgent
/remove-priority critical-urgent /priority important-soon /sig security you're welcome to make a case for raising it back to critical. What would be the motivation there?
Hi I don't wish to make that case. I was just trying to assign a priority according to guidance and . The documentation is wrong for a core feature, which seems like a "fix it now" rather than "fix it in the next release" priority. The priority isn't important to me, though. Happy for it to be whatever you think is best.
This repo uses continuous deployment (we don't wait for a release for fixes). Anyway, yes, it looks important.


Question: - [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations) - [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy) - [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt) <ins> - [`validation.policy.admission.k8s.io/validation_failure`](/docs/reference/labels-annotations-taints/audit-annotations/#validation-policy-admission-k8s-io-validation-failure) </ins> See more details on [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/). ## kubeadm

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: documents the audit annotation ; however, it is missing from (which is the formal document we use to record registrations). Proposed Solution: Update to mention the ValidatingAdmissionPolicy audit annotation. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig api-machinery /language en /priority backlog /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: documents the audit annotation ; however, it is missing from (which is the formal document we use to record registrations). Update to mention the ValidatingAdmissionPolicy audit annotation. <!--Kubernetes Version:--/sig api-machinery /language en /priority backlog /triage accepted /help </details
hey ,please review my change , I am trying to solve this
/assign
Fix merged as part of /close
Closing this issue. <detailsIn response to : Fix merged as part of Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question:
</form>

  {{ end }}   {{ end -}}

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I saw by accident very big page files on Kubernetes documentation. For example is lines long and the lines 286- are taken for the sidebar menu containing a lot of whitespace (do right-mouse and "view page source"). Proposed Solution: I reported the issue already with Docsy: and proposed a pull request. But this will not be enough. Somebody has to update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The hugo Docsy theme side issue is resolved and closed: When will somebody review and implement pull request ? You can do this separate from a Docsy theme update at It is only about (huge) whitespace reduction, not a functional change. But k8s website users will benefit in user experience.


Question: - Start or help with a [localization](/docs/contribute/localization/). --> <del> ## 下一步 </del> <ins> ## 下一步 {#next-teps} </ins> - 学习在仓库的[本地克隆中工作](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 - 为[发行版的特性](/zh/docs/contribute/new-content/new-features/)编写文档。

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Chinese page is different with English version page. Proposed Solution: Update Chinese page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh /assign
thanks reviews and approvement from xichengliudui, tengqm and idealhack


Question: If you have already created the cluster you must adapt it by doing the following: - Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace. <del> In that ConfigMap, the `config` key has a </del> <ins> In that ConfigMap, the `kubelet` key has a </ins> [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`. - On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`

Hi, In this document, In this section It is mentioned that in order to make the metrics-server works probably, you have to edit the ConfigMap as shown But in a kubeadm deployed cluster, there is no key in the ConfigMap .. There is this: Which you can not edit as described in the document. The metrics-server is not working due to this issue..
thanks for the report. the key should be renamed from to in PRs welcome. /triage accepted /sig cluster-lifecycle /kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details