Question: approvers: - pweil- title: Pod 安全策略 <ins> content_template: templates/concept weight: 20 </ins> --- <ins> {{% capture overview %}} </ins> <del> `PodSecurityPolicy` 类型的对象能够控制，是否可以向 Pod 发送请求，该 Pod 能够影响被应用到 Pod 和容器的 `SecurityContext`。 查看 [Pod 安全策略建议](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) 获取更多信息。 </del> <ins> {{< feature-state state="beta" >}} </ins> <del> {{< toc >}} </del> <ins> <!-- Pod Security Policies enable fine-grained authorization of pod creation and updates. --> Pod 安全策略支持针对 pod 创建和更新进行精细的权限控制。 {{% /capture %}} {{% capture body %}} <!-- ## What is a Pod Security Policy? --> </ins> ## 什么是 Pod 安全策略？ <del> _Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。 `PodSecurityPolicy` 对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。 </del> <ins> <!-- A _Pod Security Policy_ is a cluster-level resource that controls security sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields. They allow an administrator to control the following: --> _Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 规范中对安全敏感的方面。 [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 对象定义了一组 pod 必须在其上运行才能被系统接受的条件，以及相关字段的默认设置。 </ins> 它们允许管理员控制如下方面： <ins> <!-- | Control Aspect                                    | Field Names                                                                                | |---------------------------------------------------|----------------------------------------------------------------------------------------------| | Running of privileged containers                  | [`privileged`](#privileged)                                                                  | | Usage of host namespaces                          | [`hostPID`, `hostIPC`](#host-namespaces)                                                     | | Usage of host networking and ports                | [`hostNetwork`, `hostPorts`](#host-namespaces)                                               | | Usage of volume types                             | [`volumes`](#volumes-and-file-systems)                                                       | | Usage of the host filesystem                      | [`allowedHostPaths`](#volumes-and-file-systems)                                              | | White list of FlexVolume drivers                  | [`allowedFlexVolumes`](#flexvolume-drivers)                                                  | | Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems)                                                       | | Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems)                                        | | The user and group IDs of the container           | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups)                         | | Restricting escalation to root privileges         | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation)       | | Linux capabilities                                | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | | The SELinux context of the container              | [`seLinux`](#selinux)                                                                        | | The Allowed Proc Mount types for the container    | [`allowedProcMountTypes`](#allowedprocmounttypes)                                            | | The AppArmor profile used by containers           | [annotations](#apparmor)                                                                     | | The seccomp profile used by containers            | [annotations](#seccomp)                                                                      | | The sysctl profile used by containers             | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl)                                         | --> | 所控制的方面                     | 字段名称                                                                                | |----------------------------------|----------------------------------------------------------------------------------------------| | 运行特权容器                     | [`privileged`](#privileged)                                                                  | | 使用主机 PID 的命名空间          | [`hostPID`, `hostIPC`](#host-namespaces)                                                     | | 主机网络的使用                   | [`hostNetwork`,`hostPorts`](#host-namespaces)                                                | | 控制卷类型的使用                 | [`volumes`](#volumes-and-file-systems)                                                       | | 主机路径的使用                   | [`allowedHostPaths`](#volumes-and-file-systems)                                              | | FlexVolume 卷驱动的白名单        | [`allowedFlexVolumes`](#flexvolume-drivers)                                                  | | 分配拥有 Pod 数据卷的 FSGroup    | [`fsGroup`](#volumes-and-file-systems)                                                       | | 必须使用一个只读的 root 文件系统 | [`readOnlyRootFilesystem`(#volumes-and-file-systems)                                         | | 容器的用户和组的 ID              | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups)                         | | 限制提升为 root 特权             | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation)       | | 为容器添加默认的一组权能字         | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | | 容器的 SELinux 上下文            | [`seLinux`](#selinux)                                                                        | | 容器允许的 Proc 挂载类型         | [`allowedProcMountTypes`](#allowedprocmounttypes)                                            | | 容器使用的 AppArmor 配置         | [annotations](#apparmor)                                                                     | | 容器使用的 seccomp 配置          | [annotations](#seccomp)                                                                      | | 容器使用的 sysctl 配置           | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl)                                         | </ins> <del> | 控制面                                                        | 字段名称                          | | ------------------------------------------------------------- | --------------------------------- | | 已授权容器的运行                                              | `privileged`                      | | 为容器添加默认的一组能力                                      | `defaultAddCapabilities`          | | 为容器去掉某些能力                                            | `requiredDropCapabilities`        | | 容器能够请求添加某些能力                                      | `allowedCapabilities`             | | 控制卷类型的使用                                              | [`volumes`](#controlling-volumes) | | 主机网络的使用                                                | [`hostNetwork`](#host-network)    | | 主机端口的使用                                                | `hostPorts`                       | | 主机 PID namespace 的使用                                     | `hostPID`                         | | 主机 IPC namespace 的使用                                     | `hostIPC`                         | | 主机路径的使用                                                | [`allowedHostPaths`](#allowed-host-paths)    | | 容器的 SELinux 上下文                                         | [`seLinux`](#selinux)             | | 用户 ID                                                       | [`runAsUser`](#runasuser)         | | 配置允许的补充组                                              | [`supplementalGroups`](#supplementalgroups) | | 分配拥有 Pod 数据卷的 FSGroup                                 | [`fsGroup`](#fsgroup)             | | 必须使用一个只读的 root 文件系统                              | `readOnlyRootFilesystem`          | </del> <ins> <!-- ## Enabling Pod Security Policies --> ## 启用 Pod 安全策略 <!-- Pod security policy control is implemented as an optional (but recommended) [admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicies are enforced by [enabling the admission controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), but doing so without authorizing any policies **will prevent any pods from being created** in the cluster. --> </ins> <del> _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类： </del> <ins> Pod 安全策略控制是 [admission 控制器](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy) 的一个可选实现。PodSecurityPolicy通过 [启用 admission 控制器](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in) 被强制启用， 但是如果集群内没有授权任何策略时这样做 **将导致任何 pod 都无法被创建**。 </ins> <del> - *基于布尔值控制* ：这种类型的字段默认为最严格限制的值。 - *基于被允许的值集合控制* ：这种类型的字段会与这组值进行对比，以确认值被允许。 - *基于策略控制* ：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。 </del> <ins> <!-- Since the pod security policy API (`policy/v1beta1/podsecuritypolicy`) is enabled independently of the admission controller, for existing clusters it is recommended that policies are added and authorized before enabling the admission controller. --> 由于 Pod 安全策略 API (`policy/v1beta1/podsecuritypolicy`) 时独立于 admission 控制器启用的， 所以对于现有集群推荐在启用 admission 控制器之前就添加并授权安全策略。 <!-- ## Authorizing Policies --> ## 授权策略 <!-- When a PodSecurityPolicy resource is created, it does nothing. In order to use it, the requesting user or target pod's [service account](/docs/tasks/configure-pod-container/configure-service-account/) must be authorized to use the policy, by allowing the `use` verb on the policy. --> 当一个 PodSecurityPolicy 资源被创建后，不会执行任何动作。想要应用这个策略，请求用户或者目标 pod 的 [服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 必须在策略中使用 `use` 动词，从而被授权使用这个策略。 </ins> <del> ### RunAsUser </del> <ins> <!-- Most Kubernetes pods are not created directly by users. Instead, they are typically created indirectly as part of a [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or other templated controller via the controller manager. Granting the controller access to the policy would grant access for *all* pods created by that controller, so the preferred method for authorizing policies is to grant access to the pod's service account (see [example](#run-another-pod)). --> 多数 Kubernetes pod 并非由用户直接创建。相反，通常他们作为 [Deployment](/docs/concepts/workloads/controllers/deployment/)、 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 或者其他的模板控制器的组成部分由控制器管理器被间接地创建。 将访问权限授予控制器即相当于授权给 **所有** 由该控制器创建的 Pod，因此推荐的鉴权策略的方式是为 Pod 的服务账号授权（参见 [示例](#run-another-pod)）。 <!-- ### Via RBAC --> ### 使用 RBAC <!-- [RBAC](/docs/reference/access-authn-authz/rbac/) is a standard Kubernetes authorization mode, and can easily be used to authorize use of policies. --> [RBAC](/docs/reference/access-authn-authz/rbac/) 是一个标准的 Kubernetes 授权模式，同时也能够方便地用于授权策 略的使用。 <!-- First, a `Role` or `ClusterRole` needs to grant access to `use` the desired policies. The rules to grant access look like this: --> 首先，需要有一个 `Role` 或者 `ClusterRole` 被授予访问权限来 `use` 预期策略。授予访问权限的策略如下所示： </ins> <del> - *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。 - *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中定义了 `USER` 环境变量。不提供默认值。 - *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 。 </del> <ins> <!-- ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <role name> rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs:     ['use'] resourceNames: - <list of policies to authorize> ``` --> ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <角色名称> rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs:     ['use'] resourceNames: - <需要授权的策略列表> ``` <!-- Then the `(Cluster)Role` is bound to the authorized user(s): --> 随后该 `(Cluster)Role` 即绑定给了授权的用户： <!-- ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <binding name> roleRef: kind: ClusterRole name: <role name> apiGroup: rbac.authorization.k8s.io subjects: # Authorize specific service accounts: - kind: ServiceAccount name: <authorized service account name> namespace: <authorized pod namespace> # Authorize specific users (not recommended): - kind: User apiGroup: rbac.authorization.k8s.io name: <authorized user name> ``` --> ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <绑定名称> roleRef: kind: ClusterRole name: <角色名称> apiGroup: rbac.authorization.k8s.io subjects: # 授权给特定的服务账户: - kind: ServiceAccount name: <授权的服务账户名称> namespace: <授权的 pod 命名空间> # 授权给指定用户 (不推荐): - kind: User apiGroup: rbac.authorization.k8s.io name: <授权的用户名> ``` </ins> <del> ### SELinux </del> <ins> <!-- If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant usage for pods being run in the same namespace as the binding. This can be paired with system groups to grant access to all pods run in the namespace: --> 如果一个 `RoleBinding` (非 `ClusterRoleBinding`) 被使用，它只会授权给那些运行在与绑定相同命名空间下的 pod。 这可以与系统组一起授权给所有运行在该命名空间下的所有 pod。 </ins> <del> - *MustRunAs* - 如果没有使用预分配的值，必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。验证 `seLinuxOptions`。 - *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` ID。 </del> <ins> <!-- ```yaml # Authorize all service accounts in a namespace: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:serviceaccounts # Or equivalently, all authenticated users in a namespace: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated ``` --> ```yaml # 授权命名空间下的所有 service accounts: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:serviceaccounts # 或者同样的，授权给命名空间下的所有已验证的用户: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated ``` <!-- For more examples of RBAC bindings, see [Role Binding Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). For a complete example of authorizing a PodSecurityPolicy, see [below](#example). --> 更多关于 RBAC 绑定的示例，查看 [角色绑定示例](/docs/reference/access-authn-authz/rbac#role-binding-examples)。 关于授权 PodSecurityPolicy 的完整示例，查看 [下面](#example)。 <!-- ### Troubleshooting --> ### 故障诊断 </ins> <del> ### SupplementalGroups </del> <ins> <!-- - The [Controller Manager](/docs/admin/kube-controller-manager/) must be run against [the secured API port](/docs/reference/access-authn-authz/controlling-access/), and must not have superuser permissions. Otherwise requests would bypass authentication and authorization modules, all PodSecurityPolicy objects would be allowed, and users would be able to create privileged containers. For more details on configuring Controller Manager authorization, see [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). --> - [控制器管理器](/docs/admin/kube-controller-manager/) 必须运行于 [安全的 API 端口](/docs/reference/access-authn-authz/controlling-access/)， 并且必须不能具备超级用户权限。否则请求将可绕过身份验证和授权模块，所有的 PodSecurityPolicy 对象将被允许，并且所有的用户将能够创建特权容器。 关于配置控制器管理器授权的更多细节，查看 [控制器角色](/docs/reference/access-authn-authz/rbac/#controller-roles)。 </ins> <del> - *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。 - *RunAsAny* - 没有提供默认值。允许任意指定的 `supplementalGroups` ID。 </del> <ins> <!-- ## Policy Order --> ## 策略顺序 <!-- In addition to restricting pod creation and update, pod security policies can also be used to provide default values for many of the fields that it controls. When multiple policies are available, the pod security policy controller selects policies according to the following criteria: --> 除了限制 pod 的创建和更新之外，pod 安全策略也可以用于为由其控制的许多字段提供默认值。当同时多个策略可用时，pod 安全策略控制器依据以下标准选择策略： <!-- 1. PodSecurityPolicies which allow the pod as-is, without changing defaults or mutating the pod, are preferred.  The order of these non-mutating PodSecurityPolicies doesn't matter. 2. If the pod must be defaulted or mutated, the first PodSecurityPolicy (ordered by name) to allow the pod is selected. --> 1. 允许 pod 维持原状，不改变默认设置或者变更 pod 的 PodSecurityPolicy 是首选。这些非变更的 PodSecurityPolicy 的顺序无关紧要。 2. 如果 pod 必须默认或者变更，则使用第一个 PodSecurityPolicy（按名称排序）以允许该 pod。 </ins> <del> ### FSGroup </del> <ins> {{< note >}} <!-- During update operations (during which mutations to pod specs are disallowed) only non-mutating PodSecurityPolicies are used to validate the pod. --> 在更新操作期间（在 pod 规范不允许变更的期间）只有非变更的 PodSecurityPolicy 会用于校验 pod。 {{< /note >}} </ins> <del> - *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。 - *RunAsAny* - 没有提供默认值。允许任意指定的 `fsGroup` ID。 </del> <ins> <!-- ## Example --> ## 示例 <!-- _This example assumes you have a running cluster with the PodSecurityPolicy admission controller enabled and you have cluster admin privileges._ --> _这个示例假定你有一个运行中且已启用 PodSecurityPolicy admission 控制器的集群，并且你拥有集群管理员权限。_ <!-- ### Set up --> ### 设置 </ins> <del> ### 控制卷 </del> <ins> <!-- Set up a namespace and a service account to act as for this example. We'll use this service account to mock a non-admin user. --> 以此为例设置一个命名空间和 service account. 我们将使用这个 service account 来模拟一个非管理员用户. </ins> <del> 通过设置 PSP 卷字段，能够控制具体卷类型的使用。当创建一个卷的时候，与该字段相关的已定义卷可以允许设置如下值： </del> <ins> ```shell kubectl create namespace psp-example kubectl create serviceaccount -n psp-example fake-user kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user ``` </ins> <del> 1. azureFile 1. azureDisk 1. flocker 1. flexVolume 1. hostPath 1. emptyDir 1. gcePersistentDisk 1. awsElasticBlockStore 1. gitRepo 1. secret 1. nfs 1. iscsi 1. glusterfs 1. persistentVolumeClaim 1. rbd 1. cinder 1. cephFS 1. downwardAPI 1. fc 1. configMap 1. vsphereVolume 1. quobyte 1. projected 1. portworxVolume 1. scaleIO 1. storageos 1. * (allow all volumes) </del> <ins> <!-- To make it clear which user we're acting as and save some typing, create 2 aliases: --> 为了清晰展示我们所演示的具体用户以及省去一些键入操作,首先创建两个别名: ```shell alias kubectl-admin='kubectl -n psp-example' alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' ``` <!-- ### Create a policy and a pod --> ### 创建一个策略和一个 pod </ins> <del> 对新的 PSP，推荐允许的卷的最小集合包括：configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。 </del> <ins> <!-- Define the example PodSecurityPolicy object in a file. This is a policy that simply prevents the creation of privileged pods. The name of a PodSecurityPolicy object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> 在一个文件中定义 PodSecurityPolicy 对象实例。这里的策略只是用来禁止创建有特权 要求的 Pods。 PodSecurityPolicy 对象的命名必须是合法的 [DNS 子域名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). {{< codenew file="policy/example-psp.yaml" >}} <!-- And create it with kubectl: --> 然后通过 kubectl 命名创建它: </ins> <del> ### 主机网络 - *HostPorts* ， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。 </del> <ins> ```shell kubectl-admin create -f example-psp.yaml ``` </ins> <del> ### 允许的主机路径 - *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。 </del> <ins> <!-- Now, as the unprivileged user, try to create a simple pod: --> 现在作为一个非特权用户, 尝试创建一个简单的 pod: ```shell kubectl-user create -f- <<EOF apiVersion: v1 kind: Pod metadata: name:      pause spec: containers: - name:  pause image: k8s.gcr.io/pause EOF Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: [] ``` <!-- **What happened?** Although the PodSecurityPolicy was created, neither the pod's service account nor `fake-user` have permission to use the new policy: --> **发生了什么?** 尽管 PodSecurityPolicy 已经创建, pod 的 service account 和 `fake-user` 都没有权限使用这个策略: </ins> <del> ## 许可 </del> <ins> ```shell kubectl-user auth can-i use podsecuritypolicy/example no ``` </ins> <del> 包含 `PodSecurityPolicy` 的 _许可控制_，允许控制集群资源的创建和修改，基于这些资源在集群范围内被许可的能力。 </del> <ins> <!-- Create the rolebinding to grant `fake-user` the `use` verb on the example policy: --> 创建 rolebinding 来为示例策略中的 `fake-user` 的 `use` 动词授权: </ins> <del> 许可使用如下的方式为 Pod 创建最终的安全上下文： 1. 检索所有可用的 PSP。 1. 生成在请求中没有指定的安全上下文设置的字段值。 1. 基于可用的策略，验证最终的设置。 </del> <ins> {{< note >}} <!-- This is not the recommended way! See the [next section](#run-another-pod) for the preferred approach. --> 不推荐这种方式! 更推荐的方式请查看 [下一部分](#run-another-pod). {{< /note >}} </ins> <del> 如果某个策略能够匹配上，该 Pod 就被接受。如果请求与 PSP 不匹配，则 Pod 被拒绝。 </del> <ins> ```shell kubectl-admin create role psp:unprivileged  --verb=use  --resource=podsecuritypolicy  --resource-name=example role "psp:unprivileged" created kubectl-admin create rolebinding fake-user:psp:unprivileged  --role=psp:unprivileged  --serviceaccount=psp-example:fake-user rolebinding "fake-user:psp:unprivileged" created kubectl-user auth can-i use podsecuritypolicy/example yes ``` </ins> <del> Pod 必须基于 PSP 验证每个字段。 </del> <ins> <!-- Now retry creating the pod: --> 现在重新创建这个 pod: ```shell kubectl-user create -f- <<EOF apiVersion: v1 kind: Pod metadata: name:      pause spec: containers: - name:  pause image: k8s.gcr.io/pause EOF pod "pause" created ``` </ins> <!-- <del> ### Create a policy and a pod Define the example PodSecurityPolicy object in a file. This is a policy that simply prevents the creation of privileged pods. </del> <ins> It works as expected! But any attempts to create a privileged pod should still be denied: --> 它如期运行,但是任何创建特权 pod 的尝试都应当被拒绝: </ins> <del> {{< codenew file="policy/example-psp.yaml" >}} </del> <ins> ```shell kubectl-user create -f- <<EOF apiVersion: v1 kind: Pod metadata: name:      privileged spec: containers: - name:  pause image: k8s.gcr.io/pause securityContext: privileged: true EOF Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed] ``` </ins> <del> And create it with kubectl: </del> <ins> <!-- Delete the pod before moving on: --> 在继续下一步之前先删掉之前的 pod: </ins> ```shell <del> kubectl-admin create -f example-psp.yaml </del> <ins> kubectl-user delete pod pause </ins> ``` <del> --> ### 创建一个策略和一个 Pod </del> <ins> <!-- ### Run another pod --> ### 运行另一个 pod </ins> <del> 在一个文件中定义 PodSecurityPolicy 对象实例。这里的策略只是用来禁止创建有特权 要求的 Pods。 </del> <ins> <!-- Let's try that again, slightly differently: --> 我们来再试一次, 相比之前略微有些不同: </ins> <del> {{< codenew file="policy/example-psp.yaml" >}} </del> <ins> ```shell kubectl-user run pause --image=k8s.gcr.io/pause deployment "pause" created </ins> <del> 使用 kubectl 执行创建操作： </del> <ins> kubectl-user get pods No resources found. </ins> <del> ```shell kubectl-admin create -f example-psp.yaml </del> <ins> kubectl-user get events | head -n 2 LASTSEEN   FIRSTSEEN   COUNT     NAME              KIND         SUBOBJECT                TYPE      REASON                  SOURCE                                  MESSAGE 1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request </ins> ``` <del> ## 获取 Pod 安全策略列表 </del> <ins> <!-- **What happened?** We already bound the `psp:unprivileged` role for our `fake-user`, why are we getting the error `Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request`? The answer lies in the source - `replicaset-controller`. Fake-user successfully created the deployment (which successfully created a replicaset), but when the replicaset went to create the pod it was not authorized to use the example podsecuritypolicy. --> **发生了什么?** 我们已经将 `psp:unprivileged` 角色绑定给了 `fake-user`, 为何仍然报错 `Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request`? 答案在 `replicaset-controller` 源码中. Fake-user 成功创建了 deployment (并且该 deployment 成功创建了一个 replicaset), 然而当该 replicaset 想要创建 pod 时却没有权限使用我们的示例 pod 安全策略. </ins> <del> 获取已存在策略列表，使用 `kubectl get`： </del> <ins> <!-- In order to fix this, bind the `psp:unprivileged` role to the pod's service account instead. In this case (since we didn't specify it) the service account is `default`: --> 为了修复这个问题，将 `psp:unprivileged` 角色绑定给 pod 的 service account. 在这种情况下(由于我们没有显式指定) 该 service account 为 `default`: </ins> ```shell <del> $ kubectl get psp NAME        PRIV   CAPS  SELINUX   RUNASUSER         FSGROUP   SUPGROUP  READONLYROOTFS  VOLUMES permissive  false  []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*] privileged  true   []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*] restricted  false  []    RunAsAny  MustRunAsNonRoot  RunAsAny  RunAsAny  false           [emptyDir secret downwardAPI configMap persistentVolumeClaim projected] </del> <ins> kubectl-admin create rolebinding default:psp:unprivileged  --role=psp:unprivileged  --serviceaccount=psp-example:default rolebinding "default:psp:unprivileged" created </ins> ``` <ins> <!-- Now if you give it a minute to retry, the replicaset-controller should eventually succeed in creating the pod: --> 现在如果你给它一分钟让它重试, replicaset-controller 应该最终能够成功创建出 pod: ```shell kubectl-user get pods --watch NAME                    READY     STATUS    RESTARTS   AGE pause-7774d79b5-qrgcb   0/1       Pending   0         1s pause-7774d79b5-qrgcb   0/1       Pending   0         1s pause-7774d79b5-qrgcb   0/1       ContainerCreating   0         1s pause-7774d79b5-qrgcb   1/1       Running   0         2s ``` </ins> <del> ## 修改 Pod 安全策略 </del> <ins> <!-- ### Clean up --> ### 清理 </ins> <del> 通过交互方式修改策略，使用 `kubectl edit`： </del> <ins> <!-- Delete the namespace to clean up most of the example resources: --> 删除命名空间来清理大部分示例资源: </ins> ```shell <del> $ kubectl edit psp permissive </del> <ins> kubectl-admin delete ns psp-example namespace "psp-example" deleted </ins> ``` <ins> <!-- Note that `PodSecurityPolicy` resources are not namespaced, and must be cleaned up separately: --> 注意 `PodSecurityPolicy` 并非命名空间限定的资源类型, 必须单独清理: ```shell kubectl-admin delete psp example podsecuritypolicy "example" deleted ``` </ins> <del> 该命令将打开一个默认文本编辑器，在这里能够修改策略。 </del> <ins> <!-- ### Example Policies --> ### 示例策略 <!-- This is the least restrictive policy you can create, equivalent to not using the pod security policy admission controller: --> 这是一个你能够创建的最小化的限制性策略, 相当于不使用 pod 安全策略准入控制器: </ins> <del> ## 删除 Pod 安全策略 </del> <ins> {{< codenew file="policy/privileged-psp.yaml" >}} </ins> <del> 一旦不再需要一个策略，很容易通过 `kubectl` 删除它： </del> <ins> <!-- This is an example of a restrictive policy that requires users to run as an unprivileged user, blocks possible escalations to root, and requires use of several security mechanisms. --> 这是一个限制性策略示例,要求用户以非特权用户运行, 屏蔽了权限提升至 root 的可能性, 同时需要使用几个安全机制. </ins> <del> ```shell $ kubectl delete psp permissive podsecuritypolicy "permissive" deleted ``` </del> <ins> {{< codenew file="policy/restricted-psp.yaml" >}} <!-- ## Policy Reference --> ## 策略参考 <!-- ### Privileged --> ### 特权 </ins> <del> ## 启用 Pod 安全策略 </del> <ins> <!-- **Privileged** - determines if any container in a pod can enable privileged mode. By default a container is not allowed to access any devices on the host, but a "privileged" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. --> **特权** - 决定 pod 中的任意容器能否启用特权模式。默认情况下一个容器不允许访问主机上的任意设备， 但是一个 "特权" 容器是允许访问主机上的所有设备的。 这样容器具备的权限几乎等同于主机上运行的进程。 这对于像比如操作网络堆栈和访问设备等需要使用 linux 权能字的容器来说非常有用。 </ins> <del> 为了能够在集群中使用 Pod 安全策略，必须确保满足如下条件： </del> <ins> <!-- ### Host namespaces --> ### 主机命名空间 <!-- **HostPID** - Controls whether the pod containers can share the host process ID namespace. Note that when paired with ptrace this can be used to escalate privileges outside of the container (ptrace is forbidden by default). --> **HostPID** - 控制 pod 容器能否共享主机进程 ID 命名空间。 注意当它与 ptrace 搭配使用时可被利用于在容器外部提升权限(ptrace 默认被禁用)。 <!-- **HostIPC** - Controls whether the pod containers can share the host IPC namespace. --> **HostIPC** - 控制 pod 容器能够共享主机 IPC </ins> <del> 1. 已经启用 API 类型 `extensions/v1beta1/podsecuritypolicy`（仅对 1.6 之前的版本） 1. 已经启用许可控制器 `PodSecurityPolicy` 1. 已经定义了自己的策略 </del> <ins> <!-- **HostNetwork** - Controls whether the pod may use the node network namespace. Doing so gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. --> **HostNetwork** - 控制 pod 能否使用节点网络命名空间。 这样做可允许 pod 访问回环设备、监听 localhost 的服务以及能够用于探测同意节点上其他 pod 的网络活动。 <!-- **HostPorts** - Provides a whitelist of ranges of allowable ports in the host network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive) and `max`(inclusive). Defaults to no allowed host ports --> **HostPorts** - 提供主机网络名称空间中允许端口范围的白名单。定义为 `HostPortRange` 列表，其中包含 `min(包含)` 和 `max(包含)`。默认不允许任何主机端口。 <!-- ### Volumes and file systems --> ### 存储卷和文件系统 <!-- **Volumes** - Provides a whitelist of allowed volume types. The allowable values correspond to the volume sources that are defined when creating a volume. For the complete list of volume types, see [Types of Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*` may be used to allow all volume types. --> **Volumes** - 提供允许的存储卷类型的白名单。允许值对应于在创建卷时定义的源卷。完整的卷类型列表，请查阅 [卷类型](/docs/concepts/storage/volumes/#types-of-volumes)。 此外 `*` 可用于允许所有卷类型。 <!-- The **recommended minimum set** of allowed volumes for new PSPs are: --> 对于新 PSP 允许的卷**推荐的最小化组合** 是： - configMap - downwardAPI - emptyDir - persistentVolumeClaim - secret - projected {{< warning >}} <!-- PodSecurityPolicy does not limit the types of `PersistentVolume` objects that may be referenced by a `PersistentVolumeClaim`, and hostPath type `PersistentVolumes` do not support read-only access mode. Only trusted users should be granted permission to create `PersistentVolume` objects. --> PodSecurityPolicy 并不会对可能被 `PersistentVolumeClaim` 引用的 `PersistentVolume` 资源对象的类型做限制， 并且 hostPath 类型的 `PersistentVolumes` 并不支持只读访问模式。只有可信用户才应当给予创建 `PersistentVolume` 资源对象的权限。 {{< /warning >}} <!-- **FSGroup** - Controls the supplemental group applied to some volumes. --> **FSGroup** - 控制应用于某些卷的补充组。 <!-- - *MustRunAs* - Requires at least one `range` to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Requires at least one `range` to be specified. Allows `FSGroups` to be left unset without providing a default. Validates against all ranges if `FSGroups` is set. - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified. --> - *MustRunAs* - 要求至少指定一个 `range`。使用第一个范围的最小值作为默认值。针对所有范围进行验证。 - *MayRunAs* - 要求至少指定一个 `range`。允许 `FSGroups` 不提供默认设置。如果设置了 `FSGroups`， 则针对所有范围进行验证。 - *RunAsAny* - 不提供默认值。允许指定任意 `fsGroup` ID。 <!-- **AllowedHostPaths** - This specifies a whitelist of host paths that are allowed to be used by hostPath volumes. An empty list means there is no restriction on host paths used. This is defined as a list of objects with a single `pathPrefix` field, which allows hostPath volumes to mount a path that begins with an allowed prefix, and a `readOnly` field indicating it must be mounted read-only. For example: --> **AllowedHostPaths** - 它指定主机路径的白名单，允许 hostPath 卷使用这些白名单。空列表意味着对使用的主机路径没有限制。 这被定义为一个对象列表，其中有一个 `pathPrefix` 字段，它允许 hostPath 卷挂载一个以允许的前缀开头的路径，以及一个 `readOnly` 字段， 表示它必须以只读方式挂载。例如： ```yaml allowedHostPaths: # This allows "/foo", "/foo/", "/foo/bar" etc., but # disallows "/fool", "/etc/foo" etc. # "/foo/../" is never valid. - pathPrefix: "/foo" readOnly: true # only allow read-only mounts ``` </ins> <del> ## 使用 RBAC </del> <ins> {{< warning >}} <!-- There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and abusing the credentials of system services, such as Kubelet. --> 对于能够无限制访问主机文件系统的容器来说，有许多方式可以进行特权提升，包括从其他容器读取数据，以及滥用系统服务(如 Kubelet)的凭据。 <!-- Writeable hostPath directory volumes allow containers to write to the filesystem in ways that let them traverse the host filesystem outside the `pathPrefix`. `readOnly: true`, available in Kubernetes 1.11+, must be used on **all** `allowedHostPaths` to effectively limit access to the specified `pathPrefix`. --> 可写的 hostPath 目录卷允许容器以允许它们在 `pathPrefix` 之外遍历主机文件系统的方式写入文件系统。`readOnly: true` 在 Kubernetes 1.11+ 可用， 必须应用于 **所有** `allowedHostPaths` 以有效限制对指定 `pathPrefix` 的访问。 {{< /warning >}} <!-- **ReadOnlyRootFilesystem** - Requires that containers must run with a read-only root filesystem (i.e. no writable layer). --> **ReadOnlyRootFilesystem** - 要求容器必须运行于一个只读的根文件系统（即不可写的层）。 <!-- ### FlexVolume drivers --> ### FlexVolume 驱动 <!-- This specifies a whitelist of FlexVolume drivers that are allowed to be used by flexvolume. An empty list or nil means there is no restriction on the drivers. Please make sure [`volumes`](#volumes-and-file-systems) field contains the `flexVolume` volume type; no FlexVolume driver is allowed otherwise. --> 这指定了 FlexVolume 驱动程序的白名单，允许 FlexVolume 使用这些驱动程序。空列表或 nil 表示对驱动程序没有限制。 请确保 [`volumes`](#volumes-and-file-systems) 字段包含 `flexVolume` 卷类型；否则任何 FlexVolume 驱动都不允许。 <!-- For example: --> 例如： ```yaml apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: allow-flex-volumes spec: # ... 其他特性字段 volumes: - flexVolume allowedFlexVolumes: - driver: example/lvm - driver: example/cifs ``` </ins> <del> 在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。 </del> <ins> <!-- ### Users and groups --> ### 用户和组 <!-- **RunAsUser** - Controls which user ID the containers are run with. --> **RunAsUser** - 控制容器以哪个用户 ID 运行。 <!-- - *MustRunAs* - Requires at least one `range` to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero `runAsUser` or have the `USER` directive defined (using a numeric UID) in the image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero numeric `USER` directive in the container. No default provided. Setting `allowPrivilegeEscalation=false` is strongly recommended with this strategy. - *RunAsAny* - No default provided. Allows any `runAsUser` to be specified. --> - *MustRunAs* - 要求至少指定一个 `range`。使用第一个范围的最小值作为默认值。针对所有范围进行验证。 - *MustRunAsNonRoot* - 要求 pod 使用非零的 `runAsUser` 提交，或者在镜像中定义 `USER` 命令 (使用数字 UID)。 没有指定 `runAsNonRoot` 或 `runAsUser` 设置的 pod 将被修改为设置 `runAsNonRoot=true`， 因此需要在容器中定义一个非零的数字 `USER` 命令。不提供默认值。这个策略强烈建议设置 `allowPrivilegeEscalation=false`。 - *RunAsAny* - 不提供默认值。允许指定任意 `runAsUser`。 <!-- **RunAsGroup** - Controls which primary group ID the containers are run with. --> **RunAsGroup** - 控制容器以哪个首要组 ID 运行。 <!-- - *MustRunAs* - Requires at least one `range` to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Does not require that RunAsGroup be specified. However, when RunAsGroup is specified, they have to fall in the defined range. - *RunAsAny* - No default provided. Allows any `runAsGroup` to be specified. --> - *MustRunAs* - 要求至少指定一个 `range`。使用第一个范围的最小值作为默认值。针对所有范围进行验证。 - *MayRunAs* - 不要求指定 RunAsGroup。但是，当指定 RunAsGroup 时，它们必须落在定义的范围内。 - *RunAsAny* - 不提供默认值。允许指定任意 `runAsGroup`。 <!-- **SupplementalGroups** - Controls which group IDs containers add. --> **SupplementalGroups** - 控制容器添加那些组 ID。 <!-- - *MustRunAs* - Requires at least one `range` to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Requires at least one `range` to be specified. Allows `supplementalGroups` to be left unset without providing a default. Validates against all ranges if `supplementalGroups` is set. - *RunAsAny* - No default provided. Allows any `supplementalGroups` to be specified. --> - *MustRunAs* - 要求至少指定一个 `range`。使用第一个范围的最小值作为默认值。针对所有范围进行验证。 - *MayRunAs* - 要求至少指定一个 `range`。允许在不提供默认值的情况下不设置 `supplementalGroups`。 如果设置了 `supplementalGroups`，则对所有范围进行验证。 - *RunAsAny* - 不提供默认值。允许指定任意 `supplementalGroups`。 <!-- ### Privilege Escalation --> ### 特权提升 <!-- These options control the `allowPrivilegeEscalation` container option. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. This flag will prevent `setuid` binaries from changing the effective user ID, and prevent files from enabling extra capabilities (e.g. it will prevent the use of the `ping` tool). This behavior is required to effectively enforce `MustRunAsNonRoot`. --> 这个选项控制容器的 `allowPrivilegeEscalation` 选项。这个布尔值直接控制 [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) 标志是否设置到容器进程上。这个标志将防止 `setuid` 二进制文件改变有效的用户 ID，并防止文件启用额外的权能字 (例如，它将防止使用 `ping` 工具)。 这种行为前提是需要有效地强制指定 `MustRunAsNonRoot`。 <!-- **AllowPrivilegeEscalation** - Gates whether or not a user is allowed to set the security context of a container to `allowPrivilegeEscalation=true`. This defaults to allowed so as to not break setuid binaries. Setting it to `false` ensures that no child process of a container can gain more privileges than its parent. --> **AllowPrivilegeEscalation** - 是否允许用户将容器的安全上下文设置为 `allowPrivilegeEscalation=true`。 这是默认设置，以便不破坏 setuid 二进制文件。将其设置为 `false` 可以确保容器的子进程不能获得比其父进程更多的特权。 <!-- **DefaultAllowPrivilegeEscalation** - Sets the default for the `allowPrivilegeEscalation` option. The default behavior without this is to allow privilege escalation so as to not break setuid binaries. If that behavior is not desired, this field can be used to default to disallow, while still permitting pods to request `allowPrivilegeEscalation` explicitly. --> **DefaultAllowPrivilegeEscalation** - 设置 `allowPrivilegeEscalation` 选项的默认值。没有这个设置的默认行为是允许 特权升级，以避免破坏 setuid 二进制文件。如果这种行为并非有意，可以使此字段默认为不允许，但仍然允许 显式请求 `allowPrivilegeEscalation` 的 pods。 <!-- ### Capabilities --> ### 权能字 <!-- Linux capabilities provide a finer grained breakdown of the privileges traditionally associated with the superuser. Some of these capabilities can be used to escalate privileges or for container breakout, and may be restricted by the PodSecurityPolicy. For more details on Linux capabilities, see [capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html). --> Linux 权能字提供了对传统上与超级用户相关的特权的细粒度分解。其中一些权能字可用于特权提升或容器断接，并且可能受到 PodSecurityPolicy 的限制。 有关Linux功能的更多信息，查看 [capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)。 <!-- The following fields take a list of capabilities, specified as the capability name in ALL_CAPS without the `CAP_` prefix. --> 以下字段列出了权能字列表，在 ALL_CAPS 中指定为不带 `CAP_` 前缀的权能字名称。 <!-- **AllowedCapabilities** - Provides a whitelist of capabilities that may be added to a container. The default set of capabilities are implicitly allowed. The empty set means that no additional capabilities may be added beyond the default set. `*` can be used to allow all capabilities. --> **AllowedCapabilities** - 提供可添加到容器中的权能字白名单。默认的权能字集是隐式允许的。 空集意味着在默认集之外不能添加任何附加权能字。`*` 可用于允许所有权能字。 <!-- **RequiredDropCapabilities** - The capabilities which must be dropped from containers. These capabilities are removed from the default set, and must not be added. Capabilities listed in `RequiredDropCapabilities` must not be included in `AllowedCapabilities` or `DefaultAddCapabilities`. --> **RequiredDropCapabilities** - 必须从容器中删除的权能字。这些权能字将从默认设置中删除，并且不能被添加。 在 `requireddropcapability` 中列出的权能字不能包含在 `allowedcapability` 或 `defaultaddcapability` 中。 <!-- **DefaultAddCapabilities** - The capabilities which are added to containers by default, in addition to the runtime defaults. See the [Docker documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) for the default list of capabilities when using the Docker runtime. --> **DefaultAddCapabilities** - 除了运行时默认设置外，默认添加到容器中的权能字。查看 [Docker 文档](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) 中关于使用 Docker 运行时时默认的权能字列表。 </ins> <del> PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（Service Account）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。更多详情，查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md)，当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。 </del> <ins> ### SELinux <!-- - *MustRunAs* - Requires `seLinuxOptions` to be configured. Uses `seLinuxOptions` as the default. Validates against `seLinuxOptions`. - *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be specified. --> - *MustRunAs* - 要求设置 `seLinuxOptions`。使用 `seLinuxOptions` 作为默认值。针对所有范围进行验证。 - *RunAsAny* - 不提供默认值。允许指定任意 `seLinuxOptions`。 ### AllowedProcMountTypes <!-- `allowedProcMountTypes` is a whitelist of allowed ProcMountTypes. Empty or nil indicates that only the `DefaultProcMountType` may be used. --> `allowedProcMountTypes` 是允许 ProcMountTypes 的白名单。空列表或 nil 表示只允许 `DefaultProcMountType` 指定的默认值。 <!-- `DefaultProcMount` uses the container runtime defaults for readonly and masked paths for /proc.  Most container runtimes mask certain paths in /proc to avoid accidental security exposure of special devices or information. This is denoted as the string `Default`. --> `DefaultProcMount` 对只读路径使用容器运行时默认值，对/proc 使用掩码路径。大多数容器运行时屏蔽 /proc 中的某些路径， 以避免特殊设备或信息的意外安全性暴露。使用字符串 `Default` 表示。 <!-- The only other ProcMountType is `UnmaskedProcMount`, which bypasses the default masking behavior of the container runtime and ensures the newly created /proc the container stays intact with no modifications. This is denoted as the string `Unmasked`. --> 另一个 ProcMountType 是 `UnmaskedProcMount`，它绕过了容器运行时的默认屏蔽行为，并确保新创建的 /proc 容器保持不变。 使用字符串 `unmask` 表示。 ### AppArmor <!-- Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations). --> 通过 PodSecurityPolicy 上面的注解进行控制。参考 [AppArmor 文档](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)。 ### Seccomp <!-- The use of seccomp profiles in pods can be controlled via annotations on the PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes. --> 可以通过 PodSecurityPolicy 上的注解来控制 pod 中 seccomp 配置文件的使用。 Seccomp 是 Kubernetes 的一个 alpha 特性。 <!-- **seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that specifies the default seccomp profile to apply to containers. Possible values are: --> **seccomp.security.alpha.kubernetes.io/defaultProfileName** - 指定要应用于容器的默认 seccomp 配置文件的注解。 可选值有： <!-- - `unconfined` - Seccomp is not applied to the container processes (this is the default in Kubernetes), if no alternative is provided. - `runtime/default` - The default container runtime profile is used. - `docker/default` - The Docker default seccomp profile is used. Deprecated as of Kubernetes 1.11. Use `runtime/default` instead. - `localhost/<path>` - Specify a profile as a file on the node located at `<seccomp_root>/<path>`, where `<seccomp_root>` is defined via the `--seccomp-profile-root` flag on the Kubelet. --> - `unconfined` - 如果没有提供替代方案，则 Seccomp 不会应用于容器进程 (这是 Kubernetes 中的默认设置)。 - `runtime/default` - 使用默认的容器运行时配置。 - `docker/default` -  使用 Docker 默认的 seccomp 配置。于 Kubernetes 1.11 弃用。使用 `runtime/default` 代替。 - `localhost/<path>` - 将配置文件指定为位于节点上 `<seccomp_root>/<path>` 目录下的文件， 其中通过 Kubelet 上的 `--seccomp-profile-root` 标志来定义 `<seccomp_root>`。 <!-- **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that specifies which values are allowed for the pod seccomp annotations. Specified as a comma-delimited list of allowed values. Possible values are those listed above, plus `*` to allow all profiles. Absence of this annotation means that the default cannot be changed. --> **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 用于指定 pod seccomp 注解允许哪些取值的注解。 指定为允许值的逗号分隔列表。可选值是上面列出的值，加上 `*` 以允许所有配置文件。缺少此注解意味着无法更改默认值。 ### Sysctl <!-- By default, all safe sysctls are allowed. --> 默认情况下允许所有安全的 sysctl。 <!-- - `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination of safe and unsafe sysctls in the list. To forbid setting any sysctls, use `*` on its own. - `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by the default list, so long as these are not listed in `forbiddenSysctls`. --> - `forbiddenSysctls` - 排除特定的 sysctl。您可以在列表中禁止安全的和不安全的 sysctl 的组合。要禁止设置任意 sysctl，请单独使用 `*`。 - `allowedUnsafeSysctls` - 允许在默认列表中被禁用的特定 sysctl，只要这些 sysctl 没有在 `forbiddenSysctls` 中列出。 <!-- Refer to the [Sysctl documentation]( /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy). --> 参考 [Sysctl 文档]( /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy)。 {{% /capture %}} {{% capture whatsnext %}} <!-- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. --> 关于 api 细节参考 [Pod 安全策略指南](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)。 {{% /capture %}} </ins>

This chinese version is not updated. allowPrivilegeEscalation is not mentioned, and there are no examples for default psp
/language zh /kind cleanup
WIP
/assign
any progress?
Sorry for the long delay... finally pushed.


Question: <ins> --- title: ボリュームヘルスモニタリング content_type: concept weight: 100 --- <!-- overview --> {{< feature-state for_k8s_version="v1.21" state="alpha" >}} {{< glossary_tooltip text="CSI" term_id="csi" >}}ボリュームヘルスモニタリングにより、CSIドライバーは、基盤となるストレージシステムから異常なボリューム状態を検出し、それらを{{< glossary_tooltip text="PVC" term_id= "persistent-volume-claim" >}}または{{< glossary_tooltip text="Pod" term_id="pod" >}}のイベントとして報告できます。 <!-- body --> ## ボリュームヘルスモニタリング Kubernetes _volume health monitoring_ は、KubernetesがContainerStorageInterface(CSI)を実装する方法の一部です。ボリュームヘルスモニタリング機能は、外部のヘルスモニターコントローラーと{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}の2つのコンポーネントで実装されます。 CSIドライバーがコントローラー側からのボリュームヘルスモニタリング機能をサポートしている場合、CSIボリュームで異常なボリューム状態が検出されると、関連する{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}(PVC)でイベントが報告されます。 外部ヘルスモニター{{< glossary_tooltip text="コントローラー" term_id="controller" >}}も、ノード障害イベントを監視します。`enable-node-watcher`フラグをtrueに設定することで、ノード障害の監視を有効にできます。外部ヘルスモニターがノード障害イベントを検出すると、コントローラーは、このPVCを使用するポッドが障害ノード上にあることを示すために、PVCでイベントが報告されることを報告します。 CSIドライバーがノード側からのボリュームヘルスモニタリング機能をサポートしている場合、CSIボリュームで異常なボリューム状態が検出されると、PVCを使用するすべてのPodでイベントが報告されます。さらに、ボリュームヘルス情報はKubelet VolumeStatsメトリクスとして公開されます。新しいメトリックkubelet_volume_stats_health_status_abnormalが追加されました。このメトリックには`namespace`と`persistentvolumeclaim`の2つのラベルが含まれます。カウントは1または0です。1はボリュームが異常であることを示し、0はボリュームが正常であることを示します。詳細については、[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)を確認してください。 {{< note >}} ノード側からこの機能を使用するには、`CSIVolumeHealth`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。 {{< /note >}} ## {{% heading "whatsnext" %}} [CSIドライバーのドキュメント](https://kubernetes-csi.github.io/docs/drivers.html)を参照して、この機能を実装しているCSIドライバーを確認してください。 </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. --Translate into Japanese Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question:
 --- title: Update API Objects in Place Using kubectl patch description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch. content_template: templates/task weight: 40 --- {{% capture overview %}} This task shows how to use `kubectl patch` to update an API object in place. The exercises in this task demonstrate a strategic merge patch and a JSON merge patch. {{% /capture %}} {{% capture prerequisites %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{% /capture %}} {{% capture steps %}} ## Use a strategic merge patch to update a Deployment Here's the configuration file for a Deployment that has two replicas. Each replica is a Pod that has one container: {{< codenew file="application/deployment-patch.yaml" >}} Create the Deployment: ```shell kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml ``` View the Pods associated with your Deployment: ```shell kubectl get pods ``` The output shows that the Deployment has two Pods. The `1/1` indicates that each Pod has one container: ``` NAME                        READY     STATUS    RESTARTS   AGE patch-demo-28633765-670qr   1/1       Running   0          23s patch-demo-28633765-j5qs3   1/1       Running   0          23s ``` Make a note of the names of the running Pods. Later, you will see that these Pods get terminated and replaced by new ones. At this point, each Pod has one Container that runs the nginx image. Now suppose you want each Pod to have two containers: one that runs nginx and one that runs redis. Create a file named `patch-file.yaml` that has this content: ```yaml spec: template: spec: containers: - name: patch-demo-ctr-2 image: redis ``` Patch your Deployment: {{< tabs name="kubectl_patch_example" >}} {{{< tab name="Bash" codelang="bash" >}} kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} kubectl patch deployment patch-demo --patch $(Get-Content patch-file.yaml -Raw) {{< /tab >}}} {{< /tabs >}} View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The output shows that the PodSpec in the Deployment has two Containers: ```shell containers: - image: redis imagePullPolicy: Always name: patch-demo-ctr-2 ... - image: nginx imagePullPolicy: Always name: patch-demo-ctr ... ``` View the Pods associated with your patched Deployment: ```shell kubectl get pods ``` The output shows that the running Pods have different names from the Pods that were running previously. The Deployment terminated the old Pods and created two new Pods that comply with the updated Deployment spec. The `2/2` indicates that each Pod has two Containers: ``` NAME                          READY     STATUS    RESTARTS   AGE patch-demo-1081991389-2wrn5   2/2       Running   0          1m patch-demo-1081991389-jmg7b   2/2       Running   0          1m ``` Take a closer look at one of the patch-demo Pods: ```shell kubectl get pod <your-pod-name> --output yaml ``` The output shows that the Pod has two Containers: one running nginx and one running redis: ``` containers: - image: redis ... - image: nginx ... ``` ### Notes on the strategic merge patch The patch you did in the preceding exercise is called a *strategic merge patch*. Notice that the patch did not replace the `containers` list. Instead it added a new Container to the list. In other words, the list in the patch was merged with the existing list. This is not always what happens when you use a strategic merge patch on a list. In some cases, the list is replaced, not merged. With a strategic merge patch, a list is either replaced or merged depending on its patch strategy. The patch strategy is specified by the value of the `patchStrategy` key in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec` struct has a `patchStrategy` of `merge`: ```go type PodSpec struct { ... Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...` ``` You can also see the patch strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json): ```json "io.k8s.api.core.v1.PodSpec": { ... "containers": { "description": "List of containers belonging to the pod. ... }, "x-kubernetes-patch-merge-key": "name", "x-kubernetes-patch-strategy": "merge" }, ``` And you can see the patch strategy in the [Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). Create a file named `patch-file-tolerations.yaml` that has this content: ```yaml spec: template: spec: tolerations: - effect: NoSchedule key: disktype value: ssd ``` Patch your Deployment: ```shell kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)" ``` View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The output shows that the PodSpec in the Deployment has only one Toleration: ```shell tolerations: - effect: NoSchedule key: disktype value: ssd ``` Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the strategic merge patch uses the default patch strategy, which is `replace`. ```go type PodSpec struct { ... Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"` ``` ## Use a JSON merge patch to update a Deployment A strategic merge patch is different from a [JSON merge patch](https://tools.ietf.org/html/rfc7386). With a JSON merge patch, if you want to update a list, you have to specify the entire new list. And the new list completely replaces the existing list. The `kubectl patch` command has a `type` parameter that you can set to one of these values:

Parameter value	Merge type

json	JSON Patch, RFC 6902

merge	JSON Merge Patch, RFC 7386

strategic	Strategic merge patch

 For a comparison of JSON patch and JSON merge patch, see [JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/). The default value for the `type` parameter is `strategic`. So in the preceding exercise, you did a strategic merge patch. Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml` that has this content: ```yaml spec: template: spec: containers: - name: patch-demo-ctr-3 image: gcr.io/google-samples/node-hello:1.0 ``` In your patch command, set `type` to `merge`: ```shell kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)" ``` View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The `containers` list that you specified in the patch has only one Container. The output shows that your list of one Container replaced the existing `containers` list. ```shell spec: containers: - image: gcr.io/google-samples/node-hello:1.0 ... name: patch-demo-ctr-3 ``` List the running Pods: ```shell kubectl get pods ``` In the output, you can see that the existing Pods were terminated, and new Pods were created. The `1/1` indicates that each new Pod is running only one Container. ```shell NAME                          READY     STATUS    RESTARTS   AGE patch-demo-1307768864-69308   1/1       Running   0          1m patch-demo-1307768864-c86dc   1/1       Running   0          1m ``` ## Alternate forms of the kubectl patch command The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or directly on the command line. Create a file named `patch-file.json` that has this content: ```json { "spec": { "template": { "spec": { "containers": [ { "name": "patch-demo-ctr-2", "image": "redis" } ] } } } } ``` The following commands are equivalent: ```shell kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" kubectl patch deployment patch-demo --patch 'spec:n template:n  spec:n   containers:n   - name: patch-demo-ctr-2n     image: redis' kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}' ``` ## Summary In this exercise, you used `kubectl patch` to change the live configuration of a Deployment object. You did not change the configuration file that you originally used to create the Deployment object. Other commands for updating API objects include [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate), [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit), [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace), [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), and [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply). {{% /capture %}} {{% capture whatsnext %}} * [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/) * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) * [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) {{% /capture %}}

This is a Feature Request We have a pretty good doc on various ways to patching an object: However, the current location of the content is wrong. It is not about an application. It is about more generic ways to change an API object. What would you like to be Revise and move the content to object management section so that readers would enjoy playing with the many ways of patching an object.
/assign
/kind cleanup /language en /priority backlog


Question: - Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development. - Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/). --> <del> ## 其他贡献方式 </del> <ins> ## 其他贡献方式 {#other-ways-to-contribute} </ins> - 访问 [Kubernetes 社区网站](/zh/community/)。 参与 Twitter 或 Stack Overflow, 了解 Kubernetes 当地的聚会和活动, 等等。 <del> - 阅读[贡献者备忘单](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) ，参与 Kubernetes 功能开发。 </del> <ins> - 阅读[贡献者备忘单](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)，参与 Kubernetes 功能开发。 </ins> - 提交一篇[博客文章或案例研究](/zh/docs/contribute/new-content/blogs-case-studies/)。

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


Question: requests: cpu: 700m memory: 200Mi <del> ... </del> <ins> ... status: </ins> qosClass: Guaranteed ```

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The location of qosClass is not correct in the last example, which is a result of the following command: Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/kind bug /language en /priority backlog /sig scheduling
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
Contribute to the K8s codebase

© {{ 'now' | date: "%Y" }} The Kubernetes Authors | Distributed under CC BY 4.0

 © {{ 'now' | date: "%Y" }} The Kubernetes Authors | Documentation Distributed under CC BY 4.0

 Copyright © {{ 'now' | date: "%Y" }} The Linux Foundation®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: https://www.linuxfoundation.org/trademark-usage

Add trademark footer to properly indicate trademark guidelines around kubernetes. Something like:
Do we want to remove " 2016 The Kubernetes Authors | Distributed under CC BY 4.0" or add to it?
I'd add to it. I'd also specify that "Documentation Distributed under CC BY 4.0" Other than that, LGTM!


Question: kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。 <del> UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 </del> <ins> UIはコマンドを実行しているマシンから _のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 </ins> {{< note >}} Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。

ref: ! [x] [x] [x] [ ] content/ja/docs/concepts/configuration/manage-resources- [ ] [x] content/ja/docs/concepts/configuration/pod-priority- [x] [x] [ ] content/ja/docs/concepts/containers/runtime- [x] content/ja/docs/concepts/overview/kubernetes- [x] content/ja/docs/concepts/extend-kubernetes/api-extension/custom- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with-objects/common- [x] content/ja/docs/concepts/overview/working-with-objects/field- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with- [ ] content/ja/docs/concepts/scheduling-eviction/assign-pod- [ ] content/ja/docs/concepts/scheduling-eviction/kube- [x] content/ja/docs/concepts/scheduling-eviction/taint-and- [x] [x] content/ja/docs/concepts/security/pod-security- [x] content/ja/docs/concepts/services- [x] content/ja/docs/concepts/storage/persistent- [x] [x] content/ja/docs/concepts/workloads/controllers/cron- [x] [x] [x] [x] content/ja/docs/concepts/workloads/pods/pod- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster- [x] content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting- [ ] content/ja/docs/tasks/access-application-cluster/web-ui- [x] content/ja/docs/tasks/debug-application-cluster/get-shell-running- [x] content/ja/docs/tasks/run-application/horizontal-pod-autoscale- [x] content/ja/docs/tasks/run-application/run-single-instance-stateful- [x] content/ja/docs/tutorials/stateful-application/basic-stateful- [x] content/ja/docs/tutorials/stateful- (grep) /language ja
/triage accepted
/assign
/kind bug
I'm facing same issue lol :smiley: Feel free to mention me for review if create PRs for this.


Question: [build.environment] NODE_VERSION = "10.20.0" <del> HUGO_VERSION = "0.82.0" </del> <ins> HUGO_VERSION = "0.87.0" </ins> RUBY_VERSION = "3.0.1" [context.production.environment]

Look into evaluating how we can make building the site take less memory / cpu. As has grown, it went from a small hugo build to what it is today (a large, memory and file hungry build). This is all good though, it means we are adding content and localizations. Look into ways to reduce build time. A few options come to mind: Can we remove a large chunk of unused content? Can we build only a small subset of docs (easily and portable to the various localizations)? Are there any optimizations in hugo itself? There should be a way to reduce the amount of resources required to build . Considering there isn't a clear solution, I won't mark as good-first-issue. /sig docs /triage accepted
Idea: run the build localization-by-localization. I don't know if Hugo supports this but if it might let us run 14 shorter builds (potentially in parallel) rather than 1 long one. Idea: look for image resize options at build time. If reasonable to do so, replace the source image with what it gets resized to.
This might be an area where we could look for resources from CNCF to help with it - especially if the fix is applicable across multiple CNCF projects.


Question: When restoring the cluster, use the `--data-dir` option to specify to which folder the cluster should be restored: ```shell <del> ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db </del> <ins> etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db </ins> ``` where `<data-dir-location>` is a directory that will be created during the restore process. <del> Yet another example would be to first export the `ETCDCTL_API` environment variable: </del> <ins> The below example depicts the usage of the `etcdctl` tool for the restore operation: {{< note >}} The usage of `etcdctl` for restoring has been deprecated since etcd v3.5.x and may be removed from a future etcd release. {{< /note >}} </ins> ```shell export ETCDCTL_API=3

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: This issue refers to the page Kubernetes Documentation Tasks Administer a Cluster Operating etcd clusters for Kubernetes In the section titled "Restoring an etcd cluster", the commands use the utility to restore from an existing snapshot. Using for restoring snapshots is deprecated since etcd version 3.5.x Usage of this command displays a deprecation warning and suggests to use utility instead as shown below. I feel this change is necessary as the etcd official documentation has already changed to reflect the use of the utility, as can be seen in the etcd documentation referenced in this section - Proposed Solution: I have raised a PR to depict the use of the utility for restoring from an existing snapshot. Before submitting the PR, I have tested the changes on a local Kubernetes cluster for v1.28.0 and I can confirm everything works as expected. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.28.x and above <!--Additional Information:--
/assign
I have raised a PR to depict the use of the etcdutl utility for restoring from an existing snapshot. Any comments or improvements are welcome.
/retitle Use etcdutl instead of etcdctl for restoring an etcd cluster /language en
/sig etcd
/triage accepted
Also see


Question: <!-- overview --> <del> Kubernetes runs your workload by placing containers into Pods to run on _Nodes_. </del> <ins> Kubernetes runs your {{< glossary_tooltip text="workload" term_id="workload" >}} by placing containers into Pods to run on _Nodes_. </ins> A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}

This is a Feature Request What would you like to be Below are terms that can use the addition of a glossary tooltip to show the meaning of the said term.Below points can be to section of Nodes page which will help users for quick follow-ups. Why is this needed These references can help user understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments :
/sig docs / language en /assign
If triage is accepted, i would be happy to contribute on it. PTAL.
/language en Fixed here .
/triage accepted


Question: weight: 80 --- <!-- overview --> <del> This page shows how to create an External Load Balancer. {{< note >}} This feature is only available for cloud providers or environments which support external load balancers. {{< /note >}} </del> <ins> This page shows how to create an external load balancer. </ins> <del> When creating a service, you have the option of automatically creating a cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes </del> <ins> When creating a {{< glossary_tooltip text="Service" term_id="service" >}}, you have the option of automatically creating a cloud load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes, </ins> _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. <del> For information on provisioning and using an Ingress resource that can give services externally-reachable URLs, load balance the traffic, terminate SSL etc., please check the [Ingress](/docs/concepts/services-networking/ingress/) </del> <ins> You can also use an {{< glossary_tooltip term_id="ingress" >}} in place of Service. For more information, check the [Ingress](/docs/concepts/services-networking/ingress/) </ins> documentation. ## {{% heading "prerequisites" %}} <del> * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} Your cluster must be running in a cloud or other environment that already has support for configuring external load balancers. </ins> <!-- steps --> <del> ## Configuration file </del> <ins> ## Create a Service ### Create a Service from a manifest </ins> To create an external load balancer, add the following line to your <del> [service configuration file](/docs/concepts/services-networking/service/#loadbalancer): </del> <ins> Service manifest: </ins> ```yaml type: LoadBalancer ``` <del> Your configuration file might look like: </del> <ins> Your manifest might then look like: </ins> ```yaml apiVersion: v1

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: mentions: (see ) Weights aren't built in to Service / Endpoints / EndpointSlice / Ingress but you can indicate weighting with annotations and similar mechanisms. For example: https://kubernetes- Proposed Solution: Remove the text: Revise to explain that each implementation uses its own mechanisms for weighting and that these are not standardized. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.19 Additional Information: /language en /sig network
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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
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-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/reopen /remove-lifecycle rotten
Reopened this issue.

<detailsIn response to : /reopen /remove-lifecycle rotten 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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:


Question:
想要成为KCSP吗?

  Kubernetes 认证的发行版本、托管平台以及安装工具
软件合规性确保各厂商的 Kubernetes 版本都支持必需的 API。

  <button id="conformance" class="button" onClick="updateSrc(this.id)">参见合规性合作伙伴</button>

  Kubernetes 认证的发行版本、托管平台以及安装工具
软件合规性确保各厂商的 Kubernetes 版本都支持必需的 API。

  <button id="conformance" class="button" onClick="updateSrc(this.id)">参见合规性合作伙伴</button>

想要成为Kubernetes 认证的厂商吗?

  Kubernetes 培训合作伙伴

经过审核的培训机构在云原生技术培训方面有深厚的经验。

  <button id="ktp" class="button" onClick="updateSrc(this.id)">参见 KTP 合作伙伴</button>

想要成为KTP吗?

Kubernetes 培训合作伙伴

经过审核的培训机构在云原生技术培训方面有深厚的经验。

  <button id="ktp" class="button" onClick="updateSrc(this.id)">参见 KTP 合作伙伴</button>

想要成为KTP吗?

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: Missing partners in You can see to find the different. Proposed Solution: Update Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /language zh /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: <ins> apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: name: mysecret items: - key: username path: my-group/my-username - secret: name: mysecret2 items: - key: password path: my-group/my-password mode: 511 </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. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: ```shell # This assumes you are using filesystem-hosted static Pod configuration <del> # Run these commands on the node where the kubelet is running </del> <ins> # Run these commands on the node where the container is running </ins> # mv /etc/kubernetes/manifests/static-web.yaml /tmp sleep 20

This is a Bug Report There is a section named in page, we should add log info observation for static pod as well in the page for user benefits. Also there is already a page with a section dedicated to it. I think that will be really useful. Problem: No log observation method mentioned in the Observe static pod behaviour section Proposed Solution: Add a reference link directing to in the aforementioned section Page to Update:
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
/sig docs /language en
/assign
Would we also want to document how to work out which container ID is the right one to check?
Hi , This section might be explaining subtly how to see your container. would you like a detailed version of how this can be defined?
Hi , I already started working on this issue yesterday, is it okay if I carry forward or you want to take this up?
is a glimpse of what i in the static-pod docs Also there can be more addition to the reference section i.e. section. I some links that can be useful for understanding more about static pod.
/unassign


Question: 1. Tải về phiên bản mới nhất với câu lệnh: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/`curl -LS https://dl.k8s.io/release/stable.txt`/bin/linux/amd64/kubectl </ins> ``` <del> Để tải về phiên bản cụ thể, hãy thay thế phần `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` trong câu lệnh với một phiên bản cụ thể. </del> <ins> Để tải về phiên bản cụ thể, hãy thay thế phần `$(curl -LS https://dl.k8s.io/release/stable.txt)` trong câu lệnh với một phiên bản cụ thể. </ins> Ví dụ như, để tải về phiên bản {{< param "fullversion" >}} trên Linux, hãy nhập như sau: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </ins> ``` 2. Tạo kubectl binary thực thi.

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: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.


Question: * `initialDelaySeconds`: Number of seconds after the container has started before startup, liveness or readiness probes are initiated. If a startup  probe is defined, liveness and <del> readiness probe delays do not begin until the startup probe has succeeded. Defaults to 0 seconds. Minimum value is 0. </del> <ins> readiness probe delays do not begin until the startup probe has succeeded. If the value of `periodSeconds` is greater than `initialDelaySeconds` then the `initialDelaySeconds` would be ignored. Defaults to 0 seconds. Minimum value is 0. </ins> * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 seconds. The minimum value is 1. * `timeoutSeconds`: Number of seconds after which the probe times out.

This is a Bug Report Problem: The intial definiton given in doesn't describe that if the first probe time will be = . For example: The pod will be marked as after 60s, (tested in k8s v1.22.10). Moreover, the given if i read this code correctly, then the check is done for and the check for is done after assuming that value of Proposed Solution: Allign code and the documentation. Page to Update:
/sig docs /language en
/assign
I did tested this on the k8s 1.27 and it's still same.
I believe this is a corner case. Why do you set initialDelaySeconds to be shorter than perdioSeconds in the first place? I'm not objecting the clarification, BTW. What I am wondering is if there is a real case people will do this.
Okay. I get it now. The example manifest has a problem to fix. Thanks for raising up this.
/triage accepted
thanks :)


Question: --- <del> title: "Scheduling and Eviction" </del> <ins> title: "Scheduling, Preemption and Eviction" </ins> weight: 90 description: > <del> In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. Eviction is the process of proactively failing one or more Pods on resource-starved Nodes. </del> <ins> In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. Preemption is the process of terminating Pods with lower Priority so that Pods with higher Priority can schedule on Nodes. Eviction is the process of proactively terminating one or more Pods on resource-starved Nodes. </ins> ---

Suggestion from in /sig docs /assign cc
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
I think this makes sense. I'd like to keep the URL but change the display title to Scheduling, Preemption and Eviction.
sgtm


Question: mkdir -p /opt/bin ARCH="amd64" cd /opt/bin <del> curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} </del> <ins> curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} </ins> chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.2.7"

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: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.


Question: [release_full_details_initial_text] other = "Complete" <ins> [release_information_navbar] other = "Release Information" </ins> [release_minor_version] other = "Minor Version"

You can only get to the localized version of the page by going to the English version, and then clicking on the language dropdown to find a translation. If you are already on a localized version of the site, and the page exists in the selected language, it redirects you to the English version. See this comment for more info: Originally posted by in /area web-development
/area localization
/triage accepted
/priority important-longterm
/assign


Question:
  --skip_headers

If true, avoid header prefixes in the log messages

 --skip_log_headers

If true, avoid headers when opening log files

 --stderrthreshold int     Default: 2

logs at or above this threshold go to stderr

  --udp-timeout duration     Default: 250ms

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: ! xref: Has references to some CLI arguments that are not valid for . Seem to be side effect of changes went into Proposed Solution: Remove the invalid flags from the documentation in Page to Update:
/language en /triage accepted
/assign
/assign
Thanks for taking care of this :)


Question: <!-- overview --> このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。 <del> Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。 </del> <ins> Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用および管理に必要な専門知識に基づいてインストレーションタイプを選んでください。 Kuerbetesクラスターをローカルマシン、クラウド、データセンターにデプロイするために、[Kubernetesをダウンロード](/releases/download/)できます。 </ins> <del> Kubernetesクラスターはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。 </del> <ins> {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}や{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}のようないくつかの[Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)も、[コンテナイメージ](/releases/download/#container-images)としてクラスター内にデプロイできます。 可能であればコンテナイメージとしてKubernetesのコンポーネントを実行し、それらのコンポーネントをKubernetesで管理するようにすることを**推奨**します。 コンテナを実行するコンポーネント(特にkubelet)は、このカテゴリーには含まれません。 Kubernetesクラスターを自分で管理するのを望まないなら、[認定プラットフォーム](/ja/docs/setup/production-environment/turnkey-solutions/)をはじめとする、マネージドのサービスを選択することもできます。 複数のクラウドやベアメタル環境にまたがった、その他の標準あるいはカスタムのソリューションもあります。 </ins> <!-- body --> ## 環境について学ぶ Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。 <ins> [ツールのインストール](/ja/docs/tasks/tools/)を参照してください。 ## プロダクション環境 [プロダクション環境](/ja/docs/setup/production-environment/)用のソリューションを評価する際には、Kubernetesクラスター(または*抽象概念*)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 </ins> <del> ## 本番環境 </del> <ins> 自分で管理するクラスターであれば、Kubernetesをデプロイするための公式にサポートされているツールは[kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/)です。 </ins> <del> 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤー)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 </del> <ins> ## {{% heading "whatsnext" %}} </ins> <del> [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。 </del> <ins> - [Kubernetesのダウンロード](/releases/download/) - `kubectl`を含む、ツールのダウンロードと[インストール](/ja/docs/tasks/tools/) - 新しいクラスターのための[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)の選択 - クラスターセットアップの[ベストプラクティス](/ja/docs/setup/best-practices/)を学ぶ Kubernetesは、その{{< glossary_tooltip term_id="control-plane" text="コントロールプレーン" >}}がLinux上で実行されるよう設計されています。 クラスター内では、Linux上でも、Windowsを含めた別のオペレーティングシステム上でも、アプリケーションを実行できます。 - [Windowsノードのクラスターのセットアップ](/docs/concepts/windows/)について学ぶ </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. --Update Japanese translation sync to original English version Wed Nov 23 15:06:08 2022 +0530. Why is this needed outdated doc Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: "nginx-svc":        {&api.Service{}}, }, "application/ssa": { <del> "nginx-deployment":               {&apps.Deployment{}}, "nginx-deployment-no-replicas":   {&apps.Deployment{}}, "nginx-deployment-replicas-only": {&apps.Deployment{}}, </del> <ins> "nginx-deployment":             {&apps.Deployment{}}, "nginx-deployment-no-replicas": {&apps.Deployment{}}, </ins> }, "application/web": { "web":          {&api.Service{}, &apps.StatefulSet{}},

The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations.

For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.


Question:
 HostProcess
Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. {{< feature-state for_k8s_version="v1.23" state="beta" >}}

Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. {{< feature-state for_k8s_version="v1.26" state="stable" >}}

Restricted Fields

spec.securityContext.windowsOptions.hostProcess

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: /docs/reference/deprecation-policy/     /docs/reference/using-api/deprecation-policy/ 301 <ins> /docs/reference/generated/kubectl/kubectl-commands/     /docs/reference/kubectl/ 301 </ins> /docs/reference/generated/cloud-controller-manager/     /docs/reference/command-line-tools-reference/cloud-controller-manager/ 301 /docs/reference/generated/kubelet/     /docs/reference/command-line-tools-reference/kubelet/ 301 /docs/reference/generated/kube-apiserver/     /docs/reference/command-line-tools-reference/kube-apiserver/ 301

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 Replace with a redirect to Why is this needed We the generator for Comments /language en /priority backlog /lifecycle frozen we should definitely clean this up one day
/retitle Drop legacy kubectl reference page
/triage accepted
I want to try to help with this. /assign
a redirect; we should also delete the page we're redirecting people away from.


Question: <ins> apiVersion: v1 kind: Service metadata: name: my-service labels: app: MyApp spec: ipFamily: IPv6 type: LoadBalancer selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 </ins>  No newline at end of file

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