kubernetes学习记录
文章目录
- 概念
- 目录
- 限制范围
- 资源配额
- 控制节点上的CPU管理策略
- 总结
前言
k8s基础,详细可见限制范围 | Kubernetes
提示：以下是本篇文章正文内容，下面案例可供参考
一、概念
kubernetes集群上的容器运行时是没有计算限制的，我们可以在创建pod设置资源限制，确保一个pod不会垄断命名空间内所有可以用的资源，导致命名空间的其他的pod运行失败
二、目录
1.限制范围
LimitRange可以做到
- 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
- 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
- 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
- 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。
（1）为namespace配置内存默认值
如果在一个拥有默认内存和CPU限额的命名空间中创建一个容器，并且这个容器未指定它自己的内存或CPU的limit，他会被分配这个默认的内存或cpu的limit。既没有设置pod的limit和request才会分配默认的内存或cpu的request
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-resource-constraint
namespace: default-mem-example
spec:
limits:
- default
cpu: 550m
defaultRequest:
cpu: 500m
max:
cpu: "1"
min:
cpu: 100m
type: Container
（2）接下来创建一个pod不指定它的limit和request
apiVersion: v1
kind: Pod
metadata:
name: pod-test
spec:
containers:
- name: demo
image: 192.168.1.163/library/nginx
imagePullPolicy: IfNotPresent
apiVersion: v1
kind: Pod
metadata:
name: pod-test
spec:
containers:
- name: demo
image: 192.168.1.163/library/nginx
imagePullPolicy: IfNotPresent
namespace空间会自动分配
通过 kubectl get pod pod-test --output=yaml -n default
spec:
containers:
- image: 192.168.1.163/library/nginx
imagePullPolicy: IfNotPresent
name: demo
resources:
limits:
cpu: 550m
requests:
cpu: 500m
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-qv2zp
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: node
可见会自动配置它的CPU资源配额
2.资源配额
资源配额，通过
ResourceQuota对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。
工作方式：
不同的团队可以在不同的命名空间下工作。这可以通过 RBAC 强制执行。
集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
如果命名空间下的计算资源 （如
cpu和memory）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用LimitRanger准入控制器来为没有设置计算资源需求的 Pod 设置默认值
启动资源配额
资源配额的支持在很多 Kubernetes 版本中是默认启用的。 当 API 服务器 的命令行标志 --enable-admission-plugins= 中包含 ResourceQuota 时， 资源配额会被启用。
基于优先级类（PriorityClass）来设置资源配额
特性状态： Kubernetes v1.17 [stable]
Pod 可以创建为特定的优先级。 通过使用配额规约中的 scopeSelector 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
仅当配额规范中的 scopeSelector 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。
如果配额对象通过 scopeSelector 字段设置其作用域为优先级类， 则配额对象只能跟踪以下资源：
podscpumemoryephemeral-storagelimits.cpulimits.memorylimits.ephemeral-storagerequests.cpurequests.memoryrequests.ephemeral-storage
本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配。 该示例的工作方式如下：
- 集群中的 Pod 可取三个优先级类之一，即 "low"、"medium"、"high"。
- 为每个优先级创建一个配额对象
apiVersion: v1 kind: List items: - apiVersion: v1 kind: ResourceQuota metadata: name: pods-high spec: hard: cpu: "1000" memory: 200Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["high"] - apiVersion: v1 kind: ResourceQuota metadata: name: pods-medium spec: hard: cpu: "10" memory: 20Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["medium"] - apiVersion: v1 kind: ResourceQuota metadata: name: pods-low spec: hard: cpu: "5" memory: 10Gi pods: "10" scopeSelector: matchExpressions: - operator : In scopeName: PriorityClass values: ["low"]
节点资源管理器
k8s提供了一组资源管理器，用于支持延迟敏感的、高吞吐量的工作负载。资源管理器的目标是协调和优化节点资源，以支持对CPU/设备和内存等资源有特殊需求的pod
none 策略
none 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 通过 CFS 配额来实现 Guaranteed Pods 和 Burstable Pods 的 CPU 使用限制。
static 策略
static 策略针对具有整数型 CPU requests 的 Guaranteed Pod， 它允许该类 Pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 cpuset cgroup 控制器来实现的。
当 Guaranteed Pod 调度到节点上时，如果其容器符合静态分配要求， 相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。 因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。 换言之，容器 cpuset 中的 CPU 数量与 Pod 规约中指定的整数型 CPU limit 相等。 这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
qos服务的三种级别
1.best effort service(尽力转发型)
实际上来讲，best effort服务并不属于一种QOS，因为数据转发过程中并不存在任何服务保证机制。这也是internet上现有的服务类型。
这种服务机制对大多数应用程序比如FTP来说，是非常好的
2 differentiated service(区分服务)
数据流被按不同的标准分类，并提供相应的服务。
区分服务并不能给定精确的服务保证，它只给某类型服务提供相对优先级别的服务，正因为此，differentiated service经常被称为soft QOS
区分服务适合于带宽密集型数据应用。
3 guaranteed service(确认服务)
需要预先订购，因为确认服务有严格的带宽保证，所以又被称为hard QOS。
语音流量一般要占用8K带宽及100ms往返延时。
pod在资源配额时指定哪种qos
当pod未指定request和limits值时 默认属于besteffort
当pod指定了request和limits值时 属于burstable
当pod指定了request和limits值并且两值相等 属于guaranteed
看下面实例加以理解
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
该 Pod 属于 Burstable QoS 类型，因为其资源 requests 不等于 limits，且未指定 cpu 数量。 所以该容器运行在共享 CPU 池中。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
requests:
memory: "100Mi"
cpu: "1"
该 Pod 属于 Burstable QoS 类型，因为其资源 requests 不等于 limits。 所以该容器运行在共享 CPU 池中。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
requests:
memory: "200Mi"
cpu: "2"
该 Pod 属于 Guaranteed QoS 类型，因为其 requests 值与 limits相等。 同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。 所以，该 nginx 容器被赋予 2 个独占 CPU。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "1.5"
requests:
memory: "200Mi"
cpu: "1.5"
该 Pod 属于 Guaranteed QoS 类型，因为其 requests 值与 limits相等。 但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
该 Pod 属于 Guaranteed QoS 类型，因其指定了 limits 值，同时当未显式指定时， requests 值被设置为与 limits 值相等。 同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。 所以，该 nginx 容器被赋予 2 个独占 CPU。
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
namespace: default
spec:
containers:
- image: 192.168.1.163/library/nginx
name: nginx-qos
imagePullPolicy: IfNotPresent
resources:
limits:
cpu: 100m
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
status:
qosClass: Guaranteed
在指定qosclass类别为Guaranteed时 必须要设置资源配额且相等
提示：这里对文章进行总结：
以上就是今天学习的内容，本文仅仅简单介绍了k8s资源配额的使用
8292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
