인증 로고는 무엇을 보증하나

한 줄 요약

인증 로고는 "GA 이면서 필수인 API 가 업스트림과 같게 동작한다" 는 약속이지 "운영에 믿고 써도 된다" 는 약속이 아니고, EKS Distro 같은 배포판은 그 약속 위에 빌드·패치·지원 기간이라는 다른 가치를 얹습니다.

왜 이게 필요했나

쿠버네티스는 오픈소스라 누구나 고쳐서 배포할 수 있습니다. 배포판이 수십 개로 늘어나자 사용자는 한 가지가 불안해졌습니다. "A 에서 돌던 매니페스트가 B 에서도 똑같이 돌까?" 벤더가 API 를 조금씩 바꾸거나 기본 동작을 빼 버리면, 쿠버네티스를 고른 이유인 이식성이 사라집니다.

그래서 CNCF 는 [Certified Kubernetes Conformance Program](https://github.com/cncf/k8s-conformance) 을 운영합니다. 벤더가 정해진 시험 모음을 자기 제품에서 돌려 결과를 공개 저장소에 PR 로 올리고, 리뷰를 통과하면 인증을 받습니다. 핵심은 시험이 공개돼 있고 결과도 공개된다는 점입니다. 누구든 같은 시험을 자기 클러스터에서 다시 돌려 볼 수 있습니다. FAQ 는 사내 전용 클러스터라도 인증 없이 시험을 돌려 통과하면 적합한 것이고, 인증은 로고를 쓰기 위한 절차라고 설명합니다.

어떻게 동작하나

무엇이 시험인가. [instructions.md](https://github.com/cncf/k8s-conformance/blob/master/instructions.md) 에 따르면 표준 시험은 쿠버네티스 e2e 모음에서 [Conformance] 태그가 붙은 것들입니다. 목록은 쿠버네티스 저장소의 test/conformance/testdata/conformance.yaml 로 판마다 고정됩니다. v1.36.4 태그의 목록을 세면 446개이고, sig-node 106 · sig-api-machinery 99 · sig-storage 91 · sig-apps 60 · sig-network 47 순입니다(실측). 각 항목에는 testname·codename·설명·처음 들어간 release·소스 파일이 있습니다.

무엇이 시험이 될 수 있나. SIG Architecture 의 [Conformance Testing in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) 가 기준을 정합니다. GA 이고 선택이 아닌 기능만, 모든 공급자에서 동작해야 하고, kubelet API 에 직접 기대면 안 되며, 노드의 root 권한이나 공용 인터넷을 요구하면 안 됩니다. 반대로 GPU 같은 노드 의존 기능, 정책 강제 같은 선택 기능, 클라우드 공급자 전용 기능은 명시적으로 대상이 아닙니다. Event 내용이나 Condition 의 reason·message 처럼 판마다 바뀔 수 있는 출력을 확인하는 시험도 넣지 않습니다.

어떻게 돌리나. 제출용 결과는 Sonobuoy 나 Hydrophone 으로 만듭니다. Sonobuoy 라면 --mode=certified-conformance 가 필요하고, focus 를 직접 준다면 E2E_FOCUS=\[Conformance\] 에 E2E_SKIP 은 비워야 합니다. 인증 실행은 시험을 하나도 건너뛸 수 없습니다. PR 에는 README.md·e2e.log·junit_01.xml·PRODUCT.yaml 네 파일이 들어가고, 봇이 필요한 시험이 전부 있는지와 실패가 없는지를 먼저 검사합니다. 인증할 수 있는 판은 현재 릴리스와 그 앞 두 판이고, 이미 인증된 제품도 1년에 한 번은 새 판으로 다시 인증해야 유지됩니다.

판을 맞춰야 하는 이유. 시험 목록은 판마다 늘어납니다. 문서는 어떤 판의 적합성 시험은 그 판의 릴리스 브랜치에서 만든 것으로 돌리라고 합니다. 이 실습 VM 은 서버 v1.36.4+k3s1 에 dl.k8s.io 의 v1.36.4 테스트 바이너리를 씁니다. dry-run 으로 세면 [Conformance] focus 가 7579개 spec 중 446개를 고르고, 목록 수와 정확히 같습니다(실측).

현장에서 만나는 모습

로고가 있는 k3s 가 한 대로는 떨어집니다. 저장소의 v1.36/k3s 제출 README 는 제어 평면 한 대와 워커 한 대로 시험했다고 적고 있고, 결과는 446 통과 · 7133 건너뜀 · 약 2시간 54분이었습니다. 그런데 이 실습의 한 대짜리 k3s 에서 [sig-architecture] Conformance Tests should have at least two untainted nodes 를 돌리면 1.3초 만에 Conformance requires at least two nodes 로 실패합니다(실측). 인증은 제품 에 대한 것이고, 여러분이 세운 구성 이 적합하다는 뜻은 아닙니다.

같은 시험이 망가진 클러스터를 잡아냅니다. [sig-network] DNS should provide DNS for the cluster 는 정상 클러스터에서 3.8초에 통과했습니다. CoreDNS 를 0개로 줄이고 다시 돌리면 시험 파드가 kubernetes.default.svc.cluster.local 조회 실패를 5초마다 기록하며 600초를 기다립니다. 스위트 시간 제한을 60초로 두자 결과가 timedout 으로 남았습니다(실측). 적합성 시험은 인증용이기도 하지만, 업그레이드나 CNI 교체 뒤 "기본 동작이 살아 있는가" 를 확인하는 회귀 시험으로도 쓸 수 있습니다.

EKS Distro 는 무엇을 더하나. [EKS Distro 문서](https://distro.eks.amazonaws.com/) 는 EKS-D 를 Amazon EKS 가 쓰는 것과 같은 쿠버네티스와 의존성의 배포판이라고 설명합니다. 쿠버네티스·etcd·CoreDNS·CNI 플러그인·aws-iam-authenticator 를 묶고, 컨테이너 이미지는 Amazon Linux 2 기반으로 ECR Public 에 올립니다. FAQ 는 포크가 아니라 수정하지 않은 업스트림을 의견을 담아 묶은 것이고, 커뮤니티 지원이 끝난 판에도 최대 14개월까지 보안 패치를 한다고 말합니다. 판 표기는 v1-36-eks-7 처럼 마이너 채널 뒤에 릴리스 번호가 붙고, 이미지 태그는 kube-apiserver:v1.36.2-eks-1-36-7 처럼 업스트림 판 뒤에 채널과 번호가 붙습니다. 새 릴리스는 구성요소 판이 바뀌거나 베이스 이미지·빌드 도구(예: Go)가 바뀔 때도 나옵니다. 2026-08-18 의 v1-36-eks-7 은 kube-apiserver v1.36.2 인데, 같은 시점 업스트림 stable-1.36 은 v1.36.4 였습니다(실측). 배포판의 판은 업스트림 최신과 같지 않을 수 있습니다. EKS-D 도 k8s-conformance 저장소의 v1.36 에 type distribution 으로 제출돼 있습니다.

실무에서 진짜 중요한 것

로고는 이식성의 바닥이지 품질의 천장이 아닙니다. 인증은 GA API 가 같게 동작한다는 것만 말합니다. 고가용성 구성, 성능, 보안 기본값, NetworkPolicy 를 실제로 막는지 같은 선택 기능, 업그레이드 절차, 지원 기간은 전부 따로 확인해야 합니다.

인증 결과는 내 클러스터의 결과가 아닙니다. 제출 README 에 적힌 구성(노드 수, OS, 설치 플래그)과 내 구성이 다르면, 같은 제품이라도 떨어지는 시험이 생길 수 있습니다. 중요한 변경 뒤에는 관련 영역의 적합성 시험을 골라 직접 돌려 보는 편이 로고를 믿는 것보다 확실합니다.

판을 박습니다. 서버와 시험 바이너리의 판이 어긋나면 목록이 달라 결과를 비교할 수 없습니다. EKS-D 처럼 업스트림 패치 판과 배포판 릴리스 번호가 따로 움직이는 제품이면 두 번호를 함께 기록해야 나중에 재현할 수 있습니다.

EKS-D 자체는 이 실습 VM 에 설치하지 않았습니다. 설치 경로(kOps·kubeadm 등)와 지원 경로(EKS Anywhere)는 문서로만 확인했습니다.

다음 실습에서 할 것

판을 고정한 k3s 에서 시험 바이너리의 판을 맞추고, conformance.yaml 을 읽어 DNS 영역의 시험을 찾습니다. dry-run 으로 범위를 센 뒤 DNS 시험 하나를 통과시키고, 한 대짜리 구성이 두 노드 시험에서 떨어지는 것을 JUnit 으로 확인합니다. CoreDNS 를 줄여 같은 DNS 시험이 시간 초과로 떨어지는 것을 본 뒤 되돌려 다시 통과시키고, 결과를 인증 규칙의 말로 정리합니다.