k8s诊断之ingress 异常状态码及证书问题排查思路

我们能从这张图里看到什么有用的信息？

• 整体开销时间？
• 请求状态码？
• 请求结束的时间（结束请求记录日志）
• 尝试过的后端地址和端口？
• 后端返回的数据包长度？
• 后端返回的时间？
• 后端的状态码？

这种问题应该怎么分析呢？

1，抓取pod以及svc的ep更新记录，注意替换kubeconfig，以及label等

for i in {1..3000};do echo`date` >> p.log;kubectl --kubeconfig=/root/kehuconfig/fconfig  -n admin-testing get pods  -o wide -l app.kubernetes.io/name=ops-go-api >> p.log ;kubectl --kubeconfig=/root/kehuconfig/fconfig  -n admin-testing describe ep ops-go-api >> p.log;sleep 1;done

2，需要登录到ingress-controller的pod里面抓backends

foriin{1..3000};doecho`date`>>ng.log;/dbgbackendsgetadmin-testing-ops-go-api-http|grep-A20"endpoint">>ng.log;sleep1;done/dbgbackendsget后面接的svc是命名空间+svcname+端口名称备注:ingresscontroller不同版本查看backends的命令：<0.22：服务权重体现在nginx.conf中>=0.22：服务权重通过kubectl-nkube-systemexec-it<NGINX-INGRESS-CONOTROLLER-POD-NAME>--curlhttp://127.0.0.1:18080/configuration/backends可以看到demo/dbg-hdbgisatoolforquicklyinspectingthestateofthenginxinstanceUsage:dbg[command]AvailableCommands:backendsInspectthedynamically-loadedbackendsinformationcertsInspectdynamicSSLcertificatesconfDumpthecontentsof/etc/nginx/nginx.confgeneralOutputthegeneraldynamicluastatehelpHelpaboutanycommandFlags:-h, --helphelpfordbg--status-portintPorttousefortheluaHTTPendpointconfiguration. (default10246)Use"dbg [command] --help"formoreinformationaboutacommand./dbgbackendslistdefault-canary-ua-80default-cms-webhook-8080default-cors-5000default-cors-canary-5000default-grafana-3000default-helloworld-80default-my-multicluster-svc-80default-mysvc-80default-mywp-svc-80default-myyuan-https-34567upstream-default-backend$/dbgbackendsgetdefault-my-multicluster-svc-80{"endpoints":[{"address":"192.168.40.221",
"port":"80"}],
"name":"default-my-multicluster-svc-80",
"noServer":false,
"port":80,
"service":{"metadata":{"creationTimestamp":null},
"spec":{"clusterIP":"172.16.167.67",
"ports":[{"port":80,
"protocol":"TCP",
"targetPort":80}],
"selector":{"app":"my-nettools-multicluster-test"},
"sessionAffinity":"None",
"type":"ClusterIP"},
"status":{"loadBalancer":{}}},
"sessionAffinityConfig":{"cookieSessionAffinity":{"name":""},
"mode":"",
"name":""},
"sslPassthrough":false,
"trafficShapingPolicy":{"cookie":"",
"header":"",
"headerPattern":"",
"headerValue":"",
"weight":0},
"upstreamHashByConfig":{"upstream-hash-by-subset-size":3}}

分别采集用户的pod更新时间，endpoint更新时间，以及ingress的更新时间，看看异常的499 502等日志在哪

日志图如下：

502日志，注意一个点，time是访问结束的时间，因此是46秒-2s左右

pod的变化以及ep的变化，可以看到 46秒 44秒ep都是正常的 更新后的pod

再看下ingress的backends的endpoint，44秒的时候。T状态的pod 10.0.32.45还在endpoint中

以这个异常pod摘除的时间分析。04:36的时候 是T状态了

而ingress的时间却是 05:12的时候 才没有这个32.45的ip，中间延迟了36秒左右

这个时候我们还能查查什么？

1. apiserver是否存在限流？查看kubelet日志以及apiserver的监控大盘
2. 对比多个controller，看看是否都存在该问题？如果都存在的话说明是某个共同因素影响导致，参考1
3. 如果单个controller有延迟的问题，检查controller日志看看有没有报错信息或者所在节点的负载
4. controller版本是否滞后比较久？可考虑升级版本

ingress 配置验证

• 客户ingress中更换对应的secret
• ingress中对应的secret crt信息验证
• 证书加载验证 kt exec -it -n kube-system nginx-ingress-controller-5c654cddcc-bgfkj -- /bin/sh

/dbg certs get xxx

• 解开cert看信息： openssl x509 -in d.cert -noout -text

服务当前使用证书确认

4） curl -voa https://svc.com --resolve svc.com:443:47.243.241.18x -k
5） curl -voa https://47.243.241.18x -k

参考下面tips

测试

• https双向认证
  1） curl --cacert ./ca.crt  https://foo.bar.com --resolve foo.bar.com:443:47.243.241.18x --cert ./client.crt --key ./client.key -voa # foo.bar.com 这个域名的
  
• 证书信息查看
  2） openssl s_client -connect 47.243.241.18x:443
  4） curl -voa https://svc.com --resolve svc.com:443:47.243.241.18x -k
  5） curl -voa https://47.243.241.18x -k
• tips
  1） 访问链路上需要确认有没有WAF，有没有透明WAF，有没有443端口上的七层slb，如果这些都没有，证书才会落到集群ingress里

2） 当证书落在集群的Ingress上，不带server name （ip替代域名的方式查看证书），返回的为默认证书，域名方式查看，返回的为对应的ingress上配置的证书。

3）透明WAF针对四层SLB需要配置证书 - https://help.aliyun.com/document_detail/171453.html

4） WAF double confirm -  https://yundunnext-console.aliyun-inc.com/?error=3#/ddosbasic/cn-beijing

openssl使用

• 查看证书内容：openssl x509 -in ser.crt -noout -text
• https://blog.csdn.net/naioonai/article/details/80984032
• https://blog.csdn.net/qxxhjy/article/details/116459502
• https://zhuanlan.zhihu.com/p/368407364