🐇明明跟你说过：个人主页
🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅
🔖行路有良友，便是天堂🔖
一、引言
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的文章能陪伴您走过技术的一段旅程，共同见证成长和进步！😺😺😺
🧨🧨🧨让我们一起在技术的海洋中探索前行，共同书写美好的未来！！！
版权归原作者 明明跟你说过 所有， 如有侵权，请联系我们删除。