开启 Kubernetes 监控并实施压力测试

1. Kubectl 基本命令

1.1 创建对象

1
2
3
4
5
6
7
8
# 创建资源，也可以使用远程 URL
kubectl create -f ./my.yaml
# 使用多个文件创建资源
kubectl create -f ./my1.yaml -f ./my2.yaml
# 使用目录下的所有清单文件来创建资源
kubectl create -f ./dir
# 启动一个 nginx 实例
kubectl run nginx --image=nginx

1.2 显示和查找资源

1
2
3
4
5
6
7
8
# 列出所有 namespace 中的 service
kubectl get services
# 列出所有 namespace 中的 pod
kubectl get pods --all-namespaces
# 列出 kube-system 中的 pod
kubectl get pods -n kube-system
# 列出所有 pod 并显示详细信息
kubectl get pods -o wide

1.3 更新资源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 滚动更新 pod frontend-v1
kubectl rolling-update frontend-v1 -f frontend-v2.json
# 更新资源名称并更新镜像
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
# 更新 frontend pod 中的镜像
kubectl rolling-update frontend --image=image:v2
# 强制替换，删除后重新创建资源。会导致服务中断。
kubectl replace --force -f ./pod.json
# 为 nginx RC 创建服务，启用本地 80 端口连接到容器上的 8000 端口
kubectl expose rc nginx --port=80 --target-port=8000

1.4 删除资源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 删除 pod.json 文件中定义的类型和名称的 pod
kubectl delete -f ./pod.json
# 删除名为 "baz" 的 pod 和名为 "foo" 的 service
kubectl delete pod, service baz foo
# 删除具有 name=myLabel 标签的 pod 和 serivce
kubectl delete pods, services -l name=myLabel
# 删除具有 name=myLabel 标签的 pod 和 service，包括尚未初始化的
kubectl delete pods, services -l name=myLabel --include-uninitialized
# 删除 my-ns namespace 下的所有 pod 和 serivce，包括尚未初始化的
kubectl -n my-ns delete po,svc --all

1.5 与运行中的 Pod 交互

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 流式输出 pod 的日志（stdout
kubectl logs -f my-pod
# 流式输出 pod 中容器的日志（stdout，pod 中有多个容器的情况下使用）
kubectl logs -f my-pod -c my-container
# 交互式 shell 的方式运行 pod
kubectl run -i --tty busybox --image=busybox -- sh
 # 连接到运行中的容器
kubectl attach my-pod -i
# 在已存在的容器中执行命令（pod 中有多个容器的情况下）
kubectl exec my-pod -c my-container -- ls /

2. Dashboard 简介

Kubernetes Dashboard 是一个管理 Kubernetes 集群的全功能 Web 界面，旨在以 UI 的方式完全替代命令行工具（kubectl 等）。

在 Dashboard 页面上，可以查看 Kubernetes 的集群状态，对集群进行相关的操作。但是，Dashboard 无法图形化展现集群度量指标信息，需要安装 Heapser 插件。

下面来了解一下 Kubernetes 的监控系统，并配置监控试试。

3. 监控系统

架构图如下：

cAdvisor，是 Kubelet 内置的容器资源收集工具。它会自动收集本机容器 CPU、内存、网络和文件系统的资源占用情况，并对外提供 API。
InfluxDB，是一个开源分布式时序、事件和指标数据库。
Grafana，是 InfluxDB 的 Dashboard，提供了强大的图表展示功能。常和 InfluxDB 组合使用，展示图表化的监控数据。
Heapster，提供了整个集群的资源监控，并支持持久化数据存储到 InfluxDB 等后端存储。
kube-state-metrics，除了配置 cAdvisor、Heapster、Influx、Grafana，还可以考虑部署 kube-state-metrics。kube-state-metrics 会轮询 Kubernetes API 调度了多少个replicas、现在可用的有几个、多少个 Pod 是 running、stopped、terminated 状态、Po 重启了多少次。

4. 配置监控

获取官方配置 yaml：

1
2
3
4
5
6
git clone https://github.com/kubernetes/heapster.git
# 查看 yaml 配置列表
ls -l deploy/kube-config/influxdb/
grafana.yaml
heapster.yaml
influxdb.yaml

Heapster、InfluxDB、Grafana 均以 Pod 的形式启动和运行，创建 Pod：

1
2
3
4
5
6
7
8
kubectl create -f deploy/kube-config/influxdb/
deployment.extensions/monitoring-grafana created
service/monitoring-grafana created
serviceaccount/heapster created
deployment.extensions/heapster created
service/heapster created
deployment.extensions/monitoring-influxdb created
service/monitoring-influxdb created

可能需要等待几分钟，Pod 才会处于 Running 状态：

1
2
3
4
5
kubectl get pods -n kube-system
NAME                                    READY     STATUS    RESTARTS   AGE
heapster-7ff8d6bf9f-ngb9p               1/1       Running   0          31m
monitoring-grafana-68b57d754-4qwjm      1/1       Running   0          31m
monitoring-influxdb-cc95575b9-5j556     1/1       Running   0          31m

配置完毕之后，发现 Dashboard 并没有显示 CPU、内存等信息，查看 Heapser 日志：

1
2
kubectl logs -f heapster-7ff8d6bf9f-ngb9p  -n kube-system
1 reflector.go:190] k8s.io/heapster/metrics/util/util.go:30: Failed to list *v1.Node: nodes is forbidden: User "system:serviceaccount:kube-system:heapster" cannot list nodes at the cluster scope

提示缺角色，无权访问。新增授权：

1
2
kubectl create -f deploy/kube-config/rbac/heapster-rbac.yaml
clusterrolebinding.rbac.authorization.k8s.io/heapster created

更新 Heapser：

1
kubectl replace --force -f deploy/kube-config/influxdb/heapster.yaml

再次查看 Dashboard，Nodes 和 Pods 中，可以非常直观的看到 CPU 和 MEM 的使用情况。

5. 压力测试

下面 Apache 提供的 ab 工具，对 Kubernetes 托管的 Nginx 服务进行简单的压力测试实验。

5.1 安装 Apache

安装 Apache 可以使用 Chocolatey ，也可以使用官方提供的 Windows 安装包。

1
choco install apache-httpd

5.2 执行测试

硬件配置：

CPU，i7-4790，3.6G，4 核 8 线程
MEM，16 GB
VirtualBox，5.2.8

分配给 minikube 虚拟机 2 核 CPU，2 GB MEM

软件版本：

Windows 7
Minikube 0.28.2
Nginx 1.15.4
ApacheBench 2.3

压测开始后，在 Dashboard 看到 CPU 和内存使用量也陡增。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
ab -c 125 -n 400000 http://192.168.99.100:31925/
//并发请求数
Concurrency Level:      125
//整个测试持续的时间
Time taken for tests:   317.350 seconds
//完成的请求数
Complete requests:      400000
//失败的请求数
Failed requests:        0
//吞吐率
Requests per second:    1260.44 [#/sec] (mean)
//用户平均请求等待时间
Time per request:       99.172 [ms] (mean)
//服务器平均请求处理时间
Time per request:       0.793 [ms] (mean, across all concurrent requests)

一个 Pod

并发请求数	125	250	500	1000
持续时间(second)	317	265	313	338
吞吐率(/second)	1260	1508	1276	1182
用户平均请求等待时间(ms)	99	165	391	845
服务器平均处理时间（ms）	0.79	0.66	0.78	0.845

两个 Pod

并发请求数	125	250	500	1000
持续时间(second)	329	311	337	375
吞吐率(/second)	1213	1284	1186	1065
用户平均请求等待时间(ms)	102	194	421	938
服务器平均处理时间（ms）	0.824	0.778	0.843	0.939

从上面的表格可以看到，在一定的硬件环境下，Nginx 服务：

增加 Pod 数量，并不能显著增加服务质量（吞吐率和用户等待时间）