もしもKubernetes 2.0が登場したらどんな姿になる？

「メンテいらず」？いやいや、全然違うって！EKSとか使えばクラスタの健康診断は任せられるけど、Kubernetesって実質メンテの塊だよ。YAML投げるだけで動くのはマジすごいけど、その裏返しでメンテがハンパないの。設定、ArgoCD、オペレーター探し、values.yaml調整、アプデ、スケーリング時のノード入れ替えとか…全部大変なんだよ！
まじでメンテだらけ！

「メンテが少ない」ってのは、他のやり方と比べたらって話でしょ。俺の経験だと、K8s使うと、スケーリングとかフェイルオーバー、デプロイ、元に戻したり、障害対策、DevOps、新しいクラスタ作るのとか、同じレベルのことやるのにメンテの手間が全然かからなかったよ。まあ、人それぞれだろうけどね。

Kubernetesへの文句って、結局「複雑すぎ！」ってのが多いじゃん？でもさ、分散システム組むこと自体が複雑なんだよ、プラットフォーム関係なくね？Kubeが「複雑」に見えるのは、ソフトをデプロイするのに必要なアレコレ全部を、標準的なやり方でできちゃうからなんだって。Kubeなしで同じことやろうとしたら、自分で全部作る羽目になるし。もしそんなに色んな機能いらないなら、Kubeは別にいらないってこと。

君たちが話してるのって、Kubernetesのメンテじゃなくて、CI/CDとかシークレット管理、DB操作の自動化とかのメンテでしょ。昔だったらYAMLじゃなくて、cronjobとかansible、systemd、bashスクリプトとかをメンテしなきゃいけなかったんだよ。

俺、Hetznerでk3sを2年以上動かしてるけど、全然止まらないし（100％uptime）、マジでメンテいらずだったよ。あんまりメンテしなさすぎて、マスターノードのSSHキーなくしてさ、クラスタ全部作り直す羽目になったんだけど、それでも90分で終わった（ドキュメント直す時間込み）。急げば15分でいけるね。ARM環境でk3s、ノード3台とマスター1台、ストレージ、ロードバランサー、CloudflareでDNS自動化で、月たった20ユーロだよ。

あれって、要は自分で「クラウド」をイチから作ってるみたいなもんだよね。それがkuberetesの狙いなんだろうけど。そりゃメンテ大変だよ。自分のコードだけじゃなくて、CI/CDとかシークレット管理、ログ、ストレージ、DBとか、全部自分で動かしてるんだもん。全部自分持ちってわけ。でもさ、kuberetesで作ったやつって、クラウド変える時がめちゃくちゃ楽だったんだよね。今もAWSとAzureにノードがあるk3sクラスタ動かしてるし。

このコメントの最初の部分、ちょっとわかんないな。Kubernetesって、本番で分散システム動かすのに必要な全部をまかなう、完璧なエンドツーエンドソリューションとしては設計されてないと思うんだけど。色んなことは管理してくれるけど、さっき言ってた全部をまとめて指揮するわけじゃないでしょ。

みんながKubernetesって複雑だよねって（それはそれで正しいんだけど）言うのは、そもそも分散システムなんて大半の人は必要としてないからだと思うんだよね。k8sが流行ってるからって手出しちゃうけど、正直多くの人はVM立ててChefとかで設定して、昔みたいにソフト動かした方が絶対楽だよ。

K8sは全部をまかなうもんじゃないって？いやいや、2017年からのKubernetesはエンドツーエンドでいけるように作られてるし、実際可能だよ。CNCFの https://landscape.cncf.io/guide#app-definition-and-developme… とか見てみ？CI/CDとかログとかストレージとか、何でもあるじゃん。クラウドのリソースをk8sのCRDで包んで、LoadBalancerとかみたいに抽象化するんだ。SaaSみたいなのも自分でCubeFSとか立てれば持てるし。K8sがあれば、AWSとかじゃなくてKubernetesがターゲットになるんだ。どこまで自分でやるか（ロックインしないか）決められるのが良いとこ。Kafkaは辛いからSQS？ロックイン嫌ならKafka？自分でリスク選べるってことだね。

K8Sを制御プレーンにするとGitHubとかCircleCIみたいなのを自分でメンテするハメになるんだよ。K8Sの核じゃない重い作業だし、問題はデータプレーンにあるってこと。CRDで制御プレーンをK8Sに寄せられるのはいいけど、細かいとこはデータプレーン次第だよね。

K8Sメンテのヤバさを話すのは、マジで顧客がいて大規模にやってる人たちなんだよ。月20€のインフラとかの話は全然役に立たない。俺たちは何千サービス、10万台規模で動かしてて、コンプライアンスとか契約もあるから、メンテの辛さは超重要なんだ。あんたのコメントはうちの現場じゃノイズでしかないね。

同じ制御プレーンだとデータプレーンも上手くいきやすいよ。K8SがS3バケットとか用意してくれるなら、どこのサービスか気にしなくてOK。K8Sの核はコンテナオーケストレーションと拡張性・抽象化だ。CRDは超核だよ。GitHubとかのメンテは大変だけど、K8Sを使えばどこまで自分でやるか選べるんだ。ベンダーロックインが嫌なら、K8Sで自分で管理すればいいじゃん。

分散システム選ぶ時って、K8Sか自分で作るかじゃなくて、K8Sか、お金払ったら面倒見てくれるクラウドベンダーかって話だよね。

ほとんどの人は分散システムが要るんだよ。障害に強くて、スケールするシステムが欲しいんだ。昔は高かったけど、今は月50ドルも出せれば十分安い。ほぼどんなWebサイトでも分散システム避ける理由なくなったね。

自分でK8S制御プレーンを動かすのってEKSとかGKEと大差ないよ。マジで複雑なのは、制御プレーンじゃなくて、その上に自分で作るインフラとかデプロイ、その設定なんだ。EKS使おうが自分でやろうが、オートスケーリングとか負荷分散、監視、ネットとかは自分で解決しないといけないからね。

K8Sメンテが辛いって言う人は、マネージドKubernetes使ってるんだろ。それがメンテの複雑さのほとんどをカバーしてくれてるからね。

『同じ制御プレーンだとデータプレーンもうまくいく』は絶対ウソ。だからサービスごとに制御プレーンが違うんだよ。K8S制御プレーンは万能じゃない。ベンダーロックインがないなんてことないし（自前でも）。K8Sで減らせるけど、AWSのEKSで作った複雑なシステムをGKEとかに持っていくのは超大変だよ。

それ自業自得じゃね？余計なもん入れすぎるんだよ。追加するものは全部テクニカルデットで、タダでもコストかかるんだ。オートスケーリングがメンテよりコスト削減にならんなら、切れよ。

Helmチャートとかノードのインストーラーがあれば、インストールはマジ速い。うちはDBとか以外はクラスターのバックアップしないんだ。全部作り直せばいいからね。

確かに、Kubernetesの比較って全然適切じゃないことが多いよね。固定リソースの固定アプリと比較しても意味ないじゃん？今のデプロイはそうじゃないし。
K8sが必要なデプロイが複雑すぎって意見もわかるけど、前の会社では超慎重だったのにK8sに移行したし、今の会社でもシステムは思ったよりシンプルになるけど、大規模になるとK8sみたいなのがないと調整が大変すぎるんだよ。

うん、そうだよ。でも90％じゃなくて75％くらいかな？
”月20ドルのスタックだからメンテ不要”みたいな単純な意見には全く同意できないね。

それ、信じられないくらい自己中心的なコメントだよ。
みんなKubernetesを使う理由はたくさんあるのに、全部があなたのニーズと一致するわけじゃないんだから。

そうそう、Helmチャートとかノードインストーラーを手に入れたら終わりってわけじゃない。
でもほとんどのアプリでそこまでしなくてもいいと思うな。簡単なKustomizeスクリプトで大体の基本的なことはできるし。
シンプルにしたいと思えば、物事はシンプルになる時もあるんだよ。

バージョンアップグレードってどれくらいの頻度でやるの？
ノードとかコントロールプレーンのOSのパッチ当てとかは？
アプリの稼働時間や可用性が重要になると、すぐに複雑になるよね。

そう、でも僕はEKSのことなんて言ってないよ。
k8sを採用してる会社の99％は、そもそも採用すべきじゃないし、このテクノロジーに対するビジネスケースがないんだ。

Kubernetesって、エンジニアリングの要件より、履歴書とか昇進資料を埋めるために選ばれることがよくあるんだよ。
本当にKubernetesが必要なくらい規模が大きくて複雑な組織は、それだけ専任の担当者を置けるくらい大きいんだ。

すごく的確な意見だね。
それに加えて、E2Eソリューションならデプロイ前に学ぶ必要があるけど（それでも完璧にはできないけど）、そうじゃないと実際に問題が起きてから学ぶことになるんだ。
中途半端な分散システムを持ってる人に聞いても、自分のシステムの全ての失敗モードを知ってるわけじゃない。
ミッションクリティカルなシステムで見てきたよ。
でも、ちゃんとした信頼できるインフラがあった会社では、K8sベースの新しいインフラに移行したシステムは、メンテナンスが大幅に減って、DevOpsがずっと標準化されて（他のチームの人も必要な時に手伝えるようになった）、ミスもずっと少なくなったんだ。
K8sが全てを合理化したことに誰も異論はなかったよ。

NixOSが簡単に設定、運用、オンボードできるようになって、成功してほしいって本気で願ってるんだ。
もう人生で他の設定管理ツールは使いたくないな。
そうすれば、シンプルなVMとか分散ユースケース向けのk8sとか、どっちもコードで宣言できるんだ。

みんな、K8sが何でもオーケストレーションできるなんて知らなかった頃から、可搬性のために「K8sのベストプラクティス」を議論するようになったんだ。進歩の余地はあるよ。
現実として、乗り換えコストがゼロなんてことはない。K8sをうまく使えば、一番手間のかからない移行方法に関するベストプラクティスはたくさんあるんだ。それは十分可能だし、いつもみんながやってるのを見かけるよ。

K8sって、たくさんのアプリ開発者が共通で使えるプラットフォームを提供したいって思ったときに、やっと意味が分かってくるんだ。
GoogleのBorgから生まれて、彼らがこれでどんな問題を解決しようとしてたか理解できれば、その複雑さも納得できると思うよ。

まず、K8Sは誰もYAMLを使うよう強制してないよ。慣習的かもしれないけど、必須じゃない。kubectl applyは最初からJSONもサポートしてるし、APIエンドポイントはJSONとgrpcだよ。好きな言語でJSONでもYAMLでも作れるし、Jsonnetとかすごく良いよね。
次に、なんでHelmチャートで依存関係とか順序が問題になってるのか不思議。LinuxやWindowsみたいにサービスの起動を待つ世界じゃないのに。Kubernetesの基本原則の一つはループだよ。依存先が使えないなら、アプリはそれをリカバリ可能なエラーとして扱って、利用可能になるまでリトライし続けるべきなんだ。もしくはクラッシュすれば、ReplicaSetコントローラーがアプリを再起動してくれるしね。
チャートに依存関係がなければ、依存の競合なんて起きないし（「考えてみて」ミームをどうぞ）、各チャートを個別にインストールすればいい。Helmは必要なら同じチャートを複数バージョンインストールすることもできるけど、それを一つのnamespaceでやると大変なことになるよ。
もしあるアプリが本当に別のアプリに依存するなら、依存先を同じHelmチャートに含めるのも選択肢の一つだよ！Helmチャートは最初から複数のアプリやサービスリソースを持てるようになってるんだから。

＞Kubernetesの基本原則の一つはループだよ
そうだね、Kubernetesで作業する上で、一番重要なアーキテクチャ機能は「調停ループ」だって言えるね。現在の状態を観察して、望ましい状態との差分を確認し、その差分を適用する。これを何度も何度も繰り返すんだ。失敗とか成功の状態があるわけじゃなくて、ただ観測できる状態と、そうあってほしい状態があるだけ。その間の違いは繰り返し処理されることで解消されていくんだ。
機械制御の主流で「十分良い技術」とされているPIDフィードバックループが、Kubernetesのこの核となる部分とかなり似てるってのは面白いと思うよ。

PIDフィードバックループ、OODAループ、そしてブラックボードシステム（AI設計モデル）は、どれもK8sが体現している有効な例えだよ。最初の2つはK8s 1.0の頃のプレゼンとかトークでよく使われてたぐらい、よく知られてるんだ。

君が説明してるのはController[0]のことだね。彼らが挙げてる部屋のサーモスタットの例はすごく分かりやすいよ。
でもその原則はControllerじゃないものにも当てはまる。例えば、データベースみたいなリソースがReadyになるまで待ってから、自分自身がReadyになるワークロードがよくあるパターンだね。WebサーバーPodの中だと、DBが利用可能になるのを待って、必要なマイグレーションが適用されたかチェックして、最後にリクエストを処理し始める、みたいな流れ。
つまり、基本的には「DB待ちループ」から「マイグレーション待ちループ」、そして「Webリクエスト待ちループ」へと進んでいく感じなんだ。最後のループが終わるとクラスターはそのPodを「Ready」と見なして、Deploymentのロールアウトとかが進むんだよ。
[0] https://kubernetes.io/docs/concepts/architecture/controller/

僕も何年か前にこういうシステム（君が調停ループって呼んでるやつ）を開発したことあるけど、失敗状態は間違いなく存在するよ（いろんな理由で）。でも「ループ」の一部として、望ましい状態に戻すためにそれを修正するロジックを持たせることはできるんだ。
僕たちは失敗と「起きたこと」を関連付けるために、統合されたモニタリング／ログ分析を使ってたね。

依存関係の失敗がリカバリ可能であるべきっていう意見に大賛成だよ！
使われてなくてシャットダウンされつつあった依存サービスがfail-closedだったせいで起きた障害に巻き込まれたことがあるんだ。
サーバー間の依存関係はほとんどの場合、ソフトだよ。もしダウンストリームの依存サービスと通信できなくても、ただ500を返せばいいんだ。健全じゃないサーバーはロードバランサーに避けてもらえばいい。

＞クラッシュすれば、ReplicaSetコントローラーがアプリを再起動してくれるしね
これ、十分じゃないんだよね。今、Keycloakが起動に1分かかるんだけど、それに依存しててKeycloakがないと起動時にクラッシュするサービスが、起動に5～10分かかるんだ。ReplicaSetコントローラーがスロットリングし始めて、Keycloakが起動した後も何分も無駄に待たされるんだよ。最終的には動くけど、1分で済むのに10分も待ちたくないよ。
この問題の正しい解決策は、Init Containerを作って、依存サービスが起動するまで待ってからメインコンテナに処理を渡すことだと思う。でも、Kubernetesが起動時の依存関係を明示的に宣言できるようにしてほしいな。その依存が上がってないと僕のサービスは確実にクラッシュするんだから、何度か起動を試してスロットリングされるだけなのに、そもそも起動しようとする意味が分からないよ。
依存関係は依存関係なんだ。見て見ぬふりはできないよ。

それは、初期デプロイの速度じゃなくて、全体のレジリエンス（回復力）を最適化してるんだと思うな。遅延を増やしながら依存サービスの呼び出しをリトライするのは、本番サービスではベストプラクティスだよ。最初のロールアウトでこの挙動を見るのは不便だけど、これも自己修復なんだ。
君が思ってるより時間はかかるかもしれないけど、そんなに我慢できないなら、君が説明したような回避策（Init Containerなど）もあるよ。

「～することになっている」って言うけど、それは自社で全部作る時に良いやり方だよ。でもさ、Kubernetesより前に作られて、Dockerで動くようになって、それを簡単にKubernetesでも動くようにしたソフトってどんだけあると思ってんの？
「これが一番良いやり方だ！」っていうOpinionatedなプラットフォームを作っても、結局みんな好き勝手やって失敗するだけ。それより、色んなやり方を選べる機能を追加して、ユーザーに決めさせてあげた方が良いんじゃない？

それに対する反論としては、色々できすぎる（footguns）とか、注意を引くような厄介な機能（attractive nuisances）は、システムが安定（resilience）するのとは真逆だってことだよ。みんな別にいらなかった機能まで間違って使っちゃうし、新しい機能が増えるたびにバグや曖昧な挙動の原因になるんだから。

YAMLはJSONの上位互換（superset）なんだから。もちろん、YAMLをサポートしてるならJSONもサポートしてるに決まってるじゃん。

でも出力側は違うってのも事実だよ。kubectlだってYAMLでって指定しないとYAMLでは出力しないしね。APIがサポートしてるのはJSONとprotobufだけで、YAMLじゃないんだ。

＞Kubernetesの主要な考え方の一つはループ処理：依存関係が利用できなくても、アプリはそれを回復可能なエラーとして扱い、利用可能になるまで再試行することになっています。
これバカみたいに聞こえるかもしれないけど、ログの最初のエラー見ただけでみんなパニックになるんだよ。あるいは部署のトップがデモ見て「最高だね！でもデモする前にそのエラー消しといて」とか言うんだ。そしたらどうする？
「デプロイは成功したのに動かない。動かないならなんで受け付けたんだ」ってサポートチケットも来まくるし。
同僚みたいに「エラーログを保存しといて、2回目（いや3回？4回？いややっぱ5回だ！）のエラーで、3秒間隔で表示する。ただし最後だけは10秒まで待って、その後にネットワークエラーだったらさらに2分スリープ、最後にlogger.Info(”test1”)を入れる」みたいな訳わかんないロジック追加するか、
もう「クソ食らえ」って依存関係の順序を強制するか、だよ。バカだって分かってるんだけどね…

それは同僚を教育するチャンスだし、デプロイの仕組みにもっと高度な機能を取り入れる機会だと思うな。Kubernetesがあるコンポーネントのデプロイを「成功した」って言うのと、CI/CDパイプラインがアプリ全体のデプロイを「成功した」って確認するのは違うことだよ。K8sのが前で、後者はその後、時にはかなり後になることが多いからね。上司がエラーを見てるってことは、デプロイがまだ終わってないのに、誰かか何かが終わったって falsely に伝えてるからだよ。

何だって？Kubernetesに対する一番よく繰り返される批判の一つだよ。この記事の中でさえ、このスレッド全体がその話なのに、YAMLは何回も言及されてんじゃん。

CRDの定義がインストールされる前に使ってみなよ。ハードエラーだよ。グレースフルなリトライなんてない。たまには依存順序が強制されることもあるんだ。

YAMLからHCLへの置き換えには超反対だな。HCLって開発者には分かりにくいし、読みにくいんだよ。importできるの？エラーのデバッグも大変。protobufみたいな他の言語で好きなように書けばいいじゃん。

HCLが分かりにくいって？インフラ側でHCLとかTerraformを使ってる身としては、あれはコード書けない人向けの超簡単な設定言語だと思ってたよ。JavaScriptを毎日書いてる人がHCLで迷うなんて信じられないな。Terraformでのややこしさはあるけど、Kubernetesなら問題ないでしょ。

「HCLが分かりにくい、読みにくい」っていうのは、「新しいこと覚えるのが面倒だっただけ」にしか聞こえないね。HCL自体じゃなくて、複雑な設定対象と一緒に学んだからごちゃ混ぜになってるんじゃない？

HCLのこの書き方↓見て、分かりやすいって言える？
outer { example { foo = ”bar” } example { foo = ”baz” } }
なんかTOMLの変な書き方↓思い出すわ。
[lol]<br>[[whut]]<br>foo = ”bar”<br>[[whut]]<br>foo = ”baz”
TOMLならPythonで中身確認できるけど、HCLは無理じゃんね。

問題は開発者にHCLなんて学ばせたくないってことだよ。SREがnextやreactを覚えないのと同じ。一番いいのは簡単な抽象化があって、HCLみたいないけてない新しい概念を覚えなくて済むこと。HCLを学ぶのは始まりにすぎなくて、依存関係とかの管理がマジで大変なんだ。開発者がSREのTerraformについていくのは時間の無駄。それより開発に時間を使うべきでしょ。

これは完全にユーザーに優しくないね。例↓みたいに書いても、for_eachはmapか文字列のsetじゃないとダメで、tupleはダメってエラーが出るんだよ。
variable ”my_list” { default = [”a”, ”b”] }
resource whatever something { for_each = var.my_list }

YAMLじゃなくてHCLに価値はあると思うな。最近、TerraformでAWSのサブアカウントとかEKS、Karpenterとかプラットフォーム全部立ち上げたんだけど、KubernetesのリソースもTerraformで書いたんだ。HCLで書くいいところは、型とスキーマがあること。LSP対応のIDE（GNU Emacsとterraform-ls使ってる）なら、補完も効くし、書いた時点で間違いに気づける。Kubernetes APIリファレンスとIDEを行ったり来たりしてフィールド確認する手間が省けてマジで楽だったよ。

なんで？HCLくらい学べないようなら、成功する開発者にはなれないんじゃないの。もしインフラを学ぶべきじゃないって言うなら、それはどんな言語でも同じ話でしょ（YAMLのインデント知ってるからって何書けばいいか分かるわけじゃないし）。その意見は絶対正しいわけじゃないけど、まぁ理由は分からなくもないかな。