 --- title: kube-controller-manager Configuration (v1alpha1) content_type: tool-reference package: kubecontrollermanager.config.k8s.io/v1alpha1 auto_generated: true ---  ## 资源类型  {#resource-types} - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration) - [LeaderMigrationConfiguration](#controllermanager-config-k8s-io-v1alpha1-LeaderMigrationConfiguration) - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration) ## `NodeControllerConfiguration`     {#NodeControllerConfiguration}  **出现在：** - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration)
  NodeControllerConfiguration 包含描述 NodeController 的元素。

字段	描述

ConcurrentNodeSyncs [必需]
 int32
  ConcurrentNodeSyncs 是并发执行以进行节点同步的工作程序的数量。

 ## `ServiceControllerConfiguration`     {#ServiceControllerConfiguration}  **出现在：** - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration) - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  ServiceControllerConfiguration 包含描述 ServiceController 的元素。

字段	描述

ConcurrentServiceSyncs [必需]
 int32
  concurrentServiceSyncs 是允许同时同步的服务数。 数量越大表示服务管理响应越快，但 CPU（和网络）负载也越高。

 ## `CloudControllerManagerConfiguration`     {#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration}
  CloudControllerManagerConfiguration 包含描述云控制器管理器的元素。

字段	描述

apiVersion
string	cloudcontrollermanager.config.k8s.io/v1alpha1

kind
string	CloudControllerManagerConfiguration

Generic [必需]
 GenericControllerManagerConfiguration
  Generic 包含通用控制器管理器的配置。

KubeCloudShared [必需]
 KubeCloudSharedConfiguration
  KubeCloudSharedConfiguration 保存被云控制器管理器和 kube-controller 管理器共享的相关特性的配置。

NodeController [必需]
 NodeControllerConfiguration
  NodeController 保存与节点控制器相关的特性的配置。

ServiceController [必需]
 ServiceControllerConfiguration
  ServiceControllerConfiguration 保存 ServiceController 相关的特性的配置。

NodeStatusUpdateFrequency [必需]
 meta/v1.Duration
  NodeStatusUpdateFrequency 是控制器更新节点状态的频率。

Webhook [必需]
 WebhookConfiguration
  Webhook 是云控制器管理器托管的 webhook 的配置。

 ## `CloudProviderConfiguration`     {#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudProviderConfiguration}  **出现在：** - [KubeCloudSharedConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-KubeCloudSharedConfiguration)
  CloudProviderConfiguration 包含有关云提供商的一些基本元素。

字段	描述

Name [必需]
 string
  Name 是云服务的提供商。

CloudConfigFile [必需]
 string
  cloudConfigFile 是云提供程序配置文件的路径。

 ## `KubeCloudSharedConfiguration`     {#cloudcontrollermanager-config-k8s-io-v1alpha1-KubeCloudSharedConfiguration}  **出现在：** - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration) - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  KubeCloudSharedConfiguration 包含 kube-controller 管理器和云控制器管理器共享的元素，但不包含通用配置。

字段	描述

CloudProvider [必需]
 CloudProviderConfiguration
  CloudProviderConfiguration 保存 CloudProvider 相关特性的配置。

ExternalCloudVolumePlugin [必需]
 string
  当 cloudProvider 为 "external" 时，externalCloudVolumePlugin 用于指定插件。 它目前被仓库内的云驱动用于处理 KCM 中的节点和卷控制。

UseServiceAccountCredentials [必需]
 bool
  useServiceAccountCredentials 指出控制器是否应使用独立的服务帐户凭据运行。

AllowUntaggedCloud [必需]
 bool
  使用未标记的云实例运行。

RouteReconciliationPeriod [必需]
 meta/v1.Duration
  routeReconciliationPeriod 是云驱动商为节点创建的路由的调和周期。

NodeMonitorPeriod [必需]
 meta/v1.Duration
  nodeMonitorPeriod 是 NodeController 同步 NodeStatus 的周期。

ClusterName [必需]
 string
  clusterName 是集群的实例前缀。

ClusterCIDR [必需]
 string
  clusterCIDR 是集群中 Pod CIDR 的范围。

AllocateNodeCIDRs [必需]
 bool
  AllocateNodeCIDRs 允许为 Pod 分配 CIDR， 如果 ConfigureCloudRoutes 为 true，则允许在对云驱动商设置 CIDR。

CIDRAllocatorType [必需]
 string
  CIDRAllocatorType 决定使用哪种类型的 Pod CIDR 分配器。

ConfigureCloudRoutes [必需]
 bool
  configureCloudRoutes 使通过 allocateNodeCIDRs 分配的 CIDR 能够在云提供商上配置。

NodeSyncPeriod [必需]
 meta/v1.Duration
  nodeSyncPeriod 从云平台同步节点的周期。 周期较长时，调用云平台的次数减少， 但向集群添加新节点可能会延迟。

 ## `WebhookConfiguration`     {#cloudcontrollermanager-config-k8s-io-v1alpha1-WebhookConfiguration}  **出现在：** - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration)
  WebhookConfiguration 包含与云控制器管理器托管的 webhook 相关的配置。

字段	描述

Webhooks [必需]
 []string
  Webhooks 是要启用或者禁用的 Webhook 的列表。 '*' 表示"所有默认启用的 webhook "， 'foo' 表示"启用 'foo'"， '-foo' 表示"禁用 'foo'"， 特定名称的首个项有效。

 ## `LeaderMigrationConfiguration`     {#controllermanager-config-k8s-io-v1alpha1-LeaderMigrationConfiguration}  **出现在：** - [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
  LeaderMigrationConfiguration 为所有迁移中的领导者锁提供了版本化配置。

字段	描述

apiVersion
string	controllermanager.config.k8s.io/v1alpha1

kind
string	LeaderMigrationConfiguration

leaderName [必需]
 string
  LeaderName 是保护迁移的领导者选举资源的名称，例如：1-20-KCM-to-1-21-CCM。

resourceLock [必需]
 string
  ResourceLock 表示将被用于加锁的资源对象类型， 应该是 "leases" 或者是 "endpoints"。

controllerLeaders [必需]
 []ControllerLeaderConfiguration
  ControllerLeaders 包含迁移领导者锁配置列表。

 ## `ControllerLeaderConfiguration`     {#controllermanager-config-k8s-io-v1alpha1-ControllerLeaderConfiguration}  **出现在：** - [LeaderMigrationConfiguration](#controllermanager-config-k8s-io-v1alpha1-LeaderMigrationConfiguration)
  ControllerLeaderConfiguration 提供迁移中领导者锁的配置。

字段	描述

name [必需]
 string
  Name 是正被迁移的控制器的名称，例如：service-controller、route-controller、cloud-node-controller 等等

component [必需]
 string
  Component 是控制器运行所处的组件的名称。 例如，kube-controller-manager、cloud-controller-manager 等。 或者 “*” 表示控制器可以在任何正在参与迁移的组件中运行。

 ## `GenericControllerManagerConfiguration`     {#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration}  **出现在：** - [CloudControllerManagerConfiguration](#cloudcontrollermanager-config-k8s-io-v1alpha1-CloudControllerManagerConfiguration) - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  GenericControllerManagerConfiguration 保存通用控制器管理器的配置。

字段	描述

Port [必需]
 int32
  port 是控制器管理器运行 HTTP 服务运行的端口。

Address [必需]
 string
  address 是提供服务所用的 IP 地址（所有接口设置为 0.0.0.0）。

MinResyncPeriod [必需]
 meta/v1.Duration
  minResyncPeriod 是反射器的重新同步周期；大小是在 minResyncPeriod 和 2*minResyncPeriod 范围内的随机数。

ClientConnection [必需]
 ClientConnectionConfiguration
  ClientConnection 指定代理服务器在与 API 服务器通信时使用的 kubeconfig 文件和客户端连接设置。

ControllerStartInterval [必需]
 meta/v1.Duration
  两次启动控制器管理器之间的间隔时间。

LeaderElection [必需]
 LeaderElectionConfiguration
  leaderElection 定义领导者选举客户端的配置。

Controllers [必需]
 []string
  Controllers 是要启用或者禁用的控制器列表。 '*' 表示"所有默认启用的控制器"， 'foo' 表示"启用 'foo'"， '-foo' 表示"禁用 'foo'"， 特定名称的首个项有效。

Debugging [必需]
 DebuggingConfiguration
  DebuggingConfiguration 保存调试相关特性的配置。

LeaderMigrationEnabled [必需]
 bool
  LeaderMigrationEnabled 指示是否应为控制器管理器启用领导者迁移（Leader Migration）。

LeaderMigration [必需]
 LeaderMigrationConfiguration
  LeaderMigration 保存领导者迁移的配置。

 ## `KubeControllerManagerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration}
  KubeControllerManagerConfiguration 包含描述 kube-controller 管理器的元素。

字段	描述

apiVersion
string	kubecontrollermanager.config.k8s.io/v1alpha1

kind
string	KubeControllerManagerConfiguration

Generic [必需]
 GenericControllerManagerConfiguration
  Generic 保存通用控制器管理器的配置。

KubeCloudShared [必需]
 KubeCloudSharedConfiguration
  KubeCloudSharedConfiguration 保存云控制器管理器和 kube-controller 管理器间共享的相关特性的配置。

AttachDetachController [必需]
 AttachDetachControllerConfiguration
  AttachDetachControllerConfiguration 包含 AttachDetachController 相关特性的配置。

CSRSigningController [必需]
 CSRSigningControllerConfiguration
  CSRSigningControllerConfiguration 包含 CSRSigningController 相关特性的配置。

DaemonSetController [必需]
 DaemonSetControllerConfiguration
  DaemonSetControllerConfiguration 包含 DaemonSetController 相关特性的配置。

DeploymentController [必需]
 DeploymentControllerConfiguration
  DeploymentControllerConfiguration 包含 DeploymentController 相关特性的配置。

StatefulSetController [必需]
 StatefulSetControllerConfiguration
  StatefulSetControllerConfiguration 包含 StatefulSetController 相关特性的配置。

DeprecatedController [必需]
 DeprecatedControllerConfiguration
  DeprecatedControllerConfiguration 包含一些已弃用的特性的配置。

EndpointController [必需]
 EndpointControllerConfiguration
  EndpointControllerConfiguration 包含 EndpointController 相关特性的配置。

EndpointSliceController [必需]
 EndpointSliceControllerConfiguration
  EndpointSliceControllerConfiguration 包含 EndpointSliceController 相关特性的配置。

EndpointSliceMirroringController [必需]
 EndpointSliceMirroringControllerConfiguration
  EndpointSliceMirroringControllerConfiguration 包含 EndpointSliceMirroringController 相关特性的配置。

EphemeralVolumeController [必需]
 EphemeralVolumeControllerConfiguration
  EphemeralVolumeControllerConfiguration 包含 EphemeralVolumeController 相关特性的配置。

GarbageCollectorController [必需]
 GarbageCollectorControllerConfiguration
  GarbageCollectorControllerConfiguration 包含 GarbageCollectorController 相关特性的配置。

HPAController [必需]
 HPAControllerConfiguration
  HPAControllerConfiguration 包含 HPAController 相关特性的配置。

JobController [必需]
 JobControllerConfiguration
  HPAControllerConfiguration 包含 JobController 相关特性的配置。

CronJobController [必需]
 CronJobControllerConfiguration
  CronJobControllerConfiguration 包含 CronJobController 相关特性的配置。

LegacySATokenCleaner [必需]
 LegacySATokenCleanerConfiguration
  LegacySATokenCleanerConfiguration 包含 LegacySATokenCleaner 相关特性的配置。

NamespaceController [必需]
 NamespaceControllerConfiguration
  NamespaceControllerConfiguration 包含 NamespaceController 相关特性的配置。

NodeIPAMController [必需]
 NodeIPAMControllerConfiguration
  NodeIPAMControllerConfiguration 包含 NodeIPAMController 相关特性的配置。

NodeLifecycleController [必需]
 NodeLifecycleControllerConfiguration
  NodeLifecycleControllerConfiguration 包含 NodeLifecycleController 相关特性的配置。

PersistentVolumeBinderController [必需]
 PersistentVolumeBinderControllerConfiguration
  PersistentVolumeBinderControllerConfiguration 包含 PersistentVolumeBinderController 相关特性的配置。

PodGCController [必需]
 PodGCControllerConfiguration
  PodGCControllerConfiguration 包含 PodGCController 相关特性的配置。

ReplicaSetController [必需]
 ReplicaSetControllerConfiguration
  ReplicaSetControllerConfiguration 包含 ReplicaSetController 相关特性的配置。

ReplicationController [必需]
 ReplicationControllerConfiguration
  ReplicationControllerConfiguration 包含 ReplicationController 相关特性的配置。

ResourceQuotaController [必需]
 ResourceQuotaControllerConfiguration
  ResourceQuotaControllerConfiguration 包含 ResourceQuotaController 相关特性的配置。

SAController [必需]
 SAControllerConfiguration
  SAControllerConfiguration 包含 ServiceAccountController 相关特性的配置。

ServiceController [必需]
 ServiceControllerConfiguration
  ServiceControllerConfiguration 包含 ServiceController 相关特性的配置。

TTLAfterFinishedController [必需]
 TTLAfterFinishedControllerConfiguration
  TTLAfterFinishedControllerConfiguration 包含 TTLAfterFinishedController 相关特性的配置。

ValidatingAdmissionPolicyStatusController [必需]
 ValidatingAdmissionPolicyStatusControllerConfiguration
  ValidatingAdmissionPolicyStatusControllerConfiguration 包含 ValidatingAdmissionPolicyStatusController 相关特性的配置。

 ## `AttachDetachControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-AttachDetachControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  AttachDetachControllerConfiguration 包含描述 AttachDetachController 的元素。

字段	描述

DisableAttachDetachReconcilerSync [必需]
 bool
  Reconciler 运行一个周期性循环，通过触发 attach/detach 操作来协调期望状态与实际状态。 此标志启用或禁用调和操作。默认为 false，即被启用的。

ReconcilerSyncLoopPeriod [必需]
 meta/v1.Duration
  ReconcilerSyncLoopPeriod 是调和器在连续执行同步状态的循环间，所等待的时间量。 默认为 5 秒。

 ## `CSRSigningConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-CSRSigningConfiguration}  **出现在：** - [CSRSigningControllerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-CSRSigningControllerConfiguration)
  CSRSigningConfiguration 保存有关特定 CSR 签名者的信息。

字段	描述

CertFile [必需]
 string
  certFile 是包含 PEM 编码的 X509 CA 证书的文件名，用于颁发证书。

KeyFile [必需]
 string
  keyFile 是包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名，用于颁发证书。

 ## `CSRSigningControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-CSRSigningControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  CSRSigningControllerConfiguration 包含描述 CSRSigningController 的元素。

字段	描述

ClusterSigningCertFile [必需]
 string
  clusterSigningCertFile 是包含 PEM 编码的 X509 CA 证书的文件名，该证书用于颁发集群范围的证书。

ClusterSigningKeyFile [必需]
 string
  clusterSigningCertFile 是包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名，用于颁发集群范围的证书。

KubeletServingSignerConfiguration [必需]
 CSRSigningConfiguration
  kubeletServingSignerConfiguration 保存用于为 kubernetes.io/kubelet-serving 签名者颁发证书的证书和密钥。

KubeletClientSignerConfiguration [必需]
 CSRSigningConfiguration
  kubeletClientSignerConfiguration 保存用于为 kubernetes.io/kube-apiserver-client-kubelet 颁发证书的证书和密钥。

KubeAPIServerClientSignerConfiguration [必需]
 CSRSigningConfiguration
  kubeAPIServerClientSignerConfiguration 保存用于为 kubernetes.io/kube-apiserver-client 颁发证书的证书和密钥。

LegacyUnknownSignerConfiguration [必需]
 CSRSigningConfiguration
  legacyUnknownSignerConfiguration 保存用于颁发 kubernetes.io/legacy-unknown 证书的证书和密钥。

ClusterSigningDuration [必需]
 meta/v1.Duration
  clusterSigningDuration 是签名证书的最长持续时间。 单个 CSRs 可以通过设置 spec.expirationSeconds 来请求有效期更短的证书。

 ## `CronJobControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-CronJobControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  CronJobControllerConfiguration 包含描述 CrongJob2Controller 的元素。

字段	描述

ConcurrentCronJobSyncs [必需]
 int32
  concurrentCronJobSyncs 是允许并发同步的 Job 对象的数量。 数量越大意味着 Job 响应越快，但 CPU（和网络）负载也越高。

 ## `DaemonSetControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-DaemonSetControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  DaemonSetControllerConfiguration 包含描述 DaemonSetController 的元素。

字段	描述

ConcurrentDaemonSetSyncs [必需]
 int32
  concurrentDaemonSetSyncs 是允许并发同步的 DaemonSet 对象的数量。 数目越大意味着 DaemonSet 响应越快，但 CPU（和网络）负载也越高。

 ## `DeploymentControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-DeploymentControllerConfiguration} **Appears in:** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  DeploymentControllerConfiguration 包含描述 DeploymentController 的元素。

字段	描述

ConcurrentDeploymentSyncs [必需]
 int32
  concurrentDeploymentSyncs 是允许并发同步的 Deployment 对象的数量。 数量越大意味着 Deployment 响应更越快，但 CPU（和网络）负载也越高。

 ## `DeprecatedControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-DeprecatedControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  DeprecatedControllerConfiguration 包含被弃用的元素。
 ## `EndpointControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-EndpointControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  EndpointControllerConfiguration 包含描述 EndpointController 的元素。

字段	描述

ConcurrentEndpointSyncs [必需]
 int32
  concurrentEndpointSyncs 是将并发执行的 Endpoints 同步操作的数量。 数字越大意味着 Endpoints 更新越快，但 CPU（和网络）负载也越高。

EndpointUpdatesBatchPeriod [必需]
 meta/v1.Duration
  EndpointUpdatesBatchPeriod 描述批量更新 Endpoints 的周期长度。 Pod 更改的处理将被延迟相同的时长，以便将它们与即将到来的更新连接起来，并减少 Endpoints 更新的总数。

 ## `EndpointSliceControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-EndpointSliceControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  EndpointSliceControllerConfiguration 包含描述 EndpointSliceController 的元素。

字段	描述

ConcurrentServiceEndpointSyncs [必需]
 int32
  concurrentServiceEndpointSyncs 是将并发完成的服务端点同步操作的数量。 数字越大意味着 EndpointSlice 更新越快，但 CPU（和网络）负载也越高。

MaxEndpointsPerSlice [必需]
 int32
  maxEndpointsPerSlice 是将添加到 EndpointSlice 的最大端点数。 每个切片的端点越多，端点切片就会更少、更大，但资源消耗就会更多。

EndpointUpdatesBatchPeriod [必需]
 meta/v1.Duration
  EndpointUpdatesBatchPeriod 描述批量更新 Endpoints 的周期长度。 Pod 更改的处理将被延迟相同的时长，以便将它们与即将到来的更新连接起来，并减少 Endpoints 更新的总数。

 ## `EndpointSliceMirroringControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-EndpointSliceMirroringControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  EndpointSliceMirroringControllerConfiguration 包含描述 EndpointSliceMirroringController 的元素。

字段	描述

MirroringConcurrentServiceEndpointSyncs [必需]
 int32
  mirroringConcurrentServiceEndpointSyncs 是将并发完成的服务端点同步操作的数量。 数字越大意味着 EndpointSlice 更新越快，但 CPU（和网络）负载也越高。

MirroringMaxEndpointsPerSubset [必需]
 int32
  mirroringMaxEndpointsPerSubset 是把 EndpointSubset 映射到 EndpointSlice 的端点数上限。

MirroringEndpointUpdatesBatchPeriod [必需]
 meta/v1.Duration
  mirroringEndpointUpdatesBatchPeriod 可用于批量更新 EndpointSlice。 所有由 EndpointSlice 更改触发的更新可能被延迟，延迟的时间长度上限为 “mirroringEndpointUpdatesBatchPeriod”。 如果同一 Endpoints 资源中的其他地址在此期间发生变化，它们将被合并到同一个 EndpointSlice 更新中以实现批处理。 默认值 0 表示 Endpoints 的每次更新都会触发一次 EndpointSlice 更新。

 ## `EphemeralVolumeControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-EphemeralVolumeControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  EphemeralVolumeControllerConfiguration 包含描述 EphemeralVolumeController 的元素。

字段	描述

ConcurrentEphemeralVolumeSyncs [必需]
 int32
  ConcurrentEphemeralVolumeSyncseSyncs 是并发执行的临时卷同步操作数量。 数字越大意味着临时卷更新越快，但 CPU（和网络）负载也越高。

 ## `GarbageCollectorControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-GarbageCollectorControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  GarbageCollectorControllerConfiguration 包含描述 GarbageCollectorController 的元素。

字段	描述

EnableGarbageCollector [必需]
 bool
  启用通用垃圾收集器。必须与 kube-apiserver 的相应标志同步。 警告：通用垃圾收集器是一个 Alpha 特性。

ConcurrentGCSyncs [必需]
 int32
  concurrentGCSyncs 是允许垃圾收集器并发同步的工作线程的数量。

GCIgnoredResources [必需]
 []GroupResource
  gcIgnoredResources 是垃圾收集应该忽略的 GroupResource 列表。

 ## `GroupResource`     {#kubecontrollermanager-config-k8s-io-v1alpha1-GroupResource}  **出现在：** - [GarbageCollectorControllerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-GarbageCollectorControllerConfiguration)
  GroupResource 描述组资源。

字段	描述

Group [必需]
 string
  group 是 GroupResource 的 group 部分。

Resource [必需]
 string
  resource 是 GroupResource 的 resource 部分。

 ## `HPAControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-HPAControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  HPAControllerConfiguration 包含描述 HPAController 的元素。

字段	描述

ConcurrentHorizontalPodAutoscalerSyncs [必需]
 int32
  ConcurrentHorizontalPodAutoscalerSyncs 是允许并发同步的 HPA 对象的数量。 数字越大意味着 HPA 处理响应越快，但 CPU（和网络）负载也越高。

HorizontalPodAutoscalerSyncPeriod [必需]
 meta/v1.Duration
  HorizontalPodAutoscalerSyncPeriod 是对 HPA 中 Pod 数量进行同步的周期。

HorizontalPodAutoscalerUpscaleForbiddenWindow [必需]
 meta/v1.Duration
  HorizontalPodAutoscalerUpscaleForbiddenWindow 是一个时间段，过了这一时间段才允许下一次扩容

HorizontalPodAutoscalerDownscaleStabilizationWindow [必需]
 meta/v1.Duration
  horizontalpodautoscalerdowncalstabilizationwindow 是一个自动缩放器要回顾的时段长度， 在所给时段内，自动缩放器不会按照建议执行任何缩容操作。

HorizontalPodAutoscalerDownscaleForbiddenWindow [必需]
 meta/v1.Duration
  HorizontalPodAutoscalerDownscaleForbiddenWindow 是一个时间段长度，过了此时间段才允许执行下一此缩容操作。

HorizontalPodAutoscalerTolerance [必需]
 float64
  HorizontalPodAutoscalerTolerance 是当资源用量表明需要扩容/缩容时的容忍度。

HorizontalPodAutoscalerCPUInitializationPeriod [必需]
 meta/v1.Duration
  HorizontalPodAutoscalerCPUInitializationPeriod 是 Pod 启动后可以跳过时间段，这段时间内部执行 CPU 采样。

HorizontalPodAutoscalerInitialReadinessDelay [必需]
 meta/v1.Duration
  HorizontalPodAutoscalerInitialReadinessDelay 是 Pod 启动后的一段时间， 在此期间，readiness 状态的变更被视为初次设置 readiness 状态。 这样做的唯一影响是，对于在此期间发生 readiness 状态变化但未准备好的 Pod，HPA 将忽略其 CPU 采样值。

 ## `JobControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-JobControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  JobControllerConfiguration 包含描述 JobController 的元素。

字段	描述

ConcurrentJobSyncs [必需]
 int32
  concurrentJobSyncs 是允许并发同步的 Job 对象的数量。 数字越大意味着 Job 响应越快，但 CPU（和网络）负载也越高。

 ## `LegacySATokenCleanerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-LegacySATokenCleanerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  LegacySATokenCleanerConfiguration 包含描述 LegacySATokenCleaner 的元素。

字段	描述

CleanUpPeriod [必需]
 meta/v1.Duration
  CleanUpPeriod 是自动生成的服务帐户令牌上次被使用以来的时长，超出此时长的令牌可被清理。

 ## `NamespaceControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-NamespaceControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  NamespaceControllerConfiguration 包含描述 NamespaceController 的元素。

字段	描述

NamespaceSyncPeriod [必需]
 meta/v1.Duration
  namespaceSyncPeriod 是对名字空间生命周期更新进行同步的周期。

ConcurrentNamespaceSyncs [必需]
 int32
  concurrentNamespaceSyncs 是允许并发同步的 Namespace 对象的数量。

 ## `NodeIPAMControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-NodeIPAMControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  NodeIPAMControllerConfiguration 包含描述 NodeIpamController 的元素。

字段	描述

ServiceCIDR [必需]
 string
  serviceCIDR 为集群中 Service 的 CIDR 范围。

SecondaryServiceCIDR [必需]
 string
  SecondaryServiceCIDR 为集群中 Service 的 CIDR 范围。此字段用于双栈集群。 SecondaryServiceCIDR 和 ServiceCIDR 的 IP 族不能相同。

NodeCIDRMaskSize [必需]
 int32
  NodeCIDRMaskSize 为集群中节点 CIDR 的掩码大小。

NodeCIDRMaskSizeIPv4 [必需]
 int32
  NodeCIDRMaskSizeIPv4 为双栈集群中节点 CIDR 的掩码大小。

NodeCIDRMaskSizeIPv6 [必需]
 int32
  NodeCIDRMaskSizeIPv6 为双栈集群中节点 CIDR 的掩码大小。

 ## `NodeLifecycleControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-NodeLifecycleControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  Nodelifecyclecontrolerconfiguration 包含描述 NodeLifecycleController 的元素。

字段	描述

NodeEvictionRate [必需]
 float32
  nodeEvictionRate 是在区域健康时，如果节点发生故障，每秒删除 Pod 的节点数。

SecondaryNodeEvictionRate [必需]
 float32
  secondaryNodeEvictionRate 是在区域不健康时，如果节点故障，每秒删除 Pod 的节点数。

NodeStartupGracePeriod [必需]
 meta/v1.Duration
  nodeStartupGracePeriod 是在将节点标记为不健康之前允许启动节点无响应的时长。

NodeMonitorGracePeriod [必需]
 meta/v1.Duration
  nodeMontiorGracePeriod 是在将运行中的节点标记为不健康之前允许其无响应的时长。 必须是 kubelet 的 nodeStatusUpdateFrequency 的 N 倍，其中 N 表示允许 kubelet 发布节点状态的重试次数。

PodEvictionTimeout [必需]
 meta/v1.Duration
  podEvictionTimeout 为删除故障节点上的 Pod 的宽限时间。

LargeClusterSizeThreshold [必需]
 int32
  对于规模小于或等于 largeClusterSizeThreshold 的集群，secondaryNodeEvictionRate 会被隐式覆盖，取值为 0。

UnhealthyZoneThreshold [必需]
 float32
  当区域中至少有 unhealthyZoneThreshold（不少于 3 个）的节点处于 NotReady 状态时， nodeEvctionRate 和 secondaryNodeEvictionRate 两个属性的判定逻辑会将区域视为不健康。

 ## `PersistentVolumeBinderControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-PersistentVolumeBinderControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  PersistentVolumeBinderControllerConfiguration 包含描述 PersistentVolumeBinderController 的元素。

字段	描述

PVClaimBinderSyncPeriod [必需]
 meta/v1.Duration
  pvClaimBinderSyncPeriod 用于同步 PV 和 PVC 的周期。

VolumeConfiguration [必需]
 VolumeConfiguration
  volumeConfiguration 包含卷相关特性的配置。

VolumeHostCIDRDenylist [必需]
 []string
  已弃用：VolumeHostCIDRDenylist 是一个不能被插件中控制器访问的 CIDR 列表。

VolumeHostAllowLocalLoopback [必需]
 bool
  已弃用：VolumeHostAllowLocalLoopback 表示是否应该允许插件使用本地回路主机地址（127.0.0.1 等）。

 ## `PersistentVolumeRecyclerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-PersistentVolumeRecyclerConfiguration}  **出现在：** - [VolumeConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-VolumeConfiguration)
  PersistentVolumeRecyclerConfiguration 包含描述持久卷插件的元素。

字段	描述

MaximumRetry [必需]
 int32
  maximumRetry 是当 PV 回收失败时，PV 回收器重试的次数。

MinimumTimeoutNFS [必需]
 int32
  minimumTimeoutNFS 是用于 NFS 回收器的，用于设置 Pod 的最小 ActiveDeadlineSeconds。

PodTemplateFilePathNFS [必需]
 string
  podTemplateFilePathNFS 是一个 Pod 定义文件的路径，该文件将被用作 NFS PV 卷回收模板。

IncrementTimeoutNFS [必需]
 int32
  incrementTimeoutNFS 提供给 NFS 清理器 Pod 的设置值，数据卷每增加 1 GiB， 则需要向 Pod 中的 activeDeadlineSeconds 参数增加这里所给的秒数。

PodTemplateFilePathHostPath [必需]
 string
  podTemplateFilePathHostPath 是一个 Pod 定义文件的路径，该文件将被作为 HostPath PV 卷回收模板。 此字段仅用于开发和测试场景，在多节点集群中无法正常工作。

MinimumTimeoutHostPath [必需]
 int32
  minimumTimeoutHostPath 是用于 HostPath 回收器 Pod 的 activeDeadlineSeconds 属性值下限。 此字段仅用于开发和测试场景，在多节点集群中无法正常工作。

IncrementTimeoutHostPath [必需]
 int32
  incrementTimeoutHostPath 是提供给 HostPath 清理器 Pod 的配置值， HostPath 卷的尺寸每增加 1 GiB，则需要为 Pod 的 activeDeadlineSeconds 属性增加这里所给的秒数。 回收器 Pod 的 activeDeadlineSeconds 属性值下限。

 ## `PodGCControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-PodGCControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  PodGCControllerConfiguration 包含描述 PodGCController 的元素。

字段	描述

TerminatedPodGCThreshold [必需]
 int32
  terminatedPodGCThreshold 是提供给回收已终止 Pod 的垃圾收集器的， 所设置的数字是在垃圾收集器开始删除某 Pod 之前可以存在的、已终止 Pod 的个数。 如果 <= 0，则禁用已终止的 Pod 垃圾收集器。

 ## `ReplicaSetControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-ReplicaSetControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  ReplicaSetControllerConfiguration 包含描述 ReplicaSetController 的元素。

字段	描述

ConcurrentRSSyncs [必需]
 int32
  concurrentRSSyncs 是允许并发同步的 ReplicaSet 的数量。 数量越大意味着副本管理响应越快，但 CPU（和网络）负载也越高。

 ## `ReplicationControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-ReplicationControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  ReplicationControllerConfiguration 包含描述 ReplicationController 的元素。

字段	描述

ConcurrentRCSyncs [必需]
 int32
  concurrentRCSyncs 是允许并发同步的 ReplicationController 数量。 数量越大意味着副本管理响应越快，但 CPU（和网络）负载也越高。

 ## `ResourceQuotaControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-ResourceQuotaControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  ResourceQuotaControllerConfiguration 包含描述 ResourceQuotaController 的元素。

字段	描述

ResourceQuotaSyncPeriod [必需]
 meta/v1.Duration
  resourceQuotaSyncPeriod 是系统中 Quota 使用状态的同步周期。

ConcurrentResourceQuotaSyncs [必需]
 int32
  concurrentResourceQuotaSyncs 是允许并发同步的 ResourcQuota 数目。 数量越大意味着配额管理响应越快，但 CPU（和网络）负载也越高。

 ## `SAControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-SAControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  SAControllerConfiguration 包含描述 ServiceAccountController 的元素。

字段	描述

ServiceAccountKeyFile [必需]
 string
  serviceAccountKeyFile 是包含 PEM 编码的用于签署服务帐户令牌的 RSA 私钥的文件名。

ConcurrentSATokenSyncs [必需]
 int32
  concurrentSATokenSyncs 是将并发完成的服务帐户令牌同步操作的数量。

RootCAFile [必需]
 string
  rootCAFile 是根证书颁发机构将被包含在 ServiceAccount 的令牌 Secret 中。 所提供的数据必须是一个有效的 PEM 编码的 CA 包。

 ## `StatefulSetControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-StatefulSetControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  StatefulSetControllerConfiguration 包含描述 StatefulSetController 的元素。

字段	描述

ConcurrentStatefulSetSyncs [必需]
 int32
  concurrentStatefulSetSyncs 是允许并发同步的 StatefulSet 对象的数量。 数字越大意味着 StatefulSet 响应越快，但 CPU（和网络）负载也越高。

 ## `TTLAfterFinishedControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-TTLAfterFinishedControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  TTLAfterFinishedControllerConfiguration 包含描述 TTLAfterFinishedController 的元素。

字段	描述

ConcurrentTTLSyncs [必需]
 int32
  concurrentTTLSyncs 是允许并发同步的 TTL-after-finished 收集器工作线程的数量。

 ## `ValidatingAdmissionPolicyStatusControllerConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-ValidatingAdmissionPolicyStatusControllerConfiguration}  **出现在：** - [KubeControllerManagerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-KubeControllerManagerConfiguration)
  ValidatingAdmissionPolicyStatusControllerConfiguration 包含描述 ValidatingAdmissionPolicyStatusController 的元素。

字段	描述

ConcurrentPolicySyncs [必需]
 int32
  ConcurrentPolicySyncs 是允许并发同步的策略对象的数量。 数字越大意味着类型检查越快，但 CPU（和网络）负载越高。 默认值为 5。

 ## `VolumeConfiguration`     {#kubecontrollermanager-config-k8s-io-v1alpha1-VolumeConfiguration}  **出现在：** - [PersistentVolumeBinderControllerConfiguration](#kubecontrollermanager-config-k8s-io-v1alpha1-PersistentVolumeBinderControllerConfiguration)
  VolumeConfiguration 包含所有用于配置各个卷插件的所有参数。 从这个配置中，控制器管理器可执行文件将创建许多 volume.VolumeConfig 的实例。 每个只包含该插件所需的配置，然后将其传递给相应的插件。 控制器管理器可执行文件是代码中唯一知道支持哪些插件以及每个插件对应哪些标志的部分。

字段	描述

EnableHostPathProvisioning [必需]
 bool
  enableHostPathProvisioning 在没有云驱动的情况下允许制备 HostPath PV。 此特性用来测试和开发 PV 卷制备特性。HostPath 配置完全不受支持，在多节点集群中无法工作， 除了测试或开发之外不应该用于任何其他用途。

EnableDynamicProvisioning [必需]
 bool
  enableDynamicProvisioning 在支持动态配置的环境中运行时允许制备新卷。默认为 true。

PersistentVolumeRecyclerConfiguration [必需]
 PersistentVolumeRecyclerConfiguration
  persistentVolumeRecyclerConfiguration 保存持久卷插件的配置。

FlexVolumePluginDir [必需]
 string
  volumePluginDir 是一个完整路径，FlexVolume 插件在这一目录中搜索额外的第三方卷插件。

   No newline at end of file


gpgcheck=1 gpgkey=https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/rpm/repodata/repomd.xml.key EOF <ins> ``` </ins> <del> {{< note >}} To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/zypp/repos.d/kubernetes.repo` before running `zypper update`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/). {{< /note >}} </del> <ins> {{< note >}} To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/zypp/repos.d/kubernetes.repo` before running `zypper update`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/). {{< /note >}} </ins> <del> 1. Install kubectl using `zypper`: </del> <ins> 2. Install kubectl using `zypper`: </ins> <del> ```bash sudo zypper install -y kubectl </del> <ins> ```bash sudo zypper install -y kubectl ``` </ins> {{% /tab %}} {{< /tabs >}}


<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>


cid: docsHome layout: docsportal_home class: gridPage gridPageHome <del> linkTitle: "होम" </del> <ins> linkTitle: "प्रलेखन" </ins> main_menu: true weight: 10 hide_feedback: true


## डेप्लॉयमेंट बनाएँ <del> कुबेरनेट्स [*पॉड*](/hi/docs/concepts/workloads/pods/) एक या अधिक कंटेनरों का एक समूह है, </del> <ins> कुबेरनेट्स [*पॉड*](/docs/concepts/workloads/pods/) एक या अधिक कंटेनरों का एक समूह है, </ins> जो प्रशासन और नेटवर्किंग के उद्देश्यों के लिए एक साथ बंधे होते हैं। इस ट्यूटोरियल के पॉड में केवल एक कंटेनर है। कुबेरनेट्स <del> [*डेप्लॉयमेंट*](/hi/docs/concepts/workloads/controllers/deployment/) आपके पॉड के स्वास्थ्य की </del> <ins> [*डेप्लॉयमेंट*](/docs/concepts/workloads/controllers/deployment/) आपके पॉड के स्वास्थ्य की </ins> जाँच करता है और यदि पॉड बंद हो जाता है तो पॉड के कंटेनर को पुनः आरंभ करता है। पॉड्स के निर्माण और स्केलिंग को प्रबंधित करने के लिए डेप्लॉयमेंट अनुशंसित तरीका है।


display: block; height: 100%; position: fixed; <del> width: 100%; z-index: 1; </del> top: 0; left: 0; background-color: rgba(51, 113, 227, 3%); border-right: 1px solid #dee2e6; <del> overflow-x: hidden; </del> <ins> overflow-x: scroll; </ins> padding-top: .5rem; }