태그: #gRPC

← 전체 글

• gRPC 디버깅과 관측: grpcurl, 리플렉션, channelz, 그리고 메트릭의 함정

  gRPC 는 이진이라 curl 로 들여다볼 수 없습니다. 대신 서버가 스스로 스키마를 알려 주는 리플렉션(grpcurl 이 이것을 씀), 표준 헬스 서비스, 채널·서브채널·소켓의 통계를 내주는 channelz, 그리고 메트릭이 창 역할을 합니다. 작은 클러스터의 지표에서 함정 둘을 찾았습니다. kube-apiserver 1.34 의 etcd 클라이언트 지표 grpcclientmsgreceiv

  2026-10-16 · 18 분 읽기 #gRPC#grpcurl#서버 리플렉션#channelz#Prometheus

• grpc-go 코드 지도: ClientConn 에서 http2Client 까지, Serve 에서 핸들러까지

  grpc-go 의 클라이언트는 다섯 겹입니다. 채널(ClientConn)이 리졸버 포장과 밸런서 포장을 거느리고, 밸런서는 서브채널(addrConn)을 만들며, 호출마다 픽커가 READY 인 서브채널 하나를 골라 그 HTTP/2 전송(http2Client)에 스트림을 엽니다. 서버는 Serve → 연결마다 http2Server → 스트림마다 handleStream → 서비스 표에서 찾은 핸들

  2026-10-16 · 16 분 읽기 #gRPC#grpc-go#코드 읽기#오픈소스#Go

• 작은 클러스터에서 실제로 도는 gRPC: etcd, CRI, Hubble, OTLP

  노드 8대짜리 작은 클러스터에서 gRPC 대화 넷을 읽기만 해서 쟀습니다. kube-apiserver 는 같은 노드의 etcd 에 TCP 연결을 247개나 열어 두었는데, 쿠버네티스가 자원(CRD 포함)마다 etcd 클라이언트를 따로 만들기 때문이며 소스 주석이 이것을 알려진 문제로 적고 있습니다. kubelet 은 containerd 에 런타임·이미지 채널 둘을 열고 8대 합계 시간당 약

  2026-10-16 · 19 분 읽기 #gRPC#etcd#CRI#containerd#Hubble

• 쿠버네티스에서의 gRPC: 한 파드로 쏠리는 이유와 헬스 체크

  쿠버네티스 Service 의 기본 부하 분산은 연결을 열 때 한 번 백엔드를 고릅니다. gRPC 는 연결 하나를 오래 쓰며 그 위로 호출을 몰아 보내므로, 파드를 늘려도 기존 연결의 호출은 처음 고른 파드로만 갑니다. 해법은 셋입니다. 헤드리스 서비스와 클라이언트 측 roundrobin, 호출 단위로 나눠 주는 L7 프록시(Envoy·Cilium·메시), 그리고 프록시 없이 gRPC 라이브러

  2026-10-16 · 19 분 읽기 #gRPC#쿠버네티스#부하 분산#헤드리스 서비스#xDS

• 스트리밍, deadline, 재시도, keepalive: 호출이 길어지거나 실패할 때

  gRPC 메서드는 요청과 응답 각각이 하나인지 흐름인지에 따라 네 가지입니다. 흐름은 HTTP/2 흐름 제어 창이 막아 주고, 시간 한도는 deadline 이 남은 시간으로 다음 서버에 전달되며, 취소는 RSTSTREAM 으로 퍼집니다. 라이브러리 재시도는 서버가 응답 머리말을 보내기 전(Trailers-Only)에만, 최대 5회, 0.8~1.2배 흔들림을 섞어 합니다. grpc-go 1.8

  2026-10-16 · 20 분 읽기 #gRPC#스트리밍#deadline#재시도#keepalive

• HTTP/2 위의 gRPC: 머리말, 5바이트 접두, 트레일러의 상태 코드

  gRPC 호출 하나는 HTTP/2 스트림 하나입니다. 요청은 POST 와 :path /패키지.서비스/메서드, content-type: application/grpc, te: trailers 로 시작하고, 메시지마다 압축 표시 1바이트와 길이 4바이트가 앞에 붙습니다. 결과는 HTTP 상태(늘 200)가 아니라 응답 끝의 트레일러 grpc-status 가 정합니다. grpc-go 가 이 머리말

  2026-10-16 · 20 분 읽기 #gRPC#HTTP/2#트레일러#상태 코드#grpc-timeout

• protobuf 와이어 형식: 21바이트를 한 칸씩

  protobuf 메시지는 「태그(필드 번호와 와이어 타입) + 값」의 나열입니다. 정수는 7비트씩 끊어 쓰는 varint, 문자열과 묶음은 길이를 앞에 붙이고, 기본값은 아예 보내지 않습니다. 탁구 랠리 한 건을 표준 라이브러리만으로 손 인코딩해 보니 21바이트였고 같은 내용의 JSON 은 72바이트(들여쓰면 111바이트)였습니다. int32 로 -1 을 보내면 10바이트, sint32 로

  2026-10-16 · 12 분 읽기 #gRPC#protobuf#varint#직렬화#하위 호환

• gRPC 가 푸는 문제와 전체 그림: 계약서, 코드 생성, 채널, HTTP/2

  gRPC 는 「먼 곳의 함수를 내 함수처럼 부르기」를 네 부품으로 나눠 푼다. 계약서(.proto), 그 계약서에서 뽑아낸 언어별 코드(스텁), 연결과 부하 분산을 맡는 채널, 그리고 그 아래의 HTTP/2 입니다. 이 글은 네 부품이 각각 무엇을 책임지는지, 왜 JSON over HTTP/1.1 대신 이렇게 나눴는지, 대가는 무엇인지를 정리합니다. 작은 클러스터(노드 8대)의 지표를 읽어

  2026-10-16 · 13 분 읽기 #gRPC#protobuf#HTTP/2#RPC#쿠버네티스

• KubeVirt 소스 코드 읽기 4: virt-handler — 노드에서 VMI 를 맞추기

  virt-handler 는 노드마다 하나씩 도는 컨트롤러이고, 다른 컨트롤러와 달리 두 세계를 함께 봅니다. 클러스터의 VMI(바라는 것)와, 파드 안 libvirt 의 도메인(실제)입니다. 노드 라벨로 거른 VMI 인포머, 파드 안에서 보내오는 도메인 이벤트와 5분마다의 resync, sync() 가 고르는 세 갈래(끄기·지우기·맞추기), 파드 밖에서만 할 수 있는 준비(컨테이너 디스크 붙

  2026-10-16 · 14 분 읽기 #KubeVirt#쿠버네티스#데몬셋#gRPC#컨트롤러