Kubernetesを嫌う人のためのガイド

 (paulbutler.org)
31 ポイント 投稿者 GN⁺ 2024-03-04 | 1件のコメント | WhatsAppで共有

Kubernetesに対する批判的ガイド

  • Kubernetesは一部の技術者の間で、不必要に複雑で時間の無駄だという評判を得ており、小規模なチームで使うのは過剰設計だと見なされている。
  • Jamsocketでは数年間にわたりKubernetesを本番環境で運用し、必要な機能だけを使って残りは無視する形で、効率的な使い方を見つけた。

Kubernetesを使う理由

  • Kubernetesは、次の3つをすべて求めるときに最もよく踏み固められた道である。
    • 複数のプロセス/サーバー/スケジュール済みジョブを実行したいとき。
    • それらを冗長化して実行し、負荷分散したいとき。
    • それらの設定や相互関係をコードで構成したいとき。
  • Kubernetesは、コンピュータのプールを1台のヘッドレスコンピュータのように扱える抽象化レイヤーである。
  • Jamsocketは1日に何度もデプロイしており、製品に問題が起きると顧客の製品にも影響が及ぶため、ローリングデプロイによって頻繁にデプロイできる自信を得ている。

Kubernetesの使い方

  • Jamsocketは、Webアプリと通信できる動的プロセスを生成するサービスで、AWS Lambdaに似ているが、プロセスの寿命は単一のリクエスト/レスポンスではなくWebSocket接続に依存している。
  • Kubernetesは、APIサーバー、コンテナレジストリ、コントローラー、ログ収集基盤、一部のDNSサービス、メトリクス収集など、長時間稼働するプロセスの運用に使われている。
  • Kubernetesを使わないもの: 一時的なプロセス、静的/マーケティングサイト、直接データを保存するもの。
  • Google Kubernetes Engineを使ってKubernetesの管理を外部に委ねており、必要であればAmazon EKSへの移行も比較的容易である。

積極的に使っているKubernetesリソース

  • Deployments: ほとんどのPodはデプロイメントを通じて作成される。
  • Services: 内部サービス向けにClusterIP、外部サービス向けにLoadBalancerを使用。
  • CronJobs: クリーンアップスクリプトなどのために使用。
  • ConfigMapsとSecrets: 上記リソースにデータを渡すために使用。

慎重に使っているもの

  • StatefulSetとPersistentVolumeClaimは使っているが、重要なデータはKubernetes外部のマネージドサービスに保存することを好んでいる。
  • RBACは複雑さを増すため、可能な限り避けている。

積極的に避けているもの

  • 手作業でのYAML記述: TypeScriptとPulumiを使ってKubernetesリソース定義を生成。
  • 非標準リソースやオペレーター: サードパーティ製ソフトウェアがKubernetesのインフラを利用できるようにするが、実際には扱いにくい。
  • Helm: オペレーターとYAMLの規約のため使わない。
  • 名前に"mesh"が入っているものはすべて: 必要ないと判断している。
  • Ingressリソース: 不要な間接層を増やすのを避ける。
  • 完全なk8sスタックをローカルで再現すること: Docker Composeや独自スクリプトを使い、必要なシステムの一部だけを起動する。

人がPodを待つべきではない

  • Kubernetesは、コンテナの起動時間よりも堅牢性とモジュール性を重視して設計されており、人がPodの起動を待つようなケースには向いていない。
  • Jamsocketは、MITライセンスのRustオーケストレーターであるPlaneを使って、対話型ワークロード向けのプロセスを高速にスケジューリングして実行している。

より高水準の抽象化

  • Kubernetesの代替手段の中には非常に優れたものもあり、特にインフラをコードとして定義する必要がない場合に有用である。
  • Railway、Render、Flight Controlのようなサービスを使い、Kubernetesの代わりに別のソリューションを選ぶこともできる。
  • Kubernetesへのアプローチを体系的に管理しているなら、誰にも早すぎるとは言えない。

GN⁺の見解

  • Kubernetesは、特に大規模システムにおける複雑性の管理と自動化に強力なツールである一方、その複雑さは小規模なプロジェクトやスタートアップにとって負担になりうる。
  • この記事は、Kubernetesを使う際に生じうる過度な複雑さを避ける方法を示すことで、初心者や小規模チームでもKubernetesの利点を活用できるよう助けている。
  • Kubernetesを使う前に、本当に必要な機能とチームの技術的力量を考慮し、管理の複雑さやコストに見合う利点があるかを慎重に評価すべきである。
  • Kubernetesの代わりに、よりシンプルで管理しやすいサービスを使う方が良い場合もある。たとえばDocker Swarm、Apache Mesos、Nomadなどがあり、それぞれに長所と短所がある。
  • Kubernetesを導入する際には、既存インフラとの統合、セキュリティ、運用コスト、そして学習曲線などを考慮する必要がある。
  • Kubernetesを選ぶことで得られる利点は、スケーラビリティ、高可用性、そして多様なクラウド環境における一貫したデプロイ体験である。ただしそのためには、必要なリソース管理とオーケストレーションへの理解が求められる。

関連記事

1件のコメント

 
GN⁺ 2024-03-04
Hacker Newsのコメント

  • 1つ目のコメントの要約:

    • Kubernetesのような複雑なシステムを導入すると、その複雑さがさらに拡大し続け、さまざまなコンポーネントが相互に補強し合い、不可欠なものと見なされるようになる。
    • クラウドが初めて登場したとき、人々はロードバランサーやデータベース管理の複雑さを減らせる点に魅力を感じていた。
    • ステートレスなアプリサーバーは大きな保守上の問題ではなかったが、マイクロサービスを推し進めることで、それまで存在しなかった問題を生み出した。
    • 今ではこの文化が定着しており、マイクロサービスが必須だという主張に軽々しく同意するのは難しい。

  • 2つ目のコメントの要約:

    • 中小企業にKubernetesを導入している立場として、不満を持つエンジニアもいたが、大半は満足していると答えた。
    • Kubernetesは複雑だが、複雑な問題に適したツールである。
    • 標準があることは、文書化されていない単純な混沌よりもましであり、kubectl explain XはAWSのドキュメントよりはるかに優れていると主張している。
    • Kubernetesは複雑ではあるものの、開発者にとっては前職で使っていたのと同じように動作し、速度が重要である。

  • 3つ目のコメントの要約:

    • Kubernetes批判は流行しているが、それでもなお最良のソリューションである。
    • インフラを宣言的に定義でき、ロードバランシング、自動復旧、スケーリングを提供する。
    • スタック全体に優れた可観測性を提供し、事前パッケージ化されたソフトウェアも多数利用できる。
    • クラウド、自前サーバー、ローカル環境でほぼ同じインフラを構築できるため、特定のクラウドプロバイダーに縛られない。

  • 4つ目のコメントの要約:

    • Kubernetesの大きな利点はHelmやOperatorsにある。
    • 複雑性のコストを払うのであれば、インフラコンポーネントの「アプリストア」と、運用をプログラム的に管理できる利点を得るべきである。
    • たとえばCephのような複雑なものを設定するなら、Rookは良い方法である。
    • HelmやOperatorsはインフラを管理された「ターンキー」アプライアンスにするわけではないが、宣言的インターフェースのほうが一般に管理しやすい。

  • 5つ目のコメントの要約:

    • Kubernetesは優れた技術だが、その複雑さのために保守担当者が会社のヒーローになりがちである。
    • 多数の調整項目やレバーによって、プロジェクトの本来の目標からそれてしまうことがある。

  • 6つ目のコメントの要約:

    • 現在の会社では、KubernetesとAnsibleベースのカスタムデプロイシステムに分かれている。
    • Ansible方式もうまく機能しているが、Kubernetesへ移行すればデプロイ時間を数時間から数分へ短縮でき、より速く効率的にオートスケーリングできる。
    • Helmデプロイ失敗の原因特定の難しさや、新しい運用方式を学ぶ必要があることなどが、以前のチームから一貫して聞かれたフィードバックである。

  • 7つ目のコメントの要約:

    • 元Googleのサイト信頼性エンジニアとの会話では、実際にKubernetesを必要とする会社はごくわずかだという。
    • 多くの人は流行に乗って開発する傾向がある。

  • 8つ目のコメントの要約:

    • Kubernetesが正しいツールである場合もあるが、必要悪として受け入れるべきである。
    • 複数の当事者の失敗によって協調に失敗しうるソフトウェアは、しばしば問題を引き起こす。

  • 9つ目のコメントの要約:

    • YAMLを直接書くことは問題になりうるため、代わりにTypeScriptとPulumiを使ってKubernetesリソース定義を生成している。
    • YAMLをlintする代わりに、完全なプログラミング言語ランタイムとサードパーティライブラリを導入し、バージョン管理やプロジェクトのコンパイルといった追加の複雑さを受け入れている。

  • 10つ目のコメントの要約:

    • Kubernetesに情熱を持っていた者として、Kubernetesの良い部分は基本要素（Deployment、Service、ConfigMap）であり、それ以外は特別な状況でのみ使うべきだとしている。
    • チームは、設定を明確で分かりやすく保つために、生のYAMLを書いてkustomizeを使うことを好んでいる。