Question: [languages.uk.params] time_format_blog = "02.01.2006" # A list of language codes to look for untranslated content, ordered from left to right. <del> language_alternatives = ["en"] </del> <ins> language_alternatives = ["en"] </ins>  No newline at end of file

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: ! Proposed Solution: when run make container-serve on windows 10 then got :loading translations: "": failed to load translations: toml: invalid character at start of key: . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Maybe-relevant issue:
first delete the i18n dir then run mklink /J "E:sourcecodek8s-websitei18n" "E:sourcecodek8s-websitedatai18n"
This is a Windows issue (and is almost a duplicate of ) /retitle Trouble previewing website locally on Windows
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
I want to work on this issue. /assign
/remove-lifecycle stale


Question: ### Uncordon the node <del> 1.  Bring the node back online by marking it schedulable: </del> <ins> -   Bring the node back online by marking it schedulable: </ins> ```shell # replace <node-to-drain> with the name of your node

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--indentation issue Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--18 <!--Additional Information:--fix the page indentation
/sig cluster-lifecycle docs hi, can you show which section you think is wrong or maybe provide a screenshot?
/sig cluster-lifecycle docs Attached screenshots
i don't see the attachments, possibly because you replied via email. try adding them using the GitHub web UI.
! ! ! !
Page alignment or indentation not proper looks.
ok, i can confirm this. hi, was this broken by this PR, or maybe something on the hugo side changed recently?
The Hugo upgrade was PR
/kind bug /priority important-longterm
I've tried to make a work around for this. It looks like tabs shortcodes with code snippets inside them don't play well with shortcodes (see issue ).
I will take a stab at cleaning this up assuming work isn't currently being done. We might have to adjust the page slightly until capture is removed. /assign
I can share some WIP in case it helps
thanks for taking a look and
oof, sorry I saw this after I opened the PR. That does help! I was scratching my head on some of these bugs. Let me know if you want me to modify my PR to incorporate some of your suggestions or vice versa. I was poking fun of the page on twitter and felt obligated to try to fix it :smile:
Busy at the moment I'm afraid. Feel free to snarf any bits that look useful.


Question: <ins> --- title: 使用 AppArmor 限制容器对资源的访问 content_type: tutorial weight: 10 --- <!-- title: Restrict a Container's Access to Resources with AppArmor content_type: tutorial weight: 10 --> <!-- overview --> {{< feature-state for_k8s_version="v1.4" state="beta" >}} <!-- AppArmor is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either *enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports violations. --> AppArmor 是一个 Linux 内核安全模块， 它补充了基于标准 Linux 用户和组的权限，将程序限制在一组有限的资源中。 AppArmor 可以配置为任何应用程序减少潜在的攻击面，并且提供更加深入的防御。 它通过调整配置文件进行配置，以允许特定程序或容器所需的访问， 如 Linux 权能字、网络访问、文件权限等。 每个配置文件都可以在 *强制（enforcing）* 模式（阻止访问不允许的资源）或 *投诉（complain）* 模式（仅报告冲突）下运行。 <!-- AppArmor can help you to run a more secure deployment by restricting what containers are allowed to do, and/or provide better auditing through system logs. However, it is important to keep in mind that AppArmor is not a silver bullet and can only do so much to protect against exploits in your application code. It is important to provide good, restrictive profiles, and harden your applications and cluster from other angles as well. --> AppArmor 可以通过限制允许容器执行的操作， 和/或通过系统日志提供更好的审计来帮助你运行更安全的部署。 但是，重要的是要记住 AppArmor 不是灵丹妙药， 只能做部分事情来防止应用程序代码中的漏洞。 提供良好的限制性配置文件，并从其他角度强化你的应用程序和集群非常重要。 ## {{% heading "objectives" %}} <!-- * See an example of how to load a profile on a node * Learn how to enforce the profile on a Pod * Learn how to check that the profile is loaded * See what happens when a profile is violated * See what happens when a profile cannot be loaded --> * 查看如何在节点上加载配置文件示例 * 了解如何在 Pod 上强制执行配置文件 * 了解如何检查配置文件是否已加载 * 查看违反配置文件时会发生什么 * 查看无法加载配置文件时会发生什么 ## {{% heading "prerequisites" %}} <!-- Make sure: --> 确保： <!-- 1. Kubernetes version is at least v1.4 -- Kubernetes support for AppArmor was added in v1.4. Kubernetes components older than v1.4 are not aware of the new AppArmor annotations, and will **silently ignore** any AppArmor settings that are provided. To ensure that your Pods are receiving the expected protections, it is important to verify the Kubelet version of your nodes: ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: v1.4.0 gke-test-default-pool-239f5d02-x1kf: v1.4.0 gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` --> 1. Kubernetes 版本至少是 v1.4 —— AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。 早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注解 并且将会 **默认忽略** 提供的任何 AppArmor 设置。 为了确保你的 Pod 能够得到预期的保护，必须验证节点的 Kubelet 版本： ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: v1.4.0 gke-test-default-pool-239f5d02-x1kf: v1.4.0 gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` <!-- 2. AppArmor kernel module is enabled -- For the Linux kernel to enforce an AppArmor profile, the AppArmor kernel module must be installed and enabled. Several distributions enable the module by default, such as Ubuntu and SUSE, and many others provide optional support. To check whether the module is enabled, check the `/sys/module/apparmor/parameters/enabled` file: ```shell cat /sys/module/apparmor/parameters/enabled Y ``` If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor options if the kernel module is not enabled. {{< note >}} Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux kernel, including patches that add additional hooks and features. Kubernetes has only been tested with the upstream version, and does not promise support for other features. {{< /note >}} --> 2. AppArmor 内核模块已启用 —— 要使 Linux 内核强制执行 AppArmor 配置文件， 必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块， 如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查 `/sys/module/apparmor/parameters/enabled` 文件： ```shell cat /sys/module/apparmor/parameters/enabled Y ``` 如果 Kubelet 包含 AppArmor 支持（>= v1.4）， 但是内核模块未启用，它将拒绝运行带有 AppArmor 选项的 Pod。 {{< note >}} Ubuntu 携带了许多没有合并到上游 Linux 内核中的 AppArmor 补丁， 包括添加附加钩子和特性的补丁。Kubernetes 只在上游版本中测试过，不承诺支持其他特性。 {{< /note >}} <!-- 3. Container runtime supports AppArmor -- Currently all common Kubernetes-supported container runtimes should support AppArmor, like {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} or {{< glossary_tooltip term_id="containerd" >}}. Please refer to the corresponding runtime documentation and verify that the cluster fulfills the requirements to use AppArmor. --> 3. 容器运行时支持 AppArmor —— 目前所有常见的 Kubernetes 支持的容器运行时都应该支持 AppArmor， 像 {{< glossary_tooltip term_id="docker">}}，{{< glossary_tooltip term_id="cri-o" >}} 或 {{< glossary_tooltip term_id="containerd" >}}。 请参考相应的运行时文档并验证集群是否满足使用 AppArmor 的要求。 <!-- 4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each container should be run with. If any of the specified profiles is not already loaded in the kernel, the Kubelet (>= v1.4) will reject the Pod. You can view which profiles are loaded on a node by checking the `/sys/kernel/security/apparmor/profiles` file. For example: ```shell ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" ``` ``` apparmor-test-deny-write (enforce) apparmor-test-audit-write (enforce) docker-default (enforce) k8s-nginx (enforce) ``` For more details on loading profiles on nodes, see [Setting up nodes with profiles](#setting-up-nodes-with-profiles). --> 4. 配置文件已加载 —— 通过指定每个容器都应使用的 AppArmor 配置文件， AppArmor 会被应用到 Pod 上。如果指定的任何配置文件尚未加载到内核， Kubelet（>= v1.4） 将拒绝 Pod。 通过检查 `/sys/kernel/security/apparmor/profiles` 文件， 可以查看节点加载了哪些配置文件。例如: ```shell ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" ``` ``` apparmor-test-deny-write (enforce) apparmor-test-audit-write (enforce) docker-default (enforce) k8s-nginx (enforce) ``` 有关在节点上加载配置文件的详细信息，请参见[使用配置文件设置节点](#setting-up-nodes-with-profiles)。 <!-- As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod with AppArmor options if any of the prerequisites are not met. You can also verify AppArmor support on nodes by checking the node ready condition message (though this is likely to be removed in a later release): --> 只要 Kubelet 版本包含 AppArmor 支持(>=v1.4)， 如果不满足这些先决条件，Kubelet 将拒绝带有 AppArmor 选项的 Pod。 你还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持（尽管这可能会在以后的版本中删除）： ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled ``` <!-- lessoncontent --> <!-- ## Securing a Pod --> ## 保护 Pod {#securing-a-pod} {{< note >}} <!-- AppArmor is currently in beta, so options are specified as annotations. Once support graduates to general availability, the annotations will be replaced with first-class fields (more details in [Upgrade path to GA](#upgrade-path-to-general-availability)). --> AppArmor 目前处于 Beta 阶段，因此选项以注解形式设定。 一旦 AppArmor 支持进入正式发布阶段，注解将被替换为一阶的资源字段 （更多详情参见[升级到 GA 的途径](#upgrade-path-to-general-availability)）。 {{< /note >}} <!-- AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod container with, add an annotation to the Pod's metadata: --> AppArmor 配置文件是按 *逐个容器* 的形式来设置的。 要指定用来运行 Pod 容器的 AppArmor 配置文件，请向 Pod 的 metadata 添加注解： ```yaml container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref> ``` <!-- Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>` specifies the profile to apply. The `profile_ref` can be one of: --> `<container_name>` 的名称是配置文件所针对的容器的名称，`<profile_def>` 则设置要应用的配置文件。 `<profile_ref>` 可以是以下取值之一： <!-- * `runtime/default` to apply the runtime's default profile * `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>` * `unconfined` to indicate that no profiles will be loaded --> * `runtime/default` 应用运行时的默认配置 * `localhost/<profile_name>` 应用在主机上加载的名为 `<profile_name>` 的配置文件 * `unconfined` 表示不加载配置文件 <!-- See the [API Reference](#api-reference) for the full details on the annotation and profile name formats. --> 有关注解和配置文件名称格式的详细信息，请参阅[API 参考](#api-reference)。 <!-- Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been met, and then forwarding the profile selection to the container runtime for enforcement. If the prerequisites have not been met, the Pod will be rejected, and will not run. --> Kubernetes AppArmor 强制执行机制首先检查所有先决条件都已满足， 然后将所选的配置文件转发到容器运行时进行强制执行。 如果未满足先决条件，Pod 将被拒绝，并且不会运行。 <!-- To verify that the profile was applied, you can look for the AppArmor security option listed in the container created event: --> 要验证是否应用了配置文件，可以在容器创建事件中查找所列出的 AppArmor 安全选项： ```shell kubectl get events | grep Created ``` ``` 22s        22s         1         hello-apparmor     Pod       spec.containers{hello}   Normal    Created     {kubelet e2e-test-stclair-node-pool-31nt}   Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] ``` <!-- You can also verify directly that the container's root process is running with the correct profile by checking its proc attr: --> 你还可以通过检查容器的 proc attr，直接验证容器的根进程是否以正确的配置文件运行： ```shell kubectl exec <pod_name> cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` <!-- ## Example --> ## 举例 {#example} <!-- *This example assumes you have already set up a cluster with AppArmor support.* --> *本例假设你已经设置了一个集群使用 AppArmor 支持。* <!-- First, we need to load the profile we want to use onto our nodes. This profile denies all file writes: --> 首先，我们需要将要使用的配置文件加载到节点上。配置文件拒绝所有文件写入： ```shell #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } ``` <!-- Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our nodes. For this example we'll use SSH to install the profiles, but other approaches are discussed in [Setting up nodes with profiles](#setting-up-nodes-with-profiles). --> 由于我们不知道 Pod 将被调度到哪里，我们需要在所有节点上加载配置文件。 在本例中，我们将使用 SSH 来安装概要文件， 但是在[使用配置文件设置节点](#setting-up-nodes-with-profiles)中讨论了其他方法。 ```shell NODES=( # The SSH-accessible domain names of your nodes gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s) for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } EOF' done ``` <!-- Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile: --> 接下来，我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” Pod： {{< codenew file="pods/security/hello-apparmor.yaml" >}} ```shell kubectl create -f ./hello-apparmor.yaml ``` <!-- If we look at the pod events, we can see that the Pod container was created with the AppArmor profile "k8s-apparmor-example-deny-write": --> 如果我们查看 Pod 事件，我们可以看到 Pod 容器是用 AppArmor 配置文件 “k8s-apparmor-example-deny-write” 所创建的： ```shell kubectl get events | grep hello-apparmor ``` ``` 14s        14s         1         hello-apparmor   Pod                                Normal    Scheduled   {default-scheduler }                           Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2 14s        14s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulling     {kubelet gke-test-default-pool-239f5d02-gyn2}   pulling image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulled      {kubelet gke-test-default-pool-239f5d02-gyn2}   Successfully pulled image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Created     {kubelet gke-test-default-pool-239f5d02-gyn2}   Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989 ``` <!-- We can verify that the container is actually running with that profile by checking its proc attr: --> 我们可以通过检查该配置文件的 proc attr 来验证容器是否实际使用该配置文件运行： ```shell kubectl exec hello-apparmor -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` <!-- Finally, we can see what happens if we try to violate the profile by writing to a file: --> 最后，我们可以看到，如果我们尝试通过写入文件来违反配置文件会发生什么： ```shell kubectl exec hello-apparmor -- touch /tmp/test ``` ``` touch: /tmp/test: Permission denied error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 ``` <!-- To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded: --> 最后，让我们看看如果我们试图指定一个尚未加载的配置文件会发生什么： ```shell kubectl create -f /dev/stdin <<EOF ``` ```yaml apiVersion: v1 kind: Pod metadata: name: hello-apparmor-2 annotations: container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write spec: containers: - name: hello image: busybox command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ] EOF pod/hello-apparmor-2 created ``` ```shell kubectl describe pod hello-apparmor-2 ``` ``` Name:          hello-apparmor-2 Namespace:     default Node:          gke-test-default-pool-239f5d02-x1kf/ Start Time:    Tue, 30 Aug 2016 17:58:56 -0700 Labels:        <none> Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write Status:        Pending Reason:        AppArmor Message:       Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded IP: Controllers:   <none> Containers: hello: Container ID: Image:     busybox Image ID: Port: Command: sh -c echo 'Hello AppArmor!' && sleep 1h State:              Waiting Reason:           Blocked Ready:              False Restart Count:      0 Environment:        <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro) Conditions: Type          Status Initialized   True Ready         False PodScheduled  True Volumes: default-token-dnz7v: Type:    Secret (a volume populated by a Secret) SecretName:    default-token-dnz7v Optional:   false QoS Class:      BestEffort Node-Selectors: <none> Tolerations:    <none> Events: FirstSeen    LastSeen    Count    From                        SubobjectPath    Type        Reason        Message ---------    --------    -----    ----                        -------------    --------    ------        ------- 23s          23s         1        {default-scheduler }                         Normal      Scheduled     Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5 23s          23s         1        {kubelet e2e-test-stclair-node-pool-t1f5}             Warning        AppArmor    Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded ``` <!-- Note the pod status is Pending, with a helpful error message: `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message. --> 注意 Pod 呈现 Pending 状态，并且显示一条有用的错误信息： `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`。 还用相同的消息记录了一个事件。 <!-- ## Administration --> ## 管理 {#administration} <!-- ### Setting up nodes with profiles --> ### 使用配置文件设置节点 {#setting-up-nodes-with-profiles} <!-- Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto nodes. There are lots of ways to setup the profiles though, such as: --> Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。 有很多方法可以设置配置文件，例如： <!-- * Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to ensure the correct profiles are loaded. An example implementation can be found [here](https://git.k8s.io/kubernetes/test/images/apparmor-loader). * At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or image. * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). --> * 通过在每个节点上运行 Pod 的 [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)来确保加载了正确的配置文件。 可以在[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)找到实现示例。 * 在节点初始化时，使用节点初始化脚本(例如 Salt、Ansible 等)或镜像。 * 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。 <!-- The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles must be loaded onto every node.  An alternative approach is to add a node label for each profile (or class of profiles) on the node, and use a [node selector](/docs/concepts/configuration/assign-pod-node/) to ensure the Pod is run on a node with the required profile. --> 调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。 另一种方法是为节点上的每个配置文件（或配置文件类）添加节点标签， 并使用[节点选择器](/zh/docs/concepts/configuration/assign-pod-node/)确保 Pod 在具有所需配置文件的节点上运行。 <!-- ### Restricting profiles with the PodSecurityPolicy --> ### 使用 PodSecurityPolicy 限制配置文件 {#restricting-profiles-with-the-podsecuritypolicy} {{< note >}} <!-- PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. --> PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版本移除。 查看 [PodSecurityPolicy 文档](/zh/docs/concepts/policy/pod-security-policy/)获取更多信息。 {{< /note >}} <!-- If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: --> 如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。 要启用 PodSecurityPolicy，必须在 `apiserver` 上设置以下标志： ``` --enable-admission-plugins=PodSecurityPolicy[,others...] ``` <!-- The AppArmor options can be specified as annotations on the PodSecurityPolicy: --> AppArmor 选项可以指定为 PodSecurityPolicy 上的注解： ```yaml apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref> apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...] ``` <!-- The default profile name option specifies the profile to apply to containers by default when none is specified. The allowed profile names option specifies a list of profiles that Pod containers are allowed to be run with. If both options are provided, the default must be allowed. The profiles are specified in the same format as on containers. See the [API Reference](#api-reference) for the full specification. --> 默认配置文件名选项指定默认情况下在未指定任何配置文件时应用于容器的配置文件。 所允许的配置文件名称选项指定允许 Pod 容器运行期间所对应的配置文件列表。 如果同时提供了这两个选项，则必须允许默认值。 配置文件的指定格式与容器上的相同。有关完整规范，请参阅 [API 参考](#api-reference)。 <!-- ### Disabling AppArmor --> ### 禁用 AppArmor {#disabling-apparmor} <!-- If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag: --> 如果你不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它： ``` --feature-gates=AppArmor=false ``` <!-- When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden" error. Note that by default docker always enables the "docker-default" profile on non-privileged pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general availability (GA). --> 禁用时，任何包含 AppArmor 配置文件的 Pod 都将导致验证失败，且返回 “Forbidden” 错误。 注意，默认情况下，docker 总是在非特权 Pod 上启用 “docker-default” 配置文件（如果 AppArmor 内核模块已启用）， 并且即使特性门控已禁用，也将继续启用该配置文件。 当 AppArmor 升级到正式发布（GA）阶段时，禁用 Apparmor 的选项将被删除。 <!-- ### Upgrading to Kubernetes v1.4 with AppArmor --> ### 使用 AppArmor 升级到 Kubernetes v1.4 <!-- No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it is recommended to scrub the cluster of any pods containing an annotation with `apparmor.security.beta.kubernetes.io`. --> 不需要对 AppArmor 执行任何操作即可将集群升级到 v1.4。但是， 如果任何现有的 Pod 有一个 AppArmor 注解， 它们将无法通过合法性检查（或 PodSecurityPolicy 准入控制）。 如果节点上加载了宽松的配置文件，恶意用户可以预先应用宽松的配置文件， 将 Pod 权限提升到 docker-default 权限之上。 如果存在这个问题，建议清除集群中包含 `apparmor.security.beta.kubernetes.io` 注解的所有 Pod。 <!-- ### Upgrade path to General Availability --> ### 升级到正式发布的途径 {#upgrade-path-to-general-availability} <!-- When AppArmor is ready to be graduated to general availability (GA), the options currently specified through annotations will be converted to fields. Supporting all the upgrade and downgrade paths through the transition is very nuanced, and will be explained in detail when the transition occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will explicitly reject the annotations for at least 2 releases after that. --> 当 Apparmor 准备升级到正式发布（GA）状态时，当前通过注解指定的选项将转换为字段。 通过转换支持所有升级和降级路径是非常微妙的，并将在转换发生时详细解释。 我们将承诺在至少两个发行版本中同时支持字段和注解，并在之后的至少两个版本中显式拒绝注解。 <!-- ## Authoring Profiles --> ## 编写配置文件 {#authoring-profiles} <!-- Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some tools to help with that: --> 获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助你做到这一点： <!-- * `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and logs, and admitting the actions it takes. Further instructions are provided by the [AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools). * [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a simplified profile language. --> * `aa-genprof` 和 `aa-logprof` 通过监视应用程序的活动和日志并准许它所执行的操作来生成配置文件规则。 [AppArmor 文档](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)提供了进一步的指导。 * [bane](https://github.com/jfrazelle/bane) 是一个用于 Docker的 AppArmor 配置文件生成器，它使用一种简化的画像语言（profile language） <!-- It is recommended to run your application through Docker on a development workstation to generate the profiles, but there is nothing preventing running the tools on the Kubernetes node where your Pod is running. --> 建议在开发工作站上通过 Docker 运行应用程序以生成配置文件， 不过在运行 Pod 的 Kubernetes 节点上运行这些工具也是可以的。 <!-- To debug problems with AppArmor, you can check the system logs to see what, specifically, was denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system logs or through `journalctl`. More information is provided in [AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures). --> 想要调试 AppArmor 的问题，你可以检查系统日志，查看具体拒绝了什么。 AppArmor 将详细消息记录到 `dmesg`， 错误通常可以在系统日志中或通过 `journalctl` 找到。 更多详细信息见 [AppArmor 失败](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)。 <!-- ## API Reference --> ## API 参考 {#api-reference} <!-- ### Pod Annotation --> ### Pod 注解 {#pod-annotation} <!-- Specifying the profile a container will run with: --> 指定容器将使用的配置文件： <!-- - **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>` Where `<container_name>` matches the name of a container in the Pod. A separate profile can be specified for each container in the Pod. - **value**: a profile reference, described below --> - **键名**: `container.apparmor.security.beta.kubernetes.io/<container_name>` ，其中 `<container_name>` 与 Pod 中某容器的名称匹配。 可以为 Pod 中的每个容器指定单独的配置文件。 - **键值**: 对配置文件的引用，如下所述 <!-- ### Profile Reference --> ### 配置文件引用 {#profile-reference} <!-- - `runtime/default`: Refers to the default runtime profile. - Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still requires AppArmor to be enabled. - For Docker, this resolves to the [`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged containers, and unconfined (no profile) for privileged containers. - `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name. - The possible profile names are detailed in the [core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications). - `unconfined`: This effectively disables AppArmor on the container. --> - `runtime/default`: 指默认运行时配置文件。 - 等同于不指定配置文件（没有 PodSecurityPolicy 默认值），只是它仍然需要启用 AppArmor。 - 对于 Docker，针对非特权容器时解析为 [`Docker default`](https://docs.docker.com/engine/security/apparmor/) 配置文件， 针对特权容器时解析为 unconfined（无配置文件）。 - `localhost/<profile_name>`: 按名称引用加载到节点（localhost）上的配置文件。 - 可能的配置文件名在[核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)。 - `unconfined`: 这相当于为容器禁用 AppArmor。 <!-- Any other profile reference format is invalid. --> 任何其他配置文件引用格式无效。 <!-- ### PodSecurityPolicy Annotations --> ### PodSecurityPolicy 注解 {#podsecuritypolicy-annotations} <!-- Specifying the default profile to apply to containers when none is provided: --> 指定在未提供容器时应用于容器的默认配置文件： <!-- * **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName` * **value**: a profile reference, described above --> * **键名**: `apparmor.security.beta.kubernetes.io/defaultProfileName` * **键值**: 如上述文件参考所述 <!-- Specifying the list of profiles Pod containers is allowed to specify: --> 上面描述的指定配置文件，Pod 容器列表的配置文件引用允许指定： <!-- * **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` * **value**: a comma-separated list of profile references (described above) - Although an escaped comma is a legal character in a profile name, it cannot be explicitly allowed here. --> * **键名**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` * **键值**: 配置文件引用的逗号分隔列表（如上所述） - 尽管转义逗号是配置文件名中的合法字符，但此处不能显式允许。 ## {{% heading "whatsnext" %}} <!-- Additional resources: --> 其他资源： <!-- * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) --> * [Apparmor 配置文件语言快速指南](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [Apparmor 核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) </ins>

/language zh
/triage accepted
Please notice that: Moved in EN: ZH version exists: Suggestion: Move to Resync, if needed. This might reduce someone's effort to translate the document from scratch!
/assign


Question: Management and Administration. This group will deliver [enhancement <del> proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting </del> <ins> proposals](https://gateway-api.sigs.k8s.io/geps/overview/) consisting </ins> of resources, additions, and modifications to the Gateway API specification for mesh and mesh-adjacent use-cases.

Problem: The text on is not working, I believe the right link should be https://gateway- Check the page for the problem. Page to Update: Suggested Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the text enhancement proposals link to https://gateway- and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, I believe the right link should be https://gateway- Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the text enhancement proposals link to https://gateway- and not to this . /assign /language en Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
/kind documentation


Question: If you need access to multiple registries, you can create one secret for each registry. <ins> ## Legacy built-in kubelet credential provider In older versions of Kubernetes, the kubelet had a direct integration with cloud provider credentials. This gave it the ability to dynamically fetch credentials for image registries. There were three built-in implementations of the kubelet credential provider integration: ACR (Azure Container Registry), ECR (Elastic Container Registry), and GCR (Google Container Registry). For more information on the legacy mechanism, read the documentation for the version of Kubenetes that you are using. Kubernetes v1.26 through to v{{< skew latestVersion >}} do not include the legacy mechanism, so you would need to either: - configure a kubelet image credential provider on each node - specify image pull credentials using `imagePullSecrets` and at least one Secret </ins> ## {{% heading "whatsnext" %}} * Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md). * Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). * Learn more about [pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry).

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: Add (reinstate!) documentation for the legacy credential provider integration in the kubelet that has integrations for: ACR (Azure Container Registry) ECR (Elastic Container Registry) GCR (Google Container Registry) Why is this needed: — That legacy mechanism exists but is not currently documented. Additional Information: PR removed some earlier documentation for the built-in mechanism. The removal was aimed at removing documentation for third-party integrations but (in error) also removed details of the legacy in-tree implementation. /language en /sig node /sig cloud-provider
Any new documentation we add for this should hyperlink to , and vice versa.
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle stale
/priority important-soon This should have landed for v1.26 (ideally: earlier)
I suppose that we now need to reinstate this into the v1.25 docs and document in the live docs that their was suc a mechanism previously.
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]:
The issue has been marked as an important bug and triaged. Such issues are automatically marked as frozen when hitting the rotten state to avoid missing important bugs. Please send feedback to sig-contributor-experience at . /lifecycle frozen
We've shipped v1.26 /priority important-longterm OK to demote further once v1.27 ships (a shame, but we just might not get round to it).
I'll demote it now, I think.

/remove-priority important-longterm
/remove-priority important-soon /priority backlog
/remove-lifecycle frozen
/assign


Question: ### Beta level  - **ephemeralContainers** ([]<a href="{{< ref "../workload-resources/pod-v1#EphemeralContainer" >}}">EphemeralContainer) *Patch strategy: merge on key `name`* List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is beta-level and available on clusters that haven't disabled the EphemeralContainers feature gate.  - **preemptionPolicy** (string) PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is beta-level, gated by the NonPreemptingPriority feature-gate.

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


Question: --- title: "Security" <del> weight: 81 </del> <ins> weight: 85 </ins> description: > Concepts for keeping your cloud-native workload secure. ---

This is a Bug Report Problem: Some pages at the same width have the same weight in their . Originally, the pages have to be sorted based on weights even when localizing the documents. However, for some pages with the same weight at the same level, they are sorted in the order of the strings of the translated titles, which makes them out of order with the English documents. Each localization teams might change the weight according to their language and put them in the right order, but I think it would be better to change the overall weights in the English document. And more than 100 pages need to be modified. For example in Korean, the pages are sorted by first letter of "Korean-translated title", the order of pages below in Korean is different with that of English. English ! Korean ! <brProposed Solution: Re-order every page that has the same weight in the same level. Page to Update: If you guys think this is needed, I will organize all the pages that need to be modified at the comment. I have structured the pages of the whole document like below. Pairs with the same weights are marked with [ N ] at the beginning of the title. The value at the end of the title is each of their weights. <img width="663" alt="image" src="https://user-"<br/kind cleanup /assign
Given how much this is a problem for localizations, we could (should?) add a CI test to warn when two pages have an equal weight in a section - that'd be a way to stop the problem returning. I presume that pages with no weight declared are also a problem for the same reason.
Thank you for comment and add as a CI test seems good idea! But before adding, wouldn't it be better to check it once and make changes, and then add this task to a CI test? :smiley: As you commented, there were some pages that had no weights, too!
I'm OK with either order. Folks can work on the CI test first, or the manual fix first. We'll only really get value if we do both of those things (otherwise, we'll tend to find that we return to a state where page weights overlap). Another fix might be to sort localized pages with overlapping weight based on the collation order of the English equivalent page.

That does not sound easy, mind!
Neither do I think it's not easy to change the weights according to each Localizations. That's why I opened an issue for English documentation!! Would it be better to open a PR first(with personally modified wieghts) and then get a review, or would it be better to agree on the appropriate weights here first??
Thank you for bringing this up in the localization meeting yesterday! After chatting about it in the meeting, we determined, based on the research done by there aren't any sections where overlapping page weights are causing a different ordered side navigation in localized content that will disrupt users from understanding content. Meaning, there aren't any sections in the side nav where this issue is occurring and a user would need to read the pages in a specific order. Our recommended action is: this as an issue within the broader sig docs community, in slack and in the next community meeting, to make sure folks working on the English language docs understand the importance of page weights and potential problem overlapping pages weights cause in localized content. Use a "lazy" updating approach, to adjust English language page weights as a page is updated. I think if we implemented idea for adding a CI warning that would help speed up making the adjustments to each English page. may also want to add a note to our docs to highlight that we shouldn't use overlapping weights within a section. and does this sound like a good summary of our discussion? Did i miss anything? cc:
Thank you for your opinion !! I also agree that each localization teams would be nice to aware of this even if it doesn't need to be modified now! For docs, it seems great idea, and I'll open an issue for that!
/triage accepted
/area localization
Watch out for updating the weight values for pages that are autogenerated - we should teach the page generator to produce our preferred values instead.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
During the docs sprint we were tracking the areas that we already checked for page weights issues in this Hack MD file: Pages that have been checked off on the list were reviewed or a PR was opened to address the issue.

Anything left unchecked still needs to be be reviewed and possibly updated. Note, the reference docs are mostly autogenerated and do not need to be updated.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I've reviewed the hackmd file and it looks like the only section of the docs that hasn't been reviewed is the section. There is a PR open that addresses the page weights of files for the folders in the Tasks section, But there has not been a review for any of the pages within any of the folders. This is a rather large section of the docs and will definitely need to have page weights adjusted in some areas.
Hi Do you have a script to check the current weights ? if then, I think we could check remaining tasks for this issue. :)
Yes I have, but the script is not clean at all. If you need it immediately, I can upload(or send) the script right now. If not, I'll send it to you after refactoring.
It is just for checking remaining tasks :) no need to hurry :)
I've been working on making PRs to finish this issue up. The largest section left to do is the Tasks section. I plan to have PRs to cover those updates this week. Sorry i've left off wrapping this up for so long, but hopefully we can get all the page weights updated in english soon
I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. Feel free to reopen this issue if necessary. /close
Closing this issue. <detailsIn response to : I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. </details


Question: 1. Загрузите последнюю версию с помощью команды: ``` <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> Чтобы загрузить определенную версию, вставьте в фрагмент команды `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` нужную версию. </del> <ins> Чтобы загрузить определенную версию, вставьте в фрагмент команды `$(curl -LS https://dl.k8s.io/release/stable.txt)` нужную версию. </ins> Например, команда загрузки версии {{< param "fullversion" >}} для Linux будет выглядеть следующим образом: ``` <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. Сделайте двоичный файл kubectl исполняемым:

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: <ins> <?xml version="1.0" encoding="utf-8"?> <svg xmlns="http://www.w3.org/2000/svg" role="img" viewBox="-5.02 -4.02 443.30 433.55"> <defs> <style>.cls-2{fill:#fff}</style> </defs> <path fill="none" d="M103.88 256v48.69h225.8v-68.13h-225.8zm45.66 27.77c0 5.21-4 9.26-9.85 9.26h-7.23v-18.52h7.23c5.82 0 9.85 4 9.85 9.21zm17.73 9.23h-14.11v-18.49h14v3.63h-9.93v3.76h8.74v3.63h-8.74v3.89h10.06zm54.52 0h-13.32v-18.49h4.08v14.82h9.24zm20.88-9.26a9.85 9.85 0 0 1-19.69.05v-.05a9.85 9.85 0 0 1 19.69-.05zm35.41 9.26H264v-18.49h14v3.63h-10v3.76h8.74v3.63H268v3.89h10.06zm15.33-37v-8.24h3.76l6.27 8.24 2.41 3.17v-11.41h4v18.53h-3.45L298.56 256l-1.14-1.49v11.78h-4zm2.17 20.39a5.82 5.82 0 0 1 1.59 4.24v.05a5.75 5.75 0 0 1-4 5.74l4.53 6.62h-4.76l-4-5.93h-3.2V293h-4.04v-18.49h8.47a7.39 7.39 0 0 1 5.4 1.87zM270.09 257a9.86 9.86 0 0 1 .05-1 9.89 9.89 0 0 1 19.59 0v1a9.85 9.85 0 0 1-19.69.05zm-7.89-1v-8.24h4.08v18.53h-4.08zm-1.2 24.91v.09c0 4.29-3.34 6.51-7.49 6.51h-3.1V293h-4.08v-18.49h7.57c4.38 0 7.1 2.62 7.1 6.4zm-17.41-33.16h15.31v3.76h-5.64v14.77h-4.08v-14.77h-5.64zM229.13 256l3.56-8.37h3.76L240 256l4.38 10.29h-4.26l-1.69-4.16h-7.84l-1.69 4.16h-4.16zM206 257c0-.35 0-.69.05-1a9.39 9.39 0 0 1 9.61-8.56 9.56 9.56 0 0 1 7.34 2.86l-2.59 3a6.84 6.84 0 0 0-4.74-2.09 5.38 5.38 0 0 0-5.3 4.8 6.54 6.54 0 0 0-.08 1V257c0 3.18 2.2 5.82 5.37 5.82a6.69 6.69 0 0 0 4.87-2.17l2.59 2.62a9.47 9.47 0 0 1-7.6 3.31 9.35 9.35 0 0 1-9.5-9.53zm-2.47 24.87v3.63h-8.74v3.89h10.06V293h-14.11v-18.49h14v3.63h-9.93v3.76zM198.11 256v-8.24h4.08v18.53h-4.08zm-16.57 0v-8.24h4.08v14.82h9.24v3.71h-13.32zm2 18.51h4.39l-7.49 18.66h-3.6l-7.49-18.66h4.5l4.84 13zM163.86 256v-8.24h7.57c4.42 0 7.09 2.62 7.09 6.41v.05a7.1 7.1 0 0 1-.22 1.78c-.8 3.12-3.73 4.73-7.27 4.73h-3.1v5.56h-4.08zm-17.68 0v-8.24h7.57c4.42 0 7.09 2.62 7.09 6.41v.05a7.1 7.1 0 0 1-.22 1.78c-.8 3.12-3.73 4.73-7.27 4.73h-3.1v5.56h-4.08zm-18.12 0l3.56-8.37h3.76L139 256l4.38 10.29h-4.26l-1.69-4.16h-7.84l-1.69 4.16h-4.16zm192.22-34.39a6.15 6.15 0 0 1-2.4.33 15.7 15.7 0 0 1-3.28-.35 20.15 20.15 0 0 1-3.23-1l-1 5a19.36 19.36 0 0 0 7.5 1.33 12.09 12.09 0 0 0 6.86-1.65 5.53 5.53 0 0 0 2.43-4.88 8.33 8.33 0 0 0-.31-2.4 4.88 4.88 0 0 0-1.08-1.88 8 8 0 0 0-2.09-1.58 25.43 25.43 0 0 0-3.36-1.48q-1-.37-1.64-.69a7.06 7.06 0 0 1-1-.58 1.42 1.42 0 0 1-.5-.56 1.67 1.67 0 0 1-.12-.66q0-1.62 2.9-1.62a12.74 12.74 0 0 1 2.84.29 22.94 22.94 0 0 1 2.34.66l1.08-4.81a17.7 17.7 0 0 0-2.9-.77 20 20 0 0 0-3.81-.35 9.92 9.92 0 0 0-6.26 1.78 5.83 5.83 0 0 0-2.28 4.85 7.12 7.12 0 0 0 .46 2.69 5.61 5.61 0 0 0 1.29 1.93 7.75 7.75 0 0 0 2 1.39 28.55 28.55 0 0 0 2.63 1.12 17.36 17.36 0 0 1 2.78 1.26 1.58 1.58 0 0 1 .91 1.31 1.28 1.28 0 0 1-.76 1.32zm-190.46-17.04v12.15a17.24 17.24 0 0 0 .46 4.1 8.16 8.16 0 0 0 1.53 3.21 7 7 0 0 0 2.92 2.09 12.39 12.39 0 0 0 4.62.75 33.37 33.37 0 0 0 5.22-.39 34.36 34.36 0 0 0 4.06-.85v-21.06h-6.18v16.83q-.58.08-1.33.14t-1.41.06a3.13 3.13 0 0 1-2.94-1.33A8.83 8.83 0 0 1 136 216v-11.4zm81.28 4.92a11.1 11.1 0 0 1 1.39-.1 12.1 12.1 0 0 1 2.4.23q1.12.23 1.95.44l1-5.1a6.76 6.76 0 0 0-1.2-.35q-.71-.15-1.41-.25t-1.41-.17q-.71-.06-1.2-.06a22.56 22.56 0 0 0-5 .52 37.18 37.18 0 0 0-3.92 1.1v20.65h6.18v-16.68a8.19 8.19 0 0 1 1.22-.23zm95.7 6.88v-1.18q0-5.51-2.7-8.35a9.63 9.63 0 0 0-7.34-2.84 10.44 10.44 0 0 0-3.88.75 9.72 9.72 0 0 0-3.34 2.2 10.89 10.89 0 0 0-2.34 3.63 13.33 13.33 0 0 0-.89 5.08 14.2 14.2 0 0 0 .68 4.48 9.45 9.45 0 0 0 2.11 3.59 10 10 0 0 0 3.61 2.38 13.75 13.75 0 0 0 5.12.87 21.75 21.75 0 0 0 2.32-.12q1.16-.12 2.18-.31a17.48 17.48 0 0 0 1.84-.44 8.55 8.55 0 0 0 1.33-.5l-.83-5a12.62 12.62 0 0 1-2.67.77 17.89 17.89 0 0 1-3.34.31 7.17 7.17 0 0 1-4.23-1.12 4.1 4.1 0 0 1-1.78-3h14q.11-.57.15-1.2zm-14.09-3.09a8.7 8.7 0 0 1 .39-1.55 4.2 4.2 0 0 1 .77-1.35 3.69 3.69 0 0 1 1.24-.93 4.15 4.15 0 0 1 1.78-.35 3.93 3.93 0 0 1 1.8.37 3.77 3.77 0 0 1 1.2 1 3.84 3.84 0 0 1 .71 1.33 6.46 6.46 0 0 1 .27 1.53zM240 226.38v-12.31a16.78 16.78 0 0 0-.46-4.06 8 8 0 0 0-1.53-3.15 6.94 6.94 0 0 0-2.92-2.05 12.73 12.73 0 0 0-4.62-.73 33.37 33.37 0 0 0-5.22.39 34.5 34.5 0 0 0-4.06.85v21.06h6.18v-16.83q.58-.08 1.33-.14t1.41-.06a3.21 3.21 0 0 1 2.94 1.24 8.33 8.33 0 0 1 .79 4.23v11.57zm-41.11-10.01v-1.18q0-5.51-2.69-8.35a9.63 9.63 0 0 0-7.3-2.84 10.44 10.44 0 0 0-3.88.75 9.73 9.73 0 0 0-3.34 2.2 10.89 10.89 0 0 0-2.34 3.63 13.33 13.33 0 0 0-.89 5.08 14.2 14.2 0 0 0 .68 4.48 9.46 9.46 0 0 0 2.11 3.59 10 10 0 0 0 3.61 2.38 13.75 13.75 0 0 0 5.15.89 21.76 21.76 0 0 0 2.32-.12q1.16-.12 2.18-.31a17.49 17.49 0 0 0 1.85-.44 8.56 8.56 0 0 0 1.33-.5l-.83-5a12.61 12.61 0 0 1-2.67.77 17.88 17.88 0 0 1-3.34.31 7.17 7.17 0 0 1-4.23-1.12 4.1 4.1 0 0 1-1.78-3h14q.02-.59.06-1.22zm-14.1-3.09a8.83 8.83 0 0 1 .39-1.55 4.18 4.18 0 0 1 .77-1.35 3.7 3.7 0 0 1 1.24-.93 4.15 4.15 0 0 1 1.78-.35 3.93 3.93 0 0 1 1.8.37 3.76 3.76 0 0 1 1.2 1 3.84 3.84 0 0 1 .71 1.33 6.43 6.43 0 0 1 .27 1.53zm-30.34-18.07v30.47q.83.25 1.91.48t2.26.39q1.18.17 2.4.27t2.34.1a13.39 13.39 0 0 0 4.81-.81 9.75 9.75 0 0 0 3.57-2.3 10 10 0 0 0 2.26-3.61 13.79 13.79 0 0 0 .77-4.73 16.36 16.36 0 0 0-.62-4.66 10.34 10.34 0 0 0-1.82-3.59 8 8 0 0 0-3-2.3 9.84 9.84 0 0 0-4.1-.81 11.06 11.06 0 0 0-2.4.25 11.6 11.6 0 0 0-2.16.7v-10.85zm7.69 14.39a7.28 7.28 0 0 1 1.89-.25q4.39 0 4.39 6a7.57 7.57 0 0 1-1.29 4.6 4.44 4.44 0 0 1-3.81 1.74q-.83 0-1.53-.06t-1.16-.15v-11.27a5.37 5.37 0 0 1 1.51-.62zM265 216.37v-1.18q0-5.51-2.7-8.35A9.63 9.63 0 0 0 255 204a10.44 10.44 0 0 0-3.88.75 9.72 9.72 0 0 0-3.34 2.2 10.89 10.89 0 0 0-2.34 3.63 13.33 13.33 0 0 0-.89 5.08 14.2 14.2 0 0 0 .68 4.48 9.45 9.45 0 0 0 2.11 3.59 10 10 0 0 0 3.61 2.38 13.75 13.75 0 0 0 5.12.87 21.75 21.75 0 0 0 2.32-.12q1.16-.12 2.18-.31a17.48 17.48 0 0 0 1.84-.44 8.55 8.55 0 0 0 1.33-.5l-.83-5a12.62 12.62 0 0 1-2.67.77 17.89 17.89 0 0 1-3.34.31 7.17 7.17 0 0 1-4.23-1.12 4.1 4.1 0 0 1-1.78-3h14q.11-.57.11-1.2zm-14.09-3.09a8.7 8.7 0 0 1 .39-1.55 4.2 4.2 0 0 1 .77-1.35 3.69 3.69 0 0 1 1.24-.93 4.15 4.15 0 0 1 1.78-.35 3.93 3.93 0 0 1 1.8.37 3.77 3.77 0 0 1 1.2 1 3.84 3.84 0 0 1 .71 1.33 6.46 6.46 0 0 1 .27 1.53zm18.7-14.14v18.32a17.43 17.43 0 0 0 .39 3.86 7.09 7.09 0 0 0 1.39 3 6.57 6.57 0 0 0 2.65 1.91 11.05 11.05 0 0 0 4.19.68 14.52 14.52 0 0 0 3.36-.33 17.43 17.43 0 0 0 2.49-.79l-.87-4.81a10.53 10.53 0 0 1-1.93.52 11.74 11.74 0 0 1-2.05.19 2.94 2.94 0 0 1-2.76-1.16 6.1 6.1 0 0 1-.68-3.11v-7.67h7.42v-5.14h-7.42v-6.43zm-163.17-3.93v31.18h6.18v-9.56a16.91 16.91 0 0 1 2.09 2q1.06 1.21 2 2.51t1.8 2.62q.85 1.31 1.51 2.39h7.1q-.71-1.37-1.74-3t-2.27-3.35q-1.24-1.66-2.57-3.22a28.56 28.56 0 0 0-2.57-2.68q2.49-2.44 4.58-4.74t4.29-4.82h-7.35l-1.39 1.65-1.72 2q-.91 1.05-1.88 2.12l-1.88 2.06v-18.2zm-2.56-7.31h225.8v-49.21h-225.8zm189-35.72h10c8 0 13.6 5.52 13.6 12.72v.1c0 7.2-5.56 12.8-13.6 12.8h-10zm-24.49 0h19.3v5H274v5.19h12v5h-12v5.37h13.89v5h-19.52zm-12 0H262v25.59h-5.63zm-24.24 0h19.45v5.12h-13.86v5.45H250v5.12h-12.26v9.91h-5.63zm-12 0h5.63v25.59h-5.63zm-25.77 0h21.2v5.19h-7.79v20.4h-5.69v-20.4h-7.79zm-24.6 0h11.7c3.25 0 5.78.91 7.46 2.6a8 8 0 0 1 2.19 5.85v.07a8 8 0 0 1-5.48 7.93l6.25 9.14h-6.58l-5.48-8.19h-4.42v8.19h-5.63zm-24.49 0h19.3v5h-13.77v5.19h12.06v5h-12.06v5.37h13.89v5h-19.49zM117.11 165a13 13 0 0 1 13.34-13.23 13.2 13.2 0 0 1 10.09 3.95l-3.54 4.1a9.44 9.44 0 0 0-6.54-2.89c-4.31 0-7.42 3.58-7.42 8v.07c0 4.39 3 8 7.42 8 2.92 0 4.72-1.17 6.73-3l3.58 3.62a13.08 13.08 0 0 1-10.49 4.57A12.92 12.92 0 0 1 117.11 165zm84.5-66.56a128.26 128.26 0 0 0-12.9 2.23 124.86 124.86 0 0 0-51.44 25h62.81zm94.18 27.25a125.66 125.66 0 0 0-63.84-27.25l1.54 27.25z"/> <path d="M419.5 256.72c-1-.23-2.51-.64-3.52-.83-4.22-.8-7.64-.6-11.61-.93-8.46-.89-15.47-1.61-21.7-3.57-2.54-1-4.34-4-5.22-5.25l-4.89-1.42a157.24 157.24 0 0 0-25.22-108.94c1.25-1.14 3.62-3.24 4.29-3.86.2-2.17 0-4.45 2.28-6.85 4.76-4.47 10.76-8.18 18-12.65 3.43-2 6.61-3.32 10.06-5.87.78-.58 1.84-1.49 2.66-2.15 5.81-4.63 7.14-12.62 3-17.85s-12.25-5.72-18.05-1.08c-.83.65-1.95 1.51-2.69 2.15-3.25 2.8-5.26 5.56-8 8.46-6 6.06-10.9 11.12-16.32 14.77-2.35 1.37-5.79.89-7.35.8l-4.6 3.29a158.64 158.64 0 0 0-100.51-48.57c-.11-1.61-.25-4.53-.28-5.4-1.58-1.51-3.48-2.8-4-6.05-.53-6.51.35-13.51 1.37-22 .56-3.95 1.5-7.23 1.65-11.51v-3.44c0-7.42-5.42-13.45-12.1-13.45s-12.11 6-12.11 13.45v.34c0 1-.06 2.22 0 3.1.16 4.28 1.09 7.56 1.65 11.51 1 8.45 1.87 15.45 1.35 22a13.2 13.2 0 0 1-3.93 6.26l-.28 5.12a157.8 157.8 0 0 0-21.88 3.36 155.71 155.71 0 0 0-79.1 45.19c-1.34-.91-3.67-2.59-4.37-3.1-2.16.29-4.35 1-7.19-.7-5.42-3.65-10.35-8.68-16.32-14.74-2.74-2.9-4.72-5.66-8-8.46-.74-.63-1.86-1.49-2.69-2.15a14.4 14.4 0 0 0-8.43-3.18 11.65 11.65 0 0 0-9.65 4.27C41.68 92 43 100 48.82 104.63l.18.13c.8.65 1.78 1.47 2.51 2 3.45 2.55 6.6 3.85 10 5.87 7.24 4.47 13.24 8.18 18 12.65 1.86 2 2.18 5.47 2.43 7l3.88 3.46a156.66 156.66 0 0 0-24.7 109.21l-5.07 1.47c-1.34 1.73-3.22 4.44-5.2 5.25-6.23 2-13.24 2.68-21.7 3.57-4 .33-7.4.13-11.62.93-.92.17-2.22.51-3.23.75h-.28c-7.13 1.73-11.72 8.29-10.24 14.74s8.44 10.39 15.62 8.85h.18l.23-.08c1-.22 2.25-.46 3.13-.7 4.14-1.11 7.14-2.74 10.86-4.17 8-2.87 14.64-5.27 21.1-6.21 2.7-.21 5.55 1.67 7 2.46l5.28-.91a156.46 156.46 0 0 0 23.7 45.81v.91h.69A158.66 158.66 0 0 0 137 358.14l-2.2 5.28c.79 2 1.67 4.82 1.08 6.85-2.35 6.09-6.38 12.52-11 19.69-2.22 3.31-4.49 5.88-6.49 9.68-.48.91-1.09 2.3-1.55 3.26-3.11 6.66-.83 14.33 5.15 17.2s13.48-.16 16.71-6.83c.46-.95 1.12-2.19 1.5-3.08 1.71-3.93 2.28-7.3 3.49-11.09 3.2-8 5-16.49 9.37-21.75 1.21-1.44 3.18-2 5.22-2.54l2.74-5a156.63 156.63 0 0 0 111.71.29c.77 1.37 2.2 4 2.59 4.66 2.07.68 4.34 1 6.18 3.75 3.3 5.63 5.55 12.3 8.3 20.36 1.21 3.8 1.8 7.17 3.52 11.09.39.9 1 2.16 1.5 3.1 3.22 6.69 10.71 9.76 16.74 6.85s8.26-10.54 5.15-17.2c-.46-1-1.1-2.35-1.58-3.26-2-3.79-4.27-6.34-6.49-9.65-4.58-7.17-8.38-13.13-10.73-19.22-1-3.14.17-5.1.93-7.14a41.1 41.1 0 0 1-2-4.89 156.55 156.55 0 0 0 45.56-40.84h.24v-.32a158 158 0 0 0 24-46.62c1.56.25 4.29.73 5.17.91 1.82-1.2 3.49-2.77 6.78-2.51 6.46.93 13.1 3.33 21.11 6.21 3.72 1.43 6.72 3.08 10.86 4.19.88.23 2.13.45 3.13.67l.23.08h.18c7.18 1.54 14.15-2.38 15.62-8.85s-3.08-13.03-10.22-14.75zm-123.71-131h-62.3l-1.54-27.25a125.66 125.66 0 0 1 63.84 27.22zm-107.09-25a128.26 128.26 0 0 1 12.9-2.23l-1.54 27.25h-62.8a124.86 124.86 0 0 1 51.44-25.07zm-39.5 227.9a126.45 126.45 0 0 1-14.52-10.89h19zm95.68 16.74a125.16 125.16 0 0 1-68.31-3.52l13.33-24.11h53.91l13.38 24.19q-5.99 1.96-12.31 3.39zm39.7-16.5L280 317.68h19.44a124.07 124.07 0 0 1-14.85 11.13zm45.1-72.86v48.69h-225.8v-68.13h225.8zM114.5 210.35q1-1.07 1.88-2.12l1.72-2 1.39-1.65h7.35q-2.2 2.52-4.29 4.82t-4.55 4.73a28.56 28.56 0 0 1 2.57 2.68q1.33 1.56 2.57 3.22t2.28 3.32q1 1.66 1.74 3H120q-.66-1.08-1.51-2.39t-1.8-2.62q-1-1.31-2-2.51a16.91 16.91 0 0 0-2.09-2v9.56h-6.18v-31.18l6.18-1v18.2zm22.29 9.94a3.13 3.13 0 0 0 2.94 1.33q.66 0 1.41-.06t1.33-.14v-16.85h6.18v21.06a34.36 34.36 0 0 1-4.06.85 33.37 33.37 0 0 1-5.22.39 12.39 12.39 0 0 1-4.62-.75 7 7 0 0 1-2.92-2.09 8.16 8.16 0 0 1-1.53-3.21 17.24 17.24 0 0 1-.46-4.1v-12.15H136V216a8.83 8.83 0 0 0 .79 4.29zm26-15.92a11.06 11.06 0 0 1 2.4-.25 9.84 9.84 0 0 1 4.1.81 8 8 0 0 1 3 2.3 10.34 10.34 0 0 1 1.82 3.59 16.36 16.36 0 0 1 .62 4.66 13.79 13.79 0 0 1-.77 4.73 10 10 0 0 1-2.22 3.61 9.75 9.75 0 0 1-3.57 2.3 13.39 13.39 0 0 1-4.81.81q-1.12 0-2.34-.1t-2.4-.27q-1.18-.17-2.26-.39t-1.91-.48v-30.48l6.18-1v10.86a11.6 11.6 0 0 1 2.15-.7zm23.8 16.17a7.17 7.17 0 0 0 4.23 1.12 17.88 17.88 0 0 0 3.34-.31 12.61 12.61 0 0 0 2.67-.77l.83 5a8.56 8.56 0 0 1-1.33.5 17.49 17.49 0 0 1-1.85.44q-1 .19-2.18.31a21.76 21.76 0 0 1-2.3.17 13.75 13.75 0 0 1-5.12-.87 10 10 0 0 1-3.61-2.38 9.46 9.46 0 0 1-2.11-3.59 14.2 14.2 0 0 1-.68-4.48 13.33 13.33 0 0 1 .89-5.08 10.89 10.89 0 0 1 2.34-3.63 9.73 9.73 0 0 1 3.34-2.2 10.44 10.44 0 0 1 3.88-.75 9.63 9.63 0 0 1 7.34 2.84q2.69 2.84 2.69 8.35v1.18q0 .64-.08 1.14h-14a4.1 4.1 0 0 0 1.7 3.01zm17.12 5.85v-20.65a37.18 37.18 0 0 1 3.92-1.1 22.56 22.56 0 0 1 5-.52q.5 0 1.2.06t1.41.17q.7.1 1.41.25a6.76 6.76 0 0 1 1.2.35l-1 5.1q-.83-.21-1.95-.44a12.1 12.1 0 0 0-2.4-.23 11.1 11.1 0 0 0-1.39.1 8.19 8.19 0 0 0-1.22.23v16.67zm29.29-15.8a3.21 3.21 0 0 0-2.94-1.24q-.66 0-1.41.06t-1.33.14v16.83h-6.18v-21.06a34.5 34.5 0 0 1 4.06-.85 33.37 33.37 0 0 1 5.22-.39 12.73 12.73 0 0 1 4.62.73 6.94 6.94 0 0 1 2.92 2.05 8 8 0 0 1 1.53 3.15 16.78 16.78 0 0 1 .46 4.06v12.31h-6.18v-11.56a8.33 8.33 0 0 0-.77-4.23zm19.65 9.95a7.17 7.17 0 0 0 4.23 1.12 17.89 17.89 0 0 0 3.34-.31 12.62 12.62 0 0 0 2.67-.77l.83 5a8.55 8.55 0 0 1-1.33.5 17.48 17.48 0 0 1-1.84.44q-1 .19-2.18.31a21.75 21.75 0 0 1-2.32.12 13.75 13.75 0 0 1-5.12-.87 10 10 0 0 1-3.61-2.38 9.45 9.45 0 0 1-2.11-3.59 14.2 14.2 0 0 1-.68-4.48 13.33 13.33 0 0 1 .89-5.08 10.89 10.89 0 0 1 2.34-3.63 9.72 9.72 0 0 1 3.34-2.2 10.44 10.44 0 0 1 3.9-.72 9.63 9.63 0 0 1 7.34 2.84q2.7 2.84 2.7 8.35v1.18q0 .64-.08 1.14h-14a4.1 4.1 0 0 0 1.74 3.03zm30.51-16v5.14h-7.42v7.67a6.1 6.1 0 0 0 .68 3.11 2.94 2.94 0 0 0 2.76 1.16 11.74 11.74 0 0 0 2.05-.19 10.53 10.53 0 0 0 1.93-.52l.87 4.81a17.43 17.43 0 0 1-2.49.79 14.52 14.52 0 0 1-3.36.33 11.05 11.05 0 0 1-4.19-.68 6.57 6.57 0 0 1-2.65-1.91 7.09 7.09 0 0 1-1.39-3 17.43 17.43 0 0 1-.39-3.86v-18.25l6.18-1v6.43zm11.28 16a7.17 7.17 0 0 0 4.23 1.12 17.89 17.89 0 0 0 3.34-.31 12.62 12.62 0 0 0 2.67-.77l.83 5a8.55 8.55 0 0 1-1.33.5 17.48 17.48 0 0 1-1.84.44q-1 .19-2.18.31a21.75 21.75 0 0 1-2.32.12 13.75 13.75 0 0 1-5.12-.87 10 10 0 0 1-3.61-2.38 9.45 9.45 0 0 1-2.11-3.59 14.2 14.2 0 0 1-.68-4.48 13.33 13.33 0 0 1 .89-5.08 10.89 10.89 0 0 1 2.34-3.63 9.72 9.72 0 0 1 3.34-2.2 10.44 10.44 0 0 1 3.88-.75 9.63 9.63 0 0 1 7.34 2.84q2.7 2.84 2.7 8.35v1.18q0 .64-.08 1.14h-14a4.1 4.1 0 0 0 1.76 3.06zm25.63-1.54a17.36 17.36 0 0 0-2.78-1.26 28.55 28.55 0 0 1-2.63-1.12 7.75 7.75 0 0 1-2-1.39 5.61 5.61 0 0 1-1.29-1.93 7.12 7.12 0 0 1-.46-2.69 5.83 5.83 0 0 1 2.28-4.85 9.92 9.92 0 0 1 6.26-1.78 20 20 0 0 1 3.81.35 17.7 17.7 0 0 1 2.9.77l-1.08 4.81a22.94 22.94 0 0 0-2.34-.66 12.74 12.74 0 0 0-2.84-.29q-2.9 0-2.9 1.62a1.67 1.67 0 0 0 .13.66 1.42 1.42 0 0 0 .5.56 7.06 7.06 0 0 0 1 .58q.64.31 1.64.69a25.43 25.43 0 0 1 3.36 1.48 8 8 0 0 1 2.09 1.58 4.88 4.88 0 0 1 1.08 1.87 8.33 8.33 0 0 1 .31 2.4 5.53 5.53 0 0 1-2.43 4.88 12.09 12.09 0 0 1-6.86 1.65 19.36 19.36 0 0 1-7.5-1.33l1-5a20.15 20.15 0 0 0 3.23 1 15.7 15.7 0 0 0 3.28.35 6.15 6.15 0 0 0 2.4-.33 1.28 1.28 0 0 0 .71-1.29 1.58 1.58 0 0 0-.87-1.33zm9.61-31.13h-225.8v-49.18h225.8z" class="cls-2"/> <path d="M130.24 178.21a13.08 13.08 0 0 0 10.49-4.57l-3.58-3.64c-2 1.83-3.8 3-6.73 3-4.39 0-7.42-3.66-7.42-8v-.07c0-4.39 3.11-8 7.42-8a9.44 9.44 0 0 1 6.54 2.89l3.58-4.13a13.2 13.2 0 0 0-10.09-3.95A13 13 0 0 0 117.11 165a12.92 12.92 0 0 0 13.13 13.21zm34.47-5.45h-13.89v-5.37h12.06v-5.01h-12.06v-5.19h13.71v-5.01h-19.31v25.59h19.49v-5.01zm10.63-3.18h4.42l5.48 8.19h6.58l-6.25-9.14a8 8 0 0 0 5.48-7.93v-.07a8 8 0 0 0-2.19-5.85c-1.68-1.68-4.2-2.6-7.46-2.6h-11.7v25.59h5.63zm0-12.32h5.59c2.74 0 4.42 1.24 4.42 3.66v.08c0 2.16-1.57 3.62-4.31 3.62h-5.7zm26.76 20.51h5.63v-20.4h7.79v-5.19h-21.21v5.19h7.79v20.4zm17.99-25.59h5.63v25.59h-5.63zm17.65 15.68h12.21v-5.12h-12.21v-5.44h13.86v-5.12h-19.49v25.59h5.63v-9.91zm18.61-15.68h5.63v25.59h-5.63zm31.51 20.58h-13.89v-5.37h12.06v-5.01h-12.06v-5.19h13.71v-5.01h-19.31v25.59h19.49v-5.01zm28.58-7.76v-.07c0-7.2-5.56-12.72-13.6-12.72h-10v25.59h10c8.05-.03 13.6-5.62 13.6-12.8zm-17.95-7.71h4.35a7.35 7.35 0 0 1 7.71 7.71 7.29 7.29 0 0 1-7.71 7.64h-4.34zm1.41 53.13a3.77 3.77 0 0 0-1.2-1 3.93 3.93 0 0 0-1.8-.37 4.15 4.15 0 0 0-1.78.35 3.69 3.69 0 0 0-1.24.93 4.2 4.2 0 0 0-.77 1.35 8.7 8.7 0 0 0-.39 1.55h8.17a6.46 6.46 0 0 0-.27-1.53 3.84 3.84 0 0 0-.72-1.28zm-107.9 0a3.76 3.76 0 0 0-1.2-1 3.93 3.93 0 0 0-1.8-.37 4.15 4.15 0 0 0-1.78.35 3.7 3.7 0 0 0-1.24.93 4.18 4.18 0 0 0-.77 1.35 8.83 8.83 0 0 0-.39 1.55H193a6.43 6.43 0 0 0-.27-1.53 3.84 3.84 0 0 0-.73-1.28zm66.11 0a3.77 3.77 0 0 0-1.2-1 3.93 3.93 0 0 0-1.8-.37 4.15 4.15 0 0 0-1.78.35 3.69 3.69 0 0 0-1.24.93 4.2 4.2 0 0 0-.77 1.35 8.7 8.7 0 0 0-.39 1.55h8.17a6.46 6.46 0 0 0-.27-1.53 3.84 3.84 0 0 0-.72-1.28zm-97.49 11.03q.46.08 1.16.15t1.53.06a4.44 4.44 0 0 0 3.81-1.74 7.57 7.57 0 0 0 1.29-4.6q0-6-4.39-6a7.28 7.28 0 0 0-1.89.25 5.37 5.37 0 0 0-1.51.62zm-31.08 40.68h7.84l1.69 4.16h4.26L139 256l-3.56-8.37h-3.76l-3.61 8.37-4.38 10.29h4.16zM132 256l1.42-3.48 1.42 3.48 1 2.53H131zm18.26 4.73h3.1c3.53 0 6.46-1.61 7.27-4.73a7.1 7.1 0 0 0 .22-1.78v-.05c0-3.79-2.67-6.41-7.09-6.41h-7.57v18.53h4.08zm0-4.73v-4.56h3.15c2 0 3.31 1 3.31 2.81v.05a2.67 2.67 0 0 1-.59 1.7 3.26 3.26 0 0 1-2.64 1.1h-3.23zm17.68 4.73H171c3.53 0 6.46-1.61 7.27-4.73a7.1 7.1 0 0 0 .22-1.78v-.05c0-3.79-2.67-6.41-7.09-6.41h-7.57v18.53h4.08zm0-4.73v-4.56h3.15c2 0 3.31 1 3.31 2.81v.05a2.67 2.67 0 0 1-.59 1.7 3.26 3.26 0 0 1-2.64 1.1h-3.23zm26.91 6.58h-9.23v-14.83h-4.08v18.53h13.31v-3.7zm7.33-6.58v-8.25h-4.07v18.53h4.07V256zm13.31 10.6a9.47 9.47 0 0 0 7.6-3.31l-2.59-2.62a6.69 6.69 0 0 1-4.87 2.17c-3.18 0-5.37-2.65-5.37-5.82V257a6.54 6.54 0 0 1 .08-1 5.38 5.38 0 0 1 5.3-4.8 6.84 6.84 0 0 1 4.74 2.09l2.59-3a9.56 9.56 0 0 0-7.31-2.86A9.39 9.39 0 0 0 206 256c0 .34-.05.68-.05 1v.05a9.35 9.35 0 0 0 9.54 9.55zm15.12-4.47h7.84l1.69 4.16h4.26L240 256l-3.56-8.37h-3.74l-3.57 8.37-4.38 10.29h4.16zm2.49-6.13l1.42-3.48 1.42 3.48 1 2.53h-4.92zm16.08 0v10.28h4.08v-14.77h5.64v-3.76h-15.36v3.76h5.64V256zm17.1 0v-8.25h-4.08v18.53h4.08V256zm13.63 10.6a9.58 9.58 0 0 0 9.87-9.58V256a9.89 9.89 0 0 0-19.59 0 9.86 9.86 0 0 0-.05 1v.05a9.49 9.49 0 0 0 9.77 9.55zm-5.56-9.6a6.44 6.44 0 0 1 .08-1 5.47 5.47 0 0 1 5.48-4.8 5.56 5.56 0 0 1 5.52 4.8 6.35 6.35 0 0 1 .09 1v.05a5.54 5.54 0 0 1-5.56 5.77 5.63 5.63 0 0 1-5.61-5.82zm23.08-1v-1.5l1.13 1.5 7.84 10.28h3.47v-18.53h-4.02v11.41l-2.41-3.16-6.28-8.25h-3.76v18.53h4.03V256zm-157.74 18.51h-7.23V293h7.23c5.82 0 9.85-4 9.85-9.26v-.05c0-5.19-4.02-9.18-9.85-9.18zm5.59 9.32a5.28 5.28 0 0 1-5.59 5.53h-3.15v-11.18h3.15a5.32 5.32 0 0 1 5.59 5.59zm11.93 1.69h8.74v-3.63h-8.74v-3.76h9.93v-3.62h-13.98v18.53h14.11v-3.63h-10.06v-3.89zm12.09-11.01l7.49 18.66h3.61l7.49-18.66h-4.4l-4.84 13.05-4.85-13.05h-4.5zm35.42 3.62v-3.62h-13.98v18.53h14.11v-3.63h-10.06v-3.89h8.74v-3.63h-8.74v-3.76h9.93zm7.83-3.62h-4.08v18.53h13.32v-3.71h-9.24v-14.82zm20.3-.32a9.58 9.58 0 0 0-9.87 9.58v.05a9.85 9.85 0 0 0 19.69-.05v-.05a9.49 9.49 0 0 0-9.82-9.53zm5.56 9.64a5.54 5.54 0 0 1-5.56 5.77 5.63 5.63 0 0 1-5.61-5.82v-.05a5.54 5.54 0 0 1 5.56-5.77 5.63 5.63 0 0 1 5.61 5.82zm7.88-9.32V293h4.08v-5.56h3.1c4.16 0 7.49-2.22 7.49-6.51v-.05c0-3.79-2.67-6.41-7.09-6.41zm10.53 6.49c0 1.59-1.19 2.81-3.23 2.81h-3.23v-5.66h3.15c2.04.03 3.31 1.01 3.31 2.85zm11.2 4.52h8.73v-3.63h-8.73v-3.76h9.92v-3.62h-13.97v18.53h14.11v-3.63h-10.06v-3.89zM281.7 293h4.08v-5.93H289l4 5.93h4.76l-4.53-6.62a5.75 5.75 0 0 0 4-5.74v-.05a5.82 5.82 0 0 0-1.59-4.24 7.39 7.39 0 0 0-5.4-1.88h-8.54zm4.08-14.85h4c2 0 3.2.9 3.2 2.65v.05c0 1.56-1.14 2.62-3.12 2.62h-4.13z" class="cls-2"/> </svg> </ins>

This is feedback by email from within the CNCF/Linux Foundation: add the CKA/CKAD logos from to the page.
I'll take care of this, so assign it to me :)
/assign


Question: #### Указание версии Kubernetes <del> Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр `--kubernetes-version` в команду `minikube start`. Например, чтобы запустить Minikube из-под версии {{< param "fullversion" >}}, вам нужно выполнить следующую команду: </del> <ins> Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр `--kubernetes-version` в команду `minikube start`. Например, чтобы запустить Minikube из-под версии {{< skew currentPatchVersion >}}, вам нужно выполнить следующую команду: </ins> ```shell <del> minikube start --kubernetes-version {{< param "fullversion" >}} </del> <ins> minikube start --kubernetes-version {{< skew currentPatchVersion >}} </ins> ``` #### Указание драйвера виртуальной машины

Problem: Based on , I have created this issue/task to help update the [ru] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ru" /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/tasks/tools/install- 33: Например, для установки версии {{< param "fullversion" }} на Linux введите: 36: {{< param "fullversion" }}/bin/linux/amd64/kubectl 110: Например, для установки версии {{< param "fullversion" }} на macOS введите: 113: {{< param "fullversion" }}/bin/darwin/amd64/kubectl 175: 1. Загрузите последний релиз {{< param "fullversion" }} по этой ссылке. 180: {{< param "fullversion" }} In the branch, I found: Results for "fullversion" in "k8s-website/content/ru" /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/concepts/containers/container- 44: DNS, если включен . /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/setup/learning- 222: чтобы запустить Minikube из-под версии {{< param "fullversion" }}, вам нужно выполнить следующую команду: 225: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/tasks/tools/install- 36: Например, команда загрузки версии {{< param "fullversion" }} для Linux будет выглядеть следующим образом 39: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: Например, команда загрузки версии {{< param "fullversion" }} для macOS будет выглядеть следующим образом 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 183: 1.

Загрузите последнюю версию {{< param "fullversion" }} по этой ссылкеe


Question: ## `README.md`'s स्थानीयकरण कुबरनेट्स प्रलेखन <del> आप पर हिंदी स्थानीयकरण के maintainers तक पहुँच सकते हैं: </del> <ins> आप हिंदी स्थानीयकरण के मैन्टेनरों तक पहुँच सकते हैं: * Anubhav Vardhan ([Slack](https://kubernetes.slack.com/archives/D0261C0A3R8), [Twitter](https://twitter.com/anubha_v_ardhan), [GitHub](https://github.com/anubha-v-ardhan)) * Divya Mohan ([Slack](https://kubernetes.slack.com/archives/D027R7BE804), [Twitter](https://twitter.com/Divya_Mohan02), [GitHub](https://github.com/divya-mohan0209)) </ins> * Yashu Mittal ([Twitter](https://twitter.com/mittalyashu77), [GitHub](https://github.com/mittalyashu)) * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-hi) ## स्थानीय रूप से डॉकर का उपयोग करके साइट चलाना

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: All the current maintainers of Hindi localization are not mentioned in README- isn't grammatically correct. Proposed Solution: Add and with appropriate links to -Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language hi
Can I work on this?
Sure, Here are the links to be Slack: Twitter: GitHub: Slack: Twitter: /assign
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hey I'm working on this right now
Sorry but is already assigned to fix this. We would love to see more contributions from you.
/unassign


Question: ## Creating a new namespace <ins> {{< note >}} Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. {{< /note >}} </ins> 1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to document that namespaces starting are reserved. Why is this needed According to all namespaces with names that start with are reserved. Comments /kind feature /language en /sig architecture /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update to document that namespaces starting are reserved. According to all namespaces with names that start with are reserved. /kind feature /language en /sig architecture /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign me
GitHub didn't allow me to assign the following users: me. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me </details
/assign


Question: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/e2e-az-name </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - e2e-az1 - e2e-az2 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:

Page: This page could use a review and update for consistency, clarity, and style. Some sections read like tasks instead of conceptual information, and there's a few areas where the headings and readability are not in line with our style guidelines. /assign /sig docs /triage accepted /language en /kind cleanup
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen

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 description provide in the following section is somewhat missing out the details. It is not justifying the value of weight one should configure in the affinity section of a deployment. Proposed Solution: It would be best if this page can contain a legitimate example around the weight in Node affinity. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.18 <!--Additional Information:--What is the significance of weight: 1 as compared to weight: 100 ? Creating first issue in GIT, apologies if I have missed out something. Would be happy to hear from you.
/language en /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle rotten
/remove-lifecycle rotten
/priority backlog
From what I understand, the scheduler iterates through each field for each matched affinity term and computes a sum, then places pods in nodes that meet the scheduling requirements by order of highest weight sum. Is this correct?
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]:
fixes this.
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .


Question: <ins> --- title: ミラーPod id: mirror-pod date: 2019-08-06 short_description: > kubelet上のstatic Podを追跡するAPIサーバー内のオブジェクトです。 aka: tags: - fundamental --- kubeletが{{< glossary_tooltip text="static Pod" term_id="static-pod" >}}を代表するために使用する{{< glossary_tooltip text="Pod" term_id="pod" >}}オブジェクトです。 <!--more--> kubeletが設定の中にstatic Podを発見すると、static Podに対応するPodオブジェクトをKubernetes APIサーバー上に自動的に作成しようとします。つまり、APIサーバーからはPodが見えていますが、制御まではできないということです。 (たとえば、ミラーPodを削除しても、kubeletデーモンが対応するPodの実行を停止することはありません。) </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign


Question: ```shell openssl genrsa -out myuser.key 2048 <del> openssl req -new -key myuser.key -out myuser.csr </del> <ins> openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser" </ins> ``` ### Create a CertificateSigningRequest {#create-certificatessigningrequest}

I guess this needs to be appended here After following instructions I am unable to authenticate to the cluster if is missing.
I think the author of that reference page expected that you would use the OpenSSL tool interactively, and that's why you can read: If your configuration for OpenSSL doesn't prompt you for a common name, the advice won't work as expected. We could change this page to use a different tool - not - that is perhaps easier to explain consistently. /sig auth /language en
Just by appending would make this reference a working copy/paste step-by-step guide.
Should we do this as the first step so the docs are correct? Then we could explore the option of a different tool as per WDYT?
/triage accepted
I won't comment on that - SIG Auth or SIG Security are the best people to explain and confirm what the right fix is here, from a technical perspective. If you know it does fix this then sure, feel free to open a PR.
I will open a PR for it. /assign
Fixed it here:
or anyone from you, could you please take a look at the PR: corresponding to this issue? Thanks


Question: <ins> --- title: クラスターレベルでのPodセキュリティの標準の適用 content_type: tutorial weight: 10 --- {{% alert title="Note" %}} このチュートリアルは、新しいクラスターにのみ適用されます。 {{% /alert %}} Podセキュリティアドミッション(PSA)は、[ベータへ進み](/blog/2021/12/09/pod-security-admission-beta/)、v1.23以降でデフォルトで有効になっています。 Podセキュリティアドミッションは、Podが作成される際に、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)の適用の認可を制御するものです。 このチュートリアルでは、クラスター内の全ての名前空間に標準設定を適用することで、クラスターレベルで`baseline` Podセキュリティの標準を強制する方法を示します。 Podセキュリティの標準を特定の名前空間に適用するには、[名前空間レベルでのPodセキュリティの標準の適用](/ja/docs/tutorials/security/ns-level-pss/)を参照してください。 v{{< skew currentVersion >}}以外のKubernetesバージョンを実行している場合は、そのバージョンのドキュメントを確認してください。 ## {{% heading "prerequisites" %}} ワークステーションに以下をインストールしてください: - [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) - [kubectl](/ja/docs/tasks/tools/) このチュートリアルでは、完全な制御下にあるKubernetesクラスターの何を設定できるかをデモンストレーションします。 コントロールプレーンを設定できない管理されたクラスターのPodセキュリティアドミッションに対しての設定方法を知りたいのであれば、[名前空間レベルでのPodセキュリティの標準の適用](/ja/docs/tutorials/security/ns-level-pss/)を参照してください。 ## 適用する正しいPodセキュリティの標準の選択 [Podのセキュリティアドミッション](/ja/docs/concepts/security/pod-security-admission/)は、以下のモードでビルトインの[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)の適用を促します: `enforce`、`audit`、`warn`。 設定に最適なPodセキュリティの標準を選択するにあたって助けになる情報を収集するために、以下を行ってください: 1. Podセキュリティの標準を適用していないクラスターを作成します: ```shell kind create cluster --name psa-wo-cluster-pss ``` 出力は次のようになります: ``` Creating cluster "psa-wo-cluster-pss" ... ✓ Ensuring node image (kindest/node:v{{< skew currentVersion >}}.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹 ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-psa-wo-cluster-pss" You can now use your cluster with: kubectl cluster-info --context kind-psa-wo-cluster-pss Thanks for using kind! 😊 ``` 1. kubectl contextを新しいクラスターにセットします: ```shell kubectl cluster-info --context kind-psa-wo-cluster-pss ``` 出力は次のようになります: ``` Kubernetes control plane is running at https://127.0.0.1:61350 CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. ``` 1. クラスター内の名前空間の一覧を取得します: ```shell kubectl get ns ``` 出力は次のようになります: ``` NAME                 STATUS   AGE default              Active   9m30s kube-node-lease      Active   9m32s kube-public          Active   9m32s kube-system          Active   9m32s local-path-storage   Active   9m26s ``` 1. 異なるPodセキュリティの標準が適用されたときに何が起きるかを理解するために、`-dry-run=server`を使います: 1. privileged ```shell kubectl label --dry-run=server --overwrite ns --all  pod-security.kubernetes.io/enforce=privileged ``` 出力は次のようになります: ``` namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled namespace/kube-system labeled namespace/local-path-storage labeled ``` 2. baseline ```shell kubectl label --dry-run=server --overwrite ns --all  pod-security.kubernetes.io/enforce=baseline ``` 出力は次のようになります: ``` namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest" Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged namespace/kube-system labeled namespace/local-path-storage labeled ``` 3. restricted ```shell kubectl label --dry-run=server --overwrite ns --all  pod-security.kubernetes.io/enforce=restricted ``` 出力は次のようになります: ``` namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest" Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile namespace/kube-system labeled Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest" Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile namespace/local-path-storage labeled ``` この出力から、`privileged` Podセキュリティの標準を適用すると、名前空間のどれにも警告が示されないことに気付くでしょう。 これに対し、`baseline`と`restrict`の標準ではどちらも、とりわけ`kube-system`名前空間に対して警告が示されています。 ## モード、バージョン、標準のセット このセクションでは、`latest`バージョンに以下のPodセキュリティの標準を適用します: * `enforce`モードで`baseline`標準。 * `warn`および`audit`モードで`restricted`標準。 `baseline` Podセキュリティの標準は、免除リストを短く保てて、かつ既知の特権昇格を防ぐような、利便性のある中庸を提供します。 加えて、`kube-system`内の失敗からPodを守るために、適用されるPodセキュリティの標準の対象から名前空間を免除します。 環境にPodセキュリティアドミッションを実装する際には、以下の点を考慮してください: 1. クラスターに適用されるリスク状況に基づくと、`restricted`のようにより厳格なPodセキュリティの標準のほうが、より良い選択肢かもしれません。 1. `kube-ssytem`名前空間の免除は、Podがその名前空間で`privileged`として実行するのを許容することになります。 実世界で使うにあたっては、以下の最小権限の原則に従って`kube-system`へのアクセスを制限する厳格なRBACポリシーを適用することを、Kubernetesプロジェクトは強く推奨します。 上記の標準を実装するには、次のようにします: 1. 目的のPodセキュリティの標準を実装するために、Podセキュリティアドミッションコントローラーで利用可能な設定ファイルを作成します: ``` mkdir -p /tmp/pss cat <<EOF > /tmp/pss/cluster-level-pss.yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest" audit: "restricted" audit-version: "latest" warn: "restricted" warn-version: "latest" exemptions: usernames: [] runtimeClasses: [] namespaces: [kube-system] EOF ``` {{< note >}} `pod-security.admission.config.k8s.io/v1`設定はv1.25+での対応です。 v1.23とv1.24では[v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)を使用してください。 v1.22では[v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)を使用してください。 {{< /note >}} 1. クラスターの作成中にこのファイルを取り込むAPIサーバーを設定します: ``` cat <<EOF > /tmp/pss/cluster-config.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: admission-control-config-file: /etc/config/cluster-level-pss.yaml extraVolumes: - name: accf hostPath: /etc/config mountPath: /etc/config readOnly: false pathType: "DirectoryOrCreate" extraMounts: - hostPath: /tmp/pss containerPath: /etc/config # optional: if set, the mount is read-only. # default false readOnly: false # optional: if set, the mount needs SELinux relabeling. # default false selinuxRelabel: false # optional: set propagation mode (None, HostToContainer or Bidirectional) # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation # default None propagation: None EOF ``` {{<note>}} macOSでDocker DesktopとKinDを利用している場合は、**Preferences > Resources > File Sharing**のメニュー項目からShared Directoryとして`/tmp`を追加できます。 {{</note>}} 1. 目的のPodセキュリティの標準を適用するために、Podセキュリティアドミッションを使うクラスターを作成します: ```shell kind create cluster --name psa-with-cluster-pss --config /tmp/pss/cluster-config.yaml ``` 出力は次のようになります: ``` Creating cluster "psa-with-cluster-pss" ... ✓ Ensuring node image (kindest/node:v{{< skew currentVersion >}}.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹 ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-psa-with-cluster-pss" You can now use your cluster with: kubectl cluster-info --context kind-psa-with-cluster-pss Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 ``` 1. kubectlをこのクラスターに向けます: ```shell kubectl cluster-info --context kind-psa-with-cluster-pss ``` 出力は次のようになります: ``` Kubernetes control plane is running at https://127.0.0.1:63855 CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. ``` 1. デフォルトの名前空間にPodを作成します: ```shell kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml ``` Podは正常に開始されますが、出力には警告が含まれます: ``` Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") pod/nginx created ``` ## 後片付け では、上記で作成したクラスターを、以下のコマンドを実行して削除します: ```shell kind delete cluster --name psa-with-cluster-pss ``` ```shell kind delete cluster --name psa-wo-cluster-pss ``` ## {{% heading "whatsnext" %}} - 前出の一連の手順を一度に全て行うために[シェルスクリプト](/examples/security/kind-with-cluster-level-baseline-pod-security.sh)を実行します: 1. クラスターレベルの設定に基づきPodセキュリティの標準を作成します。 2. APIサーバーでこの設定を取り込むようにファイルを作成します。 3. この設定のAPIサーバーを立てるクラスターを作成します。 4. この新しいクラスターにkubectl contextをセットします。 5. 最小限のPod YAMLファイルを作成します。 6. 新しいクラスター内でPodを作成するために、このファイルを適用します。 - [Podのセキュリティアドミッション](/ja/docs/concepts/security/pod-security-admission/) - [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) - [名前空間レベルでのPodセキュリティの標準の適用](/ja/docs/tutorials/security/ns-level-pss/) </ins>

This is a Feature Request What would you like to be Translate into Japanese Why is this needed Comments /language ja /assign
/triage accepted