Question: max-width: 80%; border: 1px solid rgb(222, 226, 230); border-radius: 5px; <ins> margin-bottom: 1rem; padding-top: 1rem; padding-bottom: 1rem; // mermaid diagram - sequence diagram .actor { fill: #326ce5 !important; } text.actor { font-size: 18px !important; stroke: white !important; fill: white !important; } .activation0 { fill: #c9e9ec !important; } </ins> } /* HEADER */

This is a Feature Request What would you like to be Replace the sequence diagram on with the one by . This is the follow-up of . Why is this needed There are several pros to use mermaid to draw the sequence diagram: mermaid format is more readable easy to modify better styling Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/assign
/kind cleanup /language en /triage accepted /priority backlog


Question: cid: docsHome layout: docsportal_home class: gridPage gridPageHome <del> linkTitle: "Home" </del> <ins> linkTitle: "Documentation" </ins> main_menu: true weight: 10 hide_feedback: true

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: "Home" button at footer is linked to docs home page instead of K8s site home page Proposed Solution: Either that button should be linked to K8s site home page or that button should be renamed to "Documentation" instead of "Home" ! <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Thanks I'd change it to read “Documentation”. /priority backlog /help /triage accepted /language en
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 : Thanks I'd change it to read “Documentation”. /priority backlog /help /triage accepted /language en 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: <ins> --- title: 常见的标签、注解和污点 content_type: concept weight: 20 --- <!-- --- title: Well-Known Labels, Annotations and Taints content_type: concept weight: 20 --- --> <!-- overview --> <!-- Kubernetes reserves all labels and annotations in the kubernetes.io namespace. This document serves both as a reference to the values and as a coordination point for assigning values. --> Kubernetes 预留命名空间 kubernetes.io 用于所有的标签和注解。 本文档有两个作用，一是作为可用值的参考，二是作为赋值的协调点。 <!-- body --> ## kubernetes.io/arch 示例：`kubernetes.io/arch=amd64` 用于：Node <!-- The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be handy if you are mixing arm and x86 nodes. --> Kubelet 用 Go 定义的 `runtime.GOARCH` 生成该标签的键值。在混合使用 arm 和 x86 节点的场景中，此键值可以带来极大便利。 ## kubernetes.io/os 示例：`kubernetes.io/os=linux` 用于：Node <!-- The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems in your cluster (for example: mixing Linux and Windows nodes). --> Kubelet 用 Go 定义的 `runtime.GOOS` 生成该标签的键值。在混合使用异构操作系统场景下（例如：混合使用 Linux 和 Windows 节点），此键值可以带来极大便利。 ## beta.kubernetes.io/arch (deprecated) <!-- This label has been deprecated. Please use `kubernetes.io/arch` instead. --> 此标签已被弃用，取而代之的是 `kubernetes.io/arch`. ## beta.kubernetes.io/os (deprecated) <!-- This label has been deprecated. Please use `kubernetes.io/os` instead. --> 此标签已被弃用，取而代之的是 `kubernetes.io/os`. ## kubernetes.io/hostname {#kubernetesiohostname} 示例：`kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` 用于：Node <!-- The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`. This label is also used as part of the topology hierarchy.  See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information. --> Kubelet 用主机名生成此标签。需要注意的是主机名可修改，这是把“实际的”主机名通过参数 `--hostname-override` 传给 `kubelet` 实现的。 此标签也可用做拓扑层次的一个部分。更多信息参见[topology.kubernetes.io/zone](#topologykubernetesiozone)。 ## beta.kubernetes.io/instance-type (deprecated) {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). --> 从 v1.17 起，此标签被弃用，取而代之的是 [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). {{< /note >}} ## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} 示例：`node.kubernetes.io/instance-type=m3.medium` 用于：Node <!-- The Kubelet populates this with the instance type as defined by the `cloudprovider`. This will be set only if you are using a `cloudprovider`. This setting is handy if you want to target certain workloads to certain instance types, but typically you want to rely on the Kubernetes scheduler to perform resource-based scheduling. You should aim to schedule based on properties rather than on instance types (for example: require a GPU, instead of requiring a `g2.2xlarge`). --> Kubelet 用 `cloudprovider` 定义的实例类型生成此标签。 所以只有用到 `cloudprovider` 的场合，才会设置此标签。 此标签非常有用，特别是在你希望把特定工作负载打到特定实例类型的时候，但更常见的调度方法是基于 Kubernetes 调度器来执行基于资源的调度。 你应该聚焦于使用基于属性的调度方式，而尽量不要依赖实例类型（例如：应该申请一个 GPU，而不是 `g2.2xlarge`）。 ## failure-domain.beta.kubernetes.io/region (deprecated) {#failure-domainbetakubernetesioregion} 参见 [topology.kubernetes.io/region](#topologykubernetesioregion). {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion). --> 从 v1.17 开始，此标签被弃用，取而代之的是 [topology.kubernetes.io/region](#topologykubernetesioregion). {{< /note >}} ## failure-domain.beta.kubernetes.io/zone (deprecated) {#failure-domainbetakubernetesiozone} 参见 [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). --> 从 v1.17 开始，此标签被弃用，取而代之的是 [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}} ## topology.kubernetes.io/region {#topologykubernetesioregion} 示例 `topology.kubernetes.io/region=us-east-1` 参见 [topology.kubernetes.io/zone](#topologykubernetesiozone). ## topology.kubernetes.io/zone {#topologykubernetesiozone} 示例: `topology.kubernetes.io/zone=us-east-1c` 用于：Node, PersistentVolume <!-- On Node: The `kubelet` or the external `cloud-controller-manager` populates this with the information as provided by the `cloudprovider`.  This will be set only if you are using a `cloudprovider`. However, you should consider setting this on nodes if it makes sense in your topology. On PersistentVolume: topology-aware volume provisioners will automatically set node affinity constraints on `PersistentVolumes`. --> Node 场景：`kubelet` 或外部的 `cloud-controller-manager` 用 `cloudprovider` 提供的信息生成此标签。 所以只有在用到 `cloudprovider` 的场景下，此标签才会被设置。 但如果此标签在你的拓扑中有意义，你也可以考虑在 node 上设置它。 PersistentVolume 场景：拓扑自感知的卷制备程序将在 `PersistentVolumes` 上自动设置节点亲和性限制。 <!-- A zone represents a logical failure domain.  It is common for Kubernetes clusters to span multiple zones for increased availability.  While the exact definition of a zone is left to infrastructure implementations, common properties of a zone include very low network latency within a zone, no-cost network traffic within a zone, and failure independence from other zones.  For example, nodes within a zone might share a network switch, but nodes in different zones should not. --> 一个可用区（zone）表示一个逻辑故障域。Kubernetes 集群通常会跨越多个可用区以提高可用性。 虽然可用区的确切定义留给基础设施来决定，但可用区常见的属性包括：可用区内的网络延迟非常低，可用区内的网络通讯没成本，独立于其他可用区的故障域。 例如，一个可用区中的节点可以共享交换机，但不同可用区则不会。 <!-- A region represents a larger domain, made up of one or more zones.  It is uncommon for Kubernetes clusters to span multiple regions,  While the exact definition of a zone or region is left to infrastructure implementations, common properties of a region include higher network latency between them than within them, non-zero cost for network traffic between them, and failure independence from other zones or regions.  For example, nodes within a region might share power infrastructure (e.g. a UPS or generator), but nodes in different regions typically would not. --> 一个地区（region）表示一个更大的域，由一个到多个可用区组成。对于 Kubernetes 来说，跨越多个地区的集群很罕见。 虽然可用区和地区的确切定义留给基础设施来决定，但地区的常见属性包括：地区间比地区内更高的网络延迟，地区间网络流量更高的成本，独立于其他可用区或是地区的故障域。例如，一个地区内的节点可以共享电力基础设施（例如 UPS 或发电机），但不同地区内的节点显然不会。 <!-- Kubernetes makes a few assumptions about the structure of zones and regions: 1) regions and zones are hierarchical: zones are strict subsets of regions and no zone can be in 2 regions 2) zone names are unique across regions; for example region "africa-east-1" might be comprised of zones "africa-east-1a" and "africa-east-1b" --> Kubernetes 对可用区和地区的结构做出一些假设： 1）地区和可用区是层次化的：可用区是地区的严格子集，任何可用区都不能再 2 个地区中出现。 2）可用区名字在地区中独一无二：例如地区 "africa-east-1" 可由可用区 "africa-east-1a" 和 "africa-east-1b" 构成。 <!-- It should be safe to assume that topology labels do not change.  Even though labels are strictly mutable, consumers of them can assume that a given node is not going to be moved between zones without being destroyed and recreated. --> 你可以安全的假定拓扑类的标签是固定不变的。即使标签严格来说是可变的，但使用者依然可以假定一个节点只有通过销毁、重建的方式，才能在可用区间移动。 <!-- Kubernetes can use this information in various ways.  For example, the scheduler automatically tries to spread the Pods in a ReplicaSet across nodes in a single-zone cluster (to reduce the impact of node failures, see [kubernetes.io/hostname](#kubernetesiohostname)). With multiple-zone clusters, this spreading behavior also applies to zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_. --> Kubernetes 能以多种方式使用这些信息。 例如，调度器自动地尝试将 ReplicaSet 中的 Pod 打散在单可用区集群的不同节点上（以减少节点故障的影响，参见[kubernetes.io/hostname](#kubernetesiohostname)）。 在多可用区的集群中，这类打散分布的行为也会应用到可用区（以减少可用区故障的影响）。 做到这一点靠的是 _SelectorSpreadPriority_。 <!-- _SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading. --> _SelectorSpreadPriority_ 是一种最大能力分配方法（best effort）。如果集群中的可用区是异构的（例如：不同数量的节点，不同类型的节点，或不同的 Pod 资源需求），这种分配方法可以防止平均分配 Pod 到可用区。如果需要，你可以用同构的可用区（相同数量和类型的节点）来减少潜在的不平衡分布。 <!-- The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones. --> 调度器（通过 _VolumeZonePredicate_ 的预测）也会保障声明了某卷的 Pod 只能分配到该卷相同的可用区。 卷不支持跨可用区挂载。 <!-- If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. --> 如果 `PersistentVolumeLabel` 不支持给 PersistentVolume 自动打标签，你可以考虑手动加标签（或增加 `PersistentVolumeLabel` 支持）。 有了 `PersistentVolumeLabel`，调度器可以防止 Pod 挂载不同可用区中的卷。 如果你的基础架构没有此限制，那你根本就没有必要给卷增加 zone 标签。 ## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} 示例: `node.kubernetes.io/windows-build=10.0.17763` 用于：Node <!-- When the kubelet is running on Microsoft Windows, it automatically labels its node to record the version of Windows Server in use. The label's value is in the format "MajorVersion.MinorVersion.BuildNumber". --> 当 kubelet 运行于 Microsoft Windows，它给节点自动打标签，以记录 Windows Server 的版本。 标签值的格式为 "主版本.次版本.构建号" ## service.kubernetes.io/headless {#servicekubernetesioheadless} 示例：`service.kubernetes.io/headless=""` 用于：Service <!-- The control plane adds this label to an Endpoints object when the owning Service is headless. --> 在无头（headless）服务的场景下，控制平面为 Endpoint 对象添加此标签。 ## kubernetes.io/service-name {#kubernetesioservice-name} 示例：`kubernetes.io/service-name="nginx"` 用于：Service <!-- Kubernetes uses this label to differentiate multiple Services. Used currently for `ELB`(Elastic Load Balancer) only. --> Kubernetes 用此标签区分多个服务。当前仅用于 `ELB`(Elastic Load Balancer)。 ## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} 示例：`endpointslice.kubernetes.io/managed-by="controller"` 用于：EndpointSlices <!-- The label is used to indicate the controller or entity that manages an EndpointSlice. This label aims to enable different EndpointSlice objects to be managed by different controllers or entities within the same cluster. --> 此标签用来指向管理 EndpointSlice 的控制器或实体。 此标签的目的是用集群中不同的控制器或实体来管理不同的 EndpointSlice。 ## endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror} 示例：`endpointslice.kubernetes.io/skip-mirror="true"` 用于：Endpoints <!-- The label can be set to `"true"` on an Endpoints resource to indicate that the EndpointSliceMirroring controller should not mirror this resource with EndpointSlices. --> 此标签在 Endpoints 资源上设为 `"true"` 指示 EndpointSliceMirroring 控制器不要镜像此 EndpointSlices 资源。 ## service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name} 示例：`service.kubernetes.io/service-proxy-name="foo-bar"` 用于：Service <!-- The kube-proxy has this label for custom proxy, which delegates service control to custom proxy. --> kube-proxy 把此标签用于客户代理，将服务控制委托给客户代理。 ## experimental.windows.kubernetes.io/isolation-type 示例：`experimental.windows.kubernetes.io/isolation-type: "hyperv"` 用于：Pod <!-- The annotation is used to run Windows containers with Hyper-V isolation. To use Hyper-V isolation feature and create a Hyper-V isolated container, the kubelet should be started with feature gates HyperVContainer=true and the Pod should include the annotation experimental.windows.kubernetes.io/isolation-type=hyperv. < note > You can only set this annotation on Pods that have a single container. < /note > --> 此注解用于运行 Hyper-V 隔离的 Windows 容器。 要使用 Hyper-V 隔离特性，并创建  Hyper-V 隔离容器，kubelet 应该用特性门控 HyperVContainer=true 来启动，并且 Pod 应该包含注解 `experimental.windows.kubernetes.io/isolation-type=hyperv`。 {{< note >}} 你只能在单容器 Pod 上设置此注解。 {{< /note >}} ## ingressclass.kubernetes.io/is-default-class 示例：`ingressclass.kubernetes.io/is-default-class: "true"` 用于：IngressClass <!-- When a single IngressClass resource has this annotation set to `"true"`, new Ingress resource without a class specified will be assigned this default class. --> 当唯一的 IngressClass 资源将此注解的值设为 "true"，没有指定类型的新 Ingress 资源将使用此默认类型。 ## kubernetes.io/ingress.class (deprecated) {{< note >}} <!-- Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. --> 从 v1.18 开始，此注解被弃用，取而代之的是 `spec.ingressClassName`。 {{< /note >}} ## alpha.kubernetes.io/provided-node-ip 示例：`alpha.kubernetes.io/provided-node-ip: "10.0.0.1"` 用于：Node <!-- The kubelet can set this annotation on a Node to denote its configured IPv4 address. When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager. **The taints listed below are always used on Nodes** --> kubectl 在 Node 上设置此注解，表示它的 IPv4 地址。 当 kubectl 由外部的云供应商启动时，在 Node 上设置此注解，表示由命令行标记(`--node-ip`)设置的 IP 地址。 cloud-controller-manager 向云供应商验证此 IP 是否有效。 **以下列出的污点只能用于 Node** ## node.kubernetes.io/not-ready 示例：`node.kubernetes.io/not-ready:NoExecute` <!-- The node controller detects whether a node is ready by monitoring its health and adds or removes this taint accordingly. --> 节点控制器通过健康监控来检测节点是否就绪，并据此添加/删除此污点。 ## node.kubernetes.io/unreachable 示例：`node.kubernetes.io/unreachable:NoExecute` <!-- The node controller adds the taint to a node corresponding to the [NodeCondition](/docs/concepts/architecture/nodes/#condition) `Ready` being `Unknown`. --> 如果 [NodeCondition](/docs/concepts/architecture/nodes/#condition) 的 `Ready` 键值为 `Unknown`，节点控制器将添加污点到 node。 ## node.kubernetes.io/unschedulable 示例：`node.kubernetes.io/unschedulable:NoSchedule` <!-- The taint will be added to a node when initializing the node to avoid race condition. --> 当初始化节点时，添加此污点，来避免竟态的发生。 ## node.kubernetes.io/memory-pressure 示例：`node.kubernetes.io/memory-pressure:NoSchedule` <!-- The kubelet detects memory pressure based on `memory.available` and `allocatableMemory.available` observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed. --> kubelet 依据节点上观测到的 `memory.available` 和 `allocatableMemory.available` 来检测内存压力。 用观测值对比 kubelet 设置的阈值，以判断节点状态和污点是否可以被添加/移除。 ## node.kubernetes.io/disk-pressure 示例：`node.kubernetes.io/disk-pressure:NoSchedule` <!-- The kubelet detects disk pressure based on `imagefs.available`, `imagefs.inodesFree`, `nodefs.available` and `nodefs.inodesFree`(Linux only) observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed. --> kubelet 依据节点上观测到的 `imagefs.available`、`imagefs.inodesFree`、`nodefs.available` 和 `nodefs.inodesFree`(仅 Linux) 来判断磁盘压力。 用观测值对比 kubelet 设置的阈值，以确定节点状态和污点是否可以被添加/移除。 ## node.kubernetes.io/network-unavailable 示例：`node.kubernetes.io/network-unavailable:NoSchedule` <!-- This is initially set by the kubelet when the cloud provider used indicates a requirement for additional network configuration. Only when the route on the cloud is configured properly will the taint be removed by the cloud provider. --> 它初始由 kubectl 设置，云供应商用它来指示对额外网络配置的需求。 仅当云中的路由器配置妥当后，云供应商才会移除此污点。 ## node.kubernetes.io/pid-pressure 示例：`node.kubernetes.io/pid-pressure:NoSchedule` <!-- The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PIDs consumed by Kubernetes on a node to get the number of available PIDs that referred to as the `pid.available` metric. The metric is then compared to the corresponding threshold that can be set on the kubelet to determine if the node condition and taint should be added/removed. --> kubelet 检查 `/proc/sys/kernel/pid_max` 尺寸的 D 值（D-value），以及节点上 Kubernetes 消耗掉的 PID，以获取可用的 PID 数量，此数量可通过指标 `pid.available` 得到。 然后用此指标对比 kubelet 设置的阈值，以确定节点状态和污点是否可以被添加/移除。 ## node.cloudprovider.kubernetes.io/uninitialized 示例：`node.cloudprovider.kubernetes.io/uninitialized:NoSchedule` <!-- Sets this taint on a node to mark it as unusable, when kubelet is started with the "external" cloud provider, until a controller from the cloud-controller-manager initializes this node, and then removes the taint. --> 当 kubelet 由外部云供应商启动时，在节点上设置此污点以标记节点不可用，直到一个 cloud-controller-manager 控制器初始化此节点之后，才会移除此污点。 ## node.cloudprovider.kubernetes.io/shutdown 示例：`node.cloudprovider.kubernetes.io/shutdown:NoSchedule` <!-- If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`. --> 如果一个云供应商的节点被指定为关机状态，节点被打上污点 `node.cloudprovider.kubernetes.io/shutdown`，污点的影响为 `NoSchedule`。 </ins>

This is a Feature Request translate content/en/docs/tasks/tools/install-kubectl- into Chinese What would you like to be content/zh/docs/reference/labels-annotations- /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: lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels <del> /etc/..2982_06_02_21_47_53.299460680: </del> <ins> /etc/podinfo/..2982_06_02_21_47_53.299460680: </ins> total 8 -rw-r--r--  ... Feb  6 21:47 annotations -rw-r--r--  ... Feb  6 21:47 labels

the file labels and annotations should be in the directory /etc/podinfo not /etc !
Hi What's the URL of the web page that isn't right? /triage needs-information
/triage accepted
/assign


Question: <ins> --- title: cAdvisor id: cadvisor date: 2021-12-09 full_link: https://github.com/google/cadvisor/ short_description: > Tool that provides understanding of the resource usage and perfomance characteristics for containers aka: tags: - tool --- cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running {{< glossary_tooltip text="containers" term_id="container" >}}. <!--more--> It is a running daemon that collects, aggregates, processes, and exports information about running containers. Specifically, for each container it keeps resource isolation parameters, historical resource usage, histograms of complete historical resource usage and network statistics. This data is exported by container and machine-wide. </ins>

Kubernetes manages the lifecycle of all images through its image manager, which is part of the kubelet, with the cooperation of cadvisor. Needs pop up note on cadvisor
/kind feature /language en I think by pop up note, you're talking about a . Good suggestion, thanks! To fix this, someone should: add a new glossary entry read for context look in copy an existing item to use as a template (make sure to change everything that needs changing) add a glossary tooltip for cadvisor to /help /triage accepted
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 /language en add a new glossary entry /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
/priority backlog


Question: {{< feature-state for_k8s_version="v1.26" state="stable" >}} <del> In Windows, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod) by setting the `windowsOptions.hostProcess` flag on the security context of the pod spec. All containers in these </del> <ins> In Windows, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod) by setting the `windowsOptions.hostProcess` flag on the security context of the pod spec. All containers in these </ins> pods must run as Windows HostProcess containers. HostProcess pods run directly on the host and can also be used <del> to perform administrative tasks as is done with Linux privileged containers. In order to use this feature, the `WindowsHostProcessContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled. </del> <ins> to perform administrative tasks as is done with Linux privileged containers. </ins> ## Static Pods

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 However, this feature is in fact GA in v1.26 and cannot be disabled, so we should tweak that wording. Proposed Solution: Tweak that wording. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 26 (unreleased at time issue was filed) Additional Information: /sig node /sig windows If making changes before the v1.26 release, file a PR against the dev-1.26 branch.
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
PR could have included this update.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten


Question: 1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。 Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 <del> 1. Pod内のコンテナの1つが`preStop`[フック](/ja/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 </del> <ins> 1. Pod内のコンテナの1つが`preStop`[フック](/ja/docs/concepts/containers/container-lifecycle-hooks)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も`preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 </ins> {{< note >}} `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。 {{< /note >}}

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/workloads/pods/pod- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/workloads/pods/pod- is outdated. For example, there is no description of PodHasNetwork(alpha feature). Comments /language ja /assign
/triage accepted


Question: - **trafficDistribution** (string) <del> TrafficDistribution offers a way to express preferences for how traffic is distributed to Service endpoints. Implementations can use this field as a hint, but are not required to guarantee strict adherence. If the field is not set, the implementation will apply its default routing strategy. If set to "PreferClose", implementations should prioritize endpoints that are topologically close (e.g., same zone). This is an alpha field and requires enabling ServiceTrafficDistribution feature. </del> <ins> TrafficDistribution offers a way to express preferences for how traffic is distributed to Service endpoints. Implementations can use this field as a hint, but are not required to guarantee strict adherence. If the field is not set, the implementation will apply its default routing strategy. If set to "PreferClose", implementations should prioritize endpoints that are topologically close (e.g., same zone). This is an beta field and requires enabling ServiceTrafficDistribution feature. </ins>

This is a documentation mismatch 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 was looking over the release notes and when looking into i noticed that the docs show that it's still in alpha yet when we look into the , , and it says that it's now in a beta state. Proposed Solution: We'll want to update the docs to prevent any confusion for future users Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I believe you're correct thank you for spotting it! It looks like this is part of the auto generated docs. I will add a PR with a fix. /sig network
/retitle shows as alpha despite graduating to beta in v1.31 For this repo, we can take the docs part as a given.
/language en
The same upstream change would fix
/triage accepted
/assign


Question: <ins> --- title: 追踪 Kubernetes 系统组件 content_type: concept weight: 60 --- <!-- --- title: Traces For Kubernetes System Components reviewers: - logicalhan - lilic content_type: concept weight: 60 --- --> <!-- overview --> {{< feature-state for_k8s_version="v1.22" state="alpha" >}} <!-- System component traces record the latency of and relationships between operations in the cluster. --> 系统组件追踪功能记录各个集群操作的时延信息和这些操作之间的关系。 <!-- Kubernetes components emit traces using the [OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification) with the gRPC exporter and can be collected and routed to tracing backends using an [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector). --> Kubernetes 组件基于 gRPC 导出器的 [OpenTelemetry 协议](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification) 发送追踪信息，并用 [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector) 收集追踪信息，再将其转交给追踪系统的后台。 <!-- body --> <!-- ## Trace Collection --> ## 追踪信息的收集 {#trace-collection} <!-- For a complete guide to collecting traces and using the collector, see [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/). However, there are a few things to note that are specific to Kubernetes components. --> 关于收集追踪信息、以及使用收集器的完整指南，可参见 [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)。 不过，还有一些特定于 Kubernetes 组件的事项值得注意。 <!-- By default, Kubernetes components export traces using the grpc exporter for OTLP on the [IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317. As an example, if the collector is running as a sidecar to a Kubernetes component, the following receiver configuration will collect spans and log them to standard output: --> 默认情况下，Kubernetes 组件使用 gRPC 的 OTLP 导出器来导出追踪信息，将信息写到 [IANA OpenTelemetry 端口](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry)。 举例来说，如果收集器以 Kubernetes 组件的边车模式运行，以下接收器配置会收集 spans 信息，并将它们写入到标准输出。 <!-- # Replace this exporter with the exporter for your backend --> ```yaml receivers: otlp: protocols: grpc: exporters: # 用适合你后端环境的导出器替换此处的导出器 logging: logLevel: debug service: pipelines: traces: receivers: [otlp] exporters: [logging] ``` <!-- ## Component traces ### kube-apiserver traces --> ## 组件追踪 {#component-traces} ### kube-apiserver 追踪 {#kube-apiserver-traces} <!-- The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests to webhooks, etcd, and re-entrant requests. It propagates the [W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests but does not make use of the trace context attached to incoming requests, as the kube-apiserver is often a public endpoint. --> kube-apiserver 为传入的 HTTP 请求、传出到 webhook 和 etcd 的请求以及重入的请求生成 spans。 由于 kube-apiserver 通常是一个公开的端点，所以它通过出站的请求传播 [W3C 追踪上下文](https://www.w3.org/TR/trace-context/)， 但不使用入站请求的追踪上下文。 <!-- #### Enabling tracing in the kube-apiserver --> #### 在 kube-apiserver 中启用追踪 {#enabling-tracing-in-the-kube-apiserver} <!-- To enable tracing, enable the `APIServerTracing` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file with `--tracing-config-file=<path-to-config>`. This is an example config that records spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: --> 要启用追踪特性，需要启用 kube-apiserver 上的  `APIServerTracing` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。 ```yaml apiVersion: apiserver.config.k8s.io/v1alpha1 kind: TracingConfiguration # default value #endpoint: localhost:4317 samplingRatePerMillion: 100 ``` <!-- For more information about the `TracingConfiguration` struct, see [API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration). --> 有关 TracingConfiguration 结构体的更多信息，请参阅 [API 服务器配置 API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 <!-- ## Stability --> ## 稳定性 {#stability} <!-- Tracing instrumentation is still under active development, and may change in a variety of ways. This includes span names, attached attributes, instrumented endpoints, etc. Until this feature graduates to stable, there are no guarantees of backwards compatibility for tracing instrumentation. --> 追踪工具仍在积极开发中，未来它会以多种方式发生变化。 这些变化包括：span 名称、附加属性、检测端点等等。 此类特性在达到稳定版本之前，不能保证追踪工具的向后兼容性。 ## {{% heading "whatsnext" %}} <!-- * Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/) --> * 阅读[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/) </ins>  No newline at end of file

This is a Feature Request translate content/en/docs/concepts/cluster-administration/system- into Chinese. What would you like to be content/zh/docs/concepts/cluster-administration/system- /language zh /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: font-size: 16px; background-color: #3371e3; text-decoration: none; <ins> text-align: center; </ins> } <del> h5 { </del> <ins> body.cid-training h5 { </ins> font-size: 16px; font-weight: 500; line-height: 1.5em; margin-bottom: 2em; } <del> .white-text { </del> <ins> body.cid-training .white-text { </ins> color: #fff; } <del> .padded { </del> <ins> body.cid-training .padded { </ins> padding-top: 100px; padding-bottom: 100px; } <del> .blue-bg { </del> <ins> body.cid-training .blue-bg { </ins> background-color: #3371e3; } <del> .lighter-gray-bg { </del> <ins> body.cid-training .lighter-gray-bg { </ins> background-color: #f4f4f4; } <del> .two-thirds-centered { </del> <ins> body.cid-training .two-thirds-centered { </ins> width: 66%; max-width: 950px; margin-left: auto; margin-right: auto; } <del> .landscape-section { </del> <ins> body.cid-training .landscape-section { </ins> margin-left: auto; margin-right: auto; max-width: 1200px; width: 100%; } <del> #landscape { </del> <ins> body.cid-training #landscape { </ins> opacity: 1; visibility: visible; overflow: hidden;

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: * [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。 * [暂停 Deployment ](#pausing-and-resuming-a-deployment) 以应用对 PodTemplateSpec 所作的多项修改， 然后恢复其执行以启动新的上线版本。 <del> * [使用 Deployment 状态](#deployment-status) 来判定上线过程是否出现停滞。 </del> <ins> * [使用 Deployment 状态](#deployment-status)来判定上线过程是否出现停滞。 </ins> * [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。 <!--

There are some bugs: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" "image updated to 1.9.1" should be changed to "image updated to 1.16.1" The content of this article has many "", it could be changed to "deployment". For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
/language zh
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /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
looks like docs is already updated to nginx:1.16.1. Do you mind closing this issue?
There should still be a few places left unfinished.
Could you please edit the issue which needs to be still updated?
Bug1: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" Bug2: ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" Bug3: "image updated to 1.9.1" should be changed to "image updated to 1.16.1" Bug4: The content of this article has many "", it could be changed to "deployment".

For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
Thanks for clarifying. /assign
/retitle [zh] Localization bugs / work required for Deployment concept
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


Question: Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**) <ins> {{< note >}} Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node. In-place minor version `kubelet` upgrades are not supported. {{</ note >}} </ins> {{< warning >}} Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:

Follow up from , tracked in Upgrade process for is not sufficiently clear in user-facing documentation: [ ] add details to kubelet upgrade procedure (whether drain is required, whether skip-level kubelet upgrades are supported, etc) Page to Update:
Is this about in-place updates of the kubelet? Do the kubeadm upgrade tests cover that scenario? The kube-up GCE upgrade tests just replace machines running the old kubelet with machines running a newer one, bypassing the in-place upgrade questions here. Unless or until we have testing for in-place upgrades, the conservative answer is that the upgrade process for a kubelet is to provision a new machine with the desired kubelet version.
Yes I don't know.
yes, but our tests are failing due to problems with the upgrade framework in k/k (e.g. ginkgo skipping); possibly some other reasons too. the current tests are pretty much unmaintained and there are plans to replace them with something else next cycle, hopefully. we do recommend draining in our 12 -13 upgrade process. skipping minor versions is claimed as unsupported. (edit: not claimed -claimed)
is the informal guidance I've seen until now. There may be other deployment-specific reasons to destroy and rebuild nodes (node-level improvements that only take effect for new nodes, etc), but from the kubelet's perspective, drain has been sufficient, as far as I know.
/wg lts
/language en
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
/kind feature /priority backlog
cc:
/remove-lifecycle stale
There is evidence of users upgrading kubelets between minor versions without draining pods (). If that is required, the kubelet upgrade docs need to be made explicit.
Is it required? Do we have a formal decision on that?
Please, let also us address whether drain is required when upgrading between patch versions, e.g., 1.17.0 to 1.17.1. These upgrades are, arguably, more frequent than upgrades between minor versions, and therefore users have a greater incentive to skip drain.

WRT workload stability, the process is the same for PATCH iterations, so a drain would be required there too. one potential difference with MINOR updates is the CPU checkpoint format of the kubelet is not supposed to change on PATCH iterations.
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
/remove-lifecycle stale
/assign Routing to sig-node leads. If we require draining nodes before minor version upgrade or reconfiguration (and that is required, as far as I can tell), that needs to be made explicit
My opinion, a cordon -drain -upgrade -uncordon path is the safest thing to document for all situations. We should be able to do patch level upgrades (z-stream, in x.y.z) without draining but, imho, there is no point in complicating the guidance.
cordon -drain -upgrade kubelet -uncordon is the only path supported by SIG Node today. In the past, there were efforts to do in-place upgrade kubelet, including containerized kubelet by CoreOS team to simplify the upgrading flow, but none of them are officially supported by the community. Let's make the upgrade flow explicit in the doc for now, but open for the enhancement.
Now that it's official, I'll work up a docs PR :slightlysmilingface:
/triage accepted
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
/remove-lifecycle stale
Opened to update the doc. The cluster-upgrade doc already included this information