Kubernetesは常に正しい選択ではない

著者: ラク・シヴァ

編集：ノエ

現在では、ほぼすべてのアプリケーションをコンテナにパッケージ化して実行できます。コンテナは多くの問題を解決しますが、新たなオーケストレーションの課題も生み出します。クラウドネイティブ アプリケーションの構築に取り組むチームの間でコンテナ オーケストレーションの需要が高まり続ける中、Kubernetes はこの課題に対処する強力なツールとして人気が高まっています。

適切に管理された Kubernetes 環境で構築すると、自動スケーリング、自己修復、サービス検出、負荷分散など、多くの利点が得られます。ただし、Kubernetes の世界を受け入れるということは、多くの場合、コンテナ オーケストレーション テクノロジーを採用する以上のことを意味します。チームは戦略的に考える必要があります。「Kubernetes は自分にとって正しい選択だろうか?」彼らは、この広範な質問のいくつかの要素を評価することによってこれを実行する必要があります。

1. 私のチーム構成は Kubernetes に適していますか?

Kubernetes (K8s) の機能を称賛する記事は数多くありますが、これについてはここで議論するつもりはありません。多くの場合、K8s が適切な選択です。ただし、K8s との直接的なやり取りやメンテナンスは、すべてのチームやプロジェクトに適しているわけではありません。

1. クラウドネイティブ アプリケーションを持つ小規模スタートアップ: これらのチームにとって、Kubernetes の直接管理は複雑で時間がかかり、製品のリリースと拡張という目標の達成を妨げるものとなります。チームの規模を考えると、アプリケーションの開発と並行して Kubernetes クラスターを管理するには帯域幅が足りません。

2. さまざまなアプリケーション タイプを持つエンタープライズ チーム: Kubernetes は、専門的なスキルを持つ大規模なチームに適しています。ただし、完全に管理されたコンテナ ランタイムまたは Kubernetes-as-a-service の提供も検討する必要があります。これらのサービスにより、限られた DevOps リソースをチームの生産性、開発者のセルフサービス、コスト管理、その他の重要なプロジェクトに集中させることができます。

3. DevOps 文化を持つ中規模企業: これらのチームは Kubernetes への移行に対してより準備が整っていますが、これは既存のワークフローを混乱させる大規模なプロジェクトです。同様に、マネージド サービスでは、多額の投資を必要とせずに Kubernetes の多くのメリットを活用できます。

4. ソフトウェア コンサルティング: これらのチームは適応性が高いですが、Kubernetes に依存すると、コンサルティング会社が最適ではない場合でも Kubernetes を推奨することになり、さまざまなニーズを持つクライアントへのサービス提供能力が制限される可能性があります。

2. プロジェクトはどれくらい複雑ですか? K8s はやりすぎでしょうか?

K8s が要件の一部を満たしているかどうかを判断するのではなく、Kubernetes の機能とうまく一致しない、または不必要な複雑さをもたらす特定の機能と要件を特定することを検討してください。

1. 最小限のスケーラビリティ ニーズ: プロジェクトのトラフィックが一貫して低い場合、または大幅なスケーリング要件がなく、予測可能で安定したリソース ニーズがある場合、Kubernetes は不要なオーバーヘッドを導入します。このような場合、ホストされたコンテナ ランタイムまたは仮想プライベート サーバー (VPS) ソリューションの方が価値が高いことがよくあります。

2. シンプルなモノリシック アプリケーション: プロジェクトが依存関係が限られたモノリシック アプリケーションであり、独立してスケーラブルなサービスや非常に多くのインスタンス数を必要としない場合、Kubernetes はニーズに対して複雑すぎます。

3. 静的または制限されたインフラストラクチャ: プロジェクトのインフラストラクチャが小規模または静的で、リソース使用量があまり変化しない場合は、ホスティング サービスや VPS などのよりシンプルな展開オプションで十分な場合があります。

4. 開発および運用リソースが限られている: Kubernetes ではコンテナ オーケストレーションの専門知識が必要ですが、DevOps リソースが限られているプロジェクトや、Kubernetes の学習に投資する意思のないチームでは実現できません。コンテナの利点は、追加投資をしなくても実現できます。

5. プロトタイピングと短期プロジェクト: 開発ライフサイクルが短いプロジェクトや運用期間が限られているプロジェクトの場合、Kubernetes のオーバーヘッドは正当化されます。

6. プロジェクトコストの制約: プロジェクトの予算制約が厳しい場合、Kubernetes クラスターのセットアップと保守にかかる追加コストは実現不可能になります。これは、仕事を遂行するために必要な高度なスキルを持つチームメンバーのコストを考慮すると特に当てはまります。

7. インフラストラクチャの要件: Kubernetes はリソースを大量に消費するため、効果的に実行するには強力なインフラストラクチャが必要です。プロジェクトが中程度のリソース要件を持つ小規模または中規模のプロジェクトである場合は、マネージド サービスまたはサーバーレスを使用する方が適切です。

要件の複雑さだけでは、Kubernetes がチームにとって最適か過剰かはわかりません。ただし、どちらか一方に傾くのに役立ちます。 Kubernetes を直接使用しても、本質的には製品が改善されることはありません。むしろ、その強みは、製品が成長できる回復力のあるプラットフォームを構築することにあります。

写真

その結果、自分の仕事を製品に従属させることにコミットするにつれて、製品に関する作業はビジネスの基盤からさらに遠ざかってしまいます。

これにより、真の疑問が浮かび上がります。私たちはプラットフォームを構築しているのか、それとも市場投入までの時間を短縮し、コアビジネス目標に対してより迅速な ROI を提供するために取り組んでいるのか?

3. 必要なスキルはありますか?

Kubernetes は、学習の過程が困難であることがよく知られています。この複雑さの原因は何でしょうか?わかりやすくするために、スキル向上に必要な労力を測るのに役立つ特定の基準に基づいたトピックのリストを作成しました。

注: これらの複雑さのレベルは、個人の背景やこれまでの経験によって異なります。

必要な専門知識や学習時間が不足しているチームの場合、開発と展開のプロセス全体が手に負えなくなり、遅くなる可能性があります。これは、スケジュールが厳しいプロジェクトや小規模なチームにとっては健全ではありません。

4. コストへの影響はどの程度ですか?

Kubernetes 自体はオープンソースで無料ですが、実行は無料ではありません。サーバー、ストレージ、ネットワークのコストや隠れたコストなど、インフラストラクチャに関連する費用を考慮する必要があります。

最初の隠れたコストは、管理とメンテナンス、つまりチームのトレーニング、トラブルシューティング、システムのメンテナンス、内部ワークフローとセルフサービス インフラストラクチャのメンテナンスに費やされる時間とリソースです。

さまざまな理由から、本格的な Kubernetes 環境のコストを計算する際に、この作業に必要な高度なスキルを持つスタッフの給与を見落としている人が多くいます。完全に管理されたサービスやサーバーレス サービスとセルフマネージド Kubernetes との比較には多くの欠陥があるため注意してください。多くの場合、Kubernetes での時間の損失に関連するスタッフコストと機会コストが考慮されていません。

2 番目の隠れたコストは、Kubernetes エコシステムに関連しています。 Kubernetes の世界を受け入れるということは、多くの場合、コンテナ オーケストレーション プラットフォームを導入する以上のことを意味します。それは、豊富な機能と、さまざまなベンダーの補助ツール、サービス、製品の全宇宙を備えた広大な大陸に足を踏み入れるようなもので、最終的には他のコストも発生します。

V. 結論

優れたツールとは、その誇大宣伝や人気ではなく、どのように問題を解決し、エコシステムに適合するかが重要です。クラウドネイティブ アプリケーションの世界では、Kubernetes が話題の中心を占めていますが、それは当然のことです。ただし、OpenShift、Docker Swarm、または Nitric などのフレームワークによってオーケストレーションされるサーバーレスおよびマネージド サービスなどのソリューションを通じて実装されるさまざまなアプローチのトレードオフをチームで検討することをお勧めします。

オリジナルリンク: https://thenewstack.io/kubernetes-isnt-always-the-right-choice/