★ FEATURED ARTICLE “C与Kubernetes集成”这个标题初看有点模糊因为C和K8s不是同一个层面的东西。但我猜你实际想解决的是这个问题我手上有一个C写的后端服务、中间件或者算法引擎现在要把它容器化并部署到Kubernetes上真正跑起来之后C进程和K8s集群之间到底需要在哪些点上“对接”怎么对接才不翻车我见过太多团队把“集成”等同于“打镜像写Deployment”等上了生产才发现健康检查频繁误杀进程、优雅退出没生效导致请求被掐断、服务发现靠缓存IP结果滚动更新后一批请求404、监控指标暴露格式不对被Prometheus抓不到……这些问题本质上不是K8s配置写错了而是C这层完全没有为K8s的运行模型做适配。这篇文章我就从C进程的视角把和Kubernetes集成的几个核心触点拆开讲清楚包括生命周期信号、探针接口、API访问路径、观测与配置同步再把几个真实踩坑的排查过程完整复盘。1. C接入K8s不是“打镜像”先理清四个核心集成触点很多人第一次把C服务部署到K8s时第一反应是人手一个Dockerfile然后写个Deployment文件kubectl apply之后看到Pod Running就以为完事了。实际上Kubernetes对进程的管理方式和你直接在裸机上跑二进制是完全不同的它假设每个进程都遵守一套“平台契约”不遵守就会在运行期出现各种诡异问题。1.1 集成触点全景图进程与集群的每一次交互我习惯把C服务与K8s的集成拆成四个层次每次有新项目接入时都按这个清单过一遍集成层次具体触点C侧需要做什么不做的后果生命周期镜像内容、启动命令、信号处理、退出码处理SIGTERM、优雅关闭线程池和连接、合理设置退出码Pod被强杀、流量受损、滚动更新失败健康检查liveness/readiness探针接口暴露HTTP或TCP探针端口返回真实状态探针误杀、流量打到未就绪实例控制面交互Kubernetes API、Service发现、ConfigMap/Secret通过REST或SDK访问API、正确使用服务发现机制无法实现自定义控制器、配置不生效可观测性指标暴露、日志采集、链路追踪暴露Prometheus格式指标、日志输出到标准输出监控数据缺失、排障困难这四个层次里前两个是“被动适配”K8s会主动来管你的进程你躲不掉后两个是“主动集成”你需要自己去访问集群的能力。很多C项目只做了后两个中的一小部分前两个完全没有意识结果就是进程能跑但跑不稳。1.2 为什么C项目在K8s里比Go项目更容易出问题这不是说C不行而是C的历史包袱决定了它在容器环境里更容易踩坑。Go的运行时天然为容器设计静态编译、信号处理简单、goroutine被调度器管理SIGTERM来了默认退出配合K8s的默认行为就很顺。C不一样你可能用了第三方库起了一堆后台线程可能在全局某个地方捕获了SIGCHLD可能用dlopen加载动态库可能没注意std::thread的析构行为更常见的是你根本不知道K8s默认给你的优雅退出时间窗口只有30秒。更重要的一点C服务的运行依赖通常比Go多比如OpenBLAS的线程数、gRPC的线程池大小、libcurl的DNS缓存、TCMalloc的内存释放策略。这些东西在裸机上不敏感但放在Pod里配合cgroup限制、探针超时、优雅退出时间窗任何一个设置不合理都会成为生产事故的导火索。所以我一直强调一个观点“C与Kubernetes集成”不是某一个工具或SDK而是让C进程符合一种被容器平台纳管的运行方式。下面每一章我会拆开讲怎么做到。2. 生命周期管理镜像构建与SIGTERM优雅退出缺一不可2.1 多阶段构建模板静态链接优先别让glibc坑你C镜像踩得最多的坑是“能编译但跑不起来”典型报错是version GLIBCXX_3.4.29 not found或者error while loading shared libraries。原因很简单编译环境的glibc/libstdc版本比运行环境新动态链接运行时找不到对应符号。K8s镜像如果基于精简版基础镜像问题尤其严重。多阶段构建是目前最常用的解法我个人推荐一个组合编译阶段用较新的Ubuntu镜像运行阶段用distroless或者带最少依赖的Ubuntu LTS版本。关键是C编译器默认是动态链接glibc的所以要么用-static-libgcc -static-libstdc做部分静态要么加-static完全静态。一个可用的CMake构建Dockerfile模板大致长这样# 编译阶段 FROM ubuntu:22.04 AS builder RUN apt-get update apt-get install -y \ build-essential cmake libssl-dev libcurl4-openssl-dev \ protobuf-compiler libprotobuf-dev WORKDIR /src COPY . . RUN cmake -B build -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_FLAGS-static-libgcc -static-libstdc RUN cmake --build build -j$(nproc) # 运行阶段 FROM ubuntu:22.04 RUN apt-get update apt-get install -y --no-install-recommends ca-certificates \ rm -rf /var/lib/apt/lists/* COPY --frombuilder /src/build/my_service /usr/local/bin/my_service ENTRYPOINT [/usr/local/bin/my_service]这里加ca-certificates是给libcurl访问HTTPS用的去掉它你会发现调用外部HTTPS接口时全部报证书错误。如果完全静态链接没有动态依赖运行阶段可以直接上gcr.io/distroless/cc这类精简镜像但要注意里面没有shellkubectl exec进去排查会很难受我通常还是保留一个可用的运行环境。2.2 SIGTERM信号处理默认行为是“被杀死”不是你“主动退出”Kubernetes滚动更新时会先给旧Pod发SIGTERM然后等待terminationGracePeriodSeconds默认30秒超时后发SIGKILL强杀。关键点来了如果你在C代码里没有显式处理SIGTERM默认行为是进程直接终止。这个直接终止对多线程服务来说是灾难因为正在处理中的HTTP请求/ gRPC请求被中断客户端看到连接被重置已写入socket缓冲区但未flush的数据丢失第三方库持有锁的临界区没有机会释放如果这个锁被文件映射之类的机制持有下次启动可能出问题异步写盘的操作被截断产生损坏的WAL或数据文件正确的做法是启动时安装信号处理器收到SIGTERM后进入一个“优雅关闭”流程。C里信号处理有个经典约束信号处理函数里只能调用async-signal-safe函数不能直接std::cout、不能new、不能加锁。最稳妥的方案是信号处理器里只写一个volatile sig_atomic_t标志位主线程循环检查#include csignal #include atomic #include chrono #include thread std::atomicbool g_stop_requested{false}; extern C void handle_sigterm(int) { g_stop_requested.store(true); } void InstallSignalHandlers() { struct sigaction sa; sa.sa_handler handle_sigterm; sigemptyset(sa.sa_mask); sa.sa_flags 0; // 只拦SIGTERM和SIGINTSIGQUIT留给调试 sigaction(SIGTERM, sa, nullptr); sigaction(SIGINT, sa, nullptr); } void RunServer() { while (!g_stop_requested.load()) { // 处理网络事件、执行任务... std::this_thread::sleep_for(std::chrono::milliseconds(100)); } // 停止接收新请求 - 等待在途请求完成 - 释放资源 ShutdownHttpServer(); ShutdownThreadPools(); }如果你的服务用的是gRPC还要调用grpc_server_shutdown并等待所有RPC结束如果是自研的TCP长连接服务必须先停止accept新连接再给已有连接一个宽限期超时才直接close。注意退出码也要设置好优雅关闭用0异常终止用非零退出码K8s的restartPolicy才会按你的预期去重启Pod。2.3 terminationGracePeriodSeconds30秒到底够不够很多人没算过账从收到SIGTERM到K8s发SIGKILL的这30秒内你要完成“停止接收请求、排空在途请求、持久化数据、关闭连接、释放资源”这一整套动作。如果你的服务平均请求耗时2秒把在途请求全部排空可能就要十几秒。再加上gRPC的graceful shutdown有时会block等待流式RPC结束30秒真的会紧张。建议在Deployment里显式调大spec: terminationGracePeriodSeconds: 60 containers: - name: my-cpp-server image: myregistry/my-cpp-server:1.2.3同时C侧要做一层保护在信号处理主循环里监听一个“最后期限”比如进入shutdown后最多等45秒超时直接_exit(1)把账算清楚。这里有一个我实际用过的技巧在优雅关闭流程开始时立刻把readiness探针切换为“不健康”状态这样Service的endpoint会先从负载均衡池里摘掉这个Pod新的流量不会再进来剩下的时间纯粹排空在途请求。这个联动很重要后面探针章节我会详说。3. 探针接口怎么写得让K8s满意健康检查实现与调参探针是K8s和C进程之间最直接的交互。探针设计不好轻则Pod一直重启重则流量被打到不健康实例上引发雪崩。3.1 liveness和readiness的本质区别想清楚再动手用生活化类比解释liveness探针是“这个进程还活着吗”如果它失败K8s会杀掉Pod重启readiness探针是“这个进程准备好接收流量了吗”如果它失败K8s不会杀Pod但会把Pod从Service的负载均衡endpoint里摘掉。对C服务来说我一般这样设计liveness只要进程能响应探针请求就视为存活。探针逻辑尽可能简单比如检查进程内部的事件循环是否在跑、关键线程是否还活着。readiness从进程“能接收流量”的标准出发。比如HTTP服务检查监听socket是否可accept如果服务启动时需要加载几十GB的词表或模型readiness必须在加载完成后才返回200如果服务依赖下游数据库或外部缓存这里可以加一个轻量依赖检查但要注意不能太重。关键的越界设计不要在readiness探针里查数据库、查Redis、调用下游复杂接口。探针会被K8s周期性调用默认每10秒一次如果下游某个时刻抖动所有Pod的readiness同时失败流量瞬间清零整个集群直接干崩。探针只回答“服务是否就绪”不回答“依赖是否健康”这种全局问题。3.2 C里如何实现一个探针HTTP端点如果你的服务已经有HTTP框架比如Drogon、CivetWeb、cpp-httplib直接加一个路由即可。如果是纯自研TCP协议服务最简单的做法是在同一个监听fd上根据HTTP请求的第一行做判断或者干脆单独开一个探针监听端口。不要用exec探针去执行脚本C镜像里往往没有shexec探针大多数时候反而是负担。下面是用cpp-httplib写探针端的极简示例#include httplib.h void StartHealthCheckServer(uint16_t port) { httplib::Server srv; srv.Get(/healthz, [](const httplib::Request, httplib::Response res) { res.status 200; res.set_content(ok, text/plain); }); srv.Get(/readyz, [](const httplib::Request, httplib::Response res) { if (g_server_state ServerState::kReady) { res.status 200; res.set_content(ready, text/plain); } else { res.status 503; } }); srv.listen(0.0.0.0, port); }注意几个细节监听地址必须绑0.0.0.0而不是127.0.0.1Pod内的探针请求来自kubelet虽然通常在同一节点网络命名空间但K8s探针访问的是Pod IP不是localhost绑错了必挂。readiness接口里用g_server_state这种全局状态控制而不是每次查询依赖服务的可用性精准呼应前面的原则。探针本身要轻量不要在线程池繁忙时也去抢线程资源如果线程池已经全是阻塞状态readiness接口也应该能响应。3.3 探针参数调优别默认三个参数的搭配逻辑很多人的探针配置是抄模板的initialDelaySeconds: 10, periodSeconds: 10, timeoutSeconds: 1这组参数对C服务往往不合适。我提供一个调参顺序initialDelaySeconds设置成“服务启动到能响应探针的时间”再加上15~20秒缓冲。比如C服务启动要5秒加载配置、10秒初始化模型探针初始延迟至少30秒。设短了会导致启动早期probe失败虽然失败几次内不会真的杀掉Pod但日志里满是错误会干扰排障。periodSeconds默认10通常够用。如果探针接口很轻量可以加大到15或20降低无效请求不要小于5会给进程增加没意义的压力。timeoutSecondsC服务在高负载下探针响应可能变慢默认1秒太激进。我一般设3秒配合failureThreshold: 3这样最坏情况是9秒内连续3次失败才触发动作给进程留了恢复余地。failureThreshold这是“容忍度”。如果服务有GC停顿比如jvm才有的问题在C里不明显但真遇到全量内存压缩重置时也会卡顿阈值要调大。一个我实际线上的配置参考livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 15 timeoutSeconds: 3 failureThreshold: 3 successThreshold: 1 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 successThreshold: 1你可能会问liveness和readiness的initialDelaySeconds为什么要一致因为readiness失败不会导致Pod被杀但会让Pod处于NotReady状态如果初始延迟不一致可能出现Pod一直Ready但readiness还没定义好或者反过来Pod一直在重启但readiness没起来。一致便于观察。4. C进程如何安全访问Kubernetes API三条现实路径C服务和K8s控制面交互的场景主要有两个一是侧车模式里C进程需要查询Pod信息、Service endpoint、配置二是写自定义控制器时C作为业务逻辑核心需要watch CRD对象。但在动笔之前我要先泼盆冷水在C里硬调Kubernetes API的成本比你想象的高很多场景根本不需要你自己调。4.1 不需要调API的场景先试试K8s原生机制举几个最容易被误判的场景服务发现如果你的C服务需要找到另一组服务的地址优先用K8s的DNS服务发现也就是my-service.namespace.svc.cluster.local:port而不是自己调用API去list Pod。这样完全不用写API代码C里用getaddrinfo正常解析域名就行。配置下发静态配置放到ConfigMap通过环境变量或文件挂载注入Pod不要自己写一个config-server然后通过API轮询。访问其他服务优先用headless Service 客户端自定义负载均衡或者直接用Service的ClusterIP做四层负载均衡。只有在这些原生机制覆盖不了的场景比如要动态感知Pod的标签变化、要watch自定义资源、要做多租户的资源调度才需要考虑调API。4.2 路径一基于ServiceAccount直接调用REST API这是最直接的方案在Pod内以ServiceAccount身份访问API ServerC侧用libcurl发HTTPS请求。三个关键文件位于/var/run/secrets/kubernetes.io/serviceaccount/tokenServiceAccount的Bearer token用于身份认证ca.crt集群CA证书用于TLS校验namespace当前Pod所在的命名空间代码逻辑大致是#include curl/curl.h #include fstream #include sstream std::string ReadFile(const std::string path) { std::ifstream ifs(path); std::ostringstream oss; oss ifs.rdbuf(); return oss.str(); } bool CallKubernetesApi(const std::string api_path, std::string response) { const std::string base https://kubernetes.default.svc.cluster.local:443; const std::string token ReadFile(/var/run/secrets/kubernetes.io/serviceaccount/token); const std::string ca /var/run/secrets/kubernetes.io/serviceaccount/ca.crt; CURL* curl curl_easy_init(); curl_easy_setopt(curl, CURLOPT_URL, (base api_path).c_str()); curl_easy_setopt(curl, CURLOPT_CAINFO, ca.c_str()); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, curl_slist_append(nullptr, (Authorization: Bearer token).c_str())); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, curl_slist_append(nullptr, Accept: application/json)); // ... 设置写回调把response写入string CURLcode res curl_easy_perform(curl); curl_easy_cleanup(curl); return res CURLE_OK; }注意curl_slist_append返回的链表要在curl全局清理时释放否则会内存泄漏另外CURLOPT_CAINFO指向的CA文件必须存在。RBAC权限是另一个大坑默认的defaultServiceAccount往往没有list Pod的权限你要在Deployment里显式指定serviceAccountName并创建对应的Role和RoleBinding。4.3 路径二使用C Kubernetes客户端库如果不想手写REST请求和JSON解析可以找现成的C客户端库。目前比较成熟的主要是基于OpenAPI生成的和几个半维护状态的库。选择时注意几个点是否支持watch机制如果你需要监听资源变化而不是轮询必须确认库实现了watch长连接。很多简单库只支持get/list。依赖复杂度一些库基于cpprestsdk体量很大如果只是list一个资源手写curl反而更轻。生成的API覆盖度K8s API在v1.20之后有较大的版本变化库更新不及时会导致字段类型不匹配。我个人的建议是少量调用场景直接REST nlohmann/json解析需要频繁watch资源或做控制器时优先考虑Go写operator。Go的client-go是社区事实标准对K8s的控制面交互支持是C生态无法相比的。一个实际项目中C核心逻辑可以通过gRPC和Go operator通信把复杂状态机放在Go侧业务计算放在C侧两边边界清晰。4.4 路径三sidecar模式——C不该硬啃的API就交给别人如果你的C服务只是需要在Pod启动时获取一次配置、或者查询一次节点信息完全可以在initContainer里用一个轻量工具去访问API把结果写到共享volumeC进程启动时直接读文件。这样C侧不用引入任何API库也不会有token管理的安全问题。spec: initContainers: - name: fetch-config image: bitnami/kubectl:1.28 command: [sh, -c, kubectl get cm my-config -o jsonpath{.data.config.toml} /shared/config.toml] volumeMounts: - name: shared mountPath: /shared containers: - name: main image: myregistry/my-cpp-server:1.2.3 volumeMounts: - name: shared mountPath: /shared这种设计的好处是显而易见的C进程完全不知道K8s的存在它只负责读一个文件K8s相关的认证、RBAC、API调用全部隔离在initContainer里。我经常拿这个模式举例子能用平台能力解决的就别在业务进程里造轮子。5. 观测与配置集成监控指标、日志和配置热更新的实践集成做完了以后日常运维还靠三件套指标、日志、配置。5.1 Prometheus指标暴露C侧写清楚文本格式Prometheus抓取指标依赖HTTP接口返回metrics文本。C服务要么用已有的Prometheus客户端库如prometheus-cpp要么自己拼文本。自己拼看起来简单实际坑不少label转义、帮助文本格式、counter单调递增等。我建议直接用prometheus-cpp它内部帮你处理了这些琐碎的格式问题。核心注意三点指标类型计数器counter只增不减适合请求总数、错误总数仪表gauge可以升降适合当前连接数、队列长度、内存使用量直方图histogram适合耗时分布。线程安全多线程C服务里更新指标变量必须用std::atomic或者在指标对象内部做同步。不要每次请求都锁整个map高并发下锁竞争会拖垮性能。常见的优化是按线程分片聚合时合并。抓取路径不要阻塞/metrics接口被Prometheus每15秒抓一次响应要快。如果指标计算过程里要遍历大量对象并且期间要加锁需要做性能预算和快照优化。一个最简单的gauge示例#include prometheus/exposer.h #include prometheus/registry.h #include prometheus/family.h #include prometheus/gauge.h auto registry std::make_sharedprometheus::Registry(); auto family prometheus::BuildGauge() .Name(my_service_connections) .Help(Current active connections) .Register(*registry); auto gauge family.Add({{protocol, tcp}}); // 连接建立时 , 关闭时 -- gauge.Increment(); gauge.Decrement();5.2 日志别把日志写到容器内文件这是C项目迁移到K8s时最常见的“惯性错误”沿用裸机时代的习惯把日志写到/var/log/my_service/。在Pod里这样做的问题在于Pod的文件系统是临时的一旦Pod被重新调度日志全部丢失。更麻烦的是K8s生态的日志采集方案默认都在/dev/stdout上做写到文件里的日志采集不到运维侧直接抓瞎。解决方案有两个首选日志输出到标准输出K8s会把stdout和stderr自动收集到节点层的容器日志文件再由Fluentd/Loki/CloudWatch之类的组件采集走。C里用spdlog可以同时设置console sink和file sinkconsole sink打在Pod里就是stdout。次选日志写到挂载了hostPath或PVC的目录适合日志量大、需要本地文件辅助排障的场景。但要按文件大小做轮转避免把磁盘写爆。一个实用的spdlog配置模式#include spdlog/sinks/stdout_color_sinks.h #include spdlog/sinks/rotating_file_sink.h #include spdlog/async.h std::shared_ptrspdlog::logger CreateLogger() { auto console std::make_sharedspdlog::sinks::stdout_color_sink_mt(); auto file std::make_sharedspdlog::sinks::rotating_file_sink_mt( /var/log/my_service/app.log, 100 * 1024 * 1024, 5); std::vectorspdlog::sink_ptr sinks{console, file}; auto logger std::make_sharedspdlog::logger(multi, sinks.begin(), sinks.end()); logger-set_level(spdlog::level::info); logger-flush_on(spdlog::level::info); return logger; }注意flush_on设成info级别后每条日志都会flush虽然性能不如批量flush但换取的是“容器OOM或pod被杀时日志不丢”在K8s里我认为这个取舍很值。5.3 ConfigMap/Secret热加载不要幻想自动同步C项目在K8s里用ConfigMap最常见的方式是环境变量和文件挂载。这里有个反直觉的事实K8s不会因为ConfigMap变化就自动重启Pod也不会实时同步到环境变量。环境变量只在容器启动时注入一次文件挂载的方式下kubelet会定期把新的ConfigMap内容同步到Pod文件系统但同步延迟可能是几十秒甚至几分钟而且如果你用subPath方式挂载单文件内容根本不会更新。C侧要拿到动态配置通常两种做法轮询文件循环检查挂载路径下的文件mtime内容变化后重新解析配置。这最简单但要小心一次变更被多次触发或者配置解析中途文件被截断读到半截。inotify事件驱动用Linux的inotify监听文件变更事件收到IN_MODIFY或IN_CLOSE_WRITE再去读文件。注意bind mount到Pod的ConfigMap目录在更新时行为可能是一个目录下的原子替换你要监听的是目录而不是单文件细节很多。一个务实建议优先把“启动之后不会变化”的配置放在启动参数或环境变量只有真正需要热更新的配置比如功能开关、流量比例才走ConfigMap热加载而且热加载代码里要做原子替换和滚动发布别一上来就用inotify。6. 三个线上问题的完整排查链路从现象到根因最后我用三个真实复盘把前面讲过的知识点串起来。这三个案例都是我实际跟进过的C服务接入K8s后冒出的问题很有代表性。6.1 案例一readiness探针端口未监听导致Pod无限重启现象很直观kubectl get pods看到一个Pod反复CrashLoopBackOffdescribe里探针上报readiness probe failed: HTTP probe failed with statuscode: 404。团队最初怀疑是探针路径写错把/readyz改成/healthz后依然失败。排查链路是这样的先kubectl logs看主进程日志显示HTTP服务器已启动也打印了监听端口。然后kubectl exec进Pod里用curl localhost:8080/healthz居然通了。这就很诡异容器内访问正常kubelet访问失败继续看describe pod的Events和Pod IP注意到K8s探针是访问Pod IP上的端口而不是容器的localhost。手动尝试curl pod-ip:8080/healthz连接超时。最后进容器看监听地址发现HTTP框架默认只监听了127.0.0.1因为我当时图方便在代码里写了listen(localhost, 8080)。K8s的探针包到达的是eth0网卡的Pod IP自然连不上。这里的教训是容器里监听地址必须填0.0.0.0。这是一个极其隐蔽的坑因为本地开发时一切正常容器里手动curl也正常只有kubelet跨网络命名空间访问时才暴露。6.2 案例二探针超时太短把长连接服务打崩现象是服务高峰期Pod频繁重启每次重启前都有大量Connection reset by peer。看监控发现内存和CPU并不高但探针失败次数很多。团队一度怀疑是服务代码有内存泄漏折腾了一周。排查时我怀疑是探针超时和业务线程池的问题我们的C服务处理一个请求平均耗时2秒个别长查询要5秒以上。探针请求本身虽然简单但它要经过HTTP框架的线程池当线程池所有线程都被长请求占满时新请求只能排队。默认timeoutSeconds: 1加上failureThreshold: 3意味着6秒内如果线程池还腾不出手探针连续失败Pod被判定不健康。为什么这会导致雪崩因为所有Pod在同一时间都进入长查询高峰期所有探针都超时readiness全部变为不健康——虽然K8s没有杀Pod但Service的endpoint把这些Pod全摘掉了外部流量打不进来堆积的请求更多线程池更堵死锁一般的正反馈。liveness一超时再判死直接重启Pod重启期间流量继续堆积。修复手段是组合拳把timeoutSeconds从1调到3failureThreshold从默认的1很多模板是1调到3同时优化线程池给探针请求单开一个轻量级处理函数不经过业务线程池再加上业务侧的线程池排队长度限制拒绝过多请求而不是无限堆积。这个案例的核心认知是探针不是功能它是K8s对进程状态的裁决机制参数必须结合你的服务延迟画像来设计。默认参数只适合秒回的小服务不适合有大量长任务的C服务。6.3 案例三C侧缓存了Service ClusterIP滚动更新后一批请求404现象更隐蔽服务滚动更新后一部分请求会落到已终止的Pod上出现偶发404和连接拒绝。看K8s的Endpoint更新后新增Pod已Ready旧Pod也处于Terminating流量理论上应该只到新Pod。但业务侧观测到仍有少量请求打到旧Pod IP。根因定位到了C客户端代码我们的C服务为了性能在启动时通过getaddrinfo解析一次Service的ClusterIP然后把IP缓存起来之后所有请求都发到这个固定IP。滚动更新时旧Pod挂掉后这个ClusterIP的后端列表变化但客户端不会刷新更糟的是如果旧Pod的endpoint被摘除后重建新Pod同一个ClusterIP后面挂的后端已经不同客户端仍然往旧IP堆请求旧连接全部被RST。排查证据链用kubectl describe endpoints看Endpoint变化和报错时间点对齐C侧加日志打印每次请求的目标IP发现一直是同一个ClusterIP并且是旧Pod的IP。修复方案是把缓存的IP改为每请求解析一次或者至少每30秒刷新一次更进一步用K8s原生的headless Service做DNS轮询让C侧每次getaddrinfo拿到多个Pod IP再在客户端做简单的健康判断。这个案例说明一个普遍规律K8s天然假设服务发现是动态的你的C代码如果有任何形式的IP缓存都要考虑它的失效生命周期。结语我给C项目接入K8s的一条黄金建议这些案例反复验证了一个原则我现在写进团队接入文档第一页K8s管理的是“进程的声明状态”你的C程序必须用平台能理解的信号、端口、协议、格式来表达自己的状态。不要试图隐藏监听地址、不要忽略SIGTERM、不要缓存集群内的服务地址、不要写容器内文件日志、不要幻想ConfigMap会自己热更新。如果你正在把自己维护多年的C服务迁到Kubernetes我建议第一步不是写Deployment而是先用我第2和第3章的方法把生命周期和探针接口在裸机上模拟一遍发一个SIGTERM看进程能不能在预期时间内优雅退出启动一个探针客户端从外部IP访问探针端口看响不响应。这两件事做扎实了后面接入K8s就是水到渠成的事情。最后分享一个小技巧如果你在用systemd管理过C服务可以把K8s的Pod理解成一个简化版但生命周期更强的systemd单元只是它只管SIGTERM、健康检查、重启策略这三件事其余的都交给你的程序自己负责。带着这个心智模型去设计集成方案很多决策会变得简单。
阅读完成 · 觉得有帮助？
