<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[qq_44397993的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/qq_44397993</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; qq_44397993]]></copyright><item><title><![CDATA[记一次诡异网关耗时差异：Nginx耗时1s+，Envoy仅39ms，根因竟是HTTP协议版本降级]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/162556978</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/162556978</guid><author>qq_44397993</author><pubDate>Fri, 03 Jul 2026 17:23:42 +0800</pubDate><description><![CDATA[对 Nginx 默认代理协议规则不熟悉，忽略了入口协议与上游转发协议不一致的隐性坑，HTTP/1.0 短连接机制带来大量隐性性能损耗，属于典型的配置类隐性性能故障。]]></description><category></category></item><item><title><![CDATA[Istiod 启动 panic崩溃深度排查]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/161861724</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/161861724</guid><author>qq_44397993</author><pubDate>Wed, 10 Jun 2026 15:02:04 +0800</pubDate><description><![CDATA[然后根据崩溃日志搜索istio相关代码，发现并不是通过istio代理的svc地址才会进行服务发现，而是默认自动获取k8s集群中所有svc地址，当发现到集群中这个无端口的svc时，就触发了panic崩溃。通过以上istiod程序崩溃报错，初步看是因为获取service地址时出现问题，导致istiod识别错误service信息崩溃。通过这个svc地址到istio网关的vs路由中并没有查找到代理这个无端口服务，百思不得其解。某项目在使用PaaS平台网关服务时，创建路由失败，istiod不断重启，无法就绪。]]></description><category></category></item><item><title><![CDATA[k8s生产集群主机批量重启后，大量Pod启动失败故障排查复盘]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/159319406</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/159319406</guid><author>qq_44397993</author><pubDate>Sat, 21 Mar 2026 16:20:00 +0800</pubDate><description><![CDATA[本次故障看似是Pod通信异常，实则是主机重启操作不规范、kube-apiserver配置参数缺失导致的连锁问题。k8s生产集群的稳定性，离不开规范的操作流程和严谨的配置优化。]]></description><category></category></item><item><title><![CDATA[Linux主机更换主板后，keepalived启动导致重复路由的解决方案]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/159201240</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/159201240</guid><author>qq_44397993</author><pubDate>Wed, 18 Mar 2026 10:11:00 +0800</pubDate><description><![CDATA[Linux主机更换主板后，keepalived启动引发重复路由的核心诱因，是主板更换导致网卡底层信息变化，与keepalived默认路由生成策略产生冲突。通过**精准定位重复路由**，临时清除路由恢复通信，再在keepalived配置中添加参数禁用自动路由，即可彻底解决该问题。]]></description><category></category></item><item><title><![CDATA[containerd崩溃问题处理]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/156650827</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/156650827</guid><author>qq_44397993</author><pubDate>Tue, 06 Jan 2026 15:53:17 +0800</pubDate><description><![CDATA[后面通过日志关键词到对应github上进行查找，发现是关于go的一个典型的底层bug，相关issues中明确涉及go 1.13.x版本，需要升级到go 1.14.x以上版本进行解决。生产一环境有docker挂起告警，租户反馈有业务影响，登录环境发现docker确实挂掉了，重启docker后业务反馈恢复。]]></description><category></category></item><item><title><![CDATA[排查业务pod内生成未知的环境变量]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/154016099</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/154016099</guid><author>qq_44397993</author><pubDate>Tue, 28 Oct 2025 14:54:39 +0800</pubDate><description><![CDATA[至少可以锁定问题范围，这个分区应该设置了全局变量还是什么，查询半天，没有查询到这些变量的来处。初步怀疑肯定是租户定义的环境变量导致，让租户对对自己打的Dockerfile和pod中定义的环境变量进行核查，租户反馈并没有，然后尝试将这个pod调度到其它分区下，发现容器中哪些未知的环境变量没有了。某上云租户反馈发布的pod容器内会产生一些自己未定义的环境变量，导致租户制作镜像中定义的环境变量被覆盖。2、租户在Dockerfile中声明的变量，可以在创建的pod中，定义env部分的变量内容。]]></description><category></category></item><item><title><![CDATA[线上生产环境envoy网关崩溃处理]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/148708631</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/148708631</guid><author>qq_44397993</author><pubDate>Tue, 17 Jun 2025 10:31:53 +0800</pubDate><description><![CDATA[如上两个根据官方提供的命令测试均未模拟出故障期间的崩溃问题，在设置limit后只出现了413状态码，已经显示出上传文件过大。某线上生产环境反馈部分业务功能不可用了，通过登录环境排查，发现envoy网关pod全部状态异常，通过重启pod无法拉起。如上根据模拟租户侧相同的请求，能复现出当时的故障，而创建envoyfilter后就返回413,并没有崩溃。当时根据日志，当时创建envoyfilter设置max_request_bytes的大小，进行恢复。通过网关崩溃日志发现，存在两处崩溃的日志都有相同的特征。]]></description><category></category></item><item><title><![CDATA[Harbor默认Redis与Notary组件弱口令漏洞分析与修复指南]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/147518099</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/147518099</guid><author>qq_44397993</author><pubDate>Tue, 29 Apr 2025 12:37:39 +0800</pubDate><description><![CDATA[harbor在安装的代码文件中会定义一个docker-compose模板文件，上图就是我截取的一部分，它会通过common/config/notary目录下定义的server和signer的env文件获取对应变量。首先需求确认这三个用户是harbor那个组件使用，最好确认的是default这个用户，它是redis的默认用户，server、signer这两个在harbor.yml配置文件的引用外部组件中有定义，涉及到notary这个组件。core/env文件，123123就是你要设置的redis密码。]]></description><category></category></item><item><title><![CDATA[按时间戳对events数据进行删除]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/147374570</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/147374570</guid><author>qq_44397993</author><pubDate>Sun, 20 Apr 2025 19:59:19 +0800</pubDate><description><![CDATA[按照时间戳对k8s各个namespace下events数据进行删除。]]></description><category></category></item><item><title><![CDATA[harbor因权限问题导致无法启动]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/147308995</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/147308995</guid><author>qq_44397993</author><pubDate>Thu, 17 Apr 2025 16:40:38 +0800</pubDate><description><![CDATA[根据这个报错，也查看了docker-compose.yaml的文件，并没有挂载这个sudo.conf的配置，试着重启下habror，发现无法重启起来，还是报权限的问题，后面试着将harbor换一个新的数据目录，重新安装harbor试试，发现重新安装也拉不起来，还是报如上图一样的报错，很是奇怪。具体什么原因不得而知。一交付未上产环境，因为harbor多次修改密码，重启harbor发现无法正常启动，一直报权限相关错误。]]></description><category></category></item><item><title><![CDATA[logging-operator 部署fluentd-bit日志报kubernetes链接错误]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/145783010</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/145783010</guid><author>qq_44397993</author><pubDate>Fri, 21 Feb 2025 18:15:08 +0800</pubDate><description><![CDATA[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报错。]]></description><category></category></item><item><title><![CDATA[prometheus out of bound 问题处理]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/143866281</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/143866281</guid><author>qq_44397993</author><pubDate>Mon, 18 Nov 2024 20:52:55 +0800</pubDate><description><![CDATA[运行面promtheus因为调整资源，进行了pod重启，导致控制面的一级   prometheus报错，监控数据无法显示。5、删除queries.active 文件。3、删除 chunks_head 目录。1、停止 prometheus 服务。6、启动 prometheus 服务。4、删除 lock 文件。2、删除 wal 目录。]]></description><category></category></item><item><title><![CDATA[envoyFilter导致的webSockets协议无法正常工作]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/143157958</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/143157958</guid><author>qq_44397993</author><pubDate>Tue, 22 Oct 2024 15:07:45 +0800</pubDate><description><![CDATA[开始怀疑难道envoy无法处理次socket,尝试将请求头部分的内容删除，模拟请求发现可以请求通了，然后想到请求头大小导致的，集群做过一次变更，调整了envoy的请求头大小限制，但是这个限制是1G,不可能业务请求头能有这么大，然后删除了创建的envoyfilter，发现业务这个websocket的服务可以正常访问了，百思不得其解。生产项目有一个socket请求经过网关一直无法响应，其它接口服务都能正常处理。]]></description><category></category></item><item><title><![CDATA[调整istio得请求头大小限制]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/142630794</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/142630794</guid><author>qq_44397993</author><pubDate>Sun, 29 Sep 2024 11:01:01 +0800</pubDate><description><![CDATA[在istio-system分区创建一个EnvoyFilter，作用于全局网关实例，yaml如下：metadata:spec:labels:match:listener:filter:#proxy:patch:value:input:map:websocket:action:name: skip。]]></description><category></category></item><item><title><![CDATA[istio 网关开启https访问链接重置]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/142489435</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/142489435</guid><author>qq_44397993</author><pubDate>Tue, 24 Sep 2024 14:54:32 +0800</pubDate><description><![CDATA[后来自己查询相关istio官方文档，猜测可能是证书存在问题，然后根据官方提供的方式生成证书，重新配置，发现可以正常访问了。通过模拟访问，查看网关日志实例，并未有相关请求日志进入。后来一度认为是开发版本的问题，也找咱们相关网关开发查看，也并未发现问题。2、检查网关实例的日志发现无异常，调用网关的接口，查看相应的路由是否添加进去，发现路由添加成功的。一上云租户使用平台提供的istio网关，开启https，然后发现访问一直链接重置。1、检查代理的服务，进行了模拟访问是正常的，排除代理服务的问题。]]></description><category></category></item><item><title><![CDATA[haproxy程序崩溃问题处理]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/142453739</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/142453739</guid><author>qq_44397993</author><pubDate>Mon, 23 Sep 2024 11:30:03 +0800</pubDate><description><![CDATA[查询相关haproxy官网显示，确实存在这个问题，需要将haproxy升级到2.8.4以上，最终自己做了一个haproxy 2.9.9版本的镜像，推送到k8s环境进行观察和高可用测试，发现并无问题后，更新至生产环境，后面就没出现过次问题。线上一k8s环境告警出节点失联，通过排查和k8s的api建立链接失败，检查发现haproxy出现了重启，对应的日志显示出程序运行崩溃，这个情况根据日志追溯，发现曾多次崩溃，后续也在其他k8s环境也有出现。]]></description><category></category></item><item><title><![CDATA[对容器做iptables防火墙规则]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/139487000</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/139487000</guid><author>qq_44397993</author><pubDate>Thu, 06 Jun 2024 09:01:59 +0800</pubDate><description><![CDATA[iptables -I DOCKER -s 192.168.133.130(放行备库mysql） -p tcp --dport 3306 -j ACCEPT。]]></description><category></category></item><item><title><![CDATA[etcd多用途使用脚本]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/138908253</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/138908253</guid><author>qq_44397993</author><pubDate>Wed, 15 May 2024 14:46:19 +0800</pubDate><description><![CDATA[【代码】etcd多用途使用脚本。]]></description><category></category></item><item><title><![CDATA[pod删除后，kubelet无法回收子路径]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/137949727</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/137949727</guid><author>qq_44397993</author><pubDate>Fri, 19 Apr 2024 09:27:23 +0800</pubDate><description><![CDATA[在巡检查看一些kubelet日志的时候发现，kubelet日志中有大量的无法移除子路径的报错，对应的pod都是已经删除的。]]></description><category></category></item><item><title><![CDATA[k8s集群配置NodeLocal DNSCache]]></title><link>https://blog.youkuaiyun.com/qq_44397993/article/details/135509828</link><guid>https://blog.youkuaiyun.com/qq_44397993/article/details/135509828</guid><author>qq_44397993</author><pubDate>Thu, 11 Jan 2024 10:42:37 +0800</pubDate><description><![CDATA[在当今的体系结构中，运行在 ‘ClusterFirst’ DNS 模式下的 Pod 可以连接到 kube-dns serviceIP 进行 DNS 查询。node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址，因为 IPVS 负载均衡使用的接口已经占用了该地址。：集群内的服务基本都是通过域名进行访问，coredns在解析压力大时会存在慢或者丢包的情况，导致服务之间解析异常。1、 使用当前的 DNS 体系结构，如果没有本地 kube-dns/CoreDNS 实例，则具有最高。]]></description><category></category></item></channel></rss>