转自@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

imagePullPolicy: Always

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

ImagePullBackOff

当Kubernetes无奈获取到Pod中某个容器的镜像时，将呈现此谬误。

可能起因：

  • 镜像名称有效，例如拼错镜像名称，或者镜像不存在。
  • 您为image指定了不存在的标签。
  • 您检索的镜像是公有registry，而Kubernetes没有凭据能够拜访它。

解决办法：

  • 前两种状况能够通过批改镜像名称和标记来解决该问题。
  • 第三种状况，您须要将公有registry的拜访凭证，通过Secret增加到Kubernetes中并在Pod中援用它。

CrashLoopBackOff

如果容器无奈启动，则Kubernetes将显示谬误状态为：CrashLoopBackOff。

可能起因：

  • 应用程序中存在谬误，导致无奈启动。
  • 未正确配置容器。
  • Liveness探针失败太屡次。

解决办法:

  • 您能够尝试从该容器中检索日志以考察其失败的起因。如果容器重新启动太快而看不到日志，则能够应用命令：$ kubectl logs <pod-name>--previous。

RunContainerError

当容器无奈启动时，呈现此谬误。

可能起因：

  • 挂载不存在的卷，例如ConfigMap或Secrets。
  • 将只读卷装置为可读写。

解决办法：

  • 请应用kubectl describe pod命令收集和剖析谬误。

处于Pending状态的Pod

当创立利用时，在变更记录中该Pod始终Pending状态。

可能起因：

  • 集群没有足够的资源（例如CPU和内存）来运行Pod。
  • 以后的命名空间具备ResourceQuota对象，创立Pod将使命名空间超过配额。
  • 该Pod绑定到一个处于pending状态的PersistentVolumeClaim。

解决办法：

  • 查看$ kubectl describe pod<pod name>命令输入的“事件”局部内容或者在控制台查看利用事件。
  • 对于因ResourceQuotas而导致的谬误，能够应用$ kubectl get events--sort-by=.metadata.cre-ationTimestamp命令查看集群的日志。

处于未就绪状态的Pod

如果Pod正在运行但未就绪（not ready），则示意readiness就绪探针失败。

可能起因：

  • 当“就绪”探针失败时，Pod未连贯到服务，并且没有流量转发到该实例。

解决办法：

  • 就绪探针失败是应用程序的特定谬误，请查看$ kubectl describe pod<pod name>命令输入的“事件”局部内容，或者在控制台查看对应的利用事件。

监控指标阈值

推荐值