使用 Kubernetes 命名空间管理内存和 CPU 资源 (II)
平台开发 360云计算
女主宣言
众所周知,Kubernetes是允许指定CPU和RAM的请求和限制的,这一特性对于单独的pod的资源消耗管理非常有用。在本系列文章中,我们将向大家展示集群资源的高效管理的三种策略。
PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!
众所周知,Kubernetes是允许指定CPU和RAM的请求和限制的,这一特性对于单独的pod的资源消耗管理非常有用。
但是,如果你是Kubernetes集群管理员,你可能还希望控制集群中资源的全局性消耗,并/或配置所有容器的默认资源需求。
值得高兴的是,Kubernetes支持名称空间级别的集群资源管理。正如你可能已经知道的,Kubernetes的名称空间提供了名称和资源配额的范围,这允许在多个用户、项目和团队之间有效地划分集群资源。在Kubernetes中,你可以定义缺省资源请求和限制、资源约束(最小和最大资源请求和限制),以及在给定名称空间中运行的所有容器的资源配额。这些特性使得集群中的应用程序能够高效地利用资源,并在不同的团队之间有效地分配资源。例如,使用名称空间的资源约束允许你控制生产和开发工作负载如何使用资源,从而允许它们消耗有限的集群资源的公平份额。这可以通过为生产和开发工作负载创建单独的名称空间来实现,并为它们分配不同的资源约束。
在系列文章中,我们将向你展示集群资源的高效管理的三种策略:
设置默认的资源请求和容器的限制
定义最小和最大的资源约束
为名称空间中的所有容器设置资源配额
这些策略将帮助你解决各种各样的用例,利用Kubernetes名称空间和资源管理的全部功能。
为名称空间设置最小和最大资源约束
在这个例子中,我们将为命名空间创建资源约束。这些约束本质上是容器可以在资源请求和限制中使用的最小和最大资源量。让我们看看它是如何工作的!
与前面的例子一样,首先创建名称空间:
kubectl create namespace resource-constraints-demo namespace "resource-constraints-demo" created
接下来,我们将为这个名称空间创建一个限制范围:
apiVersion: v1
kind: LimitRange
metadata:
name: resource-constraints-lr
spec:
limits:
- max:
memory: 1Gi
cpu: 0.8
min:
memory: 500Mi
cpu: 0.3
type: Container
保存 LimitRange 为 limit-range-2.yaml 并创建它:
kubectl create -f limit-range-2.yaml --namespace resource-constraints-demo
limitrange "resource-constraints-lr" created
在创建了限制范围之后,让我们看看我们的最小和最大资源约束是否应用于名称空间:
kubectl get limitrange resource-constraints-lr --namespace resource-constraints-demo --output=yaml
响应如下:
spec:
limits:
- default:
cpu: 800m
memory: 1Gi
defaultRequest:
cpu: 800m
memory: 1Gi
max:
cpu: 800m
memory: 1Gi
min:
cpu: 300m
memory: 500Mi
type: Container
正如你所看到的,你的名称空间的默认资源请求和限制被自动设置为在 LimitRange 内指定的最大资源约束。现在,当我们在 resource-constraints-demo 名称空间中创建容器时,下面的规则将自动应用:
如果容器没有指定它的资源请求和限制,则应用默认的资源请求和限制。
名称空间中的所有容器都需要有大于或等于3亿的资源请求,用于CPU和500 Mi内存。
名称空间中的所有容器都需要资源限制小于或等于8亿,用于CPU和1 Gi内存。
让我们创建一个pod来说明如何将名称空间资源约束应用到容器中:
apiVersion: v1
kind: Pod
metadata:
name: resource-constraints-pod
spec:
containers:
- name: resource-constraints-ctr
image: httpd:2.4
resources:
limits:
memory: "900Mi"
cpu: 0.7
requests:
memory: "600Mi"
cpu: 0.4
该规范请求600 Mi RAM和0.4 CPU,并为这个pod中的httpd容器设置900 Mi RAM和0.7 CPU的限制。这些资源需求满足了名称空间的最小和最大约束。
我们保存为 default-resources-demo-pod-3.yaml 并在我们的名称空间中创建pod:
kubectl create -f resource-constraints-pod.yaml --namespace resource-constraints-demo
pod "resource-constraints-pod" created
接下来,检查分配给pod中的容器的资源:
kubectl get pod resource-constraints-pod --namespace resource-constraints-demo --output=yaml
你应该得到以下输出:
containers:
- image: httpd:2.4
imagePullPolicy: IfNotPresent
name: resource-constraints-ctr
resources:
limits:
cpu: 700m
memory: 900Mi
requests:
cpu: 400m
memory: 600Mi
之所以成功创建pod,是因为容器的请求和限制在名称空间的最小和最大约束范围内。
现在,让我们看看如果我们指定的请求和限制超出了为名称空间定义的最小值和最大值,会发生什么。让我们用新的请求和限制来创建一个新的pod:
apiVersion: v1
kind: Pod
metadata:
name: resource-constraints-pod-2
spec:
containers:
- name: resource-constraints-ctr-2
image: httpd:2.4
resources:
limits:
memory: "1200Mi"
cpu: 1.2
requests:
memory: "200Mi"
cpu: 0.2
我们保存为 resource-constraints-pod-2.yaml 并在我们的名称空间中创建pod:
kubectl create -f resource-constraints-pod-2.yaml --namespace resource-constraints-demo
pod "resource-constraints-pod-2" created
由于资源请求低于最小 LimitRange 的值,并且资源限制超出了这个名称空间的最大值,所以pod不会像预期的那样被创建:
Error from server (Forbidden): error when creating "resource-constraints-pod-2.yaml": pods "resource-constraints-pod-2" is forbidden: [minimum memory usage per Container is 500Mi, but request is 200Mi., minimum cpu usage per Container is 300m, but request is 200m., maximum cpu usage per Container is 800m, but limit is 1200m., maximum memory usage per Container is 1Gi, but limit is 1200Mi.]
清理
在这个例子完成之后,让我们清理一下。
删除名称空间:
kubectl delete namespace resource-constraints-demo namespace "resource-constraints-demo" deleted
总结
在本篇文章中,我们将向大家展示了为名称空间设置最小和最大资源约束。后续系列文章将会继续展示:为名称空间中的所有容器设置资源配额。
上一篇: 从存储的过去到计算的未来:AO 超并行计算机-前言
下一篇: k8s 基本 pod (3) 命名空间
推荐阅读
-
Kubernetes 容器、Pod、命名空间内存和 CPU 限制
-
Kubernetes Notes (16) - 集群管理、使用命名空间分隔系统资源、为命名空间设置资源限制、使用默认资源配额
-
Kubernetes K8S 的 CPU 和内存资源限制详情 配置命名空间的内存和 CPU 配额 配置命名空间的默认内存请求和限制 配置命名空间的默认 CPU 请求和限制 配置命运
-
使用 Kubernetes 命名空间管理内存和 CPU 资源 (I)
-
k8s [资源管理] 1 - ResourceQuota 为命名空间配置内存和 CPU 配额
-
使用 Kubernetes 命名空间管理内存和 CPU 资源 (II)
-
使用 Kubernetes 命名空间管理内存和 CPU 资源 (I)
-
Kubernetes 最佳实践 S03E02:如何使用命名空间管理 Kubernetes 资源?
-
k8s [资源管理(资源)] 4 - 用于配置命名空间内存最小和最大限制的 LimitRange
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)