クイズ: 適合性テストと EKS Distro

어떤 배포판이 Certified Kubernetes 인증을 받았다. 이 사실이 보증하는 것으로 가장 알맞은 것은?

• 그 제품이 제출한 구성에서 해당 판의 [Conformance] 시험을 건너뛰지 않고 전부 통과했다
• 그 제품으로 세운 어떤 구성의 클러스터도 운영 수준의 고가용성과 성능을 낸다
• 그 제품의 기본 보안 설정이 CIS 벤치마크 같은 강화 기준을 만족한다
• NetworkPolicy 강제처럼 쿠버네티스의 선택 기능까지 모두 업스트림과 같게 동작한다

한 대짜리 k3s(v1.36.4+k3s1)에서 [sig-architecture] Conformance Tests should have at least two untainted nodes 가 실패했다. 올바른 해석은?

• k3s 의 인증이 취소돼야 할 결함을 찾아낸 것이다
• 시험 바이너리 판이 서버와 달라 생긴 거짓 실패다
• 적합성 시험이 전제하는 구성(스케줄 가능한 노드 두 대 이상)을 이 클러스터가 갖추지 않았을 뿐이다
• k3s 는 컨트롤 플레인에 테인트를 붙이므로 워커를 더해도 이 시험은 항상 실패한다

서버가 v1.36.4+k3s1 인데 v1.37.0 테스트 바이너리로 적합성 시험을 돌리려 한다. 문제는?

• e2e.test 는 k3s 꼬리표가 붙은 판을 인식하지 못해 시작하지 않는다
• 시험 목록이 판마다 달라, 그 판의 릴리스 브랜치에서 만든 시험이 아니면 결과를 인증 기준과 비교할 수 없다
• ginkgo 판이 달라 JUnit 파일 형식이 바뀌어 제출 봇이 읽지 못한다
• 새 판 시험은 공용 인터넷에서 이미지를 받아야 해 폐쇄망에서 모두 실패한다

CoreDNS 를 0개로 줄이고 [sig-network] DNS should provide DNS for the cluster [Conformance] 를 --ginkgo.timeout=60s 로 돌렸다. JUnit 에 남는 모습은?

• 시험이 DNS 서버 없음을 곧바로 감지해 1초 안에 failed 로 끝난다
• DNS 는 kube-proxy 가 대신 응답하므로 passed 로 끝난다
• 시험 네임스페이스를 만들지 못해 skipped 로 기록된다
• 조회 실패를 기록하며 결과를 기다리다 스위트 제한에 걸려 timedout 으로 남는다

EKS Distro 의 v1-36-eks-7 릴리스에 대한 설명으로 문서와 맞는 것은?

• 쿠버네티스 1.36 채널의 일곱 번째 릴리스이고, 담긴 kube-apiserver 는 업스트림 패치 판(v1.36.2)을 따로 표기한다
• 쿠버네티스 v1.36.7 을 뜻하며 업스트림 최신 패치 판과 항상 같다
• AWS 가 API 를 수정한 포크의 7번째 판이라 업스트림 매니페스트와 호환이 보장되지 않는다
• EKS 관리형 서비스 전용 번호라 직접 설치하는 클러스터에서는 쓸 수 없다

사내 전용 클러스터가 적합한지 확인하고 싶지만 CNCF 인증 로고는 필요 없다. 문서에 따른 방법은?

• CNCF 회원사가 아니면 적합성 시험을 돌릴 권한이 없으므로 인증된 제품으로 바꾼다
• PRODUCT.yaml 만 작성해 k8s-conformance 저장소에 PR 을 올리면 적합으로 인정된다
• 같은 적합성 시험을 직접 돌려 통과하면 적합한 것이고, 인증은 로고를 쓰기 위한 별도 절차다
• Sonobuoy 의 기본 모드로 돌려 실패가 없으면 인증 제출과 같은 효력을 갖는다