k8s资源管理之ResourceQuota、LimitRange和QoS
ResourceQuota
ResourceQuota 是 Kubernetes 中的一个资源配额对象,用于限制命名空间(Namespace)中资源的使用量。ResourceQuota 可以限制命名空间中的 Pod 数量、特定类型资源对象的数量(如 Services、Deployments 等),以及命名空间内所有 Pod 可以使用的计算资源总量(如 CPU、内存等)。
ResourceQuota 的主要作用是在多用户共享 Kubernetes 集群时,确保每个命名空间中的资源使用量不会超过其配额限制,从而避免资源过度消耗和竞争。这对于管理集群资源、确保公平性和防止资源滥用非常有用。
在创建 ResourceQuota 时,管理员需要指定要限制的资源类型(如 CPU、内存、存储等)以及相应的配额值。当用户在命名空间中创建或更新资源时,Kubernetes 的配额系统会跟踪资源使用情况,并确保不超过 ResourceQuota 中定义的限制。如果请求的资源超过了配额限制,相关的 API 请求将会被拒绝,并返回 403 Forbidden 错误。
ResourceQuota 的应用范围是命名空间级别的,每个命名空间可以有一个或多个 ResourceQuota 对象。需要注意的是,ResourceQuota 只限制命名空间中资源的创建和更新操作,对于已经存在的资源对象,修改 ResourceQuota 的配额值不会影响它们的使用。
此外,ResourceQuota 的启用需要依赖于 Kubernetes API 服务器的启动参数 --enable-admission-plugins
中包含 ResourceQuota
。在默认情况下,许多 Kubernetes 发行版都会启用这个插件,以确保 ResourceQuota 的功能可用。
总的来说,ResourceQuota 是 Kubernetes 中实现资源配额管理的重要工具,它可以帮助管理员有效地控制和限制命名空间中的资源使用,确保集群的稳定性和公平性。
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-quota-example
namespace: my-namespace
spec:
hard:
pods: "10" # 命名空间中允许的最大 Pod 数量
services: "5" # 命名空间中允许的最大 Service 数量
replicationcontrollers: "2" # 命名空间中允许的最大 ReplicationController 数量
resourcequotas: "1" # 命名空间中允许的最大 ResourceQuota 数量
secrets: "10" # 命名空间中允许的最大 Secret 数量
persistentvolumeclaims: "4" # 命名空间中允许的最大 PersistentVolumeClaim 数量
services.loadbalancers: "1" # 允许的最大 LoadBalancer 类型 Service 数量
requests.cpu: "10" # 命名空间中所有 Pods 可以请求的 CPU 总量
requests.memory: "10Gi" # 命名空间中所有 Pods 可以请求的内存总量
limits.cpu: "20" # 命名空间中所有 Pods 可以使用的 CPU 总量上限
limits.memory: "20Gi" # 命名空间中所有 Pods 可以使用的内存总量上限
LimitRange
LimitRange 是 Kubernetes 中的一个资源限制策略对象,用于在命名空间内限制资源分配(给多个 Pod 或 Container)。通过 LimitRange,管理员可以实施对每个 Pod 或 Container 的最小和最大资源使用量的限制,以及对每种资源的申请值和限制值的比值的控制。此外,LimitRange 还可以设置命名空间中计算资源的默认申请/限制值,这些默认值会自动注入到多个 Container 中。
LimitRange 的主要作用包括:
- 限制资源使用:通过定义最小和最大资源限制,确保 Pod 和 Container 在使用计算资源时不会过度消耗,从而避免对集群中的其他工作负载造成干扰。
- 资源配额控制:LimitRange 可以用来实施命名空间级别的资源配额控制,确保命名空间内的资源分配符合管理策略。
- 自动注入默认值:管理员可以设置默认的资源申请和限制值,这些默认值会在创建 Pod 时自动注入到 Container 的配置中,从而简化了资源配置的过程。
- 提升资源利用率:通过合理的资源限制和默认值设置,LimitRange 有助于提高集群中资源的利用率,避免资源浪费。
LimitRange 的使用在 Kubernetes 1.10 版本及之后的版本中默认启用,并且在许多 Kubernetes 发行版中也是默认启用的。
以下是一个 LimitRange 的 YAML 示例:
apiVersion: v1
kind: LimitRange
metadata:
name: limitrange-example
namespace: my-namespace
spec:
limits:
- type: Pod
max:
cpu: "2"
memory: "2Gi"
min:
cpu: "500m"
memory: "64Mi"
default:
cpu: "1"
memory: "512Mi"
- type: Container
max:
cpu: "1"
memory: "1Gi"
min:
cpu: "200m"
memory: "32Mi"
defaultRequest:
cpu: "500m"
memory: "256Mi"
在这个示例中,我们定义了一个名为 limitrange-example
的 LimitRange 对象,它位于 my-namespace
命名空间中。spec.limits
字段下定义了两个限制规则,一个针对整个 Pod,另一个针对单个 Container。每个规则都包含了最大、最小和默认的资源限制值。
要创建这个 LimitRange 对象,同样可以使用 kubectl
命令:
bash复制代码
kubectl create -f limitrange.yaml
其中,limitrange.yaml
是包含上述 YAML 定义的文件名。
请注意,LimitRange 的名称必须是合法的 DNS 子域名,并且其限制规则应当根据实际需求和集群的硬件配置来合理设置。
QoS
QoS(Quality of Service,服务质量)是Kubernetes中用于管理Pod资源分配和调度的一个重要概念。在Kubernetes中,每个Pod都会被分配一个QoS等级,这个等级决定了Pod的调度优先级和驱逐优先级,以及Pod在不同节点上的资源分配策略。
Kubernetes定义了三种QoS等级:
-
BestEffort:这是最低级别的QoS,适用于那些不需要保证资源使用的Pod。在这种QoS等级下,Pod中的容器没有指定CPU和内存的requests和limits,因此它们可以使用任何可用的资源,但也可能因为资源不足而被系统驱逐。BestEffort Pod通常用于一些非关键的任务,如系统服务或日志收集器。
apiVersion: v1 kind: Pod metadata: name: best-effort-pod spec: containers: - name: best-effort-container image: nginx
-
Burstable:这种QoS等级适用于那些需要一定量的CPU和内存资源,但也可能需要超过这些资源的Pod。Burstable Pod被分配了一定的CPU和内存资源,但当系统中其他Pod消耗了更多的资源时,它们的资源可用性可能会受到影响。容器能够使用超过所分配的资源量(称为“突发资源”),但实际可用资源量取决于其他Pod和系统资源占用情况。
apiVersion: v1 kind: Pod metadata: name: burstable-pod spec: containers: - name: burstable-container image: nginx resources: requests: cpu: 100m memory: 100Mi
-
Guaranteed:这是最高级别的QoS,适用于那些需要保证资源使用的Pod。在这种QoS等级下,Pod里的每个容器都必须有内存/CPU限制和请求,而且值必须相等。Kubernetes会严格限制这些Pod的资源使用,确保它们始终有足够的资源来运行,并且不会被其他Pod或系统资源竞争所影响。
apiVersion: v1 kind: Pod metadata: name: guaranteed-pod spec: containers: - name: guaranteed-container image: nginx resources: requests: cpu: 500m memory: 500Mi limits: cpu: 500m memory: 500Mi
Pod的QoS等级是根据容器的资源要求和系统中其他Pod的资源使用情况来判断的。容器的资源要求可以通过在容器定义中指定相应的request和limit来定义。Kubernetes会根据这些要求来计算Pod的QoS等级,并据此进行资源分配和调度决策。
本文来自博客园,作者:dashery,转载请注明原文链接:https://www.cnblogs.com/ydswin/p/18045899