Kubernetes集群主要通过kubectl命令行进行运维，OpenShift中使用oc命令行进行运维。两个命令行的参是相同的（OpenShift集群也提供kubectl命令行，但建议使用oc命令行）。
1 检查master
主要通过以下命令检查。
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查日志看下具体问题
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
2 检查node
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 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
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访问
4 检查pod
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重启过，需要去日志检查原因
4.2 kubectl/oc logs 检查pod日志
kubectl/oc logs --tail 100 -f pod -n namespace
检查日志中有无异常
或者进入日志目录 /var/log/pods，找到容器id-json.log日志文件
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。
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的权限很高，可以创建容器，容器组，可以删除容器和容器组；
7 通过kube-promtheus监控k8s
K8s监控需要考虑以下几方面
Kubernetes节点的监控：node节点的cpu、负载、内存、硬盘等指标
内部系统组件的状态：kube-scheduler、kube-controller-manager、kubedns/coredns等组件的运行状态
metrics：Deployment的状态、资源请求、调度和API延迟等数据指标
Kube-prom的组成如下
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配置完成
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
检查状态是否正常
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里面可以配置报警规则
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进行业务日志直写，本文不介绍）
8.1 原生方式log
DockerEngine本身具有LogDriver功能，可通过配置不同的LogDriver将容器的stdout通过DockerEngine写入到远端存储，以此达到日志采集的目的。这种方式的可定制化、灵活性、资源隔离性都很低，一般不建议在生产环境中使用。
K8s的容器提供标准输出和文件两种方式。在容器中，标准输出将日志直接输出到stdout或stderr，而DockerEngine接管stdout和stderr文件描述符，将日志接收后按照DockerEngine配置的LogDriver规则进行处理；日志打印到文件的方式和虚拟机/物理机基本类似，只是日志可以使用不同的存储方式，例如默认存储、EmptyDir、HostVolume、NFS等。
8.2 daemonset方式--Node上部署log agent
DaemonSet方式在每个node节点上只运行一个日志agent，采集这个节点上所有的日志。DaemonSet相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群。
通过部署Elasticsearch集群 ，Fluentd过滤、Elasticsearch存储、Kibana展示，来收集node agent的日志。（本文介绍较为简单的Filebeat方式）
yaml配置样式如下
日志输出到文件，hostPath方式挂载，agent通过deamonset方式部署
8.3 sidecar方式：通过sidecar容器收集日志
在k8s里，可以为pod添加一个sidecar进行pod日志收集，可以使用filebeat。每个pod都需要一个独立的sidecar，以下是为nginx添加sidecar
yaml配置样式如下：
点击阅读原文，可下载该文档，本文首发于2021年 觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "容器云"技术主题 ，将会不断更新优质资料、文章。地址：
https://www.talkwithtrend.com/Topic/98447
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场
