容器云平台如何进行日常巡检？| 运维进阶

【导读】本文对容器和kubernetes容器云的日常巡检工作进行了整理，希望通过第三方开源工具和日志巡检的方式，提供排查方法和排查思路、典型案例，帮助大家学会尽快发现问题，排查问题，解决问题。【作者】曹如熙，上海逸橙网络科技有限公司， 高级运维leader。具有超过十年的互联网运维及五年以上团队管理经验，多年容器云的运维，尤其在docker和kubernetes领域非常精通。2020容器云职业技能大赛百位专家委员会成员。

1 docker容器日常巡检通过以下方式进行检查：
1.1 docker/podman ps查看容器状态Docker/podman ps -a 查看容器状态STATUS：Exited(0)：表示容器正常退出Exited(其他数字)：容器异常退出，需要通过log 查看原因Up：容器在运行状态Up(Paused)：容器暂停Up(healthy)：容器监听健康Up(unhealthy)：容器监听异常1.2 健康检查—HealthCheck一些参数需要docker 17.05以上支持1.2.1 通过docker run或者dockerfile添加健康检查例如：docker run --name=nginx --health-cmd="curl --silent --fail localhost/ || exit 1" --health-inter-val=30s --health-retries=3 --health-timeout=10s --start-period=60s nginx:latest--interval:两次健康检查的间隔，默认为 30 秒--timeout: 健康检查超时时间，，默认 30 秒--retries: 连续失败次数，默认 3 次。--start-period: 启动的初始化时间，默认 0 秒--health-cmd: shell和exec 格式，取命令的返回值结果0表示成功，1表示失败STATUS， healthy表示健康unhealthy表示不健康reserved保留值，不适用1.2.2 输出健康检查状态docker/podman inspect --format '{{json .State.Health}}' 容器名| python -m json.tool输出healthy表示健康，用户可以编写脚本监控容器状态做报警1.3 docker stats查看容器状态可以通过docker stats查看容器的cpu, 内存，网络，IO的使用情况1.4 通过第三方工具监听容器这里主要介绍prometheus+grafana+cadvisor1.4.1 prometheus介绍prometheus通过node-exporter收集node主机的信息可以看到up状态和unhealthy状态的node节点主机Unhealthy表示node节点node-exporter异常Prometheus是一款强大的第三方工具，除了docker容器监控，还支持mysq，数据仓库，Hadoop，k8s 等开源系统1.4.2 cadvisor介绍Google的开源cadvisor,帮助收集，监听容器的status和数据，主要是CPU, 内存，FS，网络等usage1.4.3 grafana介绍Grafana作为展示prometheus和cadvisor的数据，也可以实现自定义规则报警。（可以去grafana官网搜寻需要监控的模板）可以通过dashboard展示node主机上的所有容器通过panel，metrics自定义需要收集的容器数据通过自定义规则统计需要收集的容器数据，也可以统计宕机状态的容器Grafana支持自定义报警功能如果是大量的容器监控报警，建议使用alertmanager做报警1.5 docker容器的日志检查Docker的日志分为两类，一类是 Docker引擎日志；另一类是容器日志。引擎日志一般都交给了系统日志。容器日志可以理解是运行在容器内部的应用输出的日志。默认情况下，docker logs显示当前运行的容器的日志信息，内容包含 STOUT(标准输出) 和 STDERR(标准错误输出)。日志都会以 json-file的格式存储于 /var/lib/docker/containers/<容器id>/<容器id>-json.logCRIO的日志，存放在/var/log/containers/通过docker/podman logs命令查看容器的日志查看最近1小时日志docker/podman logs --since 60m容器名查看某时间段日志docker/podman logs -t --since="" --until "" 容器名建议：docker/podman run时候，日志文件-v到宿主机上，docker/podman run -d --name xxx -v /opt/log:/log xxx:latest通过elk去抓取宿主机上的日志，尽量不要通过docker logs去检查容器日志。除了docker容器，本文也向大家介绍kubernetes的日常巡检。

2 Kubernetes/OpenShift日常巡检

Kubernetes集群主要通过kubectl命令行进行运维，OpenShift中使用oc命令行进行运维。两个命令行的参是相同的（OpenShift集群也提供kubectl命令行，但建议使用oc命令行）。

2.1 检查master

主要通过以下命令检查。

2.1.1 kubectl/oc 检查master状态

kubectl/oc get cs

通过以上方法，查看kube-scheduler,  kube-controller-manager,  etcd是否正常。在上图status列，Healthy表示健康，unhealthy表示有问题需要更详细的信息，可以使用kubectl/oc describe cs，输出更详细的信息。

systemctl status calico.service

检查calico网络是否正常

systemctl status kube-apiserver.service

检查kube-apiserver 是否都是active状态

Active: active (running)

如果状态不正常，需要systemctl restart kube-apiserver

如果起不来，需要journalctl -xe查日志看下具体问题

2.1.2 kubectl/oc logs 检查master日志

kubectl/oc logs --tail 100 -f kube-apiserver -n kube-system

kubectl/oc logs --tail 100 -f kube-controllers -n kube-system

kubectl/oc logs --tail 100 -f kube-scheduler -n kube-system

kubectl/oc logs --tail 100 -f coredns -n kube-system

检查master服务日志是否正常

kubectl/oc logs --tail 100 -f calico-kube-controllers -n kube-system

检查calico是否正常

以下是node巡检

2.2 检查node

2.2.1 kubectl/oc检查node状态

kubectl/oc get node -n namespace

查看Node节点状态， STATUS Ready表示正常，NotReady不正常

注意version必须保持一致

如有NotReady问题，需要重启节点kubectl/oc，或者重启docker

如不能解决，需要reset节点后，k8s重新join该node(注意先执行kubectl/oc drain node --delete-lo-cal-data 驱离node)

systemctl status kubelet.service

systemctl status kube-proxy.service

检查状态是否是Active: active (running)

如果不正常，需要systemctl restart

如果起不来，需要journalctl -xe查日志看下具体问题

2.2.2 kubectl/oc logs检查node日志

kubectl/oc logs --tail 100 -f kube-proxy -n kube-system

kubectl/oc logs --tail 100 -f kebelet -n kube-system

检查node服务日志是否正常

kubectl/oc logs --tail 100 -f calico-node -n kube-system

检查calico节点是否正常

2.3 检查service

kubectl/oc get svc -o wide

查看k8s集群service信息

kubectl/oc get svc --all-namespaces -o wide

查看k8s所有service信息

TYPE是NodePort的service， k8s集群外部可以通过port访问

Service的TYPE包括 NodePort, ClusterIP, Loadbalance和ExternalName

以下是pod巡检

2.4 检查pod

2.4.1 kubectl/oc检查pod状态

kubectl/oc get pods -n namespace -o wide

查看STATUS状态是否正常

以下是status list：

Running，Succeeded，Waiting，ContainerCreating，Failed，Pending，Terminating，unknown，CrashLoopBackOff，ErrImagePull，ImagePullBackOff

status定义说明：

如出现异常状态，可查看pod日志内容

kubectl/oc describe pod 容器名 -n namespace

查看Conditions状态

True 表示成功，False表示失败

Initialized pod 容器初始化完毕

Ready pod 可正常提供服务

ContainersReady 容器可正常提供服务

PodScheduled pod 正在调度中，有合适的节点就会绑定，并更新到etcd

Unschedulable pod 不能调度，没有找到合适的节点

如有False状态显示

查看Events信息

Reason显示Unhealthy异常，仔细查看后面的报错信息，有针对性修复

kubectl/oc get pods -n namespace -o wide

查看RESTARTS的次数是否为0

如果不是0，说明pod重启过，需要去日志检查原因

2.4.2 kubectl/oc logs 检查pod日志

kubectl/oc logs --tail 100 -f pod -n namespace

检查日志中有无异常

或者进入日志目录 /var/log/pods，找到容器id-json.log日志文件

也可以检查日志有无异常

2.5 pod health健康检测

针对pod容器增加health check健康检测，pod.yaml中增加以下参数

livenessProbe是检测容器是否存活，running状态，如果不健康kubelet会kill pod，根据重启策略RestartPolicy执行重启pod。

ReadinessProbe判断容器是否处于Ready状态，ready状态表示pod可以接受请求，如果不健康，从service的后端endpoint列表中把pod驱离出去。

initialDelaySeconds 120表示pod初始化启动之后延迟120秒再开始检测等待pod内应用启动时间

timeoutSeconds表示超时时间

periodSeconds表示轮询时间

scheme连接使用的schema，默认HTTP,也支持TCP

successThreshold探测失败后，最少连续探测成功多少次被认定为成功。默认是1。对于liveness必须是1，最小值是1。

failureThreshold：探测成功后，最少连续探测失败多少次被认定为失败。默认是3，最小值是1。

超过failureThreshold的次数，pod重启多次后，pod STATUS状态会变更为不健康

2.6 通过dashborad检查

K8s支持dashboard管理方式

通过kubernetes-dashboard.yaml配置dashboard

通过firefox浏览器访问，https://k8sip:30443/#!/login

通过令牌方式访问，令牌查找方式，在master执行以下

kubectl/oc describe secret admin-token-xxxx -n kube-system

进入dashboard后，可以查看k8s所有资源状况

选择节点，可以查看node状态

可以查看node节点是否就绪状态，节点的CPU，内存资源使用状况

选择容器组，可以查看pod的状态信息

可以看到pod容器的状态

Dashboard也可以查看deployment，stateful, service，VP的状态信息

Dashboard的权限很高，可以创建容器，容器组，可以删除容器和容器组；

可以伸缩部署和副本集；可以创建，删除secret

2.7 通过kube-promtheus监控k8s

K8s监控需要考虑以下几方面

Kubernetes节点的监控：node节点的cpu、负载、内存、硬盘等指标

内部系统组件的状态：kube-scheduler、kube-controller-manager、kubedns/coredns等组件的运行状态

metrics：Deployment的状态、资源请求、调度和API延迟等数据指标

Kube-prom的组成如下

2.7.1 node-export监控

我们使用prometheus来监控k8s node状态和性能，采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目，比如cpu、distats、loadavg、meminfo、netstat等。

使用DeamonSet控制器来部署该pod，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展，

node-exporter.yaml样例如下：

执行kubectl get pod -n monitoring -o wide 或oc get pods -n openshift-monitoring -o wide（关于OpenShift命令行，本小节不再赘述）

可以查到node-exporter的pod状态在k8s节点上， curl 127.0.0.1:9100/metrics,可以获取到数据，说明成功收集

配置node-exporter-service.yaml

输入kubectl get svc -n monitoring -o wide |grep node

输出以下

表示service配置完成

2.7.2 kube-state-metrics

kube-state-metrics本质上是不断轮询api-server，kube-state-metrics关注于获取k8s各种资源的最新状态，如deployment或者daemonset，而kube-state-metrics是将k8s的运行状况在内存中做了个快照，并且获取新的指标。

配置kube-state-metrics-deployment.yaml样式

配置 kube-state-metrics-service.yaml

查看pod和svc

kubectl get pod -n monitoring -o wide |grep state

kubectl get svc -n monitoring -o wide |grep state

检查状态是否正常

2.7.3 grafana监控

我们使用grafana展示kube-prom的信息状态监控

grafana-deployment.yaml样式如下：

grafana-service.yaml样式如下：

查看grafana service pod

kubectl get pod,svc -n monitoring -o wide |grep grafana

访问grafana后台，浏览器访问http://ip:23000/login

（可以去grafana官网搜寻需要监控的模板）

可以查看k8s容器的内存，CPU等资源的使用率

可以查看有问题的容器副本

在alert里面可以配置报警规则

可以配置pod宕机发送报警

2.8 kubernetes日志收集

1. 原生方式：使用kubectl/oc logs直接查看本地保留的日志，或者通过docker engine的 log driver把日志重定向到文件、syslog、fluentd等系统中。

2. DaemonSet方式：在K8S的每个node上部署日志agent，由agent采集所有容器的日志到服务端。

3. Sidecar方式：一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。

Sidecar和DaemonSet是被动采集方式，主动采集方式有原生方式DockerEngine 推主动送方式（也可以通过SDK进行业务日志直写，本文不介绍）

2.8.1 原生方式log

DockerEngine本身具有LogDriver功能，可通过配置不同的LogDriver将容器的stdout通过DockerEngine写入到远端存储，以此达到日志采集的目的。这种方式的可定制化、灵活性、资源隔离性都很低，一般不建议在生产环境中使用。

K8s的容器提供标准输出和文件两种方式。在容器中，标准输出将日志直接输出到stdout或stderr，而DockerEngine接管stdout和stderr文件描述符，将日志接收后按照DockerEngine配置的LogDriver规则进行处理；日志打印到文件的方式和虚拟机/物理机基本类似，只是日志可以使用不同的存储方式，例如默认存储、EmptyDir、HostVolume、NFS等。

2.8.2 daemonset方式--Node上部署log agent

DaemonSet方式在每个node节点上只运行一个日志agent，采集这个节点上所有的日志。DaemonSet相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群。

通过部署Elasticsearch集群 ，Fluentd过滤、Elasticsearch存储、Kibana展示，来收集node agent的日志。（本文介绍较为简单的Filebeat方式）

yaml配置样式如下

日志输出到文件，hostPath方式挂载，agent通过deamonset方式部署

2.8.3 sidecar方式：通过sidecar容器收集日志

在k8s里，可以为pod添加一个sidecar进行pod日志收集，可以使用filebeat。每个pod都需要一个独立的sidecar，以下是为nginx添加sidecar

yaml配置样式如下：

本文是容器云大赛运维岗课程，点击阅读原文，可下载该文档

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

 资料/文章推荐：

欢迎关注社区 "容器云"技术主题 ，将会不断更新优质资料、文章。地址：

https://www.talkwithtrend.com/Topic/98447

■ 社区原创内容，欢迎读者以各种形式转发，网站等平台请勿擅自转载

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场