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 数量，并不能显著增加服务质量（吞吐率和用户等待时间）
6. 参考
