Kubernetesエコシステム 2026 完全ガイド — Helm・Kustomize・Argo CD・Flux・KEDA・Karpenter・Cluster API・Operator Framework 徹底分析

「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
name: myapp
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
    count: 10
patches:
  - target:
      kind: Deployment
      name: myapp
    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:
  name: myapp-prod
  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:
  name: myapp-fleet
  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:
      name: '{{cluster}}-myapp'
    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:
  name: order-consumer
  namespace: orders
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-consumer
  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:
  name: default
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
        name: default
      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:
  name: aws-eks-1-33
spec:
  controlPlane:
    ref:
      apiVersion: controlplane.cluster.x-k8s.io/v1beta2
      kind: AWSManagedControlPlaneTemplate
      name: aws-eks-1-33-cp
  infrastructure:
    ref:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
      kind: AWSManagedClusterTemplate
      name: aws-eks-1-33-infra
  workers:
    machineDeployments:
      - class: default-worker
        template:
          bootstrap:
            ref:
              apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
              kind: EKSConfigTemplate
              name: aws-eks-1-33-worker-boot
          infrastructure:
            ref:
              apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
              kind: AWSMachineTemplate
              name: aws-eks-1-33-worker

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ベース。

ディストロ	バイナリサイズ	etcd	推奨用途
kubeadm	部品分離	外部etcd	標準本番
Talos	OS一体型	etcd内蔵	K8s専用OS
k3s	約60MB	sqlite/etcd	エッジ/ホームラボ
k0s	約70MB	etcd内蔵	組み込み/エッジ
microk8s	snap	dqlite	Ubuntuデスクトップ/エッジ
kind/k3d	Dockerコンテナ	etcd内蔵	CI/ローカル
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大原則は次の通り。

レベルトリガ(level-triggered) — イベントではなく、desired stateとactual stateの差分で動く。イベントを取りこぼしても次のreconcileで回復。
OwnerReferences — 親リソースが削除されると子が自動GC。
Finalizers — 外部リソースの整理が完了するまで削除をブロック。
冪等な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は表現力が低いので、ほとんどの組織はその上に専用のポリシーエンジンを重ねます。

ツール	言語	強み	弱み
OPA Gatekeeper	Rego	表現力最強、CNCF Graduated	Rego学習コスト
Kyverno	YAML	K8sネイティブ、学習容易	複雑なポリシーには限界
KubeArmor	YAML + LSM	ランタイムBPF/LSM	カーネル依存
Falco	YAML	ランタイム異常検知	強制力なし

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

# Kyverno ClusterPolicy — latestタグ禁止、リソース上限を必須化
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-tag
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)は自社PaaSToss 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の失敗

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

latestタグを使う — イメージキャッシュで非決定性が発生。常にdigestかSemVerで固定。
livenessをreadinessのように扱う — liveness失敗はコンテナ再起動。DBコネクション失敗にlivenessを当てると無限再起動。
resources requests/limits未設定 — クラスタ全体がノイジーネイバーに翻弄される。
hostNetwork: trueの濫用 — セキュリティ・移植性とも損失。
Jobの代わりにDeploymentで一回限りのタスク — 完了済みPodが永久に残る。
kubectl apply -fで直接デプロイ — GitOps導入後に手で触るとself-healで戻される。
一つのHelmチャートに全サービス — 1行修正で全部再デプロイ。
PDBなしでノードドレイン — ダウンタイム発生。
Operator万能主義 — kubectl applyで十分なものをCRDにして複雑度増。
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年標準へ段階的に移る場合の推奨順序は次の通り。

PSP → PSS + Kyverno(即時、1.25以後PSPは削除済)。
Cluster Autoscaler → Karpenter(AWS使用時、コスト削減効果大)。
Ingress → Gateway API(段階的、新サービスから)。
HPAのみ → HPA + KEDA(イベント駆動ワークロード特定→0スケール)。
Argo CD/Flux未導入 → 導入(最大の運用改善)。
サイドカーIstio → Ambient Mesh(メモリ大幅削減)。
独自Bashスクリプト運用 → Operatorでカプセル化(小さいものから)。
単一クラスタ → 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 — 公式ドキュメント、1.33リリースノート
helm.sh — Helm公式(3.18)
kustomize.io — Kustomize公式
argo-cd.readthedocs.io — Argo CDドキュメント
fluxcd.io — Flux v2公式
keda.sh — KEDA公式、70+ スケーラ
karpenter.sh — Karpenter公式
cluster-api.sigs.k8s.io — Cluster APIドキュメント
talos.dev — Talos Linux公式
k3s.io — k3s公式
k0sproject.io — k0s公式
k9scli.io — k9s公式
github.com/lensapp/lens — Lens GitHub
headlamp.dev — Headlamp公式
github.com/cncf/sandbox — CNCF Sandbox一覧
sigs.k8s.io/controller-runtime — controller-runtime
book.kubebuilder.io — Kubebuilder Book

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