Kubernetes を使用する理由は何ですか?サーバーではなくAPIに重点を置く

このブログでは、発生する可能性のある複雑さを最小限に抑えながら、Kubernetes の API に焦点を当てて、Kubernetes の可能性を最大限に引き出す方法について説明します。 Kubernetes を活用する方法と活用できるかどうかを学びます。

「なぜ Kubernetes なのか?」からの翻訳サーバーではなく API に焦点を当てます。ティボ・ベイエン著。

2023 年から 2024 年に移行する今こそ、振り返るのに良い時期です。間違いなく、昨年の最大の話題の一つは AI の台頭でした。しかし、私の日々の仕事にもっと近いところでは、いくつかの出来事が際立っています。

サーバーレス マイクロサービスから「モノリシック」への移行に関する Amazon Prime のブログ投稿。その後、多くの生ぬるいクリックベイトや「私の技術スタックはあなたのものより優れている」といったタイプの議論が続きました。このテーマに関する必読記事と避けるべき記事をいくつか選びましょう。まずは Jeremy Daly によるこの記事から始めましょう。

ソーシャル メディアはソーシャル メディアです。Kelsey Hightower 氏が述べたように、「Kubernetes が単独で業界を 10 年後退させた」ことを含め、ほぼすべての技術トピックについて議論が交わされます。あるいは、37signals がクラウドから撤退し、Kubernetes を回避する動き。

Datadog の停止。これはさまざまな要因によって引き起こされますが、Kubernetes、Cilium、eBPF、Systemd、OS アップデートというキーワードでまとめることができます。 Gergely Orosz (The Pragmatic Engineer) がこれを非常にわかりやすく説明しています。

Kubernetes を使い、愛し、そして上記のすべてを読むと、「自分は何に巻き込まれたのか」という疑問を振り返るのは簡単です。あるいは、もっと広い意味では、「私たちの業界は何に関わっているのか？」

私の意見では、Kubernetes の価値とコストに関する議論は、「サーバー vs. サーバーレス」や「シンプル vs. 複雑」を超えるべきです。焦点を当てるべきなのは、Kubernetes の利点がそれがもたらす課題を上回り始める時期 (その時点が来ると仮定した場合) です。

それでは、今日は Kubernetes とその利点に焦点を当て、その複雑さを回避する方法を探ってみましょう。

免責事項: 一部のサプライヤー名またはロゴが表示されます。私はどのベンダーにも勤務しておらず、これは存在する可能性のある同様のソリューションよりも推奨されるものとして解釈されるべきではありません。

汎用性

Kubernetes はあらゆる場所で利用されており、さまざまな環境で実行されるさまざまなワークロードをサポートします。

写真

Kubernetesはどこにでもある

上の図に示すように、Kubernetes は、大規模なクラウドから小規模なクラウド、社内データセンター、さらにはエッジ コンピューティングまで、さまざまな環境で実行できます。

ワークロードの種類に応じて、Kubernetes は多くのことを実行できます。しかし、Kubernetes が特に適していないタイプのワークロードも存在します。モノリシック側では、（レガシー）メインフレームを想像することができます。あるいは、コンテナ化が難しい VM ベースのアプリケーション。

大規模なクラウド プラットフォームでは、データベース、インメモリ ストレージ、メッセージング コンポーネント、AI/ML およびビッグ データに重点​​を置いたサービスなど、多数のマネージド サービスが提供されています。これらのサービスでは、Kubernetes 内でクラウドやプラットフォームに依存しないクラウド ネイティブの代替手段を実行できます。しかし、これにはより多くの事前の作業が必要であり、潜在的なメリットは状況によって異なります。

そして、マイクロ スペクトルのもう一方の端では、大規模なクラウド プラットフォームが「サーバーレス」を提供します。これは、多くの場合、API ゲートウェイなどのコンポーネントや、イベント駆動型アーキテクチャの構成要素と緊密に統合された、サービスとしての関数です。たとえば、Knative を使用して、これらの関数を Kubernetes で実行することもできます。ただし、まずこれらのコンポーネントを設定してサポートする必要があり、この点ではクラウドの方が始めやすいと言えます。さらに、サーバーレスの特徴として、急速な拡張とゼロへのスケーリングが挙げられます。

Kubernetes は、ユーザーに標準化された作業方法 (大まかに言うと、YAML をクラスターに取り込む) を提供し、プラットフォーム チームにエンジニアリング チームをサポートするための統一された方法 (大まかに言うと、適切な YAML の作成を支援し、YAML をクラスターに取り込む支援) を提供します。これは、大規模なクラウド プラットフォームのマネージド サービスをすべて置き換えようとするのではなく、それらを活用して統合することで実現できます。

この標準化については後ほど詳しく説明します。

理由と方法

組織としては、（テクノロジー）戦略がなぜ選択されたのか、そして何が期待されているのかを十分に理解することが重要です。

このブログ記事のタイトルが示すように、「なぜ Kubernetes を使用するのか」という質問に明確に答えることが重要です。しかし、組織が直面している課題に対する論理的な答えが「Kubernetes」であれば、それはより良いことかもしれません。例えば：

• 大量のコンテナ化されたワークロードを効率的に実行するにはどうすればよいでしょうか?
• クラウド エキスパートのチームがゴールデン パスとガードレールを提供することで、多くのエンジニアリング チームを支援するにはどうすればよいでしょうか。
• 既存のソフトウェア配信プロセスに合わせてエッジでアプリケーションを実行するにはどうすればよいでしょうか?
• エンジニアリング チームが社内データ センターにアプリケーションを展開できるようにするにはどうすればよいでしょうか?
• 私たちにとって重要な部分に柔軟性を提供しながら、作業方法を標準化するにはどうすればよいでしょうか?
• 私たちが投資する知識とツールが可能な限り幅広く適用可能であること（たとえば、単一のクラウドベンダーに限定されない）をどのように保証しますか？

はい、最後のポイントは、少し「マルチクラウド」や「ベンダーロックイン」っぽいですね。はっきりさせておきましょう。他の場所でコンピューティングが安価であるという理由だけでクラウドを切り替えるのは、コスト効率が悪いことはほとんどありません。また、単に「マルチクラウド」であるために、マルチクラウドのパブリック部分を使用することは、コスト効率がほとんど良くありません。ベンダー ロックインは、クラウドの選択に限らず、あらゆる場所で発生します。ただし、数年単位の期間で考えると、組織はベンダーの境界を越えて適用可能なテクノロジーに重点を置くことに利点を見出す可能性があります。

高層ビルの建設

Kubernetes を導入する場合、Kubernetes が価値を提供し始める前に設定する必要があることがたくさんあります。私たちはプラットフォームを構築しています。物理的な世界の建物の例えを使って説明してみましょう。

写真

プラットフォームの構築

一番下には基礎があります。基礎は必要だからそこにありますが、単に基礎があるという理由だけで基礎を築く人はいません。 Kubernetes の用語では、基盤には、ネットワーク (CNI)、ストレージ (CSI)、コンテナ ランタイム (CRI)、仮想マシンまたはベアメタル サーバー、オペレーティング システムなどのコンポーネントが含まれます。

次は地下室です。基礎と同様に、これは最終目標ではありません (上に公園がある地下駐車場を建設する場合を除きます)。普段は当たり前だと思っているものにも対応します。機器、メンテナンス ルーム、パイプラインなど。Kubernetes では、これは稼働前に必要ないくつかの基本要件 (可観測性とセキュリティ) に対応します。証明書の管理。おそらくポリシーエンジンでしょう。

ついに地上に出る。私たちが建てるのは、目的を持った建物です。 Kubernetes の用語では、これらは明らかにデプロイされたアプリケーションです。しかし、プラットフォームの機能を強化するコンポーネントも含まれています。たとえば、ArgoCD/Flux (効率的なデプロイメントのために GitOps を使用)、Argo Workflows (ワークフロー エンジン)、KEDA (よりスマートな拡張機能) などです。

さて、各コンポーネントについて、それが基礎なのか、地下室なのか、建物なのかを議論することができます。おそらく、ArgoCD と KEDA は建物というよりは地下室のようなものでしょう。ストレージ クラスを比較的簡単に追加または削除できるため、CSI も基礎ではなく地下室である可能性があります。

重要なのは、地下から地上まで、以下のコンポーネントを観察できることです。

• ますます明らかになる
• 一般的に、時間の経過とともに適応しやすくなります
• コスト削減から価値創出へ

焦点: どこにでもいてはいけない

組織は、地上に優れた建物を建設するためのリソースが不足しているにもかかわらず、基礎や地下室に多くの時間を費やさないように注意する必要があります。

同時に、堅固な基盤の上にのみ構築することができます。地下室も崩壊しないはずです。

集中が必要です。大規模なクラウドで実行する場合、すべての基本コンポーネントが事前に構築された状態で存在します。まずこれらを考慮する必要があります。

同様に、地下レベルでは、可観測性プラットフォームの構築に多くの時間を費やすことができます。しかし、SaaS ソリューションやクラウド プロバイダーが提供するソリューションは多種多様です。セキュリティについても同様です。プレハブ部品が要件を満たしていない場合は、これらの要件を慎重に確認してください。提案されたよりシンプルな解決策が「十分に良い」ものであると確信していますか?今はシンプルなもので満足して、後で改善することはできますか?

エッジで運用する場合、OS とネットワークに重点を置くことが重要です。ネットワークを中断したり、自分自身をロックアウトしたりすることなく、リモート デバイスを安全に更新できる必要があります。一方、クラウドで実行する場合は、クラウドベンダーが提供するソリューションを優先し、そこで停止します。

プライベート環境で実行する場合、ステートフル ワークロード用の高性能ストレージ ソリューションとバックアップ ソリューションが必要になる場合があります。しかし、クラウドで実行する場合は、Kubernetes で独自のデータベースを構築する必要はありません。必要なすべてのサイズ設定オプションとポイントインタイムリカバリを提供するマネージドデータベースの使用を検討してください。 S3 互換のオブジェクト ストレージを使用してファイルを保存します。可観測性のために SaaS を使用し、すべてのログ、メトリック、トレースを保存しないようにします。これにより、ストレージ要件が最小限に抑えられ、セットアップがシンプルになります。

複雑性予算

クラスターにカスタマイズやコンポーネントを追加すると、複雑さが増します。初日のセットアップと 2 日目のメンテナンスが必要であり、そのためにはリソースが必要です。つまり、私たちが許容できる複雑さには限界があるということです。

定義される範囲は質問者によって異なる場合がありますが、プラットフォームに対するカスタマイズや追加は、資本支出、つまり投資収益を期待する先行費用と考えることができます。

設備投資によって最終的に全体の営業経費が削減されるか、少なくとも安定する限り、当社の事業は持続可能となります。そうしないと、運営費がかさんで問題が生じます。

写真

能力

これは、プラットフォームにコンポーネントを一切追加すべきではないという意味ではありません。業務の範囲が拡大するにつれて、複雑さも増します。これに対処する方法が必要です。ちなみに、これは Kubernetes に限ったことではありません。

つまり、コンポーネントを追加するタイミングと、それが将来的に全体的なワークロードにどのように影響するかを考慮する必要があるということです。

表面下にある複雑さの罠をいくつか回避すると、Kubernetes が提供する統合 API と作業方法が効果を発揮し始めます。例を見てみましょう:

課題: Kubernetes をセットアップしました。チームはアプリケーションを展開しています。しかし、ワークロードによっては再スケジュールに耐えられない場合があることに気付きました。また、一貫したラベル付けも少し問題です。

改善: ポリシー エンジンを追加しました。これは、優れたプラクティスを実装するのに役立ちます。

新しい状態: チームが YAML をクラスターにプッシュします。クラスターは時々「ノー」と言うことがあります。

課題: デプロイメント パイプラインが多数存在するようになったことに気付きました。そして、それらはすべて少しずつ異なります。クラスター内で実行する必要があるものと、主に個々のエンジニアリング チームによって管理されているこれらのパイプラインを関連付けることがますます困難になっていました。

改善: GitOps を追加しました。更新を展開するための、単一ウィンドウのプル リクエスト ベースのワークフローが実現しました。当社にはすでに PR ベースのワークフローがあったので、これは自然な流れでした。もちろん、不要なプルリクエストを避けるために、一部の更新を自動化することもできます。 CI パイプラインと CD パイプラインを分離することで、パイプラインが非常にシンプルになることも注目に値します。

新しい状態: チームは YAML を git に配置します。 GitOps は YAML をクラスターにプッシュします。クラスタリングによって物事が起こります。

課題: 一部のチームは、CPU ベースのワークロード スケーリングよりも「スマートな」ものが必要であることに気付きました。

改善: プラットフォーム チームが KEDA を設定しました。すでにポリシー エンジンが導入されているため、KEDA スケーラー構成のガードレールを簡単に設定できます。

新しい状態は、以前と同じです。チームは YAML を git に配置します。 GitOps は YAML をクラスターにプッシュします。クラスタリングによって物事が起こります。

課題: プラットフォーム チームは、エンジニアリング チームで行う必要のある変更のほとんどが、新しいサービスの名前空間、アーティファクト リポジトリ、データベース、Redis、パイプライン、IAM ID、またはキューのプロビジョニングという同じことに要約されることに気付きました。

改善点: POC 後、プラットフォーム チームは Crossplane を設定することを決定し、ポリシー エンジンを調整して制御された Crossplane リソース セットを許可し、保護を提供しました。チームは自分でリソースを設定できるようになりました。一方、プラットフォーム チームは、「類似のタスクの洪水」に圧倒されることなく、その機能の提供と維持に引き続き注力できます。

新しい状態は、以前と同じです。チームは YAML を git に配置します。 GitOps は YAML をクラスターにプッシュします。クラスタリングによって物事が起こります。

課題: プラットフォーム チームは、コンポーネントの更新を追跡するのに必要な労力が増加していることに気付きました。

改善: POC の後、Renovate を設定しました。これで、プラットフォーム チームは、プラットフォームで実行されているすべてのコンポーネントのリリース ページを確認する必要がなくなりました。

新しい状態は以前と非常に似ています。Renovate は YAML を git に配置します。 GitOps は YAML をクラスターにプッシュします。クラスタリングによって物事が起こります。

こうした変化は一夜にして起こるものではありません。さらに、組織内で物事が実行される方法を変更する必要がある場合もありますが、これは技術的な部分よりも難しい場合が多いです。しかし、追加の複雑さを 1 か所で慎重に処理することで、組織内の全体的な運用負荷を軽減できることは実証されています。

APIの考え方

Kubernetes を導入する場合、組織、経験、文化に応じてさまざまな視点が存在する可能性があります。

• ボトムアップ: 「サーバーを実行し、その上に Kubernetes を展開します」
• トップダウン：「Kubernetes を実行していて、サーバーが必要なのです」

前者は変更を避け、稼働時間に重点を置く傾向があります。

後者は、頻繁な制御された変更をさまざまなニーズを満たす手段と見なします。

微妙な違いですが、ご想像のとおり、Kubernetes を使用する場合はトップダウンの考え方の方が適しています。長期的には、より保守しやすいプラットフォームが実現します。例:

しないでください: 管理目的でサーバーへのシェル アクセスを設定します。

代わりに、(本番) サーバーにログインする必要を回避する方法に焦点を当てます。どのような観測データを送信する必要がありますか?ラボ環境でエラーシナリオを再現するにはどうすればよいでしょうか?

してはいけないこと: ノードにパッチを適用する方法と、それに伴うオーケストレーション、検査、再起動のプロセス全体を把握します。

代わりに、不変のインフラストラクチャを検討してください。多くの場合、古いノードはパッチを適用したノードに単純に置き換えられます。これは簡単に再現可能 (非本番環境でテスト済み) かつ元に戻せるプロセスです。ボーナス: カオスエンジニアリング。

してはいけないこと: Ansible を使用してサーバー上で「何か」を行う

代わりに、不変のインフラストラクチャと cloud-init に焦点を当て、絶対に必要ないくつかのインストール手順を実行します。

しないでください: 可観測性エージェント、EDR エージェントなどを使用して VM イメージを拡張します。

代わりに、デーモンセットを優先し、必要なセキュリティ コンテキストでこれらのプロセスを実行します。フライホイール効果を思い出してください。監視コンポーネントの可観測性をすべて備えた状態で、ワークロードをクラスターに簡単に配置する方法はすでにあります。さらに、Renovate はコンポーネントを最新の状態に保つのに役立ちます。

上記のポイントは、10 年前と同じ状況 (多数の VM を管理する) に陥らないようにする必要があり、さらに Kubernetes の多くの可動部分を管理する必要があるということです。 VM 管理部分を容易にするか、完全に排除するために、Kubernetes を活用する必要があります。これにより、プラットフォームと開発者のエクスペリエンスに重点を置く余地が生まれます。

結論（別名TL;DR）

ある程度の規模になると、チームの数が増えるにつれて、組織は次の課題に直面することになります。

最終的に障壁を作らずにガードレールを提供するにはどうすればよいでしょうか?

コンプライアンス、セキュリティ、コスト効率、パフォーマンス、災害復旧などのトピックすべてに対処する必要があります。これらの問題を各チームに委任することは非効率的で混乱を招き、各チームがこれらのトピックについて十分な知識を持っていることが必要になります。したがって、組織にはこの知識を統合し、すべてのチームに適用する方法が必要です。簡単に言えば、これが流行語「DevOps」が現在「プラットフォーム エンジニアリング」に置き換えられている理由です。

2024 年の Kubernetes は、大規模に実行する場合のこの種のプラットフォーム エンジニアリングを構築するのに適したテクノロジー スタックになる可能性もあります。しかし、リスクは高い。見返りは莫大なものになる可能性があるが、利益が出るまでに先行投資が必要となる。これにより、一定のリスクと参入障壁が生じます。

写真

テクノロジースタックの比較

上の図に示すように、テクノロジー スタック間には損益分岐点があります。これは一般論であることに注意してください。損益分岐点が存在するかどうか、またどこに存在するかは、組織が全体的な作業負荷を制限内に抑えることに成功しているかどうかによって決まります。ここで学べることは、Kubernetes はその性質上、初期ワークロードを多数のチームにスケーリングするのに適しているということです。

規模が主な懸念事項でない場合: Kubernetes は、集中型アプリケーションの実行方法に自然に統合されるため、エッジで実行するときに興味深い選択肢になる可能性があります。

ただし、Kubernetes は組織にまったく適していない可能性があります。

• 「いくつかの」アプリケーションをクラウドで実行する必要があるスタートアップですか?明確な目標がない限り、最初に Kubernetes を構築しないでください。
• 集中型プラットフォームチームのない自律型チーム?各チームごとに少しずつ異なる DevOps の車輪を再発明することを避けるために何かが必要です。それはKubernetesかもしれません。
• 実際にはそれほど多くのコンテナを実行せず、サーバーレスを使用していますか?素晴らしいですね。そのスタックを継続的に改善するように組織を設定してください。 「人々が Kubernetes を使用している」という理由だけで Kubernetes を検討しないでください。

複雑さの予算を賢く使いましょう。 Kubernetes を選択するときは、API に重点を置き、サーバーのことを忘れてしまうかもしれません。

太陽の光を楽しむことを忘れるほど、水面下に深く沈み込まないようにしてください。

1. フィルターバブルを避け、意味のないノイズや、やりとりを刺激するためだけのランダムなリストを除外してください。ソーシャル メディアでは、まだ多くの洞察と視点を得ることができます。
2. 幸いなことに、プレーン YAML、テンプレート化された YAML、プログラムによる YAML、または YAML に変換された JSON など、あらゆるユーザーの好みを満たす十分なツールが利用可能です。
3. チーム トポロジを見ると、「プラットフォーム チーム」または単に「チーム」と言及する場合、それぞれ「プラットフォーム チーム」と「フロー一貫性チーム」を指しています。
4. 有罪です。経験済みです。 AWS AMI のスケーリングは、デーモンセットの管理に比べて面倒です。