CNCF 지도 읽기 — 성숙도, 전달, 서비스 메시

한 줄 요약

CNCF 랜드스케이프의 수백 개 로고는 외울 대상이 아닙니다. 어떤 문제를 푸는 자리인지로 묶어 두면
새 프로젝트가 나와도 자리를 찾아 넣을 수 있습니다. 성숙도 단계는 그 프로젝트를 지금 프로덕션에
써도 되는지에 대한 커뮤니티의 신호입니다.

왜 이게 필요했나

쿠버네티스는 의도적으로 미완성입니다. 네트워킹은 CNI 로, 런타임은 CRI 로, 스토리지는 CSI 로
빼놨습니다. 본체가 모든 걸 다 하면 유지보수가 불가능하고, 특정 구현에 종속되기 때문입니다.

대가는 선택의 부담입니다. "CNI 를 뭘 쓸까"부터 "정책 엔진은 뭘 쓸까"까지 결정할 게 많습니다.
CNCF 는 이 생태계에 중립적 관리와 성숙도 신호를 제공하는 재단입니다.

어떻게 동작하나

프로젝트 성숙도 3단계

| 단계 | 의미 | 예시 |
| --- | --- | --- |
| Sandbox | 실험적. 초기 채택자용. API 가 깨질 수 있다 | 신규 프로젝트들 |
| Incubating | 프로덕션 사용 사례가 여럿 있고 커밋터가 다양해짐 | (시기마다 다름) |
| Graduated | 성숙. 보안 감사·거버넌스·다양한 기여자 확보 | Kubernetes, Prometheus, Envoy, containerd, etcd, Argo, OPA |

단계는 기능의 우열이 아니라 거버넌스와 채택의 성숙도를 뜻합니다. Sandbox 라고 성능이 나쁘다는
뜻이 아니고, Graduated 라고 우리 상황에 맞다는 뜻도 아닙니다. 다만 "이걸 쓰다가 프로젝트가
사라지지 않을까"에 대한 위험도 신호로는 쓸 만합니다.

확장 인터페이스 — 쿠버네티스가 남을 부르는 방법

• CRI — 컨테이너 런타임 (containerd, CRI-O)
• CNI — 네트워크 (Cilium, Calico, Flannel)
• CSI — 스토리지 (각종 드라이버)
• CRD + 컨트롤러 — 사용자가 API 자체를 늘리는 방법

마지막 것이 특히 중요합니다. 오퍼레이터 패턴은 "CRD 로 새 리소스 종류를 정의하고,
그 리소스를 지켜보는 컨트롤러를 붙여 도메인 지식을 코드로 만든 것"입니다. 쿠버네티스의
reconciliation loop 를 내 문제에 재사용하는 방식이죠.

전달 — CI 와 CD, 그리고 GitOps

CI 는 "커밋할 때마다 빌드하고 테스트한다", CD 는 "그 결과물을 자동으로 배포한다" 입니다.
GitOps 는 CD 를 한 번 더 뒤집습니다.

• 파이프라인이 클러스터에 밀어 넣는(push) 대신,
• 클러스터 안의 에이전트가 Git 저장소를 계속 보고 차이를 스스로 좁힙니다(pull).

Git 저장소가 곧 원하는 상태이고, 에이전트가 컨트롤러처럼 reconcile 합니다.
쿠버네티스의 선언형 모델을 조직 프로세스로 확장한 것이라고 보면 정확합니다.
얻는 것은 감사 가능성(누가 언제 무엇을 바꿨는지가 커밋 로그), 드리프트 감지
(누가 손으로 고쳐도 원래대로 되돌아옴), 롤백(커밋 되돌리기)입니다. Argo CD 와 Flux 가 대표 구현입니다.

서비스 메시

애플리케이션 코드를 안 고치고 재시도·타임아웃·mTLS·트래픽 분할·요청 단위 관측을 넣고 싶다는
요구에서 출발했습니다. 전통적 구현은 파드마다 프록시(사이드카)를 붙여 모든 트래픽을 통과시킵니다.

대가는 명확합니다 — 파드마다 프록시 하나씩이니 메모리와 지연이 늘고, 운영할 컴포넌트가 하나 더 생깁니다.
그래서 최근에는 사이드카 없이 노드 수준 프록시나 eBPF 로 같은 일을 하려는 흐름(앰비언트 모드 등)이
나왔습니다.

오픈 스탠다드

• OpenTelemetry(OTel) — 트레이스·메트릭·로그를 수집·전송하는 벤더 중립 규격과 SDK.

계측을 한 번 하면 백엔드를 갈아도 코드를 안 고칩니다.

• OpenMetrics — Prometheus 노출 형식을 표준화한 것.
• SPIFFE/SPIRE — 워크로드에 암호학적 신원(SVID)을 발급하는 규격. "IP 주소가 신원"이라는

낡은 가정을 대체합니다. 서비스 메시의 mTLS 가 기대는 기반이기도 합니다.

현장에서 만나는 모습

저자의 홈랩 플랫폼 스택이 이 지도를 그대로 실물로 보여 줍니다.
네트워크는 Cilium 1.20(eBPF, kube-proxy 없음), L4 로드밸런서는 MetalLB(풀 10.0.0.200-215),
스토리지는 csi-driver-nfs + NAS, GitOps 는 ArgoCD, 레지스트리는 Harbor, 관측은 kube-prometheus-stack,
DB 는 CloudNativePG(PostgreSQL 18, 2인스턴스 스트리밍 복제), 가상화는 KubeVirt v1.9.0 입니다.
각 자리에 하나씩 꽂혀 있다는 게 핵심입니다 — 랜드스케이프를 자리별로 읽으면 이렇게 정리됩니다.

버전 호환성이 물리는 지점도 실제로 나왔습니다. Cilium Gateway API 를 쓰려는데
Gateway API CRD v1.6.1 이 필요했습니다. v1.2 로는 tlsroutes 와 referencegrants 가
v1 이 아니어서 컨트롤러가 아예 기동을 거부했습니다. "CRD 도 API 버전이 있고, 그게 안 맞으면
컨트롤러가 안 뜬다"는 확장 모델의 현실입니다.

가장 인상적인 교훈은 KubeVirt 에서 나왔습니다. 컴포넌트 상태는 전부 AllComponentsReady 였는데
VM 이 뜨지 않았습니다. virt-launcher 파드 명세를 뜯어 보니 init 컨테이너가 실행할 바이너리를 담은
볼륨 마운트가 빠져 있었습니다. 저자의 표현을 그대로 옮기면 —
"상태가 Ready" 와 "실제로 동작한다"는 다른 명제이고, 그 클러스터에서만 세 번째 확인한 사실입니다.
관측 가능성이 왜 상태 필드 하나로 끝나지 않는지에 대한 가장 짧은 설명입니다.

이어서 읽을 것

이 모듈에는 실습이 없습니다. 이어지는 읽을거리에서 관측 가능성의 시그널을 정리하고,
마지막 퀴즈로 코스를 마무리합니다.