- 博客(70)
- 收藏
- 关注
RSS订阅原创 记一次诡异网关耗时差异：Nginx耗时1s+，Envoy仅39ms，根因竟是HTTP协议版本降级
对 Nginx 默认代理协议规则不熟悉，忽略了入口协议与上游转发协议不一致的隐性坑，HTTP/1.0 短连接机制带来大量隐性性能损耗，属于典型的配置类隐性性能故障。
2026-07-03 17:23:42
391
原创 Istiod 启动 panic崩溃深度排查
然后根据崩溃日志搜索istio相关代码，发现并不是通过istio代理的svc地址才会进行服务发现，而是默认自动获取k8s集群中所有svc地址，当发现到集群中这个无端口的svc时，就触发了panic崩溃。通过以上istiod程序崩溃报错，初步看是因为获取service地址时出现问题，导致istiod识别错误service信息崩溃。通过这个svc地址到istio网关的vs路由中并没有查找到代理这个无端口服务，百思不得其解。某项目在使用PaaS平台网关服务时，创建路由失败，istiod不断重启，无法就绪。
2026-06-10 15:02:04
252
原创 k8s生产集群主机批量重启后，大量Pod启动失败故障排查复盘
本次故障看似是Pod通信异常，实则是主机重启操作不规范、kube-apiserver配置参数缺失导致的连锁问题。k8s生产集群的稳定性，离不开规范的操作流程和严谨的配置优化。
2026-03-21 16:20:00
528
原创 Linux主机更换主板后，keepalived启动导致重复路由的解决方案
Linux主机更换主板后，keepalived启动引发重复路由的核心诱因，是主板更换导致网卡底层信息变化，与keepalived默认路由生成策略产生冲突。通过**精准定位重复路由**，临时清除路由恢复通信，再在keepalived配置中添加参数禁用自动路由，即可彻底解决该问题。
2026-03-18 10:11:00
431
原创 containerd崩溃问题处理
后面通过日志关键词到对应github上进行查找，发现是关于go的一个典型的底层bug，相关issues中明确涉及go 1.13.x版本，需要升级到go 1.14.x以上版本进行解决。生产一环境有docker挂起告警，租户反馈有业务影响，登录环境发现docker确实挂掉了，重启docker后业务反馈恢复。
2026-01-06 15:53:17
248
原创 排查业务pod内生成未知的环境变量
至少可以锁定问题范围，这个分区应该设置了全局变量还是什么，查询半天，没有查询到这些变量的来处。初步怀疑肯定是租户定义的环境变量导致，让租户对对自己打的Dockerfile和pod中定义的环境变量进行核查，租户反馈并没有，然后尝试将这个pod调度到其它分区下，发现容器中哪些未知的环境变量没有了。某上云租户反馈发布的pod容器内会产生一些自己未定义的环境变量，导致租户制作镜像中定义的环境变量被覆盖。2、租户在Dockerfile中声明的变量，可以在创建的pod中，定义env部分的变量内容。
2025-10-28 14:54:39
414
原创 线上生产环境envoy网关崩溃处理
如上两个根据官方提供的命令测试均未模拟出故障期间的崩溃问题，在设置limit后只出现了413状态码，已经显示出上传文件过大。某线上生产环境反馈部分业务功能不可用了，通过登录环境排查，发现envoy网关pod全部状态异常，通过重启pod无法拉起。如上根据模拟租户侧相同的请求，能复现出当时的故障，而创建envoyfilter后就返回413,并没有崩溃。当时根据日志，当时创建envoyfilter设置max_request_bytes的大小，进行恢复。通过网关崩溃日志发现，存在两处崩溃的日志都有相同的特征。
2025-06-17 10:31:53
988
原创 Harbor默认Redis与Notary组件弱口令漏洞分析与修复指南
harbor在安装的代码文件中会定义一个docker-compose模板文件，上图就是我截取的一部分，它会通过common/config/notary目录下定义的server和signer的env文件获取对应变量。首先需求确认这三个用户是harbor那个组件使用，最好确认的是default这个用户，它是redis的默认用户，server、signer这两个在harbor.yml配置文件的引用外部组件中有定义，涉及到notary这个组件。core/env文件，123123就是你要设置的redis密码。
2025-04-29 12:37:39
1223
原创 harbor因权限问题导致无法启动
根据这个报错，也查看了docker-compose.yaml的文件，并没有挂载这个sudo.conf的配置，试着重启下habror，发现无法重启起来，还是报权限的问题，后面试着将harbor换一个新的数据目录，重新安装harbor试试，发现重新安装也拉不起来，还是报如上图一样的报错，很是奇怪。具体什么原因不得而知。一交付未上产环境，因为harbor多次修改密码，重启harbor发现无法正常启动，一直报权限相关错误。
2025-04-17 16:40:38
614
原创 logging-operator 部署fluentd-bit日志报kubernetes链接错误
1、排查fluentd容器到kubernetes api server的联通性，进入容器中curl kubernetes.default.svc.local:443 发现是能访问的。因为logging-operator中定义支持是否启用kubernetes的变量，所以在fluentd-bit的crd中添加关闭kubernetes的变量即可。某项目使用logging-operator部署fluentd-bit进行日志采集，发现启动的fluentd-bit有大量的的链接kubernetes报错。
2025-02-21 18:15:08
468
原创 prometheus out of bound 问题处理
运行面promtheus因为调整资源，进行了pod重启，导致控制面的一级 prometheus报错，监控数据无法显示。5、删除queries.active 文件。3、删除 chunks_head 目录。1、停止 prometheus 服务。6、启动 prometheus 服务。4、删除 lock 文件。2、删除 wal 目录。
2024-11-18 20:52:55
687
原创 envoyFilter导致的webSockets协议无法正常工作
开始怀疑难道envoy无法处理次socket,尝试将请求头部分的内容删除，模拟请求发现可以请求通了，然后想到请求头大小导致的，集群做过一次变更，调整了envoy的请求头大小限制，但是这个限制是1G,不可能业务请求头能有这么大，然后删除了创建的envoyfilter，发现业务这个websocket的服务可以正常访问了，百思不得其解。生产项目有一个socket请求经过网关一直无法响应，其它接口服务都能正常处理。
2024-10-22 15:07:45
1365
原创 调整istio得请求头大小限制
在istio-system分区创建一个EnvoyFilter，作用于全局网关实例，yaml如下：metadata:spec:labels:match:listener:filter:#proxy:patch:value:input:map:websocket:action:name: skip。
2024-09-29 11:01:01
689
原创 istio 网关开启https访问链接重置
后来自己查询相关istio官方文档，猜测可能是证书存在问题，然后根据官方提供的方式生成证书，重新配置，发现可以正常访问了。通过模拟访问，查看网关日志实例，并未有相关请求日志进入。后来一度认为是开发版本的问题，也找咱们相关网关开发查看，也并未发现问题。2、检查网关实例的日志发现无异常，调用网关的接口，查看相应的路由是否添加进去，发现路由添加成功的。一上云租户使用平台提供的istio网关，开启https，然后发现访问一直链接重置。1、检查代理的服务，进行了模拟访问是正常的，排除代理服务的问题。
2024-09-24 14:54:32
838
原创 haproxy程序崩溃问题处理
查询相关haproxy官网显示，确实存在这个问题，需要将haproxy升级到2.8.4以上，最终自己做了一个haproxy 2.9.9版本的镜像，推送到k8s环境进行观察和高可用测试，发现并无问题后，更新至生产环境，后面就没出现过次问题。线上一k8s环境告警出节点失联，通过排查和k8s的api建立链接失败，检查发现haproxy出现了重启，对应的日志显示出程序运行崩溃，这个情况根据日志追溯，发现曾多次崩溃，后续也在其他k8s环境也有出现。
2024-09-23 11:30:03
1201
1
原创 对容器做iptables防火墙规则
iptables -I DOCKER -s 192.168.133.130(放行备库mysql） -p tcp --dport 3306 -j ACCEPT。
2024-06-06 09:01:59
283
原创 pod删除后，kubelet无法回收子路径
在巡检查看一些kubelet日志的时候发现，kubelet日志中有大量的无法移除子路径的报错，对应的pod都是已经删除的。
2024-04-19 09:27:23
429
原创 k8s集群配置NodeLocal DNSCache
在当今的体系结构中，运行在 ‘ClusterFirst’ DNS 模式下的 Pod 可以连接到 kube-dns serviceIP 进行 DNS 查询。node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址，因为 IPVS 负载均衡使用的接口已经占用了该地址。：集群内的服务基本都是通过域名进行访问，coredns在解析压力大时会存在慢或者丢包的情况，导致服务之间解析异常。1、 使用当前的 DNS 体系结构，如果没有本地 kube-dns/CoreDNS 实例，则具有最高。
2024-01-11 10:42:37
2808
原创 解决kubelet报failed to get imageFs info: non-existent label \“docker-images\“
主机重启后，kubelet比docker先启动，会对不健康的pod进行一个资源回收的过程，这个时候docker还没正常启动，kubelet无法调用docker的socket接口对镜像回收，会导致每五分钟一次的循环检查，默认到100次就会触发gc，会导致kubelet的pleg不健康，这个启动顺序还是很重要的。一环境主机重启后，查看kubelet日志经常有大量无法回收镜像文件报错，会导致kubelet的pleg不健康，从而导致kubelet发生重启。
2024-01-08 16:55:40
2930
原创 istio配置http1.0协议
有些任务场景中需要用到istio的http1.0协议，但是这个配置默认是没开启的，需要在istiod的配置中添加对应的环境变量参数即可。
2024-01-08 16:37:56
765
原创 k8s中pod的hostport端口突然无法访问故障处理
既然访问不通那就先给服务做个全面检查，看看哪里出了问题，看下sftp日志，也没有啥关键报错，接下来查看了下sftp服务的svc端口，发现通过svc地址和端口是能正常访问的，通过pod IP去访问也是可以，这就很奇怪了，唯独用主机ip加hostport端口就访问不通。租户告知生产环境的sftp突然无法访问了，登录环境查看sftp服务运行都是正常的，访问sftp的hostport端口确实不通。： 跟租户沟通，看看能否重启服务试试，发现重启完服务，还是老样子，通过hostport访问依然不通。
2023-11-28 17:06:07
1567
原创 一次harbor升级导致镜像项目访问无权限问题
1、根据报错反馈没权限，当时认为可能用户对这个项目是不是权限上有些问题，在harbor的镜像项目用户一栏，查看项目所在的用户是admin，镜像项目也是公开的，按理说权限应该没啥问题的，然后尝试添加一个用户进去，然后绑定到这个镜像项目，并赋予管理员权限，然后用此用户登录harbor，进入这个镜像项目还是报无权限，但是在harbor上新创建项目是没啥问题。如上改为以后无问题，也能有权限进入项目查看镜像了。3、开始登录harbor的pg库进行镜像项目的更改，先查看需要更改的项目，如下。
2023-08-25 17:51:39
907
原创 kubernetes中特定域名使用自定义DNS服务器出现的解析异常
从如上分析来看，既然在coredns中已经配置了外部转发dns服务，租户如果继续在服务中还配置外部dns服务地址，就会导致应用服务会有两个dns nameserver,首先会访问集群内部域名地址会解析到pod中配置的那个外部dns服务中，会出现解析不了的情况，就反馈失败，然后轮到集群内部定义的dns服务就会正常解析成功。把在服务中配置dnscongfig相关参数去掉，让服务统一走集群内的coredns进行转发处理即可。
2023-07-14 17:12:19
1653
原创 systemd管理自动挂载nfs
在维护的环境中，不少组件使用到nfs存储，有时候主机批量关机重启的时候，无法实现自动挂载，就需要手动去挂载，这是很费力又浪费时间的事。虽然nfs自动挂载写到了/etc/fstab里面了，但是遇到一些复杂挂载时候，可能会导致开机启动过程中卡死的情况。在一些较新的 Linux 发行版中，/etc/rc.local 文件的执行时机已经被修改，其不再能够保证在系统启动时最后执行。Where=/data2 # where 配置的是nfs client需要挂载的路径，此处路径名要和文件名一致。
2023-04-09 17:57:08
1831
原创 解决docker报eeror: write unix /var/run/docker.sock-＞@ write:broken pipe
docker故障排查
2022-10-21 17:07:43
3000
原创 calico vxlan interface down,导致 calico-node 无法添加路由
关于calico vxlan模式下，无法正常下发路由
2022-07-13 17:10:24
1701
原创 对etcd进行数据拆分
我们现在是一个k8s集群，多个租户共同使用，包括如果后期有新用户上云，申请到的资源同样也会以node节点的形式加入到现有的master节点，这样当一定规模的服务运行在集群中，势必会增加etcd的负担，整个ku8集群的数据都是存放在etcd中，只有进行合理的拆分，才能提升etcd的性能。进行etcd拆分的情况如下图：老版本的etcd仍然提供服务，只存储pod、svc等信息。新版本的etcd提供着存储ku8的events信息。之前就是因为把所有数据存放到一套etcd集群，出现events信息太多导致et
2022-04-24 14:21:44
1512
1
原创 关于文件句柄数和文件描述符的区分
在一次生产环境上，用户那边反馈服务连接redis异常，经过查看redis的日志，报打开文件数过多，通过lsof去查看文件句柄数确实超过了主机限制的句柄数，只能先重启redis进行释放连接数，进行恢复业务。上面是一个处理过程，但是后面和对方人员关于程序是否是打开那么多文件句柄数，产生分歧，对方认为一个进程打开的文件句柄数量可以使用，如下命令进行统计：ls -l /proc/pid1/fd/ | wc -l 进行统计为此，我到自己环境上验证一番，给予解释，争吵是解决不了问题，唯有真理服人了，首先
2022-02-17 17:54:47
1700
原创 Ingress进行灰度发布
现在一些业务在有新版本上线时，通常新版本即使在自己本地测试后，发布到线上环境也可能会出现一些问题，就会回滚到老版本，现在我们新版本的上线都会采取灰度发布，先让一小部分的流量请求到新版本，其余流量请求到老版本，等新版本验证没问题，逐渐让流量都请求到新版本，然后下架老版本。下面就用ingress来做下灰度发布，首先还是需要部署两个服务，一个代表老版本，一个代表新版本，我这边还是用nginx来测试，两个nginx服务部署如下：然后用ingress去分别代理这两个服务，我们这里采取权重的策略，来做流量的分发，达
2022-02-10 10:48:48
3163
原创 Ingress对服务做限流
随着现在更多环境的服务进行上云，对网关这块能实现的功能也比较关注，除了能正常的实现代理的作用，还需要可以进行比如：熔断，链路追踪，限流等，这里主要操作下对ingress的限流。首先还是需要在k8s集群上部署一个服务用来进行测试，我这里部署了一个nginx的pod，然后用ingress代理这个nginx服务，最后在ingress上做限流操作，通过访问ingress查看是否达到限流的作用。下面创建ingress的yaml来代理nginx这个服务并做限流，如下：apiVersion: extensions
2022-02-09 15:53:15
5698
原创 Ingress的代理配置
Ingress的部署这里省略，我的另外一篇博客上已经详细介绍部署过程，这里我们主要操作是给ingress添加域名，并做反向代理。先在k8s上部署一个nginx的pod,然后用ingress来代理这个nginx的pod，实现访问ingress地址就代理到对应的nginx服务，部署nginx服务，并测试能正常访问：接下来用ingress来代理这个部署好的nginx服务，编写ingress代理nginx的yaml如下：apiVersion: extensions/v1beta1kind: Ingress
2022-02-08 17:40:20
3282
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人