Kubernetes-容器资源限制、容器资源监控、Dashboard部署(可视化)

一.kubernetes容器资源限制

Kubernetes采用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为换算标准的。

1.内存限制

在server1上：
我们先讲需要的镜像上传到我们的私有仓库：

[root@server1 harbor]# docker pull progrium/stress
[root@server1 harbor]# docker tag progrium/stress:latest reg.westos.org/library/stress:latest
[root@server1 harbor]# docker push reg.westos.org/library/stress

创建一个目录limit 用来存放文件：

cd
mkdir limit
cd limit/
vim 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   ##限制200M 

执行清单pod.yaml，查看节点pod,查看日志
我们一猜它就不会执行成功，因为内存限制为50-100MI
但是却要求创建200M的内存！

[root@server2 limit]# kubectl apply -f pod.yaml 
[root@server2 limit]# kubectl get pod 
[root@server2 limit]# kubectl logs memory-demo

如果容器超过其内存限制，则会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。
所以它会一直重启！

我们删除pod节点，修改上限内存为300M，再次执行清单，并查看pod节点信息：

kubectl delete -f pod.yaml
vim pod.yaml
kubectl apply -f pod.yaml
kubectl get pod

实验完成之后，将刚才的pod.yaml清除

kubectl delete -f pod.yaml

2.CPU限制

vim pod1.yaml

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

执行清单pod1.yaml
肯定无法执行，因为虚拟机就两个cpu！
所以无法满足需求！

kubectl apply -f pod1.yaml
kubectl get pod

更改cpu限制的上下限，清除po1.yaml，再次执行清单，并查看pod节点！

kubectl delete -f po1.yaml


vim pod1.yaml
cpu: "2"
cpu: "0.1"

kubectl apply -f po1.yaml
kuybectl get pod

3.namespace设置资源限制

root@server2 limit]# vim 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,查看信息：

[root@server2 limit]# kubectl apply -f limitrange.yaml 

[root@server2 limit]# kubectl get limitranges 

[root@server2 limit]# kubectl describe limitranges limitrange-demo 

将前面的内存限制pod.yaml清单修改一下：
去掉之前的限制：

vim pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: nginx

执行清单,并查看limitranges的信息：
可以看到会使用limitrange.yaml的内存和cpu限制！

kubectl apply -f pod.yaml 

kubectl describe limitranges limitrange-demo

将内存限制打开：

再次执行pod.yaml 清单。会发现报错了：
因为namespace的限制最小为100M，而内存限制最小为50M，所以冲突了！

kubectl delete -f pod.yaml 
kubectl apply -f pod.yaml 

4.namespace设置资源配额

再次将namespace设置资源配额：

vim limitrange.yaml

apiVersion: v1 
kind: ResourceQuota 
metadata:  
  name: mem-cpu-demo 
spec:  
  hard:    
    requests.cpu: "1"    ##所有容器的cpu请求总额不能超过1核
    requests.memory: 1Gi    ##所有容器的内存请求总额不能超过1GIB
    limits.cpu: "2"    	##所有容器的cpu限额总额不能超过2核
    limits.memory: 2Gi##所有容器的内存限额总额不能超过2GIB

执行配额清单limitrange.yaml
并将其中的资源限制清除：

 kubectl apply -f limitrange.yaml
 kubectl delete limitranges limitrage-memory
 kubectl get limitranges
  kubectl get resourcequotas

 

如果将内存限制注释，那么执行清单pod.yaml的时候会报错如下图：

vim pod.yaml

kubectl apply -f pod.yaml

打开内存限制，并加入cpu限制：

vim pod.yaml

apiVersion: v1 
kind: Pod 
metadata:  
  name: memory-demo 
spec:  
  containers:  
  - name: memery-demo    
    image: nginx       
    resources:
      requests:
        memory: 50Mi
        cpu: 0.1
      limits:
        memory: 300Mi
        cpu: 0.5

可以看到配额的大小上下限和pod.yaml文件中指定的一样！

kubectl apply -f pod.yaml
kubectl describe resourcequotas 

执行配额清单：

将pod.yaml中的限制再次注释，改名为memory-demo-2

执行pod.yaml清单

kubectl apply -f pod.yaml

可以看到查看道德配额大小发生了变化：

kubectl describe resourcequotas 

再次更改pod.yaml，打开限制，改名为memory-demo-3

执行清单，并查看配额

kubectl apply -f pod.yaml
kubectl describe resourcequotas 

我们可以发现，它的配额是在不断累加的，直至达到最大限制为之！！

5. Namespace 配置Pod配额

vim limitrange.yaml

 
apiVersion: v1 
kind: ResourceQuota 
metadata:  
  name: mem-cpu-demo 
spec:  
  hard:    
    requests.cpu: "1"    
    requests.memory: 1Gi    
    limits.cpu: "2"    
    limits.memory: 2Gi
    pods: "3"	##pod最多建立3个

执行清单limitrange.yaml，查看配额信息，可以看到配置Pod配额出现：

kubectl describe resourcequotas 

实验完成之后，删除pod节点和配额：

kubectl delete pod --all
kubectl delete -f limitrange.yaml

kubectl get limitranges

二. kubernetes资源监控

1.Metrics-Server介绍

Metrics-Server是集群核心监控数据(cpu、内存)的聚合器，用来替换之前的heapster。

容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务，有了MetricsServer之后，用户就可以通过标准的 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等组件来完成。

2.Metrics-Server安装部署

mkdir metrics-server
cd metrics-server/
ls
wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

在server1上：
接下来将需要的镜像拉取下来上传到私有仓库中：

[root@server1 harbor]# docker pull bitnami/metrics-server:0.5.0 ##拉取镜像，后面可以指定版本，最新的0.4.2
[root@server1 harbor]# docker tag bitnami/metrics-server:0.5.0 reg.westos.org/library/metrics-server:v0.5.0   ##修改名字
[root@server1 harbor]# docker push reg.westos.org/library/metrics-server:v0.5.0  ##上传镜像

接下来将刚才wget下来的components.yaml文件编辑：
修改镜像名：

vim components.yaml

image: metrics-server:0.5.0

执行文件components.yaml，查看节点信息：

kubectl apply -f components.yaml 
kubectl get pod -n kube-system

发现没有就绪！

3.解决报错

3.1 错误一

查看日志的报错，解决问题：
需要再次修改清单配置：
将两处的端口改为4443

vim components.yaml

--secure-port=4443

- containerPort: 4443

3.2 错误二

这时如果执行清单，还是会无法运行，因为还有问题没有解决
解决报错：
报错：x509: certificate signed by unknown authority

启用TLS Bootstrap 证书签发(在master和各个节点中)

在server2,3,4都需要修改
添加参数：

vim /var/lib/kubelet/config.yaml

serverTLSBootstrap: true
添加之后，重启服务！
systemctl restart kubelet

刚才修改了server2的，server3,4都需要修改，重启服务，就不截图了！！

kubectl get csr
kubectl certificate approve csr-***
kubectl certificate approve csr-***
kubectl certificate approve csr-***

kubectl get csr

3.3 错误三

报错：dial tcp: lookup server2 on 10.96.0.10:53: no such host
这是因为没有内网的DNS服务器，所以metrics-server无法解析节点名字。可以直接修改 coredns的configmap，将各个节点的主机名加入到hosts中，这样所有Pod都可以从 CoreDNS中解析各个节点的名字。

kubectl -n kube-system edit cm coredns

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        hosts {
           172.25.0.2 server2
           172.25.0.3 server3
           172.25.0.4 server4
           fallthrough
        }

再次查看pod节点信息，发现恢复运行了！

kubectl -n kube-system get pod   ##查看是否running

kubectl -n kube-system describe svc metrics-server

发现endpoints后端IP地址也出现了！！

4.测试

测试：
#查看pod分配情况

kubectl top node  ##查看pod分配情况
或者用 kubectl -n kube-system top pod 

三.Dashboard部署(可视化)

Dashboard可以给用户提供一个可视化的 Web 界面来查看当前集群的各种信息。用户可以用 Kubernetes Dashboard 部署容器化的应用、监控应用的状态、执行故障排查任务以及管理 Kubernetes 各种资源。

首先拉取需要的 拉取镜像！

[root@server1 harbor]# docker pull kubernetesui/dashboard:v2.3.1
[root@server1 harbor]# docker tag kubernetesui/dashboard:v2.3.1 reg.westos.org/library/kubernetesui/dashboard:v2.3.1
[root@server1 harbor]# docker push reg.westos.org/library/kubernetesui/dashboard:v2.3.1

创建目录dashboard用来存放关于它的文件：
下载所需要的配置文件：recommended.yaml

cd 
mkdir dashboard
cd dashboard/
ls
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml

下载之后，需要将文件中的镜像地址和版本写对即可！

vim recommended.yaml

image: kubernetesui/dashboard:v2.3.1

修改之后，执行文件：

kubectl apply -f recommended.yaml 
 kubectl get ns 
 

此时查看节点，发现没有IP地址

kubectl -n kubernetes-dashboard get all
kubectl -n kubernetes-dashboard get svc

更改svc kubernetes-dashboard的网络类型为

kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard

type: LoadBalancer

再次查看svc ，可以看到分配的vip

 kubectl -n kubernetes-dashboard get svc 
 kubectl -n metallb-system get all

访问刚才查看的svc出现的外部IP地址：

https://172.25.0.11

点击允许访问，之后登陆会需要token
我们可以查看刚才生成的tocken！！

 kubectl -n kubernetes-dashboard get secrets 
  kubectl -n kubernetes-dashboard describe secrets kubernetes-dashboard-token-***

看到有tocken,复制它！

粘贴进去

登陆之后，可以看到很多警告信息如下图：

是因为没有授权所以会报错，解决授权！！

1.授权

vim rbac.yaml 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard

执行rbac.yaml 清单：

kubectl apply -f rbac.yaml 

再次访问网页
选择全部命名空间，可以查看到监控：

接下来我们试着创建一个节点：
点击右上角的+号：

选择从表单创建：

我们可以看到创建成功了！

2.测试

我们也可以在shell端，查看pod节点信息：
访问IP可以看到myapp:v1版本！

kubectl get pod
kubectl get pod -o wide
curl 10.244.141.206

自己也可以 尝试在web端再次创建其他节点或者删除节点，我这里不做展示！！