Dockerコンテナテクノロジー-コンテナネットワーク

ネット 2020-10-04 10:11:44 訪問数: null

目次

記事ディレクトリ

コンテナネットワークの開発動向

ここに写真の説明を挿入

CNI

CNI（Container Network Interface）は、GoogleとCoreOSが主導するコンテナネットワーク標準であり、柔軟性、スケーラビリティ、IP割り当て、複数のネットワークカードなどの要素を考慮して、RKTネットワークの提案に基づいて開発されています。 。

CNIは、コンテナプラットフォームのネットワーク標準化を提供することを目的としています。異なるコンテナプラットフォーム（Kubernetes、Mesos、RKTなど）は、同じインターフェイスを介して異なるネットワークコンポーネントを呼び出すことができます。このプロトコルは、次の2つのコンポーネントを接続します。

  1. コンテナ管理システム
  2. ネットワークプラグイン

コンテナネットワークスペース（ネットワークネームスペース）の作成、対応するネットワークスペースへのネットワークインターフェイス（インターフェイス）の配置、ネットワークインターフェイスへのIPの割り当てなど、特定のものがプラグインによって実装されます。

現在、CNIが提供するソリューションは一般的に2つのタイプに分けられます

  1. トンネル計画
  2. ルーティングスキーム

具体的には、Flannel、Callico、Weave、macvlanネットワークソリューション。難易度は、Callicoが最も単純で、Flannelが続き、Weaveが最も複雑です。ネットワーク技術の観点から、WeaveとFlannelはどちらもネットワークカプセル化トンネル技術です。違いは、ネットワークデバイスまたはホスト上のカプセル化の場所にあります。

ここに写真の説明を挿入

フランネル

ここに写真の説明を挿入

Flannelは、コンテナクラスター内のクロスホスト通信を解決するためにCoreOSによって提案されたネットワークソリューションです。Flannelは基本的にオーバーレイネットワークです。つまり、TCPデータはルーティング、転送、通信のために別のネットワークパケットにパッケージ化されています。現在、UDP、VXLAN、AWS VPC、GCEルーティング、その他のデータ転送方法をサポートしています。その中でVXLANテクノロジーが最も優れています。人気のある多くのデータセンターは、コンテナの導入を検討する際に、フランネルのVXLANネットワークへの切り替えを検討しています。

Flannelは各ホストにサブネットを割り当て、コンテナはこのサブネットからIPを割り当てます。これらのIPはホスト間でルーティングでき、コンテナはNATやポートマッピングなしでホスト間で通信できます。Flannelを使用すると、クラスター内のさまざまなノードホストが、コンテナーを作成するときにクラスター全体で一意の仮​​想IPアドレスを持ち、ホストノードネットワークに接続できます。Flannelは、クラスター内のすべてのノードのIPアドレス使用規則を再計画できるため、異なるノード上のコンテナーは「同じイントラネット」および「非重複」IPアドレスを取得でき、異なるノード上のコンテナーがイントラネットを直接通過できるようになります。 IP通信の場合、ネットワークカプセル化部分はコンテナからは見えません。ソースホストサービスは、元のデータコンテンツをUDPにカプセル化し、独自のルーティングテーブルに従って宛先ノードに配信します。データが到着すると、データは解凍され、宛先ノードの仮想ネットワークカードに直接入力され、宛先ホストコンテナの仮想ネットワークカードに直接到達して、ネットワーク通信の目的を達成します。

Flannelはネットワークに対する要件が高いですが、カプセル化テクノロジーが導入され、転送効率も影響を受けますが、SDNネットワークにスムーズに移行できます。VXLANテクノロジーはSDNと十分に統合でき、ネットワーク全体の自動展開とインテリジェントな運用および保守に値します。そして管理、新しいデータセンターネットワークの展開により適しています。

カリコ

ここに写真の説明を挿入

Callicoコンテナネットワークと他の仮想ネットワークの最大の違いは、パケット転送にオーバーレイネットワークを使用せず、純粋な3層ネットワークモデルを提供することです。3層通信モデルは、各コンテナがIPを介して直接通信することを意味します。ルーティングが正しく機能するには、各コンテナが配置されているホストノードが、クラスタ全体のルーティング情報を知る何らかの方法を備えている必要があります。Callicoは、BGPルーティングプロトコルを使用して、ネットワーク全体をすべて作成します。ネットワークのノードとネットワーク機器は、ネットワーク全体へのルートを記録します。

ただし、この方法では無効なルートが多数生成されるため、多くのネットワーク機器のルーティング仕様が必要になり、ネットワーク全体に低いルーティング仕様の機器を含めることはできません。さらに、Callicoは、送信元コンテナから送信元ホスト、データセンター、宛先ホスト、最後に宛先コンテナへのルーティングを実現します。プロセス全体は、パケット化や解凍なしで、常にBGPプロトコルに従ってルーティングおよび転送されます。プロセスなので、転送効率がはるかに速くなります。これは、Callicoコンテナネットワークの技術的な利点です。

織り

ここに写真の説明を挿入

Weaveは本質的にオーバーレイネットワークです。Weaveは、さまざまなホスト上のコンテナをローカルネットワークと同様のネットワークに接続するネットワークを仮想化できます。さまざまなホストが独自のプライベートIPアドレスを使用します。コンテナが複数の異なるホストに分散されている場合当時、これらのコンテナ間の通信は、Weaveを介して簡略化できます。

Weaveネットワークのコンテナは標準ポートを使用してサービスを提供し（たとえば、MySQLはデフォルトで3306を使用します）、マイクロサービスの管理は非常に単純で単純です。各コンテナは、ドメイン名を介して他のコンテナと通信することも、NATを使用せずに、ポートマッピングや複雑な接続なしで直接通信することもできます。

Weaveコンテナネットワークを導入する最大の利点は、アプリケーションコードを変更する必要がないことです。Weaveは、コンテナクラスタ内の各ホストで仮想ルータを起動し、そのホストをルータとして使用して相互接続されたネットワークトポロジを形成します。これにより、コンテナのクロスホスト通信を実現します。

Weaveをデプロイするには、ホストLinuxカーネルバージョンが3.8以上およびDocker 1.10以上であることを確認する必要があります。ホスト間のアクセス用のファイアウォールがある場合、ファイアウォールはTCP6783やUDP6783 / 6784などのポート番号を相互に許可する必要があります。これらはWeave制御ポートとデータポートです。名前を同じにすることはできません。Weaveはホスト名でサブネットを識別する必要があります。

ウィーブネットワークは、ホスト上のパケットトラフィックを直接カプセル化して、アンダーレイ3層ネットワーク全体でホストとホスト間の相互アクセスを実現するホストオーバーレイテクノロジーに似ています。これは、フランネルネットワークとの最大の違いです。フランネルはネットワークオーバーレイソリューションです。 。

Macvlan

Macvlanは、Linuxカーネルの比較的新しい機能であり、ホストのネットワークインターフェイス上に複数の仮想ネットワークインターフェイスを構成できます。これらのネットワークインターフェイスには、独自の独立したMACアドレスがあり、通信用のIPアドレスを使用して構成することもできます。macvlanとホストの下の仮想マシンまたはコンテナネットワークは同じネットワークセグメントにあり、同じブロードキャストドメインを共有します。Macvlanとbridgeは似ていますが、bridgeが存在しないため、構成とデバッグが比較的簡単で、効率が比較的高くなります。さらに、macvlan自体もVLANを完全にサポートしています。

ServiceMesh + CNI

ここに写真の説明を挿入

ServiceMeshとCNIは組み合わされた関係です。ServiceMeshはCNIに置き換わるものではありません。これらは、異なるSDNレベルで機能します。CNIはL2-4レベルで機能し、ServiceMeshはL5-7レベルのアプリケーションSDNで機能します。ServiceMeshはCNIから独立して展開することはできず、CNIとともに、階層型マイクロサービスアプリケーションに必要なネットワークサービスを提供します。Gartnerのレポートによると、2020年には、コンテナクラウドのほぼ100％にServiceMeshテクノロジーが組み込まれる予定です。現在のオープンソースのIstioは、単一のKubernetesクラスター内でのみマイクロサービスガバナンスを提供し、異種コンテナークラウドおよびクロスクラウド機能を欠いています。

CNIは、コンテナクラウドのL2-4層にあるマイクロサービス内の各PODコンテナに配信する必要があります。アプリケーション端末の配信には、L2ネットワーク接続、L3ルーティング、L2-4層のセキュリティ分離、全体的なコンテナクラウドセキュリティ、負荷分散などが必要でした。

ServiceMeshは、マイクロサービスアプリケーションレベルでのサービスガバナンスにさらに取り組んでおり、L5-7レイヤーネットワークサービスにも取り組んでいます。サービスメッシュは、各アプリケーションコンテナの前にSidecar Envoyアプリケーションプロキシを展開して、マイクロサービスと分散負荷の間のインテリジェントなルーティングを提供します。バランス、トラフィック管理、青緑色、カナリアリリース、マイクロサービスの弾力性、電流制限回路ブレーカー、タイムアウトの再試行、マイクロサービス間の視覚化、セキュリティなど。
・

Dockerコンテナネットワーク

Dockerは、コンテナ間およびコンテナと外界との間の通信方法を決定するいくつかのタイプのネットワークを提供します。

  • 基本的なネットワークタイプ
    ここに写真の説明を挿入

  • すべてのコンテナネットワークタイプを表示します。

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
c79756cf9cde        bridge              bridge              local
204025a5abbc        host                host                local
9b9024f5ac40        macvlan             macvlan             local
6478888548d8        none                null                local
p2e02u1zhn8x        overlay             overlay             swarm

ブリッジモード

ブリッジモードのDockerネットワークは、Linuxの仮想ネットワークテクノロジに基づいて実装されています。Container Dockerのネットワークインターフェイスは、デフォルトでは仮想インターフェイスであり、異なるコンテナ間またはホスト間のコンテナ間のデータ転送の効率を最大限に発揮できます。これは、Linux仮想ネットワークテクノロジがカーネル内のデータをコピーすることによって仮想インターフェイス間のデータ転送を実現するためです。つまり、送信インターフェイスの送信バッファ内のデータパケットは、通過せずに受信インターフェイスの受信バッファに直接コピーされます。外部の物理ネットワーク機器が交換されます。

Docker Daemonが起動すると、docker0という名前のLinuxブリッジがホスト上に作成され、このホスト上で起動されたDockerコンテナがこの仮想ブリッジに接続されます。Docker Daemonは、docker0（仮想L2ネットワーク）サブネットからコンテナにIPを割り当てて使用し、docker0のIPアドレスをコンテナのデフォルトゲートウェイとして設定します。同時に、ホスト上にvethペア仮想ネットワークケーブルデバイスのペアを作成します。DockerDaemonは、vethペアデバイスの一方の端を新しく作成されたコンテナに挿入し、eth0（コンテナのネットワークカード）という名前を付け、もう一方の端をvethxxx形式でdocker0 LinuxBridgeに挿入します。名前。

このネットワーク内のコンテナは相互に通信できます。外部がこのネットワーク内のコンテナにアクセスする場合は、ブリッジネットワークにアクセスし、iptablesを介してDNATルールを実装して、内部および外部のアドレス変換を実現する必要があります。

ここに写真の説明を挿入

$ ip a
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever

$ docker run -itd --name box1 busybox

$ docker exec -it box1 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

/ # ip r
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

$ brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.024246c300eb	no		vethd4ae072

ホストモード

コンテナの起動時にホストモードが使用されている場合、コンテナは独立したネットワークネームスペースを取得しませんが、ホストとネットワークネームスペースを共有します。つまり、Containerは、独自のネットワークカードを仮想化したり、独自のIPを構成したりするのではなく、ホストのIPとポートを直接使用します。

もちろん、ファイルシステム、プロセスリストなど、コンテナの他の側面は引き続きホストから分離されています。このタイプのネットワークのみを使用するコンテナは、ホストのネットワークを使用します。このタイプのネットワークは、完全に外部に公開されています。ホストにアクセスできる場合は、コンテナにアクセスできます。

$ docker run -itd --network host --name box2 busybox

$ docker exec -it box2 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:94:84:10 brd ff:ff:ff:ff:ff:ff
    inet 172.18.22.204/24 brd 172.18.22.255 scope global dynamic eth0
       valid_lft 48054sec preferred_lft 48054sec
    inet6 fe80::f816:3eff:fe94:8410/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever
7: vethd4ae072@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0
    link/ether ce:95:19:64:d0:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::cc95:19ff:fe64:d0d4/64 scope link
       valid_lft forever preferred_lft forever

macvlanモード

ネットワークトラフィックを監視し、物理ネットワークに直接接続する必要があるなど、一部のアプリケーションでは、この場合、macvlanネットワークモードを使用できます。macvlanドライバは、IPアドレスをコンテナに割り当てるだけでなく、物理MACアドレスをコンテナに割り当てます。コンテナ。macvlanを介して、クロスホストコンテナの前の通信も実現できます。

  1. macvlanネットワークを作成します。
docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=eth0 macvlan1
  1. ネットワークカードを無差別モードに設定します。
ip link set eth0 promisc on
  1. macvlanネットワークを使用してコンテナを作成します。
docker run -it --network macvlan1  --ip=172.16.86.2 busybox /bash

コンテナモード

Dockerリンクとも呼ばれるコンテナモードは、Dockerコンテナ間の通信メカニズムです。新しいコンテナが既存のコンテナにリンクされている場合、新しいコンテナは環境変数を介して既存のコンテナのリンク情報を取得します。コンテナ間の通信は、既存のコンテナに関するリンク情報を信頼できるコンテナに提供することによって実現されます。

コンテナモードはホストモードと似ていますが、コンテナモードで作成されたコンテナが物理マシンではなく他のコンテナのIPとポートを共有する点が異なります。このモードでは、コンテナ自体はネットワークとポートを構成しません。このモードを作成すると、内部に表示されます。 IPは指定したコンテナIPであり、ポートも共有されます。もちろん、プロセスなど、他のものは互いに分離されています。

docker run -it --network container:<container ID>

ここに写真の説明を挿入

なしモード

なしモードでは、コンテナには独自のネットワークネームスペースがありますが、コンテナのネットワーク構成は実行されません。つまり、このコンテナには、ネットワークカード、IP、ルーティングなどの情報は含まれません。ネットワークカードを手動で追加し、コンテナのIPを構成する必要があります。このタイプのネットワークを使用するコンテナは完全に分離されます。

なしモードを使用した後、コンテナは閉じられ、ネットワーク通信に参加しないため、コンテナのセキュリティを保証できます。

$ docker run -itd --network none --name box3 busybox

$ docker exec -it box3 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

オーバーレイモード

オーバーレイモードは、SwarmクラスターでクロスホストDockerコンテナーを接続するために使用され、異なるホスト上のコンテナーが相互に通信できるようにします。オーバーレイモードは、Dockerクラスターノード間に仮想ネットワークのレイヤーを追加します。これには、独立した仮想ネットワークセグメントがあります。したがって、コンテナーによって送信されたコンテンツは、最初に仮想サブネットに送信され、次に仮想サブネットがホストの実際のURLとしてパッケージ化されて配信されます。 。

ここに写真の説明を挿入

# 初始化 manager node。
$ docker swarm init

# 添加 worker node 到 manager。
$ docker swarm join --token <token> <manager_host>:2377

# 新建一个 Overlay 网络
$ docker network create --driver=overlay --attachable overlay

# 分别在不同的 worker node 上启动一个 busybox 容器，并连接到 Overlay 网络
$ docker run -it --network overlay --name box4 sh

このようにして、同じオーバーレイネットワーク上のクロスホストコンテナは相互に通信できます。

Swarmに基づいて、Containersクラスターサービスを管理することもできます。たとえば、オーバーレイネットワークに接続された5つのコピーを持つNginxクラスターを作成し、公開ポートは80です。

$ docker service create --name my-nginx --publish target=80,published=80 --replicas=5 --network overlay nginx

このNginxクラスターでは、いずれかのノードがコピーを終了すると、クラスターサービスは新しいコピーを再開して、すべてのワーカーノードのNginxコピーの数を5に保ちます。

コンテナポートマッピング

コアオプション：

  • -pホストポート：コンテナ内のアプリケーションリスニングポートを物理ホスト上の特定のポートにマップします。

例：

  • カスタムマッピング：
docker run -d -p 8888:80  nginx:latest

ここに写真の説明を挿入

  • ランダムマッピング
# 需要镜像支持
docker run -P

おすすめ

転載: blog.csdn.net/Jmilk/article/details/108900394
おすすめ
ランキング
Oracleのクエリ重複フィールド
An error occurred when ssm used count to query data
【Leyes de la Naturaleza】La sabiduría de las multitudes
JavaWebの研究では、（13）を締結 - セッションの使用は、重複送信フォームを防ぎます
Firebase増加サインアップクォータ
[MyBatisフレームワーク]mybatis入門
ハートレスの世界
Djangoのインストールと使用について
[转] UiPath展開アーキテクチャ
mybatis-plusは楽観的なロック変更を使用します
アーカイブ
もっと
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)

コードワールド

© 2018 codetd.com