标签: #gRPC
用亲手运行、亲手测量的数据来写 Kubernetes、DevOps 与 MLOps · 7 篇
带有 #gRPC 标签的文章共 7 篇，最新一篇发布于 2026-10-16。
常一起出现的标签: #gRPC 해부 7 #OpenTelemetry 3 #etcd 3 #HTTP/2 2 #protobuf 2
gRPC 调试与可观测性：grpcurl、反射、channelz 以及指标陷阱
gRPC 是基于二进制的，因此无法用 curl 直接查看。取而代之的是，服务器自身告知其架构的反射（grpcurl 使用此功能）、标准健康检查服务、统计通道、子通道及套接字的 channelz，以及作为窗口的指标。我们在小型集群的指标中发现了两个陷阱：kube-apiserver 1.34 的 etcd 客户端指标 grpcclientmsgreceivedtotal 在一元调用中统计的不是成功而是失败（Range 132 次 = Ra
2026-10-16 · 18 分钟阅读 #gRPC#grpcurl#서버 리플렉션#channelz#Prometheusgrpc-go 代码地图：从 ClientConn 到 http2Client，从 Serve 到 Handler
grpc-go 的客户端有五层。Channel（ClientConn）包装了解析器（Resolver）和负载均衡器（Balancer），Balancer 创建了子通道（addrConn），每次调用时 Picker 挑选一个 READY 的子通道并在其 HTTP/2 传输（http2Client）上打开一个 Stream。服务器从 Serve 到每个连接的 http2Server，再到每个流的 handleStream，最后下发到从服务表
2026-10-16 · 16 分钟阅读 #gRPC#grpc-go#코드 읽기#오픈소스#Go小型集群中实际运行的 gRPC：etcd、CRI、Hubble、OTLP
我们在一个只有 8 个节点的微型集群中，仅通过读取 gRPC 会话对进行了测量。kube-apiserver 与同一节点上的 etcd 建立了多达 247 个 TCP 连接，这是因为 Kubernetes 会为每个资源（包括 CRD）单独创建 etcd 客户端，源码注释中也将此记为一个已知问题。kubelet 在 containerd 上打开了运行时和镜像两个通道，8 个节点合计每小时调用约 11 万次 CRI，其中一半以上是 1 秒周
2026-10-16 · 19 分钟阅读 #gRPC#etcd#CRI#containerd#Hubble流式传输、deadline、重试、keepalive：当调用变长或失败时
gRPC 方法根据请求和响应是单个还是流，分为四种。流由 HTTP/2 流量控制窗口进行拦截，时间限制作为剩余的 deadline 传递给下一个服务器，取消操作通过 RSTSTREAM 传播。库重试仅在服务器发送响应头之前（Trailers-Only）进行，最多 5 次，带有 0.8 到 1.2 倍的抖动。grpc-go 1.83 尚未实现 hedging。在一个小集群中，单个 apiserver 在 etcd 上大约打开了 240 个
2026-10-16 · 20 分钟阅读 #gRPC#스트리밍#deadline#재시도#keepaliveprotobuf 传输格式：逐字节拆解 21 字节
protobuf 消息是“标签（字段编号和传输类型）+ 值”的排列。整数采用每 7 位一组的 varint 编码，字符串和嵌套结构在前面附加长度，默认值则根本不发送。仅使用标准库手写编码一个乒乓球回合（Rally）的数据大小为 21 字节，而相同内容的 JSON 为 72 字节（缩进后为 111 字节）。用 int32 发送 -1 需要 10 字节，而用 sint32 发送只需 1 字节。由于字节中写入的是字段编号而不是字段名称，只要保
2026-10-16 · 12 分钟阅读 #gRPC#protobuf#varint#직렬화#하위 호환HTTP/2 上的 gRPC：头部、5 字节前缀、Trailer 中的状态码
每一个 gRPC 调用都是一个 HTTP/2 流。请求以 POST 和 :path /package.service/method、content-type: application/grpc、te: trailers 开始，每条消息前面带有 1 字节的压缩标志和 4 字节的长度。结果不是由 HTTP 状态（通常为 200）决定的，而是由响应末尾的 Trailer grpc-status 决定的。我们追踪了 grpc-go 生成此头部和
2026-10-16 · 20 分钟阅读 #gRPC#HTTP/2#트레일러#상태 코드#grpc-timeoutgRPC 解决的问题与全貌：契约、代码生成、通道、HTTP/2
gRPC 将“像调用本地函数一样调用远程函数”这一过程拆分为四个部分：契约（.proto）、从契约中生成的各语言代码（存根）、负责连接和负载均衡的通道，以及底层的 HTTP/2。本文总结了这四个部分各自的职责，为什么不使用 JSON over HTTP/1.1 而是这样拆分，以及付出的代价。读取一个小集群（8个节点）的指标后发现，apiserver→etcd、kubelet→containerd、Hubble、OTLP、Argo CD、
2026-10-16 · 13 分钟阅读 #gRPC#protobuf#HTTP/2#RPC#쿠버네티스