docker中容器资源需求、资源限制及HeapSter的示例分析
这篇文章主要介绍了docker中容器资源需求、资源限制及HeapSter的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
容器的资源需求、资源限制
request:需求，最低保障，在调度时，这个节点必须要满足request需求的资源大小。
limits:限制、硬限制。这个限制容器无论怎么运行都不会超过limits的值。
CPU：在k8s的一个cpu对应一颗宿主机逻辑cpu。一个逻辑cpu还可以划分为1000个毫核（millcores）。所以500m=0.5个CPU，0.5m相当于二分之一的核心。
内存的计量单位：E、P、T、G、M、K
[root@master scheduler]# kubectl explain pods.spec.containers.resources.requests[root@master scheduler]# kubectl explain pods.spec.containers.resources.limits
[root@master metrics]# cat pod-demo.yaml apiVersion: v1kind: Podmetadata: name: pod-demo labels: app: myapp tier: frontendspec: containers: - name: myapp image: ikubernetes/stress-ng:v1 command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "--metrics-brief"] #-m 1表示启动一个子进程对内存做压测，-c 1表示启动一个子进程对cpu做压测.默认stress-ng的一个子进程使用256M内存 resources: requests: cpu: "200m" memory: "128Mi" limits: cpu: "1" #没有单位表示是1个cpu memory: "200Mi"
[root@master metrics]# kubectl apply -f pod-demo.yaml pod/pod-demo created
[root@master metrics]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODEpod-demo 1/1 Running 0 6m 10.244.2.48 node2
[root@master metrics]# kubectl exec -it pod-demo -- /bin/sh/ # topMem: 3542328K used, 339484K free, 123156K shrd, 3140K buff, 1737252K cachedCPU: 21% usr 4% sys 0% nic 73% idle 0% io 0% irq 0% sirqLoad average: 1.31 1.00 0.74 4/968 1405 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 8 1 root R 6884 0% 1 15% {stress-ng-cpu} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief 1404 9 root R 262m 7% 3 12% {stress-ng-vm} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief 9 1 root S 6244 0% 2 0% {stress-ng-vm} /usr/bin/stress-ng -m 1 -c 1 --metrics-brief 1 0 root S 6244 0% 0 0% /usr/bin/stress-ng -m 1 -c 1 --metrics-brief 1202 0 root S 1508 0% 0 0% /bin/sh 1405 1202 root R 1500 0% 0 0% top我们对容器分配了资源限制后，k8s会自动分配一个Qos，叫服务质量，通过kubectl describe pods xxx可以看到这个字段。
Qos可以分为三类：
Guranteed：表示每个容器的cpu和内存资源设置了相同的requests和limits值，即cpu.requests=cpu.limits和memory.requests=memory.limits，Guranteed会确保这类pod有最高的优先级，会被优先运行的，即使节点上的资源不够用。
Burstable:表示pod中至少有一个容器设置了cpu或内存资源的requests属性，可能没有定义limits属性，那么这类pod具有中等优先级。
BestEffort：指没有任何一个容器设置了requests或者limits属性，那么这类pod是最低优先级。当这类pod的资源不够用时，BestEffort中的容器会被优先终止，以便腾出资源来，给另外两类pod中的容器正常运行。
HeapSter
HeapSter的作用是收集个节点pod的资源使用情况，然后以图形界面展示给用户。
kubelet中的cAdvisor负责收集每个节点上的资源使用情况，然后把信息存储HeapSter中，HeapSter再把数据持久化的存储在数据库InfluxDB中。然后我们再通过非常优秀的Grafana来图形化展示。
一般我们监控的指标包括k8s集群的系统指标、容器指标和应用指标。
默认InfluxDB使用的是存储卷是emptyDir，容器一关数据就没了，所以我们生产要换成glusterfs等存储卷才行。
InfluxDB： https://github.com/kubernetes/heapster/blob/master/deploy/kube-config/influxdb/influxdb.yaml
[root@master metrics]# wget https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/influxdb.yaml
[root@master metrics]# kubectl apply -f influxdb.yaml deployment.extensions/monitoring-influxdb createdservice/monitoring-influxdb created
[root@master metrics]# kubectl get svc -n kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEmonitoring-influxdb ClusterIP 10.100.80.218086/TCP 17s
[root@master metrics]# kubectl get pods -n kube-systemNAME READY STATUS RESTARTS AGEmonitoring-influxdb-848b9b66f6-ks69q 1/1 Running 0 10m
[root@master metrics]# kubectl log monitoring-influxdb-848b9b66f6-ks69q -n kube-system
这样我们就部署好了influxdb。
下面我们开始部署heapster，但heapster依赖rbac。
所以我们先部署rbac，访问 https://github.com/kubernetes/heapster/tree/master/deploy/kube-config/rbac
[root@master metrics]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/rbac/heapster-rbac.yamlclusterrolebinding.rbac.authorization.k8s.io/heapster created
所以下面我就可以部署heapster了。
访问 https://github.com/kubernetes/heapster/blob/master/deploy/kube-config/influxdb/heapster.yaml
[root@master ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/heapster.yamlserviceaccount/heapster createddeployment.extensions/heapster createdservice/heapster created
[root@master ~]# kubectl get svc -n kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEheapster ClusterIP 10.100.35.11280/TCP 1m
[root@master ~]# kubectl get pods -n kube-system -o wideNAME READY STATUS RESTARTS AGE IP NODEheapster-84c9bc48c4-8h7vf 1/1 Running 0 9m 10.244.1.63 node1
[root@master ~]# kubectl logs heapster-84c9bc48c4-8h7vf -n kube-system
上面我们把heapster组件装完了，下面我们再装Grafana。
访问 https://github.com/kubernetes/heapster/blob/master/deploy/kube-config/influxdb/grafana.yaml
我们为了能在集群外部访问Grafana，所以我们需要定义NodePort，所以在granfana.yaml文件最后一行加个type: NodePort
[root@master ~]# wget https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/grafana.yaml
[root@master ~]# tail grafana.yaml # or through a public IP. # type: LoadBalancer # You could also use NodePort to expose the service at a randomly-generated port # type: NodePort ports: - port: 80 targetPort: 3000 selector: k8s-app: grafana type: NodePort
[root@master ~]# kubectl apply -f grafana.yaml deployment.extensions/monitoring-grafana createdservice/monitoring-grafana created
[root@master ~]# kubectl get svc -n kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEheapster ClusterIP 10.100.35.11280/TCP 22mkube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 37dkubernetes-dashboard NodePort 10.104.8.78 443:31647/TCP 16dmonitoring-grafana NodePort 10.96.150.141 80:30357/TCP 2mmonitoring-influxdb ClusterIP 10.100.80.21 8086/TCP 11h
[root@master ~]# kubectl get pods -n kube-systemNAME READY STATUS RESTARTS AGEmonitoring-grafana-555545f477-qhb28 1/1 Running 0 5m
打开浏览器，访问宿主机ip：http://172.16.1.100:30357
据说在v1.12中，已经完全抛弃了heapster。
root@master ~]# kubectl top nodes[root@master ~]# kubectl top pod
按理说执行上面的两个命令可以出结果，但是k8s从v1.11后不能用了，也无可奈何。
感谢你能够认真阅读完这篇文章，希望小编分享的"docker中容器资源需求、资源限制及HeapSter的示例分析"这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!
