2019-07-27-k8s openshift troubleshooting故障诊断
分享一些本人在k8s openshift项目中积累的一些异常诊断方法。 本文主要描述问题解决流程和思路，针对应用发布/运行异常、访问异常，会插入一些场景。 分两部分 1. 应用发布后运行异常，即pod 无法正常启动或者启动后无限重启 2. 应用运行正常，pod 状态是running，但是无法通过ingress，nodeport，router等方式访问
一些技巧写在前面
应该能够在平时运维上提高一些效率 a. kubectl 命令table自动补全
echo 'source <(kubectl completion bash)' >>/etc/profile
source /etc/profile
# mac
echo 'source <(kubectl completion zsh)' >> ~/.zshrc
source ~/.zshrcb. 切换namespace/project
# 使用非default namespace，先写 -n xxx ,不影响table补全 xxx
kubectl -n kube-system get deploy
kubectl -n kube-system describe pod xxx
# 如果长期在某个namespace下操作，可以设置默认namespace
kubectl config set-context --current --namespace=kube-system
kubectl get pod #看到的都是kube-system下的pod
# 如果是openshift，直接oc project 可以切换
oc project openshift-infrac. 应用迁移的时候配置文件由简到繁 不要一开始就一古脑把readiness，liveness，resource通通配上，会让你在排查故障时多走弯路。 最开始运行的时候只要镜像、端口、必要的环境变量或者存储。
应用运行异常整体处理流程
简单说就是看pod event，pod start了，看pod log为主，但是也有可能是liveness 失败导致了反复重启，event也要看 容器未出现start，看event,存储挂载失败有时候要等几分钟才会出现event
图中每个操作默认第一个命令是kubectl,如kubectl describe pod xxx 以下详述各步骤操作缘由和可能引起的原因。 查看pod 及控制器event的方法是 kubectl describe pod podname-xx 及 kubectl describe deploy deployname-xxx, 看pod日志是 kubectl logs pod-name ，如果pod内多个容器，kubectl logs pod-name -c container-name 另外，如果deploy，dc，pod中event都是空空如也，get rs,rc 看看他们的event，或许有新发现。 rs rc为deploy，dc的二级控制器，用于版本管理。
kubectl get pod 能看到pod
pod event 无start container
A. pod状态处于pending pod未被成功调度到node节点，通过查看pod event 都能够找到原因 下面列几个常见报错 a. 资源不足
解决方法
b. 使用了node selector，但是node节点未设置label
c. 存储挂载失败 这种情况在对接ceph，glusterfs的时候很有可能出现，可能是因为参数配置错误或者node节点未安装相应的client服务。 需要注意的是 创建pvc pv 并bond成功，并不能说明存储配置正确，此时是不校验存储可用性的，只有pod创建的时候，才会去真正挂载，此时才能确认存储是否可用。 创建pv pvc，并创建一个deploy 使用pvc。 pv中是我的nfs 地址，若测试，需修改成自己的
这个报错是没有安装nfs-client 每个node节点apt-get install nfs-utils 重建pod
查看event，报错不一样了，连接错误，因为，我写了错误的nfs ip，实际ip是192.168.4.133 ，修改yaml后把pv pvc删了重建，pod删了重建即可
现在都正常了，进入容器 df -h 查看挂载ok
B. pod状态处于 ImagePullBackOff或者 ErrImagePull 这个报错很明显，镜像拉取失败，通过 kubectl get pod -owide 查看pod 所在node节点，在node节点上手动docker pull 试试，或者是外网的镜像比如 gcr.io 可能需要自己手动搭梯子 另外需要注意，如果使用的是自己搭建的仓库，不是https的，而pod event 中镜像地址却是https:// 开头，说明你docker 配置中少了 Insecure Registries 的配置
pod event 有 start container
event出现start container，说明pod已经调度成功，镜像拉取成功，存储挂载成功（不代表读写权限正常） 但是可能因为健康检查配置不当或者容器启动脚本、存储权限、运行权限的原因导致启动失败而反复重启。 首先还是kubectl describe pod 看event，若没有报错内容，则查看pod log A. pod liveness 监测失败 首先需要理解liveness的功能，当liveness 监测失败次数达到设定值的时候，就会重启容器。这种原因导致的容器重启原因在event中能够很明确的获取到，修改相应设定即可，或延迟init时间，或调整监测参数、端口。解决没有什么难度，而且遇到的也相对较少。
可以看到pod已经重启2次，event中有明确报错信息，对于liveness或者readiness的错误，手动访问下配置的端口或url或者command，测试下能否成功。
B. pod 启动异常导致反复重启 这种情况是非常常见的 这种基本是启动脚本、权限之类问题引起。 基本思路是describe pod 看event，同时观察log。 首先 describe pod 看event 以及 Last State/Message 会有一些有用信息。
a. 注意 Exit Code，如果是0，那说明pod是正常运行退出的，你没有设置启动脚本或者启动脚本有误，一下就执行完了，pod认为启动脚本已经执行完成，会吧container杀掉，而pod的重启策略是一直重启 restartPolicy: Always ，你就会看到你的pod在不停重启。 比如
b. 注意 Exit Code，如果不是0 那么可能是，你的启动参数错了
c. 或者你的存储权限不对，此处为挂载的nfs server
创建pv pvc 和应用
这种情况下会出现存储权限报错
d. 或者运行权限问题 本项测试基于openshift 在新部署完成的openshift中，首次运行docker.io 上的nginx redis都会失败 和openshift Security Context Constraint（SCC）有关，SCC 用于控制访问系统资源的权限 oc get scc 可以查看所有，默认的scc是 restricted，详细的对比可以oc describe scc 查看 基本情况是privileged > anyuid > restricted restricted 必须运行在特定的user id范围，root肯定不行，及hostnetwork，hostvolume 等权限受限
举个栗子，新建一个project，运行一个docker.io 上的nginx
报错了，用户权限不足
解决方法1: 由于pod 的默认 serviceaccount 叫default，我们把default 加到scc anyuid 里面，那这个project下的所有pod都将具备 scc anyuid权限，这种方式是比较暴力的，不建议这么操作。建议按照方法2
解决方法2： 新建一个serviceaccount，将他加入到scc anyuid，然后指定需要特权服务的应用来使用这个serviceaccount，这样可以避免所有pod 都具备anyuid权限 新起一个project做测试
解决方法3： 我们按照scc restricted 复制一个，只给他增加 nginx 需要的权限
FAQ: 1. 如果你默认scc 不小心调乱了，可以用这个命令重置 oc adm policy reconcile-sccs --confirm 2. SCC 优先级：一个 sa user 可以被加到多的 scc 当中。当一个 service account user 有多个 SCC 可用时，其 scc 按照下面的规则排序 最高优先级的scc排在最前面。默认地，对于 cluster admin 角色的用户的 pod，anyuid scc 会被授予最高优先级，排在最前面。这会允许集群管理员能够以任意 user 运行 pod，而不需要指定 pod 的 SecurityContext 中的 RunAsUser 字段。 如果优先级相同，scc 将从限制最高的向限制最少的顺序排序。 如果优先级和限制都一样，那么将按照名字排序。
kubectl get pod 看不到pod
以下描述其中一种会导致发布应用看不到pod的场景。 好像是cka的一道考题。一下子涵盖了quota，limit，deploy的版本管理几个内容。 主要考察对deployment子控制器rs的了解及对quota limit了解。 通过yaml文件创建一个namespace，里面包含了quota和limit
然后在这个namespace下创建的应用都看不到pod
可以从deploy的event中看到，reason ScalingReplicaSet， replicaset是deploy的二级控制器，用于版本管理，简写rs，我们需要去查看rs 的event （openshift deploymenyconfig的二级控制器是replicationcontrollers，简写rc）
可以看到rs的event中有明确报错信息。 原因是这个namespace 设置了quota，即资源上线为1核1G。 同时设置了limitranges 为2核2G，即这个namespace下创建的容器，每个的默认资源都为2核2G，资源不足导致了pod未创建。
scc限制了volume权限，导致pod无法直接挂载nfs也会出现这种现象，看不到pod。
应用运行正常，但是无法访问
接上篇，继续解读应用无法访问的场景。只要捋清各个访问方式的原理及走向，问题迎刃而解。 前提：应用运行正常，在集群内部可以通过pod ip 访问应用。 场景如下： 集群外访问集群内应用：最常用的两种方式，ingress/route 访问， nodeport访问 集群内应用互相访问：通过servicename 访问
集群外访问集群内应用 ingress/route
ingress/route 分别是k8s/openshift常用的负载方式，常用来作为应用的负载均衡。 ingress controller 是k8s的应用负载均衡器，内部是nginx，会通过nodeselector 方式部署在特定的几个node节点，使用hostnetwork，默认监听node节点80 443端口,支持4层 7层负载，可以卸载证书。会将ingress 规则写入配置文件。 openshift中的负载均衡器叫router，内部是haproxy，默认部署在default namespace，infra 节点，hostnetwork方式，默认80 443端口，支持7层，可以卸载证书。
以openshift 为例创建一个应用及route
流量走向 流量走router/ingress controller 通过容器网络直接到pod，不走service ip！！！ 不走service ip！！！不走service ip！！！ service 只作为同步应用后端的pod ip作用，见下图这是router，ingress 也是这样 
router的配置信息进入到router容器中，有个haproxy配置文件，内容很清晰。 ingress的进入ingress controller容器，nginx.conf中可以查看server信息，看不到backend 应用pod ip，用dbg命令可以看，如下
那么异常分析流程就很清晰了： 1. 首先确认域名解析正常，通过nslookup，dig工具确认域名是解析到了router/ingress controller 所在的node节点ip。 因为使用的hostnetwork，所以router/ingress controller 的ip也就是所在node节点的ip。 或者没有使用dns解析，那么本地hosts 需要手动配置下，将域名解析到 router/ingress controller 的ip 2. 确认 router/ingress controller 容器运行正常，看下容器日志。并确认网络为hostnetwork，oc get pod -owide 要看到ip是node节点ip 3. 确认 router/ingress controller 节点能够访问异常应用的pod ip，若异常，则排查容器网络 calico或者openvswitch等。
集群外访问集群内应用 nodeport
nodeport方式不依赖于router/ingress controller。 是配置在service中。配置后，访问任意节点IP（包含master）加nodeport 端口，即可访问到应用。 端口默认范围： 30000~32767
自动分配了一个端口31086，也可以手动指定。那么访问 任意节点ip:31086 即可访问应用。 原理：创建service后，kube-proxy会写入一些规则到每个节点的iptables，使得访问节点的31086端口的流量转发到各个pod。kube-proxy容器在kube-system namespace下。可以通过查询iptables来缕清楚规则。
异常分析： 1. 确认ip forward 是打开的
确认node节点存在nodeport相关iptables，方法上面有，若iptables规则不正常，则检查kube-proxy容器运行状态及日志。
以上都正常，那么很有可能是容器网络出问题了。排查calico容器日志，及pod，service ip段是否规划有误。
集群内应用互相访问
场景： 创建deployment A，名为 tomcat，端口8080 ，创建对应service 名为tomsvc，端口 8080 创建deployment B，名为 nginx，端口80，创建对应service，名为 ngsvc， 端口 80 应用A B 互相访问使用对方servicename+端口即可。无需再通过ingress或者nodeport方式。此原理依赖于集群内部dns。（k8s 是coredns容器--之前是kubedns，openshift 是dnsmasq，是系统服务不是容器）
功能测试： 可以通过运行一个busybox:1.28来测试dns解析，里面带nslookup 注意用1.28的，有的版本里面nslookup不好使
所以异常处理的顺序，k8s和openshift中dns server有些差异，分开写，实现的功能是一致的： 1.1 k8s -- 确认集群内部dns服务正常，在master或者node节点上做
1.2 k8s -- 确认容器内部的dns地址指向
同时可以配合busybox:1.28的容器进行诊断
2.1 openshift -- 确认集群内部dns服务正常，在异常访问到pod所在node节点上做
注意openshift不能关闭NetworkManager服务，部署文档都有说明。resolv.conf文件就是靠他来更新的。
2.2 openshift -- 确认容器内部的dns地址指向 nameserver地址是pod所在node的主机ip才是正确的，openshift中pod的resolv.conf 中nameserver 默认是从所在节点的/etc/resolv.conf获取，若pod中的尚未更新，重启下openshift node服务。然后delete 相关pod再看resolv.cof
同上，同时可以配合busybox:1.28的容器进行诊断
openshift的更多dns相关的知识可以查看这篇文章。 https://www.cnblogs.com/sammyliu/p/10056035.html
故障诊断篇完结。下一篇大概是openshift template。 本篇上下完整版本可查询github，后续若有补充会更新在这 https://github.com/cai11745/k8s-ocp-yaml/blob/master/kubernetes-docs/2019-07-27-openshift-k8s-troubleshooting.md
Last updated