【k8s】资源限制管理：Namespace、Deployment与Pod的实践

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

一、引言

k8s-toc" style="margin-left:40px;">1、什么是k8s

k8s%E4%BD%BF%E7%94%A8%E8%B5%84%E6%BA%90%E9%85%8D%E9%A2%9D%E7%9A%84%E4%BD%9C%E7%94%A8-toc" style="margin-left:40px;">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 层面资源请求和限制的总和：

一、引言

k8s">1、什么是k8s

Kubernetes（简称 K8s）是一个开源的容器编排平台，用于自动化容器化应用的部署、扩展和管理。它最初由 Google 开发，并且现在由 Cloud Native Computing Foundation (CNCF) 维护。Kubernetes 提供了高效的工具和 API，使得在大规模的集群环境中管理容器变得更加容易。

k8s%E4%BD%BF%E7%94%A8%E8%B5%84%E6%BA%90%E9%85%8D%E9%A2%9D%E7%9A%84%E4%BD%9C%E7%94%A8">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-quotanamespace: 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-deploymentnamespace: default
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:containers:- name: myapp-containerimage: myapp:latestresources:requests:memory: "512Mi"  # 请求 512MB 内存cpu: "500m"      # 请求 0.5 个 CPU 核心limits:memory: "1Gi"    # 限制最大内存为 1GBcpu: "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: mypodnamespace: default
spec:containers:- name: container1image: myimage:v1resources:requests:memory: "256Mi"  # 请求 256MB 内存cpu: "500m"      # 请求 0.5 个 CPU 核limits:memory: "512Mi"  # 限制最大内存为 512MBcpu: "1"         # 限制最大 CPU 为 1 核- name: container2image: myimage:v2resources:requests:memory: "128Mi"  # 请求 128MB 内存cpu: "250m"      # 请求 0.25 个 CPU 核limits:memory: "256Mi"  # 限制最大内存为 256MBcpu: "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 核