【k8s】资源限制管理:Namespace、Deployment与Pod的实践
🐇明明跟你说过:个人主页
🏅个人专栏:《Kubernetes航线图:从船长到K8s掌舵者》 🏅
🔖行路有良友,便是天堂🔖
目录
一、引言
1、什么是k8s
2、在k8s使用资源配额的作用
二、Kubernetes资源限制概述
1、资源请求的设定(Requests)
2、资源限制的设定(Limits)
三、Namespace层面的资源限制
1、资源配额支持的资源类型
2、示例:设置命名空间的资源配额
四、Deployment层面的资源限制
1、如何在 Deployment 中设置资源请求和限制
2、资源请求与限制的影响
1. 资源调度:
2. 资源管理:
3. 容器的生命周期:
五、Pod层面的资源限制
1、如何在 Pod 中设置资源请求和限制
2、Pod 资源请求与限制的计算
1. 单个容器的资源:
2. Pod 层面资源请求和限制的总和:
一、引言
1、什么是k8s
Kubernetes(简称 K8s)是一个开源的容器编排平台,用于自动化容器化应用的部署、扩展和管理。它最初由 Google 开发,并且现在由 Cloud Native Computing Foundation (CNCF) 维护。Kubernetes 提供了高效的工具和 API,使得在大规模的集群环境中管理容器变得更加容易。
2、在k8s使用资源配额的作用
- 限制资源使用: 资源配额可以帮助管理和限制在特定 命名空间(Namespace) 中可用的资源总量。例如,你可以限制一个命名空间内最大能使用的 CPU 或内存总量,以及可以创建的 Pod 数量等。这样可以防止某个团队或应用无节制地消耗集群资源,导致集群中其他应用无法获得足够的资源。
- 避免资源争抢: 在一个多租户环境中(例如多团队共享同一个 Kubernetes 集群),资源配额可以确保每个团队在命名空间内有公平的资源分配。没有资源配额的情况下,某个团队可能会消耗整个集群的资源,影响到其他团队的应用。
- 防止资源过度分配: 资源配额有助于防止某些应用或用户请求过多资源,超出了集群的总资源容量。通过设置资源配额,可以确保集群的资源不会被过度占用,从而避免因资源过载导致的系统崩溃或性能下降。
- 提高集群的可管理性和可预测性: 资源配额帮助集群管理员清晰地了解每个命名空间的资源使用情况,并能够预测和控制集群的资源需求。这样可以更好地规划集群的容量,并防止资源不足的情况。
二、Kubernetes资源限制概述
1、资源请求的设定(Requests)
在 Kubernetes 中,资源请求(Requests) 是指容器启动时所需要的最小资源量。当 Kubernetes 调度器将容器调度到某个节点时,它会检查节点是否有足够的资源来满足容器的请求。如果节点上的资源不足,调度器将不会将容器调度到该节点,直到有足够的资源可用。
- CPU 请求(requests.cpu):表示容器启动时需要的最小 CPU 资源量。它是容器能够正常运行所必需的最低 CPU 配额。
- 内存请求(requests.memory):表示容器启动时需要的最小内存资源量。它是容器能够正常运行所必需的最低内存配额。
Kubernetes 使用 资源请求(requests) 来决定哪些节点有足够的资源来运行容器。当容器运行时,它不会使用超过请求量的资源(除非节点有剩余资源),但是它保证可以使用请求量的资源。
2、资源限制的设定(Limits)
在 Kubernetes 中,资源限制(Limits) 是指容器可以使用的最大资源量。资源限制确保容器不会超出节点或集群的资源限制,从而避免资源滥用或过度消耗影响其他容器的稳定性。
- CPU 限制(limits.cpu):表示容器可以使用的最大 CPU 资源。容器无法使用超过该限制的 CPU 资源。
- 内存限制(limits.memory):表示容器可以使用的最大内存资源。如果容器超出内存限制,Kubernetes 可能会终止该容器并将其重新调度(即 OOMKill)。
与 资源请求(Requests) 配合使用,资源请求表示容器启动时所需的最小资源量,而资源限制则是容器在运行时可以使用的最大资源量。
三、Namespace层面的资源限制
在 Kubernetes 中,Namespace 层面的资源限制 通过 资源配额(ResourceQuotas) 来实现,允许管理员在不同的命名空间(Namespace)中定义资源的使用限制。资源配额限制了每个命名空间中可以使用的资源总量,帮助确保集群中的资源在多个命名空间之间得到公平分配。
1、资源配额支持的资源类型
在 Kubernetes 中,资源配额可以控制以下几种类型的资源:
- CPU 和内存(requests 和 limits): 限制命名空间内所有容器的 CPU 和内存使用总量。可以限制请求(requests)和限制(limits)。
- Pod 数量: 限制命名空间中创建的 Pod 的最大数量。
- 服务、复制控制器、副本集等资源数量: 限制每种资源(如 Service、Deployment、ReplicaSet、StatefulSet 等)的数量。
- 持久卷(Persistent Volumes, PV): 限制命名空间内持久卷的使用数量和存储量。
- Ingress 资源数量: 限制命名空间内 Ingress 资源的数量。
- 其他对象: 如 ConfigMap、Secret、Endpoints 等资源的数量和大小。
2、示例:设置命名空间的资源配额
资源配额是通过创建 ResourceQuota 资源对象来配置的。以下是一个简单的 ResourceQuota YAML 配置文件示例,演示了如何设置命名空间的资源配额。
apiVersion: v1
kind: ResourceQuota
metadata:
name: example-resource-quota
namespace: mynamespace
spec:
hard:
requests.cpu: "2"
requests.memory: "4Gi"
limits.cpu: "4"
limits.memory: "8Gi"
pods: "10"
services: "5"
persistentvolumeclaims: "5"
configmaps: "10"
secrets: "10"
- requests.cpu:指定命名空间内所有容器 CPU 请求的总和不能超过 2 核。
- requests.memory:指定命名空间内所有容器内存请求的总和不能超过 4 Gi。
- limits.cpu:指定命名空间内所有容器 CPU 限制的总和不能超过 4 核。
- limits.memory:指定命名空间内所有容器内存限制的总和不能超过 8 Gi。
- pods:限制命名空间内最多可以创建 10 个 Pod。
- services:限制命名空间内最多可以创建 5 个服务(Service)。
- persistentvolumeclaims:限制命名空间内最多可以创建 5 个持久卷声明(PVC)。
- configmaps:限制命名空间内最多可以创建 10 个 ConfigMap。
- secrets:限制命名空间内最多可以创建 10 个 Secret。
四、Deployment层面的资源限制
在 Kubernetes 中,Deployment 资源是管理和部署一组无状态的 Pods 的一种方式。通常,Deployment 会指定一组 Pods 的副本,并管理它们的更新、扩展和回滚。与命名空间级别的资源配额不同,Deployment 层面的资源限制 是在 Pod 级别进行配置的,目的是为了限制和管理部署的容器(Pod)使用的资源(CPU 和内存)。
在 Deployment 中,资源请求(Requests)和资源限制(Limits)通常在 Pod 的容器定义中进行设置。每个容器都可以设置自己的资源请求和限制,Kubernetes 会根据这些设置来进行资源调度。
1、如何在 Deployment 中设置资源请求和限制
在 Deployment 的 YAML 文件中,容器的资源请求和限制是通过 resources 字段来配置的。下面是一个完整的示例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:latest
resources:
requests:
memory: "512Mi" # 请求 512MB 内存
cpu: "500m" # 请求 0.5 个 CPU 核心
limits:
memory: "1Gi" # 限制最大内存为 1GB
cpu: "1" # 限制最大 CPU 为 1 核
- requests:是容器在启动时请求的资源量,Kubernetes 会确保调度容器时,节点至少有这些资源可用。比如在上面的示例中,容器请求了 512MB 内存和 0.5 个 CPU 核心。
- limits:是容器能够使用的资源最大值。如果容器的资源消耗超过了这个值,Kubernetes 会对其进行限制。比如示例中限制了容器最多可以使用 1GB 内存和 1 个 CPU 核心。
2、资源请求与限制的影响
1. 资源调度:
- Kubernetes 调度器会根据 requests 来决定 Pod 可以在哪个节点上运行。请求的资源越大,Kubernetes 就会把该 Pod 调度到资源更多的节点上。如果节点的资源不足,Pod 可能会无法调度。
2. 资源管理:
- 如果没有设置资源限制(limits),容器可能会无限制地使用资源,这可能会影响同一节点上的其他 Pod。
- 设置资源限制可以防止单个容器消耗过多资源,影响其他容器或 Pod 的运行。例如,如果没有内存限制,当容器消耗大量内存时,可能会导致 OOM(Out of Memory)错误,从而导致容器崩溃。
3. 容器的生命周期:
- 当容器的资源使用超过限制时,Kubernetes 会对其进行限制。例如,CPU 的限制通常会导致容器的 CPU 被限制(throttling),内存的限制可能会导致容器被杀死(OOM)。Kubernetes 会根据设置的策略重启容器,或者在资源消耗恢复正常后重新分配资
五、Pod层面的资源限制
在 Kubernetes 中,Pod 是一组容器的集合,这些容器共享相同的网络和存储资源。Pod 是 Kubernetes 中的最小调度单元,它可以包含一个或多个容器。Pod 层面的资源限制 是针对 Pod 中所有容器的资源请求(requests)和资源限制(limits)进行配置的。
虽然 Kubernetes 中的资源限制通常在容器级别进行设置,但 Pod 也可以设置一些资源限制,这些限制是针对 Pod 中所有容器的资源请求和限制进行的总和计算。如果你有多个容器在同一个 Pod 内,那么容器级别的资源请求和限制会一起影响 Pod 层面的资源调度。
1、如何在 Pod 中设置资源请求和限制
在 Kubernetes 中,你可以在 Pod 的 YAML 文件中为容器设置资源请求和限制。在多容器的 Pod 中,Pod 的所有容器都会共享这些资源,但每个容器可以有自己独立的资源请求和限制。
以下是一个带有资源请求和限制配置的 Pod 示例:
apiVersion: v1
kind: Pod
metadata:
name: mypod
namespace: default
spec:
containers:
- name: container1
image: myimage:v1
resources:
requests:
memory: "256Mi" # 请求 256MB 内存
cpu: "500m" # 请求 0.5 个 CPU 核
limits:
memory: "512Mi" # 限制最大内存为 512MB
cpu: "1" # 限制最大 CPU 为 1 核
- name: container2
image: myimage:v2
resources:
requests:
memory: "128Mi" # 请求 128MB 内存
cpu: "250m" # 请求 0.25 个 CPU 核
limits:
memory: "256Mi" # 限制最大内存为 256MB
cpu: "500m" # 限制最大 CPU 为 0.5 核
- 资源请求(Requests):表示容器运行时所需的最小资源。Kubernetes 调度器会根据容器的请求值决定容器在哪个节点上运行,确保节点具有足够的资源以满足这些请求。
- 资源限制(Limits):表示容器可以使用的最大资源量。容器在运行时,Kubernetes 会确保容器的资源使用不超过该限制。如果容器的资源消耗超过限制(比如内存),它可能会被杀死并重启;如果是 CPU,它可能会被限制,导致其执行变慢。
2、Pod 资源请求与限制的计算
1. 单个容器的资源:
上面的示例中,Pod 中有两个容器 container1 和 container2,每个容器都分别设置了资源请求和限制。
- container1 的请求是 256Mi 内存和 0.5 个 CPU 核心,限制是 512Mi 内存和 1 个 CPU 核心。
- container2 的请求是 128Mi 内存和 0.25 个 CPU 核心,限制是 256Mi 内存和 0.5 个 CPU 核心。
2. Pod 层面资源请求和限制的总和:
虽然 Kubernetes 是按照容器级别来分配资源的,但 Pod 层面的资源管理通常会将 Pod 中所有容器的资源请求和限制进行汇总。因此,在 Pod 层面,你可以考虑 Pod 的资源请求和限制是所有容器资源的总和。
- 资源请求总和:Pod 中所有容器请求资源的总和。
- Pod 请求的内存总量 = 256Mi (container1) + 128Mi (container2) = 384Mi
- Pod 请求的 CPU 总量 = 0.5 核 (container1) + 0.25 核 (container2) = 0.75 核
- 资源限制总和:Pod 中所有容器限制资源的总和。
- Pod 限制的内存总量 = 512Mi (container1) + 256Mi (container2) = 768Mi
- Pod 限制的 CPU 总量 = 1 核 (container1) + 0.5 核 (container2) = 1.5 核
💕💕💕每一次的分享都是一次成长的旅程,感谢您的陪伴和关注。希望这些关于Kubernetes的文章能陪伴您走过技术的一段旅程,共同见证成长和进步!😺😺😺
🧨🧨🧨让我们一起在技术的海洋中探索前行,共同书写美好的未来!!!