专栏首页TKE学习分享TKE常见问题以及故障定位
原创

TKE常见问题以及故障定位

1.长连接服务:滚动更新导致负载不均

建议: client 侧设置连接过期时间或者达到一定请求数就重连

2.高并发服务:

ipvs 下,高并发 client 导致 “no route to host”

  • client 高并发导致源端口重用,ipvs 模块匹配到旧连接(weight为0,但没真正剔除,目的是ipvs为了支持graceful termination)
  • 旧连接的后端 pod 已经销毁,导致连接异常

建议:暂时没有完美解决方案,可通过 Pod 反亲和打散 client 避免流量集中规避

大流量的边缘节点源端口耗尽

  • 边缘节点通过 NodePort 接收外界流量,发生大量 SNAT,导致源端口耗尽

连接队列溢出问题

syn 队列保存半连接状态的连接, accpet 队列保存已建立但还没有被应用处理的连接

  • ss –lnt 查看连接队列情况, Send-Q 表示 accept 队列大小, Recv-Q 表示 accept 队列中连接数量,通常为0,比 Send-Q 大 1 表示溢出;
  • 通常 somaxconn 决定 accpet 队列大小,默认为 128;
$ netstat -s | grep -E 'overflow|drop'
  • 流量过大或高负载易导致应用处理不过来(accept过慢),从而队列溢出丢包;
使用sysctls调整参数
  • 使用 K8S sysctls 特性设置 somaxconn (此特性在 k8s v1.12 beta,默认开启);
通过 initContainers 初始化容器时调整参数
  • 使用 initContainers 设置 somaxconn (特权容器);
  • nginx 在 listen() 时并没有指定 somaxconn 的值为队列大小,而是有自己的默认值:511
listen 80 default backlog=1024
  • 通过在 nginx.conf 配置 backlog 可调整队列大小

慎用alpine

  • alpine 比较精简,很多依赖库没有,或者跟其它镜像不一样,一些依赖动态链接库的程序容易报错,比如 go 的 cgo 调用;
  • 底层库是 musl libc,域名解析行为跟 glibc 有差异,在 resolv.conf 配置的很多选项不支持;
  • 没有内置 bash,运行 bash 脚本不兼容;
  • 使用 lxcfs 提升容器资源可见性对 alpine 不生效(容器内看到的还是宿主机的cpu, memory使用情况),因为 alpine 内置 busybox 用系统调用获取信息而非读取 /proc;

DNS优化

search 与 ndots:

  • 若域名中的 “.” 数量大于等于 ndots 数量,直接向 dns server 查询此域名;
  • 否则就先依次遍历 search 并拼接到域名后缀查询;
  • 默认 ndots 为 5,即便把 service 名称拼全(比如 test.default.svc.cluster.local,4个 “.”),也还是会有 4 查询,前 3 次是多余的;

优化:

  • Pod dnsConfig 配置较小的 ndots;
  • 集群内部通过 service 访问时拼全后缀(namespaces.svc.cluster.local)

DNS cache

优化:

  • 改造业务,避免每次请求都查dns,比如 java 设置 networkaddress.cache.ttl ;
  • 部署 NodeLocal DNS 作为本地 DNS 缓存

常见故障定位

1、查看状态码与详情;

$ kubectl describe pod {xxx} -n {namespaces}

使用 kubectl describe pod 查看容器上次退出状态码:

分析退出状态码:

分析退出状态码:

  • 1-128 表示进程主动退出 (只是约定),具体状态码含义取决于应用程序逻辑;有时主动退出也会是 255 状态码: 代码里使用类似 exit(-1) 时,-1 被自动转成 255,通常状态码为 1 和 255 是一般性错误,看不出具体含义,需要结合日志分析;
  • 129-255 表示进程因外界中断信号退出,最常见的是 137,表示被 SIGKILL 杀死,可能是 Cgroup OOM,系统 OOM,存活检查失败或者被其它进程杀死导致。

2、查看日志;

使用 kubectl logs 查看容器日志 (-p 可看上次退出日志):

$ kubectl logs {podname} -n {namespaces}

3、查看资源配置;

使用 -o yaml 查看资源 yaml:

# pod
$ kubectl get pod {podname} -n {namespaces} -o yaml
# deploy
$ kubectl get deploy {deplyname} -n {namespaces} -o yaml
# svc
$ kubectl get svc {svcname} -n {namespaces} -o yaml
# daemonset
$ kubectl get daemonset {daemonsetname} -n {namespaces} -o yaml

4、进入容器抓包关键思路;

  • kubectl describe pod 拿到容器 id;
  • 通过 docker 或 crictl 查看容器 id 对应的进程号;
  • 使用 nsenter –n --target 进入容器进程的 netns;
  • 使用宿主机上的抓包工具进行抓包 (tcpdump)

5、Pod 无法调度;

可能原因:

  • 节点资源不够;
  • 不满足 nodeSelector 与 affinity;
  • Node 存在 Pod 没有容忍的污点;
  • 有状态应用漂移找不到符合条件的同可用区节点;
  • scheduler 不正常 (概率低)

6、Pod无法启动;

可能原因:

  • 拉取镜像失败;
    • 镜像仓库认证失败 (imagePullSecret 没有配置或配置有误);
    • 镜像仓库协议与证书问题 (http 没有加 insecure-registry / https 自签没有加 CA) ;
    • 镜像不存在 (镜像名配置有误);
    • 镜像文件损坏;
    • 镜像拉取超时 (镜像太大或在国内拉不到国外镜像);
  • 程序启动配置不当导致进程主动退出 ;
  • limit 没配置单位,内存默认用 byte,导致一直被 kill ;
  • 依赖的 ConfigMap、Secret 或者 PVC 等不存在;
  • 被管理员配置的 LimitRange, PodSecurityPolicy 限制住了;
  • 挂载 Volume 失败;
    • 命中 bug #68211;
    • Pod 漂移没有正常解挂之前的磁盘;
  • 磁盘爆满;
  • 节点内存碎片化 ;
  • controller-manager 异常;
  • CNI 网络错误;
  • 程序启动慢被存活检查 kill;

7、Pod 发生 Crash;

可能原因:

  • cgroup OOM / 系统 OOM ;
  • DNS 故障导致解析失败,业务进程报错退出;
  • 高负载导致网络不通,业务进程报错退出;
  • 存活检查探测失败,容器被 kill;
  • 业务本身 bug;
  • 容器进程被木马进程杀死

8、Pod 无法删除;

可能原因:

  • 磁盘爆满;
  • 存在 Finalizers;
  • 资源被其它进程占用;
  • 存在 “i” 文件属性;
  • 运行时 bug;

9、Namespace 无法删除;

可能原因:

  • Namespace 上存在 Finalizers (比如安装过 KubeSphere 或 Rancher,卸载后没清理 Finalizers);
  • 注册过的 apiservice 状态异常 (比如安装过 prometheus-adapter,卸载后没清理 apiservice)

10、Service/Ingress 创建失败;

可能原因:

  • LB 数量达到最大配额;
  • 复用已有 LB 但上面存在规则或正在被其它 Service/Ingress 使用 ;
  • 复用已有 LB 但 ID 写错;
  • Secret 不正确;
  • LB 内部错误 (概率低);

11、网络不通;

可能原因:

  • 节点安全组没有放通容器网段、节点网段或者 NodePort 端口区间 (30000-32768);
  • 外部服务防火墙没有放开容器网段 (如 CDB、自建 DNS);
  • DNS 异常;
  • 高负载;
  • 进程没有监听端口;

12、节点状态异常;

可能原因:

  • 节点高负载;
  • 磁盘故障;
  • 踩内核 bug;
  • 运行时 hang 住或挂掉;
  • 系统 OOM ;
  • 节点 DNS 被修改;
  • 欠费

案例: Pod 访问另一个集群的 apiserver 有延时

  • kubectl 没有使用底层库查询域名,在 alpine 下底层库是 musl libc,但 kubectl 用的却是类似 glibc 的查询逻辑;
  • 由于 alpine 没有 /etc/nsswitch.conf 文件,所以 kubectl 先查 dns,再查 hosts;
  • 虽然 dns 解析没有用,但始终会先尝试解析 dns,当踩上内核 conntrack bug 时导致部分请求丢包,等待 5s 超时后 kubectl 继续重 试,造成 5s 延时现象;

解决方案:

  • 换基础镜像,不用 alpine;
  • 挂载 nsswitch.conf 文件 (hostPath或configMap);

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • RabbitMQ常见问题及故障整理快问快答

    小九今天分享了RabbitMQ一键部署、高效安装的图文详解,接下来,针对RabbitMQ使用过程中的一些问题,小九整理了详细的常见问题问答。这样的直观方式往往能...

    w9
  • Exchange 搭建以及常见故障处理

    环境介绍:我这里用的是两台Windows 2008 R2,当然你可以使用Windows 2012 。

    DevinGeng
  • 定位 | 常见问题

    定位 1.腾讯位置服务在PC端测试过程中使用定位组件,一直显示定位中,没有地图显示? 目前地图提供的组件只支持手机端使用,PC端无法使用H5定位组件。 2.我...

    腾讯位置服务
  • SuperEdge 易学易用系列-SuperEdge 简介

    王继罗,腾讯云专家工程师,腾讯边缘 Kubernetes 管理平台 TKE Edge 技术负责人,SuperEdge 边缘容器开源项目创始人&技术负责人。 关...

    腾讯云原生
  • SuperEdge易学易用系列-系统介绍

    SuperEdge是由腾讯、Intel、VMware、虎牙直播、寒武纪、首都在线和美团等多家公司共同发起的边缘容器管理系统,它基于原生Kubernetes、针对...

    SuperEdge官方号
  • Discuz最全的常见问题及故障解决整理

    小九今天整理了Discuz使用过程中经常出现的一些问题和故障,包括安装、使用等各个部分的常见问题及答案。

    w9
  • 从安装到使用——Odoo常见问题及故障处理

    小九今天分享了Odoo一键部署、高效安装的图文详解,接下来,针对Odoo使用过程中的一些问题,小九整理了详细的常见问题问答。这样的直观方式往往能快速高效地解决一...

    w9
  • 如何构建万级Kubernetes集群场景下的etcd监控平台?

    周成,腾讯云工程师,主要负责腾讯 etcd 监控平台设计、开发、运维工作,具备大规模 Kubernetes 和 etcd 集群运维开发经验。 唐聪,腾讯云资深...

    腾讯云原生
  • mysql AB复制搭建以及常见故障排查

    MySQL主从复制(Master-Slave)也叫AB复制,Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过。但在实际的...

    DevinGeng
  • TKE上玩混沌

    为了保障云上客户的系统稳定性,最近研究了混沌工程 Chaos Engineering 的历史和相关工具。本篇探讨下混沌工程的历史,社区给的实践原则,同时演示下混...

    鲍远林
  • PWK 以及 OSCP 常见问题

    OSCP 最近在安全圈子越来越受到认知,Offsec 最近更新了一篇博文,关于 PWK 以及 OSCP 最常见的问题。本文挑一些重点讲一下:

    madneal
  • Flink 常见问题定位指南

    流计算作业通常运行时间长,数据吞吐量大,且对时延较为敏感。但实际运行中,Flink 作业可能因为各种原因出现吞吐量抖动、延迟高、快照失败等突发情况,甚至发生崩溃...

    KyleMeow
  • Flink 常见问题定位指南

    流计算作业通常运行时间长,数据吞吐量大,且对时延较为敏感。但实际运行中,Flink 作业可能因为各种原因出现吞吐量抖动、延迟高、快照失败等突发情况,甚至发生崩溃...

    腾讯云大数据
  • 腾讯云云原生混合云-TKE发行版

    徐蓓,腾讯云专家工程师,深耕云计算、K8s、离在线混部领域,K8s 社区贡献者,Memory QoS with cgroups v2 KEP 作者。 李波,...

    腾讯云原生
  • Chaos Mesh® 在腾讯——腾讯互娱混沌工程实践

    腾讯互娱运营活动每天的访问人次超过 100 亿次,高峰的 QPS 超过 100 万,每天活动代码发布更新超过 500 次,数据量也超过 200 TB。面对海量的...

    CNCF
  • 人人视频基于K8s的微服务实践:TKE + Spring Cloud

    导读:本文主要介绍了人人视频在微服务化和云原生领域的一些自己的探索,我们的内部技术栈也在朝着这些主流的方向发展演进,不至于在这波潮流中落后,当然任何技术的使用最...

    CNCF
  • Linux问题故障定位,看这一篇就够了

    有时候会遇到一些疑难杂症,并且监控插件并不能一眼立马发现问题的根源。这时候就需要登录服务器进一步深入分析问题的根源。那么分析问题需要有一定的技术经验积累,并且有...

    我在鹅厂做安全
  • 掌握运维必备技能--问题故障定位

    a. on-CPU:执行中,执行中的时间通常又分为用户态时间user和系统态时间sys。

    用户6543014
  • centos 搭建cacti监控以及常见故障解决方案

                      CentOS搭建Cacti监控平台以及故障解决

    DevinGeng

扫码关注云+社区

领取腾讯云代金券