docker では、pod は複数のコンテナーを組み合わせた実行単位を意味します。pod は Kubernetes の基本単位です。これは、複数のプロセスを「名前空間」にパッケージ化した、コンテナーの拡張または強化されたコンテナーとみなすことができます。 、ポッドを形成し、ポッド内のさまざまなプロセスのアプリケーション パッケージ化は依然として独立しています。
このチュートリアルの動作環境: linux7.3 システム、docker バージョン 19.03、Dell G3 コンピューター。
ポッドは、マルチコンテナーの実行ユニットと Kubernetes の基本ユニットを組み合わせたものです。これは、コンテナーの拡張または強化されたコンテナーと考えることができます。ポッドにはメイン コンテナといくつかの補助コンテナが含まれており、これらが連携して特定の機能を完了します。複数のプロセス (コンテナも独立したプロセスです) が名前空間にパッケージ化されると、ポッドが形成されます。ポッド内のさまざまなプロセスのアプリケーション パッケージ化は依然として独立しています (各コンテナーは独自のイメージを持ちます)。
Pod の意義は、メイン コンテナの独立性を保ちながら、メイン コンテナと補助コンテナの密接な関係を維持できることです。メイン コンテナと補助コンテナは同じライフ サイクルを持ち、同時に作成および破棄できるため、それらを Pod に配置すると、相互作用がより効率的になります。
一方、メイン コンテナはいくつかの主要なタスクを完了する必要があり、他のタスクは共通である場合があり、個別にパッケージ化して補助コンテナによって実行できます。
拡張知識
コンテナとは何ですか?
コンテナについては人によって異なる視点があるため、コンテナを正確に定義するのは簡単ではありません。 Liu Junhui 氏の見解では、コンテナはコンピューティング ユニットを提供する手段であるだけでなく、アプリケーションのパッケージ化の一形態でもあります。
#- コンテナはコンピューティング ユニットです
コンピューティング ユニットとして、コンテナはスレッド、プロセス、仮想マシン、または物理マシンと同じです (図を参照)下図）。連続スケールで見ると、分離、セキュリティ、オーバーヘッドは左に行くほど低くなり、右に行くほど高くなります。コンテナは、プロセスと仮想マシンの間のコンピューティング ユニットです。
ただし、すべてのアプリケーションがコンテナに適しているわけではなく、開発者は、独自のアプリケーションの特性とニーズに基づいて、最適なコンピューティング ユニットを選択できます。たとえば、アプリケーションが高性能で、相互に信頼しており、同じ管理領域にある場合は、スレッドまたはプロセスで十分ですが、アプリケーションがマルチテナントであり、他のアプリケーションと同じスペースで実行される場合は、スレッドまたはプロセスが必要です。データの漏洩やパフォーマンスへの影響を防ぐために、これらのアプリケーションを安全に分離する方法を検討してください。現時点では、コンテナーが良い選択になる可能性があります。
アプリケーション開発の経験がある人なら誰でも、アプリケーションが単一の実行可能ファイルではなく、少し複雑なファイルであることを知っています。 Yidian のアプリケーションは、コード、実行可能ファイル、構成の依存関係、外部依存関係 (ダイナミック リンク ライブラリ) などを含む複数の部分で構成されています。
したがって、配布パッケージを適用するときは、ターゲット オペレーティング システムのバージョン、システム アーキテクチャ、依存するモジュールなどの要素を考慮する必要があります。そうしないと、アプリケーションのインストール時にシステムのさまざまな部分が変更されてしまいます。
アプリケーションのパッケージングとして、アプリケーションの独立性と移植性を実現していることが最大の特徴であり、コンテナ自体にアプリケーションの依存関係がすべて含まれているため、あらゆるインフラ上で動作することが可能です。システムのバージョンとアーキテクチャの問題が原因で発生する可能性があります。
簡単に言えば、Docker は非常に成功したコンテナ管理プラットフォームとみなすことができます。 Docker の最も重要な部分は、その実行管理環境です (次の図を参照)。 
前述したように、コンテナはコンピューティング ユニットであり、Docker 実行環境はこれらのコンピューティング ユニットの作成、管理、破棄に使用されます。これらのコンピューティング ユニットを作成および管理するときは、コンピューティング ユニットのパッケージ化 (つまり、そのソフトウェア配布パッケージ) を使用する必要があります。これらのパッケージは、コンテナ イメージの形式で実行環境に保存されます。すべてのコンテナ コンピューティング ユニットは、これらのイメージが作成されます。
ただし、イメージ自体にはバージョン リリース、アップグレード、その他の要件があり、これには Docker のもう 1 つの重要なコンポーネントである DockerHub が関係します。 DockerHub は Apple の App Store に似ており、非常に大規模な「コンテナ マーケット」であり、一般的に使用されるソフトウェアはすべて DockerHub で見つけることができます。
Docker の最後の重要なモジュールは、コンテナーの実行環境にコマンドを発行したり、ステータスを表示したりするために使用されるユーザー インターフェイスと管理ツールです。 Docker コマンドを使用し、いくつかのパラメーターを追加するだけで、コンテナーの作成、削除、実行ステータスの表示を行うことができます。
次に、Docker の実際の動作を見てみましょう、Hello World コンテナを実行する場合を例に、Docker の使い方について説明します。実際、Docker をインストールするだけで、この Hello World コンテナーを実行してみることができます。
次のコードを通して、Docker の動作を見てみましょう: 
まず、Docker が最新バージョンの Hello World をローカルで探していることがわかります。このイメージがない場合は、DockerHub にアクセスしてダウンロードしてください。次に、イメージが実行され、Docker がバックグラウンドでそのようなコンテナーを作成します。
Docker の登場により、コンテナ アプリケーションの管理が非常に簡単になり、コンテナの実行に必要なコマンドは 1 つだけです。 DockerHubからのイメージのダウンロード、各種隔離環境の作成、コンテナや外部ネットワークの通信環境の作成はすべてDockerで完結できます。 Docker はコンテナのライフサイクル全体を管理できると言えます。
コンテナの概要として、コンテナの最大の特徴は軽量で完全に独立したデプロイメントであると要約できます。これら 2 つの特性は、クラウド ネイティブの柔軟な無制限の拡張性とオンデマンドの使用と非常に一致しており、このため、コンテナーはクラウド ネイティブの基礎となっています。
コンテナと仮想マシンは両方ともコンピューティング ユニットですが、仮想マシンからコンテナへの移行は、単純なパフォーマンスの向上やアーキテクチャの変更とは見なされず、アプリケーションの哲学の変更と見なされます。
たとえば、木こりは読書をするときに斧を使っていましたが、その後、斧を使うのは面倒だと誰もが感じたため、専門家が木を切るための別の道具であるのこぎりを導入しました。しかし、木こりが木を切るためにのこぎりを持った場合、使いやすい斧がないことに気づくでしょう。しかし実際には、斧とノコギリは 2 つの概念として使用されます。
コンテナと仮想マシンの概念の違いについて言えば、次の図を見るとさらにそれがわかります。 
コンテナの一般的なアプリケーションは 2 つのカテゴリに分類できます。1 つはマイクロサービス、もう 1 つは DevOps です。
マイクロサービスとは、さまざまなコンテナを実行するシステムのさまざまなユニットまたは機能を指します。各サービスのコンテナの数は、独自の負荷に応じて調整できます。たとえば、大規模なシステムにはユーザー ログイン、製品表示、製品インタラクションなどの機能が含まれていますが、システムのすべての部分が同時に直線的に増加するわけではなく、一部の部分がビジーになったり、一部の部分に過剰な容量が発生したりすることがあります。 
DevOps は、合理化された開発、テスト、および実稼働プロセスを指します。コンテナの「自己完結型」特性により、標準流通品として使用する場合、開発環境、テスト環境、本番環境のアプリケーションパッケージ化を完全に統一することができ、アプリケーションの依存関係設定ミスによる事故を軽減します。などにより、開発、テスト、実稼働のパイプライン全体がより効率的になります。 
ポッドは、複数のコンテナーを組み合わせた実行ユニットであり、Kubernetes の基本ユニットです。これは、コンテナーの拡張または強化されたコンテナーと考えることができます。ポッドにはメイン コンテナといくつかの補助コンテナが含まれており、これらが連携して特定の機能を完了します。複数のプロセス (コンテナも独立したプロセスです) が名前空間にパッケージ化されると、ポッドが形成されます。ポッド内のさまざまなプロセスのアプリケーション パッケージ化は依然として独立しています (各コンテナーは独自のイメージを持ちます)。
Pod の意義は、メイン コンテナの独立性を保ちながら、メイン コンテナと補助コンテナの密接な関係を維持できることです。メイン コンテナと補助コンテナは同じライフ サイクルを持ち、同時に作成および破棄できるため、それらを Pod に配置すると、相互作用がより効率的になります。
一方、メイン コンテナはいくつかの主要なタスクを完了する必要があり、他のタスクは共通である場合があり、個別にパッケージ化して補助コンテナによって実行できます。
Katacoda という Web サイトにアクセスすることを強くお勧めします。この Web サイトには、Docker や Docker Image などの実践的なプロジェクトを含む、無料のオンライン実験が多数あり、現在は完全に無料です。ここに行って手を汚してみるのもいいかもしれません。
コンテナ プラットフォームが複数のテナント アプリケーションを実行する場合、「水平攻撃」が発生しやすくなります。つまり、プロセスはシステムの脆弱性を利用して、自身の権限を管理者にアップグレードするなどの権限を昇格させ、それによって操作を取得します。システム上で実行されている他のプロセスまたはコンテナに対するアクセス許可。現在、このような脆弱性は通常、「マイニング」のためのコンピューティング リソースの悪意のある使用につながります。
この問題に対処するには、現在 2 つの解決策があり、1 つは「システム コールの制限」、もう 1 つは「独立したカーネル」です。
システム コールの制限とは、アプリケーションのシステム コールを制限することでアプリケーションの機能を低下させ、それによって他のアプリケーションへの損害を回避することを指します。現在、Google の Givsor と IBM の Nabla は両方ともこのアプローチを採用しています。下図に示すように、アプリケーションは本来すべてのシステムコールにアクセスしますが、Nablaモードでは必要なシステムコールのみにアクセスし、その他のコールはブロックされます。 
ただし、この方法の欠点は、最初にアプリケーションに「適切な」権限を与える必要があることです。誤って十分な権限を与えないと、アプリケーションがクラッシュする可能性があります。
独立カーネルとは、仮想マシン ソリューションを指します。これは、コンテナに新しいカーネルを追加することを指します。このカーネルは軽量で、「マイクロカーネル」とユニカーネルという 2 つの実装方法が含まれています。ユニカーネルとアプリケーションは一緒にコンパイルされ、システム コールを使用せずに関数を通じて直接呼び出すことができます。
このソリューションの利点は、コンテナは基本的に独自のカーネルのみを処理し、カーネルはホストを処理することです。カーネルとホスト間の対話には、いくつかの共通の命令のみが必要であり、直接呼び出しは必要ありません。システムに害を及ぼす指示。現在、Kata コンテナと JD.com クラウド ネイティブ コンテナはこの方法を使用しています。
このアプローチの利点は、最小化されたオペレーティング システムとして、マイクロカーネルがいくつかの不要なシステム操作部分を削除しながらすべてのシステム コールを満たすことができることです。システムの起動時間が非常に短く、第 2 レベルに達することができ、仮想マシンよりもオーバーヘッドが小さくなります。
推奨される学習: 「docker ビデオ チュートリアル 」
以上がDocker におけるポッドの意味の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
