文章图片
转自@twt社区，作者：李志伟
随着容器化、分布式的不断发展，业务系统的逻辑变得复杂，定位问题越来越困难，就需要从宿主机、容器管理平台和容器应用等多个层面进行监控，才可以定位性能问题、异常问题、安全问题等。本文介绍容器管理平台（k8s）的监控方法。
监控方式
容器类监控一般采用Prometheus进行监控，支持默认的pull模式获取数据，这也是官方推荐的方式。但是如果一些网络或防火墙等原因无法直接pull到数据的情况，就要借助Pushgateway让Prometheus转换为push方式获取数据；又比如我们将prometheus搭建在外网去监控内网应用的情况下，由于内网有诸多安全限制使得无法穿透，这时就要借助push模式来解决问题，还有就是监控的轮询监控大于被监控程序的执行时间，比如5秒pull一次数据，但是被监控程序1秒就执行完了。如下为pull和push的通用比较：
Pull
实时性取决于定时任务；客户端是有状态，需要知道拉取点，服务器端无状态，通常是短连接；难点实时性和流量的取舍。
Push
实时性较好；客户端无状态，服务器端有状态，需要了解每个客户端的推送点；通常是长链接；难点客户端能力和push能力不匹配问题。
K8s集群监控
使用系统命令查看kubectl top pod --all-namespaces
使用prometheus查询语句
sum(kube_pod_container_resource_limits{resource="cpu", unit="core", namespace="$Namespace"})
CPU usage / available CPU in cluster
sum (rate (container_cpu_usage_seconds_total{namespace="$Namespace"}[1m])) / sum(machine_cpu_cores) * 100
Kube_namespaces_cpu_used_percent >80%
Kube_namespaces_memory_memused_bytes_percebt>80%
Kube_namespaces_requests_cpu_percent>80%
Kube_namespaces_requests_memory_percent>80%
Pod监控项
资源限制
spec:
containers:
- image: http://gcr.io/google_containers/serve_hostname
name: kubernetes-serve-hostname
resources:
limits:
cpu: “1”
memory: 512Mi
requests:
cpu: “1”
memory: 512Mi
Pod Metrics
文章图片
文章图片
文章图片
文章图片
监控项举例：
Kube_pod_container_limit_cpu_cores>2
Node节点监控及告警
命令Kubectl get nodes
连续5分钟node状态是非ready，与master节点失联，最大告警2次
先检查状态
Systemctl status kubelet
Systemctl restart kubelet
守护进程（daemonset）监控
Kube_daemonset_statsu_number_unavailable>0 不可用pod数大于0
Kube_daemonset_current_number_normal==0 daemonset的pod与期望
Kube_daemonset_updated_number_normal==0 daemonset已更新与期望
守护进程监控项
无状态应用监控
Kube_deployment_status_replicas_unavailable>0 不可用副本数大于0
Kube_deployment_current_replicas_normal==0 当前副本数与期待副本数不一致
Kube_deployment_updated_replicas_normal==0 updateed副本数与期望副本数不一致。
Kubectl get deploy busybox
有状态应用监控
有状态核心告警
Kube_statefulset_replicas_ready_normal==0 副本是否与期望副本一致
Kube_statefulset_replicas_current_normal==0 当前副本与期望
查看未正常运行的pod的状态和事件，查看kubeclt deploy状态和事件
负载均衡器监控
应用访问通过ingress controller转发到ingress，再转发到具体的服务，最后转到具体的pod。因此ingress 监控至关重要。
文章图片
URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等，从这些信息中，我们能够分析出非常多的信息，例如：
1.网站访问的PV、UV；
2.网站访问的错误比例；
3.后端服务的响应延迟；
4.不同URL访问分布。
主要监控指标：
文章图片
文章图片
监控metric
文章图片
事件监控
事件监控是Kubernetes中的另一种监控方式，可以弥补资源监控在实时性、准确性和场景上的缺欠。
Kubernetes的架构设计是基于状态机的，不同的状态之间进行转换则会生成相应的事件，正常的状态之间转
换会生成Normal等级的事件，正常状态与异常状态之间的转换会生成Warning等级的事件。通过获取事件，实时诊断集群的异常与问题。
Pod常见问题列表：
- ImagePullBackOff
- CrashLoopBackOff
- RunContainerError
- 处于Pending状态的Pod
- 处于未就绪状态的Pod
【k8s|干货丨如何进行容器管理平台监控（k8s）】当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。
可能原因：
- 镜像名称无效，例如拼错镜像名称，或者镜像不存在。
- 您为image指定了不存在的标签。
- 您检索的镜像是私有registry，而Kubernetes没有凭据可以访问它。
- 前两种情况可以通过修改镜像名称和标记来解决该问题。
- 第三种情况，您需要将私有registry的访问凭证，通过Secret添加到Kubernetes中并在Pod中引用它。
如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。
可能原因：
- 应用程序中存在错误，导致无法启动。
- 未正确配置容器。
- Liveness探针失败太多次。
- 您可以尝试从该容器中检索日志以调查其失败的原因。如果容器重新启动太快而看不到日志，则可以使用命令：$ kubectl logs –previous。
当容器无法启动时，出现此错误。
可能原因：
- 挂载不存在的卷，例如ConfigMap或Secrets。
- 将只读卷安装为可读写。
- 请使用kubectl describe pod命令收集和分析错误。
当创建应用时，在变更记录中该Pod一直Pending状态。
可能原因：
- 集群没有足够的资源（例如CPU和内存）来运行Pod。
- 当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额。
- 该Pod绑定到一个处于pending状态的PersistentVolumeClaim。
- 检查$ kubectl describe pod命令输出的“事件”部分内容或者在控制台查看应用事件。
- 对于因ResourceQuotas而导致的错误，可以使用$ kubectl get events–sort-by=.metadata.cre-ationTimestamp命令检查集群的日志。
如果Pod正在运行但未就绪（not ready），则表示readiness就绪探针失败。
可能原因：
- 当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。
- 就绪探针失败是应用程序的特定错误，请检查$ kubectl describe pod命令输出的“事件”部分内容，或者在控制台查看对应的应用事件。
推荐值
文章图片
推荐阅读
- k8s|干货丨k8s 集群优化之监控平台的建立
- 云计算|PaaS-云计算实时性能监控工具(netdata)
- 服务器|Arm、Intel 和 AMD 服务器 CPU未来2年市场发展分析
- linux|第三阶段.Linux+arm
- java|www.xttblog.com尚硅谷Java视频教程_SpringBoot视频教程
- java|业余草尚硅谷Java视频教程_SpringBoot视频教程免费下载
- 大白话mysql|大白话mysql之深入浅出索引原理 - 下
- 小技巧|csrf和ssrf的区别
- 路由交换|ensp 查看配置命令