[シリーズ]ドッキングウィンドウのホスト環境全体マルチアリクラウドホストサーバ、ドッキングウィンドウオーバーレイネットワークトラフィックを解決します

ドッカーコンテナは、ホスト間での相互運用性を実現しています。推奨オーバーレイネットワークタイプ。

オーバーレイネットワークとは何ですか

overlayネットワークドライバは、ドッカーで、複数のホスト間の分散ネットワークを作成するプロセスを見るであろう。ネットワークがネットワーク特有のホスト上に配置され、それは確実に（クラスタサービスコンテナを含む）通信コンテナへの接続を可能にします。ドッカーは透過正しいホストドッカーデーモンおよび正しいターゲット容器と、各パケット間でルーティング処理されます。

あなたがグループを初期化するか、既存のグループにドッカーホストに参加すると、ホストドッカー上の2つの新しいネットワークを作成します。

• 群れのオーバーレイネットワークは、ユーザ定義の接続サービス、デフォルトの入力ネットワークに追加されます作成時に指定されていない場合、クラスタ制御やデータメッセージングサービスのオーバーレイネットワークの入口に呼び出されます。
• 名前のブリッジネットワークはdocker_gwbridge、それがクラスタ内の他の各ドッカーデーモンデーモンに接続します。

あなたは、オーバーレイネットワークを作成したカスタム使用のドッキングウィンドウのネットワークを作成することができ、およびサービスコンテナは、複数のネットワークに参加することができ、かつ、同じネットワークコンテナに単一の容器または群れサービスにオーバーレイネットワークに接続することができ、お互いに情報を交換することができます。

 

環境：
東第二地区（上海）2セットなど：11.11.11.11と11.11.11.22

東ゾーン（杭州）1は：11.11.11.33

アリクラウドdcokerビルドクロスホスト通信の前に。ドッカーは、物理マシンのクラスタの群れ+オーバーレイで使用されてきた成功したクロスホストアクセスの問題を解決しました。アリはそれが問題になることはありませんし、時間がかかり、クラウド上で直接思いました。逆することができ、最終的には、アリクラウドクラスターサーバー上で、ホスト間でドッキングウィンドウの相互運用性を設定することはできません。

その後、さまざまな情報を見つける領事+オーバーレイを使用し、通信することはできません。

最後に答えを見つけました：

アリクラウドセールスエンジニア：     こんにちは、VPCネットワークは自己VXLANをサポートしていませんが、基礎となるとの競合があります。

我々は1つが多くの時間を費やすことは非常に困難であり、自作のクラスタをお勧めしません、そして第二に、自作の互換性の問題がたくさんあります。そして、自作のコンテナ船サービスクラスタは、アリがオンラインに解決するためにのみ、自分の情報を見つけるために、正式な技術サポートを行くではありません。
あなたが空きクラスタを構築することができ、私たちは、あなたがコンテナサービス自体は無料で、ビルドクラスタにアリクラウドが提供するコンテナサービスの使用を検討することをお勧めしますが、関連するクラウドリソースクラスターがために支払われ、クラスタノードは、既存のECSの内部に追加されます直接、あなたは、デバッグクラスターステップを構築する必要性を排除します。  

スクリーンショット：

アリの従業員は明確な答え：VPCのネットワークは、VXLANとのドッキングウィンドウのオーバーレイながら、自己VXLANをサポートしていません！

他の主要なクラウドサーバーに加えても、一部の人は、テンセントのクラウドサーバーがない仕事（私はこれを確認していない！）んテストしていてはいけません。

ドッキングウィンドウの群れクラスターは雲アリ（アリクラウドサービスは、コンテナまたはK8Sドッキングウィンドウ群れクラスターサービスを提供する）が提供するコンテナサービスを使用するか、自分の部屋を構築することができます！
自己K8Sについては、一時的に不明で下車しません。

これは、私が考えた、自己無力にする必要があります。

しかし、不注意、アリはクラウドにネットワーク内の説明を見ました：
 

ECSの必要性は、同じ領域の2つのインスタンス間でデータを転送する場合、ネットワーク接続が推奨されます。ECSとクラウドサーバのクラウドデータベース、ロードバランシング、およびオブジェクトストアとの間にも、別のネットワーク接続を提供することができます。

ECS内ネットワーククラウドサーバ、非最適化された例I O /ギガビット共有帯域幅は、I Oの例は、最適化/ギガビットまたは25Gは、帯域幅が共有されています。それは共有ネットワークであるため、帯域幅の速度が一定であることを保証することはできませんので。

ネットワーク例内のECSの場合：

• ネットワーク通信ネットワークECSインスタンスの種類に影響を与え、それらのアカウント、ローカル、セキュリティグループなどが挙げられます。以下の表に示す特定の情報、。

  ネットワークの種類	アカウント	地域	セキュリティグループ	ネットワークの相互運用性を実現する方法
  VPC（同じVPC）	同じアカウントまたは別のアカウント	同一地域	同じセキュリティグループ	デフォルトの相互運用性は、ネットワークセキュリティの分離のセット内で達成することができます。参照してくださいネットワークの分離にセキュリティグループ。
  			異なるセキュリティグループ	ネットワーク内の相互運用性を実現することが許可セキュリティグループは、を参照してくださいセキュリティグループアプリケーション。
  VPC（異なるVPC）	同じアカウントまたは別のアカウント	同一地域	異なるセキュリティグループ	高速ネットワークを経由して相互運用性を実現する、を参照してください使用シナリオ。
  		異なる地域
  クラシックネットワーク	同じアカウント	同一地域	同じセキュリティグループ	デフォルトの交換。
  	異なるアカウント	同一地域	同じセキュリティグループまたは異なるセキュリティグループ	セキュリティグループは、ネットワーク内の相互運用性を達成するために権限を与え、詳細がご覧セキュリティグループアプリケーションを。

• プライベートネットワークのプライベートIPアドレスを変更することができます。詳細については、を参照してくださいプライベートIPアドレスを変更します。あなたは、ECSのプライベートIPアドレスのネットワークの種類の古典的な例を変更したり、交換することはできません。
• あなたは、プライベートネットワーク経由ClassicLink VPC機能、VPCのネットワーク内のアクセスクラウドリソースへのネットワークの種類のECS古典的な例の独自のネットワークを使用することができます。詳細については、を参照してくださいClassicLinkを。

 

その上で非常に明確です。VPC、同じアカウント、同じ地域、同じセキュリティグループを使用すると、デフォルトのネットワークが相互接続されています。 

言い換えれば、私は、少なくとも二つのサーバーを持って、現在のネットワークが相互接続されています。（すなわち東第二地区）、そして私は、両方のサーバー上でのテストに、コンテナを領事+オーバーレイを使用するようにしてください。お互いにpingを実行することはできません。幸い、はい。通常のpingパス。しかし、東ゾーン。確かにそれはしていません。だから、私は東第二地区によ、ものを買いました。東の、もはや地区は更新ませんが。

次に、詳細な説明。あなたは領事+オーバーレイ環境を構築する場合。

まず、領事クラスタ環境を構築

 図1に示すように、容器ミラー領事を実行し、引き上げ

[root@master /]# docker pull consul
Using default tag: latest
latest: Pulling from library/consul
Digest: sha256:a167e7222c84687c3e7f392f13b23d9f391cac80b6b839052e58617dab714805
Status: Image is up to date for consul:latest
docker.io/library/consul:latest
[root@master /]# docker run -dit \
--network host \
--privileged=true \
--restart=always  \
--hostname=master_consul \
--name=master-consul \
-v /etc/localtime:/etc/localtime \
-e CONSUL_BIND_INTERFACE=eth0 \
-e TZ='Asia/Shanghai' \
-e LANG="en_US.UTF-8" \
-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
consul:latest \
agent -server \
-bind=172.18.18.11 \
-advertise=11.11.11.11 \
-bootstrap-expect=3 -ui -node=master-consul \
-data-dir=/tmp/consul -client 0.0.0.0 

説明：
-e CONSUL_BIND_INTERFACEの使用はeth0 = eth0のカード
-bind = 172.18.18.11 IPアドレスは、ネットワークのバインドこのサーバを表します。すなわち、eth0ののネットワークカードのアドレス
パブリックネットワークIPを使用して通知アドレスを示す-advertise = 11.11.11.11、

図2は、容器の中に、クラスタを追加します

a、进入容器
docker exec -it master-consul  sh

b、 加入 consul 集群
consul join 11.11.11.11

3、残りの二つのサーバは同じステップです。

注：11.11.11.22と11.11.11.33を11.11.11.11を領事に参加しています 

第二に、オーバーレイネットワークを作成

# 创建 overlay 网卡，用于 集群服务的网卡设置（只需要在 master 节点上创建，从节点自然会获取）

docker network create --driver overlay  --subnet=20.0.0.0/24 --gateway=20.0.0.254 --attachable cluster-overlay-sub

第三に、領事のバランスをとるnginxの負荷の使用、

1、nginxのコンテナを実行しています

docker run -dit \
--net cluster-overlay-sub \
--ip 20.0.0.247 \
--privileged=true \
--restart=always  \
--name=keda-master-nginx \
--hostname=master_nginx \
-p 80:80 \
-p 443:443 \
-p 18500:8500 \
-v /usr/docker/software/nginx/html/:/usr/share/nginx/html/ \
-v /usr/docker/software/nginx/conf/:/etc/nginx/ \
-v /usr/docker/software/nginx/home/:/home/ \
-v /usr/docker/software/nginx/data/:/data/ \
-v /usr/docker/software/nginx/logs/:/var/log/nginx/ \
-v /etc/localtime:/etc/localtime \
-e TZ='Asia/Shanghai' \
-e LANG="en_US.UTF-8" \
nginx:latest

2、nginxのの上流に配置され

#consul集群负载均衡
upstream consul {
     server 11.11.11.11:8500;
     server 11.11.11.22:8500;   
     server 11.11.11.33:8500;
}
#监听本机8500端口，转发到upstream consul下
server {
    listen 8510;
    location / {
       include /etc/nginx/conf.d/proxy.conf;  
       proxy_pass http://consul;
    }
}

第四に、構成変更docker.service

[root@master /]# vim /lib/systemd/system/docker.service 

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
#ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:12375 -H unix://var/run/docker.sock -H fd:// --containerd=/run/containerd/containerd.sock
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --cluster-store=consul://11.11.11.11:18510 --cluster-advertise=172.18.18.11:12375  -H tcp://0.0.0.0:12375 -H unix://var/run/docker.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity

# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

主要：
ExecStart =は/ usr / binに/ dockerd -H FD：// --containerd = /実行/ containerd / containerd.sock --cluster店=領事：// 11.11.11.11:18510 --cluster-宣伝= 172.18 .18.11 ：12375  -H TCP：//0.0.0.0：12375 -H UNIXの場合：//var/run/docker.sock

--cluster店=領事：//11.11.11.11：18510 

彼は表し：nginxのアドレスを。負荷領事クラスタにnginxのことで

 172.18.18.11 = --cluster-宣伝：12375

表します。ipネイティブネットワーク通信ポート12375 +ドッカアドレス（別の可能性や攻撃される可能性が高いに変更デフォルトで2375、。）

残りの2台のサーバが同一の工程です。
 

第五に、再起動ドッカ 

sudo systemctl daemon-reload & sudo systemctl restart docker

第六には、3台のサーバ上で、別の容器のオーバーレイネットワークを作成します。前回の「クラスタ・オーバーレイ・サブ」のように、

コンテナを作成します。1.

master:

docker run -dit \
--net cluster-overlay-sub \
--ip 20.0.0.3 \
--privileged=true \
--restart=always  \
--name=springCloud-master-eureka \
--hostname=master_eureka \
-v /usr/docker/springCloud/eureka-dockerfile/eureka/:/var/local/eureka/ \
-v /data/springCloud/eureka/:/data/springCloud/ \
-v /etc/localtime:/etc/localtime \
-e TZ='Asia/Shanghai' \
-e LANG="en_US.UTF-8" \
-p 20000:9800 \
seowen/eureka:latest \


slave1:

docker run -dit \
--net cluster-overlay-sub \
--ip 20.0.0.4 \
--privileged=true \
--restart=always  \
--name=springCloud-slave1-eureka \
--hostname=salve1_eureka \
-v /usr/docker/springCloud/eureka-dockerfile/eureka/:/var/local/eureka/ \
-v /data/springCloud/eureka/:/data/springCloud/ \
-v /etc/localtime:/etc/localtime \
-e TZ='Asia/Shanghai' \
-e LANG="en_US.UTF-8" \
-p 20000:9800 \
seowen/eureka:latest \

slave2:

docker run -dit \
--net cluster-overlay-sub \
--ip 20.0.0.5 \
--privileged=true \
--restart=always  \
--name=springCloud-slave2-eureka \
--hostname=salve2_eureka \
-v /usr/docker/springCloud/eureka-dockerfile/eureka/:/var/local/eureka/ \
-v /data/springCloud/eureka/:/data/springCloud/ \
-v /etc/localtime:/etc/localtime \
-e TZ='Asia/Shanghai' \
-e LANG="en_US.UTF-8" \
-p 20000:9800 \
seowen/eureka:latest \

図2に示すように、容器には、pingの 

[root@master opt]# clear
[root@master opt]# docker exec -it e03b31f2c8b6 bash
[root@master_eureka eureka]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 20.0.0.2  netmask 255.255.255.0  broadcast 20.0.0.255
        ether 02:42:14:00:00:02  txqueuelen 0  (Ethernet)
        RX packets 1110  bytes 81148 (79.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.2  netmask 255.255.0.0  broadcast 172.18.255.255
        ether 02:42:ac:12:00:02  txqueuelen 0  (Ethernet)
        RX packets 3181102  bytes 810628239 (773.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2869065  bytes 791404615 (754.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 31  bytes 2392 (2.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 31  bytes 2392 (2.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@master_eureka eureka]# ping 20.0.0.3
PING 20.0.0.3 (20.0.0.3) 56(84) bytes of data.
64 bytes from 20.0.0.3: icmp_seq=1 ttl=64 time=1003 ms
64 bytes from 20.0.0.3: icmp_seq=2 ttl=64 time=3.22 ms
64 bytes from 20.0.0.3: icmp_seq=3 ttl=64 time=1.79 ms
64 bytes from 20.0.0.3: icmp_seq=4 ttl=64 time=1.79 ms
64 bytes from 20.0.0.3: icmp_seq=5 ttl=64 time=1.77 ms
64 bytes from 20.0.0.3: icmp_seq=6 ttl=64 time=1.77 ms

3、ビューネットワーク 

[root@slave2 ~]# docker network inspect cluster-overlay-sub
[
    {
        "Name": "cluster-overlay-sub",
        "Id": "26db25278114e2cxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxca1f2eddba1cf38add952b0",
        "Created": "2019-12-25T18:29:51.325915414+08:00",
        "Scope": "global",
        "Driver": "overlay",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "20.0.0.0/24",
                    "Gateway": "20.0.0.254"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "48f2da4eaa2c693939d6xxxxxxxxxxxxxxxxxxxxxxxxxxxx7c58669a4b464ad493f73": {
                "Name": "springCloud-slave2-eureka",
                "EndpointID": "2d2c68a17e0b27915e52xxxxxxxxxxxxxxxxxxxxxxxxxxx467f0eb1f7bda9",
                "MacAddress": "02:42:14:00:00:04",
                "IPv4Address": "20.0.0.4/24",
                "IPv6Address": ""
            },
            "ep-2b407f01d38b6cb1dc247xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa068040be6ded8": {
                "Name": "keda-master-nginx",
                "EndpointID": "2b407f01d38b6cxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx68040be6ded8",
                "MacAddress": "02:42:14:00:00:f7",
                "IPv4Address": "20.0.0.247/24",
                "IPv6Address": ""
            },
     
            "ep-732b41808e90ce0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxe149c0eec41": {
                "Name": "springCloud-slave1-eureka",
                "EndpointID": "732b41808e90ce0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx149c0eec41",
                "MacAddress": "02:42:14:00:00:03",
                "IPv4Address": "20.0.0.3/24",
                "IPv6Address": ""
            },
            "ep-7609e871f68fe5bc6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5e0573fc30d73f": {
                "Name": "springCloud-master-eureka",
                "EndpointID": "7609e871f68fe5bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx573fc30d73f",
                "MacAddress": "02:42:14:00:00:02",
                "IPv4Address": "20.0.0.2/24",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]
[root@slave2 ~]#

これまでのところ、多くのセットアップアリクラウドホスト、ホスト間でドッキングウィンドウコンテナのネットワークトラフィック、より完成されました