ハチソン・ネットワーク間の通信は--podできない障害

I.背景

クラスタは、バイナリデプロイです
展開が完了した後に一緒に適切に、オブジェクトを作成するためのさまざまなリソースを正常に使用することができ、
これは、アプリケーションのデプロイメント後のクロスノード通信することができないことがわかった、とポッドのIPは172.17.0.0セグメントです

第二に、調査プロセス層

ビューノードのルーティング、見つかったdocker0カードは、実際に172.17.0.0セグメントである（何を？）
以下の情報を探す：CNMベースのドッキングウィンドウの展開flanel、我々は、ドッキングウィンドウの環境変数として/run/flannel/subnet.env、および起動時にネットワーク情報フランネルを指定する必要があります

第三に、溶液（：/usr/lib/systemd/system/docker.service設定ファイルを変更します）

[単位] 
説明 = ドッカーアプリケーションコンテナエンジンの
ドキュメント = HTTPS：// docs.docker.com 
BindsTo = containerd.service 
後 =ネットワーク- online.target firewalld.service containerd.service 
ウォンツ =ネットワーク- online.target 
必要 = docker.socket 

[サービス] 
タイプ = 通知
＃デフォルトは され systemdに使用しないためためのcgroup デリゲートの問題はまだ
＃存在し、現在にsystemdのcgroup機能をサポートしていませんセット必要が
＃用の容器は、ドッキングウィンドウで実行
 EnvironmentFile = /実行/フランネル/ subnet.env 
ExecStart =は/ usr / binに/ dockerd $ DOCKER_NETWORK_OPTIONS   ：-H FD // --containerd = /実行/ containerd / containerd.sock 
ExecReload = / binに/キル- S HUP $ MAINPID 
TimeoutSec = 0 
RestartSec = 2 
を再起動 = 常に

StartLimitこと＃注 *オプションが動かされたから " サービス"に" 単位"  で systemdに229 。
＃どちらも古いし、新しいです場所はsystemdに受け入れられている229そう、アップして使用して以前の場所の
彼らの仕事にするために＃をためにsystemdのいずれかのバージョンを。
StartLimitBurst = 3 

StartLimitIntervalがStartLimitIntervalSecに改名されたこと＃ノートに systemdに230 。
＃古い、そしてどちらも新しい名前がsystemdに受け入れられている230そう、アップして使用するために、古い名前を
＃このオプション作業のためにsystemdのいずれかのバージョンを。
StartLimitInterval = 60代

非持つ＃-zeroリミット* sが原因オーバーヘッドアカウンティングにパフォーマンス上の問題を引き起こす
＃をでカーネル。お勧め使用してcgroupを行い、コンテナローカルアカウンティングを。
LimitNOFILE = 無限
LimitNPROC = 無限
LimitCORE = 無限大

＃TasksMaxコメント場合あなたにsystemdバージョンがそれをサポートしていません。
＃のみsystemdに226以上をサポートこのオプションを選択します。
TasksMax = 無限大

＃セット デリゲートはいそれにsystemdは、ドッキングウィンドウコンテナのcgroupをリセットしないように、
デリゲート= はい

＃、唯一のドッキングウィンドウのプロセスを殺していない全てのプロセスでのcgroup 
KillMode = プロセス

[インストール] 
WantedBy = multi-user.target

ポッドのDOCKER_NETWORK_OPTIONS指定したネットワークセグメント情報に/run/flannel/subnet.envコール

第四に、サプリメント

ポッドを行うには、docker0 IP何でCNIは、ポッドは常に自分自身の動的IPの申請に行く前に時間を生成し、
CNMモードでは、ポッドのネットワークセグメントは、すでにドッキングウィンドウのエンジン始動時に決定しました
CNIモードが推奨されます

ハチソン・ネットワーク間の通信は--podできない障害

おすすめ