/ cc @lukemarsden @luxas @mikedanese

jbeda 2017年03月29日

＃43474を完全に元に戻すと、0.2.0 CNIプラグインが壊れてしまう状況になります（https://github.com/kubernetes/kubernetes/issues/43014を参照）。

https://github.com/kubernetes/kubernetes/pull/43284のようなことを検討する必要があり

また、/ cc @thockin

jbeda 2017年03月29日

/ cc @ kubernetes / sig-ネットワーク-バグ

jbeda 2017年03月29日

参照： https ：

yujuhong 2017年03月29日

@jbeda --loglevel = 5でいくつかのkubeletログを取得できますか？

dcbw 2017年03月29日

@ yujuhong-これは意図したとおりに機能していると思います。とにかく、kubeadmはこの振る舞いに依存していました。＃43474で重大な変更を導入しました。 1.7でこれを修正する正しい方法について話すことができますが、今のところ、kubeadmを再び機能させる必要があります。

jbeda 2017年03月29日

現在進行中のSlackディスカッション-https： //kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

jbeda 2017年03月29日

ノードの準備ができていなくても、DaemonSetsは引き続きスケジュールされているようです。これは本当に、この場合、 kubeadmは少し偏執的すぎます。

テストする現在の計画では、 kubeadmマスターノードの準備が整うのを待つのではなく、単に登録するだけです。これは、CNIDaemonSetがCNIをセットアップするようにスケジュールできるようにするのに十分なはずです。

@kensimonはこれをテストしています。

jbeda 2017年03月29日

👍1

@jbedaええ、DaemonSetコントローラーは、主にネットワーク性を完全に知らないため、引き続きそれらをキューに入れるようです。これをもっと一般的に修正する必要があります。 kubeですぐにできることはありますか、それとも今のところすべてkubeadmにありますか？

dcbw 2017年03月29日

Ubuntu16.04にkubeadmを使用してkubernetesをインストールしようとしています。これに対する簡単な修正はありますか？

luhkevin 2017年03月29日

👍25 😕2 👎1

パッチを当てたバージョンをお持ちの場合は、 @ jbedaをテストしてください。

stevenbower 2017年03月29日

👍4

kubeadmがノードのNotReadyステータスを超えていますが、 node.alpha.kubernetes.io/notReady汚染によりノードの実行が妨げられているため、作成されるダミーデプロイメントが機能していません。許容範囲を追加しても効果がないようです。現時点でどのように進めるかは正確にはわかりません。誰かがnotReady汚れを許容するポッドを展開する方法に光を当てることができますか？

ノードをnotReadyとしてマークしないなど、他のいくつかのオプションを検討していますが、それが私たちのやりたいことであるかどうかは明確ではありません。

kensimon 2017年03月29日

kubeletコマンドラインからKUBELET_NETWORK_ARGSを削除することで回避しました。その後、kubeadm initは正常に機能し、canalcniプラグインをインストールすることができました。

sbezverk 2017年03月29日

👍4

@sbezverkその方法を説明して

overip 2017年03月29日

@sbezverk （good find :)）の結果を確認できます

coeki 2017年03月29日

@ overip / etc / systemd / system / kubelet.service.d / 10-kubeadm.confを編集する必要があります

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

$ KUBELET_NETWORK_ARGSを削除します

その後、bebeadminitが機能するようになってからkubeletを再起動します。

sbezverk 2017年03月29日

👍10 ❤1

これは私がしたことです

kubeadmリセット

以下からENVエントリを削除します。

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemdおよびkubeサービスをリロードします

systemctlデーモン-リロード
systemctl restart kubelet.service

initを再実行します

kubeadm init

jp557198 2017年03月29日

👍15 👎8

すべて正しい、そして私たちがそれにいる間

これが表示された場合：
kubelet：エラー：実行に失敗しましたkubelet：作成に失敗しましたkubelet：設定ミス：kubelet cgroupドライバー： "cgroupfs"はdockercgroupドライバーとは異なります： "systemd"

/etc/systemd/system/kubelet.service.d/10-kubeadm.confを編集して、フラグ--cgroup-driver = "systemd"を追加する必要があります。

上記のようにします

kuebadmリセット
systemctlデーモン-リロード
systemctl restart kubelet.service
kubeadminit。

coeki 2017年03月29日

👎2 👍1

kubelet CLIフラグから--network-plugin=cniを削除する場合は注意が必要です。これにより、kubeletはデフォルトでno_opプラグインを使用します...この場合でもcalico / weaveなどの一般的なプラグインが機能する場合は驚きます（ただし、次に、これらのプラグインがその下でどのように動作するかについての私の理解は少し制限されています。）

kensimon 2017年03月29日

@kensimon hm、セットアップで問題は発生していません。canalcniプラグインをデプロイしましたが、正常に機能しました。

sbezverk 2017年03月29日

@sbezverkクロスホストネットワークもうまく機能していますか？

resouer 2017年03月29日

@resouerは確認できません、私はオールインワンとしてのみ1.6.0を持っています。

sbezverk 2017年03月30日

@ resouer @ sbezverkマシンに正常に参加しました。

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

`` `[ root @ deploy-01 x86_64] ＃kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
etcd-deploy-011 / 1実行050m
kube-apiserver-deploy-011 / 1実行051m
kube-controller-manager-deploy-011 / 1実行050m
kube-dns-3913472980-6plgh3 / 3ランニング051m
kube-proxy-mbvdh1 / 1ランニング04m
kube-proxy-rmp361 / 1ランニング051m
kube-scheduler-deploy-011 / 1ランニング050m
kubernetes-dashboard-2396447444-fm8cz1 / 1ランニング024m
weave-net-3t4872 / 2ランニング044m
weave-net-hhcqp2 / 2ランニング04m

`` `

coeki 2017年03月30日

回避策は機能しますが、フランネルを動かすことができません...

stevenbower 2017年03月30日

@stevenbowerの最悪のシナリオでは、この設定を元に戻し、kubeadmビジネスが終了したらkubeletを再起動できます。

sbezverk 2017年03月30日

weaveが機能する3ノードクラスターを取得しました。このハックでこれがどれほど安定しているかはわかりませんが、とにかく感謝します！：スマイリー：

webwurst 2017年03月30日

サイドノードでは、マスターのinitが通過した後、$ KUBELET_NETWORK_ARGSを元に戻すことができます。参加したマシンでは実際には削除せず、cgroup-driverのみを削除しました。そうしないと、kubeletとdockerが連携しません。

ただし、kubeadmをリセットする必要はありません。/etc/systemd/system/kubelet.service.d/10-kubeadm.confを変更して、systemctlダンスを実行するだけです。

systemctlデーモン-リロード
systemctl restart kubelet.service

coeki 2017年03月30日

👍4

KUBELET_NETWORK_ARGSを削除し、それが機能することを報告している方へ：

私の場合、2つのクラスターがあります。1つはhttps://github.com/kubernetes/kubernetes/pull/43824からパッチを適用し、初期化時にkubeadmを正常に続行させ、もう1つはKUBELET_NETWORK_ARGSを削除したものです。 KUBELET_NETWORK_ARGSが削除されたクラスターでは、ポッド間のトラフィックはすべて失敗します。

KUBELET_NETWORK_ARGSが削除されたクラスターの場合：

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

通常のKUBELET_NETWORK_ARGSがあり、kubeadmにパッチが適用されているクラスターの場合：

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

KUBELET_NETWORK_ARGSを無効にした方は、上記が機能するかどうかを確認してください。

kensimon 2017年03月30日

ノードレディとダミーデプロイメントチェックの両方を削除することをお勧めします
1.6の場合はすべて、1.7の検証フェーズに移動します。

2017年3月29日午前10時13分、「DanWilliams」 [email protected]は次のように書いています。

@jbeda https://github.com/jbedaええ、DaemonSetのように見え
コントローラーは、主に完全に無知であるため、引き続きそれらをキューに入れます
ネットワーク性の。これをもっと一般的に修正する必要があります。ある
kubeですぐにできることはありますか、それとも今のところすべてkubeadmでですか？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
。

mikedanese 2017年03月30日

👍3

Ubuntu 16.04を実行している人は他にいますか？ systemdサービスからKUBELET_NETWORK_ARGSを削除し、 systemdデーモンをリロードしました。マスターノードを起動できますが、ノードに参加できません。エラーThe requested resource is unavailableで失敗します

LaurentDumont 2017年03月30日

KUBELET_NETWORK_ARGSが削除され、ポッド間のトラフィックが失敗します。

KUBELET_NETWORK_ARGSがkubeletに使用するプラグイン、構成とバイナリを探す場所を指示するので、私は驚かないでしょう。あなたはそれらが必要です。

yujuhong 2017年03月30日

1.6の修正として、＃43835（および1.6チェリーピック＃43837）をお勧めします。私は両方をテストしました、そして、彼らは働きます。 @jbedaと@luxasを割り当てて、目覚めたときに

mikedanese 2017年03月30日

これらのPRはどちらも合理的に見えます。ただし、代わりにhttps://github.com/kubernetes/kubernetes/pull/43824を使用することを検討する必要があると思います。少し複雑ですが、そのコードパスが保持されるため、デーモンセットを使用せずにCNIを事前構成するユーザーがいます（これはhttps://github.com/jbeda/kubeadm-gce-tfで行いますが、まだ行っていません）。 1.6に更新）ノードの準備ができるまで待ちます。

ボーナスとして、これは@kensimonのKubernetesへの最初のPRであり、彼はこのようなものをテストするために立ち寄りました。しかし、正直なところ、どちらも実行可能であり、私は本当にそれが修正されることを望んでいます。 :)

jbeda 2017年03月30日

申し訳ありませんが、 https：//github.com/kubernetes/kubernetes/pull/43824を見逃しました

mikedanese 2017年03月30日

両方ともうまくいくなら、私も満足しています

WIZARD-CXY 2017年03月30日

@kensimon KUBELET_NETWORK_ARGS間にkubadm init KUBELET_NETWORK_ARGSのみを無効にすると、うまくいきます。あなたの指示のおかげで私はそれを確認することができました。

webwurst 2017年03月30日

KUBELET_NETWORK_ARGS間にkubadm init KUBELET_NETWORK_ARGSのみを無効にした場合にのみ、 @ webwurstが機能することを確認し@kensimonからのチェックは機能し、DNSは解決します。

私はこれがひどいハックであり、ほとんどの人がたるんだチャネルを見てフォローするにはあまりにも恐ろしいことに同意します。

より良い解決策は、 @ kensimonまたは@mikedaneseからのパッチによって提示されます。

coeki 2017年03月30日

@coekiどのようにしてましたか。 kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-systemを試しましたが、kube-dnsは保留中のkube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
説明するように、それは正確にやった：削除KUBELET_NETWORK_ARGS 、 sudo systemctl daemon-reload && sudo systemctl restart kubelet.service 、 kubeadm init追加し、 KUBELET_NETWORK_ARGS再び、 sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
しかし、私のマスターはNotReadyとどまります。 describe私は得る

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

上記のようにkube-dnsの再起動を試みましたが、成功しませんでした。何か案が？私はこれで死にかけています。1.6.0のアップグレードに失敗した後、クラスターを再び実行しようとしています:(

patte 2017年03月30日

@patteだから私はdelete pods kube-dns-3913472980-3ljfx -n kube-system 、その後kube-dnsが再び表示されます。

kubeadm initの後で、 KUBELET_NETWORK_ARGS追加し、もう一度sudo systemctl daemon-reload && sudo systemctl restart kubelet.service weaveやcalicoなどのポッドネットワークをインストールしましたか？最初にそれを追加すると、それを機能させることができるはずです。

私はcentos7で試し、テストしましたが、ubuntu / xenialで行ったので、動作するはずです。

私がしたことを要約すると：

KUBELET_NETWORK_ARGS削除します
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

KUBELET_NETWORK_ARGSもう一度追加します
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

マシンに参加しました。私はvagrantを使用しているため、通常は静的ルートを10.96.0.0（クラスターIP）に追加する必要があります。
$ TOKENと一緒に使用しますが、この手順は余分です。

それで：

delete pods kube-dns-3913472980-3ljfx -n kube-system

それを待つ

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

それは恐ろしいハックですが、私にとってはうまくいきます;）

coeki 2017年03月30日

kubernetes開発コミュニティが公式の修正のためのETAを提供していないことに本当に驚いています。これは恐ろしいバグであり、コードテスト中に簡単に見つけられるはずです。少なくとも、1.6.1は修正を加えてできるだけ早くプッシュする必要があります。そうすれば、人々はクラスターのハッキングをやめ、生産的なことを始めます;）。私はここで間違っていますか？

sbezverk 2017年03月30日

👍14

やあみんな、

今週は少し気が散ってしまいましたが、これは長いスレッドです。
kubeadmのもの私はそれをよく知りません。誰かが私のために要約できますか？私
私はバグの要点を理解していると思いますが、提案された解決策は何ですか？
何が彼らを恐ろしいものにしますか？

2017年3月30日木曜日午前8時13分、Serguei Bezverkhi < [email protected]

書きました：

kubernetes開発コミュニティがそうではないことに本当に驚いています
公式の修正のためにETAを提供しました。これは恐ろしいバグだということです
コードテスト中に簡単に捕まるはずです。ないので、で
少なくとも、1.6.1は修正を加えてできるだけ早くプッシュする必要があります。そうすれば、人々は
クラスターのハッキングをやめ、生産的なことを始めましょう;）。私は
ここで間違っていますか？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
。

thockin 2017年03月30日

kubeletの変更（＃43474）により、cniプラグインが初期化される前に、kubeletがネットワークの準備ができていないことを正しく報告し始めました。これにより、依存していた順序が壊れ、kubeadmマスターの初期化でデッドロックが発生しました。この変更に至るまでの数日間、kubeadm e2eテストが中断されていたため、検出されませんでした。

現在提案されている修正は＃43824と＃43835です。

mikedanese 2017年03月30日

わかりました、それは私が理解したことでした。ネットワークプラグイン間のインターロック
近づいてきて、ノードの準備は今少しひどいです。

8:28の木、2017年3月30日には、マイクDanese [email protected]
書きました：

kubeletの変更（＃43474
https://github.com/kubernetes/kubernetes/pull/43474）kubeletに
cniプラグインが準備される前にネットワークの準備ができていないことを正しく報告し始めます
初期化されました。これは私たちが依存していたいくつかの注文を破り、引き起こしました
kubeadmマスターの初期化でのデッドロック。聞き取れませんでした
kubeadm e2eテストは、この変更に至るまでの数日間中断されていました。
現在提案されている修正は＃43824です。
https://github.com/kubernetes/kubernetes/pull/43824および＃43835
https://github.com/kubernetes/kubernetes/pull/43835 。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
。

thockin 2017年03月30日

私はまだ＃43835が好きです。これはより単純な変更であり、e2eチェックを現在の場所で実行する必要はないと思います。また、＃43824がまだ機能していないという報告があります。今日はこれを解決するためにプッシュします。

mikedanese 2017年03月30日

回避策からの担保の処理に多くの努力が無駄になっているため、今日それを解決するために+1します。

sbezverk 2017年03月30日

❤7

1.6.0がリリースされる前に、誰もkubeadm1.6.0を実際に試したことがないなんて信じられません。

また、kubelet 1.5.6 + kubeadm 1.5.6も壊れています。/etc/systemd/system/kubelet.service.d/10-kubeadm.confは/etc/kubernetes/pki/ca.crtを参照していますが、kubeadmは生成しません。 ca.crt、ca.pemがありますが。

現在、1.6.0と1.5.6がk8saptリポジトリに残っている唯一のリリースです...

Dieken 2017年03月30日

👍1

「箱から出して壊れた」、今日学んだ言葉。

Dieken 2017年03月30日

😄20 👍2

私はまだ＃43835が好きです。これはより単純な変更であり、e2eチェックを現在の場所で実行する必要はないと思います。また、＃43824がまだ機能していないという報告があります。今日はこれを解決するためにプッシュします。

これについてマイクに同意します。＃43835はより単純な変更であり、検証（必要な場合）は別のフェーズで実行できます。

yujuhong 2017年03月30日

@thockinは、特にho stNetwork：trueを使用する場合、ネットワークのよりきめ細かい条件とステータスが本当に必要

クラウドプロバイダーに固有であるため、nodeNetworkUnavailableを使用することはできません。おそらく、別の1つ、またはスケジューラーがNet workReady：falseのノードでhostNetwork：trueポッドを許可する方法、または

dcbw 2017年03月30日

同意。素晴らしい答えがなかったので、私は問題を遅らせてきました、
しかし、1.7でこれを取得する必要があります

10:02の木、2017年3月30日には、ダン・ウィリアムズ[email protected]
書きました：

@thockinhttps ：//github.com/thockin私たちは本当にきめ細かい必要があり
ネットワークの条件とステータス、特にho stNetwork：trueの場合。
ノードは一部のポッドの準備ができていますが、他のポッドの準備はできていません。
クラウドに固有であるため、nodeNetworkUnavailableを使用できません
プロバイダー。おそらく別のもの、またはスケジューラーがする方法が必要です
NetworkReady：falseを使用して、ノードでho stNetwork：trueポッドを許可するか、
汚染は、準備ができていないノードに対して機能します。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
。

thockin 2017年03月30日

@thockin任意の好ましい解決策？ノードの準備をブロックして、すでに行ったように誰がIsNodeReady（）を使用しているかを調べるか、別のノード条件を追加して、コードベースのwho-know-how-manyビットを他の場所で修正することができます。または、別のオプションがあるかもしれません。

dcbw 2017年03月30日

クラウドプロバイダーに固有であるため、nodeNetworkUnavailableを使用することはできません。おそらく、別の1つ、またはスケジューラーがNet workReady：falseのノードでhostNetwork：trueポッドを許可する方法、または

スケジューラーは、準備ができていないすべてのノードを完全に除外するのではなく、汚染と許容範囲を尊重するように修正できると思います。
ただし、誰かがho stNetwork：trueポッドに許容値を適用する必要があります。誰なのかはわかりませんが、ポッドの仕様を理解するようにスケジューラーに教えるのはあまりにも多すぎるように思われるので、スケジューラーであってはなりません。

/ cc @davidopp @ dchen1107

yujuhong 2017年03月30日

また、私のパッチやマイケルのパッチを試したことがあり、コントロールプレーンが起動するのを待っている人には、v1.6.0クラスターを管理する場合、 masterからkubeadmを構築しても機能しないように見えます。、kubeadmが無効な引数でkube-apiserverを起動しようとしているため：

unknown flag: --proxy-client-cert-file

鉱山またはマイケルの変更をv1.6.0クラスターに対してテストする場合は、今のところマスターの上に構築するのではなく、v1.6.0に対してそれらをチェリーピックします。

kensimon 2017年03月30日

@yujuhongスケジューラーは、すでにポッドに許容値を自動適用しています（https://github.com/kubernetes/kubernetes/pull/41414を参照）。これは、十分に類似したユースケースのようです。

kensimon 2017年03月30日

私はすべての汚染と準備状況の明確な画像を持っていません
ネットワーク、この時点で。ダン、書き留めるのに30分ありますか
現在の状態、それで私たちはそれをバラバラにし始めることができますか？私はあなたがそれを知っていると思います
一番。私たちが抱えている細かい問題がたくさんあるように感じます
これまでのところ毛布で覆われています。

10:22の木、2017年3月30日には、ケン・サイモン[email protected]
書きました：

@yujuhonghttps ：//github.com/yujuhongスケジューラーはすでに
許容値をポッドに自動適用します（＃41414を参照）
https://github.com/kubernetes/kubernetes/pull/41414 ）、これは
同様の十分なユースケース
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
。

thockin 2017年03月30日

@thockin私はそれを行うことができます、どこに置くべきですか？

dcbw 2017年03月30日

関連する問題がいくつかあります。そのうちの1つにタイトルを付け直して、投稿してください。
現在の状態の要約とそこから行きますか？

10:50の木、2017年3月30日には、ダン・ウィリアムズ[email protected]
書きました：

@thockin https://github.com/thockin私はそれを行うことができます、どこに置くべきですか
それ？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
。

thockin 2017年03月30日

この修正がCentOSリポジトリにいつ移植されるかについていつでも連絡がありますか？

junsaw 2017年03月30日

👍8

1.6では、デフォルトでコアKubernetesはノードに汚染を自動的に適用しません。スケジューラーは、kubeadm、kopsなどのデプロイメントシステムによって追加された、またはユーザーによって手動で追加された汚染を尊重します（そして、ポッドに追加された対応する許容範囲を尊重します）。

1.6では、デフォルトで、Kubernetesスケジューラは、ネットワークが利用できないなど、特定のノード状態を報告している場合、ノードを考慮から除外します。そのためのコードはここにあり

1.6では、NodeReady == "False"またはNodeReady == "Unknown"がある場合は常に、コアKubernetes（NodeController）がNoExecute汚染を追加するアルファ機能を有効にできます。これにより、ノードで実行されているポッドが削除され（汚染を許容しない場合）、新しいポッドがノードにスケジュールされなくなります（汚染を許容しない場合）。

長期計画では、「スケジューリングとエビクションに関して、コアKubernetesがノードの状態にどのように反応するか」ロジックをすべて移動して、汚染と許容範囲を使用することです（例：＃42001）。しかし、私たちはまだそこにいませんし、しばらくはありません。したがって、当面は、ポッドがNetworkUnavailableまたは追加する可能性のあるその他のノード条件を「許容」する方法はありません。

davidopp 2017年03月30日

@davidoppが正しく言ったことを理解している場合、関数はNodeReadyであり、true、false、またはunknownを返し、必要なものをリストにチェックします。満たされていない値のリストが返される可能性がある場合は、それに対してテストできます。

kubeadmの場合、NetworkUnavailableが唯一の場合です。 kubeadmはtrueを返すことができます。これは、kubeadminit時にnetworking / cniプラグインを渡したくない場合です。

原因よく理解できれば、少なくともkubeadmについては、この関数に基づいて汚染と許容値が設定されます。

私が間違っている場合は私を訂正してください;）

coeki 2017年03月30日

私がこの問題にぶつかったので、このスレッドにジャンプします、そしてそれは迷惑です：

ネットワークの準備が、ノード上のネットワークの状態に基づいてkubeletが追加および削除する汚染にならないのはなぜですか？
これにより、ネットワーク準備の汚染を許容するすべてのポッド（ポッドネットワークアプリ）に対してノードを「準備完了」にすることができます。

ホストネットワークポッドの場合、アドミッションコントローラーはポッドネットワークの準備状況を悪化させる可能性があります。

vishh 2017年03月31日

それはdavidoppのコメントの長期計画と一致していると思います。

mikedanese 2017年03月31日

それはdavidoppのコメントの長期計画と一致していると思います。

はい、正確に。長期的な計画では、すべてのノードの状態を汚染し、Kubernetesの内部でノードの状態に注意を払うことをやめます。私たちは、私が言及した1.6アルファ機能でその作業を開始しました。

davidopp 2017年03月31日

確認します。 v1.6パッチリリースで汚染に切り替えない理由はありますか？

vishh 2017年03月31日

ノードの状態に基づいて汚染を自動的に追加するコードは、1.6でアルファ版になりました。信頼する準備ができていません。（現在、ノードの準備完了状態のみを処理し、ネットワークは処理しません）。

davidopp 2017年03月31日

したがって、私が正しく理解していれば、今のところ、 https：//github.com/kubernetes/features/issues/166がネットワークの可用性を正しく汚染できるようになるまでに時間がかかるため、回避策を講じる必要があります。 https://github.com/kubernetes/features/issues/166でこれを修正するコメントを付けて、＃43835のようにkubeadmの修正をできるだけ早くプッシュできれば、多くのpplが満足するでしょう。

coeki 2017年03月31日

👍1

@davidoppあなたは「頼りにされていない」と言うつもりだったと思います。私はまだ、ネットワークの問題のために直接汚染を投稿するkubeletのであなたが言及した汚染ロジックに対する自動条件の間の関係を見逃しています。

vishh 2017年03月31日

はい、ありがとうございます。タイプミスでしたが、今すぐ修正しました

はい、Kubeletに汚染を追加させることができます。 Kubeletに一部のノード条件の汚染を追加させ、NodeControllerに他のノード条件の汚染を追加させることは理想的ではない場合があります（後者はマスターのみが到達不能ノードを検出できるため必要です）が、これは単なるソフトウェアエンジニアリングの議論であり、基本的なことではありません。私の計画では、NodeControllerがすべてのノード条件に汚染を追加することでしたが、そのようにするための強い要件はありません。

davidopp 2017年03月31日

確認します。この場合、単一のノード条件には、ノードコントローラーが識別できない可能性のあるいくつかの属性が関連付けられています。
@mikedaneseノードが機能するというkubeadm initの既存の動作は魅力的だと思います。 validationフェーズを追加するという要件が、主にこの問題に基づいて推進されていないことを願っています。
@dcbw @thockin @yujuhong kubeletのノード構成の問題を表すためにtaintsを使用することについて何か考えはありますか？

vishh 2017年03月31日

新しい汚染でノードの現在の自動フィルターアウトをNetworkUnavailableに置き換える場合は、前述の関数を変更する必要があることに注意してください（つまり、ノードをフィルターで除外する一連の条件から削除します）。その関数はスケジューラー以外のノードリスターで使用される可能性があるため、他にどのような副作用があるのかわかりません。

davidopp 2017年03月31日

Ubuntuで動作するはずの1.5.6をインストールする方法はありますか？ある場合は、その方法を説明していただけますか？ありがとう！

overip 2017年03月31日

新しい汚染でノードの現在の自動フィルターアウトをNetworkUnavailableに置き換える場合は、前述の関数を変更する必要があることに注意してください（つまり、ノードをフィルターで除外する一連の条件から削除します）。その関数はスケジューラー以外のノードリスターで使用される可能性があるため、他にどのような副作用があるのかわかりません。

@davidoppNetworkUnavailableとNodeReadyについて注意する必要があります。実際にクリーンアップする必要がある2つの別々の条件があります。

nodeNetworkUnavailable-これはクラウドルートに固有であり、ノード間のクラウドルートが設定されている場合、クラウドルートコントローラーのみがこの状態をクリアします。オーバーレイを作成するネットワークプラグイン、またはノード間のL3ルーティングを行わないネットワークプラグインは、この条件を望まないか、使用しません。この条件は、どのネットワークプラグインによっても追加されません。特にGCEまたはAWSがクラウドプロバイダーとして選択されている場合に、kubeletによって追加されます。別の条件であるため、NodeReadyには影響しません。

NodeReady-ネットワークプラグイン（CNIやkubenet、dockershim / CRI-Oなどのリモートランタイムなど）の影響を直接受けます。

考慮すべき3つの別々の問題があります。

クラウドルート-クラウドインフラストラクチャとネットワークプラグインにクラウドルートが必要な場合、クラウドルートがない（NodeNetworkUnavailable = trueなど）と、hostNetwork = falseポッドのスケジュールをブロックする必要があります
ネットワークプラグイン-プラグインの準備がまだ整っていない場合は、hostNetwork = falseポッドのスケジューリングをブロックする必要があります。プラグインはクラウドルートに依存しないため、ルートコントローラーと直接対話しない可能性があるため、これはNodeNetworkUnavailableとは別のものです。たとえば、他の何か（クラウドルート、フランネルなど）でノードルートを設定している場合は、kubenetをノードでローカルに使用できます。
hostNetwork = trueポッドは、これらすべての条件を無視してスケジュールする必要がありますが、他の該当する条件（ディスク容量など）が適用されます。

NodeReadyはハンマーとしては大きすぎます。ネットワークプラグインの準備のために（クラウドルートの準備とは別に！）追加のNetworkPluginReady条件が必要だと思います。それから、気になる場所にそれを配管する必要があります:(または、実際には、条件ではなく新しい汚染。

dcbw 2017年03月31日

私が見つけた別の回避策。

kubeadmが「[apiclient]最初のノードは登録されましたが、まだ準備ができていません」と出力し続けている間に、フランネルをインストールする「kube-flannel.yml」をデプロイしました。また、構成ファイルを変更せずに機能しました。

1）kubeadm init --pod-network-cidr = 10.244.0.0 / 16＆
2）cp /etc/kubernetes/admin.conf〜/.kube/config
3）kubectl apply -f kube-flannel-rbac.yml（kubeadm 1.6で必要）
4）kubectl apply -f kube-flannel.yaml
https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.ymlでkube-flannel.yamlを使用し

マスターノードを「準備完了」にすることができます。しかし、kube-dnsはメッセージで失敗しました。

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

ネットワークプラグインをweave-netに変更した後、機能しました。

bhtak 2017年03月31日

@dcbwこの号で説明されている特定の問題について、正確に何をすべきかを説明するのに十分な

davidopp 2017年03月31日

パッチを当てたデブをテストしてください

kubernetes-xenial-unstableは、 @ pipejakobと私が今日テストしているパッチが適用されたビルド1.6.1-beta.0.5+d8a384c1c5e35d-00があります。ポッドネットワークが作成されるまで、ノードは準備ができていません（たとえば、織り/フランネル構成を適用することによって）。適合性テストに合格。 PTAL。

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

mikedanese 2017年03月31日

👍1

汚染者がほとんどすべてを表現できる一般的な方向性は
条件は可能であり、したがってあらゆる点でより良いですか？

より詳細な信号が必要であることに同意します。私たちはまだ整理する必要があります
kubelet、ネットドライバー、クラウドコントローラー、クラウドプロバイダー間の相互作用
hostNetwork = falseポッドのロックを解除しますが、hostNetwork = trueはロック解除しないでください
ブロックされました。

午前7時24分PMの木、2017年3月30日には、ダン・ウィリアムズ[email protected]
書きました：

新しい汚れを現在の自動で置き換える場合は注意してください
NetworkUnavailableのノードを除外するには、を変更する必要があります。
前に述べた関数（つまり、一連の条件から削除する）
ノードを除外します）。私は他にどんな副作用があるのか分かりません
その関数は、ノードリスター以外のノードリスターで使用される可能性があるためです。
スケジューラー。
@davidopphttps ：//github.com/davidopp注意する必要があります
NetworkUnavailableとNodeReady。 2つの別々の条件があります
本当にクリーンアップする必要があります：
nodeNetworkUnavailable-これはクラウドルートに固有であり、クラウドのみです
ルートコントローラは、ノード間のクラウドルートが
設定されています。オーバーレイを作成する、またはL3を実行しないネットワークプラグイン
ノード間のルーティングは、この条件を望まないか、使用しません。この状態は
ネットワークプラグインによって追加されません。特にkubeletによって追加されたのは
GCEまたはAWSがクラウドプロバイダーとして選択されています。以来、NodeReadyには影響しません
それは別の条件です。
NodeReady-ネットワークプラグイン（CNIやkubenetなど）の影響を直接受けます
またはdockershim / CRI-Oなどのリモートランタイム）。
考慮すべき3つの別々の問題があります。
クラウドルート-クラウドインフラストラクチャとネットワークプラグインの場合
クラウドルートが必要で、次にクラウドルートがない（例：
NodeNetworkUnavailable = true）は、hostNetwork = falseのスケジューリングをブロックする必要があります
ポッド
ネットワークプラグイン-プラグインの準備がまだ整っていない場合は、
hostNetwork = falseポッドのスケジューリングをブロックする
hostNetwork = trueポッドは、これらすべての条件を無視し、
スケジュールされていますが、その他の該当する条件（ディスク容量など）が適用されます
NodeReadyはハンマーとしては大きすぎます。私たちはおそらく欲しいと思っています
ネットワークプラグインの準備のための追加のNetworkPluginReady条件
（クラウドルートの準備とは別に！）そして、それを配管する必要があります
気になる場所まで:(
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
。

thockin 2017年03月31日

kubelet KUBELET_NETWORK_ARGS構成行を削除して一時的な修正を試みている人のために、 @ jc1arkeはより簡単な回避策を見つけました-新しいマスターへの2つのセッションを持ち、最初のノードの準備が整うのを待っている間に、2番目のノードネットワーク構成を適用しますセッション：
kubeadmin initを実行した後の最初のセッション：

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
...

2番目のセッション（Calicoを使用。もちろん選択は異なる場合があります）：

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

最初のセッションに戻る：

...
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

zatricky 2017年03月31日

👍3

汚染者がほとんどすべてを表現できる一般的な方向性は
条件は可能であり、したがってあらゆる点でより良いですか？

かなり。下位互換性の懸念があるため、ノードの状態を取り除くことはおそらくできませんが、それらに基づいてアクションを実行するマスター内のすべてのロジックを取り除くことができます（スケジューリングのブロックやポッドの削除など）。動作をより明確にする（どの条件がスケジューリングをブロックするか、どの条件がエビクションを引き起こすか、エビクションを待つ時間などを記憶する必要がない）ことに加えて、条件への反応はポッドごとに構成可能です。

davidopp 2017年03月31日

@mikedaneseと@pipejakobからのデブをテストしたところ、これらは

ubuntu / xenialでテスト済み：

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

coeki 2017年03月31日

@mikedaneseと@pipejakobからのデブをテストしたところ、まだフリーズしています
[apiclient] Created API client, waiting for the control plane to become ready

５分ほど待ちましたが、何も変わりませんでした。
そして昨日それは繰り返し続けました
[apiclient] First node has registered, but is not ready yet

TTIは、問題はまだ解決策ではないと思いますか？

Ubuntu 16.04でテスト済み：
kubeadmバージョン：version.Info {メジャー： "1"、マイナー： "6 +"、GitVersion： "v1.6.1-beta.0.5 + d8a384c1c5e35d"、GitCommit： "d8a384c1c5e35d5118f79808deb7bab41f3f7964"、GitTreeState： "clean"、BuildDate： "2017 -03-31T04：20：36Z "、GoVersion：" go1.7.5 "、コンパイラ：" gc "、プラットフォーム：" linux / amd64 "}

myqq0000 2017年03月31日

@ myqq0000使用しているバージョンを投稿できますか？

kubeadm version

coeki 2017年03月31日

@coekiああ、忘れてしまいました。私は今編集し、以前のコメントでバージョンを投稿しました。 :)

myqq0000 2017年03月31日

@mikedanese centos yumリポジトリを更新する予定はありますか？それとも、yumリポジトリにすでにデプロイされていますか？

bhtak 2017年03月31日

👍2

1.6.1-beta.0.5+d8a384c1c5e35d-00試してみました（https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036に記載されている1.6.1-beta.0.5+48c6a53cf4ff7d-00は存在しないようです）。

正常に動作しているようです。
無関係：weaveを使用している場合は、「デフォルト」 https：/の代わりにhttps://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yamlを適用する必要があることに注意してください。 /git.io/weave-kube

mausch 2017年03月31日

@mauschこれらの

srinat999 2017年03月31日

@ srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

jimmycuadra 2017年03月31日

@mikedaneseパッチを適用したdebsは私のために働きます。これに取り組んでくれてありがとう！：笑顔：

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

webwurst 2017年03月31日

@mauschありがとう。彼らは私のためにも織りネットワークプロバイダーで働いています。

srinat999 2017年03月31日

Centosにも同じ修正を作成するチャンスはありますか？私たちのゲーティングシステムは、主にkubernetesクラスターベースにcentosを使用しています。私がcentosバージョンを持っている場合、私は約を保証することができます。テストとして、1日に100回のkubeadminitを実行します。

sbezverk 2017年03月31日

👍13

@mikedaneseのパッチが適用されたdebsは、部分的には機能します。 kubeadmはクラスターの準備ができていることを通知していますが、ノード自体は準備ができていません。

squall0gd 2017年03月31日

@ squall0gdノードは、ポッドネットワークが適用されたときに準備ができている必要があります（例： kubectl apply -f https://git.io/weave-kube-1.6

mikedanese 2017年03月31日

私のテスト環境（centos / 7マシンに基づくvagrant）では、kubeadmがハングします。 straceを使用すると、マスター上のkubeletサーバーに接続しようとし、FUTEX_WAIT、epoll_waitの再試行ループを実行していることがわかります。しかし、そこからの単一行のouf出力はありません。

kubeletが起動しないのが原因のようです。
（しかし、kubletが起動しない理由はわかりません。）

これはこの問題の問題ですか？

http://yum.kubernetes.io/repos/kubernetes-el7-x86_64リポジトリからバイナリを取得します。
また、 https： //storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/からバイナリを更新してみ

==>テスト用にパッチを適用したバージョンのkubeadmはどこで入手できますか？ <==

注：https： //github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 （パッチが適用されたバージョンはhttps：// heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm）ですが、それは私には機能しません。動作は同じです（出力はまったくありません）...

obnoxxx 2017年03月31日

@ squall0gd表示されている正確なメッセージを表示していただけますか。あなたの説明に基づいて、実際に新しい.debsを取得したのか、それとも古いキャッシュバージョンを使用していたのか疑問に思います。

pipejakob 2017年03月31日

@thockin @davidoppなので、Timの提案に従って、既存の問題を指揮するか、新しい問題を提出して、解きほぐされたネットワークの準備状況を追跡し、実際の状況ではなく汚染に変換し、 https：// githubのほとんどにコピーし

dcbw 2017年03月31日

unstableリポジトリで私のために機能しているように見えるものは次のとおりです（マスター自体のみをテストしました）：

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

これはある時点でerror: taint "dedicated:" not foundを吐き出しますが、それでも継続しているようです。

thenayr 2017年03月31日

👍3

これらのテストを1.6ブランチで実行しませんか？

bgrant0607 2017年03月31日

@davidoppノード条件は、理由、メッセージ、遷移時間など、何が起こっているのかを理解するために、人間に追加情報を提供することを目的としています。

bgrant0607 2017年03月31日

kubeadmは、リリースブランチでテストされているようには見えません。
https://k8s-testgrid.appspot.com/release-1.6-all

bgrant0607 2017年03月31日

@ bgrant0607どうやら、kubeadm e2eテストは、1.6リリース、IIRCに至るまでの約1週間、無効化/機能していませんでした。

dcbw 2017年03月31日

ノード条件は、理由、メッセージ、遷移時間など、何が起こっているのかを理解するために、人間に追加情報を提供することを目的としています。

@ bgrant0607は主に人間の情報を対象としていますか、それとも単なる幸せな副作用ですか？主に人間向けの場合、現在のように意思決定をスケジュールするために使用する必要がありますか、それともそれから離れる必要がありますか？

dcbw 2017年03月31日

@dcbw Taintsは、スケジュール不能と混乱の根源になることを目的としています。最終的に、スケジューラーは条件を無視する必要があります。

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

bgrant0607 2017年03月31日

ノードに汚染を追加する場合は、考慮する必要があることに注意してください

a）マスター汚染と同様に、下位互換性： https ：

b）バージョンスキュー。クラスターを1.6にアップグレードすると、kubeletは混合リリースになり、1.4と同じくらい古いものもあります。

bgrant0607 2017年03月31日

要約するか、これを解析すると、次のようになります。

@dcbwに基づく

nodeNetworkUnavailableはクラウドプロバイダーのものであり、kubeadm atmに関連付けられていないため、これに遭遇する可能性があります。

ただし、ループの根本原因であるNodeReadyは、より詳細にする必要があります。これは、プローブ/ライブネス、CNI対応などに関して、ボックスをチェックしているリストに基づいて、 @ davidoppが汚染になりたいもの

議論することはできますが、ラベルを付けてみませんか？

しかし、 @ dcbwは、この議論により適したスレッドを見つけましたか？これは、展開に関する問題のバケツになり、実際には根本的な問題ではないためです。

私は実際には問題に到達しておらず、その周りにハックを投稿していたことを知っています:)

しかしとにかく、別の場所で基本について話し合い、修正に関するETAがここに配置されていることを確認して、次に進む必要があります。

きびきびではありませんが、まあ:)

PSはい@ bgrant0607これをもっとテストすべきだった
PS2私がこれを間違って見た場合、あなたは私を責めることができます;）

coeki 2017年04月01日

@coekiまた、N-1バージョンをrpm / debリポジトリに保持するように要求を追加します。すべてのメジャーリリースは、最終的に1つか2つの問題を抱えることになります。オペレーターは、まさにその理由から、本番用のN.0リリースを長い間避けてきました。以前のバージョンがしばらく残っている場合はうまく機能します。しかし今回は、1.6が安定する前に1.5.xが完全に削除されました。これにより、問題が解決されている間、準備が整っていなかったオペレーター（ローカルリポジトリミラーリングなど）が前進することができなくなります。でこぼこのN + 1リリースの痛みは、Nをしばらく維持するだけで対処できることがよくあります。

kfox1111 2017年04月01日

👍2

@ kfox1111ゲーティングも問題です....それについてはより良い戦略が必要です:)

coeki 2017年04月01日

なぜ古いリリースを完全に削除するのですか？それは簡単に人々の自動化を壊し、繰り返し可能なインストールを妨げる可能性があります。

jimmycuadra 2017年04月01日

ノード条件は、理由、メッセージ、遷移時間など、何が起こっているのかを理解するために、人間に追加情報を提供することを目的としています。

同意しました。 UXは間違いなく、ノードの状態を取り除くことができない主な理由です。ただし、マスターアクション（エビクションやブロッキングスケジューリングなど）のトリガーとしてのノード条件のすべての使用を取り除き、代わりに汚染を使用できると信じています。

長期的には（v2 APIの長期的なように）、汚染に理由とメッセージを追加してノードの状態を取り除くことができると考えられますが、私はそれについて実際には考えておらず、正式にそうすることを提案していません。（すでに、一方向の遷移時間に相当するTimeAddedがあります。）

davidopp 2017年04月01日

@coekiいいえ、私が話していたことはゲーティングとは何の関係もありません。可能性のあるすべてのことをテストするゲートがない限り、ゲーティングはすべての問題を見つけることはできません。オペレーターは自分たちの環境で奇妙なことをするのが好きです。 :)可能な限りすべてをテストするには法外な費用がかかります。

少なくとも最初のバグ修正リリースまでに新しいリリースが作成される前に、古いリリースを削除しないようにお願いしています。この例では、1.6.1です。少なくとも。より古いバージョンを維持することはさらに良いことです。これは、新しいバージョンのバグが解決されている間、オペレーターが進歩を続けることができるようにするためのベストプラクティスです。

kfox1111 2017年04月01日

@ kfox1111 、それはゲーティングが行うことであり、良いと思われるものと一緒に行くのではなく、古い良い信頼できる方法を捨てて、今起こったことです。

@davidoppラベルと汚染は、APIの見方、UX、機械とは異なる区別があるかもしれないことに同意しますが、今は拡散しています。私も、それは:)

coeki 2017年04月01日

とにかく、あなたは私を議論に誘い込みます、私たちは本当にこの問題に参加していません、それが私のポイントでした。

coeki 2017年04月01日

もう一度質問したいのですが、「kubeadm init」が出力なしでぶら下がっているのを見ると（起動に失敗したkubeletサーバーに接続しようとしています）、この問題が発生していますか？そして、これが事実である場合、＃43835は私にとっての修正ですか？

今どこで入手できますか：

kubeadm / kubectl / kubeletの古い（1.6.0より前の）バージョン
またはkubeadmのパッチバージョン（＃43835またはその他の修正を含む）？

ありがとう！

obnoxxx 2017年04月01日

（注：上記のコミットで参照されているパッチが適用されたバージョンのkubeadmは、私には機能しません...）

obnoxxx 2017年04月01日

@obnoxxxは、release-1.6ブランチのヒントを試してください。

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

mikedanese 2017年04月01日

❤1

@mikedaneseありがとう！しようとしています...

obnoxxx 2017年04月01日

OSパッケージをインストールせずにkubeadmを実行する場合は、次のことを行う必要があります。

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.confから

mikedanese 2017年04月01日

@mikedaneseありがとう。私はosパッケージ（kube repoから）をインストールしてから、rpmからのバイナリの上にWebURLからバイナリをインストールしています...

1.6.1-beta.0.12バージョンは私には機能しませんでした：
kubeadm initは、出力なしでハングします。（kubeletに接続しようとしています）

obnoxxx 2017年04月01日

CentOSの場合は、systemdドライバーも忘れないでください。

kfox1111 2017年04月01日

システムドライバ？

obnoxxx 2017年04月01日

https://github.com/kubernetes/release/issues/306

mikedanese 2017年04月01日

おやおや、ありがとう、それは良いです！ :-)

obnoxxx 2017年04月01日

@pipejakob現在、このログにアクセスできませんが、kubeadmのバージョンを確認しました。これは、 @ webwurstと同じバージョンapt-cache policy kubeadm可能なkubeadmバージョンを確認しました。そして、kubernetes-xenial-unstableからのエントリは1つだけでした。
@mikedanese投稿する前にフランネルで試しました;）
編集：プラットフォーム全体を再構築しましたが、 kubadmは正常に機能しています：+1：

squall0gd 2017年04月01日

みんな修正の現状はどうですか？近いうちに安定したリポジトリに移動する予定ですか？

miadabrin 2017年04月01日

👍6

@mikedaneseのパッチが適用されたdebsは、同じ「ネットワークプラグインの準備ができていません」ということを行っています。

ChipmunkV 2017年04月03日

rhel（rpm）用のパッチバージョンのkubeadmを作成する方法を教えてもらえますか？

discostur 2017年04月03日

👍2

パッチが適用されたdebsを指定した

マスターノードはNotReadyます。

weave-net （weaveworks / weave-kube：1.9.4-https：//github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml）は1/2 CrashLoopBackOff ：

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

kube-dnsポッドは0/3 Pendingます。

ChipmunkV 2017年04月03日

@ChipmunkVおそらく、ユーザースペースで実行するように

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

価値があるので、 kubernetes-xenial-unstableは私にとってうまく機能しています。

pstadler 2017年04月03日

@pstadler 、ネットワークが重複していることを指摘してくれたチャットのIPALLOC_RANGEを再構成しました。

ChipmunkV 2017年04月03日

@thenayrに感謝します。 Kubernetesマスターを起動することもできますが、kubeadmjoinを使用して1人のワーカーをマスターに接続することもできます。すぐにもっと更新を投稿します

yugesha 2017年04月03日

@mikedaneseここですべてのコメントを読むまで、使用するバージョンを見つけるのに永遠に時間がかかりました。特定のバージョンのバイナリを見つけやすくする必要があります。 ci-cross/latest.txt指すもの（つまりv1.7.0-alpha.0.1982+70684584beeb0c ）を使用してみましたが、新しいkube-apiserverフラグ（つまりd8be13fee85075abfc087632b3dbc586a10897adの--proxy-client-key-file ）が導入されました。 gcr.io/google_containers/kube-apiserver-amd64の最近のタグでは機能しません...

バケットにバイナリが含まれているリビジョンを簡単に把握するにはどうすればよいですか？ディレクトリを一覧表示できると便利です。または、単純なマップファイルなど、知っている必要も推測する必要もないものがあれば十分です。

errordeveloper 2017年04月03日

@errordeveloperリリースを実行しようとしているので、安定したブランチに修正をプッシュできます

mikedanese 2017年04月03日

前のリリース1.5.6は、CentOSの7の上に私のために働いていたが、中kubeadmの唯一のバージョンであるため、今私もロールバックすることはできませんhttp://yum.kubernetes.io/repos/kubernetes-el7-x86_64が壊れ1.6です。 0。 kubeadm 1.5.6 RPMを取得する方法に関する提案はありますか？

bostone 2017年04月03日

確かに、それは残念です。古いバージョンは完全に削除されたようです。 :-(

obnoxxx 2017年04月03日

私の結果はcentos7で次のとおりです。

パッチを適用した最新のkubeadmを使用しても、kubectlについて何もしなくても、kubadminitを取得して結果を得ることができませんでした。
@coekiの指示でkubectlを開始することができ、その後kubeadmも合格しました。しかし、その後は何もうまくいきません。 kubectlは言う

The connection to the server localhost:8080 was refused - did you specify the right host or port?

何が起こっているのかヒントはありますか？

obnoxxx 2017年04月03日

@obnoxxxは、デフォルトでは8080でリッスンせず、安全な6443ポートでリッスンします。netstat-tunlpで確認できます。
admin.confを/ etc / kubernetesから$ HOME / .kube / configにコピーする必要があります
$ HOME / .kube /内のファイルのアクセス許可を変更してください。その後、kubectlがapiserverに正しく接続できるようになります。 HTH。セルゲイ

sbezverk 2017年04月03日

@apsinhaこのスレッドを知っていますか？将来に向けていくつかの重要なポイントがあると思うので、何人かの製品関係者をフォローしてもらうのは良いことかもしれません。

頭のてっぺんから：

1.6.0は自動テストを通過しませんでした： https ：
古いバージョンのバイナリ/パッケージが削除されたため、ユーザーは安全にロールバックできません。引き続き利用可能であると想定していたインストールの自動化を破りました： https ：
これが壊れているという事実の（私が見た）公の発表はありません
修正についてのタイムラインはありません（私は開発者なので、「いつ修正されますか？」と尋ねられるのがどれほど不快かは知っていますが、それでも、人々はこれを尋ねるので、少なくとも推定期間を提供するのは良いことです）
会話に参加し続けるユーザーは、状況、回避策、修正スケジュールについて混乱しています
貢献者の間での多くの技術的な議論（その多くは長期的な戦略に関するもの）が、何が起こっているのか、そして差し迫った問題にどのように対処するのかを理解しようとしているユーザーと同じスレッドで組み合わされています

Kubernetesをそれが何であるかを作るすべての偉大な人々を軽視するつもりはありません。 Kubernetesが信頼性が高く安定しているという一般の認識の観点からは見栄えが悪いため、ここで前進する「教えられる瞬間」があることを願っています。（付与されたkubeadmはアルファ/ベータですが、それでも多くの可視性があります。）

jimmycuadra 2017年04月03日

👍8 😕4

kubernetes / release.rpmを使用してkubeadm-1.5.6をビルドしたのは、（残念ながら）それを見つけるためだけでした。

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

bostone 2017年04月03日

@bostoneここで.specを調整する必要があります。

gtirloni 2017年04月03日

👍1

@sbezverkヒントをありがとう！今はもっといいです...

これは好奇心が強いです：

以前のリリースでadmin.confをコピーする必要があったことを覚えていません。
以前にkubectl -s localhost:6443試しましたが、それだけでは不十分でした。

とにかく、今は続けることができます。再度、感謝します

obnoxxx 2017年04月03日

v1.6.1はリリース中です。それはEODによって行われます。

mikedanese 2017年04月03日

👍5

いくつかの注意：

古いパッケージが削除される問題は、 https ：。 kubeadmの奇妙なバージョン管理と、これらがアルファベット順に並べ替えられているため、リポジトリにkubeadmの1.5.xバージョンを保持することができなかったようです。（ @bostoneあなたの問題はそこでも参照されています）
ここで追跡されているPRでのkubeadme2eテスト： https ：
公告についてはツイッターに

これらはすべて、PMで取り上げるのに適した問題です。 @pipejakobは、その事後

jbeda 2017年04月03日

@obnoxxx 1.5ではAPIサーバーが安全でないポートを公開していたため、admin.confをコピー/ chownする必要がありました。 1.6で変更しました。ここで、安全な資格情報を使用してAPIサーバーにアクセスする必要があります（https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2を参照）

jbeda 2017年04月03日

@mikedaneseいいですね、ありがとう！
私はダミーです-この問題に関して、このリリース1.6.1の効果はどうなりますか？
kubeletは/etc/systemd/system/kubelet.service.d/10-kubeadm.conf （ @ coekiの回避策）に変更せずに開始しますか、それとも＃43835の修正が含まれますか（これは私には何の効果もなかったようです）？

obnoxxx 2017年04月03日

@jbeda説明ありがとう

obnoxxx 2017年04月03日

@jbeda混乱は、YUMリポジトリをhttp://yum.kubernetes.io/repos/kubernetes-el7-x86_64に設定している公式のkubadmインストールドキュメントに起因すると思います

bostone 2017年04月03日

そして再び私の失望に1.5.6rpmを構築し、インストールすることは同じ正確な問題で終わった。 kubeadm init実行すると、まったく同じ行にぶら下がっています。

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

1.6.1のリリースを待つだけだと思います...

bostone 2017年04月03日

1.6.1が出ました。

mikedanese 2017年04月04日

🎉5

@mikedaneseこのバグを閉じる前に、kubeadmをテストしましたか？今、私はすでに10分間[apiclient] Created API client, waiting for the control plane to become readyを見つめています。真新しい1.6.1がインストールされたCentOS7

bostone 2017年04月04日

@bostoneこの問題が

編集してみ/etc/systemd/system/kubelet.service.d/10-kubeadm.confおよび追加--cgroup-driver=systemd

systemctl daemon-reload; systemctl restart kubeletを実行することを忘れないでください

gtirloni 2017年04月04日

@gtirloniと私たちの提案でkubeadm init終わりに到達しましたが、kubectlを実行しようとすると、次のエラーが発生します： The connection to the server localhost:8080 was refused - did you specify the right host or port?どこでどのように変更するか、または正しいポートは何ですかこの点？

bostone 2017年04月04日

👍1

これが関連しているかどうかはわかりませんが、 systemctl status kubelet実行すると次のようになります。
`` `systemctl status kubelet -l
●kubelet.service-kubelet：Kubernetesノードエージェント
ロード済み：ロード済み（/etc/systemd/system/kubelet.service;有効;ベンダープリセット：無効）
ドロップイン：/etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
アクティブ：月曜日からアクティブ（実行中）2017-04-03 17:31:07 PDT; 11分前
ドキュメント： http ：
メインPID：10382（kubelet）
CGroup：/system.slice/kubelet.service
├─10382/ usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --allow-privileged = true- -network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorization-mode = Webhook --client-ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = systemd
└─10436journalctl-k-f

Apr 03 17:41:56 sdl02269 kubelet [10382]：W0403 17：41：56.645299 10382 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Apr 03 17:41:56 sdl02269 kubelet [10382]：E0403 17：41：56.645407 10382 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false理由：NetworkPluginNotReady メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていない `` `

bostone 2017年04月04日

はい、テストしました。 e2eテストはリリースブランチに合格しています。他の問題が発生している可能性があります。

mikedanese 2017年04月04日

@bostone kubeadm init後にこれらの手順が欠落している可能性がありますか？

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

また、ここで説明ます。これは、発生しているcniconfigエラーに関連しているようです。

gtirloni 2017年04月04日

👍1

また、[apiclient]を凝視してAPIクライアントを作成し、Ubuntu16.04と1.6.1の新規インストールでコントロールプレーンがすでに10分間準備できるのを待っています

TechauraIO 2017年04月04日

@pingthings Slack Kubernetesとkubeadmチャネルに参加することをお勧めします。そこでデバッグをお手伝いします。

LaurentDumont 2017年04月04日

次の手順を実行して、centos-release-7-3.1611.el7.centos.x86_64でKubernetesクラスターを正常にセットアップしました（Dockerは既にインストールされていると想定しています）。

1）（/ etc / yum.repo.d / kubernetes.repoから）baseurl = http：//yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=>最新のKubernetes1.6.1の不安定なリポジトリを使用するには
2）yum install -y kubelet kubeadm kubectl kubernetes-cni
3）（/ etc / systemd / system / kubelet.service.d / 10-kubeadm.conf）最後の行の最後に「--cgroup-driver = systemd」を追加します。
=>これは、Dockerがcgroup-driverにsystemdを使用し、kubeletがcgroup-driverにcgroupfsを使用するためです。
4）systemctl enable kubelet && systemctl start kubelet
5）kubeadm init --pod-network-cidr 10.244.0.0/16
=>以前に--api-advertise-addressesを追加した場合は、代わりに--apiserver-advertise-addressを使用する必要があります。
6）cp /etc/kubernetes/admin.conf $ HOME /
sudo chown $（id -u）：$（id -g）$ HOME / admin.conf
KUBECONFIG = $ HOME /admin.confをエクスポートします
=>この手順を実行しないと、kubectlgetでエラーが発生する可能性があります
=>私は1.5.2ではやっていない
7）kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0ではロールベースのアクセス制御が導入されているため、Flannelデーモンセットを作成する前にClusterRoleとClusterRoleBindingを追加する必要があります
8）kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=>フランネルデーモンセットを作成する
9）（すべてのスレーブノードで）kubeadm join --token（トークン）（ip）:( port）
=> kubeadminitの結果に示されているように

上記のすべての手順は、Kubernetes-1.6.0、特にkubeadmに関するさまざまな問題からの提案を組み合わせた結果です。

これがあなたの時間を節約することを願っています。

eastcirclek 2017年04月04日

👍9

これは解決されていないようです（Ubuntu LTS、kubeadm 1.6.1）。

まず、 --apiserver-advertise-addressフラグを使用しているときに、「作成されたAPIクライアント、コントロールプレーンの準備が整うのを待っている」にkubeadmがぶら下がっているのも経験しました。ジャーナルログには次のように記載されています。

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

このフラグを指定しないと、kubeadmは成功しますが、それでもkubeletの開始時に次のエラーが発生します。

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

Kubeletが適切に起動することを拒否し、 kubectlでクラスターに接続できません

sheerun 2017年04月04日

👍6

1.5.x kubeadmバージョンがcentosリポジトリからだけでなく、Ubuntu LTSからも削除されたようです： https ：//packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages Itダウングレードが困難になり、実際には下位互換性が失われます

sheerun 2017年04月04日

@bostone

「コントロールプレーンの準備が整うのを待っている」というコツを理解しましたか？ 1.6.1ですべての変更を試した後、同じことがわかります。

ghost 2017年04月04日

@gtirloni @srzjulio kubeadm init後にこれらの手順を追加しても役に立ちませんでした。 kubeletサービスがfailedからactive (running)が、まだThe connection to the server localhost:8080 was refused - did you specify the right host or port?メッセージがあります。そして、聞いているサービスを見ると、8080はどこにも見当たりません。私が見ることができるのは、kubeletがこれらのポートでリッスンしていることです。

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

それで、8080を誤って指すいくつかの間違った（変更された？）設定がありますか？

bostone 2017年04月04日

@bostone必要なkubeletポートではなく、kube-apiserverであり、6443ポートでリッスンしている必要があります。

sbezverk 2017年04月04日

@sbezverkポートに関してはデフォルトを変更しませんでした（指示にはありません）8080から6443に切り替えるには何をする必要がありますか？

bostone 2017年04月04日

@bostone apiserverマニフェストで何も変更しなかった場合、デフォルトでは6443ポートでリッスンします。 /etc/kubernetes/admin.confを$ HOME / .kube / configにコピーし、設定ファイルの権限を変更するだけで、すべての設定が完了します。

sbezverk 2017年04月04日

@sbezverkところで-私はすべてのインストール手順をrootとして実行していますが、 kubeadm init出力からのこれらの3つの命令行は、sudoユーザーの使用を示唆しています。これに関する推奨事項は何ですか？すべてのインストール手順もsudoとして実行する必要がありますか？

bostone 2017年04月04日

わかりました、私は最初からすべてのステップを実行しました、そしてそれはより良いようです。これまでのところうまくいった手順は次のとおりです。CentOS7でrootとして実行しています。

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

-cgroup-driver=systemdを10-kubeadm.confに追加して保存します

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

この時点で、 kubectl get nodesを実行して、リストにマスターノードを表示できます。
除く手先のためのすべての手順を繰り返しkubeadm init 、代わりに実行されているkubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443によって生成されたとしてkubeadm init
このステップが完了し、マスターノードとミニオンノードが表示されます

そして今-問題：

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

したがって、ノードの準備ができていないように見えます。助言がありますか？

bostone 2017年04月04日

🎉1

を使用しているため、織りが適切に展開されていないと思います
1.6より前のyamlファイル。

「kubectlapply-fhttps ： //git.io/weave-kube-1.6」を試してください

2017年4月4日火曜日12:24 PMに、BoStoneの[email protected]は次のように書いています。

わかりました、私は最初からすべてのステップを実行しました、そしてそれはより良いようです。これが
これまでのところうまくいった手順で、rootとして実行しています。
猫<
[kubernetes]
name = Kubernetes
baseurl = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled = 1
gpgcheck = 1
repo_gpgcheck = 1
gpgkey = https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
setenforce 0
yum install -y docker kubelet kubeadm kubectl kubernetes-cni
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
-cgroup-driver = systemdを10-kubeadm.confに追加し、保存します
systemctl enable docker && systemctl start docker
systemctl enable kubelet && systemctl start kubelet
sysctl -w net.bridge.bridge-nf-call-iptables = 1
systemctl stop Firewalld; systemctl disablefirewalld
kubeadm init
cp /etc/kubernetes/admin.conf $ HOME /
chown $（id -u）：$（id -g）$ HOME / admin.conf
KUBECONFIG = $ HOME /admin.confをエクスポートします
kubectl apply -f https://git.io/weave-kube
この時点で、kubectl getノードを実行して、マスターノードを確認できます。
リスト。
もちろんkubeadmjoinを実行することを除いて、minionに対してすべての手順を繰り返します。
--kubeadmによって生成されたトークンa21234.c7abc2f82e2219fd12.34.567.89：6443
初期化
このステップが完了し、マスターノードとミニオンノードが表示されます
そして今-問題：
kubectlgetノード
名前ステータス年齢バージョン
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1
kubectldescribeノードabc02918
イベント：
SubObjectPathタイプの理由メッセージからのFirstSeenLastSeenカウント
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet、sdl02918通常の開始kubeletを開始します。
43m 43m 1 kubelet、sdl02918警告ImageGCFailedがコンテナのデータを見つけることができません/
43m 43m 29 kubelet、sdl02918通常のNodeHasSufficientDiskノードsdl02918のステータスは次のようになりました：NodeHasSufficientDisk
43m 43m 29 kubelet、sdl02918通常のNodeHasSufficientMemoryノードsdl02918のステータスは次のようになりました：NodeHasSufficientMemory
43m 43m 29 kubelet、sdl02918通常のNodeHasNoDiskPressureノードsdl02918のステータスは次のようになりました：NodeHasNoDiskPressure
42m 42m 1 kube-proxy、sdl02918通常の開始kube-proxyを開始します。
したがって、ノードの準備ができていないように見えます。助言がありますか？
—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
。

sjenning 2017年04月04日

👍4

CentOSと1.6.1-1バージョンのkubeadmを使用し、上記の手順に従うと、動作が少し異なります。クラスターは準備完了として報告されますが、次のメッセージでスタックします。

[apiclient] Temporarily unable to list nodes (will retry)

ただし、ログには同じエラーがあります。

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

dcowden 2017年04月04日

@sjenning以上です！すべてが機能するかどうかを確認するために、まだいくつかのイメージをデプロイする必要がありますが、 Readyステータスのすべてのノードを表示できます！みんなありがとう（今のところ:)

bostone 2017年04月04日

@bostone使用したのと同じレシピに従いましたが、結果が異なりました。kubeadminitを通過できませんでした。どのDockerバージョンを使用していますか？おそらくそれが私の場合の違いですか？

dcowden 2017年04月04日

@dcowdenそれはyumが私のシステムDocker version 1.12.6, build 96d83a5/1.12.6選ぶものです。また、以前のインストールに加えて修正を試みるのではなく、使用していたすべてのVMを再プロビジョニングするのに役立ちました。

bostone 2017年04月04日

@bostoneありがとう。そのバージョンにダウングレードして、動作するセットアップを取得できるかどうかを確認します。私のシステムでは、最新は奇妙な17.03.1.ceバージョンです（明らかに最新のものです）

dcowden 2017年04月04日

👍1

それが一般的に役立つかどうかはわかりませんが、私はその
CentOS7のすべての手順を実行します

https://github.com/sjenning/kubeadm-playbook

YMMVですが、少なくともプロセスを文書化しています。私もいくつかのことをします
dockerをjsonファイルロギングとオーバーレイストレージを使用するように切り替えます。

実際にプレイブックを実行していなくても、参照として役立つ場合があります。

12:55で火、2017年4月4日には、デイブ・コーデン[email protected]
書きました：

@bostonehttps ：//github.com/bostoneありがとう。それにダウングレードします
動作するセットアップを取得できるかどうかを確認するバージョン。私のシステムでは、最新のものは
奇妙な17.03.1.ceバージョン（明らかに最新の最高）
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
。

sjenning 2017年04月04日

👍4

@sjenningありがとう！それはとても役に立ちます！

dcowden 2017年04月04日

わかりました、ここに1つの問題があります。マスターとミニオンでkubeadm resetを実行し、dockerとkubeletサービスを再起動した後、 kubeadm initがCreated API client, waiting for the control plane to become readyで再びハングします。誰かがkubeadmをリセットするための完全な手順を提供できますか？
@sjenning最初にプレイブックを実行した後、プレイブックを再実行しようとしましたか？

bostone 2017年04月04日

私の場合、 @ bostoneは/var/lib/etcd/移動することでうまくいきました。

autostatic 2017年04月05日

@autostaticディレクトリは空で、名前を変更しても役に立ちませんでした。 @sjenningあなたのプレイブックがハングアップしました、私はあなたのためにチケットを作成しました

bostone 2017年04月05日

誰かがv1.6.1でダッシュボードを実行しようとしましたか？次のようなエラーが発生します。

`禁止（403）

ユーザー " system：serviceaccount ：kube- system：default "は、クラスタースコープで名前空間を一覧表示できません。（名前空間を取得）
`

Flannelを実行するために必要なように、さらにRBACを構成する必要があると思いますか？

ghost 2017年04月06日

@srzjulioそのための新しい問題を

jbeda 2017年04月06日

@srzjulio RBACルールを更新する必要があります。これを使用して、次のことを実行しました。

apiVersion：rbac.authorization.k8s.io/v1alpha1
種類：ClusterRoleBinding
メタデータ：
名前：cluster-admin
roleRef：
apiGroup：rbac.authorization.k8s.io
種類：ClusterRole
名前：cluster-admin
科目：

種類：グループ
名前：システム：マスター
種類：グループ
名前：システム：認証済み
種類：グループ
名前：システム：未認証

sbezverk 2017年04月06日

👎6

注意してください- @ sbezverkが持つバインディングは、基本的にRBACをオフにすることです。そうすると、非常に安全でないクラスターになります。

jbeda 2017年04月07日

👍3

kind: Group
name: system:unauthenticated

これは特に悪いです。つまり、資格情報がなくてもAPIサーバーに接続できる人なら誰でも、任意のコマンドを実行できます。

ericchiang 2017年04月07日

@jbedaこれは、箱から出してすぐに1.5.6で行った動作と一致します。これにより、新しいセキュリティルールで何もできなくなる代わりに、セキュリティ構成を確認して徐々に調整する機会が得られます。

sbezverk 2017年04月07日

実際、 system：unauthenticatedをクラスター管理者にすることは1.5.6よりはるかに悪いです

承認が必要ない場合は、AlwaysAllow承認者を使用してください

liggitt 2017年04月07日

監査中にすべてを許可する場合は、RBAC、AlwaysAllowの組み合わせを使用します

これにより、匿名リクエストが無効になり、RBAC拒否がAPIサーバーログに記録されますが、認証されたすべてのリクエストが引き続き必要な処理を実行できるようになります。

liggitt 2017年04月07日

申し訳ありませんが、これをもう一度繰り返しますが、これは元の問題とは何の関係もありません。そして、有効な問題や問題はありますが、会話を別の場所に移す必要があります。

もう一度申し訳ありませんが、Enterキーを押すのが早すぎますが、現状では次のようになります。

1-リリース1.6.0は問題を引き起こします
2-すべてが修正されているわけではありません
3-RBACに移行する（私の意見では良い）が、問題があるのはなぜですか？ポイント4を参照
4-これはあまりよく伝えられておらず、ドキュメントやブログなど、それを説明するものはあまりありません。
5-私は救助しようとしているすべてのpplに頭を下げますが、これを行うためのより良い方法が必要です

coeki 2017年04月07日

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissionsは、権限を開くための最も詳細なオプションの優れたガイドです。

liggitt 2017年04月07日

kubletに「

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

dockerデーモンでわかります。

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

ReSearchITEng 2017年04月12日

@ReSearchITEng Dockerを1.12.6に更新してみませんか？このバージョンではチャームのように機能します。

sbezverk 2017年04月12日

@sbezverk ：

ReSearchITEng 2017年04月12日

助けてくれてありがとう。
最後に、フランネルを使用してk8s1.6.1を完全に機能させます。すべては今、ansibleプレイブックにあります。
Centos / RHELでテスト済み。 Debianベース（Ubuntuなど）の準備も始まりましたが、多少の改良が必要な場合があります。

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS：sjenning / kubeadm-playbookに基づいた作業- @ sjenningに感謝し

ReSearchITEng 2017年04月15日

@sjenning @ReSearchITEng
こんにちは、私はあなたが作成したものと非常によく似たvagrant + ansibleプレイブック[0]を持っていますが、それでも動作させることができません。ネットワークのセットアップで失敗しています。私はカリコ、ウィーブ、フランネルを試してみましたが、3つすべてが失敗しました（症状は異なりますが）。

私はこれらのバージョンを実行しています：
[ vagrant @ master〜] $ docker --version
Dockerバージョン1.12.6、ビルド3a094bd / 1.12.6
[vagrant @ master〜] $ kubelet --version
Kubernetes v1.6.1
[vagrant @ master〜] $ kubeadmバージョン
kubeadmバージョン：version.Info {メジャー： "1"、マイナー： "6"、GitVersion： "v1.6.1"、GitCommit： "b0b7a323cc5a4a2019b2e9520c21c7830b7f708e"、GitTreeState： "clean"、BuildDate： "2017-04-03T20：33： 27Z "、GoVersion：" go1.7.5 "、コンパイラ：" gc "、プラットフォーム：" linux / amd64 "}

エラー：

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

これは重要な情報のように見えますが、修正方法がわかりません。

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

どんな助けでも大歓迎です...

[0] -https：//github.com/thiagodasilva/kubernetes-swift/tree/master/roles

thiagodasilva 2017年04月26日

私はあなたの側で何が悪いのか特定できませんでした。
https://github.com/ReSearchITEng/kubeadm-playbookのプレイブックを使用して別のインストールを作成し、違いを確認することを強くお勧めします。
PS：私の最後のテストは、kube *と画像の両方で1.6.2を使用しており、問題ないようです。

ReSearchITEng 2017年05月02日

@kelseyhightower

davidopp 2017年05月20日

@ReSearchITEng申し訳ありませんが、報告するのを忘れましたが、最終的には機能するようになりました。vagrant+ ansibleファイルは次のとおりです： https ：

thiagodasilva 2017年05月22日

同じ問題が発生しましたが、マスターノードのcni構成をワーカーノードの対応する場所にコピーするだけで、OKになりました。

systemctl status kubelet.service -l

●kubelet.service-kubelet：Kubernetesノードエージェント
ロード済み：ロード済み（/etc/systemd/system/kubelet.service;有効;ベンダープリセット：無効）
ドロップイン：/etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
アクティブ：火曜日2017-06-06 10:42:00 CST以降アクティブ（実行中）。 18分前
ドキュメント： http ：
メインPID：4414（kubelet）
メモリ：43.0M
CGroup：/system.slice/kubelet.service
├─4414/ usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --network-plugin = cni- -cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorizatio -ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = cgroupfs
└─4493journalctl-k-f

Jun 06 10:59:46 contiv1.com kubelet [4414]：W0606 10：59：46.215827 4414 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Jun 06 10:59:46 contiv1.com kubelet [4414]：E0606 10：59：46.215972 4414 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false準備完了メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていません
Jun 06 10:59:51 contiv1.com kubelet [4414]：W0606 10：59：51.216843 4414 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Jun 06 10:59:51 contiv1.com kubelet [4414]：E0606 10：59：51.216942 4414 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false準備完了メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていません
Jun 06 10:59:56 contiv1.com kubelet [4414]：W0606 10：59：56.217923 4414 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Jun 06 10:59:56 contiv1.com kubelet [4414]：E0606 10：59：56.218113 4414 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false準備完了メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていません
Jun 06 11:00:01 contiv1.com kubelet [4414]：W0606 11：00：01.219251 4414 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Jun 06 11:00:01 contiv1.com kubelet [4414]：E0606 11：00：01.219382 4414 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false準備完了メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていません
Jun 06 11:00:06 contiv1.com kubelet [4414]：W0606 11：00：06.220396 4414 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
Jun 06 11:00:06 contiv1.com kubelet [4414]：E0606 11：00：06.220575 4414 kubelet.go：2067]コンテナランタイムネットワークの準備ができていません：NetworkReady = false準備完了メッセージ：docker：ネットワークプラグインの準備ができていません：cni config初期化されていません

すべてのノードのステータス：
[ root @ swarm net.d] ＃kubectl get node
名前ステータス年齢バージョン
contiv1.com Ready 1h v1.6.4
contiv2.com Ready 1h v1.6.4
swarm.com Ready 1h v1.6.4

frankruizhi 2017年06月06日

これに関する解決策はありますか？上記のすべての解決策を試した後でも、これを行うことができませんでした。

vaibhavjain882 2017年06月08日

Kubernetesの設定に慣れていないので、非常に混乱します。ネットワークにweave-kubeを使用するhttps://medium.com/@SystemMining/setup-kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929をフォローしようとしましたが、同じ問題が発生します。これを解決する方法はありますか？
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

tirithen 2017年06月12日

なぜこれがまだ問題なのですか？ Ubuntu 16.04 / CentOS 7.3、1.6.4の公式k8sリポジトリを使用し、ここに概説されている手順に従います： https ：//kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

datamattsson 2017年06月13日

@drajenいいえ、これは_v1.6.0_のみに影響します。ネットワークをインストールしていないため、kubeletがネットワークを見つけられないことが予想されます。たとえば、実行するだけです

kubectl apply -f https://git.io/weave-kube-1.6

Weave Netをインストールすると、これらの問題は解消されます。必要に応じて、Flannel、Calico、Canal、またはその他のCNIネットワークをインストールすることを選択できます。

luxas 2017年06月13日

👍2

@luxas私はこれへの参照を見続けていますが、実行されていないクラスターに何かを適用するにはどうすればよいですか？接続するものがありません。

datamattsson 2017年06月13日

@drajen @luxasのポイントは、これがセットアップについて尋ねるのに間違った場所だということだと思います。
さまざまなセットアップガイドがこの点を乗り越えます。これは、すべてが正常に機能し始める前にネットワーク構成を適用する必要があるという点で、luxasが役立つように言及している古いガイドの典型的な欠落しているステップです。

zatricky 2017年06月13日

ええ、それは自明ではないかもしれません、そしてそれについては申し訳ありませんが、私たちはそこに単一のプロバイダー名を持つこともできません。

Slackで@drajenとチャットしましたが、問題はcgroupに関連しており、kubeletは異常であり、ポッドを作成できなかったため、問題が発生しました。

luxas 2017年06月13日

👍1

私の特定の問題に取り組んでくれたます： //github.com/kubernetes/kubeadm/issues/302

datamattsson 2017年06月14日

👍1

まだ1.7のアーチでこれを打っていますが、どこかに簡単な修正はありますか？

編集：

kubectl apply -f https://git.io/weave-kube-1.6

トリックを実行しました。CNIを実行する必要があるようです。

kris-nova 2017年07月03日

少なくともCentOS / RHELの場合は、必ず/etc/systemd/system/kubelet.service.d/10-kubeadm.confを更新し、フラグ--cgroup-driver = "systemd"を追加してください。

同じマシンに再度再インストールする場合、これは完全に適切なリセットです。
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
（これは、特にフランネルドを使用する場合に必要です）
すべてを1つで実行したい場合は、プロジェクト全体を使用することをお勧めします： https ：

ReSearchITEng 2017年07月03日

私はこの問題にぶつかりましたが、上で読んだものはまったく機能しませんでした。そこで、Ubuntuから最新のCoreOSに切り替え、最初に以前のバージョンのk8sに移行し、一般に、各VMに最後にインストールされるすべてのものについて非常に肛門的である、はるかに制御されたセットアップで再試行しました。私はkubeadmを使用していませんが、代わりにvagrantとansibleの組み合わせを使用しています。

（なぜですか？kubeadmで何が起こっているのかわからず、このように考えたので、少なくとも私は制御でき、熱心な飛行前チェックをバイパスできるようになりました。もちろん、一般的に自動化制御が強化されたように感じました。 do-not-apply-alpha-software-in-productionへの警告について心配する必要はありません。）

古い（1.4.3）エディションのk8sでこのセットアップを試したとき、このアプローチは非常に効果的でした。次に、1.71にアップグレードしてみました。繰り返しになりますが、kubeadmをまったく使用していないにもかかわらず、私はまだこの同じ問題にぶつかっています。

マスターと3人の潜在的なワーカーを含む各ノードでcalicoを実行していることを確認しました。すべてのノードがNotReadyとしてレポートしているので、weave（または他の何か）を適用して実行する方法がよくわかりません。

この全体は、チキン/エッグのように見えます...ネットワークが失敗しているため、ポッドを割り当てることはできませんが、ポッドを割り当てるには、/ etc / cni /net.dにネットワークを作成するためにネットワークを実行する必要があります。繰り返しになりますが、これはすべて、数時間前にk8s1.4.3で機能していました。とても欲求不満です！

私は誰もが与えることができる洞察をいただければ幸いです。

脚注：

マスターの場合：journalctl -r -ukubeletは私に

Jul 24 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]：E0724 00：48：16.592274 7647 kubelet.go：2136]コンテナランタイムネットワークの準備ができていません：NetworkReady = false理由：NetworkPluginNotReady メッセージ：docker ：ネットワークプラグインはありません
Jul 24 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]：W0724 00：48：16.590588 7647 cni.go：189] cni構成を更新できません：/ etc / cni / netにネットワークが見つかりません。NS

docker ps | grep calico

（読みやすさのために切り捨てられています）
cde ... quay.io/calico/ Leader -elector @ sha256 ：... "/run.sh --election = c" 8時間前8時間アップ
f72 ... calico / kube -policy-controller @ sha256 ：... "/ dist / controller" 8時間前8時間アップ
c47 ... gcr.io/google_containers/pause-amd64:3.0 "/ pause" 8時間前8時間アップ

/etc/cni/net.dはありません

私のkubectlボックスから：
kubectlgetノード
10.0.0.111 NotReady、SchedulingDisabled 8h v1.7.1 + coreos.0
10.0.0.121 NotReady 8h v1.7.1 + coreos.0
10.0.0.122 NotReady 8h v1.7.1 + coreos.0
10.0.0.123 NotReady 8h v1.7.1 + coreos.0

kubectl apply -f https://git.io/weave-kube-1.6

何も修正しませんでした。実際、問題が増えるだけのようです。

bill @ rogue ：〜/ vagrant_rogue / rogue-cluster $ kubectl apply -f https://git.io/weave-kube-1.6
serviceaccount「weave-net」が作成されました
clusterrolebinding「weave-net」が作成されました
デーモンセット「weave-net」が作成されました
サーバーからのエラー（禁止）：clusterroles.rbac.authorization.k8s.io "weave-net"は禁止されています：追加の特権を付与しようとしています：[PolicyRule {Resources：["pods"]、APIGroups：[""]、動詞： ["get"]} PolicyRule {Resources：["pods"]、APIGroups：[""]、動詞：["list"]} PolicyRule {Resources：["pods"]、APIGroups：[""]、動詞： ["watch"]} PolicyRule {Resources：["namespaces"]、APIGroups：[""]、動詞：["get"]} PolicyRule {Resources：["namespaces"]、APIGroups：[""]、動詞： ["list"]} PolicyRule {Resources：["namespaces"]、APIGroups：[""]、動詞：["watch"]} PolicyRule {Resources：["nodes"]、APIGroups：[""]、動詞： ["get"]} PolicyRule {Resources：["nodes"]、APIGroups：[""]、動詞：["list"]} PolicyRule {Resources：["nodes"]、APIGroups：[""]、動詞： ["watch"]} PolicyRule {Resources：["networkpolicies"]、APIGroups：["extensions"]、動詞：["get"]} PolicyRule {Resources：["networkpolicies"]、APIGroups：["extensions"]、動詞：["list"]} PolicyRule {Resources：["networkpolicies"]、APIGroups：["extensions"]、動詞：["watch"]}] user =＆{kube-admin [system：a uthenticated] map []} ownerrules = [] ruleResolutionErrors = []

bill @ rogue ：〜/ vagrant_rogue / rogue-cluster $ kubectl get pods --namespace = kube-system
NAME READY STATUS RESTARTS AGE
kube-apiserver-10.0.0.1111 / 1実行中18時間
kube-controller-manager-10.0.0.1111 / 1実行中18時間
kube-dns-v20-fcl010 / 3保留中08h
kube-proxy-10.0.0.1111 / 1実行中18時間
kube-proxy-10.0.0.1211 / 1実行中18時間
kube-proxy-10.0.0.1221 / 1実行中18時間
kube-proxy-10.0.0.1231 / 1実行中18時間
kube-scheduler-10.0.0.1111 / 1ランニング18時間
kubernetes-dashboard-v1.4.1-29zzk0 / 1保留中08h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v2 / 2ランニング03m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

ウィーブエラーの詳細な調査は、（a）apiserverに接続できないか、（b）「実行中」とマークされたエラーの場合はそれ自体に接続できないことを訴えていることを示しています。

billmilligan 2017年07月24日

@billmilligan同様の問題があり、DNSはコンテナの開始後数分で動作を停止します

Paxa 2017年07月24日

@Paxa @billmilligan助けが必要な場合は、この問題についてコメントしないでください。代わりに、十分な詳細が要求された状態で、kubeadmリポジトリで新しいものを開きます。

luxas 2017年07月24日

@luxas敬具、これが新しい問題かどうか疑問に思う必要があります。 kubeadmを使用せずにk8sをセットアップすると、他のすべての人がkubeadmを使用した場合とまったく同じ結果が得られるため、問題の原因としてのkubeadmが排除されているようです。おそらく、この問題はそれに応じて名前を変更する必要がありますか？

billmilligan 2017年07月24日

@billmilligan敬意を表して、問題はkubeadmに関するものであり、kubeadmなしで複製できるので、ファイルするのは間違った場所ですか？このスレッドはkubeadmの問題を解決したと思います。これは新しい問題です。新しい問題としてもっと注目されると思います。このスレッドの人々はそれがすでに解決されたと思い、それを無視しているように。

私はkubeadmを使用していますが、この問題の影響を受けており、1.6.1から解決されています。それ以来、失われたk8をデプロイしてきたので、別の問題があると思います。

kfox1111 2017年07月24日

@ kfox1111フィードバックをありがとう。私は新しい問題を提出しますが、1.7.xの他の場所でまだそれに直面しているように見える人々の数はまだ私に不思議に思います。

billmilligan 2017年07月24日

TL; DR;

エラーメッセージ

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

必ずしも悪いわけではありません。

このエラーメッセージは、サードパーティのCNI仕様実装プロバイダーにプラグインする必要があることを示してい

CNIとは何ですか？Kubernetesとどのように統合しますか？

CNIはContainerNetwork Interfaceの略で、kubeletがクラスターのネットワークを作成するために使用する仕様をこのページを参照し

Kubernetesは、CNI仕様を満たしている限り、ネットワークがどのように作成されるかを気にしません。

kubeletは、新しいポッドをネットワークに
kubelet 、CNIネットワークが使用する構成ディレクトリ（多くの場合/etc/cni/net.d ）を読み取ります。
新しいポッドが作成されると、kubeletは構成ディレクトリ内のファイルを読み取り、構成ファイルで指定されたCNIバイナリにexec送信します（バイナリは多くの場合/opt/cni/bin ）。実行されるバイナリは、サードパーティ（Weave、Flannel、Calicoなど）に属し、サードパーティによってインストールされます。

kubeadmは、Kubernetesクラスターを起動するためのkubeadm initが実行された後、そのようなCNIバイナリも構成もありません。これは、 kubeadm initが、完全に機能するクラスターを稼働させるのに十分ではないことを意味します。

これは、 kubeadm init後に、kubeletログに次のように表示されることを意味します

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

これは非常に期待されています。そうでない場合は、特定のネットワークプロバイダーを優先します。

では、どうすればこのエラーを「修正」できますか？
kubeadm入門ガイドの次のステップは、「ポッドネットワークのインストール」です。
つまり、 kubectl applyは、優先するCNIネットワークプロバイダーからのマニフェストです。

DaemonSetは、必要なCNIバイナリを/opt/cni/binコピーし、必要な構成を/etc/cni/net.d/コピーします。また、ノード間のネットワークをセットアップする実際のデーモンを実行します（たとえば、iptablesルールを記述します）。

CNIプロバイダーがインストールされると、kubeletは「ネットワークのセットアップ方法に関する情報があります」と通知し、サードパーティの構成とバイナリを使用します。

また、ネットワークがサードパーティプロバイダーによって（kubeletが呼び出すことによって）セットアップされると、ノードはそれ自体にReadyマークを付けます。

この問題はkubeadmとどのように関連していますか？

v1.6サイクルの後半に、kubeletがReady/NotReadyステータスを報告する方法を変更するPRがマージされました。以前のリリースでkubelet 、CNIネットワークが設定されているかどうかに関係なく、 Readyステータスを報告していました。これは実際には一種の間違いであり、CNIネットワークのステータスを尊重するように変更されました。つまり、CNIが初期化されていない場合はNotReady 、初期化されている場合はReadyです。

v1.6.0のkubeadmは、マスターノードがReady状態になるのを誤って待機しkubeadm initタスクを続行しました。 CNIが初期化されていないときにkubeletの動作がNotReadyを報告するように変更された場合、kubeadmはノードがReadyを取得するのを永久に待ちます。

KUBEADM側の誤解を待つことは、この問題が何であるかです

ただし、v1.6.1でリグレッションをすばやく修正し、v1.6.0の数日後にリリースしました。

これについての詳細と、v1.6.0がこの欠陥でリリースされる可能性がある理由については、回顧展をお読みください。

では、kubeadm v1.6.1 +でこの問題が発生したと思われる場合は、どうしますか？

まあ、私は本当にあなたがそうしないと思います。この問題は、 kubeadm initがデッドロックしているときに発生します。
v1.6.1以降では、ユーザーやメンテナはこれを見たことがありません。

あなたがされているが表示されます

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

v1.6以降のすべてのバージョンでkubeadm initごとに、ただしそれは悪いことではあり

とにかく、kubeadmで予期しない何かを見つけたら、新しい問題を開いてください

この問題についてこれ以上コメントしないでください。代わりに新しいものを開いてください。

@billmilliganつまり、クラスターを稼働させるには、CNIプロバイダーのマニフェストをkubectl applyするだけでよいと思います。

私は上で述べたことをかなり要約していますが、うまくいけば、より明確で詳細な方法で。
CNIの仕組みについて質問がある場合は、StackOverflow、問題、Slackなどの通常のサポートチャネルを参照してください。

（最後に、太字のテキストが多すぎて申し訳ありませんが、人々の注意を引くために必要だと感じました。）

luxas 2017年07月24日

👍2

Kubernetes: 構成されていないCNIがkubeletNotReadyを作成しているため、kubeadm 1.6.0（1.6.0のみ!!）が壊れています

@mikedaneseによる編集：パッチを適用したdebian amd64 kubeadmhttps ： //github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036を修正してテストしてください

最も参考になるコメント

全てのコメント211件

以下からENVエントリを削除します。

systemdおよびkubeサービスをリロードします

initを再実行します

KUBELET_NETWORK_ARGSを削除し、それが機能することを報告している方へ：

パッチを当てたデブをテストしてください

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemctl enable docker && systemctl start docker

systemctl enable kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables = 1

systemctl stop Firewalld; systemctl disablefirewalld

kubeadm init

cp /etc/kubernetes/admin.conf $ HOME /

chown $（id -u）：$（id -g）$ HOME / admin.conf

KUBECONFIG = $ HOME /admin.confをエクスポートします

kubectl apply -f https://git.io/weave-kube

kubectlgetノード

kubectldescribeノードabc02918

systemctl status kubelet.service -l

TL; DR;

CNIとは何ですか？Kubernetesとどのように統合しますか？

この問題はkubeadmとどのように関連していますか？

では、kubeadm v1.6.1 +でこの問題が発生したと思われる場合は、どうしますか？

とにかく、kubeadmで予期しない何かを見つけたら、新しい問題を開いてください

この問題についてこれ以上コメントしないでください。代わりに新しいものを開いてください。

関連する問題

Kubernetes: 構成されていないCNIがkubeletNotReadyを作成しているため、kubeadm 1.6.0（1.6.0のみ!!）が壊れています

@mikedaneseによる編集：パッチを適用したdebian amd64 kubeadmhttps ： //github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036を修正してテストしてください

最も参考になるコメント

全てのコメント211件

以下からENVエントリを削除します。

systemdおよびkubeサービスをリロードします

initを再実行します

KUBELET_NETWORK_ARGSを削除し、それが機能することを報告している方へ：

パッチを当てたデブをテストしてください

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemctl enable docker && systemctl start docker

systemctl enable kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables = 1

systemctl stop Firewalld; systemctl disablefirewalld

kubeadm init

cp /etc/kubernetes/admin.conf $ HOME /

chown $（id -u）：$（id -g）$ HOME / admin.conf

KUBECONFIG = $ HOME /admin.confをエクスポートします

kubectl apply -f https://git.io/weave-kube

kubectlgetノード

kubectldescribeノードabc02918

systemctl status kubelet.service -l

TL; DR;

CNIとは何ですか？Kubernetesとどのように統合しますか？

この問題はkubeadmとどのように関連していますか？

では、kubeadm v1.6.1 +でこの問題が発生したと思われる場合は、どうしますか？

とにかく、kubeadmで予期しない何かを見つけたら、新しい問題を開いてください

この問題についてこれ以上コメントしないでください。 代わりに新しいものを開いてください。

関連する問題

この問題についてこれ以上コメントしないでください。代わりに新しいものを開いてください。