Question: --> 1. 在集群中运行 Hello World 应用程序： <del> {{< codenew file="service/load-balancer-example.yaml" >}} ```shell kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` <!-- The preceding command creates a [Deployment](/docs/concepts/workloads/controllers/deployment/) object and an associated [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) object. The ReplicaSet has five [Pods](/docs/concepts/workloads/pods/pod/), each of which runs the Hello World application. --> 前面的命令创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 对象和一个关联的 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)对象。 ReplicaSet 有五个 [Pod](/zh/docs/concepts/workloads/pods/pod/)，每个都运行 Hello World 应用程序。 </del> <ins> {{< codenew file="service/load-balancer-example.yaml" >}} ```shell kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` <!-- The preceding command creates a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} and an associated {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}. The ReplicaSet has five {{< glossary_tooltip text="Pods" term_id="pod" >}} each of which runs the Hello World application. --> 前面的命令创建一个 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 对象和一个关联的 {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} 对象。 ReplicaSet 有五个 {{< glossary_tooltip text="Pods" term_id="pod" >}}， 每个都运行 Hello World 应用程序。 </ins> <!-- 1. Display information about the Deployment: --> 2. 显示有关 Deployment 的信息： <del> kubectl get deployments hello-world kubectl describe deployments hello-world </del> <ins> ```shell kubectl get deployments hello-world kubectl describe deployments hello-world ``` </ins> <!-- 1. Display information about your ReplicaSet objects: --> 3. 显示有关 ReplicaSet 对象的信息： <del> kubectl get replicasets kubectl describe replicasets </del> <ins> ```shell kubectl get replicasets kubectl describe replicasets ``` </ins> <!-- 1. Create a Service object that exposes the deployment: --> <del> 4. 创建公开 deployment 的 Service 对象： </del> <ins> 4. 创建公开 Deployment 的 Service 对象： </ins> <del> kubectl expose deployment hello-world --type=LoadBalancer --name=my-service </del> <ins> ```shell kubectl expose deployment hello-world --type=LoadBalancer --name=my-service ``` </ins> <!-- 1. Display information about the Service: --> 5. 显示有关 Service 的信息： <del> kubectl get services my-service </del> <ins> ```shell kubectl get services my-service ``` </ins> <del> <!-- </del> <ins> <!-- </ins> The output is similar to this: <del> --> </del> <ins> --> </ins> 输出类似于： <del> NAME         TYPE        CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE my-service   ClusterIP   10.3.245.137   104.198.205.71   8080/TCP   54s <!-- {{< note >}} The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details. {{< /note >}} --> 注意：`type=LoadBalancer` 服务由外部云服务提供商提供支持，本例中不包含此部分，详细信息请参考[此页](/docs/concepts/services-networking/service/#loadbalancer) <!-- {{< note >}} If the external IP address is shown as <pending>, wait for a minute and enter the same command again. {{< /note >}} --> 注意：如果外部 IP 地址显示为 <pending>，请等待一分钟再次输入相同的命令。 </del> <ins> ``` NAME         TYPE        CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE my-service   ClusterIP   10.3.245.137   104.198.205.71   8080/TCP   54s ``` <!-- {{< note >}} The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details. {{< /note >}} --> 提示：`type=LoadBalancer` 服务由外部云服务提供商提供支持，本例中不包含此部分， 详细信息请参考[此页](/docs/concepts/services-networking/service/#loadbalancer) <!-- {{< note >}} If the external IP address is shown as <pending>, wait for a minute and enter the same command again. {{< /note >}} --> 提示：如果外部 IP 地址显示为 <pending>，请等待一分钟再次输入相同的命令。 </ins> <!-- 1. Display detailed information about the Service: --> 6. 显示有关 Service 的详细信息： <del> kubectl describe services my-service </del> <ins> ```shell kubectl describe services my-service ``` </ins> <del> <!-- </del> <ins> <!-- </ins> The output is similar to this: <del> --> </del> <ins> --> </ins> 输出类似于： <del> Name:           my-service Namespace:      default Labels:         run=load-balancer-example Annotations:    <none> Selector:       run=load-balancer-example Type:           LoadBalancer IP:             10.3.245.137 LoadBalancer Ingress:   104.198.205.71 Port:           <unset> 8080/TCP NodePort:       <unset> 32377/TCP Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... Session Affinity:   None Events:         <none> <!-- </del> <ins> ``` Name:           my-service Namespace:      default Labels:         run=load-balancer-example Annotations:    <none> Selector:       run=load-balancer-example Type:           LoadBalancer IP:             10.3.245.137 LoadBalancer Ingress:   104.198.205.71 Port:           <unset> 8080/TCP NodePort:       <unset> 32377/TCP Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... Session Affinity:   None Events:         <none> ``` <!-- </ins> Make a note of the external IP address (`LoadBalancer Ingress`) exposed by your service. In this example, the external IP address is 104.198.205.71. Also note the value of `Port` and `NodePort`. In this example, the `Port` is 8080 and the `NodePort` is 32377. <del> --> </del> <ins> --> </ins> 记下服务公开的外部 IP 地址（`LoadBalancer Ingress`)。 在本例中，外部 IP 地址是 104.198.205.71。还要注意 `Port` 和 `NodePort` 的值。 在本例中，`Port` 是 8080，`NodePort` 是32377。 <!-- 1. In the preceding output, you can see that the service has several endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more. These are internal

This is a Bug Report Chinese page contentzhdocstutorialsstateless-applicationexpose-external-ip- outdated <!-- 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 contentzhdocstutorialsstateless-applicationexpose-external-ip- is different with English version page. Proposed Solution: Update Chinese page Page to Update: contentzhdocstutorialsstateless-applicationexpose-external-ip- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/assign


Question: <ins> --- layout: blog title: "Kubernetes 在 v1.27 中移除的特性和主要变更" date: 2023-03-17T14:00:00+0000 slug: upcoming-changes-in-kubernetes-v1-27 --- <!-- layout: blog title: "Kubernetes Removals and Major Changes In v1.27" date: 2023-03-17T14:00:00+0000 slug: upcoming-changes-in-kubernetes-v1-27 --> <!-- **Author**: Harshita Sao --> **作者**：Harshita Sao **译者**：Michael Yao (DaoCloud) <!-- As Kubernetes develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. Based on the information available at this point in the v1.27 release process, which is still ongoing and can introduce additional changes, this article identifies and describes some of the planned changes for the Kubernetes v1.27 release. --> 随着 Kubernetes 发展和成熟，为了此项目的整体健康，某些特性可能会被弃用、移除或替换为优化过的特性。 基于目前在 v1.27 发布流程中获得的信息，本文将列举并描述一些计划在 Kubernetes v1.27 发布中的变更， 发布工作目前仍在进行中，可能会引入更多变更。 <!-- ## A note about the k8s.gcr.io redirect to registry.k8s.io To host its container images, the Kubernetes project uses a community-owned image registry called registry.k8s.io. **On March 20th, all traffic from the out-of-date [k8s.gcr.io](https://cloud.google.com/container-registry/) registry will be redirected to [registry.k8s.io](https://github.com/kubernetes/registry.k8s.io)**. The deprecated k8s.gcr.io registry will eventually be phased out. --> ## k8s.gcr.io 重定向到 registry.k8s.io 相关说明   {#note-about-redirect} Kubernetes 项目为了托管其容器镜像，使用社区拥有的一个名为 registry.k8s.io. 的镜像仓库。 **从 3 月 20 日起，所有来自过期 [k8s.gcr.io](https://cloud.google.com/container-registry/) 仓库的流量将被重定向到 [registry.k8s.io](https://github.com/kubernetes/registry.k8s.io)**。 已弃用的 k8s.gcr.io 仓库最终将被淘汰。 <!-- ### What does this change mean? - If you are a subproject maintainer, you must update your manifests and Helm charts to use the new registry. - The v1.27 Kubernetes release will not be published to the old registry. - From April, patch releases for v1.24, v1.25, and v1.26 will no longer be published to the old registry. --> ### 这次变更意味着什么？   {#what-does-this-change-mean} - 如果你是一个子项目的 Maintainer，你必须更新自己的清单和 Helm Chart 来使用新的仓库。 - Kubernetes v1.27 版本不会发布到旧的仓库。 - 从 4 月份起，针对 v1.24、v1.25 和 v1.26 的补丁版本将不再发布到旧的仓库。 <!-- We have a [blog post](/blog/2023/03/10/image-registry-redirect/) with all the information about this change and what to do if it impacts you. --> 我们曾发布了一篇[博文](/blog/2023/03/10/image-registry-redirect/)， 讲述了此次变更有关的所有信息，以及影响到你时应该采取的措施。 <!-- ## The Kubernetes API Removal and Deprecation process The Kubernetes project has a well-documented [deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API has been marked for removal in a future Kubernetes release, it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. --> ## Kubernetes API 移除和弃用流程 {#k8s-api-deprecation-process} Kubernetes 项目对特性有一个[文档完备的弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可以被弃用， 每个稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API；移除之前该 API 将继续发挥作用（从弃用起至少一年时间）， 但使用时会显示一条警告。被移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。 <!-- - Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. - Beta or pre-release API versions must be supported for 3 releases after the deprecation. - Alpha or experimental API versions may be removed in any release without prior deprecation notice. --> - 正式发布（GA）或稳定的 API 版本可能被标记为已弃用，但只有在 Kubernetes 大版本更新时才会被移除。 - 测试版（Beta）或预发布 API 版本在弃用后必须在后续 3 个版本中继续支持。 - Alpha 或实验性 API 版本可以在任何版本中被移除，不另行通知。 <!-- Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation. --> 无论一个 API 是因为某特性从 Beta 进阶至稳定阶段而被移除，还是因为该 API 根本没有成功， 所有移除均遵从上述弃用策略。无论何时移除一个 API，文档中都会列出迁移选项。 <!-- ## API removals, and other changes for Kubernetes v1.27 ### Removal of `storage.k8s.io/v1beta1` from `CSIStorageCapacity` --> ## 针对 Kubernetes v1.27 移除的 API 和其他变更   {#api-removals-and-other-changes-in-1.27} ### 从 `CSIStorageCapacity` 移除 `storage.k8s.io/v1beta1` <!-- The [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances the scheduling of pods that use CSI volumes with late binding. The `storage.k8s.io/v1beta1` API version of CSIStorageCapacity was deprecated in v1.24, and it will no longer be served in v1.27. --> [CSIStorageCapacity](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) API 支持通过 CSIStorageCapacity 对象来暴露当前可用的存储容量，并增强在后续绑定时使用 CSI 卷的 Pod 的调度。 CSIStorageCapacity 的 `storage.k8s.io/v1beta1` API 版本在 v1.24 中已被弃用，将在 v1.27 中被移除。 <!-- Migrate manifests and API clients to use the `storage.k8s.io/v1` API version, available since v1.24. All existing persisted objects are accessible via the new API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. --> 迁移清单和 API 客户端以使用自 v1.24 起可用的 `storage.k8s.io/v1` API 版本。 所有现有的已持久保存的对象都可以通过这个新的 API 进行访问。 更多信息可以参阅 [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking)。 <!-- Kubernetes v1.27 is not removing any other APIs; however several other aspects are going to be removed. Read on for details. --> Kubernetes v1.27 没有移除任何其他 API；但还有其他若干特性将被移除。请继续阅读下文。 <!-- ### Support for deprecated seccomp annotations In Kubernetes v1.19, the [seccomp](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/135-seccomp) (secure computing mode) support graduated to General Availability (GA). This feature can be used to increase the workload security by restricting the system calls for a Pod (applies to all containers) or single containers. --> ### 对弃用的 seccomp 注解的支持 在 Kubernetes v1.19 中， [seccomp](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/135-seccomp) （安全计算模式）支持进阶至正式发布 (GA)。 此特性通过限制 Pod（应用到所有容器）或单个容器可执行的系统调用可以提高工作负载安全性。 <!-- The support for the alpha seccomp annotations `seccomp.security.alpha.kubernetes.io/pod` and `container.seccomp.security.alpha.kubernetes.io` were deprecated since v1.19, now have been completely removed. The seccomp fields are no longer auto-populated when pods with seccomp annotations are created. Pods should use the corresponding pod or container `securityContext.seccompProfile` field instead. --> 对 Alpha 状态的 seccomp 注解 `seccomp.security.alpha.kubernetes.io/pod` 和 `container.seccomp.security.alpha.kubernetes.io` 的支持自 v1.19 起被弃用， 现在已完全移除。当创建具有 seccomp 注解的 Pod 时 seccomp 字段将不再被自动填充。 Pod 应转为使用相应的 Pod 或容器 `securityContext.seccompProfile` 字段。 <!-- ### Removal of several feature gates for volume expansion The following feature gates for [volume expansion](https://github.com/kubernetes/enhancements/issues/284) GA features will be removed and must no longer be referenced in `--feature-gates` flags: --> ### 移除针对卷扩展的若干特性门控 针对[卷扩展](https://github.com/kubernetes/enhancements/issues/284) GA 特性的以下特性门控将被移除，且不得再在 `--feature-gates` 标志中引用： <!-- `ExpandCSIVolumes` : Enable expanding of CSI volumes. `ExpandInUsePersistentVolumes` : Enable expanding in-use PVCs. `ExpandPersistentVolumes` : Enable expanding of persistent volumes. --> `ExpandCSIVolumes` : 启用 CSI 卷的扩展。 `ExpandInUsePersistentVolumes` : 启用扩展正使用的 PVC。 `ExpandPersistentVolumes` : 启用持久卷的扩展。 <!-- ### Removal of `--master-service-namespace` command line argument The kube-apiserver accepts a deprecated command line argument, `--master-service-namespace`, that specified where to create the Service named `kubernetes` to represent the API server. Kubernetes v1.27 will remove that argument, which has been deprecated since the v1.26 release. --> ### 移除 `--master-service-namespace` 命令行参数 kube-apiserver 接受一个已弃用的命令行参数 `--master-service-namespace`， 该参数指定在何处创建名为 `kubernetes` 的 Service 来表示 API 服务器。 Kubernetes v1.27 将移除自 v1.26 版本已被弃用的该参数。 <!-- ### Removal of the `ControllerManagerLeaderMigration` feature gate [Leader Migration](https://github.com/kubernetes/enhancements/issues/2436) provides a mechanism in which HA clusters can safely migrate "cloud-specific" controllers between the `kube-controller-manager` and the `cloud-controller-manager` via a shared resource lock between the two components while upgrading the replicated control plane. --> ### 移除 `ControllerManagerLeaderMigration` 特性门控 [Leader Migration](https://github.com/kubernetes/enhancements/issues/2436) 提供了一种机制，让 HA 集群在升级多副本的控制平面时通过在 `kube-controller-manager` 和 `cloud-controller-manager` 这两个组件之间共享的资源锁，安全地迁移“特定于云平台”的控制器。 <!-- The `ControllerManagerLeaderMigration` feature, GA since v1.24, is unconditionally enabled and for the v1.27 release the feature gate option will be removed. If you're setting this feature gate explicitly, you'll need to remove that from command line arguments or configuration files. --> `ControllerManagerLeaderMigration` 特性自 v1.24 正式发布，被无条件启用， 在 v1.27 版本中此特性门控选项将被移除。 如果你显式设置此特性门控，你将需要从命令行参数或配置文件中将其移除。 <!-- ### Removal of `--enable-taint-manager` command line argument The kube-controller-manager command line argument `--enable-taint-manager` is deprecated, and will be removed in Kubernetes v1.27. The feature that it supports, [taint based eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions), is already enabled by default and will continue to be implicitly enabled when the flag is removed. --> ### 移除 `--enable-taint-manager` 命令行参数 kube-controller-manager 命令行参数 `--enable-taint-manager` 已被弃用， 将在 Kubernetes v1.27 中被移除。 该参数支持的特性[基于污点的驱逐](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions)已被默认启用， 且在标志被移除时也将继续被隐式启用。 <!-- ### Removal of `--pod-eviction-timeout` command line argument The deprecated command line argument `--pod-eviction-timeout` will be removed from the kube-controller-manager. --> ### 移除 `--pod-eviction-timeout` 命令行参数 弃用的命令行参数 `--pod-eviction-timeout` 将被从 kube-controller-manager 中移除。 <!-- ### Removal of the `CSI Migration` feature gate The [CSI migration](https://github.com/kubernetes/enhancements/issues/625) programme allows moving from in-tree volume plugins to out-of-tree CSI drivers. CSI migration is generally available since Kubernetes v1.16, and the associated `CSIMigration` feature gate will be removed in v1.27. --> ### 移除 `CSI Migration` 特性门控 [CSI migration](https://github.com/kubernetes/enhancements/issues/625) 程序允许从树内卷插件移动到树外 CSI 驱动程序。 CSI 迁移自 Kubernetes v1.16 起正式发布，关联的 `CSIMigration` 特性门控将在 v1.27 中被移除。 <!-- ### Removal of `CSIInlineVolume` feature gate The [CSI Ephemeral Volume](https://github.com/kubernetes/kubernetes/pull/111258) feature allows CSI volumes to be specified directly in the pod specification for ephemeral use cases. They can be used to inject arbitrary states, such as configuration, secrets, identity, variables or similar information, directly inside pods using a mounted volume. This feature graduated to GA in v1.25. Hence, the feature gate `CSIInlineVolume` will be removed in the v1.27 release. --> ### 移除 `CSIInlineVolume` 特性门控 [CSI Ephemeral Volume](https://github.com/kubernetes/kubernetes/pull/111258) 特性允许在 Pod 规约中直接指定 CSI 卷作为临时使用场景。这些 CSI 卷可用于使用挂载的卷直接在 Pod 内注入任意状态，例如配置、Secret、身份、变量或类似信息。 此特性在 v1.25 中进阶至正式发布。因此，此特性门控 `CSIInlineVolume` 将在 v1.27 版本中移除。 <!-- ### Removal of `EphemeralContainers` feature gate [Ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) graduated to GA in v1.25. These are containers with a temporary duration that executes within namespaces of an existing pod. Ephemeral containers are typically initiated by a user in order to observe the state of other pods and containers for troubleshooting and debugging purposes. For Kubernetes v1.27, API support for ephemeral containers is unconditionally enabled; the `EphemeralContainers` feature gate will be removed. --> ### 移除 `EphemeralContainers` 特性门控 [临时容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)在 v1.25 中进阶至正式发布。 这些是具有临时持续周期的容器，在现有 Pod 的命名空间内执行。 临时容器通常由用户发起，以观察其他 Pod 和容器的状态进行故障排查和调试。 对于 Kubernetes v1.27，对临时容器的 API 支持被无条件启用；`EphemeralContainers` 特性门控将被移除。 <!-- ### Removal of `LocalStorageCapacityIsolation` feature gate The [Local Ephemeral Storage Capacity Isolation](https://github.com/kubernetes/kubernetes/pull/111513) feature moved to GA in v1.25. The feature provides support for capacity isolation of local ephemeral storage between pods, such as `emptyDir` volumes, so that a pod can be hard limited in its consumption of shared resources. The kubelet will evicting Pods if consumption of local ephemeral storage exceeds the configured limit. The feature gate, `LocalStorageCapacityIsolation`, will be removed in the v1.27 release. --> ### 移除 `LocalStorageCapacityIsolation` 特性门控 [Local Ephemeral Storage Capacity Isolation](https://github.com/kubernetes/kubernetes/pull/111513) 特性在 v1.25 中进阶至正式发布。此特性支持 `emptyDir` 卷这类 Pod 之间本地临时存储的容量隔离， 因此可以硬性限制 Pod 对共享资源的消耗。如果本地临时存储的消耗超过了配置的限制，kubelet 将驱逐 Pod。 特性门控 `LocalStorageCapacityIsolation` 将在 v1.27 版本中被移除。 <!-- ### Removal of `NetworkPolicyEndPort` feature gate The v1.25 release of Kubernetes promoted `endPort` in NetworkPolicy to GA. NetworkPolicy providers that support the `endPort` field that can be used to specify a range of ports to apply a NetworkPolicy. Previously, each NetworkPolicy could only target a single port. So the feature gate `NetworkPolicyEndPort` will be removed in this release. --> ### 移除 `NetworkPolicyEndPort` 特性门控 Kubernetes v1.25 版本将 NetworkPolicy 中的 `endPort` 进阶至正式发布。 支持 `endPort` 字段的 NetworkPolicy 提供程序可用于指定一系列端口以应用 NetworkPolicy。 以前每个 NetworkPolicy 只能针对一个端口。因此，此特性门控 `NetworkPolicyEndPort` 将在此版本中被移除。 <!-- Please be aware that `endPort` field must be supported by the Network Policy provider. If your provider does not support `endPort`, and this field is specified in a Network Policy, the Network Policy will be created covering only the port field (single port). --> 请注意，`endPort` 字段必须得到 NetworkPolicy 提供程序的支持。 如果你的提供程序不支持 `endPort`，并且此字段在 NetworkPolicy 中指定， 则将创建仅涵盖端口字段（单个端口）的 NetworkPolicy。 <!-- ### Removal of `StatefulSetMinReadySeconds` feature gate For a pod that is part of a StatefulSet, Kubernetes can mark the Pod ready only if Pod is available (and passing checks) for at least the period you specify in [`minReadySeconds`](/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds). The feature became generally available in Kubernetes v1.25, and the `StatefulSetMinReadySeconds` feature gate will be locked to true and removed in the v1.27 release. --> ### 移除 `StatefulSetMinReadySeconds` 特性门控 对于作为 StatefulSet 一部分的 Pod，只有当 Pod 至少在 [`minReadySeconds`](/zh-cn/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds) 中指定的持续期内可用（并通过检查）时，Kubernetes 才会将此 Pod 标记为只读。 该特性在 Kubernetes v1.25 中正式发布，`StatefulSetMinReadySeconds` 特性门控将锁定为 true，并在 v1.27 版本中被移除。 <!-- ### Removal of `IdentifyPodOS` feature gate You can specify the operating system for a Pod, and the feature support for that is stable since the v1.25 release. The `IdentifyPodOS` feature gate will be removed for Kubernetes v1.27. --> ### 移除 `IdentifyPodOS` 特性门控 你可以为 Pod 指定操作系统，此项特性支持自 v1.25 版本进入稳定。 `IdentifyPodOS` 特性门控将在 Kubernetes v1.27 中被移除。 <!-- ### Removal of `DaemonSetUpdateSurge` feature gate The v1.25 release of Kubernetes also stabilised surge support for DaemonSet pods, implemented in order to minimize DaemonSet downtime during rollouts. The `DaemonSetUpdateSurge` feature gate will be removed in Kubernetes v1.27. --> ### 移除 `DaemonSetUpdateSurge` 特性门控 Kubernetes v1.25 版本还稳定了对 DaemonSet Pod 的浪涌支持， 其实现是为了最大限度地减少部署期间 DaemonSet 的停机时间。 `DaemonSetUpdateSurge` 特性门控将在 Kubernetes v1.27 中被移除。 <!-- ## Looking ahead The official list of [API removals](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-29) planned for Kubernetes v1.29 includes: --> ## 前瞻   {#looking-ahead} Kubernetes 1.29 计划[移除的 API 官方列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-29)包括： <!-- - The `flowcontrol.apiserver.k8s.io/v1beta2` API version of FlowSchema and PriorityLevelConfiguration will no longer be served in v1.29. --> - FlowSchema 和 PriorityLevelConfiguration 的 `flowcontrol.apiserver.k8s.io/v1beta2` API 版本将不再在 v1.29 中提供。 <!-- ## Want to know more? Deprecations are announced in the Kubernetes release notes. You can see the announcements of pending deprecations in the release notes for: --> ## 了解更多   {#want-to-know-more} Kubernetes 发行说明中宣告了弃用信息。你可以在以下版本的发行说明中看到待弃用的公告： - [Kubernetes v1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation) - [Kubernetes v1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) - [Kubernetes v1.25](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#deprecation) - [Kubernetes v1.26](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md#deprecation) <!-- We will formally announce the deprecations that come with [Kubernetes v1.27](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#deprecation) as part of the CHANGELOG for that release. --> 我们将在 [Kubernetes v1.27](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#deprecation) 的 CHANGELOG 中正式宣布该版本的弃用信息。 <!-- For information on the process of deprecation and removal, check out the official Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) document. --> 有关弃用和移除流程信息，请查阅正式的 [Kubernetes 弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)文档。 </ins>

I will localize this blog in days: To avoid any probable conflicts, this issue is opened. /assign /language zh
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: 1. Download the latest release with the command: ```bash <del> curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert" </ins> ``` 1. Validate the binary (optional)

I was following the instructions on . When I download the kubectl convert plugin, it gives me this error. !
Hi The URL used by you is wrong. In your URL you put a backslash in two places one is after $ and the second after see below: Correct one is:
For me, there seems no backslashes in the command, ! but when I copy that and paste, the backslashes appear. ! (Copied in Windows 10 x64, Chrome 97.0.4692.71, pasted to the Oracle Virtualbox VM, Ubuntu 18.04 desktop x64, bundled Terminal app) In that page, replacing to might resolve the problem. ! (This one causes no problem.) /kind bug /triage accepted
Hi when I do copy and paste it, the backslash does not appear in the command.
Maybe automatically adds backslashes.. I am using , and I guess that is using too. ( Is this correct? ) And It seems that you are using other than , Is this correct? If these are correct, then I guess that replacing to will cause no problem on , , and so on.
Hi yes, I am using the bash, maybe it is with zsh. I tried this command and it is also working, so we can replace the command with
/good-first-issue
This request has been marked as suitable for new contributors. 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 : /good-first-issue 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
Yup, I am using zsh as well
/assign
GitHub didn't allow me to assign the following users: championshuttler.

Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/assign


Question: cosign verify-blob "$BINARY" --signature "$BINARY".sig --certificate "$BINARY".cert ``` <ins> cosign v1.9.0 is required to be able to use the `--certificate` flag. Please use `--cert` for older versions of cosign. </ins> {{< note >}} To learn more about keyless signing, please refer to [Keyless Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures).

The right command line for usage should be: So with instead of the actual which is an unrecognized option, at least in version 1.6.0.
/retitle Wrong command in “Verify Signed Kubernetes Artifacts” task /language en
It appears that the cosign version has updated this parameter to --certificate But for compatibility with previous versions, both and can be used. So the document just uses the newer version of the command. related issue: related PR: code
Today, if you follow the instructions (and so you download 1.6.0), you get an error, so it might be useful to fix this anyway.
Perhaps, the version of needs to be indicated in the docs? For more advice.
Yes, maybe that would fix the problem as well.
I agree having the cosign version mentioned in the docs will help us to prevent such issues in the future.
/triage accepted
Page to update:
Can we also mention the note about cosign, something like this: if we are using cosign version v1.9.0+ we should use the parameter instead of the
/assign


Question: <del> --- reviewers: - bgrant0607 - mikedanese title: What is Kubernetes? description: > Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. content_type: concept weight: 10 card: name: concepts weight: 10 sitemap: priority: 0.9 --- <!-- overview --> This page is an overview of Kubernetes. <!-- body --> Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community. ## Going back in time Let's take a look at why Kubernetes is so useful by going back in time. ![Deployment evolution](/images/docs/Container_Evolution.svg) **Traditional deployment era:** Early on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers. **Virtualized deployment era:**  As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application. Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more. With virtualization you can present a set of physical resources as a cluster of disposable virtual machines. Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware. **Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions. Containers have become popular because they provide extra benefits, such as: * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use. * Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability). * Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure. * Observability: not only surfaces OS-level information and metrics, but also application health and other signals. * Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud. * Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else. * Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources. * Loosely coupled, distributed, elastic, liberated micro-services: applications are broken into smaller, independent pieces and can be deployed and managed dynamically – not a monolithic stack running on one big single-purpose machine. * Resource isolation: predictable application performance. * Resource utilization: high efficiency and density. ## Why you need Kubernetes and what it can do {#why-you-need-kubernetes-and-what-can-it-do} Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system? That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system. Kubernetes provides you with: * **Service discovery and load balancing** Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable. * **Storage orchestration** Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more. * **Automated rollouts and rollbacks** You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container. * **Automatic bin packing** You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources. * **Self-healing** Kubernetes restarts containers that fail, replaces containers, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. * **Secret and configuration management** Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration. ## What Kubernetes is not Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. Kubernetes: * Does not limit the types of applications supported. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes. * Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements. * Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, MySQL), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the [Open Service Broker](https://openservicebrokerapi.org/). * Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics. * Does not provide nor mandate a configuration language/system (for example, Jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications. * Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. * Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn't matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible. ## {{% heading "whatsnext" %}} *   Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) *   Ready to [Get Started](/docs/setup/)? </del>

How about "consists of a control plane and a set of machines called nodes"? Learning k8s is hard enough without obfuscating verbosity. For non-managers it's best to say it as it is ;-). Apart from that: "consists of the components that represent the control plane" suggests that there are components that represent a control pane, not are a control pane, and a set of nodes. So where is the control pane? I'm probably a big introvert and a nerd, but this confuses me to the point where I actually have to think about what this means... "In what way do the components represent the control pane? Where is the control pane itself? Am I not getting this? Probably not. It probably means these components are the control pane. Stupid me, of course that's what it means." So, while I could have understood what was meant in a split second, it takes me a couple of seconds of contemplation and a few minutes to suggest an improvement.
We could update the source of to make that change. Nice suggestion. is automatically generated. For a bigger improvement, we could move to and configure a redirect. /language en
/triage accepted /help If someone is planning to move this forward: move to configure a redirect from the old URL to the new URL (see ) make sure that the updated ends how you'd expect. It's likely that setting in the will 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 : /triage accepted /help move to configure a redirect from the old URL to the new URL (see ) make sure that the updated ends how you'd expect. It's likely that setting in the will 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
Feel free to reply with questions.
I would love to take this /assign
/good-first-issue For the first-timers, look
This request has been marked as suitable for new contributors. 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 : /good-first-issue For the first-timers, look 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: 4. Katacoda environment only: Type `30000`, and then click **Display Port**. {{< note >}} <del> The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service. </del> <ins> The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service. </ins> If you are running in an environment as root, see [Open Dashboard with URL](#open-dashboard-with-url). <del> To stop the proxy, run `Ctrl+C` to exit the process. The dashboard remains running. </del> <ins> By default, the dashboard is only accessible from within the internal Kubernetes virtual network. The `dashboard` command creates a temporary proxy to make the dashboard accessible from outside the Kubernetes virtual network. To stop the proxy, run `Ctrl+C` to exit the process. After the command exits, the dashboard remains running in Kubernetes cluster. You can run the `dashboard` command again to create another proxy to access the dashboard. </ins> {{< /note >}} ## Open Dashboard with URL

Nope, when you press Ctrl+C after running the dashboard stops working.
Thanks for the first issue here! By saying "when you press Ctrl+C after running minikube dashboard the dashboard stops working", do you mean the web browser cannot access the dashboard page after Ctrl+C? This is the expected behavior. After the proxy is stopped, the current web browser session stops working. But the dashboard server is still running in the background, you can open another proxy connection to access it again. I can try to improve the doc if the original sentence confuses new learners.
Hello, From a user perspective the dashboard is unusable after Ctrl+C and if you start it again it’s on a different port so it looks very mich like it’s stopped. The real question is why starting the dashboard should block the CLI like this. I’d say the behaviour is unnecessarily confusing for beginners and the documentation compounds this.
Let me improve the doc to clarify this. /triage accepted /kind feature
/assign


Question: /docs/reference/glossary/maintainer/    /docs/reference/glossary/approver/ 301 <ins> /docs/reference/kubectl/kubectl-cmds/     /docs/reference/generated/kubectl/kubectl-commands/ 301! </ins> /docs/reference/kubectl/kubectl/kubectl_*.md    /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301

A page just to provide a link another page? My be you are planning more links on this page. If not this page it self can point to target page.
Hi in this there is another link reference to kubectl commands refrence , so far i am understanding is that you want to replace reference Link for kubectl command to be in this ?
To fix this, edit  so that it redirects to /good-first-issue /language en
/triage accepted
/retitle No page content for
/assign
hi could you help to review the PR? Thanks
~reviewers~ approvers for the English localization (who are mainly volunteers) pick up that task on a . I can take a look though.
/remove-good-first-issue
/assign
I the redirect () but it doesn't seem to be working on the deploy preview or locally. Any advice would be appreciated:


Question: <ins> apiVersion: v1 kind: Pod metadata: name: envvars-multiple-secrets spec: containers: - name: envars-test-container image: nginx env: - name: BACKEND_USERNAME valueFrom: secretKeyRef: name: backend-user key: backend-username - name: DB_USERNAME valueFrom: secretKeyRef: name: db-user key: db-username </ins>

Translate into Japanese. This page has not been translated. /language ja /assign
/triage accepted


Question: - Put object descriptions in annotations, to allow better introspection. <ins> {{< note >}} There is a breaking change introduced in the [YAML 1.2](https://yaml.org/spec/1.2.0/#id2602744) boolean values specification with respect to [YAML 1.1](https://yaml.org/spec/1.1/#id864510). This is a known [issue](https://github.com/kubernetes/kubernetes/issues/34146) in Kubernetes. YAML 1.2 only recognizes **true** and **false** as valid booleans, while YAML 1.1 also accepts **yes**, **no**, **on**, and  **off** as booleans. However, Kubernetes uses YAML [parsers](https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024) that are mostly compatible with YAML 1.1, which means that using **yes** or **no** instead of **true** or **false** in a YAML manifest may cause unexpected errors or behaviors. To avoid this issue, it is recommended to always use **true** or **false** for boolean values in YAML manifests, and to quote any strings that may be confused with booleans, such as **"yes"** or **"no"**. Besides booleans, there are additional specifications changes between YAML versions. Please refer to the [YAML Specification Changes](https://spec.yaml.io/main/spec/1.2.2/ext/changes) documentation for a comprehensive list. {{< /note >}} </ins> ## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs} - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or

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 describes a bug in Kubernetes where YAML 1.2 documents are not parsed (Kubernetes does not have good support for YAML 1.1), but then also Kubernetes does incorrectly parse completely valid YAML 1.1 the way that the specification defines. Why is this needed The bug makes it hard for some people, using conformant libraries, to make YAML documents that Kubernetes accepts. We should document the bug so that readers are aware of the shortcomings here. Comments /wg api-expression /language en /priority backlog
/triage accepted
i can help you because I'm new to it so if i can tag along i will be able to learn a lot
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
would you add this as a warning note in ?
/assign


Question: Creation and deletion of namespaces are described in the [Admin Guide documentation for namespaces](/docs/admin/namespaces). <ins> {{< note >}} Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. {{< /note >}} </ins> ### Viewing namespaces You can list the current namespaces in a cluster using:

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 document that namespaces starting are reserved. Why is this needed According to all namespaces with names that start with are reserved. Comments /kind feature /language en /sig architecture /good-first-issue
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. --Update to document that namespaces starting are reserved. According to all namespaces with names that start with are reserved. /kind feature /language en /sig architecture /good-first-issue 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
/assign me
GitHub didn't allow me to assign the following users: me. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me </details
/assign


Question: <ins> --- reviewers: title: リソースクォータ content_template: templates/concept weight: 10 --- {{% capture overview %}} 複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。 リソースクォータはこの問題に対処するための管理者向けツールです。 {{% /capture %}} {{% capture body %}} `ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。 リソースクォータは下記のように働きます。 - 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 - `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 - 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。 - "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかけ、"production"という名前空間には制限をかけない。 クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。 リソースの競合もクォータの変更も、作成済みのリソースには影響しません。 ## リソースクォータを有効にする 多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。 特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。 ## リソースクォータの計算 特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。 下記のリソースタイプがサポートされています。 | リソース名 | 説明 | | --------------------- | ----------------------------------------------------------- | | `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 | | `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 | | `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | | `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 | ### 拡張リソースのためのリソースクォータ 上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。 * `requests.nvidia.com/gpu: 4` さらなる詳細は[クォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 ## ストレージのリソースクォータ 特定の名前空間において[ストレージリソース](/ja/docs/concepts/storage/persistent-volumes/)の総数に上限をかけることができます。 さらに、関連するストレージクラスに基づいて、ストレージリソースの消費量に上限をかけることもできます。 | リソース名 | 説明 | | --------------------- | ----------------------------------------------------------- | | `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 | | `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | | `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 | | `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | 例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。 * `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` * `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` Kubernetes v1.8において、ローカルのエフェメラルストレージに対するリソースクォータのサポートがα版の機能として追加されました。 | リソース名 | 説明 | | ------------------------------- |----------------------------------------------------------- | | `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | | `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | ## オブジェクト数に対するクォータ Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 * `count/<resource>.<group>` オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。 * `count/persistentvolumeclaims` * `count/services` * `count/secrets` * `count/configmaps` * `count/replicationcontrollers` * `count/deployments.apps` * `count/replicasets.apps` * `count/statefulsets.apps` * `count/jobs.batch` * `count/cronjobs.batch` * `count/deployments.extensions` Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 `count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 下記のタイプのリソースがサポートされています。 | リソース名 | 説明 | | ------------------------------- | ------------------------------------------------- | | `configmaps` | 名前空間内で存在可能なConfigMapの総数。  | | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。  | | `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | | `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | | `services` | 名前空間内で存在可能なServiceの総数。 | | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | | `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | | `secrets` | 名前空間内で存在可能なSecretの総数。 | 例えば、`pods`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`pods`のリソースクォータを名前空間に設定したい場合があります。 ## クォータのスコープについて 各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。 | スコープ | 説明 | | ----- | ----------- | | `Terminating` | `.spec.activeDeadlineSeconds >= 0`であるPodに一致します。 | | `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 | | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | `BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods` `Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: * `cpu` * `limits.cpu` * `limits.memory` * `memory` * `pods` * `requests.cpu` * `requests.memory` ### PriorityClass毎のリソースクォータ {{< feature-state for_k8s_version="1.12" state="beta" >}} Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 - クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。 - 1つのリソースクォータのオブジェクトは優先度毎に作成されます。 下記のYAMLを`quota.yml`というファイルに保存します。 ```yaml apiVersion: v1 kind: List items: - apiVersion: v1 kind: ResourceQuota metadata: name: pods-high spec: hard: cpu: "1000" memory: 200Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["high"] - apiVersion: v1 kind: ResourceQuota metadata: name: pods-medium spec: hard: cpu: "10" memory: 20Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["medium"] - apiVersion: v1 kind: ResourceQuota metadata: name: pods-low spec: hard: cpu: "5" memory: 10Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["low"] ``` `kubectl create`を実行してYAMLの内容を適用します。 ```shell kubectl create -f ./quota.yml ``` ```shell resourcequota/pods-high created resourcequota/pods-medium created resourcequota/pods-low created ``` `kubectl describe quota`を実行して`Used`クォータが`0`であることを確認します。 ```shell kubectl describe quota ``` ```shell Name:       pods-high Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         0     1k memory      0     200Gi pods        0     10 Name:       pods-low Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         0     5 memory      0     10Gi pods        0     10 Name:       pods-medium Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         0     10 memory      0     20Gi pods        0     10 ``` プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに保存します。 ```yaml apiVersion: v1 kind: Pod metadata: name: high-priority spec: containers: - name: high-priority image: ubuntu command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"] resources: requests: memory: "10Gi" cpu: "500m" limits: memory: "10Gi" cpu: "500m" priorityClassName: high ``` `kubectl create`でマニフェストを適用します。 ```shell kubectl create -f ./high-priority-pod.yml ``` `pods-high`という名前のプライオリティーが"high"のクォータにおける"Used"項目の値が変更され、それ以外の2つの値は変更されていないことを確認してください。 ```shell kubectl describe quota ``` ```shell Name:       pods-high Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         500m  1k memory      10Gi  200Gi pods        1     10 Name:       pods-low Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         0     5 memory      0     10Gi pods        0     10 Name:       pods-medium Namespace:  default Resource    Used  Hard --------    ----  ---- cpu         0     10 memory      0     20Gi pods        0     10 ``` `scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。 * `In` * `NotIn` * `Exist` * `DoesNotExist` ## リクエスト vs リミット コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。 ## クォータの確認と設定 {#viewing-and-setting-quotas} kubectlでは、クォータの作成、更新、確認をサポートしています。 ```shell kubectl create namespace myspace ``` ```shell cat <<EOF > compute-resources.yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi requests.nvidia.com/gpu: 4 EOF ``` ```shell kubectl create -f ./compute-resources.yaml --namespace=myspace ``` ```shell cat <<EOF > object-counts.yaml apiVersion: v1 kind: ResourceQuota metadata: name: object-counts spec: hard: configmaps: "10" persistentvolumeclaims: "4" pods: "4" replicationcontrollers: "20" secrets: "10" services: "10" services.loadbalancers: "2" EOF ``` ```shell kubectl create -f ./object-counts.yaml --namespace=myspace ``` ```shell kubectl get quota --namespace=myspace ``` ```shell NAME                    AGE compute-resources       30s object-counts           32s ``` ```shell kubectl describe quota compute-resources --namespace=myspace ``` ```shell Name:                    compute-resources Namespace:               myspace Resource                 Used  Hard --------                 ----  ---- limits.cpu               0     2 limits.memory            0     2Gi requests.cpu             0     1 requests.memory          0     1Gi requests.nvidia.com/gpu  0     4 ``` ```shell kubectl describe quota object-counts --namespace=myspace ``` ```shell Name:                   object-counts Namespace:              myspace Resource                Used    Hard --------                ----    ---- configmaps              0       10 persistentvolumeclaims  0       4 pods                    0       4 replicationcontrollers  0       20 secrets                 1       10 services                0       10 services.loadbalancers  0       2 ``` また、kubectlは`count/<resource>.<group>`というシンタックスを用いることにより、名前空間に依存した全ての主要なリソースに対するオブジェクト数のクォータをサポートしています。 ```shell kubectl create namespace myspace ``` ```shell kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace ``` ```shell kubectl run nginx --image=nginx --replicas=2 --namespace=myspace ``` ```shell kubectl describe quota --namespace=myspace ``` ```shell Name:                         test Namespace:                    myspace Resource                      Used  Hard --------                      ----  ---- count/deployments.extensions  1     2 count/pods                    2     3 count/replicasets.extensions  1     4 count/secrets                 1     4 ``` ## クォータとクラスター容量 `ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。 下記のようなより複雑なポリシーが必要な状況があります。 - 複数チーム間でクラスターリソースの総量を分けあう。 - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。 - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。 このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 ## デフォルトで優先度クラスの消費を制限する 例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。 このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。 これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。 {{< tabs name="example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: "ResourceQuota" configuration: apiVersion: apiserver.config.k8s.io/v1 kind: ResourceQuotaConfiguration limitedResources: - resource: pods matchScopes: - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` {{% /tab %}} {{% tab name="apiserver.k8s.io/v1alpha1" %}} ```yaml # v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。 apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: "ResourceQuota" configuration: # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。 apiVersion: resourcequota.admission.k8s.io/v1beta1 kind: Configuration limitedResources: - resource: pods matchScopes: - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` {{% /tab %}} {{< /tabs >}} なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。 ```yaml scopeSelector: matchExpressions: - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。 ## 例 [リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。 {{% /capture %}} {{% capture whatsnext %}} さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 {{% /capture %}} </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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed This document is not translated in Japanese. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Copy a file from en contents to concepts/policy/resource- and translate it into Japanese.
/assign /language-ja
/language ja
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
/assign
/unassign
/close
Closing this issue. <detailsIn response to : /close 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: <hr> <del> - **resource** (string), 必选 </del> <ins> - **resource** (string)，必选 </ins> <!-- Required: resource to select --> 必选：选择的资源

Hello, I noticed some punctuation errors on page /language zh
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
/retitle Punctuation errors on /remove-kind feature /kind bug


Question: * Configure `kubectl` to communicate with your Kubernetes API server. For instructions, see the documentation for your cloud provider. ## {{% heading "objectives" %}} * Run five instances of a Hello World application. * Create a Service object that exposes an external IP address. * Use the Service object to access the running application. <!-- lessoncontent --> ## Creating a service for an application running in five pods

This is a Bug Report There are some commands in the tutorial that are missing code formatting. This is a request to update those commands and remove any extra lines in the page. <!--Required Information--Problem: The tutorial has commands that are not formatted as code. For example, kubectl get deployments hello-world Add code formatting: Proposed Solution: Identify the commands that are missing code formatting. Add the code formatting to the commands. Clean up any extra lines in the page. Page to Update: This is a good issue for a first time contributor. If you need more information, feel free to ask in this issue. It is a good idea to build your changes locally.
/good-first-issue
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 : /good-first-issue 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
/triage accepted /language en Thanks - another good spot
Is this PR currently being worked on?
it seems already formatted, right?
I don't see any issues with the page as well, and it looks like it was last modified July 27, 2020 at 4:18. Are we missing something?
Let me look. I'd like a first time contributor to work on this issue.
The page renders correctly, however, it would be helpful to clean up the formatting of the page such as extra lines and spaces. Also, the page should use code blocks around any commands (instead of indentation). Let me know if you need more information. Thanks!
i'm a first timer in kubernetes. But i saw nothing wrong in formatting code nor indentation. Only i think there is missing some instruction in creating apps. Should be better to follow Just my 2cent. wdyt?
/assign


Question: the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. Processes within a privileged container get almost the same privileges that are available to processes outside a container. --> <del> ## 容器的特权模式     {#rivileged-mode-for-containers} </del> <ins> ## 容器的特权模式     {#privileged-mode-for-containers} </ins> Pod 中的任何容器都可以使用容器规约中的 [安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的

Hi, the header url of Privileged mode for containers in Chinese version doc misses a . Best regards.
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
/kind bug /language zh
/assign /retitle [zh] Wrong custom heading ID in zh/docs/concepts/workloads/pods


Question: * [Node Metrics Data](/docs/reference/instrumentation/node-metrics). <del> * [CRI Pod & Container Metrics](/docs/reference/instrumentation/cri-pod-container-metrics). </del>  No newline at end of file <ins> * [CRI Pod & Container Metrics](/docs/reference/instrumentation/cri-pod-container-metrics). </ins>

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: does not link in the page content to every item that we can find (on a desktop browser) in the left-hand navigation for that section. Proposed Solution: Add more links into (look at the left nav to see which ones they are) Page to Update: /language en /priority backlog /good-first-issue /triage accepted :information_source: have you already worked on an issue? Please save this for a contributor who has not.
This request has been marked as suitable for new contributors. 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: does not link in the page content to every item that we can find (on a desktop browser) in the left-hand navigation for that section. Add more links into (look at the left nav to see which ones they are) /good-first-issue /triage accepted 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
I want to work on this. /assign
Pr to fix this issue


Question: <!-- Now create the secrets using the file: --> <del> 现在使用文件创建 secrets： </del> <ins> 现在使用文件创建 Secrets： </ins> ```shell kubectl apply -f nginxsecrets.yaml

Nginx https 404
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 It sounds like you wanted to provide feedback about a web page. Which web page was that? /triage needs-information


Question: If you're already using `minikube` for your development process: ```bash <del> minikube service frontend </del> <ins> minikube service web-tcp </ins> ``` Otherwise, let's look up what IP your service is using! ```sh <del> kubectl describe svc frontend </del> <ins> kubectl describe svc web-tcp </ins> ``` ```none <del> Name:                     frontend-tcp Namespace:                default Labels:                   io.kompose.service=frontend-tcp Annotations:              kompose.cmd: kompose convert kompose.service.type: LoadBalancer kompose.version: 1.26.0 (40646f47) Selector:                 io.kompose.service=frontend Type:                     LoadBalancer IP Family Policy:         SingleStack IP Families:              IPv4 IP:                       10.43.67.174 IPs:                      10.43.67.174 Port:                     80  80/TCP TargetPort:               80/TCP NodePort:                 80  31254/TCP Endpoints:                10.42.0.25:80 Session Affinity:         None External Traffic Policy:  Cluster Events: Type    Reason                Age   From                Message ----    ------                ----  ----                ------- Normal  EnsuringLoadBalancer  62s   service-controller  Ensuring load balancer Normal  AppliedDaemonSet      62s   service-controller  Applied LoadBalancer DaemonSet kube-system/svclb-frontend-tcp-9362d276 </del> <ins> Name:                     web-tcp Namespace:                default Labels:                   io.kompose.service=web-tcp Annotations:              kompose.cmd: kompose convert kompose.service.type: LoadBalancer kompose.version: 1.33.0 (3ce457399) Selector:                 io.kompose.service=web Type:                     LoadBalancer IP Family Policy:         SingleStack IP Families:              IPv4 IP:                       10.102.30.3 IPs:                      10.102.30.3 Port:                     8080  8080/TCP TargetPort:               8080/TCP NodePort:                 8080  31624/TCP Endpoints:                10.244.0.5:8080 Session Affinity:         None External Traffic Policy:  Cluster Events:                   <none> </ins> ``` If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.

This demonstration for converting docker compose to a kubernetes demo is referencing some old docker image / manifest types that are no longer supported and I think they fail to build, this breaks the demo workflow. Following the guide as described isn't working... To test, running a confirms this sample yaml file is using an obsolete tag, and more so the container images aren't compliant. Running the kompose conversion & apply works, but the application never shows up when attempting to curl (using for the , or even just changing to for local dev). trying to get the minikube service (with minikube tunnel running), it fails with the following: Checking the pod confirms the image pull fails with an : Same when trying to curl I believe the maintainers need to kindly update the Docker Compose yaml sample file provided to reflect newer docker images! Thanks in advance for this helpful demonstration
This refers specifically to the information contained here: which was last updated funny enough on my birthday, February 5th, 2023. Probably just needs to be updated given newer Dockerfile support versions / manifests
It was also I think necessary to add the Ingress add-on for minikube
/language en
maybe the updated version of this demo is here: as it looks like that docker sample does in fact build with docker. Running kompose convert though doesn't work on that.

Probably just some divergence
/kind bug
/retitle Stale page "Translate a Docker Compose File to Kubernetes Resources"
/triage accepted
/assign
Issues with image pull: Warning Failed 17m (x4 over 19m) kubelet Failed to pull image "": Error response from daemon: manifest for not found: manifest unknown: Failed to fetch "v4" from request "/v2/google-samples/gb-frontend/manifests/v4" Changes to commands/files: #Upgrade to v1.33 curl -L -o kompose #Update to docker- based on kompose site examples At services: redis-leader: containername: redis-leader image: redis ports: "6379" redis-replica: containername: redis-replica image: redis ports: "6379" command: redis-server --replicaof redis-leader 6379 --dir /tmp web: containername: web image: ports: "8080:8080" environment: GETHOSTS_FROM=dns labels: LoadBalancer #Apply new yaml files kubectl apply -f redis-leader-, redis-replica-, web-, redis-leader-,redis-replica-,web-tcp- Changes to Output: INFO Kubernetes file "redis-leader-" created INFO Kubernetes file "redis-replica-" created INFO Kubernetes file "web-tcp-" created INFO Kubernetes file "redis-leader-" created INFO Kubernetes file "redis-replica-" created INFO Kubernetes file "web-" created created created created service/redis-leader created service/redis-replica created service/web-tcp created Changes to Testing Services: minikube service web-tcp Starting tunnel for service web-tcp. Opening service default/web-tcp in default browser... Because you are using a Docker driver on linux, the terminal needs to be open to run it.

kubectl describe service web-tcp Name: web-tcp Namespace: default Labels: io.kompose.service=web-tcp Annotations: kompose convert LoadBalancer kompose.version: 1.33.0 () Selector: io.kompose.service=web Type: LoadBalancer IP Family Policy: SingleStack IP Families: IPv4 IP: 10.102.30.3 IPs: 10.102.30.3 Port: 8080 8080/TCP TargetPort: 8080/TCP NodePort: 8080 /TCP Endpoints: 10.244.0.5:8080 Session Affinity: None External Traffic Policy: Cluster Events: <none


Question: <ins> --- title: "Kubeadm" weight: 10 no_list: true content_type: concept card: name: reference weight: 40 --- <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">kubeadmは、`kubeadm init`や`kubeadm join`などのコマンドを提供するツールで、Kubernetesクラスターを構築する上でのベストプラクティスを反映した「近道」を提供するものとして開発されました。 kubeadmは実用最小限のクラスターをセットアップするための処理を実行します。設計上、kubeadmはブートストラップのみを行い、マシンのプロビジョニングは行いません。同様に、Kubernetesダッシュボード、モニタリングソリューション、クラウド向けのアドオンなど、あれば便利でもなくても支障のない各種アドオンのインストールも範囲外です。 その代わりに、高度な特定用途向けのツールはkubeadmをベースに構築されることが期待されています。理想的には、すべてのデプロイのベースとしてkubeadmを使用することで、適合テストに通るクラスターを簡単に作れるようになります。 ## インストール方法 kubeadmをインストールするには、[インストールガイド](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm)を参照してください。 ## {{% heading "whatsnext" %}} * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init)を使用して、Kubernetesのコントロールプレーンノードをブートストラップする * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join)を使用して、Kubernetesのワーカーノードをブートストラップし、クラスターに参加させる * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade)で、Kubernetesクラスターを新しいバージョンにアップグレードする * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config)を使用して、kubeadm v1.7.x以前で初期化されたクラスターを、`kubeadm upgrade`を利用できるように設定する * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token)で、`kubeadm join`のためのトークンを管理する * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset)を使用して、`kubeadm init`または`kubeadm join`でホストに行われた変更を元に戻す * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version)で、kubeadmのバージョンを表示する * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha)で、コミュニティからのフィードバックを集めるために有効にされた各種機能を試用する </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


Question: cat ./kubectl-whoami ``` 次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。 <del> The next few examples assume that you already made `kubectl-whoami` have the following contents: </del> ```shell #!/bin/bash

This is a Bug Report <!--Required Information--Problem: There are both a raw untranslated sentence and its translated sentence. Proposed Solution: remove this raw sentence Page to Update:
/assign
/triage accepted


Question: locality, inter-workload interference, and so on. --> 在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 <del> 亲和以及反亲和要求、数据局域性、负载间的干扰等等。 </del> <ins> 亲和以及反亲和要求、数据局部性、负载间的干扰等等。 </ins> <!-- ## Scheduling with kube-scheduler {#kube-scheduler-implementation}

originalFactors that need to be taken into account for scheduling decisions include individual and collective resource requirements, hardware / software / policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and so on. translation// "data locality" should translate to "", not "".
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
/language zh
translates it as "". Generally speaking, in computer terminology, we translate this as "". Does this page need to be changed Request for advice
“”“”“”“”
PR


Question: <ins> apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: ipFamilyPolicy: PreferDualStack ipFamilies: - IPv6 - IPv4 selector: app: MyApp ports: - protocol: TCP port: 80 </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
/triage accepted