目录
一 . k8s容器资源限制
Kubernetes采用request和limit两种限制类型来对资源进行分配。
- request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。
- limit(资源限额):即运行Pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。
资源类型:
(1)CPU 的单位是核心数,内存的单位是字节。
(2)一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀m
表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。
内存单位:
K、M、G、T、P、E #通常是以1000为换算标准的。
Ki、Mi、Gi、Ti、Pi、Ei #通常是以1024为换算标准的。
清楚上个实验的环境影响
1.内存限制(pod)
将需要的镜像上传到私有仓库
编辑资源清单,对节点容器使用的内存进行限制
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo
image: stress
args:
- --vm
- "1"
- --vm-bytes
- 200M
resources:
requests:
memory: 50Mi
limits:
memory: 100Mi ##限制200M
创建一个目录limit 用来存放文件,应用清单,报错!!
内存限制为50-100MI,但是却要求创建200M的内存!!!
如果容器超过其内存限制,则会被终止
。如果可重新启动,则与所有其他类型的运行时故障一样,kubelet 将重新启动它。
修改上限内存为300M,再次执行清单,并查看pod节点信息
运行成功!!!
2.cpu限制(pod)
执行清单pod1.yaml
无法执行,因为虚拟机只有两个cpu!!!
查看详细信息,发现无法调度
更改cpu限制的上下限,最少0.5个cpu
再次执行清单,并查看pod节点, running !!!
3.namespace设置资源限制
cat limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: limitrange-memory
spec:
limits:
- default: ##pod内没有定义资源限制时以default为准
cpu: 0.5
memory: 512Mi
defaultRequest:
cpu: 0.1
memory: 256Mi
max:
cpu: 1
memory: 1Gi
min:
cpu: 0.1
memory: 100Mi
type: Container
执行清单limitrange.yaml,查看信息
执行pod.yaml文件,发现无法运行,原因是内存下限必须大于100Mi!!!
取消内存的限制,创建pod
查看pod的详细信息,发现使用的是limitrange.yaml的内存和cpu限制!!!
4.namespace设置资源配额
requests.cpu: "1" 所有容器的cpu请求总额不能超过1核
requests.memory: 1Gi 所有容器的内存请求总额不能超过1GIB
limits.cpu: "2" 所有容器的cpu限额总额不能超过2核
limits.memory: 2Gi 所有容器的内存限额总额不能超过2GIB
将namespace设置资源配额
执行配额清单limitrange.yaml
并将其中的资源限制清除
查看资源配额
将内存限制注释,执行清单pod.yaml的时候会报错!!!
cat pod.yaml
有配额无限制(必须有限制)
打开内存限制,并加入cpu限制
可以看到配额的大小上下限和pod.yaml文件中指定的一样!!!
执行配额清单,将pod.yaml中的限制再次注释,改名为memory-demo-2
执行pod.yaml清单
可以看到查看道德配额大小发生了变化
再次更改pod.yaml,打开限制,改名为memory-demo-3
cpu不够会报错
显示已使用量
重新分配剩下的0.8个cpu,创建memory-demo-3
显示已使用量
成功创建!!!
5.Namespace配置Pod配额
ResourceQuota也可以限制namespace中运行的Pod数
限制pod数量为3
执行清单
pod数量限制上限为3个,超出无法建立
二. kubernetes资源监控
Metrics-Server部署
-
Metrics-Server是集群核心监控数据的聚合器,用来替换之前的heapster。
-
容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务,有了Metrics-Server之后,用户就可以通过标准的 Kubernetes API 来访问到这些监控数据。
- Metrics API 只可以查询当前的度量数据,并不保存历史数据。
- Metrics API URI 为 /apis/metrics.k8s.io/,在 k8s.io/metrics 维护。
- 必须部署 metrics-server 才能使用该 API,metrics-server 通过调用 Kubelet Summary API 获取数据。
-
Metrics Server 并不是 kube-apiserver 的一部分,而是通过 Aggregator 这种插件机制,在独立部署的情况下同 kube-apiserver 一起统一对外服务的。
-
kube-aggregator 其实就是一个根据 URL 选择具体的 API 后端的代理服务器。
-
Metrics-server属于Core metrics(核心指标),提供API metrics.k8s.io,仅提供Node和Pod的CPU和内存使用情况。而其他Custom Metrics(自定义指标)由Prometheus等组件来完成。
资源下载:https://github.com/kubernetes-incubator/metrics-server
实验环境:
将需要的镜像拉取下来上传到私有仓库中
将刚才wget下来的components.yaml文件编辑,修改镜像名
执行文件components.yaml,查看节点信息
发现没有就绪!!!
三种报错及解决方法
查看日志的报错,解决问题:
需要再次修改清单配置:
将两处的端口改为4443
报错:x509: certificate signed by unknown authority
启用TLS Bootstrap 证书签发(在master和各个节点中)
在server2,3,4都需要修改
添加参数:
添加之后,重启服务
启用TLS Bootstrap 证书签发(在master和各个节点中)
报错:dial tcp: lookup server2 on 10.96.0.10:53: no such host
没有内网的DNS服务器,所以metrics-server无法解析节点名字。可以直接修改 coredns的configmap,将各个节点的主机名加入到hosts中,这样所有Pod都可以从 CoreDNS中解析各个节点的名字。
再次查看pod节点信息,发现恢复运行!!!