序章

スケーラビリティ、移植性、および堅牢性を念頭に置いてアプリケーションを設計および実行することは、特にシステムの複雑さが増すにつれて、困難になる可能性があります。 アプリケーションまたはシステムのアーキテクチャーは、それをどのように実行する必要があるか、その環境に何を期待するか、および関連するコンポーネントとどの程度密接に結合しているかを決定します。 設計段階で特定のパターンに従い、特定の運用慣行を順守することで、高度に分散された環境で実行するときにアプリケーションが直面する最も一般的な問題のいくつかに対処できます。

DockerKubernetesなどのテクノロジーは、チームがソフトウェアをパッケージ化し、分散コンピューターのプラットフォームで配布、展開、拡張するのに役立ちます。 これらのツールの能力を最大限に活用する方法を学ぶことは、より高い柔軟性、制御、および応答性でアプリケーションを管理するのに役立ちます。

このガイドでは、Kubernetesでのワークロードのスケーリングと管理に役立ついくつかの原則とパターンについて説明します。 Kubernetesはさまざまな種類のワークロードを実行できますが、選択内容が操作のしやすさと利用可能な可能性に影響を与える可能性があります。

アプリケーションのスケーラビリティのための設計

ソフトウェアを作成する場合、多くの要件が、使用するパターンとアーキテクチャに影響します。 Kubernetesの場合、最も重要な要素の1つは、水平方向にスケーリングできることです。これにより、並列で実行されるアプリケーションの同一コピーの数を増やして、負荷を分散し、可用性を向上させます。 これは、垂直スケーリングの代替手段であり、通常、単一のアプリケーションスタックの容量を増やすことを意味します。

特に、マイクロサービスは、クラスターでのスケーラブルなデプロイに適したソフトウェアデザインパターンです。 開発者は、内部メカニズムを介して通信する大規模な複合プログラムではなく、明確に定義されたAPIを介してネットワークを介して通信する小さな構成可能なアプリケーションを作成します。 モノリシックアプリケーションを個別の単一目的コンポーネントにリファクタリングすることで、各機能を個別にスケーリングできます。 アプリケーションレベルで通常存在する複雑さとオーバーヘッドの多くは、Kubernetesなどのプラットフォームで管理できる運用領域に転送されます。

特定のソフトウェアパターンに加えて、クラウドネイティブアプリケーションは、いくつかの追加の考慮事項を念頭に置いて設計されています。 クラウドネイティブアプリケーションは、クラウドプラットフォームを最大限に活用するために、復元力、可観測性、および管理機能が組み込まれたマイクロサービスアーキテクチャパターンに従うプログラムです。

たとえば、クラウドネイティブアプリケーションは、インスタンスが異常になった場合にプラットフォームがライフサイクルイベントを管理できるようにするヘルスレポートメトリックを使用して構築されます。 堅牢なテレメトリデータを生成(およびエクスポートできるようにする)して、オペレーターに問題を警告し、情報に基づいた決定を下せるようにします。 アプリケーションは、データを破損したり応答しなくなったりすることなく、定期的な再起動と障害、バックエンドの可用性の変更、および高負荷を処理するように設計されています。

次の12要素のアプリケーション哲学

クラウド対応のWebアプリを作成するときに最も重要な特性に焦点を当てるのに役立つ一般的な方法の1つは、12ファクターアプリの哲学です。 もともとは、開発者と運用チームがクラウドで実行するように設計されたWebサービスによって共有されるコア品質を理解するのを支援するために作成されましたが、この原則は、Kubernetesのようなクラスター環境に存在するソフトウェアに非常によく適用されます。 モノリシックアプリケーションはこれらの推奨事項に従うことでメリットが得られますが、これらの原則に基づいて設計されたマイクロサービスアーキテクチャは特にうまく機能します。

12の要因の簡単な要約は次のとおりです。

  1. コードベース:バージョン管理システム(GitやMercurialなど)のすべてのコードを管理します。 コードベースは、展開されるものを包括的に指示します。
  2. 依存関係:依存関係は、ベンダー(コードとともに保存)またはパッケージマネージャーがインストールできる形式で固定されたバージョンのいずれかで、コードベースによって完全かつ明示的に管理する必要があります。
  3. Config:構成パラメーターをアプリケーションから分離し、アプリケーション自体に焼き付けるのではなく、デプロイメント環境で定義します。
  4. バッキングサービス:ローカルサービスとリモートサービスはどちらも、構成で設定された接続の詳細を使用して、ネットワークアクセス可能なリソースとして抽象化されます。
  5. ビルド、リリース、実行:アプリケーションのビルド段階は、アプリケーションのリリースおよび操作プロセスから完全に分離する必要があります。 ビルドステージはソースコードからデプロイメントアーティファクトを作成し、リリースステージはアーティファクトと構成を組み合わせ、実行ステージはリリースを実行します。
  6. プロセス:アプリケーションは、状態のローカル保存に依存してはならないプロセスとして実装されます。 4番目の要素で説明されているように、状態はバッキングサービスにオフロードする必要があります。
  7. ポートバインディング:アプリケーションは、ポートにネイティブにバインドし、接続をリッスンする必要があります。 ルーティングとリクエスト転送は外部で処理する必要があります。
  8. 同時実行性:アプリケーションは、プロセスモデルのスケーリングに依存する必要があります。 アプリケーションの複数のコピーを同時に、場合によっては複数のサーバー間で実行すると、アプリケーションコードを調整せずにスケーリングできます。
  9. 廃棄可能性:プロセスは、深刻な副作用なしに迅速に開始し、正常に停止できる必要があります。
  10. 開発/本番パリティ:テスト、ステージング、および本番環境は厳密に一致し、同期が保たれている必要があります。 環境間の違いは、非互換性とテストされていない構成が表示される機会です。
  11. ログ:アプリケーションはログを標準出力にストリーミングして、外部サービスがログを最適に処理する方法を決定できるようにする必要があります。
  12. 管理プロセス: 1回限りの管理プロセスは、特定のリリースに対して実行し、メインプロセスコードとともに出荷する必要があります。

Twelve Factorsが提供するガイドラインに従うことで、Kubernetesに適したアプリケーションを作成して実行できます。 12の要素により、開発者はアプリケーションの主な目的に焦点を合わせ、コンポーネント間の動作条件とインターフェイスを検討し、入力、出力、標準のプロセス管理機能を使用してKubernetesで予測どおりに実行することができます。

アプリケーションコンポーネントのコンテナ化

Kubernetesはコンテナを使用して、クラスタノード全体で分離されたパッケージ化されたアプリケーションを実行します。 Kubernetesで実行するには、アプリケーションを1つ以上のコンテナイメージにカプセル化し、Dockerなどのコンテナランタイムを使用して実行する必要があります。 コンポーネントをコンテナ化することはKubernetesの要件ですが、前述の12要素のアプリ手法の原則の多くを強化し、スケーリングと管理を改善するのにも役立ちます。

たとえば、コンテナは、アプリケーション環境と外部ホストシステムを分離します。 これらは、アプリケーション間通信へのネットワーク化されたアプローチをサポートし、通常、環境変数を介して構成を取得し、に書き込まれたログを公開します。 stdoutstderr. コンテナ自体は、プロセスベースの同時実行性を促進し、独立してスケーラブルでプロセスのランタイム環境をバンドルすることにより、開発/製品のパリティを維持するのに役立ちます。 これらの特性により、アプリケーションをパッケージ化して、Kubernetesでスムーズに実行できるようになります。

コンテナの最適化に関するガイドライン

コンテナテクノロジーの柔軟性により、アプリケーションをカプセル化するさまざまな方法が可能になります。 ただし、Kubernetes環境では、他の方法よりもうまく機能する方法があります。

アプリケーションのコンテナー化に関するほとんどのベストプラクティスは、コンテナー内からソフトウェアをセットアップして実行する方法を定義するイメージ構築に関係しています。 一般に、画像サイズを小さく簡単に保つことには、多くの利点があります。 サイズが最適化されたイメージは、Dockerや他のコンテナーフレームワークが自動的に実行するように設計されているイメージの更新の間に既存のレイヤーを再利用することで、クラスターで新しいコンテナーを起動するために必要な時間とリソースを削減できます。

コンテナイメージを作成する際の最初の良いステップは、本番環境で実行される最終イメージからビルドステップを分離するために最善を尽くすことです。 ソフトウェアのコンパイルまたはバンドルには、通常、追加のツールが必要であり、追加の時間がかかり、コンテナ間で一貫性がないか、最終的なランタイム環境に不要なアーティファクト(クロスプラットフォームの依存関係など)が生成されます。 ビルドプロセスをランタイム環境からきれいに分離する1つの方法は、Dockerマルチステージビルドを使用することです。 マルチステージビルド構成では、ビルドプロセス中に使用する1つのベースイメージを指定し、実行時に使用する別のベースイメージを定義できます。 これにより、すべてのビルドツールがインストールされたイメージを使用してソフトウェアをビルドし、結果のアーティファクトをスリムで合理化されたイメージにコピーして、後で毎回使用することができます。

このタイプの機能を利用できるので、通常、最小限の親イメージの上に本番イメージを構築することをお勧めします。 「ディストリビューション」スタイルの親レイヤーに見られる肥大化を完全に回避したい場合は、 ubuntu:20.04 (完全なUbuntu 20.04サーバー環境が含まれています)、次のコマンドでイメージを構築できます scratch — Dockerの最小のベースイメージ—親として。 しかし scratch ベースレイヤーは多くのコアツールへのアクセスを提供せず、Linux環境に関するいくつかのベースラインの仮定を破ることがよくあります。 別の方法として、 Alpine Linux alpine imageは、小さいながらも完全な機能を備えたLinuxディストリビューションを提供する、堅固で最小限の基本環境であるため、人気が高まっています。

PythonやRubyのような解釈された言語の場合、コンパイル段階がなく、本番環境でコードを実行するためにインタープリターが使用可能である必要があるため、パラダイムはわずかにシフトします。 ただし、スリムなイメージは依然として理想的であるため、AlpineLinux上に構築された多くの言語固有の最適化されたイメージがDockerHubで利用できます。 インタプリタ言語に小さいイメージを使用する利点は、コンパイル言語の場合と同様です。Kubernetesは、必要なすべてのコンテナイメージを新しいノードにすばやくプルして、意味のある作業を開始できるようになります。

コンテナとポッドの範囲の決定

アプリケーションをコンテナ化してKubernetesクラスタで実行する必要がありますが、ポッドは、Kubernetesが直接管理できる抽象化の最小単位です。 ポッドは、1つ以上の密接に結合されたコンテナで構成されるKubernetesオブジェクトです。 ポッド内のコンテナはライフサイクルを共有し、単一のユニットとして一緒に管理されます。 たとえば、コンテナは常に同じノード(サーバー)でスケジュール(デプロイ)され、同時に開始または停止され、ファイルシステムやIPアドレスなどのリソースを共有します。

Kubernetesがこれらのコンポーネントをどのように処理するか、および抽象化の各レイヤーがシステムに何を提供するかを理解することが重要です。 いくつかの考慮事項は、これらの抽象化のそれぞれを使用して、アプリケーションのカプセル化のいくつかの自然なポイントを特定するのに役立ちます。

コンテナの効果的な範囲を決定する1つの方法は、自然な開発境界を探すことです。 システムがマイクロサービスアーキテクチャを使用して動作している場合、さまざまなコンテキストで使用できる機能の個別のユニットを表すために、適切に設計されたコンテナが頻繁に構築されます。 このレベルの抽象化により、チームはコンテナーイメージへの変更をリリースし、これらのイメージが使用される任意の環境にこの新しい機能を展開できます。 アプリケーションは、それぞれが特定の機能を果たすが、プロセス全体を単独で実行することはできない個々のコンテナーを構成することによって構築できます。

上記とは対照的に、ポッドは通常、システムのどの部分が独立した管理から最も恩恵を受ける可能性があるかを考えることによって構築されます。 Kubernetesは、ユーザー向けの最小の抽象化としてポッドを使用するため、これらはKubernetesツールとAPIが直接対話して制御できる最も原始的なユニットです。 ポッドを開始、停止、再起動したり、ポッド上に構築された高レベルのオブジェクトを使用して、レプリケーションおよびライフサイクル管理機能を導入したりできます。 Kubernetesでは、ポッド内のコンテナを個別に管理することはできないため、個別の管理の恩恵を受ける可能性のあるコンテナをグループ化しないでください。

Kubernetesの機能と抽象化の多くはポッドを直接処理するため、1つのポッドに一緒にスケーリングする必要があるアイテムをバンドルし、独立してスケーリングする必要があるアイテムを分離することは理にかなっています。 たとえば、Webサーバーを異なるポッドのアプリケーションサーバーから分離すると、必要に応じて各レイヤーを個別にスケーリングできます。 ただし、Webサーバーとデータベースアダプターを同じポッドにバンドルすることは、アダプターがWebサーバーが正しく機能するために必要な基本的な機能を提供する場合に意味があります。

サポートコンテナをバンドルすることによるポッド機能の強化

これを念頭に置いて、どのタイプのコンテナを1つのポッドにバンドルする必要がありますか? 通常、プライマリコンテナはポッドのコア機能を実行する役割を果たしますが、プライマリコンテナを変更または拡張したり、一意の展開環境への接続を支援したりする追加のコンテナを定義できます。

たとえば、ウェブサーバーポッドでは、リポジトリが変更されたときに関連するコンテナが静的ファイルを更新している間に、Nginxコンテナがリクエストをリッスンしてコンテンツを提供する場合があります。 これらのコンポーネントの両方を単一のコンテナー内にパッケージ化することは魅力的かもしれませんが、それらを別々のコンテナーとして実装することには大きな利点があります。 Webサーバーコンテナとリポジトリプラーの両方を、異なるコンテキストで独立して使用できます。 それらは異なるチームによって維持され、それぞれが異なるコンパニオンコンテナで動作するように動作を一般化するように開発できます。

BrendanBurnsとDavidOppenheimerは、コンテナベースの分散システムのデザインパターンに関する論文で、サポートコンテナをバンドルするための3つの主要なパターンを特定しました。 これらは、コンテナをポッドにまとめてパッケージ化するための最も一般的なユースケースの一部を表しています。

  • Sidecar:このパターンでは、セカンダリコンテナーが拡張され、プライマリコンテナーのコア機能が強化されます。 このパターンには、別のコンテナで非標準またはユーティリティ関数を実行することが含まれます。 たとえば、ログを転送したり、更新された構成値を監視したりするコンテナーは、主なフォーカスを変更せずにポッドの機能を拡張できます。
  • アンバサダー:アンバサダーパターンは、補助コンテナーを使用して、メインコンテナーのリモートリソースを抽象化します。 プライマリコンテナーはアンバサダーコンテナーに直接接続し、アンバサダーコンテナーは、分散Redisクラスターなどの潜在的に複雑な外部リソースのプールに接続して抽象化します。 プライマリコンテナは、外部サービスに接続するために実際のデプロイメント環境を認識したり気にしたりする必要はありません。
  • Adapter:アダプターパターンは、プライマリコンテナーのデータ、プロトコル、またはインターフェイスを変換して、外部の関係者が期待する標準に合わせるために使用されます。 アダプタコンテナは、それらが提供するアプリケーションが互換性のないインターフェイスのみをネイティブにサポートしている場合でも、一元化されたサービスへの均一なアクセスを可能にします。

構成をConfigMapsとシークレットに抽出する

アプリケーション構成をコンテナイメージに組み込むことができますが、複数のコンテキストでの展開をサポートし、より柔軟な管理を可能にするために、コンポーネントを実行時に構成可能にするのが最善です。 ランタイム設定パラメータを管理するために、KubernetesはConfigMapsSecretsと呼ばれる2つの異なるタイプのオブジェクトを提供します。

ConfigMapsは、実行時にポッドやその他のオブジェクトに公開できるデータを格納するために使用されるメカニズムです。 ConfigMaps内に保存されたデータは、環境変数として表示することも、ポッドにファイルとしてマウントすることもできます。 これらの場所から読み取るようにアプリケーションを設計することにより、ConfigMapsを使用して実行時に構成を挿入し、コンテナーイメージを再構築せずにコンポーネントの動作を変更できます。

シークレットは、機密データを安全に保存し、必要に応じてポッドやその他のコンポーネントがデータにアクセスできるようにするために使用される、同様のKubernetesオブジェクトタイプです。 シークレットは、通常の構成で簡単にアクセスできる場所にプレーンテキストとして保存せずに、機密情報をアプリケーションに渡す便利な方法です。 機能的には、これらはConfigMapとほぼ同じように機能するため、アプリケーションは同じメカニズムを使用してConfigMapとシークレットからのデータを使用できます。

ConfigMapsとSecretsは、構成パラメーターをKubernetesオブジェクト定義に直接配置することを回避するのに役立ちます。 値の代わりに構成キーをマップして、ConfigMapまたはSecretを変更することでその場で構成を更新できます。 これにより、リソースのKubernetes定義を変更せずに、ポッドやその他のKubernetesオブジェクトのアクティブなランタイム動作を変更する機会が得られます。

準備と活気のプローブの実装

Kubernetesには、コンポーネントのライフサイクルを管理し、アプリケーションが常に正常で利用可能であることを保証するための、すぐに使用できる機能が多数含まれています。 ただし、これらの機能を利用するには、Kubernetesがアプリケーションの状態を監視および解釈する方法を理解する必要があります。 そのために、Kubernetesではlivenessおよびreadinessプローブを定義できます。

ライブネスプローブを使用すると、Kubernetesは、コンテナ内のアプリケーションが有効でアクティブに実行されているかどうかを判断できます。 Kubernetesは、コンテナ内で定期的にコマンドを実行して基本的なアプリケーションの動作を確認したり、HTTPまたはTCPネットワークリクエストを指定された場所に送信して、プロセスが利用可能で期待どおりに応答できるかどうかを判断できます。 ライブネスプローブが失敗した場合、Kubernetesはコンテナを再起動して、ポッド内の機能の再確立を試みます。

準備プローブは、ポッドがトラフィックを処理する準備ができているかどうかを判断するために使用される同様のツールです。 コンテナー内のアプリケーションは、クライアント要求を受け入れる準備ができる前に初期化手順を実行する必要がある場合や、構成の変更時に再ロードする必要がある場合があります。 準備プローブが失敗すると、コンテナを再起動する代わりに、Kubernetesはポッドへのリクエストの送信を一時的に停止します。 これにより、ポッドは、グループ全体の状態に影響を与えることなく、初期化またはメンテナンスルーチンを完了できます。

ライブネスプローブと準備プローブを組み合わせることで、ポッドを自動的に再起動するか、バックエンドグループから削除するようにKubernetesに指示できます。 これらの機能を利用するようにインフラストラクチャを構成すると、Kubernetesは、追加の操作作業なしでアプリケーションの可用性と正常性を管理できます。

展開を使用して規模と可用性を管理する

以前、ポッドデザインの基本について説明したときに、他のKubernetesオブジェクトがこれらのプリミティブに基づいて構築され、より高度な機能を提供することを説明しました。 そのような複合オブジェクトの1つであるdeploymentは、おそらく最も一般的に定義および操作されるKubernetesオブジェクトです。

デプロイは、他のKubernetesプリミティブに基づいて構築され、機能を追加する複合オブジェクトです。 これらは、 ReplicaSets と呼ばれる中間オブジェクトにライフサイクル管理機能を追加します。これには、ローリング更新、以前のバージョンへのロールバック、および状態間の移行を実行する機能が含まれます。 これらのReplicaSetを使用すると、ポッドテンプレートを定義して、単一のポッドデザインの複数のコピーを起動および管理できます。 これにより、インフラストラクチャを簡単にスケールアウトし、可用性要件を管理し、障害が発生した場合にポッドを自動的に再起動できます。

これらの追加機能は、ベースポッドレイヤーに管理フレームワークと自己修復機能を提供します。 ポッドは、定義したワークロードを最終的に実行するユニットですが、通常はプロビジョニングおよび管理する必要のあるユニットではありません。 代わりに、ポッドは、デプロイメントなどの高レベルのオブジェクトを介してプロビジョニングされたときにアプリケーションを堅牢に実行できるビルディングブロックと考えてください。

アプリケーション層へのアクセスを管理するためのサービスと入力ルールの作成

デプロイメントを使用すると、交換可能なポッドのセットをプロビジョニングおよび管理して、アプリケーションをスケールアウトし、ユーザーの要求を満たすことができます。 ただし、プロビジョニングされたポッドへのトラフィックのルーティングは別の問題です。 ローリングアップデートの一部としてポッドがスワップアウトされたり、再起動されたり、ホストの障害のために移動されたりすると、実行中のグループに以前に関連付けられていたネットワークアドレスが変更されます。 Kubernetes services を使用すると、ポッドの動的プールのルーティング情報を維持し、インフラストラクチャのさまざまなレイヤーへのアクセスを制御することで、この複雑さを管理できます。

Kubernetesでは、サービスはトラフィックがポッドのセットにルーティングされる方法を制御する特定のメカニズムです。 外部クライアントからのトラフィックを転送する場合でも、複数の内部コンポーネント間の接続を管理する場合でも、サービスを使用すると、トラフィックの流れを制御できます。 その後、Kubernetesは、環境が変化し、ネットワークアドレスが変更された場合でも、関連するポッドに接続を転送するために必要なすべての情報を更新および維持します。

内部でサービスにアクセスする

サービスを効果的に使用するには、最初にポッドの各グループの対象となるコンシューマーを決定する必要があります。 サービスがKubernetesクラスター内にデプロイされた他のアプリケーションによってのみ使用される場合、 clusterIP サービスタイプを使用すると、クラスター内からのみルーティング可能な安定したIPアドレスを使用してポッドのセットに接続できます。 クラスタにデプロイされたオブジェクトは、サービスのIPアドレスにトラフィックを直接送信することで、複製されたポッドのグループと通信できます。 これは最も単純なサービスタイプであり、内部アプリケーション層に適しています。

オプションのDNSアドオンを使用すると、KubernetesはサービスのDNS名を提供できます。 これにより、ポッドやその他のオブジェクトがIPアドレスではなく名前でサービスと通信できるようになります。 このメカニズムによってサービスの使用状況が大幅に変わることはありませんが、名前ベースの識別子を使用すると、サービスのIPアドレスを必ずしも知らなくても、コンポーネントの接続や相互作用の定義が簡単になります。

公共消費のための公開サービス

インターフェイスがパブリックにアクセス可能である必要がある場合、通常、最適なオプションはロードバランサーサービスタイプです。 これは、特定のクラウドプロバイダーのAPIを使用してロードバランサーをプロビジョニングします。ロードバランサーは、公開されているIPアドレスを介してサービスポッドにトラフィックを提供します。 これにより、外部リクエストをサービス内のポッドにルーティングし、内部クラスターネットワークに制御されたネットワークチャネルを提供できます。

ロードバランササービスタイプはすべてのサービスにロードバランサを作成するため、このメソッドを使用してKubernetesサービスを公開するのはコストがかかる可能性があります。 これを軽減するために、Kubernetes ingress オブジェクトを使用して、事前に定義された一連のルールに基づいて、さまざまなタイプのリクエストをさまざまなサービスにルーティングする方法を説明できます。 たとえば、「 example.com 」のリクエストはサービスAに送信され、「sammytheshark.com」のリクエストはサービスBにルーティングされる場合があります。 入力オブジェクトは、事前定義されたパターンに基づいて、リクエストの混合ストリームをターゲットサービスに論理的にルーティングする方法を説明する方法を提供します。

入力ルールは、クラスター内にポッドとしてデプロイされた入力コントローラー(通常はNginxなどの一種の負荷分散)によって解釈される必要があります。これにより、入力ルールが実装され、それに応じてトラフィックがKubernetesサービスに転送されます。 入力実装を使用して、クラスター所有者が実行する必要のある外部ロードバランサーの数を最小限に抑えることができます。

宣言型構文を使用したKubernetes状態の管理

Kubernetesは、クラスターにデプロイされるリソースを定義および制御する際に非常に多くの柔軟性を提供します。 次のようなツールを使用する kubectl、アドホックオブジェクトを必須に定義して、クラスターにすぐにデプロイできます。 これは、Kubernetesを学習するときにリソースをすばやくデプロイするのに役立ちますが、このアプローチには欠点があり、長期的な本番管理には望ましくありません。

命令型管理の主な問題の1つは、クラスターにデプロイした変更の記録が残らないことです。 これにより、障害が発生した場合の復旧や、システムに適用されている運用上の変更の追跡が困難または不可能になります。

幸い、Kubernetesには、テキストファイル内のリソースを完全に定義してから使用できる、代替の宣言型構文が用意されています。 kubectl 構成または変更を適用します。 これらの構成ファイルをバージョン管理リポジトリに保存することは、変更を監視し、組織の他の部分で使用されるレビュープロセスと統合するための優れた方法です。 ファイルベースの管理では、既存の定義をコピーして編集することにより、既存のパターンを新しいリソースに適合させることもできます。 Kubernetesオブジェクト定義をバージョン管理されたディレクトリに保存すると、各時点で目的のクラスター状態のスナップショットを維持できます。 これは、リカバリ操作、移行中、またはシステムに導入された意図しない変更の根本原因を追跡するときに非常に役立ちます。

結論

アプリケーションを実行するインフラストラクチャを管理し、最新のオーケストレーション環境によって提供される機能を最大限に活用する方法を学ぶことは、気が遠くなる可能性があります。 ただし、Kubernetesのようなシステムやコンテナのようなテクノロジーによって提供される利点の多くは、開発と運用の実践がツールが構築されている概念と一致している場合に、より明確になります。 Kubernetesが得意とするパターンを使用してシステムを設計し、特定の機能が複雑なデプロイの課題をどのように軽減できるかを理解することで、プラットフォームでの実行エクスペリエンスを向上させることができます。

次に、Kubernetesの既存のアプリケーションの最新化についてお読みください。