認定ロゴは何を保証するのか

一言でいうと

認定ロゴは「GAで必須のAPIがアップストリームと同じように動作する」という約束であって、「本番で安心して使える」という約束ではありません。EKS Distroのようなディストリビューションは、その約束の上に、ビルド・パッチ・サポート期間という別の価値を載せています。

なぜ必要なのか

Kubernetesはオープンソースなので、誰でも修正して配布できます。ディストリビューションが数十個に増えると、ユーザーは1つのことが不安になりました。「Aで動いていたマニフェストが、Bでもまったく同じように動くのか」。ベンダーがAPIを少しずつ変えたり、デフォルトの動作を外してしまったりすると、Kubernetesを選んだ理由である移植性が失われます。

そこでCNCFは、Certified Kubernetes Conformance Programを運営しています。ベンダーが決められたテストスイートを自社の製品で実行し、結果を公開リポジトリにPRで提出して、レビューを通過すると認定を受けます。核心は、テストが公開されていて、結果も公開されることです。誰でも同じテストを自分のクラスターで再実行できます。FAQは、社内専用のクラスターでも、認定を受けなくてもテストを実行して通過すれば適合しており、認定はロゴを使うための手続きだと説明しています。

どう動くのか

何がテストなのか。instructions.mdによると、標準のテストは、Kubernetesのe2eスイートのうち[Conformance]タグが付いたものです。一覧はKubernetesリポジトリの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が基準を決めています。GAであり、かつオプションではない機能だけが対象で、すべてのプロバイダーで動作する必要があり、kubelet APIに直接頼ってはならず、ノードのroot権限や公開インターネットを要求してはいけません。逆に、GPUのようなノード依存の機能、ポリシーの強制のようなオプション機能、クラウドプロバイダー専用の機能は、明示的に対象外です。Eventの内容やConditionのreasonとmessageのように、バージョンによって変わりうる出力を確認するテストも入れません。

どう実行するのか。提出用の結果は、SonobuoyまたはHydrophoneで作ります。Sonobuoyなら--mode=certified-conformanceが必要で、focusを直接指定するなら、E2E_FOCUS=\[Conformance\]にしてE2E_SKIPは空にする必要があります。認定のための実行では、テストを1つもスキップできません。PRにはREADME.md・e2e.log・junit_01.xml・PRODUCT.yamlの4つのファイルが入り、ボットが、必要なテストがすべてあるか、失敗がないかを先に検査します。認定できるバージョンは現在のリリースとその前の2つで、すでに認定された製品も、1年に1回は新しいバージョンで再認定しないと維持されません。

バージョンを合わせる必要がある理由。テストの一覧はバージョンごとに増えます。ドキュメントは、あるバージョンの適合性テストは、そのバージョンのリリースブランチから作ったもので実行するよう求めています。このラボのVMは、サーバーv1.36.4+k3s1に、dl.k8s.ioのv1.36.4のテストバイナリを使います。dry-runで数えると、[Conformance]のfocusが7579個のspecから446個を選び、一覧の数とちょうど同じです(実測)。

現場での姿

ロゴがあるk3sでも、1台構成では不合格になります。リポジトリのv1.36/k3sの提出READMEは、コントロールプレーン1台とワーカー1台でテストしたと書いていて、結果は446個合格・7133個スキップ・約2時間54分でした。ところが、このラボの1台構成の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個に減らして再実行すると、テスト用Podがkubernetes.default.svc.cluster.localの参照失敗を5秒ごとに記録しながら600秒待ちます。スイートの時間制限を60秒にすると、結果がtimedoutとして残りました(実測)。適合性テストは認定用でもありますが、アップグレードやCNIの交換の後に「基本動作が生きているか」を確認する回帰テストとしても使えます。

EKS Distroは何を加えるのか。EKS Distroのドキュメントは、EKS-DをAmazon EKSが使っているものと同じKubernetesと依存関係のディストリビューションだと説明しています。Kubernetes・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テストを1つ通過させ、1台構成が2ノードのテストで不合格になることをJUnitで確認します。CoreDNSを減らして同じDNSテストがタイムアウトで不合格になることを見た後、元に戻して再び通過させ、結果を認定ルールの言葉でまとめます。