ポッド容器のデザインパターンと感謝
理解ポッドやコンテナのデザインパターン：本論文では、共同で4整理ネイティブクラウド技術のオープンクラスCNCFとアリババからレッスンを終えました。私たちが見逃してはならない、ポッド、ポッドの実装メカニズムとコンテナ詳細な設計パターンを導入する必要がある理由はもちろん、アリババA上級技術専門家、CNCF公式大使張レイです。
以下の三つの部分の周りのコースの公転を共有：
- なぜポッド;
- ポッドの実装機構と、
- 詳細コンテナのデザインパターン。
まず、なぜ必要ポッド
コンテナの基本的な考え方
さて、最初の質問を見てください：なぜ我々は、ポッドが必要なのでしょうか？私たちは、ポッドはKubernetesの非常に重要な概念の内部プロジェクトが、また、スケジューリングの非常に重要な1個の原子単位であることを知っているが、なぜ私たちは、このような考え方が必要なのでしょうか？私たちは、コンテナドッカーのを使用する場合は、そのような文はありません。あなたはポッドを理解したい場合は実際には、我々は、第一の容器の概念を見てそうまず、コンテナを理解する必要があります。
容器の性質は、実際のプロセスであり、ビューは、リソースに制約のあるプロセスを単離します。
プロセス我々はマシンの管理にあるので、PID = 1は、仮想マシンの管理手段は、管理インフラストラクチャに等しくアプリケーション自体を、あるコンテナが、コンテナの管理は、アプリケーション自体の直接的な管理に等しかったです。これは不変のは最高の体現インフラの前に言って、この時間は、アプリケーション、インフラストラクチャに相当し、それは不変でなければなりません。
前提上記の例の場合、Kubernetesそれは何ですか？私たちは、そうならば、これはオペレーティングシステムソフトウェアのインストールパッケージの血管像であるので、これは、非常に興味深いです、多くの人々はクラウドオペレーティングシステムのKubernetesの時代であると言うことを知って、類推は、それらの間の関係です。
オペレーティング・システムの実例
Kubernetesは、オペレーティングシステムであれば、我々は、実際のオペレーティングシステムの例を見て可能性があります。
HelloWorldのと呼ばれるプログラムがある例としては、HelloWorldのは、このプログラムは、実際のプロセスは、Linuxのスレッドに実質的に同一であることのプロセス、ここでノートを取る必要のセットで構成されています。
LinuxはあなたがLinuxシステムからpstreeコマンドでHelloWorldのを見に行く場合は、スレッド内の軽量プロセスであるため、このHelloWorldのは、実際には4つのスレッド、すなわち、で構成されて表示されます{API、メイン、ログ、コンピューティング}。言い換えれば、このような4つのスレッドは、実際の作業状況のHelloWorldプログラムを形成し、リソースのHelloWorldプログラムを共有し、連携して動作します。
これは、上記概念的なプロセスグループであり、プロセスまたはスレッドグループ内のオペレーティング・システムは、非常に現実的例に設定されています。
次に、実際のオペレーティングシステムでは、プログラムは、多くの場合、プロセスグループに従って管理され、考えることを望むかもしれません。KubernetesのアナロジーはそれはLinuxなどのオペレーティング・システム、です。我々は先に述べたコンテナの場合、それは、Linuxのスレッドの前にあるプロセスと比較することができます。ポッドは、それは何ですか？ポッドはどこのLinuxスレッドグループであること、実際には我々だけ言及しているプロセスグループです。
プロセスグループのコンセプト
それはプロセスグループになると、最初にすべてのあなたは、少なくとも概念的に理解していることを示唆している、我々は詳細に説明します。
または、前の例：4つのプロセスからなるHelloWorldのプログラムは、これらのプロセスの間でいくつかのリソースとファイルを共有することになります。だから今の質問はあります：あなたは、コンテナのHelloWorldプログラム稼働して、今それを言うならば、あなたはそれをどのように行うのでしょうか？
もちろん、最も自然な解決策の一つは、私は今、4つのプロセスを実行しますドッカーコンテナを、開始することです。しかし、これでプロセス容器内部PID = 1は？例えば、それは私のメインコースである必要があり、その後の質問はまた、残りの3つのプロセスを管理する責任がある「誰が」、ある場合には、そのような問題がありますそれは？
コアの問題は、コンテナ自体のデザインは、「単一プロセス」のモデルであるということであるコンテナは一つのプロセスだけを再生することができますという意味ではありません、コンテナのアプリケーションのためには、プロセスに等しく、それが唯一のPID = 1のプロセスを管理するために行くことができ、その後、他のアップ実際には、プロセスが管理された状態です。だから、サービスアプリケーションのプロセス自体は、「プロセス管理」する能力を持っています。
例えば、プログラムは、HelloWorldシステムへ、または直接直接にsystemdに容器1 PID =処理する能力、そうでないアプリケーション、またはコンテナがプロセスの数を管理する方法はありませんを有しています。PID = 1は、アプリケーション・プロセスそのものであるため、我々は、プロセスを殺すために、このPID = 1を入れたり、操作が死亡した時に、自身の場合、誰が回収されなかったリソースの残りの3つのプロセスは、これは非常に、非常にあります深刻な問題。
そして、本当にsystemdにアプリケーション自体にこれを回す、または他の問題につながるコンテナ内にsystemdを実行します。もはや、アプリケーション自体を管理している船舶の管理を行う、経営が等しいにsystemdにしている間、ここに問題は非常に明確です。例えば、私は、コンテナプログラムまたはプロセス内で実行にsystemdされ、その後、次のは、これはアプリケーションの外ではないでしょうか？それを失敗していませんか？珍しい故障ではないですか？容器がsystemdにによって管理されているので、直接知っているのは実際に方法はありません。これは、多くの場合、より困難な容器内部の複雑なプログラムを実行する理由の一つです。
ここで再び整理をお手伝い：コンテナは、実際に「単一プロセス」のモデルであるので、あなたが容器内の複数のプロセスを起動するのであれば、一つだけは、プロセスPID = 1、およびこの時間として使用することができPID = 1の場合プロセスがハングアップ、または終了に失敗し、その後、他の三つのプロセスが自然に孤児となり、誰もがそれらを管理することはできません、誰もが、これは非常に悪い状況で、そのリソースを回復することはできません。
注：Linuxコンテナの「単一工程」モデル、容器のライフサイクルを参照すると、容器が複数のプロセスを作成できません。PID = 1（コンテナアプリケーションプロセス）ライフサイクルではなく、そのプロセスと等価です。もちろん、通常の状況下では、コンテナアプリケーション・プロセスはとてもあなた異常終了一度（例えばsshの終端として）、コンテナ内に作成されているのexec sshまたは他のプロセスによっては、孤立したプロセスになることは非常に容易であること、プロセスを管理する能力を持っていません。
ターンでは、実際には、systemdには、他のすべてのプロセスを管理するためにそれを使用して、コンテナ内で実行することができます。これは、第二の問題を作成します。実際には、直接への道は自分のアプリケーションを管理していない、私のアプリケーションは、systemdに引き継がなければので、この時点でのアプリケーションの状態のライフサイクルは、コンテナのライフサイクルと同じではありません。この管理モデルは、実際には非常に、非常に複雑です。
ポッド=「プロセスグループ」
内部kubernetesでは、ポッドは、実際にそれはあなたのプロジェクトのためのkubernetesは、グループの概念に類似したプロセスから抽象化することが可能です。
先に述べたように、アプリケーションのHelloWorldで構成される4つのプロセスでは、ポッドは、4個のコンテナを持っているとして、実際に定義されますKubernetesに、我々はこの概念を理解することは非常に慎重でなければなりません。
4人の異なる責任、相互のコラボレーションプロセスは、今そこにあることを、二つの問題が発生しますので、容器に入れていないKubernetesに、コンテナ上で実行して行く必要があります。だから、あなたはそれでKubernetesでそれをどのように行うのでしょうか？これは、プロセス4個の4つの別々のコンテナが起動され、そしてそれらはポッドと内部で定義されているの分離を行います。
Kubernetes HelloWorldのは、あなたが実際に4個のコンテナを見たとき、彼らは特定のリソースを共有プルアップする際に、これらのリソースは、ポッドに属し、我々はKubernetesでポッドを言ったので、だから、唯一つの論理ユニットではなく、本当がありますこれは言っポッドに対応したものです、そしていくつかはしません。何かまで実際に、4つのコンテナである、物理的に存在します。4つのコンテナ、またはポッドと呼ばれる複数の容器の組み合わせ。そして、あなたは、特定のリソースを共有するコンテナの内側には、ポッドはまた、原子ディスパッチ単位をKubernetesのでKubernetesポッドは、資源の配分の単位で、非常に明確なコンセプトがなければなりません。
ポッドの設計は、上述の、またKubernetesは、彼らが出たいプロジェクトが、早くもGoogleのR＆Dのボルグとして、それはこのような問題ことが判明しました。これは、ボルグ紙に非常に、非常に明確な説明があります。Googleのエンジニアは、アプリケーションの展開、次のボルグで見つけ簡単に言えば、多くの場面での「プロセスとプロセスグループ」と同様の関係があります。具体的には、彼らは同じマシン上に展開する必要がありそうということ、これらのアプリケーションの前の協力の緊密な関係を持っており、特定の情報を共有する傾向があります。
これらは、プロセスグループの概念が、また、ポッドの使用状況です。
なぜポッドスケジューリングの原子単位でなければなりませんか？
ここでは、いくつかの問題がある可能性があります：このグループについての事はプロセスですが、なぜそれのうち抽象的な概念としての地位をポッド必要がありますが？または、この問題をスケジュールすることにより、ポッドは、それを取り除くためにすることができますか？なぜポッドは、スケジューリングの原子ユニット内部Kubernetesでなければなりませんか？
下には、我々は例を挙げて説明します。
二つの容器がある場合、それらは密接に協力しているので、彼らはポッドの内部に配置する必要があります。具体的には、第一の容器は、サービスコンテナである、それはログファイルを書き込みますアプリケーションと呼ばれ、第二の容器は、LogCollectorがと呼ばれ、前方にそれだけでElasticSearchバックエンドへのAppコンテナログファイルを書き込みます。
リソースは、これは二つの容器を必要とする：アプリケーションコンテナはメモリ、LogCollectorが必要と0.5Gメモリの1Gを必要とし、現在のクラスタ環境で使用可能なメモリは、このような状況です：ノードA：1.25Gメモリ、ノードB：2Gメモリを。
あなたは何も今ポッドの概念を言っていない場合は、2つだけのコンテナ、二つの容器は、単一のマシン上で実行されている緊密なコラボレーションであることを。スケジューラ最初のアプリは、上記ノードAに予定している場合しかし、その後、何が起こるのだろうか？次に、あなたが見つける：LogCollectorが、実際にリソース不足のノードAをスケジュールする方法はありません。実際には、アプリケーション全体自体が問題を持っているこの時間は、スケジュールが失敗した、再スケジュールする必要があります。
上記は、グループスケジューリング障害の非常に典型的な例です。英語が呼び出されます。タスクの同時スケジューリング問題、問題はそれが多くのプロジェクトは、このような問題が解決策を持っている、解決できないと言うことではありません。
例えば、Mesosの内部には、それは買いだめ資源（リソース買いだめ）と呼ばれる事でしょう。すべては親和タスクに達した制約を設定した場合に、ある、統一始め、これは非常に一般的なグループスケジューリングソリューションです。
「アプリケーション」と「LogCollectorが」は、これら2つの容器がMesosでは、前述した、と彼らはすぐにスケジュールが、そうで両容器とが完全に提出されて言うことはありませんので、統一始まりました。また、すべてのスケジューリング効率がために待機する必要性が失われている最初の、新たな問題をもたらすでしょう。状況が生じてしまうの外に待機することが必要となりますので、デッドロック、お互いを待っている状況です。これらのメカニズムMesosは、それはまた、追加の複雑さをもたらし、対処する必要があります。
別の解決策は、Googleのソリューションです。それは楽観的スケジュールと呼ばれる非常に複雑で、非常に強力なソリューションを、作られたオメガシステム（ボルグは、次の世代である）の内側にあります。たとえば、次のようにこれらの競合の異常事態、最初のスケジューリング、どうかと葛藤した後、背中を丸めることによって、問題を解決するためにそうすることを、非常に微妙なロールバックメカニズムを設定します。比較的よりエレガント、そしてより効率的にするための方法が、その実装のメカニズムは非常に複雑です。この多くの人々は、それは悲観的ロックの設定は楽観的ロックよりも単純でなければならないで、理解することができます。
そして、タスクの同時スケジューリング問題のように、中Kubernetesに、直接、このようなAのコンセプトポッドによって解決してください。問題は存在しないですのでKubernetesであるため、このようなA LogCollectorがアプリケーションコンテナとコンテナ内に、必然的にスケジューリングにおけるポッドのスケジューリング単位であるポッド、に属している必要があります。
ポッドは再び理解します
そのような知識の前で話すの後、私たちは、第一の容器内部ポッド、ポッドが何であるかを改めて理解しなければならない「スーパー親密な関係。」
ここでは、我々はすべて理解しておくべき「スーパー」という言葉、親密と呼ばれる関係があることが普通である、親密が一定であるスケジューリングを通じて解決することができます。
例えば、2ポッドは今がある、彼らはそれが親密な関係に属していることを、スケジューラは確かに助けを行うことができ、同じホスト上で実行する必要があります。しかし、超親密な関係のために、それはポッドで解決しなければならないという問題点があります。スーパー密接な関係が与えられていない場合ので、その後、全体ポッドまたはアプリケーション全体を起動することはできません。
スーパー親密な関係とは何ですか？大まかに次のカテゴリに分類：
- 2つのプロセスが、前述の間例えば、ファイル交換が行われますその一例である、雑誌、読書ログを書き込みます。
- 2つのプロセスがローカルであるか、ソケットが通信するローカルホストする必要がある間、これは超ローカル通信親密です。
- 二つの容器またはマイクロサービス間で、パフォーマンス上の理由から、非常に頻繁にRPC呼び出しを発生する必要があり、彼らはスーパー親密な関係であることを望みます。
- 二つの容器または一部のLinux名前空間を共有する必要があるアプリケーションに最適です。単純な、最も一般的な例では、私は別の容器にネットワーク名前空間コンテナを追加する必要があります。だから私は、別の容器へのネットワークデバイス、およびそのネットワークの情報を見ることができます。
さらにいくつかの関係よりも、スーパー親密な関係をしているように、彼らはポッドの概念を通過しますKubernetesで解決されています。
今、私たちは、あなたがポッドを必要とする理由を理解するために、このようなポッドのコンセプトデザインを理解していること。これは、2つの問題を解決します。
- 私たちはどのように超親密に記述する。
- どのように我々は超親密な関係のための容器を行ったり、ビジネスを行うことはポッドの最も重要な要求の一つである、統一されています。
二、ポッドの実装メカニズム
ポッド解決すべき問題は、
ポッド、自分自身のようなそのような事は論理的な概念です。マシン上にあること、それがあるかどうかをどのようにそれを達成するには？これは、我々は2番目の質問を説明したいものです。
そのポッドは、この問題を解決するので、コアは、特定のリソースとポッドで複数のコンテナ間でのデータの最も効率的な共有を作成する方法です。
容器との間もともとLinuxの名前空間とのcgroupで区切られたので、解決することになりまし実用的であるこの分離を壊した後、特定の物事や特定の情報を共有する方法です。これは、ポッドは、コアの問題を解決するために設計されています。
ネットワークおよびストレージ：だから具体的な解決策は、2つの部分に分かれています。
1.共有ネットワーク
最初の質問はどのように共有ネットワークへのポッド以上の容器中にありますか？次に例を示します。
例えば、容器Aと2つのネットワーク名前空間を共有する必要がある容器Bを含み、ポッドは、今あります。Kubernetesでは溶液中でこれです：それは全体のポッドネットワーク名前空間の小さな共有に各ポッド、コンテナから追加のインフラコンテナになります。
インフラコンテナは、100〜200キロバイト程度、アセンブリ言語で記述され、非常に小さなミラーであるコンテナ「一時停止」状態に常にあります。こうしたインフラコンテナとそれ以来、他のすべてのコンテナが経由して名前空間に参加中のネットワークの名前空間インフラ・コンテナに追加されます。
内部のすべてのコンテナポッドがそう、彼らはネットワークのビューがまったく同じである参照してください。それは次のとおりです。彼らはこの1が作成された初めてのインフラコンテナポッドから来て、実際には、全体で、ネットワーク情報に関連付けられているなど、ネットワーク機器、IPアドレス、MACアドレスを、参照してください。これは、ポッドのネットワーク共有を解決するためのソリューションです。
IPアドレスがなければなりませんしたポッドは、対応するネットワークのネームスペースポッドのアドレス、およびまた、IPアドレスインフラコンテナです。私たちが見るようで、他のすべてのネットワーク・リソースは、ポッドAおよびポッドは内のすべての船舶で共有されています。これは、ポッドのネットワーク実装です。
そのための必要性の中間容器を言ったために対応が存在し、ポッド内部の全体は、インフラコンテナは最初に起動する必要があります。ポッド及び全ライフサイクルライフサイクルインフラ容器、AおよびBは独立している容器に相当します。この操作を行うには、全体のポッドは再構築しません、それは設計に非常に重要であり、それは再起動しません、：Kubernetesの内部が、それはつまり、鏡1個体におけるポッドを更新するために許可されている理由です。
2.共有ストレージ
2番目の質問：ポッドどのように共有ストレージに？ポッドは、ストレージが比較的単純で共有しました。
例えば、今、二つの容器があり、一つはnginxのは、他のは、nginxの中でいくつかの論文を置くためにnginxのアクセスを通じて、私を聞かせて、非常に一般的なコンテナである、です。だから、このディレクトリを共有する必要があります。私は実際には、ボリュームがポッドレベルになると、ファイルを共有したり、非常にシンプルであるポッド内のディレクトリを共有しています。そして、すべてのコンテナは、彼らはすべての共有ボリューム、すべてが同じポッドコンテナに属していることです。
例えば、上記の例では、このボリュームが共有データと呼ばれ、これはポッドレベルに属し、したがって各容器に直接陳述することができる。限り、あなたは、あなたがボリュームをマウントすることを宣言するように、このボリューム共有データをマウントするには、あなたは、実際に私たちは同じものであることがわかり、容器の中にこのディレクトリに移動します。これは実際に貯蔵容器を共有するポッドでKubernetesです。
だから、前の例では、アプリケーションコンテナアプリケーションは限り文が同じボリュームをマウントするよう、限りログがボリュームに書かれているように、日記を書き、ボリュームはすぐに参照するには、別のLogCollectorがコンテナことができます。これらは、ポッドを達成するための方法で保存されます。
第三に、詳細設計パターンコンテナ
ポッド、ポッドも最後にこの事を理解しては達成する方法である理由今、私たちは知っています。最後に、これに基づいて、Kubernetes非常に提唱者の概念を詳しく見てみると、コンテナのデザインパターンと呼ばれます。
例えば
次は、例を挙げて説明してあなたに来ます。
例えば、私は今、非常に一般的なものの魅力を持っている：私は今、アプリケーションを公開すると、アプリケーションはJavaで書かれている、バッグWAR TomcatのWebアプリケーションディレクトリに置く必要があるが、あなたがそれを起動することができるように、そこにあります。しかし、Tomcatのパッケージまたは、このようなAの例コンテナのようなWAR、実行する方法を、どのように公開するには？そして、いくつかの慣行があります。
実施例：WARとTomcat内部ミラーにパッケージすることができます。しかし、今鏡である問題が、実際にはこのプレゼントは2つのことにそれをこします。それでは、私はWARを更新するかどうか、私はTomcatを更新することを、あなたはもっと面倒で新しいイメージを、再しなければなりません。
第二の方法：Tomcatのパッケージのみミラーがあります。それは内部の、このコンテナは、後でそれを可能にするので、私のウェブAPPディレクトリにぶら下がって、私たちのTomcatの容器にマウントし、ホストからWARに、Tomcatのですが、データ量は、そのようなホストパスを使用する必要がありますあなたはそれを使用することができます。
しかし、この時間は、問題を見つけます。このアプローチは確かに分散ストレージシステムを維持する必要があります。コンテナは、最初の上記のホストAで開始することができますので、Bを再起動する2番目の時間は、移行することができるコンテナです何かを上がることがあり、その状態が維持されていません。データを検索、容器AまたはBにおいて、WARパッケージに見出すことができるかどうか、分散ストレージシステムを維持することが必要です。
でも、分散ストレージシステムでは、あなたはまた、WARパッケージにボリュームを維持する責任があるとボリュームを必要としないことに注意してください。例えば：あなたは、アプリケーションを起動し、それぞれの開始前にKubernetesボリュームプラグインのポッドのための単一のセットを記述する必要がマウントを適用することができます使用し、その後、ボリュームにWARパッケージを必要と。
この操作は、まだ比較的高く、容器自体が（WARパッケージの内容のボリュームを管理するために使用される）持続性メモリカードに依存しなければならない複雑さをもたらします。
InitContainer
したがって、我々は考慮していない、この組み合わせのように、これ以上の一般的な方法はありませんか？でも地元Kubernetesに、いかなる状況でも、分散ストレージを使用することはできませんの下で、あなたは解放することができ、再生することができます。
実際、初期コンテナと呼ばれるこの組み合わせ、のようなKubernetesの内部での方法があります。
最初の初期化コンテナを定義し、それだけで一つのことは、ボリュームの内側に鏡画像からWARパッケージをコピーすることではない、それは仕上がりからこの操作を撤回し、マップ上のYAMLで、その初期コンテナ：一つの例は同じですユーザーは、容器の前に、注文を実行するために、定義に厳密に従って開始されます。
そして、鍵はコピー先のディレクトリにちょうどそのようなコピーです：APPディレクトリは、実際のボリュームです。そして、我々は、以前のポッド内部の複数の容器を述べ、ボリューム彼らはTomcatコンテナ、ちょうどパッケージミラーTomcatは今、共有することができます。しかし、それは私のボリュームとしてAPPディレクトリの使用を宣言するために、開始し、Webアプリケーションのディレクトリにマウントするためにそれらを取るとき。
そのsample.war、絶対にすでにこのボリューム内に存在する：WARアプリケーションのために存在していたこのボリュームはそうと、この時間は、すでに初期化コンテナを介して実行されているように、コピー操作のために完了しました。実行時までの第二段階は、フロントsample.warの内部のコピーを見つけることができるように、ボリュームをハングアップするために、Tomcatコンテナを起動します。
このようにして記述することが可能である：ポッドは自己完結型で、ポッドを置くことができます成功し、世界上記のいずれかKubernetesで有効になっています。程度に分布していないストレージを心配しないで、ボリュームは、それが公開されている必要があり、永続的ではありません。
これには、コンテナの二つの異なる役割を組み合わせることで、このような方法で、そのような構成でアプリケーションのそのような数は、初期コンテナをデパッキング均一な画像は、ポッドは非常に典型的な例でそれを行います。「サイドカー」：と呼ばれる非常に古典的なコンテナのデザインパターン、あるKubernetesでこのような概念、。
容器のデザインモード：サイドカー
サイドカーとは何ですか？前の例を引用している事実は、ポッドの内部には、あなたには、いくつかの補助作業メインコンテナー・ビジネス・ニーズを実行するために、特別なコンテナを定義することができるなど、実際には、それはサイドカーで、事、初期コンテナを行っているでしょうそれはそれらのTomcatを使用できるようにするように、共有ディレクトリにコピーされたWARの鏡像を担当しています。
他の操作は、それは何がありますか？例えば：
もともと行うには、コンテナのSSHの必要性の内部で何かをする必要があり、スクリプトを書くことができ、事前条件の数は、実際には、サイドカー、またはinitコンテナ等を介して解決する別の方法のようにすることができます。
もちろん、この典型的な例があるがある私のログ収集、ログ収集自体プロセスは、その後、あなたがこのコレクション内で行うことをポッドにそれをパッケージ化することができ、小型のコンテナです。
別の非常に重要なことは、今のデバッグ、アプリケーション全体が再び内部の追加の小さなアプリケーションポッドコンテナを定義することができ、実際に、それは幹部のアプリケーションの名前空間ポッドを行くことができ、デバッグアプリケーションです。
それを行うことができるということです条件を、作業他のコンテナを表示します。同じ操作を監視することもできるので、サイドカーは、コンテナの主な事業とのコラボレーションに、起動としてそれを使用し、その後、限り監視コンポーネントが内部の追加の小さなコンテナに取り付けられたとして、コンテナを参照するにはログインするSSHに不要になりましたでそれを行うにはサイドカー方法。
この練習は非常に明白な利点は、私が独立サイドカーコンテナを解放することができたので、アクセシビリティは、私のサービスコンテナから分離するという事実である、そしてもっと重要なのは、この機能を再利用することができ、それはサイドカーの監視と同じですまたはログサイドカーは、会社全体で共有することができます。これは、強力なデザインパターンです。
サイドカー：アプリケーションとログ収集
次に、我々はこのようなモデルのサイドカー詳細な洗練を見てみましょう、それはまた、他の多くのシナリオがあります。
例えば、アプリケーションログ収集、書き込みログボリューム内部で、前述のサービスコンテナ、および共有されるボリュームポッド、ようにそのコンテナログ - 即ち容器が直接ログファイルに、ボリュームによって共有されなければならないサイドカー読み出され、その後、リモートストレージ内部に格納された、または別の例に転送します。今、業界共通Fluentdログプロセスまたはログコンポーネントでは、基本的にこのように動作します。
サイドカー：エージェントコンテナ
第2の使用サイドカー、それはプロキシコンテナプロキシとして呼び出すことができます。剤容器、それは何と呼ばれますか？
ポッドがある場合は、今、外部システム、またはいくつかの外部サービスが、これらの外部システムにアクセスする必要があるクラスタでは、この統一どのように時間と簡単な方法は、IPアドレスを使用して、これらのクラスタがアクセス権を持って置きますか？コードを変更します。一つの方法は、することです。これらのクラスターに記録されたアドレスコードがあるため、また、プロキシ容器サイドカーによって、すなわち、デカップリングする方法があります。
単純に、単一の書き込みこのような小さなプロキシは、それを外に1つのIPアドレスのみを暴露された外部ドッキングサービスのクラスタを、処理するために置きます。それでは、容器本体のアクセスプロキシサービス、およびこれらのサービスがプロキシ・クラスタに接続されている彼らは、同じネットワーク名前空間、ネットワークの同じビューに属しているので、ここではポッドキーは、直接通信localhostを通じ、複数の容器があることがあり、彼らはそう二つの通信はlocalhost、およびパフォーマンスのロスなし。
だから、デカップリング剤容器の外側を行うことに加えて、および劣化性能が、もっと重要なのは、プロキシコンテナコードのように、会社全体で再利用することができません。
サイドカー：コンテナアダプタ
サイドカー第3の設計モード - コンテナアダプタアダプタは、アダプタは何をしますか？
今、ビジネスさらさAPIは、例えば、APIの形式はAであり、今はそうである仕事を、行うには、APIのBがあり、それは1つのフォーマットのみを知っている私のコンテナー・ビジネスを訪問行くための外部システムがあり、どのようにビジネスのコードを変更しようとして、コンテナー・ビジネスを取り除くための方法を見つけること。しかし、実際には、あなたが変換層のアダプターにより、これを行うことができます。
今例：今インタフェースを監視さらさコンテナがある/メトリクス、この容器のURLのメトリックを訪問し、ビジネスを得ることができます。しかし、今、これは監視システム、それがあるURLへのアクセス/健康をアップグレードし、私が唯一知っ監視を行うために、健康のヘルスチェックURLを公開し、メトリックは知りません。次に、どのようにこれを行うには？このアダプタの外部被曝はURLを監視し、そのような健康であるので、それはコードを変更する必要があるだろうが、あなたはそれのメトリックに転送健康のためのすべての要求のためのコードが、追加の書き込みアダプタを、変更することはできません。あなたのビジネスや缶の仕事上、どの缶、。
ポッドの間でコンテナ内のこのキーの嘘はありませんので、性能の損失はありません、直接通信によりローカルホストされており、このような容器は、これらのデザインパターンの利点は、私たちをもたらしたが、アダプター会社全体を再利用することができます。
このセクションでは、要約したもの
- ポッドは、「コンテナのデザインモード」コアメカニズムの実現にKubernetesプロジェクトです。
- 「コンテナのデザインモードでは、」グーグルボルグは、大規模なコンテナクラスタ管理のベストプラクティスの一つでもKubernetesは、複雑なアプリケーションの振り付けに依存する基盤の一つです。
- すべての自然「デザインモード」は、次のとおりです。デカップリングと再利用。
インストラクターのレビュー
Kubernetesシステム内部ポッドやコンテナのデザインパターンが最も重要なポイントの基本的な知識である、私は読者が慎重に把握し、マスターしようとすることができます願っています。ここでは、私はあなたが会社やチームでの使用ポッド独自の方法で新鮮な表情の前に行く示唆、それの設計多かれ少なかれ採用し、いわゆる「リッチコンテナ」ではないでしょうか？このデザインは、非常に悪い運用・保守習慣の多くを訓練します、唯一の過渡的形式です。私は強くあなたが徐々にコンテナのデザインが豊富なコンテナのデカップリング、ポッドを形成するために、複数のコンテナに分割して思考のパターンを採用することを示唆しています。現在進行中のキャンペーンの現在のアリババ「包括的なクラウドは」仕事の重要なコンテンツを促進するためには、このためです。