💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「Kubernetesはもはや『プラットフォーム』ではなく、『プラットフォームを作るためのカーネル』だ。2026年の本当の競争は、その上にArgo CD・Flux・Crossplaneが描くコントロールプレーンの形にある。」 — KubeCon NA 2025 キーノート

Kubernetesが1.0に到達した2015年7月から11年が経ちました。2026年5月時点の安定版最新は1.33(Octarine)で、1.30〜1.33は4ヶ月サイクルでリリースされ、1.34がまもなくRCに入ります。その間に、「どうやってクラスタを作るか」よりも「**その上でどうやってGitOpsでワークロードを回し、自動でスケールし、自動でノードを増やし、マルチクラスタを束ね、CRDで自己拡張するか**」が中心テーマになりました。

2026年のKubernetesエコシステムは6つのレイヤーに整理できます。(1)**マニフェストツール** — Helm・Kustomize・Carvel・Jsonnet・cdk8s。(2)**GitOpsコントローラ** — Argo CDとFlux v2。(3)**オートスケール** — KEDA・Karpenter・Cluster Autoscaler。(4)**クラスタライフサイクル** — Cluster API・kOps・Talos Linux・k3s/k0s/microk8s/kind/k3d・vCluster・KubeVirt。(5)**拡張モデル** — Operator Framework・Kubebuilder・Operator SDK・KCC・Crossplane。(6)**運用UX** — k9s・Lens・Headlamp・Komodor・Pixie。

本記事ではこの6レイヤーを一気に概観し、日本・韓国企業の実適用事例も併せて整理します。

1. 2026年のKubernetes地図 — 6レイヤーと4つの潮流

Kubernetesエコシステムは6レイヤーと、その上を横切る4つの大きな潮流として理解できます。

| レイヤー | 代表ツール | 中心的な役割 |

|---|---|---|

| マニフェスト | Helm・Kustomize・Carvel ytt・Jsonnet・cdk8s | YAML生成と再利用 |

| GitOps | Argo CD・Flux v2 | Gitからクラスタへ同期 |

| オートスケール | KEDA・Karpenter・CAS | ワークロード/ノードのスケーリング |

| ライフサイクル | Cluster API・kOps・Talos | クラスタ自体のIaC |

| 拡張(CRD) | Operator Framework・Kubebuilder・KCC・Crossplane | コントローラパターン |

| 運用UX | k9s・Lens・Headlamp・Pixie | 人間のためのインターフェース |

このレイヤーを横切る4つの潮流は明確です。第一に、**宣言型の完全勝利** — kubectl applyの時代は終わり、Git + Argo/Fluxが標準。第二に、**ノードスケジューリングの単純化** — AWSではKarpenterが事実上の標準となり、NodePool一枚でASG/MIG/MSSを置き換える。第三に、**OSのK8s専用化** — Talos Linux・Bottlerocket・FlatcarのようなK8s専用OSが急速にシェアを伸ばす。第四に、**CRD万能主義の後退** — 小さなコントローラは良いが、すべてをCRDにすべきではないという反省が広がり、Crossplane v2もより軽量に再設計されました。

2. Kubernetes 1.30から1.33まで — 何が変わったのか

2024年4月の1.30(Uwubernetes)から2026年初頭の1.33(Octarine)までを一行でまとめると、「**サイドカーがGAになり、ImageVolumeがGAになり、Dynamic Resource AllocationがGAに向かって突き進み、in-place pod resizeがbetaに入った時期**」です。

詳細を整理するとこうです。1.29〜1.30で**サイドカーコンテナ**がbetaに入り、initコンテナに`restartPolicy: Always`を付ける書き方が標準化、Istio ambient meshやOpenTelemetryサイドカーが即座に採用しました。1.31で**AppArmor**と**PersistentVolume Last Phase Transition Time**がGAになり、kube-proxyのnftablesモードがbetaに入りました。1.32で**In-Place Pod Vertical Scaling**がbeta、**Dynamic Resource Allocation(DRA)** がv1beta1へ。1.33では**ImageVolume**(コンテナイメージをボリュームとしてマウント)がbeta、**Sidecar Containers**がGAに昇格しました。

3. Helm 3.18 — チャート、OCIレジストリ、Helmfile

Helmは2026年でもマニフェストパッケージングの事実上の標準です。3.18+でOCIレジストリのpush/pullが完全に安定し、`helm push oci://registry.example.com/charts/myapp --version 1.2.3`一行でECR/GHCR/Harborにチャートを公開できます。Helm 4は2025年末にalphaが出ましたが、2026年5月時点で本番は依然として3.xです。

Chart.yaml — チャートのメタデータ

apiVersion: v2

description: A Helm chart for myapp

type: application

version: 1.2.3

appVersion: "2.5.0"

dependencies:

- name: postgresql

version: "15.3.1"

repository: oci://registry-1.docker.io/bitnamicharts

- name: redis

version: "20.0.0"

repository: oci://registry-1.docker.io/bitnamicharts

condition: redis.enabled

valuesとテンプレートは次のように分離します。

values.yaml — 環境ごとのデフォルト

replicaCount: 2

image:

repository: ghcr.io/myorg/myapp

tag: "" # appVersionへフォールバック

pullPolicy: IfNotPresent

resources:

requests:

cpu: 100m

memory: 128Mi

limits:

cpu: 500m

memory: 512Mi

autoscaling:

enabled: true

minReplicas: 2

maxReplicas: 20

targetCPUUtilizationPercentage: 70

redis:

enabled: true

auth:

enabled: false

運用のコツ。(1)`values-prod.yaml`・`values-stg.yaml`のように環境別valuesを置き、Argo CD ApplicationSetで合成。(2)**helm-secrets** + SOPS + KMSで機密値を暗号化。(3)**sealed-secrets**(Bitnami)はクラスタ単位の鍵でGitOpsフレンドリー、**External Secrets Operator**はVault/AWS Secrets Manager/GCP Secret Managerなど外部SoT連携に強い。2026年のベストプラクティスは「**機密値はESOで外部SoT、非機密の環境別値はhelm-secretsでGit**」の組み合わせです。

4. Kustomize — オーバーレイ・コンポーネント・replacements

Kustomizeはkubectlに同梱されているので導入摩擦がゼロで、「ベース+オーバーレイ」モデルが直感的です。2026年の推奨構造はbase/、overlays/dev|stg|prod/、components/(共通変形)の3層構成です。

base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- deployment.yaml

- service.yaml

- configmap.yaml

commonLabels:

app.kubernetes.io/name: myapp

images:

- name: myapp

newName: ghcr.io/myorg/myapp

newTag: 2.5.0

overlays/prod/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

namespace: prod

resources:

- ../../base

components:

- ../../components/hpa

- ../../components/podsecurity-restricted

replicas:

- name: myapp

patches:

- target:

kind: Deployment

patch: |-

- op: replace

path: /spec/template/spec/containers/0/resources/limits/memory

value: 2Gi

Helm vs Kustomize論争は2026年にはほぼ収束しました。結論は「**Helmは外部OSSチャートを取り込んで再配布するのに強く、Kustomizeは内部の自前マニフェストを環境ごとに分岐するのに強い**」で、Argo CD・Fluxとも「KustomizeがHelmチャートを包む」ハイブリッドを一級市民として扱います。

5. Carvel・Jsonnet・cdk8s — Helmの先

第三のマニフェストツール群は「**プログラマブルYAML**」陣営です。**Carvel**(VMware/Broadcom)はytt(YAMLテンプレート)・kapp(applier)・kbld(イメージピン留め)・vendir(依存性ロック)の4点セットを提供します。Helmのような文字列置換ではなくYAML構造を直接変形するため、インデントエラーが消えます。

**Jsonnet + Tanka**はGrafana Labsが自社インフラを運用する流儀で、Jsonnet言語でコードのようにマニフェストを書きます。Loki・Mimir・TempoはすべてTankaでデプロイされます。学習コストは高いですが、大規模で同質的な環境では強力です。

**cdk8s**(AWS、CNCF Sandbox)はTypeScript/Python/Go/JavaでK8sマニフェストを生成します。標準ライブラリcdk8s+がDeployment・Service・Ingressなどの高レベルコンポーネントを提供し、「型安全なYAML」を求めるチームに適します。ただ2026年時点での採用率はHelm/Kustomize比で一桁%台にとどまります。

6. Argo CD vs Flux v2 — GitOpsの二大陣営

CNCF GraduatedプロジェクトであるArgo CD(Intuit、現Akuity)とFlux v2(旧Weaveworks、現ControlPlane)は、GitOpsの事実上の二大標準です。2026年時点のシェアは概ねArgo CDが70%、Flux v2が25%、自前コントローラが5%と推定されます。

Argo CD Application — 最もシンプルな形

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/myorg/manifests

targetRevision: main

path: overlays/prod

destination:

server: https://kubernetes.default.svc

namespace: prod

syncPolicy:

automated:

prune: true

selfHeal: true

syncOptions:

- CreateNamespace=true

- ServerSideApply=true

retry:

limit: 5

backoff:

duration: 5s

factor: 2

maxDuration: 3m

ApplicationSet — 複数クラスタ/環境を一括

apiVersion: argoproj.io/v1alpha1

kind: ApplicationSet

metadata:

namespace: argocd

spec:

generators:

- matrix:

generators:

- list:

elements:

- cluster: prod-asia

region: ap-northeast-2

- cluster: prod-us

region: us-east-1

- list:

elements:

- env: prod

template:

metadata:

spec:

project: default

source:

repoURL: https://github.com/myorg/manifests

targetRevision: main

path: 'overlays/{{env}}'

destination:

server: 'https://{{cluster}}.example.com'

namespace: myapp

Flux v2の強みは4つのコントローラ(Source/Kustomize/Helm/Notification)に分かれたマイクロカーネル構造、Argo CDの強みはUI・マルチテナンシー・RBAC・ApplicationSetです。一般的な指針は「**小規模でHelmチャートをそのまま使うならFlux、大規模マルチテナントでUIが欲しいならArgo CD**」です。

Argoのコンパニオンプロジェクト — **Argo Rollouts**(Canary/Blue-Green)、**Argo Workflows**(K8sネイティブのワークフローエンジン)、**Argo Events**(イベントソース→トリガ) — も併用されることが多いです。Argo RolloutsのAnalysisTemplateはPrometheusメトリクスに基づきcanaryトラフィックを自動で増やすかロールバックします。

7. KEDA — イベント駆動オートスケール

KEDA(Kubernetes Event-Driven Autoscaling、CNCF Graduated)はHPAでは扱えない外部イベント(Kafka lag・RabbitMQ queue depth・AWS SQS・Pub/Sub・Cronなど)を基準にPodを0〜Nへスケールします。2026年5月時点で70以上のスケーラをサポートします。

KEDA ScaledObject — Kafka lagでスケール

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

namespace: orders

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

minReplicaCount: 0

maxReplicaCount: 100

cooldownPeriod: 60

pollingInterval: 15

triggers:

- type: kafka

metadata:

bootstrapServers: kafka.kafka.svc:9092

consumerGroup: order-consumer

topic: orders

lagThreshold: "1000"

offsetResetPolicy: latest

- type: prometheus

metadata:

serverAddress: http://prometheus.monitoring.svc:9090

threshold: "100"

query: sum(rate(http_requests_total{service="order-api"}[1m]))

KEDAの目玉機能は**0までのスケールイン**です。夜間バッチや滅多に発火しないイベントワーカーは平時0レプリカで置けるので、コスト削減効果が大きい。一方でcold startは存在するため、SLAの厳しいAPIではminReplicaCountを2以上にするのが定石です。

8. Karpenter — AWSの標準になったノードオートスケーラ

Karpenterは2025年11月にCNCF Incubatingを経て、2026年初頭にGraduatedへ昇格し、AWSではCluster Autoscalerに代わる事実上の標準になりました。主な違いは(1)ASG/MIGに縛られず、**Podの実際の要件を見てEC2インスタンスタイプをその都度選ぶ**、(2)**約30秒**で反応する、(3)Spot/On-Demand/Graviton/x86を単一NodePoolで混在運用、(4)Bottlerocket/Amazon Linux 2023/Ubuntu AMIの自動パッチ、です。

Karpenter NodePool — Spot優先、Graviton優先

apiVersion: karpenter.sh/v1

kind: NodePool

metadata:

spec:

template:

metadata:

labels:

team: platform

spec:

requirements:

- key: karpenter.k8s.aws/instance-category

operator: In

values: ["c", "m", "r"]

- key: karpenter.k8s.aws/instance-generation

operator: Gt

values: ["5"]

- key: kubernetes.io/arch

operator: In

values: ["arm64", "amd64"]

- key: karpenter.sh/capacity-type

operator: In

values: ["spot", "on-demand"]

nodeClassRef:

group: karpenter.k8s.aws

kind: EC2NodeClass

expireAfter: 720h # 30日ごとに強制再生成してパッチを当てる

limits:

cpu: "10000"

memory: 10000Gi

disruption:

consolidationPolicy: WhenEmptyOrUnderutilized

consolidateAfter: 30s

budgets:

- nodes: "10%"

GCP向けKarpenter Providerは2025年にbeta、Azure向けAKS Karpenterは2025年にGAになりましたが、2026年5月時点でAWS以外ではCluster Autoscalerが依然優勢です。

9. Cluster API — クラスタ自体をK8sオブジェクトに

Cluster API(CAPI、SIG-Cluster-Lifecycle)は「クラスタを作るクラスタ(management cluster)」というメタモデルを導入します。Cluster・MachineDeployment・ClusterClassなどのCRDでワークロードクラスタの形を宣言し、インフラプロバイダ(CAPA=AWS、CAPG=GCP、CAPZ=Azure、CAPV=vSphere、k0s-bootstrapなど)が実機を作ります。

CAPIは2026年5月時点で1.10+であり、**ClusterClass**(クラスタテンプレート)が安定したことで、同じ形のクラスタを10〜100個宣言的に量産するパターンが一般化しました。AWS EKS AnywhereはCAPIをコアに置き、VMware Tanzu Kubernetes Grid・Rancher RKE2 Provisioner・Giant Swarm・MirantisがいずれもCAPI上に自社製品を載せる形で収斂しています。

ClusterClass — クラスタテンプレート1枚

apiVersion: cluster.x-k8s.io/v1beta1

kind: ClusterClass

metadata:

spec:

controlPlane:

ref:

apiVersion: controlplane.cluster.x-k8s.io/v1beta2

kind: AWSManagedControlPlaneTemplate

infrastructure:

ref:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2

kind: AWSManagedClusterTemplate

workers:

machineDeployments:

- class: default-worker

template:

bootstrap:

ref:

apiVersion: bootstrap.cluster.x-k8s.io/v1beta1

kind: EKSConfigTemplate

infrastructure:

ref:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2

kind: AWSMachineTemplate

CAPIの学習曲線は急ですが、50以上のクラスタを運用する組織には「**クラスタ自体のGitOps**」を実現できる点でほぼ必須のツールになりました。

10. クラスタディストロ — vanilla・Talos・k3s・k0s・microk8s

Kubernetesディストロは大きく5種類に分類されます。(1)**vanilla(kubeadm)** — 最も標準的、EKS/GKE/AKSのコア。(2)**Talos Linux**(Sidero Labs) — SSHもパッケージマネージャもない、すべてがAPIのK8s専用OS。2026年に最も急速にシェアを伸ばしているディストロ。(3)**k3s**(SUSE/Rancher) — 単一バイナリ約60MB、エッジ/IoT/ホームラボの標準。(4)**k0s**(Mirantis) — k3sに似るがhostPath依存なし、controlplane HAがより単純。(5)**microk8s**(Canonical) — Ubuntuフレンドリー、snapベース。

|---|---|---|---|

| k3s | 約60MB | sqlite/etcd | エッジ/ホームラボ |

| k0s | 約70MB | etcd内蔵 | 組み込み/エッジ |

| minikube | VM | etcd内蔵 | 学習 |

Talosは2026年に入り、LINEやMercariなど日本のビッグテックでの採用が始まり、韓国でもTossやNAVERが一部ワークロードで実験中です。

11. vCluster・KubeVirt — クラスタの中のクラスタ、K8sの中のVM

**vCluster**(Loft Labs)はホストクラスタ内に軽量な仮想コントロールプレーンを立ち上げ、テナントごとに「ニセクラスタ」を提供します。ユーザーは自分のvCluster内でcluster-adminですが、隔離はホストクラスタ上の専用ネームスペースで担保されます。「ネームスペース隔離」ではなく「ニセクラスタ隔離」でマルチテナントK8sを解く手法として2025年以降急速に成長中です。

**KubeVirt**は逆方向に、K8sの中でVMを動かすプロジェクトです。Red Hat OpenShift Virtualizationのコアであり、VMとコンテナを同一コントロールプレーンの下に置きます。レガシーWindows/RHEL VMとクラウドネイティブワークロードを共存させなければならない金融・公共・通信領域で多く採用されます。

12. Operator Framework・Kubebuilder・Operator SDK

CRD + コントローラパターンはKubernetes最強の拡張機構です。2026年の事実上の標準は、**controller-runtime**(sigs.k8s.io)の上に**Kubebuilder**(scaffold)または**Operator SDK**(Red Hat)でプロジェクトを起こすことです。コントローラパターンの4大原則は次の通り。

1. **レベルトリガ(level-triggered)** — イベントではなく、desired stateとactual stateの差分で動く。イベントを取りこぼしても次のreconcileで回復。

2. **OwnerReferences** — 親リソースが削除されると子が自動GC。

3. **Finalizers** — 外部リソースの整理が完了するまで削除をブロック。

4. **冪等なReconcile** — 同じ入力に同じ出力。中間状態を保存しない。

// controller-runtime ベースのReconcile骨格

func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {

log := log.FromContext(ctx)

var app v1alpha1.MyApp

if err := r.Get(ctx, req.NamespacedName, &app); err != nil {

if apierrors.IsNotFound(err) {

return ctrl.Result{}, nil

}

return ctrl.Result{}, err

}

// Finalizer登録

if app.DeletionTimestamp.IsZero() {

if !controllerutil.ContainsFinalizer(&app, "myapp.example.com/finalizer") {

controllerutil.AddFinalizer(&app, "myapp.example.com/finalizer")

return ctrl.Result{}, r.Update(ctx, &app)

}

} else {

if err := r.cleanupExternal(ctx, &app); err != nil {

return ctrl.Result{RequeueAfter: 30 * time.Second}, err

}

controllerutil.RemoveFinalizer(&app, "myapp.example.com/finalizer")

return ctrl.Result{}, r.Update(ctx, &app)

}

// 望ましいDeploymentを作りSSAで適用

desired := r.buildDeployment(&app)

if err := controllerutil.SetControllerReference(&app, desired, r.Scheme); err != nil {

return ctrl.Result{}, err

}

if err := r.Patch(ctx, desired, client.Apply, client.FieldOwner("myapp-controller"), client.ForceOwnership); err != nil {

return ctrl.Result{}, err

}

// ステータス更新

app.Status.Ready = true

if err := r.Status().Update(ctx, &app); err != nil {

return ctrl.Result{}, err

}

log.Info("reconciled", "name", app.Name)

return ctrl.Result{RequeueAfter: 5 * time.Minute}, nil

}

運用のコツ。(1)**SSA(Server-Side Apply)** をデフォルトに。fieldManagerが衝突を自動解決します。(2)`RequeueAfter`を積極的に活用してwatchだけに頼らない。(3)`Status.Conditions`は標準パターン(Ready/Progressing/Degraded)で統一。

13. KCC・Crossplane — クラウドをK8sオブジェクトに

K8sコントロールプレーンを「**クラウドリソースのインターフェース**」として使う流れは二陣営に分かれました。**KCC(Config Connector、GCP)** はGCPリソースをK8s CRDとして公開し、**Crossplane**(CNCF Incubating)はマルチクラウド(AWS/GCP/Azure/外部SaaS)を単一抽象で束ねます。Crossplane v2(2025年末発表)はCompositionを軽量化し、関数ベースパターンを一級市民にしました。

選択指針はシンプルです。**GCP単一**ならKCC、**マルチクラウドまたは外部SaaSも含む**ならCrossplane、**AWS単一**ならAWS Controllers for Kubernetes(ACK)が一般的です。ただし2026年時点でCrossplaneは依然として学習曲線が急で、Terraform/OpenTofuとの境界を明確に設計しないと運用負荷が大きくなります。

14. K8sセキュリティ — PSS・OPA Gatekeeper・Kyverno・Falco・KubeArmor

PodSecurityPolicy(PSP)は1.25で削除され、その後を**Pod Security Standards(PSS)** が引き継ぎました。PSSは3つのプロファイル(privileged/baseline/restricted)をネームスペースのラベルで適用します。ただPSSは表現力が低いので、ほとんどの組織はその上に専用のポリシーエンジンを重ねます。

| ツール | 言語 | 強み | 弱み |

|---|---|---|---|

2026年の傾向は「**強制はKyverno、ランタイム検知はFalco**」の組み合わせが最も多い。OPA Gatekeeperは依然強力ですが、KyvernoのYAMLフレンドリーさが急速にシェアを伸ばしています。

Kyverno ClusterPolicy — latestタグ禁止、リソース上限を必須化

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

spec:

validationFailureAction: Enforce

background: true

rules:

- name: validate-image-tag

match:

any:

- resources:

kinds:

- Pod

validate:

message: "イメージタグはlatestや未指定を禁止"

pattern:

spec:

containers:

- image: "!*:latest"

- name: require-resources

match:

any:

- resources:

kinds:

- Pod

validate:

message: "すべてのコンテナにresources.limitsが必要"

pattern:

spec:

containers:

- resources:

limits:

memory: "?*"

cpu: "?*"

15. K8sネットワーキング — NetworkPolicy・Gateway API・Cilium

NetworkPolicyは1.7から存在しますが表現力が貧弱で、2026年の標準は**Gateway API(GA)** と**CiliumNetworkPolicy**の組み合わせです。Gateway APIはIngressの後継でL4/L7双方を扱い、GatewayClass/Gateway/HTTPRoute/GRPCRoute/TCPRouteに分かれます。2024年のGA以後、ほとんどのクラウドLBコントローラがGateway APIモードに対応しました。

CiliumはCNI市場の事実上の標準になり、eBPFベースでkube-proxyを置き換えられ、Cilium Service Mesh(サイドカーレスL7)・Hubble(可観測性)・Tetragon(セキュリティ)までを一つのスタックに束ねます。2026年時点でCiliumはEKS/GKE/AKSすべてで一級市民で、シェアは約40%で首位です。

16. K8sストレージ — CSI・OpenEBS・Longhorn・Rook

ストレージインターフェースは**CSI(Container Storage Interface)** に統一されました。2026年の選択肢は(1)クラウドネイティブ(EBS/EFS/PD/Azure Disk/Files CSIドライバ)、(2)**OpenEBS**(Mayastor) — eBPF/NVMe-oFベースのローカルストレージ、(3)**Longhorn**(SUSE/Rancher) — 分散ブロックストレージ、(4)**Rook**(Ceph) — 大容量ブロック/オブジェクト/ファイル、(5)**Portworx**(Pure Storage) — エンタープライズ商用、です。

選択基準は単純です。**クラウドならそのクラウドのCSI**がデフォルト、**ベアメタル/オンプレ + 小規模**ならLonghorn、**ベアメタル/オンプレ + 大容量**ならRookが一般的です。

17. マルチクラスタ — Karmada・Liqo・Submariner・Skupper

組織が成長すると単一クラスタでは足りなくなります。2026年のマルチクラスタ4大選択肢は次の通り。

**Karmada**(Huawei → CNCF Incubating)は「ポリシーベースのマルチクラスタスケジューラ」で、PropagationPolicy/OverridePolicyでワークロードを複数クラスタに分散配置します。中国ビッグテックや韓国の一部企業が活発に使っています。

**Liqo**(伊Polito → CNCF Sandbox)は逆に「**Virtual Kubeletで他クラスタを単一ノードのように見せる**」アプローチで、動的ペアリングが強みです。

**Submariner**(Red Hat)と**Skupper**(Red Hat)はクラスタ間ネットワーク接続に特化、Submarinerは直接Pod CIDRを束ね、SkupperはL7プロキシベースです。

**Admiralty**はマルチクラスタスケジューリング特化のもう一つの選択肢。2024年にKubeFedがarchivedになり、その空白をKarmada/Liqoが埋めています。

18. サービスメッシュ — Istio Ambient・Linkerd・Cilium

サービスメッシュは2024〜2025年に大きな転換を経ました。Istioが**ambient mesh**(サイドカーレスモード)をGAでリリースし、Podあたり200MBのメモリ負担が消え、ztunnel(L4)とwaypoint(L7)の二層構造になりました。Linkerdは依然最軽量ですが、Buoyantのライセンス変更でOSSユーザーが一部離脱しました。**Cilium Service Mesh**はL7処理をサイドカーなしのeBPFで解く方式で急成長中です。

2026年の推奨は(1)**シンプル+無料**ならLinkerd OSSまたはCilium Service Mesh、(2)**機能豊富+大規模**ならIstio ambient、(3)**既にCilium CNI採用済**ならそのままCilium Service Mesh、です。

19. 運用UX — k9s・Lens・Headlamp・Komodor・Pixie

CLI/UIツールは2026年でも充実しています。**k9s**(Fernand Galiana)はターミナルUIの事実上の標準で、ほぼ全SREのdotfilesに入っています。

~/.config/k9s/skins/default.yaml — シンプルなダークテーマ

k9s:

body:

fgColor: dodgerblue

bgColor: black

logoColor: orange

prompt:

fgColor: cadetblue

bgColor: black

suggestColor: dodgerblue

info:

fgColor: orange

sectionColor: white

views:

table:

fgColor: aqua

bgColor: black

cursorFgColor: black

cursorBgColor: aqua

header:

fgColor: white

bgColor: black

sorterColor: aqua

**Lens**(Mirantis)はGUIの王者でしたが2023年のライセンス変更でOSSフォーク**OpenLens**が分岐し、**Headlamp**(Kinvolk → CNCF Sandbox)が完全OSS代替として地位を確立しました。**Octant**(VMware)は2022年にsunset。**Komodor**・**Devtron**はワークフロー寄りの商用/OSS代替。**Pixie**(New Relic → CNCF)はeBPFベースの自動可観測性でサイドカーなしにトレースを収集します。

2026年の推奨スタックは一般に「**ターミナルはk9s、GUIはHeadlamp、深いデバッグはPixie**」の組み合わせです。

20. K8s CI/CD — Tekton vs Argo Workflows vs GitHub Actions

K8s上のCI/CDは(1)**Tekton**(CD Foundation) — Pipeline/Task CRDベース、(2)**Argo Workflows** — DAGベースのK8sネイティブ、(3)**GitHub Actions Runner Controller(ARC)** — GitHub Actions RunnerをK8s Podで動かす、(4)**Jenkins X**(衰退傾向)、(5)**Drone**(Harness買収後変化)、に整理されます。

2026年の傾向は明確です。**ビルドはGitHub Actions/GitLab CI(ARCパターン)、デプロイはArgo CD/Flux**に分離するのが標準となり、K8sネイティブのワークフロー(Tekton/Argo Workflows)はML学習パイプラインやデータ処理のような「長いジョブ」領域に絞られました。

21. 可観測性スタック — Prometheus・Grafana・OpenTelemetry・Loki・Tempo

K8s可観測性の標準スタックは(1)**メトリクス** — Prometheus + Thanos/Mimir/Cortex、(2)**ログ** — Loki/OpenSearch/Elastic、(3)**トレース** — Tempo/Jaeger、(4)**収集** — OpenTelemetry Collector、(5)**可視化** — Grafanaです。2026年にはPrometheus 3.0(2024.11)がOTel互換を強化し、OTLPが事実上の標準収集プロトコルになりました。

eBPFベースの自動可観測性 — **Pixie**・**Coroot**・**Parca**(continuous profiling) — がサイドカーレス観測の新潮流を作っており、Grafana Labsの**Beyla**(eBPF自動計装)も急成長中です。

22. 韓国企業事例 — NAVER・Coupang・Toss・Kakao

**NAVER**はNCP(NAVER Cloud Platform)でNKS(NAVER Kubernetes Service)を提供しつつ、社内では自社PaaSの**NBP(NAVER Build Platform)** 上にArgo CDと独自のマルチクラスタコントローラを運用しています。検索・ショッピング・WebtoonなどのサービスがK8s上で稼働し、一部のML学習はvClusterで分離されています。

**Coupang**はAWS EKSのヘビーユーザーです。2024年の発表でKarpenter導入によりEC2コストを約30%削減した事例が公開され、深夜配送のピークトラフィックをKEDA + Karpenterの組み合わせで吸収しています。GitOpsはArgo CDが中心。

**Toss**(Viva Republica)は自社PaaS**Toss Cloud**の下にマルチリージョンEKSを運用。KubeCon EU 2024で発表された「数百のマイクロサービスをArgo CD ApplicationSetで管理するパターン」が有名です。一部ワークロードでTalos Linuxの実験を行っています。

**Kakao**は社内K8sプラットフォームの**DKOS(D2 Kubernetes Service)** を運用し、KakaoTalk・Daum・Kakao Payがその上で稼働します。社内テナントには一部、vCluster + Argo CDによるマルチテナント提供がなされていると発表されています。

23. 日本企業事例 — LINE Verda・Mercari・ZOZO・CyberAgent・SoftBank

**LINE Verda**はLINE/Yahoo Japan(現LY Corporation)の社内クラウドで、OpenStack上に独自のLINE Kubernetes Engineを載せて運用し、KubeConで定期的に登壇しています。2024〜2025年はTalos実験とマルチテナントvClusterパターンが話題でした。

**Mercari**はGCP GKEを中心に運用。KubeCon 2023〜2024で「マイクロサービス1,000個をArgo CDでGitOpsする事例」が共有され、2025年からはMLプラットフォームをKubeFlowから自家製Argo Workflowsベースへ移行中です。

**ZOZO**(ZOZOTOWN)はAWS EKS上でArgo CD + Karpenterの組み合わせで運用。ZOZO TECH BLOGにArgo Rolloutsのcanaryパターン事例が多数公開されています。

**CyberAgent(CAグループ)** は子会社が多くそれぞれクラウドを使い分けますが、社内共通プラットフォームの**AKE(AbemaTV Kubernetes Engine)** と**CIU(CyberAgent Internal Unit)** がK8s標準を定義します。ABEMA TVはGKE + Argo CDが主軸です。

**SoftBank**は自社OpenStack上でK8sを運用しつつOperatorパターンを積極活用し、B2B 5GパケットコアにK8sを適用する試みをKubeConで発表しています。

24. K8sアンチパターン — よく見る10の失敗

現場で繰り返されるミスをまとめると次の通り。

1. **`latest`タグを使う** — イメージキャッシュで非決定性が発生。常にdigestかSemVerで固定。

2. **livenessをreadinessのように扱う** — liveness失敗はコンテナ再起動。DBコネクション失敗にlivenessを当てると無限再起動。

3. **resources requests/limits未設定** — クラスタ全体がノイジーネイバーに翻弄される。

4. **`hostNetwork: true`の濫用** — セキュリティ・移植性とも損失。

5. **Jobの代わりにDeploymentで一回限りのタスク** — 完了済みPodが永久に残る。

6. **kubectl apply -fで直接デプロイ** — GitOps導入後に手で触るとself-healで戻される。

7. **一つのHelmチャートに全サービス** — 1行修正で全部再デプロイ。

8. **PDBなしでノードドレイン** — ダウンタイム発生。

9. **Operator万能主義** — kubectl applyで十分なものをCRDにして複雑度増。

10. **secretをConfigMapに平文** — もしくはGitに平文commit。ESO/SOPS/sealed-secretsで解決。

25. 2026年推奨スタック — 規模別ガイド

組織規模に応じて推奨スタックは異なります。

**小規模(1〜3名、1〜3クラスタ)**: k3sまたはマネージドEKS/GKE/AKS、Helm + Argo CD、Cilium CNI、Karpenter(AWS)またはCluster Autoscaler、k9s + Headlamp。

**中規模(10〜50名、5〜20クラスタ)**: マネージドK8s + Cluster API一部導入、Helm + Kustomize混在、Argo CD ApplicationSet、KEDA + Karpenter、Kyvernoポリシー、OpenTelemetry + Grafanaスタック、ESO + sealed-secrets。

**大規模(100名以上、50クラスタ以上)**: Cluster API本格導入またはTalos Linux、Argo CD複数インスタンスまたはFlux + Argo CD併用、KarmadaまたはLiqoでマルチクラスタ、自前Operator多数、Crossplaneでクラウド抽象化、Pixie + Beylaで自動可観測、Karporでワークロードインベントリ。

26. マイグレーションガイド — どこから手をつけるか

既にK8sを運用しているチームが2026年標準へ段階的に移る場合の推奨順序は次の通り。

1. **PSP → PSS + Kyverno**(即時、1.25以後PSPは削除済)。

2. **Cluster Autoscaler → Karpenter**(AWS使用時、コスト削減効果大)。

3. **Ingress → Gateway API**(段階的、新サービスから)。

4. **HPAのみ → HPA + KEDA**(イベント駆動ワークロード特定→0スケール)。

5. **Argo CD/Flux未導入 → 導入**(最大の運用改善)。

6. **サイドカーIstio → Ambient Mesh**(メモリ大幅削減)。

7. **独自Bashスクリプト運用 → Operatorでカプセル化**(小さいものから)。

8. **単一クラスタ → CAPIで標準化**(クラスタ5つを超えたら)。

27. 結論 — 2026年のK8sは「プラットフォームを作るプラットフォーム」

2026年のKubernetesはもはや「ワークロードオーケストレーター」ではなく、「**プラットフォームを作るためのコントロールプレーン**」です。Argo CD/Fluxによる宣言型運用、Karpenter/KEDAによる自動スケール、Cluster API/Talosによるクラスタ自体のIaC、Operator/Crossplaneによる抽象化、k9s/Headlamp/Pixieによる人間のためのUX — この5軸が2026年の標準になりました。

要点は「**全部のツールを導入するのではなく、組織規模に合った最小スタックを選んで段階的に拡張する**」ことです。Helm + Argo CD + Karpenter + Cilium + k9sを上手く使うだけで、ほとんどの組織には十分です。

References

- [kubernetes.io](https://kubernetes.io/) — 公式ドキュメント、1.33リリースノート

- [helm.sh](https://helm.sh/) — Helm公式(3.18)

- [kustomize.io](https://kustomize.io/) — Kustomize公式

- [argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/) — Argo CDドキュメント

- [fluxcd.io](https://fluxcd.io/) — Flux v2公式

- [keda.sh](https://keda.sh/) — KEDA公式、70+ スケーラ

- [karpenter.sh](https://karpenter.sh/) — Karpenter公式

- [cluster-api.sigs.k8s.io](https://cluster-api.sigs.k8s.io/) — Cluster APIドキュメント

- [talos.dev](https://www.talos.dev/) — Talos Linux公式

- [k3s.io](https://k3s.io/) — k3s公式

- [k0sproject.io](https://k0sproject.io/) — k0s公式

- [k9scli.io](https://k9scli.io/) — k9s公式

- [github.com/lensapp/lens](https://github.com/lensapp/lens) — Lens GitHub

- [headlamp.dev](https://headlamp.dev/) — Headlamp公式

- [github.com/cncf/sandbox](https://github.com/cncf/sandbox) — CNCF Sandbox一覧

- [sigs.k8s.io/controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) — controller-runtime

- [book.kubebuilder.io](https://book.kubebuilder.io/) — Kubebuilder Book

Kubernetesは2014年の最初のcommit以来11年間、「ゆるく結合したコントローラ群」という本質を失わずに進化してきました。2026年のエコシステムも同じ土台の上に新たなレイヤーを積む方向で発展しており、この記事で整理した6レイヤーは今後数年変わらない骨格です。