就職面接が Kubernetes について教えてくれたこと
(notnotp.com)- Kubernetes は小規模な会社でも、技術的なスケーラビリティより デプロイ方法の統一 と組織運営の問題を解決する基準として採用されている
- 最近の求職活動で話した会社はすべて Kubernetes を使っており、5年前の VM・serverless・K8s が併存する構図とは異なっていた
- CTO たちが挙げた中核的な理由は、サービスごとに同じ方法でデプロイでき、YAML と Helm チャートに運用知識を残し、GitOps で変更履歴を追跡できる点だった
- 小さな会社は HPA、Pod Disruption Budget、ノードアフィニティのような高度な機能より 組織的な利点 のために、複雑な Kubernetes を受け入れている
- 初期段階の会社は製品に集中するため Kubernetes なしで始めるほうがよく、CTO が1人でエンジニアリングを担わなくなる時点から導入の必要性が大きくなる
最近の求職で見えた変化
- 最近の求職活動で求人票を読み、面接を受け、約12社のエンジニアリングチームと話した結果、話したすべての会社が Kubernetes を使っていた
- 5年前に転職活動をしたときは、Kubernetes をまれに使うグループ、VM/VPS/EC2 上で
systemdを使うグループ、Lambda や Cloud Run のような serverless のグループが併存していた - 現在働いている会社は Big Tech 規模の問題があるので Kubernetes が明確に適しているが、2つのサービスしか持たない10人規模のスタートアップまで Kubernetes を使っているのは驚きだった
- 話した会社はマイクロサービスを運用していたわけでも、高いスケールに近い環境だったわけでもなく、Kubernetes の技術的側面には大きな関心を持っていなかった
Kubernetes 採用理由と判断基準
-
なぜ Kubernetes を使うのか
- 1つ目の理由は uniformity で、すべてのサービスが同じ方法でデプロイされれば、特定のサービスだけが古いベア VM の bash スクリプトや Docker Compose に縛られる状況がなくなる
- 2つ目の理由は 共有可能で採用可能な知識 で、Kubernetes が共通言語のように使われることで、Helm チャートと Kube 設定を見るだけでもアーキテクチャを素早く把握できる
- 知識が人の頭の中ではなく YAML に残っていれば、誰かが去ったあとに後任者が実行方法を把握するために何週間も費やすことが減る
- 現在の会社のオンコール SRE は、初めて見るサービスでも Kubernetes パターンがチームごとに共通しているため保守できる
- この利点は、設定が過度に特殊でない場合にのみ成り立つ
- 3つ目の理由は 追跡可能性 で、クラスターに直接
kubectl apply -fを実行するのではなく、Helm チャートを git に上げたあと MR 承認と FluxCD または ArgoCD によるデプロイを経れば、変更履歴が残る - この流れは GitOps と Kubernetes が自然にかみ合うため、ほぼ追加コストなしでコンプライアンスに役立つ
- 現在の会社はこの方法で ISO 認証をうまく通過している
-
得られた結論
- CTO たちの選択は愚かなものではなく、実際の問題を解決する方法だった
- Kubernetes は技術的な問題に対する技術的な解決策のように見えたが、多くの CTO は予想以上に 非技術的な利点 に強い関心を持っていた
- 小さな会社の技術的な問題は Kubernetes が必須なほどではなく、マニフェストに topologySpreadConstraints、HPA、Pod Disruption Budget、ノードアフィニティのルールがない可能性が高い
- 彼らは VM を使っていたときと似た数のノードを維持しながらも、組織的な利点のために複雑なソフトウェア運用コストを受け入れている
-
なぜ最近になって移行が起きたのか
- 5年前は VM と
systemd、serverless、Kubernetes がすべて選択肢として残っていたが、今の求人票では VM とsystemdの組み合わせはほぼ消え、serverless はニッチにとどまり、Kubernetes が勝った - 移行のタイミングの理由は完全には明確ではない
- 考えられる理由は、EKS、GKE、AKS のような マネージド Kubernetes が成熟し、Kubernetes を学んだ人が十分に増えたことで、別の方式を採用するほうがかえって難しくなった点にある
- Helm は、他の人が作ったチャートをそのまま使うという選択肢を現実的なオプションにした
- 5年前は VM と
-
いつ Kubernetes を使うべきか
- 個人的な基準は、CTO がもはや唯一のエンジニアではなくなる瞬間だ
- 2人目のエンジニアが加わると、サーバーを自分でセットアップしていない人がデプロイしなければならず、何にでも SSH キーを渡す方式ではなく、適切なアクセス制御が必要になる
- 結局は誰かが会社を去り、その人が持っていた運用知識も一緒に失われうる
- この時点から、知識は人ではなく システム の中に残っていなければならない
- それ以前の段階では、クラスターのデバッグは実際に難しく、製品に使うべきエネルギーをインフラに使ってしまう可能性がある
- 大口顧客との通話直前に
CrashLoopBackOffに陥った pod の原因を2時間探すより、VPS 上で緊急にgit pullで直すほうが、速くて理解しやすい非常対応かもしれない
1件のコメント
Lobste.rsの意見
ヨーロッパ側では理由は明確です。CTOたちは、K8sの上に載せておけばマネージドK8sプロバイダーを数週間で切り替えられると信じています
それが正しいという意味ではありませんが、実際にそう信じています。PR環境もより簡単になると考えています
ですが核心はプロバイダー切り替えです。今後数年以内に米国とつながりのあるプロバイダーの利用禁止が生じると予想しており、特にGDPRや金融システムなどでその可能性が高いです。だからそのリスクに備えているのです
会社の規模に関係なく、技術業界が完全に方向を見失った証拠のように見えます。スタックはますます画一的で複雑になったのに、その結果として、歯を食いしばらずに使える製品やサービスを見つけるのがより難しくなっています
もっと優れたOSの基本要素が必要です。たとえばコンテナは、一貫した設計なしにカーネルのさまざまな隔離機能を寄せ集めたもので、穴が多くありました
今ではコンテナ隔離はかなり良くなりましたが、最初からセキュリティと健全性を設計したのではなく、モグラ叩きのように修正した結果です。カーネルが巨大な技術的負債を処理するか、誰かが移行に値するカーネルを作るまでは、その上に何かを積み続けることになるでしょう
十分に複雑なデプロイツールは、結局その場しのぎで作られ、非公式に定義され、バグが多く、遅いKubernetesの半端な実装を含むことになります
2009年に10億ドル規模のSaaS電子商取引会社をどう構成していたか、超大規模AAAマルチプレイヤーゲームのオンラインバックエンドがどう動いていたかを長々と話せますが、それらは単一マシンへのデプロイよりは、確かにKubernetesに近いものでした
ですがもっと速く、組織が正確に必要とする形で強い意見を持っていて、製品要件と衝突する形ではありませんでした
Kubernetesの「バグが多い」というのは、コアシステムそのものより、私たちが望む通りに動かそうとしてその上に載せる数多くのインターフェース層から来る場合が多いです
問題は、たいていの組織がK8sを中途半端に導入し、それを管理するDevOpsチームまで置きながら、結局はソフトウェアエンジニアにK8s関連の作成、デプロイ、デバッグ、運用をすべて押しつけている点にあります
良いDevOpsチームなら、内部的にHerokuのような体験を提供すべきです。必要なリソースを定義してmainにマージすればデプロイされるべきで、ひどいGitOps/DevOpsダッシュボードで何が悪いのか迷うべきではありません
Herokuが開発者体験の頂点で、K8s以後それを失ってしまったと思います
もちろんHerokuはデータベース連携やgit pushデプロイまで含めた、より統合された体験を提供しますが、Kubernetesの上にカスタムの外殻を作るのはあまり良くありません。結局すべてのパラメータをそのまま通すことになるからです
業界での技術採用はいつも「既製服のように採用し、不要なら解雇する」という原則で動いています。これもその最新の例の一つです
「知識は人ではなくシステムが持つべきだ」という一文が、ぼんやり考えていたことをとてもうまく表現してくれています
こうした形式化は、プロセスの変動性が下がるときにだけ可能です。人が直接やり、プロセスを文書化し、スクリプト化し、その次に自動化するという流れです
人気のあるツールやエコシステムの一般的なワークフローでは、この段階の大半をほとんど無料で得られます
DevOpsをそれほど多くやっているわけではなく、今はsystemdとたまに使うpodmanコンテナだけでもシステムはうまく回っています。IoT/AgTech分野で働いています
この記事には、非技術系の経営陣からよく聞く類の「主張」があります。だいたい「向こうもLoRaをやってますよね？ じゃあ大丈夫ですね？ 明日リリースできますよね？」のようなものです
不均一性だけが成功の唯一の障害だという信念があります。二つのシステムがFiberやModbusを使っているとか、「APIがある」といっただけで、すぐに接続して「1 + 1が総和を超える」素晴らしい体験を作れると考えています
ですが、二つのソフトウェアが低レベルの相互運用標準に合意しているからといって、簡単にパースできるデータをどう解釈し、どう有用に使うかを決める実際の作業が消えるわけではありません
二人が同じ言語を話せるからといって、やるべきことがなくなるわけではありません。共通言語を使うからといって、チームの一部がそのツールを使い、その当時知っていた条件のもとで下した決定が消えるわけでもありません
初期には科学・工学の世界でFortranが共通語でしたが、だからといって同僚たちの仕事に完全に戸惑ったり、書き直したりすることがなくなったわけでもありません
K8sの価値や、現在「標準」として定着している点には不満はありません。ただ、それによってどんな種類かのプログラミング上の問題が消えるという主張には同意しづらいです。醜さ保存の法則は今も残っています
Kubernetesはまともなデプロイプラットフォームです
デプロイ形態もまた別の理由です。Cantonノードの作業をしていますが、上流のCantonソフトウェアと関連アプリはHelmチャートで提供されています
Kubernetesが私たちの仕事に適しているかどうかとは別で、私はそうは思いませんが、ソフトウェアはそのようにデプロイされ、サポートされています。その道筋から外れると、Kubernetesを扱うこと以上に仕事が増えます
この記事があまりにもAIが書いたように聞こえるのは私だけでしょうか
それでも趣旨には同意します。ホームラボ/セルフホスティング構成を、カスタムsystemd設定や思い出せないシェルコマンドや「くそ、あの設定手順をどのMarkdownファイルに書いたんだっけ？」という状態から移行している最中ですが、本当にすがすがしいです
まだ本物の継続的デプロイシステムを使っているわけではありませんが、小さな
applyシェルスクリプトとYAMLファイルの束だけでも、災害が起きても90%は復旧できそうだという感覚が気に入っていますsystemdは概念的には単純ですが再現性が複雑で、Kubernetesはその逆です。概念コストはより払うことになりますが、再現性と、それに伴う理解ははるかに強くなります。少なくとも今のところはそう見ています
まだKubernetesを学んでいる途中段階ですが、最近かなり楽しく使っています
こうした一級定義を備えた垂直統合は、間違った方向に見えます