Question:
 --- api_metadata: apiVersion: "apiregistration.k8s.io/v1" import: "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1" kind: "APIService" content_type: "api_reference" description: "APIService 是用来表示一个特定的 GroupVersion 的服务器" title: "APIService" weight: 4 ---  `apiVersion: apiregistration.k8s.io/v1` `import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"` ## APIService {#APIService}  APIService 是用来表示一个特定的 GroupVersion 的服务器。名称必须为 "version.group"。
 - **apiVersion**: apiregistration.k8s.io/v1 - **kind**: APIService - **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta)  标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (<a href="{{< ref "../cluster-resources/api-service-v1#APIServiceSpec" >}}">APIServiceSpec)  spec 包含用于定位和与服务器通信的信息 - **status** (<a href="{{< ref "../cluster-resources/api-service-v1#APIServiceStatus" >}}">APIServiceStatus)  status 包含某 API 服务器的派生信息 ## APIServiceSpec {#APIServiceSpec}  APIServiceSpec 包含用于定位和与服务器通信的信息。仅支持 HTTPS 协议，但是你可以禁用证书验证。
 - **groupPriorityMinimum** (int32)， 必需  groupPriorityMininum 是这个组至少应该具有的优先级。优先级高表示客户端优先选择该组。 请注意，该组的其他版本可能会指定更高的 groupPriorityMininum 值，使得整个组获得更高的优先级。 主排序基于 groupPriorityMinimum 值，从高到低排序（20 在 10 之前）。 次要排序基于对象名称的字母顺序（v1.bar 在 v1.foo 之前）。 我们建议这样配置：`*.k8s.io`（扩展除外）值设置为 18000，PaaS（OpenShift、Deis）建议值为 2000 左右。 - **versionPriority** (int32)， 必需  versionPriority 控制该 API 版本在其组中的排序，必须大于零。主排序基于 versionPriority， 从高到低排序（20 在 10 之前）。因为在同一个组里，这个数字可以很小，可能是几十。 在版本优先级相等的情况下，版本字符串将被用来计算组内的顺序。如果版本字符串是与 Kubernetes 的版本号形式类似， 则它将排序在 Kubernetes 形式版本字符串之前。Kubernetes 的版本号字符串按字典顺序排列。 Kubernetes 版本号以 “v” 字符开头，后面是一个数字（主版本），然后是可选字符串 “alpha” 或 “beta” 和另一个数字（次要版本）。 它们首先按 GA > beta > alpha 排序（其中 GA 是没有 beta 或 alpha 等后缀的版本），然后比较主要版本， 最后是比较次要版本。版本排序列表示例：v10、v2、v1、v11beta2、v10beta3、v3beta1、v12alpha1、v11alpha2、foo1、foo10。 - **caBundle** ([]byte)  **原子性：将在合并期间被替换** caBundle 是一个 PEM 编码的 CA 包，用于验证 API 服务器的服务证书。如果未指定， 则使用 API 服务器上的系统根证书。 - **group** (string)  group 是此服务器主机的 API 组名称。 - **insecureSkipTLSVerify** (boolean)  insecureSkipTLSVerify 代表在与此服务器通信时禁用 TLS 证书验证。强烈建议不要这样做。你应该使用 caBundle。 - **service** (ServiceReference)  service 是对该 API 服务器的服务的引用。它只能在端口 443 上通信。如果 service 是 nil， 则意味着 API groupversion 的处理是在当前服务器上本地处理的。服务调用被直接委托给正常的处理程序链来完成。   **ServiceReference 保存对 Service.legacy.k8s.io 的一个引用。** - **service.name** (string)  name 是服务的名称 - **service.namespace** (string)  namespace 是服务的命名空间 - **service.port** (int32)  如果指定，则为托管 Webhook 的服务上的端口。为实现向后兼容，默认端口号为 443。 `port` 应该是一个有效的端口号（1-65535，包含）。 - **version** (string)  version 是此服务器的 API 版本。例如：“v1”。 ## APIServiceStatus {#APIServiceStatus}  APIServiceStatus 包含有关 API 服务器的派生信息
 - **conditions** ([]APIServiceCondition)  **补丁策略：基于键 `type` 合并** **Map：合并时将保留 type 键的唯一值** APIService 的当前服务状态。   **APIServiceCondition 描述 APIService 在特定点的状态** - **conditions.status** (string)， 必需  status 表示状况（Condition）的状态，取值为 True、False 或 Unknown 之一。 - **conditions.type** (string)， 必需  type 是状况的类型。 - **conditions.lastTransitionTime** (Time)  上一次发生状况状态转换的时间。   Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。 - **conditions.message** (string)  指示上次转换的详细可读信息。 - **conditions.reason** (string)  表述状况上次转换原因的、驼峰格式命名的、唯一的一个词。 ## APIServiceList {#APIServiceList}  APIServiceList 是 APIService 对象的列表。
 - **apiVersion**: apiregistration.k8s.io/v1 - **kind**: APIServiceList - **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta)  标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **items** ([]<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService)， 必需  items 是 APIService 的列表 ## Operations {#Operations}
  ### `get` 读取指定的 APIService #### HTTP 请求 GET /apis/apiregistration.k8s.io/v1/apiservices/{name}  #### 参数 - **name** （**路径参数**）：string，必需 APIService 名称 - **pretty** （**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 401: Unauthorized  ### `get` 读取指定 APIService 的状态 #### HTTP 请求 GET /apis/apiregistration.k8s.io/v1/apiservices/{name}/status  #### 参数 - **name** （**路径参数**）：string，必需 APIService 名称 - **pretty** （**查询参数**）：string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 401: Unauthorized  ### `list` 列出或观察 APIService 类的对象 #### HTTP 请求 GET /apis/apiregistration.k8s.io/v1/apiservices  #### 参数 - **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 - **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 "../cluster-resources/api-service-v1#APIServiceList" >}}">APIServiceList): OK 401: Unauthorized  ### `create` 创建一个 APIService #### HTTP 请求 POST /apis/apiregistration.k8s.io/v1/apiservices  #### 参数 - **body**：<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService， 必需 - **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 "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 201 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Created 202 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Accepted 401: Unauthorized  ### `update` 替换指定的 APIService #### HTTP 请求 PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}  #### 参数 - **name** （**路径参数**）：string， 必需  APIService 名称 - **body**：<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService， 必需 - **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 "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 201 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Created 401: Unauthorized  ### `update` 替换指定 APIService 的 status #### HTTP 请求 PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}/status  #### 参数 - **name**（**路径参数**）：string， 必需 APIService 名称 - **body**：<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService， 必需 - **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 "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 201 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Created 401: Unauthorized  ### `patch` 部分更新指定的 APIService #### HTTP 请求 PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}  #### 参数 - **name**（**路径参数**）：string， 必需 APIService 名称 - **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 "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 201 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Created 401: Unauthorized  ### `patch` 部分更新指定 APIService 的 status #### HTTP 请求 PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status  #### 参数 - **name**（**路径参数**）：string， 必需 APIService 名称 - **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 "../cluster-resources/api-service-v1#APIService" >}}">APIService): OK 201 (<a href="{{< ref "../cluster-resources/api-service-v1#APIService" >}}">APIService): Created 401: Unauthorized  ### `delete` 删除一个 APIService #### HTTP 请求 DELETE /apis/apiregistration.k8s.io/v1/apiservices/{name}  #### 参数 - **name**（**路径参数**）：string， 必需 APIService 名称 - **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` 删除 APIService 集合 #### HTTP 请求 DELETE /apis/apiregistration.k8s.io/v1/apiservices  #### 参数 - **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 - **timeoutSeconds** （**查询参数**）：integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 401: Unauthorized

Translate Chinese version for docs/reference/kubernetes-api/cluster-resources/api-service- Comments /language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted


Question: ClusterIP range is subdivided. Dynamic allocated ClusterIP addresses will be allocated preferently from the upper range allowing users to assign static ClusterIPs from the lower range with a low risk of collision. See <del> [Avoiding collisions](/docs/concepts/services-networking/service/#avoiding-collisions) </del> <ins> [Avoiding collisions](/docs/reference/networking/virtual-ips/#avoiding-collisions) </ins> for more details. - `SizeMemoryBackedVolumes`: Enable kubelets to determine the size limit for memory-backed volumes (mainly `emptyDir` volumes).

This is a Bug Report Problem: Links for Avoiding collisions are broken in: (at point) Proposed Solution: Update in both pages with Other possible solutions: Page to Update:
/language en /area blog
/retitle Broken links for "Avoiding collisions" in 'Service' and 'Feature Gates' page /remove-area blog
I think the link became broken during the revision process of the Service concept page. We should make an update to direct it to the correct location, which I believe is /priority backlog /triage accepted
/assign
/sig docs PR raised
Similar to


Question: --- title: Tutorial Interativo - Expondo seu aplicativo weight: 20 <ins> headless: true toc_hide: true _build: list: never publishResources: false </ins> --- <!DOCTYPE html>

The terminal to use the interactive tutorials is using Katacoda, however, it was purchased by O'Reilly and is outside the domain that the terminal is using to run.
Hi You can ask support queries in channels.
Page related to issue: /language pt
/retitle [pt-br] Remove the obsolete online interactive tutorial from the page
For anyone willing to assist on this, please refer to PR for information regarding the implementation of similar changes carried out on the main website (i.e. English pages).
/good-first-isssue
/triage accepted /assign
/retitle [pt-br] Obsolete online interactive tutorial in the Using Minikube to Create a Cluster page /kind bug


Question: <ins> --- title: "Cloud Native Security and Kubernetes" linkTitle: "Cloud Native Security" weight: 10 # The section index lists this explicitly hide_summary: true description: > Concepts for keeping your cloud-native workload secure. --- Kubernetes is based on a cloud-native architecture, and draws on advice from the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} about good practice for cloud native information security. Read on through this page for an overview of how Kubernetes is designed to help you deploy a secure cloud native platform. ## Cloud native information security {{< comment >}} There are localized versions available of this whitepaper; if you can link to one of those when localizing, that's even better. {{< /comment >}} The CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper) on cloud native security defines security controls and practices that are appropriate to different _lifecycle phases_. ## _Develop_ lifecycle phase {#lifecycle-phase-develop} - Ensure the integrity of development environments. - Design applications following good practice for information security, appropriate for your context. - Consider end user security as part of solution design. To achieve this, you can: 1. Adopt an architecture, such as [zero trust](https://glossary.cncf.io/zero-trust-architecture/), that minimizes attack surfaces, even for internal threats. 1. Define a code review process that considers security concerns. 1. Build a _threat model_ of your system or application that identifies trust boundaries. Use that to model to identify risks and to help find ways to treat those risks. 1. Incorporate advanced security automation, such as _fuzzing_ and [security chaos engineering](https://glossary.cncf.io/security-chaos-engineering/), where it's justified. ## _Distribute_ lifecycle phase {#lifecycle-phase-distribute} - Ensure the security of the supply chain for container images you execute. - Ensure the security of the supply chain for the cluster and other components that execute your application. An example of another component might be an external database that your cloud-native application uses for persistence. To achieve this, you can: 1. Scan container images and other artifacts for known vulnerabilities. 1. Ensure that software distribution uses encryption in transit, with a chain of trust for the software source. 1. Adopt and follow processes to update dependencies when updates are available, especially in response to security announcements. 1. Use validation mechanisms such as digital certificates for supply chain assurance. 1. Subscribe to feeds and other mechanisms to alert you to security risks. 1. Restrict access to artifacts. Place container images in a [private registry](/docs/concepts/containers/images/#using-a-private-registry) that only allows authorized clients to pull images. ## _Deploy_ lifecycle phase {#lifecycle-phase-deploy} Ensure appropriate restrictions on what can be deployed, who can deploy it, and where it can be deployed to. You can enforce measures from the _distribute_ phase, such as verifying the cryptographic identity of container image artifacts. When you deploy Kubernetes, you also set the foundation for your applications' runtime environment: a Kubernetes cluster (or multiple clusters). That IT infrastructure must provide the security guarantees that higher layers expect. ## _Runtime_ lifecycle phase {#lifecycle-phase-runtime} The Runtime phase comprises three critical areas: [compute](#protection-runtime-compute), [access](#protection-runtime-access), and [storage](#protection-runtime-storage). ### Runtime protection: access {#protection-runtime-access} The Kubernetes API is what makes your cluster work. Protecting this API is key to providing effective cluster security. Other pages in the Kubernetes documentation have more detail about how to set up specific aspects of access control. The [security checklist](/docs/concepts/security/security-checklist/) has a set of suggested basic checks for your cluster. Beyond that, securing your cluster means implementing effective [authentication](/docs/concepts/security/controlling-access/#authentication) and [authorization](/docs/concepts/security/controlling-access/#authorization) for API access. Use [ServiceAccounts](/docs/concepts/security/service-accounts/) to provide and manage security identities for workloads and cluster components. Kubernetes uses TLS to protect API traffic; make sure to deploy the cluster using TLS (including for traffic between nodes and the control plane), and protect the encryption keys. If you use Kubernetes' own API for [CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/#certificate-signing-requests), pay special attention to restricting misuse there. ### Runtime protection: compute {#protection-runtime-compute} {{< glossary_tooltip text="Containers" term_id="container" >}} provide two things: isolation between different applications, and a mechanism to combine those isolated applications to run on the same host computer. Those two aspects, isolation and aggregation, mean that runtime security involves trade-offs and finding an appropriate balance. Kubernetes relies on a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} to actually set up and run containers. The Kubernetes project does not recommend a specific container runtime and you should make sure that the runtime(s) that you choose meet your information security needs. To protect your compute at runtime, you can: 1. Enforce [Pod security standards](/docs/concepts/security/pod-security-standards/) for applications, to help ensure they run with only the necessary privileges. 1. Run a specialized operating system on your nodes that is designed specifically for running containerized workloads. This is typically based on a read-only operating system (_immutable image_) that provides only the services essential for running containers. Container-specific operating systems help to isolate system components and present a reduced attack surface in case of a container escape. 1. Define [ResourceQuotas](/docs/concepts/policy/resource-quotas/) to fairly allocate shared resources, and use mechanisms such as [LimitRanges](/docs/concepts/policy/limit-range/) to ensure that Pods specify their resource requirements. 1. Partition workloads across different nodes. Use [node isolation](/docs/concepts/scheduling-eviction/assign-pod-node/#node-isolation-restriction) mechanisms, either from Kubernetes itself or from the ecosystem, to ensure that Pods with different trust contexts are run on separate sets of nodes. 1. Use a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} that provides security restrictions. 1. On Linux nodes, use a Linux security module such as [AppArmor](/docs/tutorials/security/apparmor/) (beta) or [seccomp](/docs/tutorials/security/seccomp/). ### Runtime protection: storage {#protection-runtime-storage} To protect storage for your cluster and the applications that run there, you can: 1. Integrate your cluster with an external storage plugin that provides encryption at rest for volumes. 1. Enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for API objects. 1. Protect data durability using backups. Verify that you can restore these, whenever you need to. 1. Authenticate connections between cluster nodes and any network storage they rely upon. 1. Implement data encryption within your own application. For encryption keys, generating these within specialized hardware provides the best protection against disclosure risks. A _hardware security module_ can let you perform cryptographic operations without allowing the security key to be copied elsewhere. ### Networking and security You should also consider network security measures, such as [NetworkPolicy](/docs/concepts/services-networking/network-policies/) or a [service mesh](https://glossary.cncf.io/service-mesh/). Some network plugins for Kubernetes provide encryption for your cluster network, using technologies such as a virtual private network (VPN) overlay. By design, Kubernetes lets you use your own networking plugin for your cluster (if you use managed Kubernetes, the person or organization managing your cluster may have chosen a network plugin for you). The network plugin you choose and the way you integrate it can have a strong impact on the security of information in transit. ### Observability and runtime security Kubernetes lets you extend your cluster with extra tooling. You can set up third party solutions to help you monitor or troubleshoot your applications and the clusters they are running. You also get some basic observability features built in to Kubernetes itself. Your code running in containers can generate logs, publish metrics or provide other observability data; at deploy time, you need to make sure your cluster provides an appropriate level of protection there. If you set up a metrics dashboard or something similar, review the chain of components that populate data into that dashboard, as well as the dashboard itself. Make sure that the whole chain is designed with enough resilience and enough integrity protection that you can rely on it even during an incident where your cluster might be degraded. Where appropriate, deploy security measures below the level of Kubernetes itself, such as cryptographically measured boot, or authenticated distribution of time (which helps ensure the fidelity of logs and audit records). For a high assurance environment, deploy cryptographic protections to ensure that logs are both tamper-proof and confidential. ## {{% heading "whatsnext" %}} ### Cloud native security {#further-reading-cloud-native} * CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper) on cloud native security. * CNCF [white paper](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) on good practices for securing a software supply chain. * [Fixing the Kubernetes clusterf**k: Understanding security from the kernel up](https://archive.fosdem.org/2020/schedule/event/kubernetes/) (FOSDEM 2020) * [Kubernetes Security Best Practices](https://www.youtube.com/watch?v=wqsUfvRyYpw) (Kubernetes Forum Seoul 2019) * [Towards Measured Boot Out of the Box](https://www.youtube.com/watch?v=EzSkU3Oecuw) (Linux Security Summit 2016) ### Kubernetes and information security {#further-reading-k8s} * [Kubernetes security](/docs/concepts/security/) * [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/) * [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) * [Secrets in Kubernetes](/docs/concepts/configuration/secret/) * [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) * [Network policies](/docs/concepts/services-networking/network-policies/) for Pods * [Pod security standards](/docs/concepts/security/pod-security-standards/) * [RuntimeClasses](/docs/concepts/containers/runtime-class) </ins>

This is a Refactor request <!-- 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 overview page at is a bit out of date: no reference to I'm not convinced that the “Four Cs of cloud native security” model is useful for readers to learn Does not align with other CNCF documents, such as Proposed Solution: Either: remove outright migrate content from into several destinations (keep this brief but on-point) …and then redirect to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig docs /sig security /language en
If we keep the link to then we should update it to be as this is the English docs.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /triage accepted
Also see
/assign
I'd appreciate a (fresh) review on .


Question: readinessProbe: tcpSocket: port: 8080 <del> initialDelaySeconds: 5 </del> <ins> initialDelaySeconds: 15 </ins> periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 <del> periodSeconds: 20 </del> <ins> periodSeconds: 10 </ins>

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


Question: - kow3ns title: Safely Drain a Node content_type: task <del> min-kubernetes-server-version: 1.5 </del> weight: 310 ---

The PR improperly set the minim version to 1.5 when there is no such version. Public link: Markdown file: ! !
/assign
kubernetes 1.5 release end of life (1 October 2017) already passed so this page needs updation
/kind bug
I guess it is mentioned because in v1.5: As per release It totally depends upon the docs and /sig node what they want to mention. If it is mentioned because of the time this feature went beta this page might be right.
/retitle “Safely Drain a Node” states that you need Kubernetes 1.5 or later /language en That statement is correct and its inclusion does not, to me, feel misleading. /priority awaiting-more-evidence
Just to confirm the version indicates the complete functionality is not available until v1.5 is released? PDB is . Only confusing area is what functionality in the document is for 1.5 and what is available now?
Try this: The page does not say you need to wait for an upcoming release. I think you have misunderstood what is actually a clear statement We could drop the shortcode as we assume everyone is using Kubernetes 1.21 or later.
/triage accepted Drop the version-check would be desireable.
/priority important-longterm
For SIG Docs, this is only a backlog priority I think. We've other work that we'd want to prioritize. Help here is still very welcome!


Question: } ``` <ins> {{<note>}} The keys and the values in the map must be strings. In other words, you cannot use numeric, boolean, list or other types for either the keys or the values. {{</note>}} </ins> Here are some examples of information that could be recorded in annotations: * Fields managed by a declarative configuration layer. Attaching these fields

This is a Feature Request Currently only key validity is specified. There is no mention on that e.g. numeric, boolean, list or other types for annotation values are not permitted.
/triage accepted /sig architecture
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
/remove-lifecycle stale /assign


Question: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:

Description of Node Affinity example pod spec "pods/pod-with-node-" contains an error: does not apply. The spec shows instead that key "" should be "". Under the Node Affinity Weight section, the following note is also out-of-place: It needs to be moved to the previous section.
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
This issue is a duplicate of . /triage duplicate

Just above this anchor #node-affinity-per-scheduling-profile, the note block is referring to the Pod spec pod-with-node- 2 above, but it's placement appears to refer to the one immediately above. It takes a little bouncing around the page to sort it out :)
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

Only minor confusion, after the first example Pod spec, where "In this example, the following rules apply:" the bullet points that follow are misleading where first bullet refers to the example below, the second to the example above.
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

! The label with the key not exist in the example for node affinity:
/kind bug /language en /triage accepted Thanks for reporting this. I would fix this discrepancy by copying the example manifest to make a new example, that does use the key key. The Git history might show a previous version that already did, which would make it easier to write the copy. The reason I'd make that copy is because I suspect that more than one page relies on the same example (and that's why an unhelpful change has slipped through).
/assign


Question: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:

pods/pod-with-node-affinity.yaml
Page: /language zh
/triage accepted The YAML file was not sync'ed with English version.
/assign


Question: to validate the request. If an expression evaluates to false, the validation check is enforced according to the `spec.failurePolicy` field. <ins> {{< note >}} You can quickly test CEL expressions in [CEL Playground](https://playcel.undistro.io). {{< /note >}} </ins> To configure a validating admission policy for use in a cluster, a binding is required. The following is an example of a ValidatingAdmissionPolicyBinding.:

Hello there, I would like to suggest adding a link to the CEL Playground in the Kubernetes documentation. CEL (Common Expression Language) is used in Kubernetes APIs, such as the , and the CEL Playground can help users easily test expressions. The playground also includes a set of examples and the . I believe the link would be useful on the following pages: The CEL Playground is available at and the source code can be found at I also invite you to test and contribute to the project. Thank you.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
/transfer website The repo is not quite the right place to track this.
/language en /kind feature
If we add a link, I would add it to: (and I wouldn't add it to the reference page ; instead, we can have link to the three pages I listed above)
/wg api-expression
@ Hey which particular points on these links would you want the CEL playground. I will be glad for more clarification on this?
IMHO, a mention similar to the mention of on the would help: but saying that users can quickly test CEL expressions in the playground.
Hi I've opened a PR () with some suggestions for adding the CEL Playground link. Please take a look and let me know your thoughts. Inviting to share their thoughts as well.
I'm supportive of this. It's a wonderful tool and the community will benefit from being more aware of it.
/triage accepted


Question: Once a request passes all admission controllers, it is validated using the validation routines for the corresponding API object, and then written to the object store (shown as step **4**). <ins> ## Auditing Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster. The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself. For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/). </ins> ## API server ports and IPs

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 (briefly) mention that access control mechanisms are followed, optionally, by an audit mechanism recording that decision. Why is this needed Once the concept of auditing is into the Concepts section, we can update other mentions of that concept to hyperlink there. Comments Also relevant to The task page at already gives some background to the mechanism. It's OK to borrow text from that task page if it makes sense to do so. /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: <ins> --- title: アドオンのインストール content_type: concept --- <!-- overview --> {{% thirdparty-content %}} アドオンはKubernetesの機能を拡張するものです。 このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 <!-- body --> ## ネットワークとネットワークポリシー * [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 * [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションをサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 * [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 * [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 * [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 * [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 * [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 ## サービスディスカバリ * [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。 ## 可視化と制御 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。 * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。 ## インフラストラクチャ * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 ## レガシーなアドオン いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。 よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 </ins>

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


Question: <hr> <del> - **fieldPath** (string), 必需的 </del> <ins> - **fieldPath** (string)，必需的 </ins> 在指定 API 版本中要选择的字段的路径。

Hello, I noticed some punctuation errors on page /language zh
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/retitle Punctuation errors on /remove-kind feature /kind bug


Question: <ins> --- title: "クラスター" weight: 60 --- </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
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: 2. To see the rollout status, run: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this:

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: <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: patch-demo

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x ] Bug Report Problem: Deployment yaml file: mysql- api version does not fit 1.9 version: apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment Proposed Solution: change apiVersion to: apps/v1 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 9 ! <!--Additional Information:--


Question: <del> # i18n strings for the Portuguese (main) site. </del> <ins> # i18n strings for the Portuguese (main) site. [caution] other = "Cuidado:" </ins> <del> [deprecation_warning] other = " a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma captura instantânea estática. Para obter documentação atualizada, consulte " </del> <ins> [cleanup_heading] other = "Limpando" [community_events_calendar] other = "Calendário de Eventos" [community_forum_name] other = "Fórum" [community_github_name] other = "GitHub" # Community links [community_slack_name] other = "Slack" [community_stack_overflow_name] other = "Stack Overflow" [community_twitter_name] other = "Twitter" </ins> [deprecation_file_warning] other = "Descontinuado" <del> [objectives_heading] other = "Objetivos" </del> <ins> [deprecation_warning] other = " a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma captura instantânea estática. Para obter documentação atualizada, consulte " </ins> <del> [cleanup_heading] other = "Limpando" </del> <ins> [docs_label_browse] other = "Procurar documentos" </ins> <del> [prerequisites_heading] other = "Antes de você começar" </del> <ins> [docs_label_contributors] other = "Colaboradores" </ins> <del> [whatsnext_heading] other = "Qual é o próximo" </del> <ins> [docs_label_i_am] other = "Eu sou..." [docs_label_users] other = "Usuários" </ins> [feedback_heading] other = "Comentários" <ins> [feedback_no] other = "Não" </ins> [feedback_question] other = "Esta página foi útil?"

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: After PR was merged, the website does not build. This is because the Portuguese localization includes a duplicate translation for a string. Proposed Solution: Remove the duplication Additional Information: /priority critical-urgent /kind bug


Question: --build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" </ins> container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. <del> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </del> <ins> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </ins> test-examples: scripts/test_examples.sh install

Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
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
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented.

May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: unless the Pod's grace period expires. For more details, see [Termination of Pods](/docs/user-guide/pods/#termination-of-pods). <ins> **Note**: Kubernetes only sends the preStop event when a Pod is *terminated*. This means that the preStop hook is not invoked when the Pod is *completed*. This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807). {: .note} </ins> {% endcapture %}

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [* ] Bug Report Problem: preStop handler not working when job was deleted Proposed Solution: if issue actually exists along with tests, special statement should be given for documentation Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--9 <!--Additional Information:--
please track this issue: kubernetes/kubernetes At the same time, we should document it.
ok thanks! very expected to proceed it.


Question: Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace <del> (beyond discovery permissions given to all authenticated users). </del> <ins> (beyond the permissions given by [API discovery roles](#discovery-roles)). </ins> This allows you to grant particular roles to particular ServiceAccounts as needed. Fine-grained role bindings provide greater security, but require more effort to administrate.

The phrase "beyond discovery permissions given to all authenticated users" in these two sections seems inaccurate. It is quite possible to guess that it references to namely , , , but because of "discovery permissions" phrase it seems to only refer to . It would be better to use different wording, for example: beyond the permissions given by beyond the permissions given by and groups beyond the permissions given by , , cluster roles
/language en /sig docs /kind feature
/retitle Ambiguity in 'beyond discovery permissions' wording in "Using RBAC Authorization" page
/sig auth
/triage accepted A clarification seems reasonable.
/assign
PR working on this issue.


Question: {{- $latestVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $latestVersionAddMinor -}} {{- $latestVersionAddMinor -}} {{- end -}} <ins> {{- $currentVersion := site.Params.version -}} {{- $currentVersion := (replace $currentVersion "v" "") -}} {{- $currentVersionArray := split $currentVersion "." -}} {{- $currentMinorVersion := int (index $currentVersionArray 1) -}} <!-- output latestVersion based on captured arg --> {{- if eq $version "currentVersion" -}} {{- $currentVersion -}} {{- end -}} <!-- output currentVersionAddMinor based on captured args --> {{- if eq $version "currentVersionAddMinor" -}} {{- $seperator := .Get 2 -}} {{- if eq $seperator "" -}} {{- $seperator = "." -}} {{- end -}} {{- $currentVersionAddMinor := int (.Get 1) -}} {{- $currentVersionAddMinor = add $currentMinorVersion $currentVersionAddMinor -}} {{- $currentVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $currentVersionAddMinor -}} {{- $currentVersionAddMinor -}} {{- end -}} </ins> <!-- example shortcode use: - skew nextMinorVersion - skew latestVersion <ins> - skew currentVersion </ins> - skew prevMinorVersion - skew oldestMinorVersion - skew latestVersionAddMinor -1 "-" <ins> - skew currentVersionAddMinor -1 "-" </ins> -->  No newline at end of file

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The page https://v1- explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.20.x to version 1.21.x, and from version 1.21.x to 1.21.y. (Should be from version 1.19.x to version 1.20.x, and from version 1.20.x to 1.20.y.) Proposed Solution: In Replace =- =- ... Page to Update: https://v1- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
I think we should fix the shortcode to use the documented version, rather than the most recent release. /sig cluster-lifecycle /language en
the intent behind seems to be misleading if is fed at build time pointing at the latest current k8s version. while extending the latestVersion shortcodes i expected to be static and hardcoded per k/website release branch. i can send PRs for this but i'd need to understand more about the "documented" version that you mentioned. i.e. making latestVersion fixed to 1.20 in the 1.20 release branch seems reasonable to me.
^ for additional opinions.
Despite a misleading name, is supposed to use not . AIUI.
i can see is being used in a few places: should all of these be modified to use or only the shortcodes in ? and for which branches - and ?
is useful, it does represent the most recent release.
ok, i can PR the change for 1.20, and master since this is only a problem for the kubeadm upgrade docs. is also used here, but the versions there are just examples. https://v1-
here are the PRs:
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
/remove-lifecycle stale
/triage accepted
/priority-important longterm
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority-important longterm Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority important-longterm


Question: ``` kubeadm을 사용하는 경우, <del> [kubelet용 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 수동으로 구성한다. </del> <ins> [kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다. </ins> ### CRI-O

<!-- 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: In , the link href is (English). The of is recently in . Proposed Solution: In , Before: After: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
/language ko
/triage accepted
Resolved by


Question: - Use `uniq` to aggregate image counts ```shell <del> kubectl get pods --all-namespaces -o jsonpath="{..image}" | </del> <ins> kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | </ins> tr -s '[[:space:]]' 'n' | sort | uniq -c

Hi, I've tested this example : It returns image names double, because "{..image}" recursively search in the output of JSON, So at the first, it will find the "image" word in "" and at the second time, it will find the "image" word in "". It means you will see the image name two times for each pod at least. Please change your example. Best Regards, Alireza Bahmani.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi What's the URL of the page where you've seen a problem?
here are the links to the: kubernetes docs website page ~ markdown file(s) where it require changes ~
The issue is, the following command produces 2 times (the count of image in a single pod). As mentioned, it is because the command count both the occurrence from the & sections from a single pod json manifest. Ideally it should be:
Following could be one of the fix for it:
/assign
There are other references . These would return duplicate images as well, right? I've updated those as well for now.
Hi yes, I feel those also need to be fixed. Let's wait for to provide their review. :)


Question: | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | | | `HyperVContainer` | `false` | Alpha | 1.10 | | | `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | | <ins> | `IPv6DualStack` | `false` | Alpha | 1.16 | | </ins> | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |

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--The FeatureGate "IPv6DualStack" does not exist in the feature gate reference page. There is no way to clearly track the support for dual stack as Alpha/Beta/GA.. Proposed Solution: Please add the feature gate referenced in "" in the feature gate reference page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--version v1.18 <!--Additional Information:--
/assign /kind bug
/sig network


Question: [Kubernetes 历史上最大的迁移](/zh-cn/blog/2024/05/20/completing-cloud-provider-migration/)中，大约删除了 150 万行代码，将核心组件的二进制文件大小减小了约 40%。在项目早期，很明显可扩展性是成功的关键。 然而，如何实现这种可扩展性并不总是很清楚。此次迁移从核心 Kubernetes 代码库中删除了各种特定于供应商的功能。 <del> 现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如[自定义资源定义（CRD）](https://https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) </del> <ins> 现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如[自定义资源定义（CRD）](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) </ins> 或 [Gateway API](https://gateway-api.sigs.k8s.io/) 等 API 标准。 Kubernetes 在为其庞大的用户群体提供服务时也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、由社区拥有的 registry.k8s.io。为用户提供预编译二进制镜像的出口带宽和成本已经变得非常巨大。这一新的仓库变更使社区能够以更具成本效益和性能高效的方式继续提供这些便利的镜像。

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 zh translation of the blog post "10 Years of Kubernetes" has a link which repeats the part of it and thus directs to an inaccessible page. Proposed Solution: Just removing the repetition. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--This issue is similar to
/assign
/priority backlog /triage accepted


Question: ### Install using native package management {{< tabs name="kubectl_install" >}} <del> {{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubectl {{< /tab >}} </del> <ins> {{% tab name="Debian-based distributions" %}} 1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository: ```shell sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl ``` 2. Download the Google Cloud public signing key: ```shell sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. Add the Kubernetes `apt` repository: ```shell echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. Update `apt` package index with the new repository and install kubectl: ```shell sudo apt-get update sudo apt-get install -y kubectl ``` {{% /tab %}} </ins> <del> {{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo </del> <ins> {{< tab name="Red Hat-based distributions" codelang="bash" >}} cat <<EOF > /etc/yum.repos.d/kubernetes.repo </ins> [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64

The current installation instructions for installing the third party Kubernetes Apt repository on Debian/Ubuntu, goes against best security practice. Currently the signing keys are to . The keychain should be downloaded to (file name to match the name used in ) using or (not as this is deprecated and will be last available in Debian 11 and Ubuntu 22.04) and referred to in as such Page to Update: References:
i read the linked pages and this change seems valid. thank you for bringing this up. would you help us by sending a PR for that? /sig cluster-lifecycle
/priority important-longterm /kind cleanup
/triage accepted
Please see
/sig cli


Question: title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> --- <!-- layout: blog

This is a Bug Report Problem: The dockershim alias () now directs to the Chinese localized version () because the same alias exists in multiple files. Proposed Solution: Removal of the alias in the Chinese version of the blog post or updated to be A policy or linter might be worth putting in place for aliases as well to prevent future issues. Page to Update:
/triage accepted /kind bug /language zh
A similar problem occurred some time ago with aliases in security. I just checked a few other files. Aliases field is set: content/zh/docs/reference/issues- content/zh/docs/reference/issues- Aliases field not set (set in version): content/zh/docs/reference/access-authn- Should add a note to the localization or documentation about how to update the field.
/assign


Question: ### TaintNodesByCondition {#taintnodesbycondition} <del> {{< feature-state for_k8s_version="v1.12" state="beta" >}} </del> <ins> {{< feature-state for_k8s_version="v1.17" state="stable" >}} </ins> This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions.

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 that the admission controller is beta; however the related feature gate is now GA. Proposed Solution: Verify the feature status of the TaintNodeByCondition feature for the admission controller specifically. If is in fact stable, update the page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en
could you confirm whether that admission controller is still beta?
/triage accepted
/assign
is this just a matter of getting a "yes" from someone on SIG Node to confirm that is GA? It seems to be as you mentioned, since 1.17 () but let me know if we need explicit confirmation and I'll chase it down.
Confirmed GA since 1.17 by Will update the page


Question: <ins> --- layout: blog title: "更新: dockershimの削除に関するFAQ" linkTitle: "dockershimの削除に関するFAQ" date: 2022-02-17 slug: dockershim-faq aliases: [ '/ja/dockershim' ] --- **この記事は2020年の後半に投稿されたオリジナルの記事[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)の更新版です。 この記事にはv1.24のリリースに関する更新を含みます。** --- この文書では、Kubernetesからの _dockershim_ の削除に関するよくある質問について説明します。 この削除はKubernetes v1.20リリースの一部としてはじめて[発表](/blog/2020/12/08/kubernetes-1-20-release-announcement/)されたものです。 Kubernetes [v1.24のリリース](/releases/#release-v1-24)においてdockershimは実際にKubernetesから削除されました。 これが何を意味するかについては、ブログ記事[Don't Panic: Kubernetes and Docker](/ja/blog/2020/12/02/dont-panic-kubernetes-and-docker/)をご覧ください。 [dockershim削除の影響範囲を確認する](/ja/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)をお読みいただくことで、 dockershimの削除があなたやあなたの組織に与える影響をご判断いただけます。 Kubernetes 1.24リリースに至るまでの間、Kubernetesコントリビューターはこの移行を円滑に行えるようにするために尽力してきました。 - 私たちの[コミットメントと次のステップ](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)を詳述したブログ記事。 - [他のコンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/#container-runtimes)への移行に大きな障害があるかどうかのチェック。 - [dockershimからの移行](/ja/docs/tasks/administer-cluster/migrating-from-dockershim/)ガイドの追加。 - [dockershimの削除とCRI互換ランタイムの使用に関する記事一覧](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)の作成。 このリストには、上に示した文書の一部が含まれており、また、厳選された外部の情報(ベンダーによるガイドを含む)もカバーしています。 ### dockershimはなぜKubernetesから削除されたのですか？ Kubernetesの初期のバージョンは、特定のコンテナランタイム上でのみ動作しました。 Docker Engineです。その後、Kubernetesは他のコンテナランタイムと連携するためのサポートを追加しました。 オーケストレーター(Kubernetesなど)と多くの異なるコンテナランタイムの間の相互運用を可能にするため、 CRI標準が[作成](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)されました。 Docker Engineはそのインターフェイス(CRI)を実装していないため、Kubernetesプロジェクトは移行を支援する特別なコードを作成し、 その _dockershim_ コードをKubernetes自身の一部としました。 dockershimコードは常に一時的な解決策であることを意図されていました(このためshimと名付けられています)。 コミュニティでの議論や計画については、[dockershimの削除によるKubernetes改良の提案][drkep]にてお読みいただけます。 実際、dockershimのメンテナンスはKubernetesメンテナーにとって大きな負担になっていました。 さらに、dockershimとほとんど互換性のなかった機能、たとえばcgroups v2やユーザーネームスペースなどが、 これらの新しいCRIランタイムに実装されています。Kubernetesからdockershimを削除することで、これらの分野でのさらなる開発が可能になります。 [drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim ### Dockerとコンテナは同じものですか？ DockerはLinuxのコンテナパターンを普及させ、その基盤技術の発展に寄与してきましたが、 Linuxのコンテナ技術そのものはかなり以前から存在しています。 また、コンテナエコシステムはDockerを超えてより広範に発展してきました。 OCIやCRIのような標準は、Dockerの機能の一部を置き換えたり、既存の機能を強化したりすることで、 私達のエコシステムの多くのツールの成長と繁栄を助けてきました。 ### 既存のコンテナイメージは引き続き使えるのですか？ はい、`docker build`から生成されるイメージは、全てのCRI実装で動作します。 既存のイメージも全く同じように動作します。 ### プライベートイメージについてはどうでしょうか？ はい、すべてのCRIランタイムはKubernetesで使われているものと同一のpull secretsをサポートしており、 PodSpecまたはService Accountを通して利用できます。 ### Kubernetes 1.23でDocker Engineを引き続き使用できますか？ はい、1.20で変更されたのは、Docker Engineランタイムを使用している場合に警告ログが[kubelet]起動時に出るようになったことだけです。 この警告は、1.23までのすべてのバージョンで表示されます。 dockershimの削除はKubernetes 1.24で行われました。 Kubernetes v1.24以降を実行している場合は、[Docker Engineを引き続きコンテナランタイムとして利用できますか？](#can-i-still-use-docker-engine-as-my-container-runtime)をご覧ください。 (CRIがサポートされているKubernetesリリースを使用している場合、dockershimから切り替えることができることを忘れないでください。 リリースv1.24からはKubernetesにdockershimが含まれなくなったため、**必ず**切り替えなければなりません)。 [kubelet]: /docs/reference/command-line-tools-reference/kubelet/ ### どのCRIの実装を使うべきでしょうか？ これは難しい質問で、様々な要素に依存します。 もしDocker Engineがうまく動いているのであれば、containerdに移行するのは比較的簡単で、 性能もオーバーヘッドも確実に改善されるでしょう。 しかし、他の選択のほうがあなたの環境により適合する場合もありますので、 [CNCF landscape]にあるすべての選択肢を検討されることをおすすめします。 [CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category #### Docker Engineを引き続きコンテナランタイムとして利用できますか？ {#can-i-still-use-docker-engine-as-my-container-runtime} 第一に、ご自身のPCで開発やテスト用途でDockerを使用している場合、何も変わることはありません。 Kubernetesでどのコンテナランタイムを使っていても、Dockerをローカルで使い続けることができます。 コンテナではこのような相互運用性を実現できます。 MirantisとDockerは、Kubernetesから内蔵のdockershimが削除された後も、 Docker Engineの代替アダプターを維持することに[コミット][mirantis]しています。 代替アダプターの名前は[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)です。 `cri-dockerd`をインストールして、kubeletをDocker Engineに接続するために使用することができます。 詳細については、[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)を読んでください。 [mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ ### 今現在でプロダクション環境に他のランタイムを使用している例はあるのでしょうか？ Kubernetesプロジェクトが生み出したすべての成果物(Kubernetesバイナリ)は、リリースごとに検証されています。 また、[kind]プロジェクトは以前からcontainerdを使っており、プロジェクトのユースケースにおいて安定性が向上してきています。 kindとcontainerdは、Kubernetesコードベースの変更を検証するために毎日何回も利用されています。 他の関連プロジェクトも同様のパターンを追っており、他のコンテナランタイムの安定性と使いやすさが示されています。 例として、OpenShift 4.xは2019年6月以降、CRI-Oランタイムをプロダクション環境で使っています。 他の事例や参考資料はについては、 containerdとCRI-O(Cloud Native Computing Foundation ([CNCF])の2つのコンテナランタイム)の採用例をご覧ください。 - [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) - [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) [CRI-O]: https://cri-o.io/ [kind]: https://kind.sigs.k8s.io/ [CNCF]: https://cncf.io ### OCIという単語をよく見るのですが、これは何ですか？ OCIは[Open Container Initiative]の略で、コンテナツールとテクノロジー間の数多くのインターフェースの標準化を行った団体です。 彼らはコンテナイメージをパッケージするための標準仕様(OCI image-spec)と、 コンテナを実行するための標準仕様(OCI runtime-spec)をメンテナンスしています。 また、[runc]という形でruntime-specの実装もメンテナンスしており、 これは[containerd]と[CRI-O]の両方でデフォルトの下位ランタイムとなっています。 CRIはこれらの低レベル仕様に基づいて、コンテナを管理するためのエンドツーエンドの標準を提供します。 [Open Container Initiative]: https://opencontainers.org/about/overview/ [runc]: https://github.com/opencontainers/runc [containerd]: https://containerd.io/ ### CRI実装を変更する際に注意すべきことは何ですか？ DockerとほとんどのCRI(containerdを含む)において、下位で使用されるコンテナ化コードは同じものですが、 いくつかの細かい違いが存在します。移行する際に考慮すべき一般的な事項は次のとおりです。 - ログ設定 - ランタイムリソースの制限 - ノード構成スクリプトでdockerコマンドやコントロールソケット経由でDocker Engineを使用しているもの - `kubectl`のプラグインで`docker` CLIまたはDocker Engineコントロールソケットが必要なもの - KubernetesプロジェクトのツールでDocker Engineへの直接アクセスが必要なもの(例:廃止された`kube-imagepuller`ツール) - `registry-mirrors`やinsecureレジストリなどの機能の設定 - その他の支援スクリプトやデーモンでDocker Engineが利用可能であることを想定していてKubernetes外で実行されるもの(モニタリング・セキュリティエージェントなど) - GPUまたは特別なハードウェア、そしてランタイムおよびKubernetesとそれらハードウェアの統合方法 あなたがKubernetesのリソース要求/制限やファイルベースのログ収集DaemonSetを使用しているのであれば、それらは問題なく動作し続けますが、 `dockerd`の設定をカスタマイズしていた場合は、それを新しいコンテナランタイムに適合させる必要があるでしょう。 他に注意することとしては、システムメンテナンスを実行するようなものや、コンテナ内でイメージをビルドするようなものが動作しなくなります。 前者の場合は、[`crictl`][cr]ツールをdrop-inの置き換えとして使用できます([docker cliからcrictlへのマッピング](https://kubernetes.io/ja/docs/tasks/debug/debug-cluster/crictl/#docker-cli%E3%81%8B%E3%82%89crictl%E3%81%B8%E3%81%AE%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0)を参照)。 後者の場合は、[img]、[buildah]、[kaniko]、[buildkit-cli-for-kubectl]のようなDockerを必要としない新しいコンテナビルドの選択肢を使用できます。 [cr]: https://github.com/kubernetes-sigs/cri-tools [img]: https://github.com/genuinetools/img [buildah]: https://github.com/containers/buildah [kaniko]: https://github.com/GoogleContainerTools/kaniko [buildkit-cli-for-kubectl]: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl containerdを使っているのであれば、[ドキュメント]を参照して、移行するのにどのような構成が利用可能かを確認するところから始めるといいでしょう。 [ドキュメント]: https://github.com/containerd/cri/blob/master/docs/registry.md containerdとCRI-OをKubernetesで使用する方法に関しては、[コンテナランタイム]に関するKubernetesのドキュメントを参照してください。 [コンテナランタイム]: /ja/docs/setup/production-environment/container-runtimes/ ### さらに質問がある場合どうすればいいでしょうか？ ベンダーサポートのKubernetesディストリビューションを使用している場合、彼らの製品に対するアップグレード計画について尋ねることができます。 エンドユーザーの質問に関しては、[エンドユーザーコミュニティフォーラム](https://discuss.kubernetes.io/)に投稿してください。 dockershimの削除に関する決定については、専用の[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)で議論することができます。 変更点に関するより詳細な技術的な議論は、[待ってください、DockerはKubernetesで非推奨になったのですか？][dep]という素晴らしいブログ記事も参照してください。 [dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m ### dockershimを使っているかどうかを検出できるツールはありますか？ はい！[Detector for Docker Socket (DDS)][dds]というkubectlプラグインをインストールすることであなたのクラスターを確認していただけます。 DDSは、アクティブなKubernetesワークロードがDocker Engineソケット(`docker.sock`)をボリュームとしてマウントしているかを検出できます。 さらなる詳細と使用パターンについては、DDSプロジェクトの[README][dds]を参照してください。 [dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket ### ハグしていただけますか？ はい、私達は引き続きいつでもハグに応じています。🤗🤗🤗 </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Add japanese translations of the contents listed below: {{% dockershim-removal %}} block Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref.
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
/language ja


Question: <!-- overview --> Many applications rely on configuration which is used during either application initialization or runtime. Most of the times there is a requirement to adjust values assigned to configuration parameters. <del> ConfigMaps is the kubernetes way to inject application pods with configuration data. </del> <ins> ConfigMaps are the Kubernetes way to inject application pods with configuration data. </ins> ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.

This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as “optional”). If you reference a ConfigMap that doesn’t exist, the Pod won’t start. Likewise, references to keys that don’t exist in the ConfigMap will prevent the pod from starting. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign


Question: description: > Principles and practices for good RBAC design for cluster operators. content_type: concept <ins> weight: 60 </ins> --- <!-- overview -->

This is a Feature Request What would you like to be A section in the Kubernetes documentation to provide users with best practice guidelines and references to Kubernetes projects and solutions for multi-tenancy. This can be a new section in . Why is this needed Kubernetes is commonly used by multiple teams and to run multiple applications. The has been chartered with defining multi-tenancy models for Kubernetes and making these easy to consume for end users. The group has produced multiple projects like , , and and published blog posts on and the projects (, ). The HNC and Virtual Cluster projects have “graduated” from the working group and are now managed under SIG-auth and SIG-cluster-lifecycle. However, multi-tenancy remains a confusing and complex topic for Kubernetes users, especially beginners. Having a section on multi-tenancy in the Kubernetes documentation, with links to projects, would be helpful to all users. Comments If this seems like a good idea, the Multi-Tenancy WG can take the lead to propose a draft document. cc:
Happy for multitenancy WG to take this forward - also, that WG is welcome to triage this as accepted. Please also explore whether you can put new content within three of the existing sections: and, that way, avoid adding a new section to the concept list - we already have quite a few. of course, it's also fine to add new Task or Reference pages that cover multi-tenancy aspects.
/language en
/triage accepted
See also
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/wg multi-tenancy
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg multi-tenancy 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
/wg multitenancy


Question:
First, check that the app is running. To find the exposed IP address and port, run the describe service command:

kubectl describe services/kubernetes-bootcamp

Create an environment variable called <tt>NODE_PORT</tt> that has the value of the Node port assigned:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
  echo "NODE_PORT=$NODE_PORT"

Next, do a curl to the the exposed IP and port:

curl http://"$(minikube ip):$NODE_PORT"

A qotation mark is missing at the end of a command, making it wrong. At the page at step 2: The command is: export NODEPORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index 0).nodePort}}') And should be: export NODEPORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index 0).nodePort}}')"
/language en
/triage accepted
/assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig doc </details
Page to Update: /retitle Unquoted export in "Performing a Rolling Update" tutorial /kind bug
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted


Question: <del> #!/bin/bash #!/usr/bin/env bash # This script reproduces what the kubelet does # to calculate memory.available relative to root cgroup. # current memory usage memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}') memory_working_set=${memory_usage_in_bytes} if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; then memory_working_set=0 else memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) fi memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) memory_available_in_kb=$((memory_available_in_bytes / 1024)) memory_available_in_mb=$((memory_available_in_kb / 1024)) echo "memory.capacity_in_bytes $memory_capacity_in_bytes" echo "memory.usage_in_bytes $memory_usage_in_bytes" echo "memory.total_inactive_file $memory_total_inactive_file" echo "memory.working_set $memory_working_set" echo "memory.available_in_bytes $memory_available_in_bytes" echo "memory.available_in_kb $memory_available_in_kb" echo "memory.available_in_mb $memory_available_in_mb" </del>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There is a broken link to script in tasks/administer-cluster/out-of- file. At 44 line: Proposed Solution: Move the script file to examples directory. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign


Question: <ins> --- title: ラベル id: label date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels short_description: > ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 aka: tags: - fundamental --- ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 <!--more--> ラベルは、{{< glossary_tooltip text="Pod" term_id="pod" >}}などのオブジェクトに付与されるキーと値のペアです。オブジェクトのサブセットを組織化したり選択したりするために使われます。 </ins>

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


This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --I think in Japanese StatefulSet page is a little confusing. It says that one Persistent Volueme (PV) is created per VolumeClaimTemplate. So, I imagined that if I defined a VolumeClaimTemplate and replicas=3, 1 PV would be created. However, in reality, 1 PV is assigned to each pod, resulting in 3 PVs being created. And in , it doesn't mention Persistent Volume. I think it is better that Stable Storage section in Japanese is updated. Why is this needed Stable Storage section in Japanese is a little confusing. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language ja
/kind bug
PV and PVC are 1:1 mapping with pods. so Japanese explanation has to be updated
Thanks If you are interested, would you like to work on this issue? If it’s difficult to work, please comment with . /area localization /triage accepted
Thanks, I want to try to work on this issue! /assign


Question: * `template` 字段包含以下子字段： * Pod 被使用 `.metadata.labels` 字段打上 `app: nginx` 标签。 * Pod 模板规约（即 `.template.spec` 字段）指示 Pods 运行一个 `nginx` 容器， <del> 该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/)镜像。 </del> <ins> 该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/) 镜像。 </ins> * 创建一个容器并使用 `.spec.template.spec.containers[0].name` 字段将其命名为 `nginx`。 <!--

There are some bugs: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" "image updated to 1.9.1" should be changed to "image updated to 1.16.1" The content of this article has many "", it could be changed to "deployment". For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
/language zh
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
looks like docs is already updated to nginx:1.16.1. Do you mind closing this issue?
There should still be a few places left unfinished.
Could you please edit the issue which needs to be still updated?
Bug1: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" Bug2: ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" Bug3: "image updated to 1.9.1" should be changed to "image updated to 1.16.1" Bug4: The content of this article has many "", it could be changed to "deployment".

For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
Thanks for clarifying. /assign
/retitle [zh] Localization bugs / work required for Deployment concept
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted