いつも問題になるのは、その複雑さのどの部分を排除できるかってことだよね。今まで見た「k8sの抽象化」は、非常に小さなサブセットのものにしか機能しない（例えばHerokuのようなラッパー）か、最終的にはk8sと同じくらい複雑な完全なDSLを発展させる（そして今度はその仕事特有のDSLを学ばなきゃいけない）って感じだ。

常識的なデフォルトは「クラウドプロバイダーの管理サービスの顧客にさせること」と矛盾してる。k8sを見れば見るほど、ストレージやネットワーキング周りが「バッテリーなし」って感じがする。結果として、バッテリーはAWSやGCPから請求書がついてくる。k8sはオープンソースプロジェクトというより、これらの非常に儲かるギャップフィラーサービスへの依存を促す手段になってる気がする。

YAMLよりもTerraform/HCLの方が読みやすいと思うのは、目に見えない文字を処理しなくていいからだね。

追加したいのは「常識的なデフォルト」だね。これがk3sの好きなところなんだ。

Kubernetesの外からクライアントサイド（例えばkubectl）でHCL、JSON、YAMLなどを簡単に構築してシリアライズ/デシリアライズできるよ。これはKubernetes自体とは全く関係ない話だね。

これ知ってるかもしれないけど、Kubernetesのインターフェース定義はすでにprotobufなんだよ（crdを除いて）。

混乱してる？俺はインフラ側で、HCL/Terraformを使ってる時に、コードが書けない人向けの赤ちゃん向け設定言語を使ってる気分なんだ。JavaScriptを一日中使ってる人がHCLを混乱するなんて、想像できないな。はっきり言うと、HCLの構文とデータ型について話してるんだ。Terraformの処理方法は、確かに混乱することもあるけどね。でもKubernetesにはそんな落とし穴はないよ。

YAMLをHCLに置き換えるのには大反対だな。代わりに価値があると思う。最近、半日でプラットフォーム全体を立ち上げるためのTerraformコードに取り組んでるんだ（AWSサブアカウント、EKSクラスター、Karpenter用のマネージドノードグループ、Karpenterデプロイメント、Ingressコントローラー、LGTMスタック、パブリック/プライベートDNSゾーン、cert-managerなどなど）。Kubernetesリソースも含めて、すべてTerraformでやったよ。HCLでKubernetesリソース（やHelmデプロイメント）を作成するのが良かったのは、型があってスキーマがあるから、LSP（言語サーバープロトコル）に対応したIDEなら、意味のあるオートコンプリートや適切な構文チェックができるってこと。失敗するのを見ないと適用できないなんてことはないし、Emacs（言語サーバー経由）で自分が書いてることが間違ってるって教えてもらえるから、IDEとKubernetes APIリファレンスを行き来する必要がなくて助かるよ。

HCLは本当にひどいと思う。K8sのYAMLは全然問題ないよ。今までその型で解決できないユースケースに出会ったことがない。もしやりすぎてるなら、コンフィグマップが間違った選択かもね。

HCLの一番の不満は、forループの実装が嫌いってこと。あの構文、ほんとに嫌だわ。

開発者はHCLがとても混乱すると感じている。読みづらいことがある。今はインポートをサポートしているのかな？エラーはデバッグが難しいこともある。これはHCLについての問題というより、「新しいことを学ぶのが嫌だった」という感じがするし、HCLを複雑なものと同時に学ぶのが、設定言語の問題というよりは、問題領域の問題だと思う。

ちょっと挑発的な意見を言わせてもらうけど、AIの時代に設定言語についての議論は無意味だよ。もう誰も手作業でデプロイメントの設定を作らないから。AIはK8sの仕組みに必要な変な構文を生成できて、人間よりも信頼性が高いんだ。今日じゃなくても、3ヶ月後にはそうなるかも。K8s 2.0の夢を大きく描きたいなら、AIに人間の意図を解析させてデプロイメントやクラスター管理を生成させればいい。これを「バイブ設定」とでも呼んで、欲しいことを普通の言葉で説明するんだ。良いモデルなら、エッジケースについて考えて質問してくれるし、レビュー用の設定を生成してくれる。エッジローダーのオペレーターなら自動的に適用してくれるかもね。現代のコード生成はすでにその方向に進んでるから、想像しているアプリを作るためにAIとやり取りしてるんだ。バカな選択をしないように導く必要はあるけど、全ての機能を手作業で作るわけじゃない。「4つのポッドをアンチアフィニティで、ローリングデプロイメント、既存のPostgresポッドに接続して、CPU使用率に基づいてオートスケーリングしたい」とAIに言って、あとは自分の生活を楽しめばいい。それが私たちの進むべき道だよ。このコメントがどんな反応を引き起こすか、心の準備はできてるから、遠慮なくどうぞ。賛否両論の意見を聞きたいんだ。

HCLだけはやめてほしい。TerraformでHCL使うと頭痛がするんだよ。

ある意味、状態が二重に存在するのは冗長だよね。Kubernetes自体とTerraformの状態で。それが、リソースがミューテーションWebhookやそれに類似したもので変更されると問題を引き起こすことがある。だから、プロパティを「計算フィールド」とかにマークする必要があるんだ。TFを使ってアプリケーションを管理するのはあまり好きじゃないな。でも、クラスターの管理は大丈夫かも。

Kubernetes自体は、たくさんの抽象化のレイヤーがあるんだ。ポッドがコアの新しいアイデアで、これは素晴らしいけど、デプロイメントやレプリカセット、ネームスペースもあって…Docker Swarmを使えたらいいのにって思う。Terraformも一層のシンプルさで、比較的学びやすかった。今、K8sを学んでる真っ最中だから、その難しさはよくわかってるよ。

プログラムの種類の違いは人間の構築物だっていう問題だと思うようになった。人間的には君に同意するよ。オペレーターやコントローラーは、ある意味でCOMやCORBAを思い出させる。彼らは非常に抽象的で、設計において判断（や誤判断）を許すほど柔軟なんだ。シンプルな実装には、もっと意見がはっきりしていて柔軟性が少ないk8s-liteが欲しいな。自分の足を撃つようなことが少なくなるものがいい。だけど、非常に複雑な実装には、既存の抽象化が制限に感じることもある。時には、単一のクラスターがセルラーアーキテクチャのセル境界の基盤になる理由があるんだ。Kubernetes 2.0や他の何かが、問題空間の全ての複雑さを包含しつつ、人間のアーキテクトやプログラマーが扱いやすいものになれるのか、時々疑問に思うよ。

わぁ…すごいね、ライブマイグレーションはとても興味深い。今は価格に基づいてクラウド間でオートスケーリングをしてるけど、実際のライブマイグレーションは別の話だね。

• グローバルに分散 これは必須じゃないの？
• Tailnetをデフォルトのネットワークスタックに それは、もし使うことになったら真っ先に取り外したいものだね。Kubernetesが基盤のホストが単一のNICしか持ってないと仮定するのは、業界にとって悪夢で、約20年も遅れを取らせて、クラウドで動いてない人たちをペナルティしてる。複数のCNI実装があってよかった。最近になってMultus（https://www.redhat.com/en/blog/demystifying-multus）で、インフラのその部分に少しは常識が戻ってきたみたい。
• 最初からマルチテナント対応 これがKubernetesとどう違うの？
• Bittorrentをデフォルトのストレージスタックに 面白いかもしれないけど、もしパブリックコンテナイメージをシードすることも意味してるなら、エグレストラフィックがめちゃくちゃ高いから注意が必要だね。

これはKubernetesじゃなくて、GPUを動かすためのカスタムソリューションだよ。

へへ、これ見てなかったんじゃない？このディレクトリね。https://github.com/agentsea/nebulous/blob/v0.1.88/deploy/cha... それに、お願いだからこんなことは絶対にやらないでほしい、ほんとに。https://github.com/agentsea/nebulous/blob/v0.1.88/deploy/cha...

この意見、すごく嫌いなんだよね。しかも、これをよく見る。年取ってるし、ちょっと冷めちゃってるから仕方ないけど… 誰かが「X技術は重すぎる」って言って、シンプルにノートパソコンで動かしたいって思うんだよね。「そんな余計なものはいらない」って。で、時間とリソースを使ってY技術を作り出す。Y技術が人気になって、人々がそれに追加してスケールできるようになる。だって、誰もノートパソコンで本番環境を動かさないから。別の誰かが来て、「ああ、Y技術は重すぎる、こんな余計なものはいらない…」って言うんだ。「時の車輪には始まりも終わりもない。しかし、それは始まりだった。」

Kubernetesが解決する問題は「これをどうデプロイするか」なんだ。だからRivet（見た目はクールだね）のドキュメントを見に行くと、選択肢は以下の通り。* シングルコンテナ * Docker Compose * 手動デプロイ（docker runコマンドを使って） でも、現実的にこれが「サーバーレスインフラストラクチャプラットフォーム」を実際の規模でデプロイするのに viable な方法なの？直感的には、RivetをKubernetes上でデプロイするにはどうするか、コンテナかkube-virtみたいなもので物理/仮想マシンの上でこのサーバーレスプラットフォームを動かすかって思う。Docker ComposeがKubernetesよりも良い、信頼性が高くスケーラブルな代替手段なの？それとも、クラウドサービスを売るってこと？でも、それはKubernetes 2.0じゃないよね。もしRivetをセルフホストするつもりなら、ドキュメントをKubernetesで動かせるように変えるよ。

私の経験では、インフラやオペレーションに関しては「ただ動く」ものはないよ。Herokuのようなものでもスケーリングの問題に直面するし、どれだけお金を払うかによっても変わる。もし人々が求めているのが簡単に採用できるデプロイメントプラットフォームなら、Kubernetesを人々が望むPaaSの基盤として理解するのがいいと思う。そうは言っても、Rivetは面白そうだね。BEAMエコシステムのいくつかのアイデアを認識しているよ。私にとっての魅力は、スケールでのデプロイよりも、レジリエンスやローカルファーストに関係していることが多いかな。

標準的なシンプルなモノリシックアプリを作るエンジニアとしてのニーズには、全てをこなせるシステムは要らない。できるだけシンプルに数個のサービスをホストできる能力から始めたい。ここではHerokuやRenderレベルの複雑さが欲しい。データベースを立ち上げて、シンプルなスケーリングルールのウェブワーカーやバックグラウンドワーカーを用意する感じ。デザインが完璧になったら、他に何か追加できるか見てみて。高メンテナンスで理解不能になるなら、無理にやらなくていい。それがシンプルなアプリをホストする最高の方法として永遠に愛されることになるから。

それは全然違うよ。タロスを立ち上げて、10分くらいでNノードのクラスターが作れるんだから。9分はダウンロードや設定待ちで、実際の設定は1分。こんなに簡単なんだよ。

もしk8sをサービスとして使っていて、クラスターメンテナンスを全部外注してるなら、どの部分が特に複雑だと思う？設定や仕様は広範だけど、サービスを本番環境に投入するためには、そのごく一部だけ知ってればいいかも。k8sへのデプロイは、docker-composeよりちょっと複雑な設定でできるよ。とはいえ、多くのアプリにとっては、その「ちょっとだけ」すら不要かもしれないし、実際に求められてたのはdocker-composeだったんだよね。docker-composeが持続的な支持を得られなかったのは残念だな。

私たちはいくつかのAKSクラスターを運用してるけど、ちゃんと動いてるよ。自動更新以外のメンテナンスはほとんどやらない。コンテナは24/7で問題なく動いてるし、すごく驚きだよ。

それは全然違うよ。k3s（k8sにはいくつかの落とし穴があるけど）クラスターの維持はとても簡単だし、適切なエビクションルールさえあればk3sの自動アップグレードもあるからね（ポッドの中断があるかもしれないけど）。Cephはちょっと難しいけど、レモンやロングホーンを選べばほぼメンテナンスフリーだよ。数千のヘルムチャートがあって、最も複雑なデータベースでも1分以内にデプロイできる。人気のヘルムテンプレートを使えば、自分のサービスをデプロイするのもすごく簡単だよ。ヘルムは完璧じゃないけど、自分のやりたいように設定すればすごく便利。例えば、アプリケーションのデータベースとアプリ自体を一つのヘルムチャートにまとめた「デプロイメント」チャートを持ってるから、values.yamlのコード補完もバッチリ。多くのサーバーレスプラットフォームのように、簡単にKubernetesに飛び込むことはできないけど、実際の本番環境で数十万を節約するために一週間頭を悩ませるのは、私にとっては明らかに無駄じゃないよ。

俺が見たいのは、容量を追加するのがプラグ＆プレイなやつだな。機械をネットワークに接続して、起動したら自動的にファームのUIにノードとして現れるみたいな。USBメモリをPCに挿すとストレージが増える感じで。

「すべき」と言うけど、それは自分のソフトウェアスタックを社内で作るときにはいいけど、Kubernetesで動くソフトウェアはどれだけあるの？それが存在する前に作られたものもあるよね。でも、誰かがそれがDockerで動くことを見つけて、その後、Dockerで動くからKubernetesでも簡単に動かせるって気づいたんだよね。自分が考える最適な方法で物事をやるプラットフォームを作ることはできるけど、結局人々は自分たちのやり方でやって、悪い結果になることもある。あるいは、いろんな方法で動くように機能を追加して、人々に使い方を選ばせることもできる。

Kubernetesの主要なイディオムの一つはループだね。実際、Kubernetesを使っていると、Kubernetesの主なアーキテクチャ的特徴は「調整ループ」だと思う。現在の状態を観察して、望ましい状態との差分を取り、その差分を適用する。これを何度も繰り返すんだ。「失敗」や「成功」の状態はなくて、観察できることと、観察したいことだけがある。その二つの違いは繰り返し解消されるんだ。機械制御の「十分な技術」であるPIDフィードバックループが、Kubernetesのこのコアコンポーネントにかなり似ているのは面白いと思う。

依存関係の失敗は回復可能であるべきってのには大賛成。実際に使ってない依存関係が原因で発生した障害に巻き込まれたことがあるよ。サーバー間の依存関係はほとんどがソフトなものだから、下流の依存関係と通信できないなら500を返せばいい。負荷分散装置に不健康なサーバーを避けさせればいいんだ。

YAMLはJSONのスーパーセットだよ。だから、YAMLをサポートしているものはもちろんJSONもサポートしてる。

Kubernetesの主要な考え方の一つはループなんだ。依存関係が利用できない場合、アプリはそれを回復可能なエラーとして扱って、依存関係が利用可能になるまで再試行することになってる。これ、バカみたいに聞こえるかもしれないけど、最初のエラーをログで見た人がパニックになるんだよね。あるいは、部門のトップがデモを見て「めっちゃいいね。でもデモする前に、そのエラーを消して」って言うこともある。そしたらどうする？それとも、サポートチケットを開いて「デプロイ時にエラーは出なかったのに、動いてない。動かないなら、なんで受け入れたの？」って言う人もいる。俺の同僚の一人は「エラーログを保存して、2回（いや、3回、4回？いや、5回）発生した時だけ表示する、間に3秒の遅延を入れて、最後のやつは最大10秒かかる。もしこれがネットワークエラーなら、さらに2分待って、最後にlogger.Info("test1")を入れる」っていう変なロジックを追加するか、「もういいや」って言って依存関係の順序を導入するかだよね。バカだって分かってるけど…。

2年以上、Hetznerでk3sを運営して100%の稼働率を保っているよ。実際、メンテナンスがほとんどなかったから、マスターノードのSSHキーを失くしちゃって、クラスター全体を再プロビジョニングしなきゃいけなかったんだ。ドキュメントの更新にかかった時間も含めて、約90分かかったよ。もし重要だったら、15分以内にできたと思う。k3sを使ったk8sクラスターが月20€、ARM専用で、ノード3つ、マスター1つ、ストレージとCloudflareの自動DNS付きのロードバランサーがあるよ。

「低メンテナンス」は他の選択肢に対して相対的なものだよ。私の経験では、K8sを扱っているときは、同じサービスの質を得るために必要なメンテナンスがずっと少なかった（[自動]スケーリングからフェイルオーバー、デプロイ、ロールバック、ディザスタリカバリー、DevOps、完全に独立したクラスターを立ち上げるのがどれだけ簡単かまで）それに比べて、K8sを使わない場合はね。人それぞれかもしれないけど。

自業自得な感じだね。そんなに色々インストールするのやめなよ。追加するものは全部技術的負債になって、コストがかかるからね、たとえその製品が無料でも。オートスケーリングが技術的負債やメンテナンスの負担よりもお金を節約できないなら、オフにしちゃえ。

大体同じサービスを組み合わせて動かすのは、メンテナンスがめちゃくちゃ楽で、ほったらかしでも大丈夫なレベルだよ。ただ、何をしてるか分かってないと、「かっこいいウィジェットをインストールする」罠にはまっちゃうから気をつけて。

あなたが話してるのはKubernetesのメンテナンスじゃなくて、CI/CDシステムやシークレット管理システム、データベースを操作するための自動化のメンテナンスについてだよね。昔はYAMLファイルを編集する代わりに、ソフトウェアベンダーがcronジョブやansibleプレイブック、systemdユニット、bashスクリプトのメンテナンスを頼んできたもんだ。

基本的な緊張感は、実際にサービスを運用するのは複雑で、より良い抽象化で隠したり避けたりできないってことだよね。だから、選択肢はその複雑さに対処する（k8sの場合）か、誰かにやってもらう（「コードをアップロードするだけ」なサーバーレスプラットフォームの一つ）かのどちらか。オペレーションの人を隠すことはできるけど、彼らを完全に排除することはできない。それがみんなが求めてることみたいだね。

何をするかによるね。シンプルなウェブサーバーを運用したいだけなら、名前付き/シンプソンサーバーの群を運用するよりも確実にメンテナンスは楽だよ。でも、そうするともっと色々やりたくなってくる。RDSをやめて、クラスター内でDBを運用するようになったり。パイプラインを手動でチェックするのをやめて、自動スケーリングを実装したり。無料ではないし、誰もそんなことは言ってないけど、他のシステムでメンテナンス負担が少ない状態でやれるかって言われると、疑わしいな。結局、サービスを運用するにはメンテナンスが必要だけど、以前よりは少なくて、多くの負担が多くのサービスに分散されてるはず。だけど、ちゃんと監視は必要だよ。手動でスケーリングするのに時間をかけてるなら、自動スケーリングを実装しない方がいい。そうしないと、新たに維持すべきものが増えて、何のリターンもないから。