Question:
 --- api_metadata: apiVersion: "certificates.k8s.io/v1alpha1" import: "k8s.io/api/certificates/v1alpha1" kind: "ClusterTrustBundle" content_type: "api_reference" description: "ClusterTrustBundle 是一个集群范围的容器，用于存放 X.509 信任锚（根证书）。" title: "ClusterTrustBundle v1alpha1" weight: 5 ---  `apiVersion: certificates.k8s.io/v1alpha1` `import "k8s.io/api/certificates/v1alpha1"` ## ClusterTrustBundle {#ClusterTrustBundle}  ClusterTrustBundle 是一个集群范围的容器，用于存放 X.509 信任锚（根证书）。 ClusterTrustBundle 对象被视为可被集群中的任何已通过身份验证的用户读取， 因为此对象可以由使用 `clusterTrustBundle` 投射的 Pod 挂载。 所有服务账号默认都有对 ClusterTrustBundle 的读取权限。 对于仅对集群具有命名空间级访问权限的用户，可以通过伪装他们可以访问的服务账号来读取 ClusterTrustBundle。  ClusterTrustBundle 可以选择与特定的签名程序相关联，此时它包含该签名程序的一组有效信任锚。 签名程序可以有多个关联的 ClusterTrustBundle； 对于该签名程序而言每个 ClusterTrustBundle 都是独立的一组信任锚。 准入控制用于确保只有对签名程序有访问权限的用户才能创建或修改相应的捆绑包。
 - **apiVersion**: certificates.k8s.io/v1alpha1 - **kind**: ClusterTrustBundle  - **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta) metadata 包含对象的元数据。 - **spec** (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundleSpec" >}}">ClusterTrustBundleSpec)，必需 spec 包含签名程序（如果有）和信任锚。 ## ClusterTrustBundleSpec {#ClusterTrustBundleSpec}  ClusterTrustBundleSpec 包含签名程序和信任锚。
  - **trustBundle** (string)，必需 trustBundle 包含此捆绑包的各个 X.509 信任锚，这个 PEM 捆绑包是采用 PEM 包装的 DER 格式的若干 X.509 证书。  数据必须仅由可解析为有效 X.509 证书的 PEM 证书块组成。 每个证书必须包含设置了 CA 标志的基本约束扩展。 API 服务器将拒绝包含重复证书或使用 PEM 块头的对象。 ClusterTrustBundles 的使用者（包括 kubelet）可以根据自己的逻辑对此文件中的证书块进行重新排序和去重， 也可以删除 PEM 块头和块间数据。  - **signerName** (string) signerName 表示关联的签名程序（如果有）。 要创建或更新设置了 signerName 属性的 ClusterTrustBundle，你必须具备以下集群范围的权限：  group=certificates.k8s.io resource=signers resourceName=<签名程序名称> verb=attest   如果 signerName 不为空，则 ClusterTrustBundle 对象的名称必须以签名程序名称作为前缀（将斜杠转换为冒号）。 例如，对于签名程序名称 `example.com/foo`，有效的 ClusterTrustBundle 对象名称包括 `example.com:foo:abc` 和 `example.com:foo:v1`。 如果 signerName 为空，则 ClusterTrustBundle 对象的名称不能具有此类前缀。 针对 ClusterTrustBundles 的列举/监视请求可以使用 `spec.signerName=NAME` 字段选择算符针对此字段进行过滤。 ## ClusterTrustBundleList {#ClusterTrustBundleList}  ClusterTrustBundleList 是 ClusterTrustBundle 对象的集合。
 - **apiVersion**: certificates.k8s.io/v1alpha1 - **kind**: ClusterTrustBundleList  - **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta) metadata 包含列表的元数据。 - **items** ([]<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle)，必需 items 是 ClusterTrustBundle 对象的集合。  ## 操作 {#Operations}
  ### `get` 读取指定的 ClusterTrustBundle #### HTTP 请求 GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}  #### 参数 - **name**（**路径参数**）：string，必需 ClusterTrustBundle 的名称。 - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): OK 401: Unauthorized  ### `list` 列举或监视类别为 ClusterTrustBundle 的对象 #### HTTP 请求 GET /apis/certificates.k8s.io/v1alpha1/clustertrustbundles  #### 参数 - **allowWatchBookmarks**（**查询参数**）：boolean <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks - **continue**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue - **fieldSelector**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector - **labelSelector**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector - **limit**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty - **resourceVersion**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion - **resourceVersionMatch**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch - **sendInitialEvents**（**查询参数**）：boolean <a href="{{< ref "../common-parameters/common-parameters#sendInitialEvents" >}}">sendInitialEvents - **timeoutSeconds**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds - **watch**（**查询参数**）：boolean <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch  #### 响应 200 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundleList" >}}">ClusterTrustBundleList): OK 401: Unauthorized  ### `create` 创建 ClusterTrustBundle #### HTTP 请求 POST /apis/certificates.k8s.io/v1alpha1/clustertrustbundles  #### 参数 - **body**: <a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle，必需 - **dryRun**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun - **fieldManager**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager - **fieldValidation**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): OK 201 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): Created 202 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): Accepted 401: Unauthorized  ### `update` 替换指定的 ClusterTrustBundle #### HTTP 请求 PUT /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}  #### 参数 - **name**（**路径参数**）：string，必需 ClusterTrustBundle 的名称。 - **body**: <a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle，必需 - **dryRun**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun - **fieldManager**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager - **fieldValidation**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): OK 201 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): Created 401: Unauthorized  ### `patch` 部分更新指定的 ClusterTrustBundle #### HTTP 请求 PATCH /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}  #### 参数 - **name**（**路径参数**）：string，必需 ClusterTrustBundle 的名称。 - **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch，必需 - **dryRun**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun - **fieldManager**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager - **fieldValidation**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation - **force**（**查询参数**）：boolean <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): OK 201 (<a href="{{< ref "../authentication-resources/cluster-trust-bundle-v1alpha1#ClusterTrustBundle" >}}">ClusterTrustBundle): Created 401: Unauthorized  ### `delete` 删除 ClusterTrustBundle #### HTTP 请求 DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles/{name}  #### 参数 - **name**（**路径参数**）：string，必需 ClusterTrustBundle 的名称。 - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions - **dryRun**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun - **gracePeriodSeconds**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty - **propagationPolicy**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 202 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): Accepted 401: Unauthorized  ### `deletecollection` 删除 ClusterTrustBundle 的集合 #### HTTP 请求 DELETE /apis/certificates.k8s.io/v1alpha1/clustertrustbundles  #### 参数 - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions - **continue**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue - **dryRun**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun - **fieldSelector**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector - **gracePeriodSeconds**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds - **labelSelector**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector - **limit**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit - **pretty**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty - **propagationPolicy**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy - **resourceVersion**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion - **resourceVersionMatch**（**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch - **sendInitialEvents**（**查询参数**）：boolean <a href="{{< ref "../common-parameters/common-parameters#sendInitialEvents" >}}">sendInitialEvents - **timeoutSeconds**（**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 401: Unauthorized

The API reference is not yet localized into zh-cn.
/sig docs /language zh /area localization
/triage accepted
can I take up this??
/assign


Question: kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Dump current cluster state to /path/to/cluster-state # View existing taints on which exist on current nodes. <del> kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect </del> <ins> kubectl get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect' </ins> # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule

Add quotes in the flag of command to avoid confusing the shell: Otherwise, this is what user may see:
Link:
/assign
/triage accepted /language en /retitle Unquoted command in kubectl cheat sheet


Question: This tutorial assumes that you are using `minikube` to run a local Kubernetes cluster. Visit [Install tools](/docs/tasks/tools/#minikube) to learn how to install `minikube`. <ins> {{< note >}} This tutorial uses a container that requires the AMD64 architecture. If you are using minikube on a computer with a different CPU architecture, you could try using minikube with a driver that can emulate AMD64. For example, the Docker Desktop driver can do this. {{< /note >}} </ins> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} If you are using an older Kubernetes version, switch to the documentation for that version.

Problem: Going through the documentation provided by the link such issue has being met on the step of verification that Ingress controller is directing the traffic using the command below: curl --resolve "hello-$( minikube ip )" -i http://hello- After running this command the terminal returns: Failed to connect to hello- port 80 after ms: Couldn't connect to server Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Kubernetes version: v1.28.3 <!--Additional Information:--Environment that is used: Macbook M1 Pro Minikube version: v1.32.0 Minikube uses the docker driver. Step on which problem has been met:
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
Page reported in issue: /language en
This is same as issue /triage duplicate I believe this should be fixed by updating the page by mentioning the instructions to create a for MacOS and Windows users. I'll try to work on a PR for this. Till the time the page is modified, the way around this is mentioned . The reason why it fails on MacOS and Windows is documented here , , You can also visit the page and view the tab in Step 4 Deploy applications.
/assign

you need start and then to solve same problem in mac
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
/triage needs-information Hi. Is this about a particular web page?
sorry, this is about following tutorial Create an Ingress step 4
/retitle Ingress tutorial does not mention commands needed for Mac /remove-triage needs-information
/kind bug /language en
I can confirm that this is a valid issue on MacOS and the page needs to be updated. I think we should move this to /triage accepted. I cannot test this on Windows at the moment, but suggests that the behaviour on Windows will be the same as MacOS. The network is limited if using the Docker driver on Darwin, Windows, or WSL, and the Node IP is not reachable directly.
/assign


Question: 同样，查看`annotations`文件： ```shell <del> /# cat /etc/annotations </del> <ins> /# cat /etc/podinfo/annotations </ins> ``` <!--

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


Question: memory: 200Mi requests: memory: 100Mi <del> ... </del> <ins> ... status: </ins> qosClass: Burstable ```

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


Question: to see its supported topology keys and examples. {{< note >}} <del> If you choose to use `waitForFirstConsumer`, do not use `nodeName` in the Pod spec </del> <ins> If you choose to use `WaitForFirstConsumer`, do not use `nodeName` in the Pod spec </ins> to specify node affinity. If `nodeName` is used in this case, the scheduler will be bypassed and PVC will remain in `pending` state. Instead, you can use node selector for hostname in this case as shown below.

In ; waitForFirstConsumer is spelt. Correct spelling is WaitForFirstConsumer
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
Issue solved with


Question: This prevents dangling load balancer resources even in corner cases such as the service controller crashing. <del> ## External Load Balancer Providers </del> <ins> ## External load balancer providers </ins> It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster. When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods <del> within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object. ## Caveats and Limitations when preserving source IPs GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB kube-proxy rules which would correctly balance across all endpoints. With the new functionality, the external traffic is not equally load balanced across pods, but rather equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability for specifying the weight per node, they balance equally across all target nodes, disregarding the number of pods on each node). We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal distribution will be seen, even without weights. Once the external load balancers provide weights, this functionality can be added to the LB programming path. *Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date* Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. </del> <ins> within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the nodes hosting the relevant Kubernetes pods. The Kubernetes control plane automates the creation of the external load balancer, health checks (if needed), and packet filtering rules (if needed). Once the cloud provider allocates an IP address for the load balancer, the control plane looks up that external IP address and populates it into the Service object. ## {{% heading "whatsnext" %}} * Read about [Service](/docs/concepts/services-networking/service/) * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: mentions: (see ) Weights aren't built in to Service / Endpoints / EndpointSlice / Ingress but you can indicate weighting with annotations and similar mechanisms. For example: https://kubernetes- Proposed Solution: Remove the text: Revise to explain that each implementation uses its own mechanisms for weighting and that these are not standardized. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.19 Additional Information: /language en /sig network
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten
Reopened this issue.

<detailsIn response to : /reopen /remove-lifecycle rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:


Question: 注意，某些方案可能需要同时采用几种类型的扩展。 <!-- image source for flowchart: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> <del> {{< figure src="/zh-cn/docs/concepts/extend-kubernetes/flowchart.png" </del> <ins> {{< figure src="/zh-cn/docs/concepts/extend-kubernetes/flowchart.svg" </ins> alt="附带使用场景问题和实现指南的流程图。绿圈表示是；红圈表示否。" class="diagram-large" caption="选择一个扩展方式的流程图指导" >}}

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
Please raise the issue in English language so that it can be easy to understand in community.
/language zh Issue Translation is Currently this After this page select , the text in the flow chart is not .
/triage needs-information Even with a translation, I don't understand if this is a bug report, a support query, or a feature request.
/retitle [zh] Bug - the text in the flowchart should be Chinese on Extending Kubernetes page It is a bug, on zh-cn page , the text in the flowchart should be Chinese instead of Korean.
Re-titling can only be requested by trusted users, like repository collaborators. <detailsIn response to : /retitle [zh] Bug - the text in the flowchart should be Chinese on Extending Kubernetes page , the text in the flowchart should be Chinese instead of Korean. 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
/retitle [zh] Bug - the text in the flowchart should be Chinese on Extending Kubernetes page
/assign


Question: use of that credential. Set short lifetimes on certificates and automate their rotation. Use an authentication provider that can control how long issued tokens are available and use short lifetimes where possible. If you use service-account tokens in external integrations, plan to <del> rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap </del> <ins> rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap </ins> token used for setting up nodes should be revoked or its authorization removed. ### Review third party integrations before enabling them

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --We have two pages with similar aims: We should ensure that the advice in the two documents is aligned, and also make sure that the two documents link to each other. Why is this needed It's a bad idea to document multiple ways to make sure that your cluster is secure, unless those are well aligned. Comments /sig security /sig docs /language en
Relevant to
Regarding this: We can use a reference section/note/what's next section in the end of stating: -
/triage accepted
Hey I would like to work on this.
/assign


Question: {{< note >}} Um eine spezifische Version herunterzuladen, ersetze `$(curl -L -s https://dl.k8s.io/release/stable.txt)` mit der spezifischen Version <del> Um zum Beispiel Version {{< param "fullversion" >}} auf Intel macOS herunterzuladen: </del> <ins> Um zum Beispiel Version {{< skew currentPatchVersion >}} auf Intel macOS herunterzuladen: </ins> ```bash <del> curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl" </ins> ``` Für macOS auf Apple Silicon (z.B. M1/M2): ```bash <del> curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/arm64/kubectl" </ins> ``` {{< /note >}}

[de] Replace deprecated shortcode Problem: Based on , I have created this issue/task to help update the [de] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 42: Um zum Beispiel Version {{< param "fullversion" }} auf Linux herunterzuladen: 45: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 47: Um zum Beispiel Version {{< param "fullversion" }} auf Intel macOS herunterzuladen: 50: curl -LO "{{< param "fullversion" }}/bin/darwin/amd64/kubectl" 56: curl -LO "{{< param "fullversion" }}/bin/darwin/arm64/kubectl" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install- 200: Um beispielsweise die Version {{< param "fullversion" }} auf macOS herunterzuladen, verwenden Sie 203: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 228: Um beispielsweise die Version {{< param "fullversion" }} auf Linux herunterzuladen, verwenden Sie 231: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 247: Laden Sie das aktuellste Release {{< param "fullversion" }} von diesem linkg


Question: <ins> --- layout: blog title: "在 CRI 运行时内验证容器镜像签名" date: 2023-06-29 slug: container-image-signature-verification --- <!-- layout: blog title: "Verifying Container Image Signatures Within CRI Runtimes" date: 2023-06-29 slug: container-image-signature-verification --> <!-- **Author**: Sascha Grunert --> **作者:** Sascha Grunert **译者:** [Michael Yao](https://github.com/windsonsea) (DaoCloud) <!-- The Kubernetes community has been signing their container image-based artifacts since release v1.24. While the graduation of the [corresponding enhancement][kep] from `alpha` to `beta` in v1.26 introduced signatures for the binary artifacts, other projects followed the approach by providing image signatures for their releases, too. This means that they either create the signatures within their own CI/CD pipelines, for example by using GitHub actions, or rely on the Kubernetes [image promotion][promo] process to automatically sign the images by proposing pull requests to the [k/k8s.io][k8s.io] repository. A requirement for using this process is that the project is part of the `kubernetes` or `kubernetes-sigs` GitHub organization, so that they can utilize the community infrastructure for pushing images into staging buckets. --> Kubernetes 社区自 v1.24 版本开始对基于容器镜像的工件进行签名。在 v1.26 中， [相应的增强特性][kep]从 `alpha` 进阶至 `beta`，引入了针对二进制工件的签名。 其他项目也采用了类似的方法，为其发布版本提供镜像签名。这意味着这些项目要么使用 GitHub actions 在自己的 CI/CD 流程中创建签名，要么依赖于 Kubernetes 的[镜像推广][promo]流程， 通过向 [k/k8s.io][k8s.io] 仓库提交 PR 来自动签名镜像。 使用此流程的前提要求是项目必须属于 `kubernetes` 或 `kubernetes-sigs` GitHub 组织， 这样能够利用社区基础设施将镜像推送到暂存桶中。 [kep]: https://github.com/kubernetes/enhancements/issues/3031 [promo]: https://github.com/kubernetes-sigs/promo-tools/blob/e2b96dd/docs/image-promotion.md [k8s.io]: https://github.com/kubernetes/k8s.io/tree/4b95cc2/k8s.gcr.io <!-- Assuming that a project now produces signed container image artifacts, how can one actually verify the signatures? It is possible to do it manually like outlined in the [official Kubernetes documentation][docs]. The problem with this approach is that it involves no automation at all and should be only done for testing purposes. In production environments, tools like the [sigstore policy-controller][policy-controller] can help with the automation. These tools provide a higher level API by using [Custom Resource Definitions (CRD)][crd] as well as an integrated [admission controller and webhook][admission] to verify the signatures. --> 假设一个项目现在生成了已签名的容器镜像工件，那么如何实际验证这些签名呢？ 你可以按照 [Kubernetes 官方文档][docs]所述来手动验证。但是这种方式的问题在于完全没有自动化， 应仅用于测试目的。在生产环境中，[sigstore policy-controller][policy-controller] 这样的工具有助于进行自动化处理。这些工具使用[自定义资源定义（CRD）][crd]提供了更高级别的 API， 并且利用集成的[准入控制器和 Webhook][admission]来验证签名。 [docs]: /zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures [policy-controller]: https://docs.sigstore.dev/policy-controller/overview [crd]: /zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources [admission]: /zh-cn/docs/reference/access-authn-authz/admission-controllers <!-- The general usage flow for an admission controller based verification is: --> 基于准入控制器的验证的一般使用流程如下： <!-- {{< figure src="/blog/2023/06/29/container-image-signature-verification/flow.svg" alt="Create an instance of the policy and annotate the namespace to validate the signatures. Then create the pod. The controller evaluates the policy and if it passes, then it does the image pull if necessary. If the policy evaluation fails, then it will not admit the pod." >}} --> {{< figure src="/blog/2023/06/29/container-image-signature-verification/flow.svg" alt="创建一个策略的实例，并对命名空间添加注解以验证签名。然后创建 Pod。控制器会评估策略，如果评估通过，则根据需要执行镜像拉取。如果策略评估失败，则不允许该 Pod 运行。" >}} <!-- A key benefit of this architecture is simplicity: A single instance within the cluster validates the signatures before any image pull can happen in the container runtime on the nodes, which gets initiated by the kubelet. This benefit also brings along the issue of separation: The node which should pull the container image is not necessarily the same node that performs the admission. This means that if the controller is compromised, then a cluster-wide policy enforcement can no longer be possible. One way to solve this issue is doing the policy evaluation directly within the [Container Runtime Interface (CRI)][cri] compatible container runtime. The runtime is directly connected to the [kubelet][kubelet] on a node and does all the tasks like pulling images. [CRI-O][cri-o] is one of those available runtimes and will feature full support for container image signature verification in v1.28. --> 这种架构的一个主要优点是简单：集群中的单个实例会先验证签名，然后才在节点上的容器运行时中执行镜像拉取操作， 镜像拉取是由 kubelet 触发的。这个优点也带来了分离的问题：应拉取容器镜像的节点不一定是执行准入控制的节点。 这意味着如果控制器受到攻击，那么无法在整个集群范围内强制执行策略。 解决此问题的一种方式是直接在与[容器运行时接口（CRI）][cri]兼容的容器运行时中进行策略评估。 这种运行时直接连接到节点上的 [kubelet][kubelet]，执行拉取镜像等所有任务。 [CRI-O][cri-o] 是可用的运行时之一，将在 v1.28 中完全支持容器镜像签名验证。 [cri]: /docs/concepts/architecture/cri [kubelet]: /docs/reference/command-line-tools-reference/kubelet [cri-o]: https://github.com/cri-o/cri-o <!-- How does it work? CRI-O reads a file called [`policy.json`][policy.json], which contains all the rules defined for container images. For example, you can define a policy which only allows signed images `quay.io/crio/signed` for any tag or digest like this: --> 容器运行时是如何工作的呢？CRI-O 会读取一个名为 [`policy.json`][policy.json] 的文件， 其中包含了为容器镜像定义的所有规则。例如，你可以定义一个策略， 只允许带有以下标记或摘要的已签名镜像 `quay.io/crio/signed`： [policy.json]: https://github.com/containers/image/blob/b3e0ba2/docs/containers-policy.json.5.md#sigstoresigned ```json { "default": [{ "type": "reject" }], "transports": { "docker": { "quay.io/crio/signed": [ { "type": "sigstoreSigned", "signedIdentity": { "type": "matchRepository" }, "fulcio": { "oidcIssuer": "https://github.com/login/oauth", "subjectEmail": "sgrunert@redhat.com", "caData": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUI5ekNDQVh5Z0F3SUJBZ0lVQUxaTkFQRmR4SFB3amVEbG9Ed3lZQ2hBTy80d0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNVEV3TURjeE16VTJOVGxhRncwek1URXdNRFV4TXpVMk5UaGFNQ294RlRBVEJnTlZCQW9UREhOcFozTjBiM0psCkxtUmxkakVSTUE4R0ExVUVBeE1JYzJsbmMzUnZjbVV3ZGpBUUJnY3Foa2pPUFFJQkJnVXJnUVFBSWdOaUFBVDcKWGVGVDRyYjNQUUd3UzRJYWp0TGszL09sbnBnYW5nYUJjbFlwc1lCcjVpKzR5bkIwN2NlYjNMUDBPSU9aZHhleApYNjljNWlWdXlKUlErSHowNXlpK1VGM3VCV0FsSHBpUzVzaDArSDJHSEU3U1hyazFFQzVtMVRyMTlMOWdnOTJqCll6QmhNQTRHQTFVZER3RUIvd1FFQXdJQkJqQVBCZ05WSFJNQkFmOEVCVEFEQVFIL01CMEdBMVVkRGdRV0JCUlkKd0I1ZmtVV2xacWw2ekpDaGt5TFFLc1hGK2pBZkJnTlZIU01FR0RBV2dCUll3QjVma1VXbFpxbDZ6SkNoa3lMUQpLc1hGK2pBS0JnZ3Foa2pPUFFRREF3TnBBREJtQWpFQWoxbkhlWFpwKzEzTldCTmErRURzRFA4RzFXV2cxdENNCldQL1dIUHFwYVZvMGpoc3dlTkZaZ1NzMGVFN3dZSTRxQWpFQTJXQjlvdDk4c0lrb0YzdlpZZGQzL1Z0V0I1YjkKVE5NZWE3SXgvc3RKNVRmY0xMZUFCTEU0Qk5KT3NRNHZuQkhKCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=" }, "rekorPublicKeyData": "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFMkcyWSsydGFiZFRWNUJjR2lCSXgwYTlmQUZ3cgprQmJtTFNHdGtzNEwzcVg2eVlZMHp1ZkJuaEM4VXIvaXk1NUdoV1AvOUEvYlkyTGhDMzBNOStSWXR3PT0KLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tCg==" } ] } } } ``` <!-- CRI-O has to be started to use that policy as the global source of truth: --> CRI-O 必须被启动才能将策略用作全局的可信源： ```console > sudo crio --log-level debug --signature-policy ./policy.json ``` <!-- CRI-O is now able to pull the image while verifying its signatures. This can be done by using [`crictl` (cri-tools)][cri-tools], for example: --> CRI-O 现在可以在验证镜像签名的同时拉取镜像。例如，可以使用 [`crictl`（cri-tools）][cri-tools] 来完成此操作： [cri-tools]: https://github.com/kubernetes-sigs/cri-tools ```console > sudo crictl -D pull quay.io/crio/signed DEBU[…] get image connection DEBU[…] PullImageRequest: &PullImageRequest{Image:&ImageSpec{Image:quay.io/crio/signed,Annotations:map[string]string{},},Auth:nil,SandboxConfig:nil,} DEBU[…] PullImageResponse: &PullImageResponse{ImageRef:quay.io/crio/signed@sha256:18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a,} Image is up to date for quay.io/crio/signed@sha256:18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a ``` <!-- The CRI-O debug logs will also indicate that the signature got successfully validated: --> CRI-O 的调试日志也会表明签名已成功验证： ```console DEBU[…] IsRunningImageAllowed for image docker:quay.io/crio/signed:latest DEBU[…]  Using transport "docker" specific policy section quay.io/crio/signed DEBU[…] Reading /var/lib/containers/sigstore/crio/signed@sha256=18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a/signature-1 DEBU[…] Looking for sigstore attachments in quay.io/crio/signed:sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig DEBU[…] GET https://quay.io/v2/crio/signed/manifests/sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig DEBU[…] Content-Type from manifest GET is "application/vnd.oci.image.manifest.v1+json" DEBU[…] Found a sigstore attachment manifest with 1 layers DEBU[…] Fetching sigstore attachment 1/1: sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45 DEBU[…] Downloading /v2/crio/signed/blobs/sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45 DEBU[…] GET https://quay.io/v2/crio/signed/blobs/sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45 DEBU[…]  Requirement 0: allowed DEBU[…] Overall: allowed ``` <!-- All of the defined fields like `oidcIssuer` and `subjectEmail` in the policy have to match, while `fulcio.caData` and `rekorPublicKeyData` are the public keys from the upstream [fulcio (OIDC PKI)][fulcio] and [rekor (transparency log)][rekor] instances. --> 策略中定义的 `oidcIssuer` 和 `subjectEmail` 等所有字段都必须匹配， 而 `fulcio.caData` 和 `rekorPublicKeyData` 是来自上游 [fulcio（OIDC PKI）][fulcio] 和 [rekor（透明日志）][rekor] 实例的公钥。 [fulcio]: https://github.com/sigstore/fulcio [rekor]: https://github.com/sigstore/rekor <!-- This means that if you now invalidate the `subjectEmail` of the policy, for example to `wrong@mail.com`: --> 这意味着如果你现在将策略中的 `subjectEmail` 作废，例如更改为 `wrong@mail.com`： ```console > jq '.transports.docker."quay.io/crio/signed"[0].fulcio.subjectEmail = "wrong@mail.com"' policy.json > new-policy.json > mv new-policy.json policy.json ``` <!-- Then remove the image, since it already exists locally: --> 然后移除镜像，因为此镜像已存在于本地： ```console > sudo crictl rmi quay.io/crio/signed ``` <!-- Now when you pull the image, CRI-O complains that the required email is wrong: --> 现在当你拉取镜像时，CRI-O 将报错所需的 email 是错的： ```console > sudo crictl pull quay.io/crio/signed FATA[…] pulling image: rpc error: code = Unknown desc = Source image rejected: Required email wrong@mail.com not found (got []string{"sgrunert@redhat.com"}) ``` <!-- It is also possible to test an unsigned image against the policy. For that you have to modify the key `quay.io/crio/signed` to something like `quay.io/crio/unsigned`: --> 你还可以对未签名的镜像进行策略测试。为此，你需要将键 `quay.io/crio/signed` 修改为类似 `quay.io/crio/unsigned`： ```console > sed -i 's;quay.io/crio/signed;quay.io/crio/unsigned;' policy.json ``` <!-- If you now pull the container image, CRI-O will complain that no signature exists for it: --> 如果你现在拉取容器镜像，CRI-O 将报错此镜像不存在签名： ```console > sudo crictl pull quay.io/crio/unsigned FATA[…] pulling image: rpc error: code = Unknown desc = SignatureValidationFailed: Source image rejected: A signature was required, but no signature exists ``` <!-- It is important to mention that CRI-O will match the `.critical.identity.docker-reference` field within the signature to match with the image repository. For example, if you verify the image `registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.3`, then the corresponding `docker-reference` should be `registry.k8s.io/kube-apiserver-amd64`: --> 需要强调的是，CRI-O 将签名中的 `.critical.identity.docker-reference` 字段与镜像仓库进行匹配。 例如，如果你要验证镜像 `registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.3`， 则相应的 `docker-reference` 须是 `registry.k8s.io/kube-apiserver-amd64`： ```console > cosign verify registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.3  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com  --certificate-oidc-issuer https://accounts.google.com  | jq -r '.[0].critical.identity."docker-reference"' … registry.k8s.io/kubernetes/kube-apiserver-amd64 ``` <!-- The Kubernetes community introduced `registry.k8s.io` as proxy mirror for various registries. Before the release of [kpromo v4.0.2][kpromo], images had been signed with the actual mirror rather than `registry.k8s.io`: --> Kubernetes 社区引入了 `registry.k8s.io` 作为各种镜像仓库的代理镜像。 在 [kpromo v4.0.2][kpromo] 版本发布之前，镜像已使用实际镜像签名而不是使用 `registry.k8s.io` 签名： [kpromo]: https://github.com/kubernetes-sigs/promo-tools/releases/tag/v4.0.2 ```console > cosign verify registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.2  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com  --certificate-oidc-issuer https://accounts.google.com  | jq -r '.[0].critical.identity."docker-reference"' … asia-northeast2-docker.pkg.dev/k8s-artifacts-prod/images/kubernetes/kube-apiserver-amd64 ``` <!-- The change of the `docker-reference` to `registry.k8s.io` makes it easier for end users to validate the signatures, because they cannot know anything about the underlying infrastructure being used. The feature to set the identity on image signing has been added to [cosign][cosign-pr] via the flag `sign --sign-container-identity` as well and will be part of its upcoming release. --> 将 `docker-reference` 更改为 `registry.k8s.io` 使最终用户更容易验证签名， 因为他们不需要知道所使用的底层基础设施的详细信息。设置镜像签名身份的特性已通过 `sign --sign-container-identity` 标志添加到 `cosign`，并将成为即将发布的版本的一部分。 [cosign-pr]: https://github.com/sigstore/cosign/pull/2984 <!-- The Kubernetes image pull error code `SignatureValidationFailed` got [recently added to Kubernetes][pr-117717] and will be available from v1.28. This error code allows end-users to understand image pull failures directly from the kubectl CLI. For example, if you run CRI-O together with Kubernetes using the policy which requires `quay.io/crio/unsigned` to be signed, then a pod definition like this: --> [最近在 Kubernetes 中添加了][pr-117717]镜像拉取错误码 `SignatureValidationFailed`， 将从 v1.28 版本开始可用。这个错误码允许最终用户直接从 kubectl CLI 了解镜像拉取失败的原因。 例如，如果你使用要求对 `quay.io/crio/unsigned` 进行签名的策略同时运行 CRI-O 和 Kubernetes， 那么 Pod 的定义如下： [pr-117717]: https://github.com/kubernetes/kubernetes/pull/117717 ```yaml apiVersion: v1 kind: Pod metadata: name: pod spec: containers: - name: container image: quay.io/crio/unsigned ``` <!-- Will cause the `SignatureValidationFailed` error when applying the pod manifest: --> 将在应用 Pod 清单时造成 `SignatureValidationFailed` 错误： ```console > kubectl apply -f pod.yaml pod/pod created ``` ```console > kubectl get pods NAME   READY   STATUS                      RESTARTS   AGE pod    0/1     SignatureValidationFailed   0          4s ``` ```console > kubectl describe pod pod | tail -n8 Type     Reason     Age                From               Message ----     ------     ----               ----               ------- Normal   Scheduled  58s                default-scheduler  Successfully assigned default/pod to 127.0.0.1 Normal   BackOff    22s (x2 over 55s)  kubelet            Back-off pulling image "quay.io/crio/unsigned" Warning  Failed     22s (x2 over 55s)  kubelet            Error: ImagePullBackOff Normal   Pulling    9s (x3 over 58s)   kubelet            Pulling image "quay.io/crio/unsigned" Warning  Failed     6s (x3 over 55s)   kubelet            Failed to pull image "quay.io/crio/unsigned": SignatureValidationFailed: Source image rejected: A signature was required, but no signature exists Warning  Failed     6s (x3 over 55s)   kubelet            Error: SignatureValidationFailed ``` <!-- This overall behavior provides a more Kubernetes native experience and does not rely on third party software to be installed in the cluster. --> 这种整体行为提供了更符合 Kubernetes 原生体验的方式，并且不依赖于在集群中安装的第三方软件。 <!-- There are still a few corner cases to consider: For example, what if you want to allow policies per namespace in the same way the policy-controller supports it? Well, there is an upcoming CRI-O feature in v1.28 for that! CRI-O will support the `--signature-policy-dir` / `signature_policy_dir` option, which defines the root path for pod namespace-separated signature policies. This means that CRI-O will lookup that path and assemble a policy like `<SIGNATURE_POLICY_DIR>/<NAMESPACE>.json`, which will be used on image pull if existing. If no pod namespace is provided on image pull ([via the sandbox config][sandbox-config]), or the concatenated path is non-existent, then CRI-O's global policy will be used as fallback. --> 还有一些特殊情况需要考虑：例如，如果你希望像策略控制器那样允许按命名空间设置策略，怎么办？ 好消息是，CRI-O 在 v1.28 版本中即将推出这个特性！CRI-O 将支持 `--signature-policy-dir` / `signature_policy_dir` 选项，为命名空间隔离的签名策略的 Pod 定义根路径。 这意味着 CRI-O 将查找该路径，并组装一个类似 `<SIGNATURE_POLICY_DIR>/<NAMESPACE>.json` 的策略，在镜像拉取时如果存在则使用该策略。如果（[通过沙盒配置][sandbox-config]） 在镜像拉取时未提供 Pod 命名空间，或者串接的路径不存在，则 CRI-O 的全局策略将用作后备。 [sandbox-config]: https://github.com/kubernetes/cri-api/blob/e5515a5/pkg/apis/runtime/v1/api.proto#L1448 <!-- Another corner case to consider is critical for the correct signature verification within container runtimes: The kubelet only invokes container image pulls if the image does not already exist on disk. This means that an unrestricted policy from Kubernetes namespace A can allow pulling an image, while namespace B is not able to enforce the policy because it already exits on the node. Finally, CRI-O has to verify the policy not only on image pull, but also on container creation. This fact makes things even a bit more complicated, because the CRI does not really pass down the user specified image reference on container creation, but an already resolved image ID, or digest. A [small change to the CRI][pr-118652] can help with that. --> 另一个需要考虑的特殊情况对于容器运行时中正确的签名验证至关重要：kubelet 仅在磁盘上不存在镜像时才调用容器镜像拉取。这意味着来自 Kubernetes 命名空间 A 的不受限策略可以允许拉取一个镜像，而命名空间 B 则无法强制执行该策略， 因为它已经存在于节点上了。最后，CRI-O 必须在容器创建时验证策略，而不仅仅是在镜像拉取时。 这一事实使情况变得更加复杂，因为 CRI 在容器创建时并没有真正传递用户指定的镜像引用， 而是传递已经解析过的镜像 ID 或摘要。[对 CRI 进行小改动][pr-118652] 有助于解决这个问题。 [pr-118652]: https://github.com/kubernetes/kubernetes/pull/118652 <!-- Now that everything happens within the container runtime, someone has to maintain and define the policies to provide a good user experience around that feature. The CRDs of the policy-controller are great, while we could imagine that a daemon within the cluster can write the policies for CRI-O per namespace. This would make any additional hook obsolete and moves the responsibility of verifying the image signature to the actual instance which pulls the image. [I evaluated][thread] other possible paths toward a better container image signature verification within plain Kubernetes, but I could not find a great fit for a native API. This means that I believe that a CRD is the way to go, but users still need an instance which actually serves it. --> 现在一切都发生在容器运行时中，大家必须维护和定义策略以提供良好的用户体验。 策略控制器的 CRD 非常出色，我们可以想象集群中的一个守护进程可以按命名空间为 CRI-O 编写策略。 这将使任何额外的回调过时，并将验证镜像签名的责任移交给实际拉取镜像的实例。 我已经评估了在纯 Kubernetes 中实现更好的容器镜像签名验证的其他可能途径， 但我没有找到一个很好的原生 API 解决方案。这意味着我相信 CRD 是正确的方法， 但用户仍然需要一个实际有作用的实例。 [thread]: https://groups.google.com/g/kubernetes-sig-node/c/kgpxqcsJ7Vc/m/7X7t_ElsAgAJ <!-- Thank you for reading this blog post! If you're interested in more, providing feedback or asking for help, then feel free to get in touch with me directly via [Slack (#crio)][slack] or the [SIG Node mailing list][mail]. --> 感谢阅读这篇博文！如果你对更多内容感兴趣，想提供反馈或寻求帮助，请随时通过 [Slack (#crio)][slack] 或 [SIG Node 邮件列表][mail]直接联系我。 [slack]: https://kubernetes.slack.com/messages/crio [mail]: https://groups.google.com/forum/#!forum/kubernetes-sig-node </ins>

I will localize the blog: . To avoid any conflict, this issue is opened. /language zh /assign
/triage accepted


Question: kubectl version --client --output=yaml ``` <del> 1. After installing the plugin, clean up the installation files: </del> <ins> 1. After installing and validating kubectl, delete the checksum file: </ins> ```bash <del> rm kubectl kubectl.sha256 </del> <ins> rm kubectl.sha256 </ins> ``` ### Install with Homebrew on macOS

In Step 6 of , The command says to delete kubectl along with kubectl.sha256 file, but kubectl is already moved in step 4. The command needs to be rm kubectl.sha256 instead of rm kubectl kubectl.sha256
/language en
/retitle Incorrect cleanup instruction in macOS kubectl installation guide /kind bug
Indeed there appears to be discrepancy in the cleanup instruction as the removal command in Step 6 erroneously attempts to delete the already-moved kubectl binary as part of Step 4. We should address this inconsistency. /triage accepted /priority backlog
I can help with this. Worked on this files before too. /assign
i submited PR pelase review when got time. Thanks!


Question: - `cosign` ([install guide](https://docs.sigstore.dev/cosign/installation/)) - `curl` (often provided by your operating system) <del> - `jq` ([download jq](https://stedolan.github.io/jq/download/)) </del> <ins> - `jq` ([download jq](https://jqlang.github.io/jq/download/)) </ins> ## Verifying binary signatures

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 download page for is now (previously ) Proposed Solution: Throughout the English pages, replace the old download URL with the new one. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The download page for is now (previously ) Throughout the English pages, replace the old download URL with the new one. <!--Kubernetes Version:--/language en /priority backlog /triage accepted /help </details
I want to help with this. /assign
Hello I would like to work on this issue are you working on the issue?
I have riasd PR to help with this issue.


Question: --- title: Kubernetes 对象管理 <del> redirect_from: - "/docs/concepts/tools/kubectl/object-management-overview/" - "/docs/concepts/tools/kubectl/object-management-overview.html" - "/docs/user-guide/working-with-resources/" - "/docs/user-guide/working-with-resources.html" </del> --- {% capture overview %}

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This link: redirects to this page: The link is found here: Proposed Solution: Fix the redirect for /docs/user-guide/working-with-resources Page to Update: Redirect for
Yeah, it's confusing. Why it's P3? How hard to fix it? How I can help?
I know what the problem is and will submit a PR shortly. None of the pages in the /cn directory should have the directive at the top of the page. For example, currently, /cn/docs/tutorials/object-management-kubectl/object- has this set at the top of the page:
Wow! Thank you!!
Ok, nothing should be redirected to the /cn pages anymore. Cheers


Question: ## イメージの名称 コンテナイメージは、`pause`、`example/mycontainer`、または`kube-apiserver`のような名前が通常つけられます。 <del> イメージにはレジストリのホスト名も含めることができ（例：`fictional.registry.example/imagename`）、さらにポート番号も含めることが可能です（例：`fictional.registry.example:10443/imagename`）。 </del> <ins> イメージにはレジストリのホスト名も含めることができ(例：`fictional.registry.example/imagename`)、さらにポート番号も含めることが可能です(例：`fictional.registry.example:10443/imagename`)。 </ins> レジストリのホスト名を指定しない場合は、KubernetesはDockerパブリックレジストリを意味していると見なします。 <del> イメージ名の後に、_タグ_ を追加することができます（`docker`や`podman`のようなコマンドを利用した場合と同様）。 </del> <ins> イメージ名の後に、_タグ_ を追加することができます(`docker`や`podman`のようなコマンドを利用した場合と同様)。 </ins> タグによって同じイメージの異なるバージョンを識別できます。 イメージタグは大文字と小文字、数値、アンダースコア(`_`)、ピリオド(`.`)とマイナス(`-`)で構成されます。 イメージタグでは区切り記号(`_`、`-`、`.`)を指定できる追加ルールがあります。 タグを指定しない場合は、Kubernetesは`latest`タグを指定したと見なします。 <del> {{< caution >}} 本番環境でコンテナをデプロイする場合は、`latest`タグの使用を避けるべきです。 実行中のイメージのバージョンを追跡するのが難しく、機能しているバージョンへのロールバックがより困難になるためです。 </del> <ins> ## イメージの更新 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}、Pod、またはPodテンプレートを含むその他のオブジェクトを最初に作成するとき、デフォルトでは、Pod内のすべてのコンテナのPullポリシーは、明示的に指定されていない場合、`IfNotPresent`に設定されます。 イメージがすでに存在する場合、このポリシーは{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}にイメージのPullをスキップさせます。 ### イメージPullポリシー コンテナの`imagePullPolicy`とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が指定されたイメージをPull(ダウンロード)しようとする時に影響します。 以下は、`imagePullPolicy`に設定できる値とその効果の一覧です。 `IfNotPresent` : イメージがローカルにまだ存在しない場合のみ、イメージがPullされます。 `Always` : kubeletがコンテナを起動するときは常にコンテナイメージレジストリに照会して、イメージ名をイメージ[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)に解決します。 ローカルにキャッシュされた同一ダイジェストのコンテナイメージがあった場合、kubeletはキャッシュされたイメージを使用します。 そうでない場合、kubeletは解決されたダイジェストのイメージをPullし、そのイメージを使ってコンテナを起動します。 `Never` : kubeletは、イメージを取得しようとしません。ローカルにイメージがすでに存在する場合、kubeletはコンテナを起動しようとします。それ以外の場合、起動に失敗します。 詳細は、[事前にPullしたイメージ](#pre-pulled-images)を参照してください。 レジストリに確実にアクセスできるのであれば、基盤となるイメージプロバイダーのキャッシュセマンティクスにより`imagePullPolicy: Always`でも効率的です。 コンテナランタイムは、イメージレイヤーが既にノード上に存在することを認識できるので、再度ダウンロードする必要がありません。 {{< note >}} 本番環境でコンテナをデプロイする場合は、`:latest`タグの使用を避けるべきです。 実行中のイメージのバージョンを追跡するのが難しく、正しくロールバックすることがより困難になるためです。 </ins> かわりに、`v1.42.0`のような特定できるタグを指定してください。 <del> {{< /caution >}} </del> <ins> {{< /note >}} Podがいつも同じバージョンのコンテナイメージを使用するために、イメージのダイジェストを指定することができます。`<image-name>:<tag>`を`<image-name>@<digest>`に置き換えてください(例えば、`image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。 </ins> <del> ## イメージの更新 </del> <ins> イメージタグを使用する場合、イメージレジストリがそのイメージのタグが表すコードを変更すると、新旧のコードを実行するPodが混在することになるかもしれません。 イメージダイジェストは特定のバージョンのイメージを一意に識別するため、Kubernetesは特定のイメージ名とダイジェストが指定されたコンテナを起動するたびに同じコードを実行します。 イメージをダイジェストで指定することは、レジストリの変更でそのようなバージョンの混在を起こさないように、実行するコードを固定します。 Pod(およびPodテンプレート)を作成する時に、実行中のワークロードがタグではなくイメージダイジェストに基づき定義されるように変化させるサードパーティーの[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)があります。 レジストリでどのようなタグの変更があっても、すべてのワークロードが必ず同じコードを実行するようにしたい場合に役立ちます。 </ins> <del> デフォルトのpull policyでは、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}はイメージを既に取得済みの場合、イメージのPullをスキップさせる`IfNotPresent`が設定されています。 常にPullを強制させたい場合は、次のいずれかの方法で実行できます。 </del> <ins> #### デフォルトのイメージPullポリシー {#imagepullpolicy-defaulting} </ins> <del> - コンテナの`imagePullPolicy`に`Always`を設定する - `imagePullPolicy`を省略し、使用するイメージに`:latest`タグを使用する - `imagePullPolicy`と使用するイメージのタグを省略する - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にする </del> <ins> 新しいPodがAPIサーバに送信されると、クラスターは特定の条件が満たされたときに`imagePullPolicy`フィールドを設定します。 </ins> <del> `imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。 </del> <ins> - `imagePullPolicy`フィールドを省略し、コンテナイメージのタグに`:latest`を指定した場合、`imagePullPolicy`には自動的に`Always`が設定される - `imagePullPolicy`フィールドを省略し、コンテナイメージのタグを指定しなかった場合、`imagePullPolicy`には自動的に`Always`が設定される - `imagePullPolicy`フィールドを省略し、コンテナイメージのタグに`:latest`以外を指定した場合、`imagePullPolicy`には自動的に`IfNotPresent`が設定される {{< note >}} コンテナの`imagePullPolicy`の値は、そのオブジェクトが最初に _作成_ されたときに常に設定され、イメージのタグが後で変更された場合でも更新されません。 例えば、タグが`:latest` _でない_ イメージを使ってDeploymentを生成した場合、後でDeploymentのイメージを`:latest`タグに変更しても、`imagePullPolicy`は`Always`に更新されません。オブジェクトのPullポリシーは、初期作成後に手動で変更する必要があります。 {{< /note >}} #### 必要なイメージをPullする 常に強制的にPullしたい場合は、以下のいずれかを行ってください。 - コンテナの`imagePullPolicy`に`Always`を設定する。 - `imagePullPolicy`を省略し、使用するイメージに`:latest`タグ使用する。Pod生成時に、Kubernetesがポリシーに`Always`を設定する。 - `imagePullPolicy`と使用するイメージのタグを省略する。Pod生成時に、Kubernetesがポリシーに`Always`を設定する。 - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にする。 ### ImagePullBackOff kubeletがコンテナランタイムを使ってPodのコンテナの生成を開始するとき、`ImagePullBackOff`のためにコンテナが[Waiting](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting)状態になる可能性があります。 `ImagePullBackOff`ステータスは、KubernetesがコンテナイメージをPullできないために、コンテナを開始できないことを意味します(イメージ名が無効である、`imagePullSecret`なしでプライベートレジストリからPullしたなどの理由のため)。`BackOff`は、バックオフの遅延を増加させながらKubernetesがイメージをPullしようとし続けることを示します。 Kubernetesは、組み込まれた制限である300秒(5分)に達するまで、試行するごとに遅延を増加させます。 </ins> ## イメージインデックスを使ったマルチアーキテクチャイメージ

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


Question: ### Cron schedule syntax ``` <del> # ┌───────────── minute (0 - 59) # │ ┌───────────── hour (0 - 23) # │ │ ┌───────────── day of the month (1 - 31) # │ │ │ ┌───────────── month (1 - 12) # │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday; # │ │ │ │ │                                   7 is also Sunday on some systems) # │ │ │ │ │ # │ │ │ │ │ # * * * * * </del> <ins> #      ┌────────────────── timezone (optional) #      |      ┌───────────── minute (0 - 59) #      |      │ ┌───────────── hour (0 - 23) #      |      │ │ ┌───────────── day of the month (1 - 31) #      |      │ │ │ ┌───────────── month (1 - 12) #      |      │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday; #      |      │ │ │ │ │                                   7 is also Sunday on some systems) #      |      │ │ │ │ │ #      |      │ │ │ │ │ # CRON_TZ=UTC * * * * * </ins> ```

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: PR highlights that the documentation for CronJob is out of date since the v1.22 release. We're now using the revised controller by default (with no option to revert) and also a different syntax for the schedule. Proposed Solution: Identify stale or incorrect data on the pages about CronJobs Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v.122 Additional Information: /kind bug /sig apps Relevant to
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <ins> --- layout: blog title: "Security Profiles Operator v0.4.0 中的新功能" date: 2021-12-17 slug: security-profiles-operator --- <!-- layout: blog title: "What's new in Security Profiles Operator v0.4.0" date: 2021-12-17 slug: security-profiles-operator --> <!-- **Authors:** Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert --> **作者:** Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert --- <!-- The [Security Profiles Operator (SPO)](https://sigs.k8s.io/security-profiles-operator) is an out-of-tree Kubernetes enhancement to make the management of [seccomp](https://en.wikipedia.org/wiki/Seccomp), [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) and [AppArmor](https://en.wikipedia.org/wiki/AppArmor) profiles easier and more convenient. We're happy to announce that we recently [released v0.4.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.4.0) of the operator, which contains a ton of new features, fixes and usability improvements. --> [Security Profiles Operator (SPO)](https://sigs.k8s.io/security-profiles-operator) 是一种树外 Kubernetes 增强功能，用于更方便、更便捷地管理 [seccomp](https://en.wikipedia.org/wiki/Seccomp)、 [SELinux](https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E5%A2%9E%E5%BC%BA%E5%BC%8FLinux) 和 [AppArmor](https://zh.wikipedia.org/wiki/AppArmor) 配置文件。 我们很高兴地宣布，我们最近[发布了 v0.4.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.4.0) 的 Operator，其中包含了大量的新功能、缺陷修复和可用性改进。 <!-- ## What's new It has been a while since the last [v0.3.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.3.0) release of the operator. We added new features, fine-tuned existing ones and reworked our documentation in 290 commits over the past half year. --> ## 有哪些新特性 距离上次的 [v0.3.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.3.0) 的发布已经有一段时间了。在过去的半年里，我们增加了新的功能，对现有的功能进行了微调， 并且在过去的半年里，我们通过 290 个提交重新编写了文档。 <!-- One of the highlights is that we're now able to record seccomp and SELinux profiles using the operators [log enricher](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#log-enricher-based-recording). This allows us to reduce the dependencies required for profile recording to have [auditd](https://linux.die.net/man/8/auditd) or [syslog](https://en.wikipedia.org/wiki/Syslog) (as fallback) running on the nodes. All profile recordings in the operator work in the same way by using the `ProfileRecording` CRD as well as their corresponding [label selectors](/docs/concepts/overview/working-with-objects/labels). The log enricher itself can be also used to gather meaningful insights about seccomp and SELinux messages of a node. Checkout the [official documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-the-log-enricher) to learn more about it. --> 亮点之一是我们现在能够使用 Operator 的[日志增强组件](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#log-enricher-based-recording) 记录 seccomp 和 SELinux 的配置文件。 这使我们能够减少配置文件记录所需的依赖事项，使得仅剩的依赖变为在节点上运行 [auditd](https://linux.die.net/man/8/auditd) 或 [syslog](https://en.wikipedia.org/wiki/Syslog)（作为一种回退机制）。 通过使用 `ProfileRecording` CRD 及其对应的[标签选择算符](/zh-cn/concepts/overview/working-with-objects/labels)， Operator 中的所有配置文件记录都以相同的方式工作。 日志增强组件本身也可用于获得有关节点上的 seccomp 和 SELinux 消息的有意义的洞察。 查看[官方文档](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-the-log-enricher) 了解更多信息。 <!-- ### seccomp related improvements Beside the log enricher based recording we now offer an alternative to record seccomp profiles by utilizing [ebpf](https://ebpf.io). This optional feature can be enabled by setting `enableBpfRecorder` to `true`. This results in running a dedicated container, which ships a custom bpf module on every node to collect the syscalls for containers. It even supports older Kernel versions which do not expose the [BPF Type Format (BTF)](https://www.kernel.org/doc/html/latest/bpf/btf.html) per default as well as the `amd64` and `arm64` architectures. Checkout [our documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#ebpf-based-recording) to see it in action. By the way, we now add the seccomp profile architecture of the recorder host to the recorded profile as well. --> ### 与 seccomp 有关的改进 除了基于日志丰富器的记录之外，我们现在还使用 [ebpf](https://ebpf.io) 作为记录 seccomp 配置文件的一种替代方法。可以通过将 `enableBpfRecorder` 设置为 `true` 来启用此可选功能。 启用之后会导致一个专用的容器被启动运行；该容器在每个节点上提供一个自定义 bpf 模块以收集容器的系统调用。 它甚至支持默认不公开 [BPF 类型格式 (BTF)](https://www.kernel.org/doc/html/latest/bpf/btf.html) 的旧内核版本以及 `amd64 ` 和 `arm64` 架构。查看 [我们的文档](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#ebpf-based-recording) 以查看它的实际效果。顺便说一句，我们现在也将记录器主机的 seccomp 配置文件体系结构添加到记录的配置文件中。 <!-- We also graduated the seccomp profile API from `v1alpha1` to `v1beta1`. This aligns with our overall goal to stabilize the CRD APIs over time. The only thing which has changed is that the seccomp profile type `Architectures` now points to `[]Arch` instead of `[]*Arch`. --> 我们还将 seccomp 配置文件 API 从 `v1alpha1` 升级到 `v1beta1`。 这符合我们随着时间的推移稳定 CRD API 的总体目标。 唯一改变的是 seccomp 配置文件类型 `Architectures` 现在指向 `[]Arch` 而不是 `[]*Arch`。 <!-- ### SELinux enhancements Managing SELinux policies (an equivalent to using `semodule` that you would normally call on a single server) is not done by SPO itself, but by another container called selinuxd to provide better isolation. This release switched to using selinuxd containers from a personal repository to images located under [our team's quay.io repository](https://quay.io/organization/security-profiles-operator). The selinuxd repository has moved as well to [the containers GitHub organization](https://github.com/containers/selinuxd). --> ### SELinux 增强功能 管理 SELinux 策略（相当于使用通常在单个服务器上调用的 `semodule` ）不是由 SPO 本身完成的， 而是由另一个名为 selinuxd 的容器完成，以提供更好的隔离。此版本将所使用的 selinuxd 容器镜像从个人仓库迁移到位于[我们团队的 quay.io 仓库](https://quay.io/organization/security-profiles-operator)下的镜像。 selinuxd 仓库也已移至[GitHub 组织 containers](https://github.com/containers/selinuxd)。 <!-- Please note that selinuxd links dynamically to `libsemanage` and mounts the SELinux directories from the nodes, which means that the selinuxd container must be running the same distribution as the cluster nodes. SPO defaults to using CentOS-8 based containers, but we also build Fedora based ones. If you are using another distribution and would like us to add support for it, please file [an issue against selinuxd](https://github.com/containers/selinuxd/issues). --> 请注意，selinuxd 动态链接到 libsemanage 并挂载节点上的 SELinux 目录， 这意味着 selinuxd 容器必须与集群节点运行相同的发行版。SPO 默认使用基于 CentOS-8 的容器， 但我们也构建基于 Fedora 的容器。如果你使用其他发行版并希望我们添加对它的支持， 请[针对 selinuxd 提交 issue](https://github.com/containers/selinuxd/issues)。 <!-- #### Profile Recording This release adds support for recording of SELinux profiles. The recording itself is managed via an instance of a `ProfileRecording` Custom Resource as seen in an [example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/profilerecording-selinux-logs.yaml) in our repository. From the user's point of view it works pretty much the same as recording of seccomp profiles. --> #### 配置文件记录 此版本（0.4.0）增加了记录 SELinux 配置文件的支持。记录本身是通过 `ProfileRecording` 自定义资源的实例管理的， 如我们仓库中的[示例](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/profilerecording-selinux-logs.yaml) 所示。从用户的角度来看，它的工作原理与记录 seccomp 配置文件几乎相同。 <!-- Under the hood, to know what the workload is doing SPO installs a special permissive policy called [selinuxrecording](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/profiles/selinuxrecording.cil) on startup which allows everything and logs all AVCs to `audit.log`. These AVC messages are scraped by the log enricher component and when the recorded workload exits, the policy is created. --> 在后台，为了知道工作负载在做什么，SPO 安装了一个名为 [selinuxrecording](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/profiles/selinuxrecording.cil) 的、限制宽松的策略，允许执行所有操作并将所有 AVC 记录到 `audit.log` 中。 这些 AVC 消息由日志增强组件抓取，当所记录的工作负载退出时，该策略被创建。 <!-- #### `SELinuxProfile` CRD graduation An `v1alpha2` version of the `SelinuxProfile` object has been introduced. This removes the raw Common Intermediate Language (CIL) from the object itself and instead adds a simple policy language to ease the writing and parsing experience. --> #### `SELinuxProfile` CRD 毕业 我们引入了 `SelinuxProfile` 对象的 `v1alpha2` 版本。 这个版本从对象中删除了原始的通用中间语言 (CIL)，并添加了一种简单的策略语言来简化编写和解析体验。 <!-- Alongside, a `RawSelinuxProfile` object was also introduced. This contains a wrapped and raw representation of the policy. This was intended for folks to be able to take their existing policies into use as soon as possible. However, on validations are done here. --> 此外，我们还引入了 `RawSelinuxProfile` 对象。该对象包含策略的包装和原始表示。 引入此对象是为了让人们能够尽快将他们现有的策略付诸实现。但是，策略的验证是在这里完成的。 <!-- ### AppArmor support This version introduces the initial support for AppArmor, allowing users to load and unload AppArmor profiles into cluster nodes by using the new [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/crds/apparmorprofile.yaml) CRD. --> ### AppArmor 支持 0.4.0 版本引入了对 AppArmor 的初始支持，允许用户通过使用新的 [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/crds/apparmorprofile.yaml) 在集群节点中 CRD 加载或卸载 AppArmor 配置文件。 <!-- To enable AppArmor support use the [enableAppArmor feature gate](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/config.yaml#L10) switch of your SPO configuration. Then use our [apparmor example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/apparmorprofile.yaml) to deploy your first profile across your cluster. --> 要启用 AppArmor 支持，请使用 SPO 配置的 [enableAppArmor 特性门控](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/config.yaml#L10)开关。 然后使用我们的 [apparmor 示例](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/apparmorprofile.yaml) 在集群中部署你第一个配置文件。 <!-- ### Metrics The operator now exposes metrics, which are described in detail in our new [metrics documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-metrics). We decided to secure the metrics retrieval process by using [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy), while we ship an additional `spo-metrics-client` cluster role (and binding) to retrieve the metrics from within the cluster. If you're using [OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift), then we provide an out of the box working [`ServiceMonitor`](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#automatic-servicemonitor-deployment) to access the metrics. --> ### 指标 Operator 现在能够公开在我们的新[指标文档](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-metrics)中详细描述的指标。 我们决定使用 [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy) 来保护指标检索过程， 同时我们提供了一个额外的 `spo-metrics-client` 集群角色（和绑定）以从集群内检索指标。 如果你使用 [OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift)， 那么我们提供了一个开箱即用的 [`ServiceMonitor`](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#automatic-servicemonitor-deployment) 来访问指标。 <!-- #### Debuggability and robustness Beside all those new features, we decided to restructure parts of the Security Profiles Operator internally to make it better to debug and more robust. For example, we now maintain an internal [gRPC](https://grpc.io) API to communicate within the operator across different features. We also improved the performance of the log enricher, which now caches results for faster retrieval of the log data. The operator can be put into a more [verbose log mode](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#set-logging-verbosity) by setting `verbosity` from `0` to `1`. --> #### 可调试性和稳健性 除了所有这些新功能外，我们还决定在内部重组安全配置文件操作程序的部分内容，使其更易于调试和更稳健。 例如，我们现在维护了一个内部 [gRPC](https://grpc.io) API，以便在 Operator 内部跨不同功能组件进行通信。 我们还提高了日志增强组件的性能，现在它可以缓存结果，以便更快地检索日志数据。 Operator 可以通过将 `verbosity` 设置从 `0` 改为 `1`，启用更详细的日志模式(https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#set-logging-verbosity)。 <!-- We also print the used `libseccomp` and `libbpf` versions on startup, as well as expose CPU and memory profiling endpoints for each container via the [`enableProfiling` option](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#enable-cpu-and-memory-profiling). Dedicated liveness and startup probes inside of the operator daemon will now additionally improve the life cycle of the operator. --> 我们还在启动时打印所使用的 `libseccomp` 和 `libbpf` 版本， 并通过 [`enableProfiling` 选项](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#enable-cpu-and-memory-profiling) 公开每个容器的 CPU 和内存性能分析端点。 Operator 守护程序内部的专用的存活态探测和启动探测现在能进一步改善 Operator 的生命周期管理。 <!-- ## Conclusion Thank you for reading this update. We're looking forward to future enhancements of the operator and would love to get your feedback about the latest release. Feel free to reach out to us via the Kubernetes slack [#security-profiles-operator](https://kubernetes.slack.com/messages/security-profiles-operator) for any feedback or question. --> ## 总结 感谢你阅读这次更新。我们期待着 Operater 的未来改进，并希望得到你对最新版本的反馈。 欢迎通过 Kubernetes slack [#security-profiles-operator](https://kubernetes.slack.com/messages/security-profiles-operator) 与我们联系，提出任何反馈或问题。 </ins>

This is a Feature Report Problem: misssing Chinese translation docs: content/en/blog/_posts/2021-12-17-security-profiles-operator- URL Proposed Solution: add Chinese translation docs in website Kubernetes Blog Comments /language zh /assign
URL is :
/triage accepted


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

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


Question: A partir de Kubernetes 1.8, el servidor de métricas se despliega por defecto como un objeto de tipo [Deployment](https://github.com/docs/concepts/workloads/controllers/deployment/) en clústeres creados con el script `kube-up.sh`. Si usas otro mecanismo de configuración de Kubernetes, puedes desplegarlo <del> usando los [yamls de despliegue](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy) </del> <ins> usando los [yamls de despliegue](https://github.com/kubernetes-sigs/metrics-server/releases) </ins> proporcionados. Está soportado a partir de Kubernetes 1.7 (más detalles al final). El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet](/docs/admin/kubelet/) en cada nodo.

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


Question: ## 使用例 <del> 一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。 </del> <ins> RuntimeClassがクラスターに対して設定されると、PodSpecで`runtimeClassName`を指定して使用できます。 </ins> 例えば ```yaml

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/containers/runtime- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/containers/runtime- is outdated. Comments /language ja /assign
/triage accepted


Question: ### 추가 컨트롤 플레인 노드 업그레이드 <del> 1.  첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다. </del> <ins> 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다. </ins> <del> ``` sudo kubeadm upgrade node ``` </del> <ins> ``` sudo kubeadm upgrade node ``` </ins> <del> 아래 명령 대신 위의 명령을 사용한다. </del> <ins> 아래 명령 대신 위의 명령을 사용한다. </ins> <del> ``` sudo kubeadm upgrade apply ``` </del> <ins> ``` sudo kubeadm upgrade apply ``` </ins> <del> 또한 `sudo kubeadm upgrade plan` 은 필요하지 않다. </del> <ins> 또한 `sudo kubeadm upgrade plan` 은 필요하지 않다. </ins> ### kubelet과 kubectl 업그레이드 <del> 1.  모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. </del> <ins> 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. </ins> <del> {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </ins> # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubelet kubectl &&  apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 &&  apt-mark hold kubelet kubectl <ins> - </ins> # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update &&  apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </ins> # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> <del> 1.  kubelet을 다시 시작한다. </del> <ins> kubelet을 다시 시작한다. </ins> <del> ```shell sudo systemctl restart kubelet ``` </del> <ins> ```shell sudo systemctl restart kubelet ``` </ins> ## 워커 노드 업그레이드

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Broken layout on "kubeadm " ! Proposed Solution: Check and apply upstream changes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
/unassign This issue already has been assigned to .


Question: Notice how the number of desired replicas is 3 according to `.spec.replicas` field. <del> 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. </del> <ins> 3. To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. </ins> The output is similar to: ```

I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign


Question: type: LoadBalancer ``` <del> ## Using kubectl </del> <ins> ### Create a Service using kubectl </ins> You can alternatively create the service with the `kubectl expose` command and its `--type=LoadBalancer` flag: ```bash <del> kubectl expose rc example --port=8765 --target-port=9376  </del> <ins> kubectl expose deployment example --port=8765 --target-port=9376  </ins> --name=example-service --type=LoadBalancer ``` <del> This command creates a new service using the same selectors as the referenced resource (in the case of the example above, a replication controller named `example`). </del> <ins> This command creates a new Service using the same selectors as the referenced resource (in the case of the example above, a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} named `example`). </ins> For more information, including optional flags, refer to the [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: mentions: (see ) Weights aren't built in to Service / Endpoints / EndpointSlice / Ingress but you can indicate weighting with annotations and similar mechanisms. For example: https://kubernetes- Proposed Solution: Remove the text: Revise to explain that each implementation uses its own mechanisms for weighting and that these are not standardized. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.19 Additional Information: /language en /sig network
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten
Reopened this issue.

<detailsIn response to : /reopen /remove-lifecycle rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:


Question: persistent volume (virtual disk) is being created. The virtual disk is distributed across the Virtual SAN datastore to meet the requirements. <del> You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html) </del> <ins> You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/fa4c8b8ad46a85b6555d715dd9d27ff69839df53/documentation/policy-based-mgmt.md) </ins> for more details on how to use storage policies for persistent volumes management.

Problem: The text on is not working, it should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text Storage Policy Based Management for dynamic provisioning of volumes to 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, it should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text Storage Policy Based Management for dynamic provisioning of volumes to 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


Question: * You need to be able to exec into pods * Feature gate `UserNamespacesStatelessPodsSupport` need to be enabled. <del> In addition, support is needed in the {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} to use this feature with Kubernetes stateless pods: </del> <ins> The cluster that you're using **must** include at least one node that meets the [requirements](/docs/concepts/workloads/pods/user-namespaces/#before-you-begin) for using user namespaces with Pods. </ins> <del> * CRI-O: v1.25 has support for user namespaces. </del> <ins> If you have a mixture of nodes and only some of the nodes provide user namespace support for Pods, you also need to ensure that the user namespace Pods are [scheduled](/docs/concepts/scheduling-eviction/assign-pod-node/) to suitable nodes. </ins> Please note that **if your container runtime doesn't support user namespaces, the new `pod.spec` field will be silently ignored and the pod will be created without

CONDITION was running with UserNamespacesStatelessPodsSupport=true -apiserver was running with UserNamespacesStatelessPodsSupport=true busybox-user configured hostUsers: false deployed successfully: file created: containerd log, no UserNameSpace Option in spec.Spec struct (I modified the log to highlight NamespaceOptions part): SYMPTOM No Pod user namespace created:container was running as root:no id mapping set in uid_map: Pod user namespace created with command was running as non-root user feature gate for kubelet and apiserver Pod configuration and apply it user namespace with I have tested directly with and to confirm runc support user namespace. Here is part of feature output, so I think containerd and runc part is OK: It seems kubelet did not provide the correct user namespace options in request of RunPodSandbox. <details</details<detailsno </details<details</details<details</details<details</details<detailsNot relavent </details
/sig node
can you please attach the for this. First, it will confirm that kubelet picked up the configuration and second it may have some failures that can give a clue what is happening /cc /triage needs-information
any chance you can try the same set up on an OS with newer kernel version? Just to confirm if this is OS specific or not
Am I reading the report correctly and you are using containerd 1.6? I mean, it says wrongly formatted this: In that case, this is completely expected. It is documented here too, see the end of this section in bold letter: https://v1- What this means is: support for userns was in containerd 1.7. Older versions of containerd, for backwards compatibility, just ignore the request of userns from the kubelet.
Also, in the original report, you pasted twice the api-server in the output of :)
if confirms this is running containerd 1.6, I think we can close this :)
1.7 supports it, correct?

Can you send an update for https://v1-
/remove-kind bug /kind documentation /triage accepted /retitle "document that containerd 1.6 does not support userns feature (KEP 127)"
/triage accepted
/retitle "document that containerd 1.7 is needed to use the userns feature (KEP 127)"
In which case, I think the place to explain that is /remove-triage needs-information
/transfer website
/language en /sig docs
thanks, done! Please note, though, that the link I pasted (https://v1-) mentions also that support is needed from the container runtime (if you don't have support what was reported here happens) and the only runtime supported is CRIO. I think maybe that was not so clear, and now containerd 1.7 was released a few days ago, so I opened a PR to mention containerd 1.7 and hopefully clarify the runtime support
Thank you for kind reply. containerd version is 1.6.8 in my env. I'll try to update it to 1.7.0 and deploy the rootless pod again. Besides, I have already tried to debug run the kubelet from src with dlv and confirmed that the API request contained userns options(idmapping). So the problem likely exists on containerd side.
Additionally, the information provided by kubelet's log is so limited. That makes me hard to locate the problem.
Here is the update after I upgrade containerd 1.6.8 -1.7.0 After I deploy the rootless pod: userns created: is running as the rootless user: mapping is correct: Thank you for the great help!
And what about OCI runtime version (eg. runc)? I think it is helpful to clarify its version requisition.
cool, great that it is working now! Regarding the OCI runtime, each containerd version mandates that at least runc version X should be used, so we should be safe with that. I think distros honor it too, but if you know some example where it is not honored, let us know!


Question: padding-bottom: 5rem; } <del> section.call-to-action .main-section > div.call-to-action > div { order: 1; </del> <ins> body.cid-training section.call-to-action .main-section > div.call-to-action > div { </ins> padding: 20px; } <del> section.call-to-action .main-section .cta-text { text-align: center; flex: 1 1 auto; max-width: 50vw; </del> <ins> body.cid-training section.call-to-action .main-section .cta-text { width: 100%; flex-basis: 100%; </ins> } <del> /* if max() and min() are available, use them */ section.call-to-action .main-section .cta-text { </del> <ins> body.cid-training section.call-to-action .main-section .cta-text > * { margin-left: auto; margin-right: auto; text-align: center; /* if max() and min() are available, use them */ </ins> min-width: min(20em, 50vw); max-width: min(1000px, 50vw); } <del> section.call-to-action .main-section .cta-image.cta-image-before { order: 0 } section.call-to-action .main-section .cta-image.cta-image-after { order: 2 </del> <ins> body.cid-training section.call-to-action .main-section .cta-image { max-width: max(20vw,150px); flex-basis: auto; </ins> } <del> section.call-to-action .main-section .cta-image > img { </del> <ins> body.cid-training section.call-to-action .main-section .cta-image > img { </ins> display: block; width: 150px; margin: auto; } <del> .col { </del> <ins> body.cid-training #logo-cks { order: 2; /* central */ } body.cid-training .col { </ins> display: flex; flex-direction: row; float: left; margin: 1% 0 1% 1.6%; } <del> .col:first-child { margin-left: 0; } </del> <ins> body.cid-training .col:first-child { margin-left: 0; } </ins> <del> .col-container { </del> <ins> body.cid-training .col-container { </ins> display: flex; /* Make the container element behave like a table */ flex-direction: row; width: 100%; /* Set full-width to expand the whole page */ padding-bottom: 30px; } <del> .col-nav { </del> <ins> body.cid-training .col-nav { </ins> display: flex; flex-grow: 1; width: 18%;

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


Question: --- title: "ツールのインストール" <del> description: Kubernetesのツールをローカルのコンピュータ上にセットアップします。 </del> <ins> description: Kubernetesのツールをローカルのコンピューター上にセットアップします。 </ins> weight: 10 no_list: true ---

This is a Feature Request What would you like to be fix the notation variations of the term "computer" valid: invalid: | Why is this needed In Japanese documents, There are notation variations. The Japanese localization of k/website has rules, so we want to follow them. Comments FYI: Japanese Localization document: command /language ja /area localization /help /good-first-issue
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
PTAL before woking
PR
/remove-help


Question: <ins> --- title: huge pageを管理する content_type: task description: クラスター内のスケジュール可能なリソースとしてhuge pageの設定と管理を行います。 --- <!-- overview --> {{< feature-state state="stable" >}} Kubernetesでは、事前割り当てされたhuge pageをPod内のアプリケーションに割り当てたり利用したりすることをサポートしています。このページでは、ユーザーがhuge pageを利用できるようにする方法について説明します。 ## {{% heading "prerequisites" %}} 1. Kubernetesのノードがhuge pageのキャパシティを報告するためには、ノード上でhuge pageを事前割り当てしておく必要があります。1つのノードでは複数のサイズのhuge pageが事前割り当てできます。 ノードは、すべてのhuge pageリソースを、スケジュール可能なリソースとして自動的に探索・報告してくれます。 <!-- steps --> ## API huge pageはコンテナレベルのリソース要求で`hugepages-<size>`という名前のリソースを指定することで利用できます。ここで、`<size>`は、特定のノード上でサポートされている整数値を使った最も小さなバイナリ表記です。たとえば、ノードが2048KiBと1048576KiBのページサイズをサポートしている場合、ノードはスケジュール可能なリソースとして、`hugepages-2Mi`と`hugepages-1Gi`の2つのリソースを公開します。CPUやメモリとは違い、huge pageはオーバーコミットをサポートしません。huge pageリソースをリクエストするときには、メモリやCPUリソースを同時にリクエストしなければならないことに注意してください。 1つのPodのspec内に書くことで、Podから複数のサイズのhuge pageを利用することもできます。その場合、すべてのボリュームマウントで`medium: HugePages-<hugepagesize>`という表記を使う必要があります。 ```yaml apiVersion: v1 kind: Pod metadata: name: huge-pages-example spec: containers: - name: example image: fedora:latest command: - sleep - inf volumeMounts: - mountPath: /hugepages-2Mi name: hugepage-2mi - mountPath: /hugepages-1Gi name: hugepage-1gi resources: limits: hugepages-2Mi: 100Mi hugepages-1Gi: 2Gi memory: 100Mi requests: memory: 100Mi volumes: - name: hugepage-2mi emptyDir: medium: HugePages-2Mi - name: hugepage-1gi emptyDir: medium: HugePages-1Gi ``` Podで1種類のサイズのhuge pageをリクエストするときだけは、`medium: HugePages`という表記を使うこともできます。 ```yaml apiVersion: v1 kind: Pod metadata: name: huge-pages-example spec: containers: - name: example image: fedora:latest command: - sleep - inf volumeMounts: - mountPath: /hugepages name: hugepage resources: limits: hugepages-2Mi: 100Mi memory: 100Mi requests: memory: 100Mi volumes: - name: hugepage emptyDir: medium: HugePages ``` - huge pageのrequestsはlimitsと等しくなければなりません。limitsを指定した場合にはこれがデフォルトですが、requestsを指定しなかった場合にはデフォルトではありません。 - huge pageはコンテナのスコープで隔離されるため、各コンテナにはそれぞれのcgroupサンドボックスの中でcontainer specでリクエストされた通りのlimitが設定されます。 - huge pageベースのEmptyDirボリュームは、Podがリクエストしたよりも大きなサイズのページメモリーを使用できません。 - `shmget()`に`SHM_HUGETLB`を指定して取得したhuge pageを使用するアプリケーションは、`/proc/sys/vm/hugetlb_shm_group`に一致する補助グループ(supplemental group)を使用して実行する必要があります。 - namespace内のhuge pageの使用量は、ResourceQuotaに対して`cpu`や`memory`のような他の計算リソースと同じように`hugepages-<size>`というトークンを使用することで制御できます。 - 複数のサイズのhuge pageのサポートはフィーチャーゲートによる設定が必要です。{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}上で、`HugePageStorageMediumSize`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を使用すると有効にできます(`--feature-gates=HugePageStorageMediumSize=true`)。 </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
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details