複数のESXiホストでkubernetesクラスターをセットアップしようとしています。 etcd/kube-apiserver/kube-scheduler/kube-controller-managerは問題ないようですが、Dockerホスト(この場合はcoreos安定ホスト)ではkubeletは機能しているように見えますが、kube-proxyは機能しません。
次のコマンドを実行していると、リストされているエラーが発生します。
coreos1 core # /opt/bin/kube-proxy --master=10.42.0.51:8080 --v=0
E0817 13:51:29.558463 6506 proxier.go:164] Error removing pure-iptables proxy rule: error checking rule: exit status 2: iptables v1.4.21: Couldn't load target `KUBE-SERVICES':No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
E0817 13:51:29.560023 6506 proxier.go:167] Error removing pure-iptables proxy rule: error checking rule: exit status 2: iptables v1.4.21: Couldn't load target `KUBE-SERVICES':No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
参照されているものを含まないいくつかのiptablesチェーンが作成されますが、これとの取引が何であるかはわかりません。このホストでフランネルをセットアップして動作をテストしました。テストポッドを起動することはできますが、外部IPを取得することはなく、手動で起動したホストは、kubernetesで構成されたIP範囲に到達できません。
V1.0/1.0.1のドキュメントはかなり軽いようですが、非常に初期のベータバージョンでログハウツードキュメントを実行し続けています。
Pure-iptablesモードを使用するためにkube-proxyコマンドパラメーターをオーバーライドしましたか?
Kube-proxyのユーザースペースプロキシモードを使用できるはずです。
純粋なiptablesモードの有効化にも取り組んでいますが、それまでの間、ユーザースペースモードでブロックが解除される可能性があります。
(フラグはlegacy-userspace-proxy [= true]です)
これらの行の直前に、次のログ行が表示されます。
「pure-iptablesプロキシルールを破棄します。ここでのエラーは許容されます。」
プロキシには2つのモードがあり、スタートアップコードは、未使用のモードがクリーンアップされていることを確認しています。他のモードを使用したことがない場合は、クリーンアップする必要はありません。予期しない何かが発生した場合に備えて、エラーを非表示にするよりもログに記録する方がよいと判断しました。プログラムで「何もしない」と「何かをしているエラー」を区別するのは難しいので、私たちはそうしませんでした。
つまり、これはエラーではないと思います。実際に問題が発生していますか?