陈日志 发布的文章

背景

近期在一套 Kubernetes 集群中，发现一个非常反常的现象：

  • 在节点上执行 netstat / ss 命令异常缓慢，甚至需要几分钟才能返回结果
  • 节点本身负载并不高，CPU、内存看起来都比较正常

由于 netstat/ss 本质上只是读取内核和 /proc 信息，这种“卡死级别”的慢速，往往意味着 系统层面存在异常规模的数据结构。

这篇文章记录了从一个看似普通的 netstat 慢问题，一步步定位到 Calico socket FD 泄漏 Bug，并最终通过升级版本彻底解决的完整过程。

从 netstat/ss 变慢开始

最初的直接表现是：

time netstat -ntlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:10010         0.0.0.0:*               LISTEN      1530975/cri-dockerd 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1165/sshd: /usr/sbi 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      164980/nginx: worke 
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd           
tcp        0      0 127.0.0.1:9099          0.0.0.0:*               LISTEN      1171111/calico-node 
tcp        0      0 0.0.0.0:20048           0.0.0.0:*               LISTEN      2503623/rpc.mountd  
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.1:10256         0.0.0.0:*               LISTEN      623016/kube-proxy   
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN      1531381/kubelet     
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      623016/kube-proxy   
tcp        0      0 0.0.0.0:57325           0.0.0.0:*               LISTEN      2500368/rpc.statd
tcp        0      0 0.0.0.0:46433           0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      1165/sshd: /usr/sbi 
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd           
tcp6       0      0 :::20048                :::*                    LISTEN      2503623/rpc.mountd  
tcp6       0      0 :::2049                 :::*                    LISTEN      -                   
tcp6       0      0 :::2380                 :::*                    LISTEN      619966/etcd         
tcp6       0      0 :::2379                 :::*                    LISTEN      619966/etcd         
tcp6       0      0 :::40007                :::*                    LISTEN      -                   
tcp6       0      0 :::6443                 :::*                    LISTEN      621032/kube-apiserv 
tcp6       0      0 :::9369                 :::*                    LISTEN      2484838/pushprox-cl 
tcp6       0      0 :::9796                 :::*                    LISTEN      2485357/node_export 
tcp6       0      0 :::10250                :::*                    LISTEN      1531381/kubelet     
tcp6       0      0 :::10259                :::*                    LISTEN      621666/kube-schedul 
tcp6       0      0 :::10257                :::*                    LISTEN      621333/kube-control 
tcp6       0      0 :::48607                :::*                    LISTEN      2500368/rpc.statd   

real    3m21.534s
user    3m9.634s
sys     0m11.357s

可见执行非常慢。

- 阅读剩余部分 -

背景

在一个 Spring Boot 3.x 项目中，为了满足可重复构建（Reproducible Build）的要求(可查看我另一篇文章了解可重复构建)，我在 pom.xml 中新增了如下配置：

<project.build.outputTimestamp>2026-01-01T00:00:00Z</project.build.outputTimestamp>

该配置用于固定构建产物的时间戳，确保多次构建生成的 JAR 文件在字节级别保持一致。

然而，加上该配置后，应用在运行时出现了异常：

  • 启动正常
  • 业务请求触发时抛出运行时错误
  • 错误与 okhttp 相关
jakarta.servlet.ServletException: Handler dispatch failed: java.lang.NoClassDefFoundError: Could not initialize class com.xxx.common.util.HttpUtil
...
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.xxx.common.util.HttpUtil
...
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchFieldError: Companion [in thread "http-nio-80-exec-9"]
    at okhttp3.internal.Util.<clinit>(Util.kt:70) ~[okhttp-4.10.0.jar!/:?]

而在未添加该配置时，应用运行完全正常。

- 阅读剩余部分 -

在很长一段时间里，Ingress 是 Kubernetes 集群的标准北向流量入口。但随着业务复杂度增加、微服务体系兴起、多协议需求增长，Ingress 的先天缺陷越来越明显。

2024–2025 年，Kubernetes 官方与 CNCF 明确：

Gateway API 是下一代流量管理标准，将逐步取代 Ingress 成为默认推荐方式。

而随着 ingress-nginx 宣布在 2026 年 3 月停止维护，Gateway API 的迁移意义愈发明确。

本文将从原理、对比、设计理念、CRD、部署与使用示例多个方面全面介绍 Gateway API。

1. 什么是 Gateway API？

Gateway API 是 Kubernetes SIG-Network 推出的新一代流量治理标准。

核心目标：

  • 统一 L4/L7 流量管理
  • 取代 Ingress 的简陋模型
  • 提供可扩展、可观察、可分权协作的网关体系
  • 能适配云厂商、服务网格、Ingress 控制器等各种实现

image.png

- 阅读剩余部分 -

在软件开发与数据库管理的日常中，程序bug或误执行SQL语句导致的数据错误更新是一个不容忽视的问题。这类问题不仅可能导致业务数据的混乱，还可能对企业造成严重的经济损失。幸运的是，数据库系统为我们提供了一种强大的数据恢复机制——binlog（Binary Log），它能够记录所有修改数据的SQL语句，为我们在数据遭遇不测时提供了一线生机。本文将详细介绍如何通过解析binlog来恢复因程序bug或误执行SQL导致的数据错误更新或删除。

binlog基础

什么是binlog？

binlog是MySQL数据库中的一种二进制日志文件，它记录了数据库中所有修改数据的SQL语句，包括增删改操作。binlog的主要作用是用于数据库的主从复制和数据恢复。

binlog的类型

MySQL的binlog有三种格式：STATEMENT、ROW和MIXED。

  • STATEMENT：记录每一条会修改数据的SQL语句本身。
  • ROW：记录每一行数据的变化，不记录SQL语句本身。
  • MIXED：默认情况下使用STATEMENT格式，但在某些特殊情况下会自动切换为ROW格式。

- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 25