問題タブ [cni]

flannel を CNI プラグインとして使用して、Centos 7 に新しい k8s クラスターをセットアップします。ワーカーをクラスターに参加させるとき、CNI0 ブリッジは作成されません。

環境は kubernetes 13.2.1、Docker-CE 18.09、Flannel 010 です。Centos 7.4。私の理解では、CNI0 は flannel によって呼び出されたときに brctl によって作成されます。docker debug を使用すると、install-cni-kube-flannel コンテナーがインスタンス化されていることがわかります。/var/lib を見ると、/var/lib/cni ディレクトリが作成されていることがわかりません。

CNI0 と /var/lib/cni ディレクトリは install-cni-kube-flannel コンテナによって作成されると思います。これをさらにトラブルシューティングするにはどうすればよいですか? CNI インターフェイスのログ機能はありますか?

Docker と Podman の両方を同じマシンにインストールしました。それが私の最初の問題ですか？多分。しかし、私の目標は両方を実行することであり、とにかく続けたいと思っています。

私の問題は次のとおりです。Docker のルールと Podman のルールの間に iptables の競合があるようで、私の作業ソリューションは意味がありません。

バージョン情報: OS: RHEL 7.6 Podman: 0.11.1.1 Docker: 18.09.1 Iptables: 1.4.21

2 つの情報:

1. docker デーモンは、起動時にコンテナー ネットワークの iptables ルールを追加します。
2. Podman は、コンテナーの実行時に、コンテナー ネットワーク用の CNI (Container Network Interface) を介して iptables ルールを追加します。

ポート (たとえば、5000 など) を公開する podman を使用してコンテナーを実行しています。私の質問と、リモート アクセスを機能させるケース 3 で遭遇する非常に奇妙な動作を説明するのに役立つ 3 つのテスト ケースを作成しました。読む。

1. 最初のケースは完全に理にかなっています。Docker をインストールせずにPodman を通常どおりインストールし、コンテナーを実行します。ふふっ！コンテナーが実行され、期待どおりにポートにリモート アクセスできます。

2. 2 番目のケースは、リモート アクセスが失敗する場合です。Podman を通常どおりインストールし、Docker サービスをインストールして実行し、Podman でコンテナーを実行します。ブーム。ホストへのルートがないため、リモート アクセスは失敗します。

3 番目のケースに進む前に、2 つの非常に具体的な iptables ルールに注意することが重要です。これらのルールを表示するには (Docker デーモンが実行されており、Podman コンテナーが稼働している場合)、次を実行します。

コマンドの出力は次のとおりです。

次に 3 番目のケースです。

3. だから私はiptablesをいじっていて、危険であることを十分に知っています。

CNI-HOSTPORT-DNATルールを削除することにしました。

そして突然、ポート 5000 経由でコンテナにリモート アクセスできるようになりました。

私の質問は：

前述のルールを削除すると、再び機能するようになるのはなぜですか? CNI によって生成されたルールを削除すると、Podman のネットワークが壊れると思うかもしれません。しかし、そうではありません。私は困惑しています！

前もって感謝します。

更新：問題を理解しましたが、それは私のせいでした。

私のパケットは DNAT の後に FORWARD チェーンに正しく送信されていましたが、そのチェーンにはデフォルトの DROP があり、そのチェーンにはポート 5000 宛てのパケットを受け入れるルールがありません。dport=5000 パケットを受け入れる FORWARD ルールを追加したら、 、それは働き始めました。

この質問は閉じることができます。