关于k8s:干货丨如何进行容器管理平台监控k8s

48次阅读

共计 3350 个字符，预计需要花费 9 分钟才能阅读完成。

转自 @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 就绪探针失败。

可能起因：