私が仕事の面接で学んだKubernetesについて

2026年6月16日原文(notnotp.com)

概要

Kubernetesが多くの企業で標準となった現状
技術的理由よりも組織的メリットを重視する傾向
導入理由は「統一性」「標準化された知識」「トレーサビリティ」
小規模でもKubernetesを選ぶ企業の増加
それでも初期段階では導入を慎重に考えるべきという意見

求人市場でのKubernetesの普及

最近の転職活動 で、多くの企業が Kubernetes を導入している現状
5年前は「Kubernetes採用組」「VM＋systemd組」「サーバーレス組」と三分されていた状況
現在は どの企業もKubernetes を利用、特に小規模スタートアップでも普及
マイクロサービスや大規模トラフィックでなくても利用される傾向

なぜKubernetesなのか：CTO達の本音

技術的理由 よりも 組織的メリット を重視する企業が多い
主な理由は以下の3つ
- 統一性
  - すべてのサービスが同じ方法でデプロイされる安心感
  - サービスごとに異なる運用手法や属人化の排除
  - 「どのサービスも同じ手順で管理できる」運用の一元化
- 標準化された知識
  - Kubernetes がエンジニアの共通言語となった現状
  - YAMLやHelmチャートでアーキテクチャ全体を把握できる
  - 特定の担当者が抜けても、 知識がドキュメント化 されているため引き継ぎが容易
  - SREや新メンバーでも即座にサービス運用が可能
- トレーサビリティ
  - 直接クラスタに変更を加えるのではなく、 GitOps （Helm＋FluxCD/ArgoCD）で管理
  - すべての変更がgit上で追跡可能、承認フローも明確
  - コンプライアンス対応や監査にも有効
  - 「誰が何をしたか」が常に可視化される体制

技術的な難しさより組織的なメリット

CTO達は「 技術的な必要性」よりも「 組織運営上の課題解決」を重視
実際には高度なKubernetes機能（HPA, Pod Disruption Budget, node affinity等）を使わないケースが大半
VM時代とノード数が変わらなくても、 一元管理 と 知識の共有 を得るためにKubernetesを採用
複雑なソフトウェア導入のコスト を、組織的メリットで受け入れている実情

それでも初期段階ではKubernetesを推奨しない理由

Kubernetesクラスタのトラブル対応 は難易度が高く、初期フェーズでは本業（プロダクト開発）に集中すべき
緊急時はVPS＋git pullのようなシンプルな運用が迅速かつ分かりやすい
CrashLoopBackOff 等のKubernetes特有のトラブルは、顧客対応前には避けたいリスク
「まずはシンプルな運用から始め、必要に応じてKubernetes導入を検討」するアプローチを推奨

なぜ最近Kubernetesが急速に普及したのか

5年前はVM＋systemd組も多かったが、現在はほぼ消滅
サーバーレス は依然としてニッチ
普及の要因として
- EKS/GKE/AKSなどのマネージドKubernetes の成熟
- エンジニアのKubernetes習得が進み、他の選択肢の人材確保が困難化
- Helm による「誰かのチャートをそのまま使う」運用の一般化
それでも決定的な理由は不明。業界全体の流れに疑問を持つ声

Kubernetes導入の最適なタイミング

CTOが唯一のエンジニアでなくなった瞬間 がKubernetes導入の目安
サーバー構築者以外がデプロイする必要が出てきた時点で、 知識の属人化 や アクセス制御 の課題が顕在化
退職時のノウハウ流出防止や、組織としての持続可能性確保に有効
「 システムが知識を持つ」ことの重要性

Hackerたちの意見

Kubernetesってほんとどこにでもあるよね。自分で運用しない限り、小さなKubernetesクラスターは管理がそんなに大変じゃないと思う。みんなサーバー管理の面倒さを忘れちゃってるんじゃないかな。結局のところ、Kubernetesは「退屈な技術」になりつつあるよね。

CTOの次に雇ったエンジニアが2人目でk8sを導入するって、ちょっと危ない兆候だよね。CTOの優先順位が間違ってるってことだし、ユーザーの問題を解決するんじゃなくて、自分のインフラをいじるのを楽しんでる感じ。

└

それがこの記事のポイントだと思ったんだけど、技術的なメリットはあまりないけど、非技術的なメリットのために使ってるってことだよね？

1年前はKubernetesがオーバーキルだと思ってたけど、今はどうかな？お気に入りのGPTにマニフェストを生成させて、プライマリアプリをクラスターに入れてテレプレゼンスで実行したり、コンテナから直接実行してコンテキストやクラスターを90年代のように切り替えたりできるよ。Docker ComposeとDockerが嫌いな理由の一つは、隔離がないこと。もちろん、深く手を突っ込めばできるけど、ローカルのk8sならワークスペースごとにクラスターを立てられるから、PostgreSQLインスタンス間のポートの競合を心配しなくていいんだ。LLMが出る前は、一貫したYAMLを書くのが面倒だったけど、今は小規模開発ならほぼタダ飯だね。

└

面白いね。Kubernetesについて読み始めたばかりなんだけど、さっき説明したプロセスについて詳しく書かれた資料ってある？

└

Docker ComposeとDockerが嫌いな理由の一つは、アイソレーションがないこと。確かに、腕を深く突っ込めばできるけど、ローカルのk8sではワークスペースごとにクラスターを立てられるから、PostgreSQLのインスタンス間でポートが競合する心配がない。Dockerのネットワークを理解できないから、複数のコンテナを自分のポートで動かせず、他のものと競合しないようにKubernetesを使うのは、災害のレシピみたいだね。特に、これを管理するエージェントを使う場合は、重要なデータを失うことになるよ。 > ほぼタダ飯だね。ああ、若者の有名な最後の言葉 :)

└

すごく同意する。LLMが得意なのは、TerraformやKubernetesのデプロイメント（またはHelmチャート）を書くことだね。以前は半日かかってたリサーチや試行錯誤が、今ではAIで20秒で終わるし、98%の確率で初回で成功する。で、Grafanaに指示して新しいサービス用のダッシュボードを作らせるのも簡単。昔は中規模の会社を支えるのに4人のDevOps/SREが必要だったのが、今ではパートタイムのSRE一人で済むようになった。

└

ついに自分のハードウェアを買って、LLMを使ってk3sクラスターをデプロイしたよ。DIYのホームラボやホスティングが今まで以上に手軽になったと思う。クラウドのコストを削減して、AIに投資するのがいいよね。予算のあるソロ開発者には、これが理にかなってると思う。

└

これは両方の側面があるね。どの段階でも、SOTAモデルをKubernetesに再パッケージできる。もしちょっと冒険したいなら、デプロイスクリプトすら必要ないよ。適切な権限を持ったllmユーザーアカウントと、全サーバーのSSHキーさえあれば大丈夫。

└

お気に入りのGPTにマニフェストを生成させてみて、... > LLMが一貫したYAMLを書く前は本当に面倒だったけど、今は低い開発スケールではほぼタダみたいなもんだね。マニフェストを書くのは些細なことに思えるけど、実際にプロダクションでk8sクラスターを運用しているのは誰？アップグレードを行うのは誰？システムを監視するために呼ばれるのは誰？もちろん、誰かが全部やってくれるなら、それはタダ飯に感じるよね！

スタートアップでこの決定をしたことがあるけど（その時エンジニアチームは約30人で、モノリスに約10のサポートサービスがあった）、もう一度やりたくないな。この記事に書かれている理由があってもね。統一性はいいけど、直接EC2インスタンスで動いていたアプリから移行したんだ。新しいサービスを立ち上げるたびに、EC2インスタンスをちゃんとプロビジョニングするのが大変だった。でもk8sは本当に面倒くさい。新しい人が気づかないことの一つは、全然バッテリーが含まれてないってこと。基本的なマネージドクラスターをセットアップするには、いくつかの追加コントローラー（ingress、cert-manager、external dnsなど）をインストールしなきゃいけないし、そのプロセスがちゃんと動いてるかも確認しなきゃいけない（重要なリソースのためのアドミッションウェブフックコントローラーがダウンしないことを願う！）。それに、クラスターだけじゃなくて、すべてのコントローラーも約3ヶ月ごとに大規模なアップグレードをしないといけないし、壊れる変更を導入するのに誰も遠慮しない。さらに、k8sのネットワーキングやDNSレイヤーは、ほとんどのスタートアップには全く必要ない複雑さをもたらす。EKSを使ってるなら、CoreDNSのスケーリングやモニタリングについても読んでおくべきだと思う。複雑さなしで宣言的にいくつかのコンテナをいくつかのインスタンスにデプロイできるシンプルなソリューションが市場に本当に必要だと思う。そういうのがあると思うけど、k8sが全ての酸素を吸い取っちゃってる感じ。

└

シンプルなソリューションが市場に欠けてると思う。複雑さなしで、宣言的にいくつかのインスタンスにコンテナをデプロイできるやつ。HashicorpのNomadがまさにそれで、いろんな実行方法もサポートしてるのがいいね。ライセンス変更が残念で、興味がほぼなくなっちゃったから、やっぱりその穴はまだ埋まってないみたい。

Hacker Newsで議論の続きを見る

ハクソク