linux--kubernetes(资源限制和监控 1)

一切镜像尽在本人私有仓库中

k8s容器资源限制

• k8s采用request和limit两种限制类型来对资源进行分配

• • request(资源需求)：即运行pod的节点必须满足运行pod的最基本需求才能运行pod。
• • limit(资源限制)：即运行pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。

• 资源类型：

• • CPU的单位是核心数，内存的单位是字节。
• • 一个容器申请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为换算标准的。

内存资源限制

[kubeadm@server2 limit]$ cat pod.yaml 
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

• 如果容器超过其内存限制，则会被终止。如果可重新启动，则与其他所有类型的运行故障一样，kubelet将重新启动它。
• 如果一个容器超过其内存要求，那么当节点内存不足时，它的pod可能被逐出。

• 当资源限制没冲突的时候正常启动

• 资源内部机制使用的是cgroup类型
• 目录： /sys/fs/cgroup/systemd

cpu资源限制

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    args:
    - -c
    - "2"
    resources:
      requests:
        cpu: "5"
      limits:
        cpu: "10"

无法满足要求
cpu使用率过高不会被杀死

满足要求

namespace设置资源限制

• 资源限制

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
 - 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 在 namespace 中施加的最小和最大内存限制只有在创新和更性pod时才会被应用。改变LimitRange不会对之前创建的pod有影响。

• LimitRange - default xx会自动对没有设置资源限制的pod自动添加限制

• 设置配额限制

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:                     硬限制
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

一旦设置配额后，后续的容器必须设置请求（4种请求都设置），当然，这只是在rq设置的defult的namespace中

资源会统计总的namespace中的资源加以限定，不管是之前创建还是准备创建

namespace中pod的限制

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"

当然，以上设定对应相对的namespace，其它的namespace没有影响

为了后续不受影响，删除相应的设定

资源监控

• metrics-server是集群核心监控数据的聚合器，用来替换之前的heapster。
• 容器相关的metrics主要来自于kubelet内置的cadvisor服务，有了metrics-server之后，用户就可以通过标准的kubernetes API来访问到这些监控数据。
• mestrics API只可以查询当前的度量数据，并不保存历史数据。
• mestrics API URI为/apis/metrics.k8s.io/,在k8s.io/metrics维护。
• 必须部署metrics-server才能使用该API,metrics-server通过调用kubelet summary API获取数据。
• 示例：

 http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes
 http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
 http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>

• metrics server并不是 kube-apiserver的一部分，而是通过aggregator 这种插件机制，在独立部署的情况下同 kube-apiserver一起统一对外服务。
• kube-aggregator 其实就是一个根据URL选择具体的API后端的代理服务器。

• metrics-server属于core metrics（核心指标），提供APIA metrics.k8s.io,仅提供Node和Pod的CPU和内存使用情况。而其它clustom metrics(自定义制表)由prometheus等组建来完成。

https://github.com/kubernetes-sigs/metrics-server

下载官方的配置文件

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml
修改镜像位置为私有仓库

• 当前还不能使用，需要修改其它配置

查看pod日志

####### 错误1：#########

没有内网dns服务器，所以metrics-server无法解析节点名字。可以直接修改coredns的configmap，将各个节点的主机名加入到hosts中，这样所有的pod都可以从coredns中解析各个节点的名字。

kubectl -n kube-system edit cm coredns

再查看日志出现错误2

#########错误2#########

metrics server支持一个参数 --kubelet-insecure-tls，可以跳过这一检查，但是官方并不推荐这样使用。

启用TLS Bootstrap 证书签发

所有节点做以下操作

[root@server2 limit]# vim /var/lib/kubelet/config.yaml
serverTLSBootstrap: true         最后一行
systemctl restart kubelet

批准证书

服务拉起

调取API信息

配置一个阿里云的yum源安装jq

yum install jq -y

规则输出