k8s（九）容器资源限制,资源监控

一 . 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节点信息，发现恢复运行！！！