Kubernetes前書きKubernetesは、コンテナ化されたアプリケーションを管理するためのオープンソースのコンテナオーケストレーションツールです。[このシリーズの前のチュートリアル]では、DigitalOceanでKubernetesを構成しました。クラスターが稼働しているので、コンテナー化されたアプリケーションをデプロイできます。このチュートリアルでは、Kubernetesでポッドを展開し、サービスとして公開し、レプリケーションコントローラーを介してスケーリングするときに、これらのプリミティブがどのように連携するかを学習します。前提条件このチュートリアルを完了するには、まずこのシリーズの前のチュートリアルhttps://www.digitalocean.com/community/tutorials/webinar-series-getting-started-with-kubernetes[Kubernetesの開始]を完了する必要があります。Kubernetesプリミティブを理解するKubernetesは、クライアントがアプリケーションの作成、スケーリング、終了に使用するAPIを公開します。各操作は、Kubernetesが管理する1つ以上のオブジェクトを対象としています。これらのオブジェクトは、Kubernetesの基本的な構成要素を形成します。これらは、コンテナ化されたアプリケーションを管理するためのプリミティブです。Kubernetesの主要なAPIオブジェクトの概要は次のとおりです。クラスタ:コンピューティング、ストレージ、およびネットワークリソースのプール。ノード:クラスター内で実行されているホストマシン。名前空間:クラスターの論理パーティション。ラベル*および*セレクター:識別とサービス検出のためのキーと値のペア。サービス:同じアプリケーションに属するポッドのコレクション。レプリカセット:可用性とスケーラビリティを保証します。展開:アプリケーションのライフサイクルを管理します。これらをさらに詳しく見てみましょう。Kubernetesクラスターを実行する_Nodes_もオブジェクトとして扱われます。Kubernetesの他のAPIオブジェクトと同様に管理できます。アプリケーションの論理的な分離を可能にするために、Kubernetesは_Namespaces_の作成をサポートしています。組織は、開発、テスト、ステージング、および実稼働環境を実行するためにKubernetesクラスターを論理的にパーティション化できます。各環境は、個別に管理される専用のネームスペースに配置できます。Node_を介してAPIを公開します。KubernetesはDockerコンテナーを実行しますが、これらのコンテナーを直接展開することはできません。代わりに、アプリケーションはKubernetesが理解できる形式でパッケージ化する必要があります。この形式により、Kubernetesはコンテナ化されたアプリケーションを効率的に管理できます。これらのアプリケーションには、連携する必要がある1つ以上のコンテナが含まれている場合があります。Kubernetesでのパッケージ化と展開の基本単位は、_Pod_と呼ばれます。各Podには、一緒に管理する必要がある1つ以上のコンテナが含まれる場合があります。Webサーバー(Nginx)コンテナーとキャッシュ(Re​​dis)コンテナーをポッドとして一緒にパッケージ化できます。Kubernetesは、ポッドに属するすべてのコンテナーを論理ユニットとして扱います。新しいPodが作成されるたびに、Pod定義で宣言されたすべてのコンテナーが作成されます。ポッド内のすべてのコンテナーは、IPアドレス、ホスト名、ストレージなどの同じコンテキストを共有します。APIではなく、プロセス間通信(IPC)を介して互いに通信します。コンテナをパッケージ化してKubernetesにデプロイしたら、内部および外部アクセスのためにコンテナを公開する必要があります。データベースやキャッシュなどの特定のコンテナは、外部に公開する必要はありません。APIとWebフロントエンドは、他の消費者とエンドユーザーによって直接アクセスされるため、一般に公開する必要があります。Kubernetesでは、コンテナはポリシーに基づいて内部または外部に公開されます。このメカニズムにより、データベースなどのデリケートなワークロードを公開するリスクが軽減されます。Kubernetesのポッドは、_Services_を通じて公開されます。各サービスは、ポートおよびプロトコル情報とともに内部または外部エンドポイントとして宣言されます。Servicesに依存しています。サービスはTCPおよびUDPプロトコルをサポートします。PodやサービスなどのKubernetesの各オブジェクトは、_Labels_および_Selectors_と呼ばれる追加のメタデータに関連付けられています。ラベルは、Kubernetesオブジェクトに関連付けられたキーと値のペアです。これらのラベルは、1つ以上のAPIオブジェクトを一意に識別します。セレクターは、1つのKubernetesオブジェクトを別のオブジェクトに関連付けます。サービスで定義されたセレクターは、セレクターの値と一致するラベルを持つすべてのポッドをKubernetesが検索するのに役立ちます。この関連付けにより、オブジェクトの動的検出が可能になります。実行時に同じラベルで作成された新しいオブジェクトは即座に検出され、対応するセレクタに関連付けられます。このサービス検出メカニズムにより、スケールインおよびスケールアウト操作などの効率的な動的構成が可能になります。コンテナに切り替える利点の1つは、迅速なスケーリングです。コンテナは仮想マシンと比較すると軽量であるため、数秒でスケーリングできます。可用性が高くスケーラブルなセットアップでは、アプリケーションの複数のインスタンスをデプロイし、これらのアプリケーションのインスタンスの最小数が常に実行されていることを確認する必要があります。Sets_の概念を導入しました。ポッドの複数のインスタンスをクラスターで実行する必要がある場合、それらはレプリカセットとしてパッケージ化されます。Kubernetesは、レプリカセットで定義されたPodの数が常に実行モードであることを確認します。ハードウェアまたは構成の問題によりポッドが終了した場合、Kubernetesコントロールプレーンはすぐに別のポッドを起動します。_Deployment_オブジェクトは、ポッドとレプリカセットの組み合わせです。このプリミティブは、KubernetesアプリケーションにPaaSのような機能をもたらします。最小限のダウンタイムで既存の展開のローリングアップグレードを実行できます。デプロイメントでは、カナリアデプロイメントやブルー/グリーンデプロイメントなどのパターンも使用できます。コンテナ化されたアプリケーションのアプリケーションライフサイクル管理(ALM)の重要な部分を処理します。+`はデフォルトの名前空間を対象にします。それでは、アプリケーションを起動しましょう。CLIを介してKubernetesに送信されます。ポッドを定義して展開しましょう。+`という新しいYAMLファイルを作成します。Webサーバーに基づく1つのコンテナーでポッドを定義する次のコードを追加します。TCPプロトコルを介してポート「80」で公開されます。+」が含まれていることに注意してください。これらのラベルを使用して、特定のポッドを識別および構成します。TCP次のコマンドを実行してポッドを作成します。createdポッドの作成を確認しましょう。2m次のステップでは、このPodをパブリックインターネットにアクセスできるようにします。–サービスを介したポッドの公開サービスは、一連のPodを内部または外部に公開します。Nginxポッドを一般公開するサービスを定義しましょう。NodePortを介してNginxを公開します。これは、クラスターの各ノードで開かれた任意のポートを介してPodにアクセスできるようにするスキームです。+`という新しいファイルを作成します。+`に一致する同じネームスペース内のすべてのポッドを検出します。YAMLファイルのセレクターセクションは、この関連付けを明示的に定義します。Type:NodePort宣言を介して、サービスのタイプがNodePortであることを指定します。次に、を使用してクラスターに送信します。Simple-Service.ymlサービスが正常に作成されたことを示す次の出力が表示されます。createdポッドが利用可能なポートを取得しましょう。+`で利用可能であることがわかります。ワーカーノードの1つに接続してみましょう。DigitalOceanコンソールを使用して、いずれかのワーカーノードのIPアドレスを取得します。[Kubernetesクラスターに関連付けられたDigitalOceanコンソールのドロップレット。+`上のノードの1つにHTTPリクエストを送信します。http://:32097Nginxのデフォルトのホームページを含む応答が表示されます。</body></html>ポッドとサービスを定義しました。次に、レプリカセットを使用したスケーリングを見てみましょう。–レプリカセットを介したポッドのスケーリングレプリカセットは、クラスターで少なくとも最小数のポッドが実行されていることを確認します。現在のポッドを削除し、レプリカセットを使用して3つのポッドを再作成しましょう。既存のポッドを削除します。deleted次に、新しいレプリカセット宣言を作成します。レプリカセットの定義はポッドと同じです。主な違いは、実行する必要があるPodの数を定義するレプリカ要素が含まれていることです。ポッドと同様に、サービス検出に役立つメタデータとしてラベルも含まれています。+`を作成し、このコードをファイルに追加します。TCPファイルを保存して閉じます。次に、レプリカセットを作成します。created次に、ポッドの数を確認します。38sNodePortを介してサービスにアクセスすると、リクエストはレプリカセットによって管理されるポッドの1つに送信されます。ポッドの1つを削除して何が起こるかを見て、レプリカセットの機能をテストしましょう。deletedポッドをもう一度見てください。2mポッドが削除されるとすぐに、Kubernetesは別のポッドを作成して、目的のカウントが維持されるようにします。次に、展開を見てみましょう。–展開に対処するコンテナをポッドおよびレプリカセットとして展開できますが、展開を使用すると、アプリケーションのアップグレードとパッチ適用が簡単になります。展開を使用してPodをインプレースでアップグレードできます。これはレプリカセットでは実行できません。これにより、最小限のダウンタイムでアプリケーションの新しいバージョンを展開できます。PaaSのような機能をアプリケーション管理にもたらします。展開を作成する前に、既存のレプリカセットを削除します。これにより、関連するポッドも削除されます。deleted次に、新しい展開を定義します。+`を作成し、次のコードを追加します。80展開を作成し、作成を確認します。created展開を表示します。1mデプロイメントによりPodが作成されるため、YAMLファイルのレプリカ宣言に従って3つのPodが実行されます。2m前に作成したサービスは、デプロイによって作成されたポッドにリクエストをルーティングし続けます。これは、元のポッド定義と同じ値を含むラベルがあるためです。展開とサービスを削除して、リソースをクリーンアップします。documentation]を参照してください。Webサーバーをデプロイする際のKubernetesの基本的な構成要素を調査しました。このシリーズの次のパートでは、マルチコンテナアプリケーションをパッケージ化、展開、スケーリング、および管理する方法を学習します。