【云原生技术】探针**就是：Kubelet（K8s 节点上的组件）会**进入容器里执行一条命令**，根据命令的退出码判断健康

1) Exec 探针是什么？怎么用？举例

Exec 探针 就是：Kubelet（K8s 节点上的组件）会进入容器里执行一条命令，根据命令的退出码判断健康：

• 退出码 0：探针成功（健康）
• 非 0：探针失败（不健康）

它适合检查"HTTP 不好表达"的状态，比如：关键文件是否存在、进程是否卡死、依赖是否可用、内部脚本逻辑等。

例子 A：readinessProbe（就绪探针）用 Exec

场景：只有当应用完成初始化并生成 /tmp/ready 文件时才可接流量。

readinessProbe:
  exec:
    command: ["sh", "-c", "test -f /tmp/ready"]
  initialDelaySeconds: 5
  periodSeconds: 3
  timeoutSeconds: 1
  failureThreshold: 3

含义：

• Kubelet 每 3 秒执行一次 test -f /tmp/ready
• 找到文件就 Ready；否则不 Ready（Service 不会把流量转给它）

例子 B：livenessProbe（存活探针）用 Exec

场景：检查主进程是否还在（简单粗暴，但常见）。

livenessProbe:
  exec:
    command: ["sh", "-c", "pidof users-service >/dev/null"]
  periodSeconds: 10
  timeoutSeconds: 1
  failureThreshold: 3

失败 3 次后，K8s 会重启容器（因为认为它"死了/卡死了"）。

注意：Exec 探针命令依赖镜像里有 sh/test/pidof/curl 等工具；精简镜像可能没有，需要改用 HTTP/TCP 探针或加入必要工具。

---

2) "K8s 层面的流量与生命周期"指什么？

流量（Traffic）在 K8s 层面怎么控制

K8s 会用 readinessProbe + Endpoints 决定某个 Pod 是否接收集群内流量：

• Pod Ready ：会被加入 Service 的 Endpoints，集群流量才会转发给它
• Pod NotReady：会从 Endpoints 移除，相当于"摘除流量"（但 Pod 可能还在运行）

生命周期（Lifecycle）在 K8s 层面怎么控制

K8s 会用 livenessProbe/startupProbe 决定是否要：

• 重启容器（Crash/卡死）
• 延长启动宽限（startupProbe 通过前不做 liveness 判定）
• 滚动升级时优雅下线（preStop + readiness 先变 NotReady，再终止）

一句话：

• readiness 管"能不能接流量"
• liveness 管"要不要重启"
• startup 管"启动慢别误杀"

---

3) Pod 到底怎么注册到 Consul？谁干的活？

"注册到 Consul"这件事一定是某个程序做的，常见三种模式：

模式 1：Pod 里有 srpcsrv/agent（sidecar 或伴随进程）------最符合你们说法

• Pod 启动后，srpcsrv 进程拿到 Pod IP/端口/标签
• 调用 Consul API 把这个实例注册进去
• 并维持健康（TTL 心跳或配合健康检查）

谁干活：Pod 内的 srpcsrv/agent

模式 2：业务进程自己带注册能力（SDK 内置）

• 应用启动后（比如 users 服务本身）直接调用 Consul API 注册自己
• 不一定单独有 srpcsrv 进程

谁干活：业务进程（users）

模式 3：K8s 与 Consul 集成组件自动同步（控制器/同步器）

• 集群里有一个组件 watch Pod/Service
• 自动把实例信息同步到 Consul

谁干活：集群里的同步组件（不在 Pod 内）

你们如果明确"srpcgw 先调 srpcsrv，再查 Consul"，通常至少说明 srpcsrv 在"发现侧"存在；至于"注册侧"是不是 srpcsrv 干，需要看你们部署方式（见第 5 问）。

---

4) Consul 健康检查怎么做？谁干的活？

Consul 的健康检查常见也有三类，执行者略不同：

A. HTTP/TCP 主动探测

• Consul（或 Consul agent）定期去访问：
  • HTTP：http://<Address>:<Port>/health
  • TCP：能不能连通 <Address>:<Port>
• 结果写入 Consul：passing / warning / critical

谁干活：Consul/Consul agent 主动去探测

B. TTL（心跳）检查

• Consul 不主动探测
• 需要注册方（srpcsrv/应用）定期调用 Consul：报告 "PASS"
• 超时不报就变 critical

谁干活：发心跳的进程（srpcsrv 或应用）

C. Script/Exec 类检查（在 Consul agent 所在机器上执行）

• 由 Consul agent 在本机执行脚本判断健康（K8s 里用得相对少）

谁干活：Consul agent

---

5) Pod 里怎么会有 srpcsrv 进程？Pod 里有 srpcgw 吗？

Pod 里有 srpcsrv 进程，通常来自两种部署方式

1. Sidecar 容器 ：一个 Pod 里有两个容器：
   • users 容器（业务）
   • srpcsrv 容器（治理/注册/发现/心跳等）
2. 同容器多进程 ：在同一个容器里用 supervisor 等方式同时启动 users + srpcsrv
   （这种不如 sidecar 常见，但也有人用）

你可以通过 kubectl get pod <pod> -o yaml 看 containers: 里是否有第二个容器叫 srpcsrv，最直观。

Pod 里通常没有 srpcgw

• srpcgw 是网关，一般是独立 Deployment（网关 Pod 一组），不跟业务 Pod 混在一起
• 业务 Pod（users）通常只跑业务 +（可选）srpcsrv sidecar

---

6) users 服务 2 个 Pod，一笔交易进来是谁决定走哪个 Pod？

在你们的链路"srpcgw → srpcsrv → Consul"下，通常是两层决策：

第 1 层：是否走信创/非信创 ------ srpcgw 决定

• 例如 30% 信创、70% 非信创
• 或按用户号/机构号一致性分流
• 决定完后，带条件去问 srpcsrv：users + env=xinchuang

第 2 层：在该环境的 2 个 Pod 里选哪一个 ------ srpcsrv 决定

• srpcsrv 从 Consul 拿到该环境下的健康实例列表（2 个 Pod）
• 用负载均衡算法（轮询/权重/最少连接/熔断）选 1 个
• 把选中的 Pod 地址返回给 srpcgw，srpcgw 去转发

只有在"srpcsrv 只返回列表、由 srpcgw 选址"的设计里，才会变成 srpcgw 决定具体 Pod；但你们前面问 srpcsrv 干啥，且是"先调 srpcsrv"，更常见是 srpcsrv 选 Pod。

---