Docker Swarm、Kubernetes、Mesos は、最も人気のあるコンテナ オーケストレーション フレームワークです。 Arun Gupta 氏は講演の中で、Docker、Swarm、Kubernetes の次の側面を比較しています。
- 地域開発。
- 導入機能。
- マルチコンテナアプリケーション。
- サービスの発見。
- サービスのスケーリング。
- XNUMX 回だけ実行されるタスク。
- Maven との統合。
- 「ローリング」アップデート。
- Couchbase データベース クラスターの作成。
その結果、各オーケストレーション ツールが提供するものを明確に理解し、これらのプラットフォームを効果的に使用する方法を学ぶことができます。
Arun Gupta は、アマゾン ウェブ サービスのオープンソース製品の主任技術者であり、10 年以上にわたって Sun、Oracle、Red Hat、Couchbase の開発者コミュニティを開発してきました。 マーケティング キャンペーンやプログラムの戦略を開発、実装する部門横断的なチームを率いて働いた豊富な経験を持っています。 彼は Sun エンジニアのチームを率い、Java EE チームの創設者の 4 人であり、Devoxx2Kids の米国支社の創設者でもあります。 Arun Gupta は、IT ブログに 40 件を超える投稿を投稿しており、XNUMX か国以上で講演を行っています。
55 行目には、このデータベース サービスを指す COUCHBASE_URI が含まれています。これも Kubernetes 構成ファイルを使用して作成されました。 2 行目を見ると、kind: Service が couchbase-service という名前で作成しているサービスであり、同じ名前が 4 行目にリストされています。 以下にいくつかのポートを示します。
重要な行は 6 行目と 7 行目です。サービス中に、「これが私が探しているラベルです!」と言いますが、これらのラベルは変数ペア名にすぎず、7 行目は私の couchbase-rs-pod を指しています。応用。 以下は、これらの同じラベルへのアクセスを提供するポートです。
19 行目で新しいタイプの ReplicaSet を作成し、31 行目にはイメージの名前が含まれ、24 ～ 27 行目はポッドに関連付けられたメタデータを指します。 これはまさにサービスが探しているものであり、接続する必要があるものです。 ファイルの最後には、55 ～ 56 行目と 4 行目との間に、「このサービスを使用してください!」という何らかの接続があります。
そこで、レプリカ セットが存在するときにサービスを開始します。各レプリカ セットには対応するラベルが付いた独自のポートがあるため、サービスに含まれます。 開発者の観点から見ると、サービスを呼び出すだけで、必要なレプリカのセットが使用されます。
その結果、Couchbase Service 経由でデータベース バックエンドと通信する WildFly ポッドができました。 いくつかの WildFly ポッドでフロントエンドを使用できます。これは、couchbase サービスを通じて couchbase バックエンドとも通信します。
後で、クラスターの外側にあるサービスが、その IP アドレスを介してクラスター内にあり、内部 IP アドレスを持つ要素とどのように通信するかを見ていきます。
ステートレス コンテナーは優れていますが、ステートフル コンテナーを使用するとどの程度良いのでしょうか? ステートフルまたは永続コンテナーのシステム設定を見てみましょう。 Docker では、注意が必要なデータ ストレージ レイアウトに対して 4 つの異なるアプローチがあります。 XNUMX つ目は暗黙的なコンテナごとです。これは、couchbase、MySQL、または MyDB の完全なコンテナを使用する場合、それらはすべてデフォルトのサンドボックスから開始されることを意味します。 つまり、データベースに保存されているものはすべてコンテナ自体に保存されます。 コンテナが消滅するとデータも一緒に消滅します。
XNUMX つ目は、コンテナごとの明示的です。docker volume create コマンドを使用して特定のストレージを作成し、そこにデータを保存します。 XNUMX 番目のホストごとのアプローチは、コンテナーに保存されているすべてのものをホスト上で同時に複製するストレージ マッピングに関連付けられています。 コンテナーに障害が発生した場合、データはホスト上に残ります。 後者は、複数のマルチホスト ホストの使用であり、さまざまなソリューションの運用段階で推奨されます。 アプリケーションを含むコンテナはホスト上で実行されていますが、データをインターネット上のどこかに保存したいとします。そのために、分散システムの自動マッピングを使用します。
これらの各方法では、特定の保存場所が使用されます。 暗黙的および明示的なコンテナごとのデータは、ホスト上の /var/lib/docker/volumes に保存されます。 ホストごとの方法を使用する場合、ストレージはコンテナー内にマウントされ、コンテナー自体はホストにマウントされます。 マルチホストの場合は、Ceph、ClusterFS、NFS などのソリューションを使用できます。
永続コンテナーに障害が発生した場合、最初の XNUMX つのケースではストレージ ディレクトリにアクセスできなくなりますが、最後の XNUMX つのケースではアクセスは維持されます。 ただし、最初のケースでは、仮想マシン上で実行されている Docker ホストを通じてリポジトリにアクセスできます。 XNUMX 番目のケースでは、Explicit ストレージを作成しているため、データも失われません。
ホストに障害が発生した場合、最初の XNUMX つのケースではストレージ ディレクトリは使用できなくなりますが、最後のケースではストレージとの接続は中断されません。 最後に、共有関数は、最初のケースではストレージから完全に除外されますが、残りのケースでは可能です。 XNUMX 番目のケースでは、データベースが分散ストレージをサポートしているかどうかに応じてストレージを共有できます。 Per-Host の場合、特定のホスト上でのみデータ分散が可能であり、マルチホストの場合はクラスター拡張によって提供されます。
ステートフル コンテナを作成するときは、これを考慮する必要があります。 もう XNUMX つの便利な Docker ツールは、「バッテリーは存在するが交換する必要がある」という原則に基づいて動作する Volume プラグインです。 Docker コンテナを起動すると、「データベースを使用してコンテナを起動すると、このコンテナにデータを保存できるようになります。」と表示されます。 これはデフォルトの機能ですが、変更することができます。 このプラグインを使用すると、コンテナ データベースの代わりにネットワーク ドライブなどを使用できるようになります。 これには、ホストベースのストレージ用のデフォルトのドライバーが含まれており、Amazon EBS、Azure Storage、GCE Persistent Disk などの外部ストレージ システムとコンテナーを統合できます。
次のスライドは、Docker Volume プラグインのアーキテクチャを示しています。
青色は、青色の Docker ホストに関連付けられた Docker クライアントを表します。この Docker ホストには、データを保存するためのコンテナーを提供するローカル ストレージ エンジンがあります。 緑色はプラグイン クライアントとプラグイン デーモンを示し、これらもホストに接続されています。 これらは、必要なタイプのストレージ バックエンドのネットワーク ストレージにデータを保存する機会を提供します。
Docker Volume プラグインは Portworx ストレージで使用できます。 PX-Dev モジュールは実際には、Docker ホストに接続して実行するコンテナであり、Amazon EBS にデータを簡単に保存できるようになります。
Portworx クライアントを使用すると、ホストに接続されているさまざまなストレージ コンテナのステータスを監視できます。 私のブログにアクセスすると、Docker で Portworx を最大限に活用する方法を読むことができます。
Kubernetes のストレージの概念は Docker に似ており、ポッド内のコンテナーにアクセスできるディレクトリによって表されます。 これらはコンテナの寿命とは無関係です。 使用可能な最も一般的なストレージ タイプは、hostPath、nfs、awsElasticBlockStore、および gsePersistentDisk です。 これらのストアが Kubernetes でどのように機能するかを見てみましょう。 通常、それらを接続するプロセスは 3 つのステップで構成されます。
50 つ目は、ネットワーク側の誰か (通常は管理者) が永続ストレージを提供することです。 これに対応する PersistentVolume 構成ファイルがあります。 次に、アプリケーション開発者は、PersistentVolumeClaim と呼ばれる構成ファイル、または PVC ストレージ リクエストを作成します。これには、次のように記述されます。 10 GB だけ必要です。」 最後の 3 番目のステップでは、リクエストがストレージとしてマウントされ、ポッド、レプリカ セット、または類似のものを持つアプリケーションがその使用を開始します。 このプロセスは前述の XNUMX つのステップで構成されており、スケーラブルであることを覚えておくことが重要です。
次のスライドは、AWS アーキテクチャの Kubernetes Persistence Container を示しています。
Kubernetes クラスターを表す茶色の四角形の中に、黄色で示された XNUMX つのマスター ノードと XNUMX つのワーカー ノードがあります。 ワーカー ノードの XNUMX つには、オレンジ色のポッド、ストレージ、レプリカ コントローラー、および緑色の Docker Couchbase コンテナーが含まれています。 クラスター内部のノードの上にある紫色の四角形は、外部からアクセスできるサービスを示しています。 このアーキテクチャは、デバイス自体にデータを保存する場合に推奨されます。 必要に応じて、次のスライドに示すように、クラスターの外側の EBS にデータを保存できます。 これはスケーリングのための典型的なモデルですが、これを使用する場合は経済的な側面を考慮する必要があります。ネットワーク上のどこかにデータを保存すると、ホストに保存するよりもコストが高くなる可能性があります。 コンテナ化ソリューションを選択する場合、これは重要な議論の XNUMX つです。
Docker と同様に、Portworx で永続的な Kubernetes コンテナを使用できます。
これは、現在の Kubernetes 1.6 用語では「StatefulSet」と呼ばれるもので、Pod の停止と正常なシャットダウンの実行に関するイベントを処理するステートフル アプリケーションを操作する方法です。 私たちの場合、そのようなアプリケーションはデータベースです。 私のブログでは、Portworx を使用して Kubernetes で StatefulSet を作成する方法を読むことができます。
開発面についてお話しましょう。 先ほど述べたように、Docker には CE と EE の 2 つのバージョンがあり、最初のケースでは、毎月更新される EE のバージョンとは対照的に、3 か月に XNUMX 回更新される Community Edition の安定バージョンについて話します。 Mac、Linux、または Windows 用の Docker をダウンロードできます。 インストールすると、Docker は自動的に更新されるため、開始するのは非常に簡単です。
Kubernetes の場合、私は Minikube バージョンを好みます。これは、単一ノード上にクラスターを作成してプラットフォームを使い始めるのに良い方法です。 複数のノードのクラスターを作成する場合、バージョンの選択肢はさらに広がります。kops、kube-aws (CoreOS+AWS)、kube-up (古い) です。 AWS ベースの Kubernetes の使用を検討している場合は、AWS SIG に参加することをお勧めします。AWS SIG は毎週金曜日にオンラインで開催され、AWS Kubernetes の使用に関するさまざまな興味深い資料を公開しています。
これらのプラットフォームでローリング アップデートがどのように実行されるかを見てみましょう。 複数のノードからなるクラスターがある場合、WildFly:1 などの特定のバージョンのイメージが使用されます。 ローリング アップデートとは、各ノード上でイメージ バージョンが次々と新しいものに置き換えられることを意味します。
これを行うには、 docker service update (サービス名) コマンドを使用します。このコマンドでは、WildFly:2 イメージの新しいバージョンと更新メソッド update-Parallelism 2 を指定します。数字の 2 は、システムが 2 つのアプリケーション イメージを更新することを意味します。同時に、10 秒間の更新が 10 秒遅れ、その後次の 2 つのイメージがさらに 2 つのノードで更新されます。 この単純なローリング アップデート メカニズムは、Docker の一部として提供されます。
Kubernetes では、ローリング アップデートは次のように機能します。 レプリケーション コントローラー rc は同じバージョンのレプリカのセットを作成し、この webapp-rc 内の各ポッドには etcd にあるラベルが提供されます。 ポッドが必要な場合は、アプリケーション サービスを使用して etcd リポジトリにアクセスし、指定されたラベルを使用してポッドを提供します。
この場合、WildFly バージョン 3 アプリケーションを実行しているレプリケーション コントローラーに 1 つのポッドがあります。バックグラウンドで更新すると、最後に同じ名前とインデックスを持つ別のレプリケーション コントローラーが作成されます - - xxxxx (x は乱数)同じラベルが付いています。 現在、Application Service には、アプリケーションの古いバージョンを含む XNUMX つのポッドと、新しいレプリケーション コントローラー内の新しいバージョンを含む XNUMX つのポッドがあります。 この後、古いポッドが削除され、新しいポッドを備えたレプリケーション コントローラーの名前が変更され、動作が開始されます。
モニタリングに移りましょう。 Docker には多くの組み込み監視コマンドがあります。 たとえば、docker container stats コマンド ライン インターフェイスを使用すると、プロセッサーの使用状況、ディスクの使用状況、ネットワークの負荷など、コンテナーの状態に関する情報をコンソールに毎秒表示できます。 Docker Remote API ツールは、クライアントがサーバーと通信する方法に関するデータを提供します。 単純なコマンドを使用しますが、Docker REST API に基づいています。 この場合、REST、フラッシュ、リモートという単語は同じ意味です。 ホストと通信するときは REST API です。 Docker リモート API を使用すると、コンテナーの実行に関する詳細情報を取得できます。 私のブログでは、Windows Server でこの監視を使用する方法の詳細を概説しています。
マルチホスト クラスターの実行時に Docker システム イベントを監視すると、特定のホスト上のホスト クラッシュやコンテナー クラッシュ、サービスのスケーリングなどに関するデータを取得できます。 Docker 1.20 以降、既存のアプリケーションにエンドポイントを埋め込む Prometheus が含まれています。 これにより、HTTP 経由でメトリクスを受信し、ダッシュボードに表示できるようになります。
もう 60 つの監視機能は cAdvisor (コンテナ アドバイザの略) です。 実行中のコンテナからのリソース使用量とパフォーマンス データを分析して提供し、すぐに Prometheus メトリクスを提供します。 このツールの特別な点は、過去 XNUMX 秒間のデータのみを提供することです。 したがって、長期的なプロセスを監視できるように、このデータを収集してデータベースに保存できる必要があります。 Grafana または Kibana を使用してダッシュボード メトリクスをグラフィカルに表示するために使用することもできます。 私のブログには、cAdvisor を使用して Kibana ダッシュボードを使用してコンテナーを監視する方法が詳しく説明されています。
次のスライドは、Prometheus エンドポイントの出力がどのようなものであるか、および表示できるメトリクスを示しています。
左下には HTTP リクエスト、レスポンスなどのメトリクスが表示され、右側にはそれらのグラフィック表示が表示されます。
Kubernetes には組み込みの監視ツールも含まれています。 このスライドは、XNUMX つのマスター ノードと XNUMX つのワーカー ノードを含む一般的なクラスターを示しています。
各動作ノードには、自動的に起動される cAdvisor が含まれています。 さらに、Kubernetes バージョン 1.0.6 以降と互換性のあるパフォーマンス監視およびメトリクス収集システムである Heapster があります。 Heapster を使用すると、ワークロード、ポッド、コンテナーのパフォーマンス メトリックだけでなく、クラスター全体によって生成されたイベントやその他のシグナルも収集できます。 データを収集するために、各ポッドの Kubelet と通信し、情報を InfluxDB データベースに自動的に保存し、それをメトリクスとして Grafana ダッシュボードに出力します。 ただし、miniKube を使用している場合、この機能はデフォルトでは利用できないため、監視にはアドオンを使用する必要があることに注意してください。 したがって、それはすべて、コンテナーを実行する場所と、デフォルトで使用できる監視ツールと個別のアドオンとしてインストールする必要がある監視ツールによって異なります。
次のスライドは、コンテナの実行ステータスを示す Grafana ダッシュボードを示しています。 ここには非常に興味深いデータがたくさんあります。 もちろん、SysDig、DataDog、NewRelic など、商用の Docker および Kubernetes プロセス監視ツールが多数あります。 中には30年間の無料お試し期間を設けているものもあるので、自分に合ったものを試してみることができます。 個人的には、Kubernetes とうまく統合できる SysDig と NewRelic を使用することを好みます。 Docker プラットフォームと Kubernetes プラットフォームの両方に同様にうまく統合できるツールがあります。
いくつかの広告 🙂
いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 , 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。
アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む
出所： habr.com