Question:
 --- api_metadata: apiVersion: "batch/v1" import: "k8s.io/api/batch/v1" kind: "Job" content_type: "api_reference" description: "Job 表示单个作业的配置。" title: "Job" weight: 9 ---  `apiVersion: batch/v1` `import "k8s.io/api/batch/v1"` ## Job {#Job}  Job 表示单个作业的配置。
 - **apiVersion**: batch/v1 - **kind**: Job  - **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 "../workload-resources/job-v1#JobSpec" >}}">JobSpec) 作业的预期行为的规约。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status  - **status** (<a href="{{< ref "../workload-resources/job-v1#JobStatus" >}}">JobStatus) 作业的当前状态。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status ## JobSpec {#JobSpec}  JobSpec 描述了作业执行的情况。
 ### Replicas  - **template** (<a href="{{< ref "../workload-resources/pod-template-v1#PodTemplateSpec" >}}">PodTemplateSpec), 必需 描述执行作业时将创建的 Pod。更多信息： https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ - **parallelism** (int32) 指定作业应在任何给定时刻预期运行的 Pod 个数上限。 当(.spec.completions - .status.successful) < .spec.parallelism 时， 即当剩余的工作小于最大并行度时，在稳定状态下运行的 Pod 的实际数量将小于此数量。 更多信息： https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ ### Lifecycle  - **completions** (int32) 指定作业应该运行并预期成功完成的 Pod 个数。设置为 nil 意味着任何 Pod 的成功都标识着所有 Pod 的成功， 并允许 parallelism 设置为任何正值。设置为 1 意味着并行性被限制为 1，并且该 Pod 的成功标志着作业的成功。更多信息： https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/  - **completionMode** (string) completionMode 指定如何跟踪 Pod 完成情况。它可以是 `NonIndexed` （默认） 或者 `Indexed`。 `NonIndexed` 表示当有 `.spec.completions` 个成功完成的 Pod 时，认为 Job 完成。每个 Pod 完成都是彼此同源的。  `Indexed` 意味着 Job 的各个 Pod 会获得对应的完成索引值，从 0 到（`.spec.completions - 1`），可在注解 "batch.kubernetes.io/job-completion-index" 中找到。当每个索引都对应有一个成功完成的 Pod 时， 该作业被认为是完成的。 当值为 `Indexed` 时，必须指定 `.spec.completions` 并且 `.spec.parallelism` 必须小于或等于 10^5。 此外，Pod 名称采用 `$(job-name)-$(index)-$(random-string)` 的形式，Pod 主机名采用 `$(job-name)-$(index)` 的形式。  将来可能添加更多的完成模式。如果 Job 控制器发现它无法识别的模式 （这种情况在升级期间由于版本偏差可能发生），则控制器会跳过 Job 的更新。  - **backoffLimit** (int32) 指定标记此作业失败之前的重试次数。默认值为 6。 - **activeDeadlineSeconds** (int64) 系统尝试终止作业之前作业可以持续活跃的持续时间（秒），时间长度是相对于 startTime 的； 字段值必须为正整数。如果作业被挂起（在创建期间或因更新而挂起）， 则当作业再次恢复时，此计时器会被停止并重置。  - **ttlSecondsAfterFinished** (int32) ttlSecondsAfterFinished 限制已完成执行（完成或失败）的作业的生命周期。如果设置了这个字段， 在 Job 完成 ttlSecondsAfterFinished 秒之后，就可以被自动删除。 当 Job 被删除时，它的生命周期保证（例如终结器）会被考察。 如果未设置此字段，则作业不会被自动删除。如果此字段设置为零，则作业在完成后即可立即删除。  - **suspend** (boolean) suspend 指定 Job 控制器是否应该创建 Pod。如果创建 Job 时将 suspend 设置为 true，则 Job 控制器不会创建任何 Pod。 如果 Job 在创建后被挂起（即标志从 false 变为 true），则 Job 控制器将删除与该 Job 关联的所有活动 Pod。 用户必须设计他们的工作负载来优雅地处理这个问题。暂停 Job 将重置 Job 的 startTime 字段， 也会重置 ActiveDeadlineSeconds 计时器。默认为 false。 ### Selector  - **selector** (<a href="{{< ref "../common-definitions/label-selector#LabelSelector" >}}">LabelSelector) 对应与 Pod 计数匹配的 Pod 的标签查询。通常，系统会为你设置此字段。更多信息： https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors - **manualSelector** (boolean) manualSelector 控制 Pod 标签和 Pod 选择器的生成。除非你确定你在做什么，否则不要设置 `manualSelector`。 当此字段为 false 或未设置时，系统会选择此 Pod 唯一的标签并将这些标签附加到 Pod 模板。 当此字段为 true 时，用户负责选择唯一标签并指定选择器。 未能选择唯一标签可能会导致此作业和其他作业无法正常运行。 但是，你可能会在使用旧的 `extensions/v1beta1` API 创建的作业中看到 `manualSelector=true`。 更多信息： https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector ## JobStatus {#JobStatus}  JobStatus 表示 Job 的当前状态。
  - **startTime** (Time) 表示作业控制器开始处理作业的时间。在挂起状态下创建 Job 时，直到第一次恢复时才会设置此字段。 每次从暂停中恢复作业时都会重置此字段。它表示为 RFC3339 格式的 UTC 时间。 **Time 是 time.Time 的包装器，支持正确编码为 YAML 和 JSON。time 包提供的许多工厂方法都提供了包装器。**  - **completionTime** (Time) 表示作业完成的时间。不能保证对多个独立操作按发生的先后顺序设置。此字段表示为 RFC3339 格式的 UTC 时间。 仅当作业成功完成时才设置完成时间。 **Time 是 time.Time 的包装器，支持正确编码为 YAML 和 JSON。time 包提供的许多工厂方法都提供了包装器。**  - **active** (int32) 待处理和正在运行的 Pod 的数量。 - **failed** (int32) 进入 Failed 阶段的 Pod 数量。 - **succeeded** (int32) 进入 Succeeded 阶段的 Pod 数量。  - **completedIndexes** (string) completedIndexes 以文本格式保存 `.spec.completionMode` 设置为 `"Indexed"` 的 Pod 已完成的索引。 索引用十进制整数表示，用逗号分隔。数字是按递增的顺序排列的。三个或更多的连续数字被压缩， 用系列的第一个和最后一个元素表示，用连字符分开。例如，如果完成的索引是 1、3、4、5 和 7，则表示为 "1、3-5、7"。  - **conditions** ([]JobCondition) **补丁策略：根据 `type` 键合并** **原子：在合并过程中，将被替换。** 对象当前状态的最新可用观察结果。当作业失败时，其中一个状况的类型为 “Failed”，状态为 true。 当作业被暂停时，其中一个状况的类型为 “Suspended”，状态为true；当作业被恢复时，该状况的状态将变为 false。 作业完成时，其中一个状况的类型为 "Complete"，状态为 true。更多信息： https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/jobs-run-to-completion/  **JobCondition 描述作业的当前状况。**  - **conditions.status** (string), 必需 状况的状态，True、False、Unknown 之一。 - **conditions.type** (string), 必需 作业状况的类型，Completed 或 Failed。 - **conditions.lastProbeTime** (Time) 最后一次探测的时间。  **Time 是对 time.Time 的封装，支持正确编码为 YAML 和 JSON。我们为 time 包提供的许多工厂方法提供了封装器。**  - **conditions.lastTransitionTime** (Time) 上一次从一种状况转换到另一种状况的时间。  **Time 是 time.Time 的包装器，支持正确编码为 YAML 和 JSON。time 包提供的许多工厂方法都提供了包装器。**  - **conditions.message** (string) 表示上次转换信息的人类可读消息。 - **conditions.reason** (string) 状况最后一次转换的（简要）原因  - **uncountedTerminatedPods** (UncountedTerminatedPods) UncountedTerminatedPods 保存已终止但尚未被作业控制器纳入状态计数器中的 Pod 的 UID 的集合。 作业控制器所创建 Pod 带有终结器。当 Pod 终止（成功或失败）时，控制器将执行三个步骤以在作业状态中对其进行说明： （1）将 Pod UID 添加到此字段的列表中。（2）去掉 Pod 中的终结器。（3）从数组中删除 Pod UID，同时为相应的计数器加一。  此字段为 Beta 级别。作业控制器仅在启用特性门控 JobTrackingWithFinalizers 时使用此字段（默认启用）。 使用此字段可能无法跟踪旧作业，在这种情况下，该字段保持为空。  **UncountedTerminatedPods 持有已经终止的 Pod 的 UID，但还没有被计入工作状态计数器中。**  - **uncountedTerminatedPods.failed** ([]string) **Set: 在合并过程中，唯一的值将被保留** failed 字段包含已失败 Pod 的 UID。  - **uncountedTerminatedPods.succeeded** ([]string) **Set: 在合并过程中，唯一的值将被保留** succeeded 包含已成功的 Pod 的 UID。  ### Alpha 级别  - **ready** (int32) 状况为 Ready 的 Pod 数量。 此字段为 Beta 级别。当特性门控 JobReadyPods 启用（默认启用）时，作业控制器会填充该字段。 ## JobList {#JobList}  JobList 是 Job 的集合。
 - **apiVersion**: batch/v1 - **kind**: JobList  - **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 "../workload-resources/job-v1#Job" >}}">Job), required items 是 Job 对象的列表。  ## 操作 {#Operations}
  ### `get` 读取指定的 Job #### HTTP 请求 GET /apis/batch/v1/namespaces/{namespace}/jobs/{name} #### 参数 - **name** (**路径参数**)：string，必需 Job 的名字。  - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **pretty** (**查询参数**): string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): OK 401: Unauthorized ### `get` 读取指定作业的状态 #### HTTP 请求 GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status #### 参数  - **name** (**路径参数**): string, 必需 Job 的名称。 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **pretty** (**查询参数**): string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): OK 401: Unauthorized ### `list` 列举或监测 Job 类别的对象 #### HTTP 请求 GET /apis/batch/v1/namespaces/{namespace}/jobs #### 参数 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **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 "../workload-resources/job-v1#JobList" >}}">JobList): OK 401: Unauthorized ### `list` 列举或监测 Job 类别的对象 #### HTTP 请求 GET /apis/batch/v1/jobs #### 参数  - **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 "../workload-resources/job-v1#JobList" >}}">JobList): OK 401: Unauthorized ### `create` 创建一个 Job #### HTTP 请求 POST /apis/batch/v1/namespaces/{namespace}/jobs #### 参数 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **body**: <a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job, 必需  - **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 "../workload-resources/job-v1#Job" >}}">Job): OK 201 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Created 202 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Accepted 401: Unauthorized ### `update` 替换指定的 Job #### HTTP 请求 PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name} #### 参数  - **name** (**路径参数**): string, 必需 Job 的名称。 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **body**: <a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job, 必需  - **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 "../workload-resources/job-v1#Job" >}}">Job): OK 201 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Created 401: Unauthorized ### `update` 替换指定 Job 的状态 #### HTTP 请求 PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status #### 参数  - **name** (**路径参数**): string, 必需 Job 的名字 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **body**: <a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job, 必需  - **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 "../workload-resources/job-v1#Job" >}}">Job): OK 201 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Created 401: Unauthorized ### `patch` 部分更新指定的 Job #### HTTP 请求 PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}  #### 参数 - **name** (**路径参数**): string, 必需 Job 的名称。 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **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 "../workload-resources/job-v1#Job" >}}">Job): OK 201 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Created 401: Unauthorized ### `patch` 部分更新指定 Job 的状态 #### HTTP 请求 PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status #### 参数  - **name** (**路径参数**): string, 必需 Job 的名称。 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **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 "../workload-resources/job-v1#Job" >}}">Job): OK 201 (<a href="{{< ref "../workload-resources/job-v1#Job" >}}">Job): Created 401: Unauthorized ### `delete` 删除一个 Job #### HTTP 请求 DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name} #### 参数 - **name** (**路径参数**): string, 必需 Job的名称 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **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` 删除 Job 的集合 #### HTTP 请求 DELETE /apis/batch/v1/namespaces/{namespace}/jobs #### 参数 - **namespace** (**路径参数**): string, 必需 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace - **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

This is a Feature Report Problem: misssing Chinese translation docs: Proposed Solution: add Chinese translation docs in website Documentation Comments /language zh /assign
/triage accepted
/close Now tracked by
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: - lifecycle - livenessProbe - readinessProbe <del> - securityContext </del> - startupProbe - definition: io.k8s.api.core.v1.ReplicationControllerSpec

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


Question: --- <ins> reviewers: - bgrant0607 - mikedanese </ins> title: "Overview" <ins> description: > Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. content_type: concept </ins> weight: 20 <del> description: Get a high-level outline of Kubernetes and the components it is built from. sitemap: priority: 0.9 </del> <ins> card: name: concepts weight: 10 no_list: true </ins> --- <ins> <!-- overview --> This page is an overview of Kubernetes. <!-- body --> Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community. ## Going back in time Let's take a look at why Kubernetes is so useful by going back in time. ![Deployment evolution](/images/docs/Container_Evolution.svg) **Traditional deployment era:** Early on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers. **Virtualized deployment era:**  As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application. Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more. With virtualization you can present a set of physical resources as a cluster of disposable virtual machines. Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware. **Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions. Containers have become popular because they provide extra benefits, such as: * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use. * Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability). * Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure. * Observability: not only surfaces OS-level information and metrics, but also application health and other signals. * Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud. * Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else. * Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources. * Loosely coupled, distributed, elastic, liberated micro-services: applications are broken into smaller, independent pieces and can be deployed and managed dynamically – not a monolithic stack running on one big single-purpose machine. * Resource isolation: predictable application performance. * Resource utilization: high efficiency and density. ## Why you need Kubernetes and what it can do {#why-you-need-kubernetes-and-what-can-it-do} Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system? That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system. Kubernetes provides you with: * **Service discovery and load balancing** Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable. * **Storage orchestration** Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more. * **Automated rollouts and rollbacks** You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container. * **Automatic bin packing** You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources. * **Self-healing** Kubernetes restarts containers that fail, replaces containers, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. * **Secret and configuration management** Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration. ## What Kubernetes is not Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. Kubernetes: * Does not limit the types of applications supported. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes. * Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements. * Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, MySQL), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the [Open Service Broker](https://openservicebrokerapi.org/). * Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics. * Does not provide nor mandate a configuration language/system (for example, Jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications. * Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. * Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn't matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible. ## {{% heading "whatsnext" %}} *   Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) *   Take a look at the [The Kubernetes API](/docs/concepts/overview/kubernetes-api/) *  Take a look at the [Cluster Architecture](/docs/concepts/architecture/) *   Ready to [Get Started](/docs/setup/)? </ins>

How about "consists of a control plane and a set of machines called nodes"? Learning k8s is hard enough without obfuscating verbosity. For non-managers it's best to say it as it is ;-). Apart from that: "consists of the components that represent the control plane" suggests that there are components that represent a control pane, not are a control pane, and a set of nodes. So where is the control pane? I'm probably a big introvert and a nerd, but this confuses me to the point where I actually have to think about what this means... "In what way do the components represent the control pane? Where is the control pane itself? Am I not getting this? Probably not. It probably means these components are the control pane. Stupid me, of course that's what it means." So, while I could have understood what was meant in a split second, it takes me a couple of seconds of contemplation and a few minutes to suggest an improvement.
We could update the source of to make that change. Nice suggestion. is automatically generated. For a bigger improvement, we could move to and configure a redirect. /language en
/triage accepted /help If someone is planning to move this forward: move to configure a redirect from the old URL to the new URL (see ) make sure that the updated ends how you'd expect. It's likely that setting in the will help.
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help move to configure a redirect from the old URL to the new URL (see ) make sure that the updated ends how you'd expect. It's likely that setting in the will 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
Feel free to reply with questions.
I would love to take this /assign
/good-first-issue For the first-timers, look
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue For the first-timers, look 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: <ins> --- reviewers: - ramrodo - krol3 - electrocucaracha title: Volúmenes Persistentes feature: title: Orquestación de almacenamiento description: > Monta automáticamente el sistema de almacenamiento de tu elección, ya sea de almacenamiento local, un proveedor de nube pública o un sistema de almacenamiento en red como iSCSI o NFS. content_type: concept weight: 20 --- <!-- overview --> Este documento describe _volúmenes persistentes_ en Kubernetes. Se sugiere familiarizarse con [volumes](/es/docs/concepts/storage/volumes/), [StorageClasses](/es/docs/concepts/storage/storage-classes/) y [VolumeAttributesClasses](/docs/concepts/storage/volume-attributes-classes/). <!-- body --> ## Introducción La gestión del almacenamiento es un problema distinto de la gestión de instancias de cómputo. El subsistema PersistentVolume proporciona una API para usuarios y administradores que abstrae los detalles de cómo se proporciona el almacenamiento de cómo se consume. Para hacer esto, introducimos dos nuevos recursos de API: PersistentVolume y PersistentVolumeClaim. Un _PersistentVolume_ (PV) es una pieza de almacenamiento en el cluster que ha sido provisionada por un administrador o provisionada dinámicamente usando [Storage Classes](/es/docs/concepts/storage/storage-classes/). Es un recurso en el cluster al igual que un nodo es un recurso del cluster. Los PVs son plugins de volumen como Volumes, pero tienen un ciclo de vida independiente de cualquier Pod individual que use el PV. Este objeto API captura los detalles de la implementación del almacenamiento, sea NFS, iSCSI o un sistema de almacenamiento específico de un proveedor de nube. Un _PersistentVolumeClaim_ (PVC) es una solicitud de almacenamiento por parte de un usuario. Es similar a un Pod. Los Pods consumen recursos de nodos y los PVCs consumen recursos de PVs. Los Pods pueden solicitar niveles específicos de recursos (CPU y Memoria). Las solicitudes pueden pedir tamaños específicos y modos de acceso (por ejemplo, pueden montarse como ReadWriteOnce, ReadOnlyMany, ReadWriteMany o ReadWriteOncePod, ver [AccessModes](#modos-de-acceso)). Aunque los PersistentVolumeClaims permiten a un usuario consumir recursos de almacenamiento abstractos, es común que los usuarios necesiten PersistentVolumes con propiedades variadas, tales como rendimiento, para diferentes problemas. Los administradores del cluster necesitan poder ofrecer una variedad de PersistentVolumes que difieran en más aspectos que el tamaño y los modos de acceso, sin exponer a los usuarios a los detalles de cómo se implementan esos volúmenes. Para estas necesidades, existe el recurso _StorageClass_. Vea el [tutorial detallado con ejemplos prácticos](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). ## Ciclo de vida de un volumen y una solicitud Los PVs son recursos en el cluster. Los PVCs son solicitudes para esos recursos y también actúan como comprobantes de reclamo al recurso. La interacción entre PVs y PVCs sigue este ciclo de vida: ### Aprovisionamiento Hay dos formas en que los PVs pueden ser aprovisionados: estáticamente o dinámicamente. #### Estático Un administrador del cluster crea un número de PVs. Llevan los detalles del almacenamiento real, que está disponible para uso de los usuarios del cluster. Existen en la API de Kubernetes y están disponibles para su consumo. #### Dinámico Cuando ninguno de los PVs estáticos creados por el administrador coincide con un PersistentVolumeClaim de un usuario, el cluster puede intentar aprovisionar dinámicamente un volumen especialmente para el PVC. Este aprovisionamiento se basa en StorageClasses: el PVC debe solicitar una [clase de almacenamiento](/es/docs/concepts/storage/storage-classes/) y el administrador debe haber creado y configurado esa clase para que ocurra el aprovisionamiento dinámico. Las solicitudes que piden la clase `""` efectivamente desactivan el aprovisionamiento dinámico para sí mismas. Para habilitar el aprovisionamiento dinámico de almacenamiento basado en clases de almacenamiento, el administrador del cluster necesita habilitar el controlador de admisión `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) en el servidor API. Esto se puede hacer, por ejemplo, asegurándose de que `DefaultStorageClass` esté entre la lista de valores delimitados por comas y ordenados para la bandera `--enable-admission-plugins` del componente del servidor API. Para más información sobre las banderas de línea de comandos del servidor API, consulta la documentación de [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/). ### Binding Un usuario crea, o en el caso de aprovisionamiento dinámico, ya ha creado, un PersistentVolumeClaim con una cantidad específica de almacenamiento solicitado y con ciertos modos de acceso. Un bucle de control en el plano de control observa los nuevos PVCs, encuentra un PV coincidente (si es posible) y los une. Si un PV fue aprovisionado dinámicamente para un nuevo PVC, el bucle siempre unirá ese PV al PVC. De lo contrario, el usuario siempre obtendrá al menos lo que pidió, pero el volumen puede ser superior a lo solicitado. Una vez unidos, los enlaces PersistentVolumeClaim son exclusivos, independientemente de cómo se hayan unido. Una unión PVC a PV es un mapeo uno a uno, utilizando un ClaimRef que es una unión bidireccional entre el PersistentVolume y el PersistentVolumeClaim. Las solicitudes permanecerán sin unir indefinidamente si no existe un volumen coincidente. Las solicitudes se unirán a medida que los volúmenes coincidentes estén disponibles. Por ejemplo, un cluster aprovisionado con muchos PVs de 50Gi no coincidirá con un PVC que solicite 100Gi. El PVC puede unirse cuando se agregue un PV de 100Gi al cluster. ### Uso Los Pods usan las solicitudes como volúmenes. El cluster inspecciona la solicitud para encontrar el volumen unido y monta ese volumen para un Pod. Para los volúmenes que admiten múltiples modos de acceso, el usuario especifica qué modo desea cuando utiliza su solicitud como volumen en un Pod. Una vez que un usuario tiene una solicitud y esa solicitud está unida, el PV unido pertenece al usuario mientras lo necesiten. Los usuarios programan Pods y acceden a sus PVs reclamados incluyendo una sección de `persistentVolumeClaim` en el bloque `volumes` de un Pod. Consulta [Solicitudes como Volúmenes](#solicitudes-como-volumenes) para más detalles sobre esto. ### Protección de Objeto de Almacenamiento en Uso El propósito de la función de Protección de Objeto de Almacenamiento en Uso es asegurar que las PersistentVolumeClaims (PVCs) en uso activo por un Pod y los PersistentVolumes (PVs) que están unidos a PVCs no sean eliminados del sistema, ya que esto podría resultar en pérdida de datos. {{< note >}} Un PVC está en uso activo por un Pod cuando existe un objeto Pod que está utilizando el PVC. {{< /note >}} Si un usuario elimina un PVC en uso activo por un Pod, el PVC no se elimina inmediatamente. La eliminación del PVC se pospone hasta que el PVC ya no esté en uso activo por ningún Pod. Además, si un administrador elimina un PV que está unido a un PVC, el PV no se elimina inmediatamente. La eliminación del PV se pospone hasta que el PV ya no esté unido a ningún PVC. Puedes ver que un PVC está protegido cuando el estado del PVC es `Terminating` y la lista de `Finalizers` incluye `kubernetes.io/pvc-protection`: ```shell kubectl describe pvc hostpath Name:          hostpath Namespace:     default StorageClass:  example-hostpath Status:        Terminating Volume: Labels:        <none> Annotations:   volume.beta.kubernetes.io/storage-class=example-hostpath volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath Finalizers:    [kubernetes.io/pvc-protection] ... ``` Puedes ver que un PV está protegido cuando el estado del PV es `Terminating` y la lista de `Finalizers` incluye también `kubernetes.io/pv-protection`: ```shell kubectl describe pv task-pv-volume Name:            task-pv-volume Labels:          type=local Annotations:     <none> Finalizers:      [kubernetes.io/pv-protection] StorageClass:    standard Status:          Terminating Claim: Reclaim Policy:  Delete Access Modes:    RWO Capacity:        1Gi Message: Source: Type:          HostPath (bare host directory volume) Path:          /tmp/data HostPathType: Events:            <none> ``` ### Reclamación Cuando un usuario ha terminado con su volumen, puede eliminar los objetos PVC de la API que permite la recuperación del recurso. La política de reclamación para un PersistentVolume le dice al cluster qué hacer con el volumen después de que ha sido liberado de su solicitud. Actualmente, los volúmenes pueden ser Retenidos, Reciclados o Eliminados. #### Retener La política de reclamación `Retain` permite la recuperación manual del recurso. Cuando se elimina el PersistentVolumeClaim, el PersistentVolume todavía existe y el volumen se considera "liberado". Pero aún no está disponible para otra solicitud porque los datos del reclamante anterior permanecen en el volumen. Un administrador puede recuperar manualmente el volumen con los siguientes pasos. 1. Eliminar el PersistentVolume. El recurso de almacenamiento asociado en la infraestructura externa todavía existe después de que se haya eliminado el PV. 1. Limpiar manualmente los datos en el recurso de almacenamiento asociado en consecuencia. 1. Eliminar manualmente el recurso de almacenamiento asociado. Si deseas reutilizar el mismo recurso de almacenamiento, crea un nuevo PersistentVolume con la misma definición de recurso de almacenamiento. #### Eliminar Para los plugins de volumen que soportan la política de reclamación `Delete`, la eliminación remueve tanto el objeto PersistentVolume de Kubernetes, como el recurso de almacenamiento asociado en la infraestructura externa. Los volúmenes que fueron aprovisionados dinámicamente heredan la [política de reclamación de su StorageClass](#reclaim-policy), que por defecto es `Delete`. El administrador debe configurar la StorageClass de acuerdo con las expectativas de los usuarios; de lo contrario, el PV debe ser editado o modificado después de que se haya creado. Consulta [Cambiar la Política de Reclamación de un PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar {{< warning >}} La política de reclamación `Recycle` está obsoleta. En su lugar, el enfoque recomendado es utilizar el aprovisionamiento dinámico. {{< /warning >}} Si es compatible con el plugin de volumen subyacente, la política de reclamación `Recycle` realiza un borrado básico (`rm -rf /elvolumen/*`) en el volumen y lo hace disponible nuevamente para una nueva solicitud. Sin embargo, un administrador puede configurar una plantilla de Pod reciclador personalizada usando los argumentos de línea de comandos del administrador del controlador de Kubernetes como se describe en la [referencia](/docs/reference/command-line-tools-reference/kube-controller-manager/). La plantilla de Pod reciclador personalizada debe contener una especificación de `volumes`, como se muestra en el ejemplo a continuación: ```yaml apiVersion: v1 kind: Pod metadata: name: pv-recycler namespace: default spec: restartPolicy: Never volumes: - name: vol hostPath: path: /any/path/it/will/be/replaced containers: - name: pv-recycler image: "registry.k8s.io/busybox" command: [ "/bin/sh", "-c", 'test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z "$(ls -A /scrub)" || exit 1', ] volumeMounts: - name: vol mountPath: /scrub ``` Sin embargo, la ruta particular especificada en la plantilla de Pod reciclador personalizado en la parte de `volumes` se reemplaza con la ruta particular del volumen que está siendo reciclado. ### Finalizador de protección de eliminación de PersistentVolume {{< feature-state for_k8s_version="v1.23" state="alpha" >}} Los finalizadores pueden agregarse en un PersistentVolume para asegurar que los PersistentVolumes con política de reclamación `Delete` solo se eliminen después de que se eliminen los almacenamientos subyacentes. Los finalizadores recién introducidos `kubernetes.io/pv-controller` y `external-provisioner.volume.kubernetes.io/finalizer` solo se agregan a los volúmenes provisionados dinámicamente. El finalizador `kubernetes.io/pv-controller` se agrega a los volúmenes de plugins integrados. El siguiente es un ejemplo. ```shell kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 Name:            pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 Labels:          <none> Annotations:     kubernetes.io/createdby: vsphere-volume-dynamic-provisioner pv.kubernetes.io/bound-by-controller: yes pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume Finalizers:      [kubernetes.io/pv-protection kubernetes.io/pv-controller] StorageClass:    vcp-sc Status:          Bound Claim:           default/vcp-pvc-1 Reclaim Policy:  Delete Access Modes:    RWO VolumeMode:      Filesystem Capacity:        1Gi Node Affinity:   <none> Message: Source: Type:               vSphereVolume (a Persistent Disk resource in vSphere) VolumePath:         [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk FSType:             ext4 StoragePolicyName:  vSAN Default Storage Policy Events:                 <none> ``` El finalizador `external-provisioner.volume.kubernetes.io/finalizer` se agrega para los volúmenes CSI. El siguiente es un ejemplo: ```shell Name:            pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d Labels:          <none> Annotations:     pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com Finalizers:      [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] StorageClass:    fast Status:          Bound Claim:           demo-app/nginx-logs Reclaim Policy:  Delete Access Modes:    RWO VolumeMode:      Filesystem Capacity:        200Mi Node Affinity:   <none> Message: Source: Type:              CSI (a Container Storage Interface (CSI) volume source) Driver:            csi.vsphere.vmware.com FSType:            ext4 VolumeHandle:      44830fa8-79b4-406b-8b58-621ba25353fd ReadOnly:          false VolumeAttributes:      storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com type=vSphere CNS Block Volume Events:                <none> ``` Cuando la bandera de función `CSIMigration{provider}` está habilitada para un plugin de volumen integrado específico, el finalizador `kubernetes.io/pv-controller` se reemplaza por el finalizador `external-provisioner.volume.kubernetes.io/finalizer`. ### Reservando un PersistentVolume El plano de control puede [unir PersistentVolumeClaims a PersistentVolumes correspondientes](#binding) en el cluster. Sin embargo, si quieres que un PVC se una a un PV específico, necesitas pre-unirlos. Al especificar un PersistentVolume en un PersistentVolumeClaim, declaras una unión entre ese PV y PVC específicos. Si el PersistentVolume existe y no ha reservado PersistentVolumeClaims a través de su campo `claimRef`, entonces el PersistentVolume y el PersistentVolumeClaim se unirán. La unión ocurre independientemente de algunos criterios de coincidencia de volumen, incluida la afinidad de nodo. El plano de control aún verifica que la [clase de almacenamiento](/es/docs/concepts/storage/storage-classes/), los modos de acceso y el tamaño de almacenamiento solicitado sean válidos. ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set volumeName: foo-pv ... ``` Este método no garantiza ningún privilegio de unión al PersistentVolume. Si otros PersistentVolumeClaims pudieran usar el PV que especificas, primero necesitas reservar ese volumen de almacenamiento. Especifica el PersistentVolumeClaim relevante en el campo `claimRef` del PV para que otros PVCs no puedan unirse a él. ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: foo-pv spec: storageClassName: "" claimRef: name: foo-pvc namespace: foo ... ``` Esto es útil si deseas consumir PersistentVolumes que tienen su `claimPolicy` establecido en `Retain`, incluyendo casos donde estás reutilizando un PV existente. ### Expandiendo Persistent Volume Claims {{< feature-state for_k8s_version="v1.24" state="stable" >}} El soporte para expandir PersistentVolumeClaims (PVCs) está habilitado por defecto. Puedes expandir los siguientes tipos de volúmenes: - azureFile (obsoleto) - {{< glossary_tooltip text="csi" term_id="csi" >}} - flexVolume (obsoleto) - rbd (obsoleto) - portworxVolume (obsoleto) Solo puedes expandir un PVC si el campo `allowVolumeExpansion` de su clase de almacenamiento está establecido en verdadero. ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: example-vol-default provisioner: vendor-name.example/magicstorage parameters: resturl: "http://192.168.10.100:8080" restuser: "" secretNamespace: "" secretName: "" allowVolumeExpansion: true ``` Para solicitar un volumen más grande para un PVC, edita el objeto PVC y especifica un tamaño mayor. Esto desencadena la expansión del volumen que respalda el PersistentVolume subyacente. Nunca se crea un nuevo PersistentVolume para satisfacer la solicitud. En cambio, se redimensiona un volumen existente. {{< warning >}} Editar directamente el tamaño de un PersistentVolume puede impedir un redimensionamiento automático de ese volumen. Si editas la capacidad de un PersistentVolume, y luego editas el `.spec` de un PersistentVolumeClaim coincidente para hacer que el tamaño del PersistentVolumeClaim coincida con el PersistentVolume, entonces no ocurre ningún redimensionamiento de almacenamiento. El plano de control de Kubernetes verá que el estado deseado de ambos recursos coincide, concluirá que el tamaño del volumen de respaldo se ha aumentado manualmente y que no es necesario ningún redimensionamiento. {{< /warning >}} #### Expansión de volúmenes CSI {{< feature-state for_k8s_version="v1.24" state="stable" >}} El soporte para la expansión de volúmenes CSI está habilitado por defecto, pero también requiere que un controlador CSI específico soporte la expansión de volumen. Consulta la documentación del controlador CSI específico para obtener más información. #### Redimensionando un volumen que contiene un sistema de archivos Solo puedes redimensionar volúmenes que contienen un sistema de archivos si el sistema de archivos es XFS, Ext3 o Ext4. Cuando un volumen contiene un sistema de archivos, el sistema de archivos solo se redimensiona cuando un nuevo Pod está utilizando el PersistentVolumeClaim en modo `ReadWrite`. La expansión del sistema de archivos se realiza cuando un Pod se está iniciando o cuando un Pod está en ejecución y el sistema de archivos subyacente soporta la expansión en línea. Los FlexVolumes (obsoletos desde Kubernetes v1.23) permiten redimensionar si el controlador está configurado con la capacidad `RequiresFSResize` en `true`. El FlexVolume se puede redimensionar al reiniciar el Pod. #### Redimensionando un PersistentVolumeClaim en uso {{< feature-state for_k8s_version="v1.24" state="stable" >}} En este caso, no necesitas eliminar y recrear un Pod o despliegue que esté utilizando un PVC existente. Cualquier PVC en uso se vuelve automáticamente disponible para su Pod tan pronto como su sistema de archivos haya sido expandido. Esta característica no tiene efecto en PVCs que no están en uso por un Pod o despliegue. Debes crear un Pod que utilice el PVC antes de que la expansión pueda completarse. Similar a otros tipos de volúmenes - los volúmenes FlexVolume también pueden ser expandidos cuando están en uso por un Pod. {{< note >}} El redimensionamiento de FlexVolume es posible solo cuando el controlador subyacente soporta el redimensionamiento. {{< /note >}} #### Recuperación de fallos al expandir volúmenes Si un usuario especifica un nuevo tamaño que es demasiado grande para ser satisfecho por el sistema de almacenamiento subyacente, la expansión del PVC será reintentada continuamente hasta que el usuario o el administrador del cluster tomen alguna acción. Esto puede ser indeseable y por lo tanto Kubernetes proporciona los siguientes métodos de recuperación de tales fallos. {{< tabs name="recovery_methods" >}} {{% tab name="Manualmente con acceso de Administrador del Cluster" %}} Si la expansión del almacenamiento subyacente falla, el administrador del cluster puede recuperar manualmente el estado del Persistent Volume Claim (PVC) y cancelar las solicitudes de redimensionamiento. De lo contrario, las solicitudes de redimensionamiento son reintentadas continuamente por el controlador sin intervención del administrador. 1. Marca el PersistentVolume (PV) que está vinculado al PersistentVolumeClaim (PVC) con una política de reclamación `Retain`. 2. Elimina el PVC. Dado que el PV tiene una política de reclamación `Retain`, no perderemos ningún dato al recrear el PVC. 3. Elimina la entrada `claimRef` de las especificaciones del PV, para que un nuevo PVC pueda vincularse a él. Esto debería hacer que el PV esté `Available` (Disponible). 4. Vuelve a crear el PVC con un tamaño menor que el PV y establece el campo `volumeName` del PVC con el nombre del PV. Esto debería vincular el nuevo PVC al PV existente. 5. No olvides restaurar la política de reclamación del PV. {{% /tab %}} {{% tab name="By requesting expansion to smaller size" %}} {{% feature-state for_k8s_version="v1.23" state="alpha" %}} {{< note >}} La recuperación de la expansión fallida de PVC por parte de los usuarios está disponible como una característica alfa desde Kubernetes 1.23. La funcionalidad `RecoverVolumeExpansionFailure` debe estar habilitada para que esta característica funcione. Consulta la documentación de [puertas de características](/docs/reference/command-line-tools-reference/feature-gates/) para más información. {{< /note >}} Si las puertas de características `RecoverVolumeExpansionFailure` están habilitadas en tu cluster, y la expansión ha fallado para un PVC, puedes intentar nuevamente la expansión con un tamaño menor al valor previamente solicitado. Para solicitar un nuevo intento de expansión con un tamaño propuesto menor, edita `.spec.resources` para ese PVC y elige un valor que sea menor al valor que intentaste previamente. Esto es útil si la expansión a un valor más alto no tuvo éxito debido a una restricción de capacidad. Si eso ha ocurrido, o sospechas que podría haber ocurrido, puedes intentar nuevamente la expansión especificando un tamaño que esté dentro de los límites de capacidad del proveedor de almacenamiento subyacente. Puedes monitorear el estado de la operación de redimensionamiento observando `.status.allocatedResourceStatuses` y los eventos en el PVC. Ten en cuenta que, aunque puedes especificar una cantidad menor de almacenamiento que la solicitada anteriormente, el nuevo valor aún debe ser mayor que `.status.capacity`. Kubernetes no admite reducir un PVC a menos de su tamaño actual. {{% /tab %}} {{% /tabs %}} ## Tipos de Persistent Volumes Los tipos de PersistentVolume se implementan como plugins. Actualmente, Kubernetes admite los siguientes plugins: - [`csi`](/docs/concepts/storage/volumes/#csi) - Interfaz de Almacenamiento de Contenedores (CSI) - [`fc`](/docs/concepts/storage/volumes/#fc) - Almacenamiento de Canal de Fibra (FC) - [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - Volumen HostPath (solo para pruebas en un único nodo; NO FUNCIONARÁ en un clúster multinodo; considera usar el volumen `local` en su lugar) - [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI sobre IP) almacenamiento - [`local`](/docs/concepts/storage/volumes/#local) - dispositivos de almacenamiento locales montados en los nodos. - [`nfs`](/docs/concepts/storage/volumes/#nfs) - Almacenamiento del Sistema de Archivos de Red (NFS) Los siguientes tipos de PersistentVolume están obsoletos. Esto significa que el soporte aún está disponible, pero se eliminará en una futura versión de Kubernetes. - [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File (**obsoleto** en v1.21) - [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume (**obsoleto** en v1.23) - [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Volumen Portworx (**obsoleto** en v1.25) - [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - Volumen VMDK de vSphere (**obsoleto** en v1.19) - [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - Volumen CephFS (**obsoleto** en v1.28) - [`rbd`](/docs/concepts/storage/volumes/#rbd) - Dispositivo de Bloque Rados (RBD) (**obsoleto** en v1.28) Versiones anteriores de Kubernetes también soportaban los siguientes tipos de PersistentVolume integrados: - [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) (**no disponible** en v1.27) - [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Disco Azure (**no disponible** en v1.27) - [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (almacenamiento en bloque de OpenStack) (**no disponible** en v1.26) - `photonPersistentDisk` - Disco persistente del controlador Photon. (**no disponible** a partir de v1.15) - `scaleIO` - Volumen ScaleIO. (**no disponible** a partir de v1.21) - `flocker` - Almacenamiento Flocker. (**no disponible** a partir de v1.25) - `quobyte` - Volumen Quobyte. (**no disponible** a partir de v1.25) - `storageos` - Volumen StorageOS. (**no disponible** a partir de v1.25) ## Volúmenes Persistentes Cada PV contiene una especificación y un estado, que corresponden a la especificación y el estado del volumen. El nombre de un objeto PersistentVolume debe ser un válido [nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2 ``` {{< note >}} Es posible que se requieran programas auxiliares relacionados con el tipo de volumen para el uso de un PersistentVolume dentro de un clúster. En este ejemplo, el PersistentVolume es de tipo NFS y se requiere el programa auxiliar /sbin/mount.nfs para admitir el montaje de sistemas de archivos NFS. {{< /note >}} ### Capacidad Por lo general, un PV tendrá una capacidad de almacenamiento específica. Esto se establece utilizando el atributo `capacity` del PV. Lea el término del glosario [Cantidad](/docs/reference/glossary/?all=true#term-quantity) para comprender las unidades esperadas por `capacity`. Actualmente, el tamaño de almacenamiento es el único recurso que se puede establecer o solicitar. En el futuro, los atributos adicionales pueden incluir IOPS, throughput, etc. ### Modo de Volumen {{< feature-state for_k8s_version="v1.18" state="stable" >}} Kubernetes admite dos `volumeModes` (modos de volumen) para PersistentVolumes: `Filesystem` y `Block` (Sistema de archivos y Bloque). `volumeMode` es un parámetro opcional de la API. `Filesystem` es el modo predeterminado que se utiliza cuando se omite el parámetro `volumeMode`. Un volumen con `volumeMode: Filesystem` se _monta_ en Pods en un directorio. Si el volumen está respaldado por un dispositivo de bloque y el dispositivo está vacío, Kubernetes crea un sistema de archivos en el dispositivo antes de montarlo por primera vez. Puedes establecer el valor de `volumeMode` en `Block` para utilizar un volumen como un dispositivo de bloque sin formato. Este tipo de volumen se presenta en un Pod como un dispositivo de bloque, sin ningún sistema de archivos en él. Este modo es útil para proporcionar al Pod la forma más rápida posible de acceder a un volumen, sin ninguna capa de sistema de archivos entre el Pod y el volumen. Por otro lado, la aplicación que se ejecuta en el Pod debe saber cómo manejar un dispositivo de bloque sin formato. Consulta [Soporte para Volumen de Bloque sin Formato](#soporte-para-volumen-de-bloque-sin-formato) para ver un ejemplo de cómo usar un volumen con `volumeMode: Block` en un Pod. ### Modos de Acceso Un PersistentVolume puede montarse en un host de cualquier manera compatible con el proveedor de recursos. Como se muestra en la tabla a continuación, los proveedores tendrán diferentes capacidades y los modos de acceso de cada PV se establecerán en los modos específicos admitidos por ese volumen en particular. Por ejemplo, NFS puede admitir múltiples clientes de lectura/escritura, pero un PV de NFS específico podría exportarse en el servidor como de solo lectura. Cada PV tiene su propio conjunto de modos de acceso que describen las capacidades específicas de ese PV en particular. Los modos de acceso son: `ReadWriteOnce` : el volumen puede montarse como lectura-escritura por un solo nodo. El modo de acceso ReadWriteOnce aún puede permitir que varios pods accedan al volumen cuando los pods se ejecutan en el mismo nodo. Para el acceso de un solo pod, consulta ReadWriteOncePod. `ReadOnlyMany` : el volumen puede montarse como solo lectura por muchos nodos. `ReadWriteMany` : el volumen puede montarse como lectura-escritura por muchos nodos. `ReadWriteOncePod` : {{< feature-state for_k8s_version="v1.29" state="stable" >}} el volumen puede montarse como lectura-escritura por un solo Pod. Utiliza el modo de acceso ReadWriteOncePod si deseas garantizar que solo un pod en todo el clúster pueda leer ese PVC o escribir en él. {{< note >}} El modo de acceso `ReadWriteOncePod` solo es compatible con los volúmenes {{< glossary_tooltip text="CSI" term_id="csi" >}} y Kubernetes versión 1.22+. Para utilizar esta función, deberás actualizar los siguientes [CSI sidecars](https://kubernetes-csi.github.io/docs/sidecar-containers.html) a estas versiones o superiores: - [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) - [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) - [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) {{< /note >}} En la línea de comandos (CLI), los modos de acceso se abrevian de la siguiente manera: - RWO - ReadWriteOnce (Lectura/Escritura para Uno) - ROX - ReadOnlyMany (Solo Lectura para Muchos) - RWX - ReadWriteMany (Lectura/Escritura para Muchos) - RWOP - ReadWriteOncePod (Lectura/Escritura para Uno por Pod) {{< note >}} Kubernetes utiliza modos de acceso de volumen para hacer coincidir las solicitudes de PersistentVolumeClaims y los PersistentVolumes. En algunos casos, los modos de acceso de volumen también restringen dónde se puede montar el PersistentVolume. Los modos de acceso de volumen **no** imponen protección contra escritura una vez que el almacenamiento se ha montado. Incluso si se especifican los modos de acceso como ReadWriteOnce, ReadOnlyMany o ReadWriteMany, no establecen ninguna restricción en el volumen. Por ejemplo, incluso si se crea un PersistentVolume como ReadOnlyMany, no garantiza que sea de solo lectura. Si los modos de acceso se especifican como ReadWriteOncePod, el volumen está restringido y solo se puede montar en un único Pod. {{< /note >}} > **¡Importante!** Un volumen solo puede montarse utilizando un modo de acceso a la vez, incluso si admite varios modos. | Volume Plugin  |     ReadWriteOnce     |     ReadOnlyMany      |           ReadWriteMany            | ReadWriteOncePod      | | :------------- | :-------------------: | :-------------------: | :--------------------------------: | --------------------- | --- | | AzureFile      |       ✓        |       ✓        |              ✓              | -                     | | CephFS         |       ✓        |       ✓        |              ✓              | -                     | | CSI            | depends on the driver | depends on the driver |       depends on the driver        | depends on the driver | | FC             |       ✓        |       ✓        |                 -                  | -                     | | FlexVolume     |       ✓        |       ✓        |       depends on the driver        | -                     | | HostPath       |       ✓        |           -           |                 -                  | -                     | | iSCSI          |       ✓        |       ✓        |                 -                  | -                     | | NFS            |       ✓        |       ✓        |              ✓              | -                     | | RBD            |       ✓        |       ✓        |                 -                  | -                     | | VsphereVolume  |       ✓        |           -           | - (works when Pods are collocated) | -                     | | PortworxVolume |       ✓        |           -           |              ✓              | -                     | -   | ### Clase Un PV puede tener una clase, que se especifica configurando el atributo `storageClassName` con el nombre de una [StorageClass](/docs/concepts/storage/storage-classes/). Un PV de una clase particular solo puede vincularse a PVC que soliciten esa clase. Un PV sin `storageClassName` no tiene clase y solo puede vincularse a PVC que no soliciten una clase en particular. En el pasado, en lugar del atributo `storageClassName`, se utilizaba la anotación `volume.beta.kubernetes.io/storage-class`. Esta anotación todavía funciona; sin embargo, quedará completamente en desuso en una versión futura de Kubernetes. ### Política de Reclamación Las políticas de reclamación actuales son: - Retain (Retener) -- reclamación manual - Recycle (Reciclar) -- limpieza básica (`rm -rf /elvolumen/*`) - Delete (Eliminar) -- eliminar el volumen Para Kubernetes {{< skew currentVersion >}}, solo los tipos de volumen `nfs` y `hostPath` admiten el reciclaje. ### Opciones de Montaje Un administrador de Kubernetes puede especificar opciones de montaje adicionales cuando se monta un Persistent Volume en un nodo. {{< note >}} No todos los tipos de Persistent Volumes admiten opciones de montaje. {{< /note >}} Los siguientes tipos de volumen admiten opciones de montaje: - `azureFile` - `cephfs` (**desaconsejado** en v1.28) - `cinder` (**desaconsejado** en v1.18) - `iscsi` - `nfs` - `rbd` (**desaconsejado** en v1.28) - `vsphereVolume` Las opciones de montaje no se validan. Si una opción de montaje es inválida, el montaje falla. En el pasado, en lugar del atributo `mountOptions`, se utilizaba la anotación `volume.beta.kubernetes.io/mount-options`. Esta anotación todavía funciona; sin embargo, quedará completamente en desuso en una versión futura de Kubernetes. Se recomienda utilizar el atributo `mountOptions` para especificar las opciones de montaje en lugar de la anotación. ### Afinidad de Nodos {{< note >}} Para la mayoría de los tipos de volumen, no es necesario establecer este campo. Debes establecer esto explícitamente para los volúmenes [locales](/docs/concepts/storage/volumes/#local). {{< /note >}} Un PV puede especificar la afinidad de nodos para definir restricciones que limiten desde qué nodos se puede acceder a este volumen. Los Pods que utilizan un PV solo se programarán en nodos seleccionados por la afinidad de nodos. Para especificar la afinidad de nodos, configura `nodeAffinity` en `.spec` de un PV. La referencia de API de [PersistentVolume](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) tiene más detalles sobre este campo. ### Fase Un PersistentVolume estará en una de las siguientes fases: `Available` (Disponible) : un recurso gratuito que aún no está vinculado a una solicitud `Bound` (Vinculado) : el volumen está vinculado a una solicitud `Released` (Liberado) : la solicitud ha sido eliminada, pero el recurso de almacenamiento asociado aún no ha sido reclamado por el clúster `Failed` (Fallido) : el volumen ha fallado en su proceso de reclamación (automatizada) Puedes ver el nombre de la PVC vinculada al PV utilizando `kubectl describe persistentvolume <nombre>`. #### Marca de tiempo de transición de fase {{< feature-state for_k8s_version="v1.29" state="beta" >}} El campo `.status` de un PersistentVolume puede incluir un campo `lastPhaseTransitionTime` en versión alfa. Este campo registra la marca de tiempo de la última transición de fase del volumen. Para volúmenes recién creados, la fase se establece en `Pending` (Pendiente) y `lastPhaseTransitionTime` se establece en el tiempo actual. {{< note >}} Debes habilitar la [característica de puerta](/docs/reference/command-line-tools-reference/feature-gates/) `PersistentVolumeLastPhaseTransitionTime` para poder usar o ver el campo `lastPhaseTransitionTime`. {{< /note >}} ## PersistentVolumeClaims Cada PVC contiene un spec (especificación) y un status (estado), que es la especificación y el estado de la solicitud. El nombre de un objeto PersistentVolumeClaim debe ser un [nombre de subdominio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - { key: environment, operator: In, values: [dev] } ``` ### Modos de Acceso Las solicitudes utilizan [las mismas convenciones que los volúmenes](#access-modes) al solicitar almacenamiento con modos de acceso específicos. ### Modos de Volumen Las solicitudes utilizan [la misma convención que los volúmenes](#volume-mode) para indicar el consumo del volumen como un sistema de archivos o un dispositivo de bloque. ### Recursos Las solicitudes, al igual que los Pods, pueden solicitar cantidades específicas de un recurso. En este caso, la solicitud es para almacenamiento. El mismo [modelo de recurso](https://git.k8s.io/design-proposals-archive/scheduling/resources.md) se aplica tanto a los volúmenes como a las solicitudes. ### Selector Las solicitudes pueden especificar un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para filtrar aún más el conjunto de volúmenes. Solo los volúmenes cuyas etiquetas coincidan con el selector pueden vincularse a la solicitud. El selector puede constar de dos campos: - `matchLabels` (coincidencia de etiquetas) - el volumen debe tener una etiqueta con este valor. - `matchExpressions` (expresiones de coincidencia) - una lista de requisitos especificados por clave, lista de valores y operador que relaciona la clave y los valores. Los operadores válidos incluyen In, NotIn, Exists y DoesNotExist. Todos los requisitos, tanto de `matchLabels` como de `matchExpressions`, se combinan mediante un operador AND: todos deben cumplirse para que haya coincidencia. ### Clase Una solicitud puede solicitar una clase en particular especificando el nombre de una [StorageClass](/docs/concepts/storage/storage-classes/) utilizando el atributo `storageClassName`. Solo los PV de la clase solicitada, es decir, aquellos con el mismo `storageClassName` que el PVC, pueden vincularse al PVC. Las PVC no necesariamente tienen que solicitar una clase. Una PVC con su `storageClassName` configurado igual a `""` siempre se interpreta como una solicitud de un PV sin clase, por lo que solo puede vincularse a PV sin clase (sin anotación o con `""` configurado). Una PVC sin `storageClassName` no es exactamente lo mismo y se trata de manera diferente por parte del clúster, dependiendo de si el plugin de admisión [`DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) está activado. - Si el plugin de admisión está activado, el administrador puede especificar una StorageClass predeterminada. Todas las PVC que no tengan `storageClassName` solo podrán vincularse a los PV de esa clase predeterminada. La especificación de una StorageClass predeterminada se realiza configurando la anotación `storageclass.kubernetes.io/is-default-class` igual a `true` en un objeto StorageClass. Si el administrador no especifica una predeterminada, el clúster responderá a la creación de PVC como si el plugin de admisión estuviera desactivado. Si se especifican más de una StorageClass predeterminada, la más nueva se utilizará cuando se provisione dinámicamente la PVC. - Si el plugin de admisión está desactivado, no existe una noción de una StorageClass predeterminada. Todas las PVC que tengan `storageClassName` configurado como `""` solo podrán vincularse a los PV que también tengan `storageClassName` configurado como `""`. Sin embargo, las PVC sin `storageClassName` pueden actualizarse más adelante una vez que esté disponible la StorageClass predeterminada. Si la PVC se actualiza, ya no se vinculará a los PV que tengan `storageClassName` configurado como `""`. Consulta [asignación retroactiva de StorageClass predeterminada](#retroactive-default-storageclass-assignment) para obtener más detalles. Según el método de instalación, el administrador puede implementar una StorageClass predeterminada en un clúster de Kubernetes mediante el administrador de complementos durante la instalación. Cuando una PVC especifica un `selector` además de solicitar una StorageClass, los requisitos se combinan mediante una operación AND: solo se puede vincular un PV de la clase solicitada y con las etiquetas solicitadas a la PVC. {{< note >}} Actualmente, una PVC con un `selector` no vacío no puede tener un PV provisionado dinámicamente para ella. {{< /note >}} En el pasado, en lugar del atributo `storageClassName`, se utilizaba la anotación `volume.beta.kubernetes.io/storage-class`. Esta anotación todavía funciona; sin embargo, no será compatible en futuras versiones de Kubernetes. Se recomienda utilizar el atributo `storageClassName` en su lugar. #### Asignación retroactiva de StorageClass predeterminada {{< feature-state for_k8s_version="v1.29" state="stable" >}} Puedes crear una PersistentVolumeClaim sin especificar un `storageClassName` para la nueva PVC, incluso cuando no exista una StorageClass predeterminada en tu clúster. En este caso, la nueva PVC se crea tal como la definiste, y el `storageClassName` de esa PVC permanece sin configurar hasta que esté disponible la predeterminada. Cuando está disponible una StorageClass predeterminada, el plano de control identifica cualquier PVC existente sin `storageClassName`. Para las PVC que tienen un valor vacío para `storageClassName` o que no tienen esta clave, el plano de control actualiza esas PVC para establecer `storageClassName` de acuerdo con la nueva StorageClass predeterminada. Si tienes una PVC existente donde `storageClassName` es `""`, y configuras una StorageClass predeterminada, entonces esta PVC no se actualizará. Para seguir vinculando a PV con `storageClassName` configurado como `""` (mientras existe una StorageClass predeterminada), debes establecer el `storageClassName` de la PVC asociada en `""`. Este comportamiento ayuda a los administradores a cambiar la StorageClass predeterminada eliminando primero la antigua y luego creando o configurando otra. Este breve período en el que no hay una predeterminada hace que las PVC creadas en ese momento sin `storageClassName` no tengan ninguna predeterminada, pero debido a la asignación retroactiva de la StorageClass predeterminada, esta forma de cambiar las predeterminadas es segura. ## Solicitudes como Volúmenes Los Pods acceden al almacenamiento utilizando la solicitud como un volumen. Las solicitudes deben existir en el mismo espacio de nombres (namespace) que el Pod que utiliza la solicitud. El clúster encuentra la solicitud en el espacio de nombres del Pod y la utiliza para obtener el PersistentVolume que respalda la solicitud. Luego, el volumen se monta en el host y dentro del Pod. ```yaml apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim ``` ### Una Nota sobre Espacios de Nombres Las vinculaciones de PersistentVolumes son exclusivas y, dado que las PersistentVolumeClaims son objetos con espacio de nombres, montar solicitudes con modos "Many" (`ROX`, `RWX`) solo es posible dentro de un mismo espacio de nombres (namespace). ### Los PersistentVolumes de tipo `hostPath` Los PersistentVolumes de tipo `hostPath` utilizan un archivo o directorio en el nodo para emular almacenamiento conectado a la red. Consulta [un ejemplo de un volumen de tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). ## Soporte para Volúmenes en Bloque sin Procesar {{< feature-state for_k8s_version="v1.29" state="stable" >}} Los siguientes complementos de volumen admiten volúmenes en bloque sin procesar, incluida la provisión dinámica cuando corresponda: - CSI - FC (Fibre Channel) - iSCSI - Volumen local - OpenStack Cinder - RBD (desaconsejado) - RBD (Ceph Block Device; desaconsejado) - VsphereVolume ### PersistentVolume que Utiliza un Volumen en Bloque sin Procesar {#persistent-volume-using-a-raw-block-volume} ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: block-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce volumeMode: Block persistentVolumeReclaimPolicy: Retain fc: targetWWNs: ["50060e801049cfd1"] lun: 0 readOnly: false ``` ### PersistentVolumeClaim Solicitando un Volumen en Bloque sin Procesar {#persistent-volume-claim-requesting-a-raw-block-volume} ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 10Gi ``` ### Especificación de Pod Agregando la Ruta del Dispositivo en Bloque sin Procesar en el Contenedor ```yaml apiVersion: v1 kind: Pod metadata: name: pod-with-block-volume spec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: ["tail -f /dev/null"] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim: claimName: block-pvc ``` {{< note >}} Cuando agregas un dispositivo en bloque sin procesar para un Pod, especificas la ruta del dispositivo en el contenedor en lugar de una ruta de montaje. {{< /note >}} ### Vinculación de Volúmenes en Bloque Si un usuario solicita un volumen en bloque sin procesar indicándolo mediante el campo `volumeMode` en la especificación de PersistentVolumeClaim, las reglas de vinculación difieren ligeramente de versiones anteriores que no consideraban este modo como parte de la especificación. A continuación, se muestra una tabla de las posibles combinaciones que el usuario y el administrador pueden especificar para solicitar un dispositivo en bloque sin procesar. La tabla indica si el volumen se vinculará o no dadas las combinaciones: Matriz de vinculación de volumen para volúmenes provisionados estáticamente: | PV volumeMode | PVC volumeMode |  Result | | ------------- | :------------: | ------: | | unspecified   |  unspecified   |    BIND | | unspecified   |     Block      | NO BIND | | unspecified   |   Filesystem   |    BIND | | Block         |  unspecified   | NO BIND | | Block         |     Block      |    BIND | | Block         |   Filesystem   | NO BIND | | Filesystem    |   Filesystem   |    BIND | | Filesystem    |     Block      | NO BIND | | Filesystem    |  unspecified   |    BIND | {{< note >}} Solo se admiten volúmenes provisionados estáticamente en la versión alfa. Los administradores deben tener en cuenta estos valores al trabajar con dispositivos en bloque sin procesar. {{< /note >}} ## Soporte para Instantáneas de Volúmenes y Restauración de Volúmenes desde Instantáneas {{< feature-state for_k8s_version="v1.29" state="stable" >}} Las instantáneas de volúmenes solo admiten los complementos de volumen CSI fuera del árbol. Para obtener más detalles, consulta [Instantáneas de Volúmenes](/docs/concepts/storage/volume-snapshots/). Los complementos de volumen dentro del árbol están obsoletos. Puedes obtener información sobre los complementos de volumen obsoletos en el [FAQ de Complementos de Volumen](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). ### Crear una PersistentVolumeClaim desde una Instantánea de Volumen {#create-persistent-volume-claim-from-volume-snapshot} ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: restore-pvc spec: storageClassName: csi-hostpath-sc dataSource: name: new-snapshot-test kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` ## Clonación de Volúmenes [Clonación de Volúmenes](/docs/concepts/storage/volume-pvc-datasource/) solo está disponible para complementos de volumen CSI. ### Crear una PersistentVolumeClaim desde una PVC existente {#create-persistent-volume-claim-from-an-existing-pvc} ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cloned-pvc spec: storageClassName: my-csi-plugin dataSource: name: existing-src-pvc-name kind: PersistentVolumeClaim accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` ## Pobladores de Volúmenes y Fuentes de Datos {{< feature-state for_k8s_version="v1.29" state="beta" >}} Kubernetes admite pobladores de volúmenes personalizados. Para utilizar pobladores de volúmenes personalizados, debes habilitar la característica `AnyVolumeDataSource` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para el kube-apiserver y kube-controller-manager. Los pobladores de volúmenes aprovechan un campo de especificación de PVC llamado `dataSourceRef`. A diferencia del campo `dataSource`, que solo puede contener una referencia a otra PersistentVolumeClaim o a un VolumeSnapshot, el campo `dataSourceRef` puede contener una referencia a cualquier objeto en el mismo espacio de nombres, excepto los objetos principales que no sean PVC. Para los clústeres que tienen habilitada la característica, se prefiere el uso de `dataSourceRef` en lugar de `dataSource`. ## Fuentes de Datos entre Espacios de Nombres {{< feature-state for_k8s_version="v1.26" state="alpha" >}} Kubernetes admite fuentes de datos de volúmenes entre espacios de nombres. Para utilizar fuentes de datos de volúmenes entre espacios de nombres, debes habilitar las características `AnyVolumeDataSource` y `CrossNamespaceVolumeDataSource` [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) para el kube-apiserver y kube-controller-manager. Además, debes habilitar la característica `CrossNamespaceVolumeDataSource` para el csi-provisioner. Al habilitar la característica `CrossNamespaceVolumeDataSource`, puedes especificar un espacio de nombres en el campo dataSourceRef. {{< note >}} Cuando especificas un espacio de nombres para una fuente de datos de volumen, Kubernetes verifica la existencia de un ReferenceGrant en el otro espacio de nombres antes de aceptar la referencia. ReferenceGrant forma parte de las API de extensiones de `gateway.networking.k8s.io`. Consulta [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) en la documentación de la API de Gateway para obtener detalles. Esto significa que debes extender tu clúster de Kubernetes con al menos ReferenceGrant de la API de Gateway antes de poder utilizar este mecanismo. {{< /note >}} ## Las referencias a fuentes de datos El campo `dataSourceRef` se comporta de manera casi idéntica al campo `dataSource`. Si se especifica uno mientras que el otro no, el servidor de la API asignará el mismo valor a ambos campos. Ninguno de los campos puede cambiarse después de su creación, y cualquier intento de especificar valores diferentes para los dos campos resultará en un error de validación. Por lo tanto, los dos campos siempre tendrán el mismo contenido. Hay dos diferencias importantes entre el campo `dataSourceRef` y el campo `dataSource` que los usuarios deben tener en cuenta: - El campo `dataSource` ignora los valores no válidos (como si el campo estuviera en blanco), mientras que el campo `dataSourceRef` nunca ignora los valores y generará un error si se utiliza un valor no válido. Los valores no válidos son cualquier objeto central (objetos sin apiGroup) excepto PVCs. - El campo `dataSourceRef` puede contener diferentes tipos de objetos, mientras que el campo `dataSource` solo permite PVCs y VolumeSnapshots. Cuando se habilita la característica `CrossNamespaceVolumeDataSource`, existen diferencias adicionales: - El campo `dataSource` solo permite objetos locales, mientras que el campo `dataSourceRef` permite objetos en cualquier espacio de nombres. - Cuando se especifica un espacio de nombres, `dataSource` y `dataSourceRef` no están sincronizados. Los usuarios siempre deben utilizar `dataSourceRef` en clústeres que tengan habilitada la puerta de enlace de características y recurrir a `dataSource` en clústeres que no la tengan habilitada. No es necesario mirar ambos campos bajo ninguna circunstancia. Los valores duplicados con semántica ligeramente diferente existen solo por compatibilidad con versiones anteriores. En particular, una mezcla de controladores más antiguos y más nuevos pueden interoperar porque los campos son iguales. ### Uso de pobladores de volúmenes Los pobladores de volúmenes son controladores que pueden crear volúmenes no vacíos, donde el contenido del volumen es determinado por un Recurso Personalizado. Los usuarios crean un volumen poblado haciendo referencia a un Recurso Personalizado utilizando el campo `dataSourceRef`: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: populated-pvc spec: dataSourceRef: name: example-name kind: ExampleDataSource apiGroup: example.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` Dado que los pobladores de volúmenes son componentes externos, los intentos de crear una PVC que los utilice pueden fallar si no se han instalado todos los componentes correctos. Los controladores externos deben generar eventos en la PVC para proporcionar retroalimentación sobre el estado de la creación, incluyendo advertencias si la PVC no puede ser creada debido a la falta de algún componente necesario. Esto ayuda a los usuarios a comprender por qué la creación de la PVC ha fallado y qué componentes faltan para que funcione correctamente. Puedes instalar el controlador [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) en tu clúster. Este controlador genera eventos de advertencia en una PVC en caso de que no haya ningún poblador registrado para manejar ese tipo de fuente de datos. Cuando se instala un poblador adecuado para una PVC, es responsabilidad de ese controlador de poblador informar sobre eventos relacionados con la creación del volumen y problemas durante el proceso. Esto proporciona información útil para los usuarios y administradores del clúster sobre el estado y los problemas relacionados con las PVC que utilizan pobladores de volúmenes. ### Uso de una fuente de datos de volumen entre espacios de nombres {{< feature-state for_k8s_version="v1.26" state="alpha" >}} Crea un ReferenceGrant para permitir que el propietario del espacio de nombres acepte la referencia. Define un volumen poblado especificando una fuente de datos de volumen entre espacios de nombres utilizando el campo `dataSourceRef`. Debes tener un ReferenceGrant válido en el espacio de nombres de origen previamente: ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: allow-ns1-pvc namespace: default spec: from: - group: "" kind: PersistentVolumeClaim namespace: ns1 to: - group: snapshot.storage.k8s.io kind: VolumeSnapshot name: new-snapshot-demo ``` ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: ns1 spec: storageClassName: example accessModes: - ReadWriteOnce resources: requests: storage: 1Gi dataSourceRef: apiGroup: snapshot.storage.k8s.io kind: VolumeSnapshot name: new-snapshot-demo namespace: default volumeMode: Filesystem ``` ## Escribiendo configuraciones portátiles Si estás escribiendo plantillas de configuración o ejemplos que se ejecutarán en una amplia gama de clústeres y necesitas almacenamiento persistente, se recomienda que utilices el siguiente patrón: - Incluye objetos PersistentVolumeClaim en tu conjunto de configuración (junto con Despliegues, ConfigMaps, etc.). - No incluyas objetos PersistentVolume en la configuración, ya que el usuario que instala la configuración puede no tener permisos para crear PersistentVolumes. - Ofrece al usuario la opción de proporcionar un nombre de clase de almacenamiento al instanciar la plantilla. - Si el usuario proporciona un nombre de clase de almacenamiento, coloca ese valor en el campo `persistentVolumeClaim.storageClassName`. Esto hará que la PVC coincida con la clase de almacenamiento correcta si el administrador del clúster ha habilitado las StorageClasses. - Si el usuario no proporciona un nombre de clase de almacenamiento, deja el campo `persistentVolumeClaim.storageClassName` como nulo. Esto hará que se provisione automáticamente un PV para el usuario con la StorageClass predeterminada en el clúster. Muchos entornos de clúster tienen una StorageClass predeterminada instalada, o los administradores pueden crear su propia StorageClass predeterminada. - En tus herramientas, observa las PVC que no se están enlazando después de algún tiempo y comunica esto al usuario, ya que esto puede indicar que el clúster no tiene soporte de almacenamiento dinámico (en cuyo caso el usuario debe crear un PV correspondiente) o que el clúster no tiene un sistema de almacenamiento (en cuyo caso el usuario no puede implementar configuraciones que requieran PVCs). ## {{% heading "whatsnext" %}} - Aprende más sobre [Cómo crear un PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). - Aprende más sobre [Cómo crear un PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). - Lee el [documento de diseño de almacenamiento persistente](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md). ### Referencias de API {#reference} Puedes encontrar información detallada sobre las APIs [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) y [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) en la documentación oficial de Kubernetes. Estos enlaces te llevarán a las páginas de referencia que describen las especificaciones y los campos de estas API, junto con ejemplos y ejercicios de uso. </ins>

This is a Feature Request What would you like to be Localize to Spanish Why is this needed There is no Spanish localization for this file. Comments /triage accepted /kind feature /language es /sig docs
This issue was created to be assigned to Could you add a comment here to assign this issue to you Edith, please?
Hi I would love to work on this translation.
/assign


Question: [弃用](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。 更多关于 CSI 制备器的详情，请参阅 [Kubernetes vSphere CSI 驱动](https://vsphere-csi-driver.sigs.k8s.io/) <del> 和 [vSphereVolume CSI 迁移](/zh-cn/docs/concepts/storage/volumes/#csi-migration-5)。 </del> <ins> 和 [vSphereVolume CSI 迁移](/zh-cn/docs/concepts/storage/volumes/#vsphere-csi-migration)。 </ins> <!-- #### CSI Provisioner {#vsphere-provisioner-csi}

stay In the page, the link at the text "vSphereVolume CSI " should be -csi-migration
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 zh
Are you still working on it?
I submitted PR to solve this issue and put you as the co-author.