Kubernetes: ネットワークプラグインの準備ができていません:cni configuninitialized

作成日 2017年07月12日  ·  75コメント  ·  ソース: kubernetes/kubernetes

こんにちは、kubeadmを介してkubernetesの新規インストールを実行したいのですが、インストールを開始するとスタックします

[apiclient] Created API client, waiting for the control plane to become ready

journalctl -xeを実行すると、次のように表示されます。

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

そして、私はなぜこのエラーが発生するのかわかりません。 また、firewalldを無効にしようとしましたが、効果がありませんでした。

環境

  • Kubernetesバージョン( kubectl version ):v1.7.0
  • クラウドプロバイダーまたはハードウェア構成**:
  • OS(例:/ etc / os-releaseから):CentOS 7
  • カーネル(例: uname -a ):3.10.0-514.26.2.el7.x86_64
  • ツールのインストール:Kubeadm
  • その他:
    Dockerバージョン: Docker version 17.06.0-ce, build 02c1d87
    私のRPMバージョン:

kubeadm-1.7.0, kubectl-1.7.0, kubelet-1.7.0, kubernetes-cni-0.5.1

ご協力いただきありがとうございます

arekubeadm kinbug sinetwork

最も参考になるコメント

flanneldにはk8s1.12の修正が必要です。
このPRを使用してください(承認されるまで):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
これは既知の問題です: https

全てのコメント75件

@PLoicこの問題に関するsigラベルはありません。 次の方法でsigラベルを追加してください。
(1)sigに言及する: @kubernetes/sig-<team-name>-misc
例:APIマシナリーの場合は@kubernetes/sig-api-machinery-*
(2)ラベルを手動で指定する: /sig <label>
例:sig / scalabilityの場合は/sig scalability

_注:方法(1)は、チームへの通知をトリガーします。 チームリストはこちら、ラベルリストはこちら_

/ area [kubeadm]

@PLoic /etc/cni/net.dにCNIネットワークが定義されておらず、明らかにCNIネットワークプラグインを使用しているため、このエラーが発生します。 ネットワークを構成する方法をCNIドライバーに指示するには、そのディレクトリに構成ファイルを書き込む必要があります。 kubeadmが何をどのように行うのかはわかりませんが、 @ jbedaまたは他のkubeadmの人々に任せます。

外部参照:#43567

@dcbwこんにちはdcbw、@ PLoicと同じ環境ですが、これと同じエラーが発生します

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf$KUBELET_NETWORK_ARGSを削除することで機能しているようです

$ KUBELET_NETWORK_ARGSを削除しても機能しません。

@PLoicも私と一緒に動作しません

ステップ3の@PLoicは、どのポッドネットワークをインストールしましたか? さまざまな選択肢があり、その後のトラブルシューティングは特定のケースによって異なります。

@PLoicも、kubeletログは素晴らしいでしょう

このプラグインを適用してみてください:kubectl apply --filename
わたしにはできる。

@PLoic @dcbw k8s(1.7)のフランネルプラグインをインストールしても同じエラーが発生します。解決策を提供できますか?

7月14日17:57:20node2 kubelet:W0714 17:57:20.540849 17504 cni.go:189] cni構成を更新できません:/etc/cni/net.dにネットワークが見つかりません
Jul 14 17:57:20 node2 kubelet:E0714 17:57:20.541001 17504 kubelet.go:2136]コンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker:ネットワークプラグインの準備ができていません:cni config uninitialized
Jul 14 17:57:23 node2 kubelet:I0714 17:57:23.032330 17504kubelet.go:1820]ポッド同期のスキップ-[ContainerManagersystemdバージョンの開始に失敗しました。一時ユニットとしてスライスを開始する機能はサポートされていません]

遅れて申し訳ありませんが、Weaveを使用していました。kubernetesを1.7.1に更新し、新しいバージョンのweaveを使用します。

すべてのコンポーネントを更新しましたが、機能しているようです。 :)

この問題を@PLoicで閉じても大丈夫ですか?

@cmlucianoはい、この問題を閉じても大丈夫だと思います

/etc/systemd/system/kubelet.service.d/10-kubeadm.confの$ KUBELET_NETWORK_ARGSを削除するとうまくいきます。
ありがとう@PLoic

KUBELET_NETWORK_ARGSは、どの種類のネットワークプラグインを期待するかをkubeletに指示するものであることに注意してください。 それを削除すると、kubeletはプラグインを予期しないため、基盤となるコンテナーランタイムが提供するもの、通常はDocker「ブリッジ」ネットワークを取得します。

これは、特にマシンが1台しかない場合は、問題ない場合があります。 実際にCNIを使用したい場合は役に立ちません。

kubeadmでもまったく同じエラーが発生し、次の場所で永久に発生します。

[apiclient] Created API client, waiting for the control plane to become ready

「journalctl-r-u kubelet」には、次の行が何度も表示されます。
Aug 31 16:34:41 k8smaster1 kubelet[8876]: E0831 16:34:41.499982 8876 kubelet.go:2136] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Aug 31 16:34:41 k8smaster1 kubelet[8876]: W0831 16:34:41.499746 8876 cni.go:189] Unable to update cni config: No networks found in /etc/cni/net.d

バージョンの詳細は次のとおりです。
`kubeadmバージョン:&version.Info {メジャー:" 1 "、マイナー:" 7 "、GitVersion:" v1.7.4 "、GitCommit:" 793658f2d7ca7f064d2bdf606519f9fe1229c381 "、GitTreeState:" clean "、BuildDate:" 2017-08-17T08:30 :51Z "、GoVersion:" go1.8.3 "、コンパイラ:" gc "、プラットフォーム:" linux / amd64 "}

Kubectlバージョン:クライアントバージョン:version.Info {メジャー: "1"、マイナー: "7"、GitVersion: "v1.7.4"、GitCommit: "793658f2d7ca7f064d2bdf606519f9fe1229c381"、GitTreeState: "clean"、BuildDate: "2017-08-17T08 :48:23Z "、GoVersion:" go1.8.3 "、コンパイラ:" gc "、プラットフォーム:" linux / amd64 "}`

OSの詳細は次のとおりです。
Operating System: Red Hat Enterprise Linux Server 7.3 (Maipo) Kernel: Linux 3.10.0-514.el7.x86_64 Architecture: x86-64
どんな助けでも大歓迎です!

@ ashish-billoreどのCNIプロバイダーをインストールしましたか?

マスターブランチの最近のgithubチップでUnable to update cni config: No networks found in /etc/cni/net.dを取得しています- "v1.9.0-alpha.0.690+9aef242a4c1e42-dirty"

Ubuntu17.04で

この行を10-kubelet.confから削除した場合:
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/ --cni-bin-dir=/opt/cni/bin""

kubeletが起動し、ポッドネットワークプラグインとしてweave-netをインストールしますが、kube-systemポッドが起動しません(スケジュールされたままですか?)。

kube-system   etcd-luboitvbox                      0/1       Pending   0          31m
kube-system   kube-apiserver-luboitvbox            0/1       Pending   0          31m
kube-system   kube-controller-manager-luboitvbox   0/1       Pending   0          31m
kube-system   kube-dns-1848271846-7mw9x            0/3       Pending   0          32m
kube-system   kube-proxy-k89jp                     0/1       Pending   0          32m
kube-system   kube-scheduler-luboitvbox            0/1       Pending   0          31m
kube-system   weave-net-v8888                      0/2       Pending   0          30m

フランネルでも同じことが起こります。

こんにちは、

参考までに、この問題が発生しました。Kubernetesではv1.6以降RBACが導入されています。kubeletがAPIサーバーと正しく通信できるように、対応するサービスアカウント、RBACルール、フランネルデーモンセットを作成する必要があります。

実行する必要があります:

$ kubectl create -f https://raw.githubusercontent.com/coreos/flannel/v0.9.0/Documentation/kube-flannel.yml

お役に立てば幸いです。

こんにちは皆さん、なぜこの問題は解決されたのですか? 解決策があったように見えませんか?

これは、weaveCNIプラグインを使用してk8のクラスターをインストールしようとしたときに表示されます。

@vinayvenkat OPが更新され、問題が解決したため、問題は解決されました。

Kubernetes、特にネットワーキングは非常に複雑で多様であるため、類似しているように見える問題が実際には同じであると想定するべきではありません。 新しい号を開き、そこでの特定の状況の完全な詳細を提供します。

問題がWeaveNetにある場合は、 https://github.com/weaveworks/issues/newまたはWeaveコミュニティSlackでより焦点を絞った回答を得ることができます。

私も同じ問題に遭遇しました。 ただし、k8sのインストールでは致命的なエラーではありません。
問題は、kubeletがdockerのcgroupとは異なるsystemd cgroupを使用し、kubeletとdockerの両方を調整し、kubeadmを再度実行すると、正常に実行される可能性があることです。
あなたを助けることを願っています。

OS(例:/ etc / os-releaseから):CentOS 7

ポッドネットワークプロバイダーポッドが実行されているにもかかわらず、ノードの/etc/cni/net.dディレクトリが空になっている場合は、 setenforce 0を試して、ポッドネットワークプロバイダーポッドを削除してください。 k8sはそれを再起動し、うまくいけば、設定をコピーできるようになります。

kubeletを再起動することを忘れないでください...
/etc/systemd/system/kubelet.service.d/10-kubeadm.confの$ KUBELET_NETWORK_ARGSを削除します
systemctl enable kubelet && systemctl start kubelet
その後、ノードに再参加します
この方法は私にとってはうまくいきます〜

こんにちは、

/etc/systemd/system/kubelet.service.d/10-kubeadm.confの$ KUBELET_NETWORK_ARGSにコメントしてサービス/サーバーを再起動するか、kubeadmをリセットして再度参加する場合/ kubeadminitでクラスターを再作成する
そして再びノードに参加し、

ポッドは実行状態になりますが、kube-dnsポッドについて説明すると表示されます

警告不健康な1m(x4 over 2m)kubelet、マスター準備プローブが失敗しました:Get http://172.17.0.2:8081 / readyness:dial tcp 172.17.0.2:8081:getsockopt:connection refused

以下のような完全な出力。

イベント:
メッセージから理由年齢を入力
---- ------ ---- ---- -------
通常のスケジュール済み10mdefault-schedulerkube-dns-6f4fd4bdf-qxmznがマスターに正常に割り当てられました
通常のSuccessfulMountVolume10m kubelet、マスターMountVolume.SetUpがボリューム「kube-dns-token-47fpd」に対して成功しました
通常のSuccessfulMountVolume10m kubelet、マスターMountVolume.SetUpがボリューム「kube-dns-config」に対して成功しました
通常のプル10mkubelet、マスタープルイメージ「gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7」
通常プルされた10mkubelet、マスターイメージ "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7"が正常にプルされました
通常作成10mkubelet、マスター作成コンテナ
通常開始10mkubelet、マスター開始コンテナ
通常のプル10mkubelet、マスタープルイメージ「gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7」
通常プルされた10mkubelet、マスターイメージ "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7"を正常にプルしました
通常作成10mkubelet、マスター作成コンテナ
通常開始10mkubelet、マスター開始コンテナ
通常のプル10mkubelet、マスタープルイメージ「gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7」
通常プルされた10mkubelet、マスターイメージ "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7"を正常にプルしました
通常作成10mkubelet、マスター作成コンテナ
通常開始10mkubelet、マスター開始コンテナ
通常のSuccessfulMountVolume2m kubelet、マスターMountVolume.SetUpがボリューム「kube-dns-token-47fpd」に対して成功しました
通常のSuccessfulMountVolume2m kubelet、マスターMountVolume.SetUpがボリューム「kube-dns-config」に対して成功しました
通常のSandboxChanged2m kubelet、マスターPodサンドボックスが変更され、強制終了されて再作成されます。
通常のプル2mkubelet、マスターコンテナイメージ「gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7」はすでにマシンに存在します
通常作成2mkubelet、マスター作成コンテナ
通常開始2mkubelet、マスター開始コンテナ
通常作成2mkubelet、マスター作成コンテナ
通常のプル2mkubelet、マスターコンテナイメージ「gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7」はすでにマシンに存在します
通常開始2mkubelet、マスター開始コンテナ
通常のプル2mkubelet、マスターコンテナイメージ「gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7」はすでにマシンに存在します
通常作成2mkubelet、マスター作成コンテナ
通常開始2mkubelet、マスター開始コンテナ
警告不健康な1m(x4 over 2m)kubelet、マスター準備プローブが失敗しました:Get http://172.17.0.2:8081 / readyness:dial tcp 172.17.0.2:8081:getsockopt:connection refused

docker @ master :〜$ kubectl get pods --namespace = kube-system
NAME READY STATUS RESTARTS AGE
etcd-master1 / 1ランニング114m
kube-apiserver-master1 / 1ランニング114m
kube-controller-manager-master1 / 1ランニング114m
kube-dns-6f4fd4bdf-qxmzn3 / 3ランニング315m
kube-proxy-d54fk1 / 1ランニング115m
kube-scheduler-master1 / 1ランニング114m

SELinuxについてはまだ誰も言及していません。 強制モードでSELinuxを使用してCentos7マシンでkubeadm joinを実行すると、このエラーが発生しました。 setenforce 0を設定し、kubeadmを再実行すると、問題が修正されました。

おかげでsetenforce0は私のために働いた。

1. $ KUBELET_NETWORK_ARGSを取り出し、問題を解決しない
2.setenforce 0
3.systemctl stopfirewalld
4.docker cgroups drivers:systemd与Environment = "KUBELET_CGROUP_ARGS = -cgroup-driver = systemd"
一致
しかし、あなたは問題がまだ存在していることを知っています。


5月20日20:10:45k8s kubelet:I0520 20:10:45.244383 17638kubelet.go:1794]ポッド同期のスキップ-[コンテナーランタイムがダウンしています]
5月20日20:10:45k8s kubelet:E0520 20:10:45.920981 17638 Reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:460:リストに失敗しました* v1.Node:Get https: //192.168.18.90:6443/api/v1/nodes?fieldSelector=metadata.name%3Dk8s.master.com&limit=500&resourceVersion=0 :ダイヤルtcp 192.168.18.90:6443:getsockopt:接続が拒否されました
5月20日20:10:45k8s kubelet:E0520 20:10:45.924021 17638 Reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:451:* v1.Serviceの一覧表示に失敗しました: httpsを取得
5月20日20:10:45k8s kubelet:E0520 20:10:45.935594 17638 Reflector.go:205] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47:* v1.Podの一覧表示に失敗しました:取得https://192.168.18.90:6443 / api / v1 / pods?fieldSelector = spec.nodeName%3Dk8s.master.com&limit = 500&resourceVersion = 0:ダイヤルtcp 192.168.18.90:6443:getsockopt:接続が拒否されました

5月23日10:19:45arch kubelet [13585]:E0523 10:19:45.909458 13585 kubelet.go:2095]コンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker:ネットワークプラグインの準備ができていません:cni config初期化されていません
5月23日10:19:46arch kubelet [13585]:E0523 10:19:46.0​​02646 13585 helpers.go:468] PercpuUsageのCPUは0でしたが、実際の数は8です。 余分なCPUを無視する

`sudo kubectl get node

名前ステータスロール年齢バージョン
127.0.0.1 NotReady23時間v1.8.13`

これに遭遇したばかりで、ファイルが実際に空であることが原因のようです。 install-cniコンテナからの出力は次のとおりです。

$ k logs canal-25rct install-cni -n kube-system
ls: /calico-secrets: No such file or directory
Wrote Calico CNI binaries to /host/opt/cni/bin
CNI plugin version: v3.1.2
/host/secondary-bin-dir is non-writeable, skipping
CNI config: {
Created CNI config 10-calico.conflist
Done configuring CNI.  Sleep=true

そして/etc/cni/net.d/10-calico.conflist

$ cat /etc/cni/net.d/10-calico.conflist 
{

コンテナにシェルinitContainerしようとすると(おそらく

$ k exec -it canal-25rct -c install-cni -n kube-system -- /bin/bash
Error: Malformed environment entry: "  "name": "k8s-pod-network",
": Success
command terminated with exit code 45

スクリプトのバージョンが変更されていないため、奇妙です。最近変更したのは、コンテナーを実行するためにrktに切り替えることだけです。 また、これが役立つ場合は、Container Linux(CoreOS)上にあります。

K8sの皆さん、こんにちは。

私は何度も同じ問題を抱えていました。 たとえば、K8sの初期化中に問題が発生し、 kubeadm resetを使用してK8sを再度初期化する必要がありました。 初期化コマンドを実行した後、kubeletに次のエラーを記録しました。

Jun 01 10:13:40 vncub0626 kubelet[18861]: I0601 10:13:40.665823   18861 kubelet.go:2102] Container runtime status: Runtime Conditions: RuntimeReady=true reason: message:, NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 01 10:13:40 vncub0626 kubelet[18861]: E0601 10:13:40.665874   18861 kubelet.go:2105] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

...私はこのエラーメッセージに腹を立てました-何も助けにはなりませんでした。 だから私は自分自身に言いました-最初は初期化が実行されましたが、再初期化は実行されませんでした。 したがって、Kubelet構成の次の行が原因ではありませんでした: KUBELET_NETWORK_ARGSそして私はコメントに同意しません。 だから私はkubeletログを何度も読みました...そして最後に私はログで次のエラーメッセージに気づきました:

Jun 01 10:13:29 vncub0626 kubelet[18861]: E0601 10:13:29.376339   18861 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:465: Failed to list *v1.Service: Get https://10.96.22.11:6443/api/v1/services?limit=500&resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

このエラーは、前回の初期化後のホームディレクトリの~/.kube/configファイルの不良が原因で発生しました。 それを削除した後、私は再び初期化を実行します...そしてvoilá...初期化は正常に終了しました。 :]

...このエラーは悪夢であり、その原因を特定することはほとんど不可能であるため、他の誰かに役立つことを願っています。

@waldaufあなたは正しいです!!! 驚くばかり!!!

followコマンドを実行するとうまくいきます

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml

kubeadmバージョンv1.10.3

/etc/systemd/system/kubelet.service.d/10-kubeadm.confの$ KUBELET_NETWORK_ARGSを削除するとうまくいきます。

可視性のために繰り返す:

KUBELET_NETWORK_ARGSは、どの種類のネットワークプラグインを期待するかをkubeletに指示するものであることに注意してください。 それを削除すると、kubeletはプラグインを予期しないため、基盤となるコンテナーランタイムが提供するもの、通常はDocker「ブリッジ」ネットワークを取得します。

これは、特にマシンが1台しかない場合は、問題ない場合があります。 実際にCNIを使用したい場合は役に立ちません。

@waldauf thx、それは動作します

私のフランネルプラグインが正しくインストールされていないときにこれが私に出くわしました。

今日はこのガイド(https://www.techrepublic.com/article/how-to-install-a-kubernetes-cluster-on-centos-7/)に従っていましたが、「/ etc / systemd」のcgroupfs構成を見逃していました。 /system/kubelet.service.d/10-kubeadm.conf」。 私が修正すると、それは魅力のように機能しました

https://github.com/kubernetes/kubernetes/issues/48798#issuecomment -395965665

@ChinaSilenceなぜフランネルを使わなければならないのか説明できますか? フランネルなしではできませんか?

flannel0.10.0とkubernetes1.12.0はどういうわけか一緒に動作できません。 kubernetes 1.12.0に問題があるため、kubernetesを1.11.3にダウングレードしましたが、すべて正常に動作しています。

kubernetesがその問題をすぐに修正することを願っています。

@ bilalx20確認できます
あなたができることは織りやカリコを試すことです、彼らは働きます。

この問題は、Ubuntu16.04とk8s1.12で発生します。

1.11.0にダウングレードすると、すべてが稼働しています。

CentOS7.5とk8s1.12でこの問題が発生しました

/var/lib/kubelet/kubeadm-flags.envからcniプラグイン設定を削除すると正常に機能します

flanneldにはk8s1.12の修正が必要です。
このPRを使用してください(承認されるまで):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
これは既知の問題です: https

@ReSearchITEngが1.12.1で説明する問題を経験しました。 彼/彼女の解決策は私のために働いた。
編集:スクラッチ、ノードの1つはkubeadm join後も同じ問題を示しています
EDIT2:無関係の問題、このGPUノードでnvidia-container-runtimeが欠落していたことが判明しました。 不良ノードでjournalctl -xeu kubeletを使用して診断されました

TL; DR:ソリューションは機能します

@ReSearchITEngのソリューションが

誰かがこれをグーグルしている場合に備えて。 同じ問題が発生しました。私の場合、cloud-initプロセスで/ etc / sysconfig / network-scripts / ifcfg- {interface-name}のNM_CONTROLLEDオプションがnoに設定されました。
NetworkManagerがsdnポッドに必要なresolv.confファイルを作成するには、このオプションをyesに設定する必要があります。

ウィーブマニフェストを実際に適用できなかったため、ネットワークプラグインが初期化されませんでした。
自己メモ:他の場所で答えを探す前に、 Weaveインストールマニュアル全体を読んでください:+1:

flanneldにはk8s1.12の修正が必要です。
このPRを使用してください(承認されるまで):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
これは既知の問題です: coreos / francel#1044

追加:
この問題は、kuberadmの最初のinit corednsが原因であると思いますが、init flannelは原因ではないため、「ネットワークプラグインの準備ができていません:cniconfigが初期化されていません」とスローされます。
解決:

  1. kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.ymlフランネルをインストールします
  2. corednsポッドをリセットします
    kubectl delete coredns-xx-xx
  3. 次に、 kubectl get podsを実行して、機能するかどうかを確認します。

このエラーが表示された場合、「cni0」のIPアドレスはすでに10.244.1.1/24と異なります。
これに従ってください:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

このエラー「失敗したコンテナの再起動をバックオフ」が表示され、次の方法でログを取得できる場合

root<strong i="28">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

次に、障害が発生したノードにファイル「/etc/resolv.conf」が表示されます。ネームサーバーがlocalhostの場合、ループバックが発生します。次のように変更します。

#nameserver 127.0.1.1
nameserver 8.8.8.8

kueblet startconfに--network-plugin = cniを追加します
私のシステムでは:
1.vim /etc/systemd/system/kubelet.service
2.delete --network-plugin = cni
3. kubeletを再起動します(systemctlデーモン-リロード; systemctl restart kubelet)

あなたのシステムで3つのステップを実行してください、多分あなたのインストールは私とは異なります、このようにしてください

削除した@ mdzddl --network-plugin = cni原因kubeletがcniについて文句を言いますか? それほど賢くない。 デフォルトのネットワークプラグインを削除することは、まったくお勧めしません。

flanneldにはk8s1.12の修正が必要です。
このPRを使用してください(承認されるまで):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
これは既知の問題です: coreos / francel#1044

私のために働く!

削除した@ mdzddl --network-plugin = cni原因kubeletがcniについて文句を言いますか? それほど賢くない。 デフォルトのネットワークプラグインを削除することは、まったくお勧めしません。

次に、解決策は何ですか

flanneldにはk8s1.12の修正が必要です。
このPRを使用してください(承認されるまで):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
これは既知の問題です: coreos / francel#1044

追加:
この問題は、kuberadmの最初のinit corednsが原因であると思いますが、init flannelは原因ではないため、「ネットワークプラグインの準備ができていません:cniconfigが初期化されていません」とスローされます。
解決:

  1. kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.ymlフランネルをインストールします
  2. corednsポッドをリセットします
    kubectl delete coredns-xx-xx
  3. 次に、 kubectl get podsを実行して、機能するかどうかを確認します。

このエラーが表示された場合、「cni0」のIPアドレスはすでに10.244.1.1/24と異なります。
これに従ってください:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

このエラー「失敗したコンテナの再起動をバックオフ」が表示され、次の方法でログを取得できる場合

root<strong i="29">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

次に、障害が発生したノードにファイル「/etc/resolv.conf」が表示されます。ネームサーバーがlocalhostの場合、ループバックが発生します。次のように変更します。

#nameserver 127.0.1.1
nameserver 8.8.8.8

kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannelが作成されました
clusterrolebinding.rbac.authorization.k8s.io/flannelが作成されました
serviceaccount / flannelが作成されました
configmap / kube-flannel-cfgが作成されました
https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml 」を認識できません:バージョン「extensions / v1beta1」の種類「DaemonSet」に一致するものがありません
https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml 」を認識できません:バージョン「extensions / v1beta1」の種類「DaemonSet」に一致するものがありません
https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml 」を認識できません:バージョン「extensions / v1beta1」の種類「DaemonSet」に一致するものがありません
https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml 」を認識できません:バージョン「extensions / v1beta1」の種類「DaemonSet」に一致するものがありません
https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml 」を認識できません:バージョン「extensions / v1beta1」の種類「DaemonSet」に一致するものがありません

上記のようにエラーをスローします

flannelは、k8s1.16の最新の変更に準拠するようにマニフェストを更新していません。
CalicoやWeaveNetなどの別のCNIプラグインを試してください。

...またはapps/v1代わりにextensions/v1beta1 apps/v1を使用するようにフランネルマニフェストにパッチを適用します

この問題は、k8s1.16を使用するUbuntu16.04で発生します(vagrantでubuntuを実行します)

/var/lib/kubelet/kubeadm-flags.envからcniプラグインconfを削除すると正常に機能します

flannelは、k8s1.16の最新の変更に準拠するようにマニフェストを更新していません。
CalicoやWeaveNetなどの別のCNIプラグインを試してください。
..。
...または拡張機能/ v1beta1の代わりにapps / v1を使用するようにフランネルマニフェストにパッチを適用します

これはしばらく前に修正されましたが、Kubernetesドキュメントのリンクは、機能しない古いバージョンを示しています(https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster- kubeadm /にはhttps://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.ymlがあります)。 代わりに「マスター」を使用すると機能し、別の問題も修正されます(CNI構成にバージョンがありません)。

これは私が見たものです:このエラーは、フランネルをまだ実行していないときに発生しますが、apiserver、scheduler、controller-managerのマニフェストだけでkubletを開始します-10-kubeadm.confにこの行があります-"Environment =" KUBELET_NETWORK_ARGS = -network-plugin = cni --cni-conf-dir = /etc/cni/net.d --cni-bin-dir = / opt / cni / bin --node-ip = 192.168.8.11 "

コメントして、kubeletを開始します。
次に、コアkubeシステムポッドが表示されます。
次に、kube-proxyをインストールします
次にフランネルをインストールします
*次に、上記の行のコメントを解除して、kubeletを再起動します*
core-dns / kube-dnsをインストールします

こんにちは、
バージョン1.16.0をインストールしようとしていますが、kuberouterプラグを使用していますが、同じエラーが発生します

コンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker:ネットワークプラグインの準備ができていません:cni configuninitialized

こんにちは、
バージョン1.16.0をインストールしようとしていますが、kuberouterプラグを使用していますが、同じエラーが発生します

コンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker:ネットワークプラグインの準備ができていません:cni configuninitialized

実行環境に関する詳細情報を提供できれば、役に立ちます。 たとえば、Operate System、およびエラーが発生する前に何をしましたか。

これは、Amazonでのバージョン1.16.0の新しい新規インストールです。
私はこのAMIを使用しています-k8s-1.16-debian-stretch-amd64-hvm-ebs-2020-01-17
うなめ-a
Linux ip-172-28-125-218 4.9.0-11-amd64#1 SMP Debian 4.9.189-3 + deb9u2(2019-11-11)x86_64 GNU / Linux

1.15.0をインストールしても、まったく問題はありません。

これは、マスターノードのsyslogに表示されるものです。

3月12日05:26:22ip-172-28-125-218kubeletÄ3656Å:E0312 05:26:22.7610093656kubelet.go:2187Åコンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker :ネットワークプラグインがありません準備完了:cniconfigが初期化されていません
3月12日05:26:25ip-172-28-125-218dockerÄ3570Å:I0312 05:26:25.713681 3619dns.go:47ÅDNSView変更なし:5
3月12日05:26:25ip-172-28-125-218kubeletÄ3656Å:W0312 05:26:25.8838573656cni.go:202ÅCNI構成の検証エラー&äkubernetesfalseÄ0xc0009d8260ÅÄ123349911010586101114115105111110 34 58 34 34 44 34110 97109101 34 58 34107117 98101114110101116101115 34 44 34112108117103105110115 34 58 91123 34 98114105100103101 34 58 34107117 98101 45 98114105100103101 34 44 34105112 97109 34 58123 34115117 98110101116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34116121112101 34 58 34 104111115116 45108111 99 97108 34125 44 34105115 68101102 97117108116 71 97116101119 97121 34 58116114117101 44 34110 97109101 34 58 34107117 98101114 110101116101115 34 44 34116121112101 34 58 34 981141051001031013412593125Åå:Äpluginbridgeは構成バージョン ""Åをサポートしていません
3月12日05:26:25ip-172-28-125-218kubeletÄ3656Å:W0312 05:26:25.8839253656cni.go:237Åcni構成を更新できません:/etc/cni/net.d/に有効なネットワークが見つかりません
Mar 12 05:26:27ip-172-28-125-218kubeletÄ3656Å:E0312 05:26:27.762309 3656kubelet.go:2187Åコンテナランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker :ネットワークプラグインがありません準備完了:cniconfigが初期化されていません
3月12日05:26:30ip-172-28-125-218dockerÄ3570Å:I0312 05:26:30.713906 3619dns.go:47ÅDNSView変更なし:5
3月12日05:26:30ip-172-28-125-218kubeletÄ3656Å:W0312 05:26:30.886362 3656cni.go:202ÅCNI構成の検証エラー&äkubernetesfalseÄ0xc0008fc000ÅÄ123349911010586101114115105111110 34 58 34 34 44 34110 97109101 34 58 34107117 98101114110101116101115 34 44 34112108117103105110115 34 58 91123 34 98114105100103101 34 58 34107117 98101 45 98114105100103101 34 44 34105112 97109 34 58123 34115117 98110101116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34116121112101 34 58 34 104111115116 45108111 99 97108 34125 44 34105115 68101102 97117108116 71 97116101119 97121 34 58116114117101 44 34110 97109101 34 58 34107117 98101114 110101116101115 34 44 34116121112101 34 58 34 981141051001031013412593125Åå:Äpluginbridgeは構成バージョン ""Åをサポートしていません
3月12日05:26:30ip-172-28-125-218kubeletÄ3656Å:W0312 05:26:30.8864283656cni.go:237Åcni構成を更新できません:/etc/cni/net.d/に有効なネットワークが見つかりません

/var/lib/kubelet/kubeadm-flags.envからcniプラグインconfを削除すると、K8s1.16.8を使用するCentOS7.6でも機能します。

何も変更しないでください。 このコマンドを実行するだけです。 エラーはなくなります。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

1.18で機能した@ikramuallahに感謝し

何も変更しないでください。 このコマンドを実行するだけです。 エラーはなくなります。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

ありがとう!

何も変更しないでください。 このコマンドを実行するだけです。 エラーはなくなります。
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

ありがとう!

申し訳ありませんが、リンクにアクセスできません。 何か間違えている ?

@juxunyリンクは問題ありませんが、一時的なネットワーク接続の問題が発生している可能性がありますか?

誰か助けてください
kube-proxy-windows-xhxzwの場合、ポッドのステータスはContainerCreatingです。ポッドについて説明すると、次のように警告が表示されます。

警告NetworkNotReady3m27s(x4964 over 168m)kubelet、casts1ネットワークの準備ができていません:ランタイムネットワークの準備ができていません:NetworkReady = false理由:NetworkPluginNotReadyメッセージ:docker:ネットワークプラグインの準備ができていません:cni config uninitialized

他のすべてのポッドは実行状態です。 kube-proxy-windowsを除く

以下のようにkubernetes環境を作成しました。
マスターノード対応V1.19.0RHEL 7 OS
ワーカーノードNotReadyV1.19.0 Windows Server 2019
Windowsワーカーノードをマスターノードに参加させようとしています

フランネルネットワークを使用しています。 私は以下の解決策を試しました:
1.kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

  1. 10-flannel.confglistのcniVersionを「0.3.1」から「0.2.0」に変更します。
    10-flannel.confglistはすでにそこにありました。

正確な問題を教えてください

私の場合、初期のkubernetesマスターであるときに、この問題が発生しました。 etcd内のすべてのデータを削除した後、プロセスの初期化は成功しました
すべてのetcdノード:
systemctl stop etcd
rm -rf / var / lib / etcd / *
systemctlデーモン-reload && systemctl enable etcd && systemctl start

このページは役に立ちましたか?
0 / 5 - 0 評価