親愛なる友よ、君は Kubernetes を作ってしまった

• 友人への手紙

  • Kubernetes を避けようとしていたのに、結局は似たようなシステムを作ることになった経緯を説明する内容。
  • 友人は「退屈な技術」を選び、シンプルなコンテナ実行を望んでいたが、結局は複雑なスクリプトや設定によって問題が発生した。
  • Docker Compose に切り替えてもすべての問題を解決できるわけではなく、デプロイ、ローリングアップデート、ロールバック、スケーリングのために別のソリューションが必要だと気づく。

• サーバー拡張とネットワークの複雑性

  • 2 台目のサーバーへ拡張する必要性を感じるようになる。
  • Tailscale のようなオーバーレイネットワークを使ってサービスディスカバリを試みる。
  • ネットワークの複雑さを解決しようとするが、結局はさらに多くの問題に直面する。

• 保守と自動化

  • スクリプトを作った本人が休暇に入ったり退職したりしたら、複雑な設定や文書化されていない設定変更を誰が管理するのか、という疑問が生じる。
  • カスタムスクリプトの保守問題を解決するため、Ansible を使って VM をイミュータブルかつバージョン管理可能にする。
  • Kubernetes を使わないのだから、より簡単に保守できるはずだと考える。

• コンテナ生成とセキュリティの問題

  • プログラムから別のコンテナを生成する必要が出てくる。
  • Docker ソケットを Web アプリにマウントするのはセキュリティ上危険なため、それを解決するための別サービスを書く。
    • Docker API の安全な部分だけを公開する別サービスを書いて問題を解決する。

• 結論

  • 結局、自分たちは Kubernetes に似たシステムを構築していたのだと気づく。
    • 標準の設定フォーマット、デプロイ方法、オーバーレイネットワーク、サービスディスカバリ、イミュータブルノード、API サーバーを含む複雑なシステムが完成する

• PS

  • Kubernetes を置き換えるより良いソリューションが存在する可能性を否定するものではない。
  • ただし、Kubernetes を複雑だと決めつける前に、それが解決しようとしている問題を十分に理解することを勧めている.

[savvykang]

デプロイの引き継ぎを解決するためにKubernetesを導入するという話は、あまりよく理解できませんね。

[kandk]

保守と自動化がコードレベルで容易に行えます。
Infrastructure as Codeも可能です。

[savvykang]

EKSのようなマネージドk8sサービス環境では、ロードバランサーもあり Route 53 との連携も可能ですが、セルフホスティングのk8sはロードバランサーの実装もなく、DNS連携もかなり限定的なんですよね。k8s運用チームが別にある会社では、おっしゃるような利点が実際に成り立つのかもしれません。

ぱっと聞くと悪くないソリューションに見えますが、実際に使ってみるとあらゆる状況で動くわけではありません

[kandk]

k8sの運用チームがなくても使いやすいです。EKSを使えば大丈夫です。

[savvykang]

ソースコードさえ渡せば引き継ぎは終わりだという主張と同じではないでしょうか？ 業務マニュアルと業務遂行の履歴は、やはり依然として必要だと思います。

[kbumsik]

Infra as Code 自体、ソースコードさえ渡せば終わらせるためにあるものではありますよね。
もちろん、どんなコードでも同じように基本的なドキュメント化はされているべきですが。

[kandk]

ソースコードがよく書かれていて、ドキュメントがしっかりしていれば可能です。
業務マニュアルや業務遂行の履歴が別にあれば役に立つでしょうが、それはこの記事とは別の話のようですね。

[GN⁺]

Hacker Newsの意見

• 複数の会社でシェルスクリプトを使ってデプロイを成功させた経験がある

  • 2つのPHPサービスで1日10億件以上のリクエストを処理し、サーバーにファイルを転送してマイグレーションを実行することで、ダウンタイムなしのデプロイを行った
  • 退職口座のようにウェブスケールを必要としない業界では、Jenkins経由でDockerコマンドを使ってデプロイを行った
  • テスト環境を数分以内に必要に応じて利用できた
  • 現在の会社はKubernetesの導入を進めようとしているが、複雑さのために苦労している

• KubernetesではYAMLファイルを管理するために2〜3人の専任担当者が必要になる

  • クラウドプロバイダーを選べば複雑な部分を解決できるが、追加コストが発生する
  • YAMLファイルは人が書くものではなく、ツールが生成すべき設定ファイルである
  • ほとんどのウェブサイトやサービスにKubernetesは必要ない

• 単純なものが脆弱だという考えは誤りである

  • YAMLファイルやKubernetesの複雑さを理解してデバッグするほうが難しい
  • Kubernetesの代替としてはシェルスクリプトがある

• Kubernetesが必要ない場合もある

  • EC2インスタンスと簡単なシェルスクリプトだけで10万人以上の同時ユーザーを処理できる
  • 問題がないなら、あえて変更する必要はない

• シェルスクリプトでiptablesルールやsysctlの編集を簡単に管理できる

  • ワークキューを使えば、コンテナをプログラムで生成する代わりにジョブをプッシュできる

• Kubernetesを批判するのは非専門的だ

  • GoogleやNetflixのような大規模アプリケーションでないなら、単純なスクリプトを書いたほうがよい

• 自前システムの制約はすべてコストであり、汎用ソリューションの柔軟性はすべて利点であるという前提は誤りである

  • コードベースで似たようなパターンに従い、サービスが同じ方法でデプロイされることを望んでいる

• Kubernetesの問題は、無数のオープンソースライブラリがシステムを理解しにくくし、バグを引き起こすことだ

• Kubernetesの学習曲線を乗り越えた人たちは、複雑さはそこまでひどくないと言う

  • 開発者にKubernetesを教える講義は30分ほどで済み、Helmチャートを書けるようになる