k8s（九）容器资源限制,资源监控
目录
- 一 . k8s容器资源限制
-
- 1.内存限制（pod）
- 2.cpu限制（pod）
- 3.namespace设置资源限制
- 4.namespace设置资源配额
- 5.Namespace配置Pod配额
- 二. kubernetes资源监控
-
- Metrics-Server部署
- 三种报错及解决方法
一 . 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节点信息，发现恢复运行！！！
