Kubernetes: kubeadm 1.6.0（仅 1.6.0！！）由于未配置的 CNI 导致 kubelet NotReady 损坏

创建于 2017-03-29  ·  211评论  ·  资料来源: kubernetes/kubernetes

https://github.com/kubernetes/kubeadm/issues/212 中的初步报告

我怀疑这是在https://github.com/kubernetes/kubernetes/pull/43474中引入的

发生了什么（全部在单主上）：

  1. kubeadm 启动配置一个 kubelet 并使用静态 Pod 配置一个控制平面
  2. kubeadm 创建节点对象并等待 kubelet 加入并准备就绪
  3. kubelet 永远不会准备好，所以 kubeadm 永远等待

在节点的条件列表中：

  Ready         False   Wed, 29 Mar 2017 15:54:04 +0000     Wed, 29 Mar 2017 15:32:33 +0000     KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

以前的行为是让 kubelet 加入集群，即使没有配置 CNI。 然后，用户通常会运行带有主机网络的 DaemonSet，以在所有节点上引导 CNI。 节点从不加入的事实意味着，从根本上说，DaemonSets 不能用于引导 CNI。

由@mikedanese编辑：请测试打补丁的 debian amd64 kubeadm https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036 并修​​复

prioritcritical-urgent sinetwork
资料来源
picture jbeda
👍5

最有用的评论

我正在尝试在 Ubuntu 16.04 上使用 kubeadm 安装 kubernetes。 有没有快速解决方法？

picture luhkevin 于 2017-03-29
👍25 😕2 👎1

所有211条评论

/ cc @lukemarsden @luxas @mikedanese

jbeda picture 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 picture jbeda 于 2017-03-29

/ cc @ kubernetes / sig-network-bugs

jbeda picture jbeda 于 2017-03-29

参考： https :

yujuhong picture yujuhong 于 2017-03-29

@jbeda我可以使用 --loglevel=5 获取一些 kubelet 日志吗？

dcbw picture dcbw 于 2017-03-29

@yujuhong - 你提到你认为这是按预期工作的。 无论如何，kubeadm 依赖于这种行为。 我们引入了 #43474 的重大更改。 我们可以讨论在 1.7 中修复这个问题的正确方法，但现在，我们需要让 kubeadm 再次工作。

jbeda picture jbeda 于 2017-03-29

现在正在进行 Slack 讨论 -- https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

jbeda picture jbeda 于 2017-03-29

即使节点没有准备好，看起来 DaemonSets 仍然会被调度。 在这种情况下，这真的是kubeadm有点太偏执了。

我们将要测试的当前计划是让kubeadm不再等待主节点准备好，而是让它注册。 这应该足以让 CNI DaemonSet 被安排来设置 CNI。

@kensimon正在对此进行测试。

jbeda picture jbeda 于 2017-03-29
👍1

@jbeda是的，看起来 DaemonSet 控制器仍然会将它们排入队列，主要是因为它完全不了解网络。 我们真的应该更普遍地解决这个问题。 在 kube 中有什么可以立即执行的操作，还是现在都在 kubeadm 中？

dcbw picture dcbw 于 2017-03-29

我正在尝试在 Ubuntu 16.04 上使用 kubeadm 安装 kubernetes。 有没有快速解决方法？

luhkevin picture luhkevin 于 2017-03-29
👍25 😕2 👎1

@jbeda如果你有一个补丁版本很乐意测试它..

stevenbower picture stevenbower 于 2017-03-29
👍4

我让 kubeadm 超过了节点的NotReady状态，但是由于node.alpha.kubernetes.io/notReady污点阻止它运行，它创建的虚拟部署不起作用。 添加容忍似乎没有帮助，我不完全确定此时如何进行。 有人能解释一下如何部署一个可以容忍notReady污点的 pod 吗？

我正在探索其他一些选项，例如不将节点标记为 notReady，但目前尚不清楚这就是我们想要做的。

kensimon picture kensimon 于 2017-03-29

我们通过从 kubelet 命令行中删除 KUBELET_NETWORK_ARGS 来解决这个问题。 之后 kubeadm init 工作正常，我们能够安装 canal cni 插件。

sbezverk picture sbezverk 于 2017-03-29
👍4

@sbezverk你能描述一下怎么做吗？

overip picture overip 于 2017-03-29

可以确认@sbezverk (good find :) ) 的发现，调整 /etc/systemd/system/10-kubeadm.conf 并删除 KUBELET_NETWORK_ARGS 将使其在 centos 上运行。 用编织测试。

coeki picture 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

然后在 bebeadm init 应该可以工作后重新启动 kubelet。

sbezverk picture sbezverk 于 2017-03-29
👍10 ❤1

这就是我所做的

kubeadm 重置

从以下位置删除 ENV 条目：

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

重新加载 systemd 和 kube 服务

systemctl 守护进程重新加载
systemctl 重启 kubelet.service

重新运行初始化

kubeadm 初始化

jp557198 picture jp557198 于 2017-03-29
👍15 👎8

一切都正确，而我们在此期间

如果你看到这个：
kubelet：错误：无法运行 Kubelet：无法创建 kubelet：错误配置：kubelet cgroup 驱动程序：“cgroupfs”与 docker cgroup 驱动程序不同：“systemd”

您必须编辑您的 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 并添加标志 --cgroup-driver="systemd"

并按上述方式做

kuebadm 重置
systemctl 守护进程重新加载
systemctl 重启 kubelet.service
kubeadm 初始化。

coeki picture coeki 于 2017-03-29
👎2 👍1

我会小心地从 kubelet CLI 标志中删除--network-plugin=cni ，这会导致 kubelet 默认使用 no_op 插件......如果像 calico/weave 这样的常见插件在这种情况下甚至可以工作，我会感到惊讶（但是然后我对这些插件如何在下面运行的理解有点有限。）

kensimon picture kensimon 于 2017-03-29

@kensimon嗯，在我的设置中没有看到任何问题，我部署了 canal cni 插件并且它运行良好..

sbezverk picture sbezverk 于 2017-03-29

@sbezverk跨主机网络也能正常工作吗？

resouer picture resouer 于 2017-03-29

@resouer无法确认，我只有 1.6.0 作为一体机。

sbezverk picture 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
名称就绪状态重新开始年龄
etcd-deploy-01 1/1 运行 0 50m
kube-apiserver-deploy-01 1/1 运行 0 51m
kube-controller-manager-deploy-01 1/1 运行 0 50m
kube-dns-3913472980-6plgh 3/3 运行 0 51m
kube-proxy-mbvdh 1/1 运行 0 4m
kube-proxy-rmp36 1/1 运行 0 51m
kube-scheduler-deploy-01 1/1 运行 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 运行 0 24m
weave-net-3t487 2/2 运行 0 44m
weave-net-hhcqp 2/2 运行 0 4m

``

coeki picture coeki 于 2017-03-30

解决方法有效，但无法让法兰绒继续运行......

stevenbower picture stevenbower 于 2017-03-30

@stevenbower 在最坏的情况下，您可以在完成 kubeadm 业务后恢复此设置并重新启动 kubelet。

sbezverk picture sbezverk 于 2017-03-30

我有一个weave工作的三节点集群。 不知道这个 hack 可能有多稳定，但还是谢谢！ ：笑脸：

webwurst picture webwurst 于 2017-03-30

在侧节点上，您可以在主节点上的初始化通过后放回 $KUBELET_NETWORK_ARGS。 我在加入的机器上其实没有去掉，只去掉了cgroup-driver，否则kubelet和docker不能协同工作。

但是你不必重置 kubeadm，只需更改 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 并执行 systemctl dance：

systemctl 守护进程重新加载
systemctl 重启 kubelet.service

coeki picture coeki 于 2017-03-30
👍4

对于那些放弃 KUBELET_NETWORK_ARGS 并报告它对你有用的人：

对我来说，我有 2 个集群：一个是我从https://github.com/kubernetes/kubernetes/pull/43824应用补丁并让 kubeadm 在初始化时正常进行，另一个是删除了 KUBELET_NETWORK_ARGS。 在删除了 KUBELET_NETWORK_ARGS 的集群上，Pod 之间的任何流量都会失败。

在删除了 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 picture kensimon 于 2017-03-30

我建议我们同时删除节点就绪和虚拟部署检查
总共 1.6 并将它们移到 1.7 的验证阶段。

2017 年 3 月 29 日上午 10:13，“丹·威廉姆斯”通知@github.com写道：

@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 picture mikedanese 于 2017-03-30
👍3

还有其他人在运行 Ubuntu 16.04 吗？ 我已经从systemd服务中删除了KUBELET_NETWORK_ARGS并重新加载了systemd守护进程。 我可以打开一个主节点，但不能加入一个节点。 它失败并出现错误The requested resource is unavailable

LaurentDumont picture LaurentDumont 于 2017-03-30

删除了 KUBELET_NETWORK_ARGS，Pod 之间的任何流量都会失败。

我不会感到惊讶，因为 KUBELET_NETWORK_ARGS 告诉 kubelet 使用什么插件，在哪里查找配置和二进制文件。 你需要它们。

yujuhong picture yujuhong 于 2017-03-30

我推荐 #43835（和 1.6 樱桃选择 #43837）作为我们为 1.6 所做的修复。 我测试了两者，它们都有效。 我已经指派@jbeda和@luxas在他们醒来时进行审查。

mikedanese picture mikedanese 于 2017-03-30

这两个 PR 看起来都很合理。 但我认为我们应该考虑使用https://github.com/kubernetes/kubernetes/pull/43824代替。 虽然它有点复杂，但它确实保留了该代码路径，以便在使用 Daemonset 之外预配置 CNI 的用户（我在 https://github.com/jbeda/kubeadm-gce-tf 中这样做，尽管我还没有将其更新为 1.6）仍然等待节点准备就绪。

作为奖励，这是@kensimon对

jbeda picture jbeda 于 2017-03-30

抱歉，我错过了https://github.com/kubernetes/kubernetes/pull/43824。 如果他们都工作，我也很高兴。

mikedanese picture mikedanese 于 2017-03-30

如果他们都工作，我也很高兴

WIZARD-CXY picture WIZARD-CXY 于 2017-03-30

@kensimon它对我kubadm init期间禁用KUBELET_NETWORK_ARGS时。 感谢您的指示，我可以验证这一点。

webwurst picture webwurst 于 2017-03-30

当您仅在kubadm init期间禁用KUBELET_NETWORK_ARGS时，确认@webwurst可以正常工作。 我不得不重新启动 kube-dns 以使其恢复。 来自@kensimon的检查有效，dns 解析。

虽然我同意这是一个可怕的黑客，对于大多数人来说太可怕了，看看松弛的频道。

来自@kensimon或@mikedanese 的补丁提供了更好的解决方案。

coeki picture coeki 于 2017-03-30

@coeki你是如何重新启动 kube-dns 的。 我尝试了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 picture 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安装一个 pod 网络，例如 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

加入一台机器，通常要添加一条静态路由到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 picture coeki 于 2017-03-30

我真的很惊讶 kubernetes 开发社区没有为官方修复提供任何 ETA。 我的意思是这是一个可怕的错误，在代码测试期间应该很容易被发现。 既然它没有，至少，1.6.1 应该尽快通过修复推送，这样人们就可以停止黑客攻击他们的集群并开始做富有成效的事情;)。 我在这里错了吗？

sbezverk picture sbezverk 于 2017-03-30
👍14

大家好，

这周我有点心烦意乱，这是一个很长的线程
kubeadm 的东西我不太了解。 有人可以为我总结一下吗？ 一世
我想我明白了错误的要点，但是建议的解决方案是什么？
是什么让它们变得可怕？

2017 年 3 月 30 日星期四上午 8:13，Serguei Bezverkhi < [email protected]

写道：

我真的很惊讶 kubernetes 开发社区没有
提供了官方修复的任何预计到达时间。 我的意思是这是一个可怕的错误
在代码测试期间应该很容易被捕获。 既然还没有，在
至少，1.6.1 应该尽快通过修复推送，这样人们就会
停止黑客攻击他们的集群并开始做富有成效的事情;)。 我是吗
错在这里？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

thockin picture thockin 于 2017-03-30

kubelet 中的更改 (#43474) 导致 kubelet 在 cni 插件初始化之前启动正确报告网络未就绪。 这打破了我们所依赖的一些顺序，并导致 kubeadm 主初始化中的死锁。 我们没有发现它，因为 kubeadm e2e 测试在此更改之前已经中断了几天。

当前提议的修复是#43824 和#43835。

mikedanese picture mikedanese 于 2017-03-30

好吧，我是这么理解的。 网络插件之间的互锁
即将到来，节点准备情况现在有点糟糕。

2017 年 3 月 30 日星期四上午 8:28，Mike Danese通知@github.com
写道：

kubelet 的变化 (#43474
https://github.com/kubernetes/kubernetes/pull/43474 ) 导致 kubelet
开始正确报告网络未准备好之前 cni 插件
初始化。 这打破了我们依赖并导致的一些顺序
kubeadm master 初始化中的死锁。 我们没有抓住它，因为
在此更改之前，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 picture thockin 于 2017-03-30

我还是更喜欢#43835。 这是一个更简单的更改，我认为不应在它们所在的位置进行 e2e 检查，并且有报告称 #43824 仍然无法正常工作。 我今天要推动解决这个问题。

mikedanese picture mikedanese 于 2017-03-30

+1 今天解决它，因为在处理来自变通方法的抵押品上浪费了很多努力。

sbezverk picture sbezverk 于 2017-03-30
❤7

我不敢相信在 1.6.0 发布之前没有人真正尝试过 kubeadm 1.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 是 k8s apt 存储库中唯一剩下的版本...

Dieken picture Dieken 于 2017-03-30
👍1

“开箱即用”，今天学到的话。

Dieken picture Dieken 于 2017-03-30
😄20 👍2

我还是更喜欢#43835。 这是一个更简单的更改，我认为不应在它们所在的位置进行 e2e 检查，并且有报告称 #43824 仍然无法正常工作。 我今天要推动解决这个问题。

同意迈克的这一点。 #43835 是更简单的更改，验证（如果需要）可以在单独的阶段完成。

yujuhong picture yujuhong 于 2017-03-30

@thockin我们真的需要更细粒度的网络条件和状态，尤其是使用stNetwork:true 时。 节点可以为某些 pod 做好准备，但不能为其他 pod 做好准备。

我们不能使用 nodeNetworkUnavailable，因为它特定于云提供商。 我们可能需要另一种方法，或者调度程序允许在具有 Net workReady:false 的节点上使用hostNetwork:true pod 的方法，或者使污点对未就绪节点起作用。 和工作 kubeadm e2e 测试:(

dcbw picture dcbw 于 2017-03-30

同意。 我一直在拖延问题，因为我没有很好的答案，
但我们需要在 1.7 中得到这个

2017 年 3 月 30 日星期四上午 10:02，Dan Williams通知@github.com
写道：

@thockin https://github.com/thockin我们真的需要更细粒度的
网络的条件和状态，尤其是使用hostNetwork:true 时。
节点可以为某些 pod 做好准备，但不能为其他 pod 做好准备。

我们不能使用 nodeNetworkUnavailable，因为它特定于云
提供者。 我们可能需要另一个，或者调度程序的一种方式
使用 Net workReady:false允许节点上的hostNetwork:true pod，或者使
污点适用于未就绪节点。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

thockin picture thockin 于 2017-03-30

@thockin任何首选的解决方案？ 我们可以阻止节点准备就绪并找出谁使用 IsNodeReady() 就像我们已经完成的那样，或者我们可以添加另一个节点条件，然后在其他地方修复代码库的谁知道多少位。 或者也许还有另一种选择。

dcbw picture dcbw 于 2017-03-30

我们不能使用 nodeNetworkUnavailable，因为它特定于云提供商。 我们可能需要另一种方法，或者调度程序允许在具有 Net workReady:false 的节点上使用hostNetwork:true pod 的方法，或者使污点对未就绪节点起作用。

我认为可以修复调度程序以尊重污点和容忍度，而不是完全排除所有未就绪的节点。
不过，必须有人在hostNetwork:true pod 上应用容忍度。 我不知道是谁，但它不应该是调度程序，因为教调度程序理解 pod 规范似乎太多了。

/cc @davidopp @dchen1107

yujuhong picture yujuhong 于 2017-03-30

此外，对于任何尝试过我或迈克尔的补丁并在即将到来的控制平面上挂断的人来说，似乎从master构建 kubeadm 在管理 v1.6.0 集群时不起作用，由于 kubeadm 尝试使用无效参数启动 kube-apiserver：

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

如果您想针对 v1.6.0 集群测试我的或 michael 的更改，请针对 v1.6.0 挑选它们，而不是暂时构建在 master 之上。

kensimon picture kensimon 于 2017-03-30

@yujuhong调度程序已经自动对 pod 应用了容忍度（参见 https://github.com/kubernetes/kubernetes/pull/41414），这似乎是一个足够相似的用例

kensimon picture kensimon 于 2017-03-30

我没有清楚地了解所有的污点和准备情况
网络，此时。 丹，你有半小时的时间写下
当前状态，所以我们可以开始梳理它？ 我想你知道
最好的事物。 我确实觉得我们有一些我们刚刚遇到的细粒度问题
毯子覆盖到目前为止。

2017 年 3 月 30 日星期四上午 10:22，Ken Simon通知@github.com
写道：

@yujuhong https://github.com/yujuhong调度器已经
自动对 pod 应用容忍度（参见 #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 picture thockin 于 2017-03-30

@thockin我可以做到，我应该把它放在哪里？

dcbw picture dcbw 于 2017-03-30

有几个相关的问题，我们可以重新命名其中一个，发布一个
总结当前状态并从那里开始？

2017 年 3 月 30 日星期四上午 10:50，Dan Williams通知@github.com
写道：

@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 picture thockin 于 2017-03-30

我们是否有关于何时将此修复程序移植到 CentOS 存储库的时间线？

junsaw picture junsaw 于 2017-03-30
👍8

默认情况下，在 1.6 中，核心 Kubernetes 不会自动将任何污点应用到节点。 调度程序确实尊重由 kubeadm、kops 等部署系统添加或由用户手动添加的污点（并尊重添加到 pod 的相应容忍度）。

在 1.6 中，默认情况下，如果节点报告某些节点情况（包括网络不可用），Kubernetes 调度程序会将节点排除在考虑范围之外。 代码在这里。 它与污点无关——它只是查看节点条件。

在 1.6 中，您可以启用 alpha 功能，该功能会导致核心 Kubernetes（NodeController）在 NodeReady == "False" 或 NodeReady == "Unknown" 时添加 NoExecute 污点。 这将导致节点上运行的 Pod 被驱逐（如果它们不能容忍污点）并阻止新的 Pod 调度到节点上（如果它们不能容忍污点）。

长期计划是将所有“核心 Kubernetes 如何对节点条件做出反应，关于调度和驱逐”逻辑使用污点和容忍（例如#42001）。 但我们还没有到那里，也不会有一段时间。 因此，就近期而言，Pod 无法“容忍” NetworkUnavailable 或您可能决定添加的任何其他节点条件。

davidopp picture davidopp 于 2017-03-30

如果我理解@davidopp所说的正确，那么该函数就是 NodeReady，它现在返回 true 或 false 或未知，并在列表中打勾，列出需要的内容。 如果它可以返回不满足的值列表，您可以对此进行测试。

在 kubeadm 的情况下，如果 NetworkUnavailable，则是唯一的。 kubeadm 可以返回 true。 在这种情况下，我们不希望在 kubeadm 初始化时传入 network/cni 插件。

因为如果我理解得很好，污点和容忍度是基于这个函数设置的，至少对于 kubeadm。

如果我错了纠正我 ;）

coeki picture coeki 于 2017-03-30

跳到这个线程是因为我遇到了这个问题并且很烦人：

为什么网络就绪不能成为 kubelet 根据节点上的网络状态添加和删除的污点？
这样，节点可以为所有容忍网络就绪污染的 Pod（Pod 网络应用程序）“准备好”。

对于主机网络 pod，准入控制器可以向 pod 网络就绪污染注入容忍度。

vishh picture vishh 于 2017-03-31

我认为这与 davidopp 评论中的长期计划一致。

mikedanese picture mikedanese 于 2017-03-31

我认为这与 davidopp 评论中的长期计划一致。

对，就是这样。 长期计划是对每个节点条件进行污染，并停止让 Kubernetes 内部的任何内容关注节点条件。 我们从我提到的 1.6 alpha 功能开始这项工作。

davidopp picture davidopp 于 2017-03-31

确认。 是否有理由不在 v1.6 补丁版本中切换到 taints？

vishh picture vishh 于 2017-03-31

根据节点条件自动添加污点的代码刚刚在 1.6 中进入 alpha 阶段。 它还没有准备好被依赖。 （而且它目前只处理节点就绪状态，不处理网络）。

davidopp picture davidopp 于 2017-03-31

所以，如果我理解正确的话，现在，由于https://github.com/kubernetes/features/issues/166需要更长的时间才能正确地污染网络可用性，我们必须进行解决。 如果我们可以尽快为 kubeadm 推送修复程序，例如 #43835，并通过https://github.com/kubernetes/features/issues/166发表评论来修复此问题，那么很多人都会很高兴。

coeki picture coeki 于 2017-03-31
👍1

@davidopp我想你的意思是“不依赖”。 我仍然缺少自动条件与您提到的 kubelet 直接针对网络问题发布污点的污点逻辑之间的关系。

vishh picture vishh 于 2017-03-31

是的，谢谢，这是一个错字，现在修正

是的，您可以让 Kubelet 添加污点。 让 Kubelet 为某些节点条件添加污点并让 NodeController 为其他节点条件添加污点可能并不理想（后者是必要的，因为只有主节点才能检测到节点不可达），但这只是一个软件工程论点，而不是任何基本的东西。 我的计划是让 NodeController 为所有节点条件添加污点，但没有强烈要求这样做。

davidopp picture davidopp 于 2017-03-31

确认。 在这种情况下，单个节点条件具有与其关联的多个属性，节点控制器可能无法识别这些属性。
@mikedanese我觉得kubeadm init导致运行节点的现有行为很有吸引力。 我希望添加validation阶段的要求不是主要基于此问题。
@dcbw @thockin @yujuhong关于在 kubelet 中使用污点来表示节点配置问题有什么想法吗？

vishh picture vishh 于 2017-03-31

请注意，如果您希望您的新污点将当前自动过滤掉的节点替换为 NetworkUnavailable，您将需要修改我之前提到的函数（即将它从过滤掉节点的条件集中删除）。 我不知道会有什么其他副作用，因为除了调度程序之外，该函数还可用于节点列表器。

davidopp picture davidopp 于 2017-03-31

有没有办法安装应该在 Ubuntu 上运行的 1.5.6？ 如果有，你能解释一下怎么做吗？ 谢谢！

overip picture overip 于 2017-03-31

请注意，如果您希望您的新污点将当前自动过滤掉的节点替换为 NetworkUnavailable，您将需要修改我之前提到的函数（即将它从过滤掉节点的条件集中删除）。 我不知道会有什么其他副作用，因为除了调度程序之外，该函数还可用于节点列表器。

@davidopp我们需要小心 NetworkUnavailable 与 NodeReady。 有两个单独的条件应该真正清理：

nodeNetworkUnavailable - 这是特定于云路由的，只有当节点之间的云路由已经建立时，云路由控制器才会清除这个条件。 创建覆盖或不在节点之间执行 L3 路由的网络插件不希望或使用此条件。 这个条件不是任何网络插件添加的； 它是由 kubelet 专门在选择 GCE 或 AWS 作为云提供商时添加的。 不影响 NodeReady，因为它是一个单独的条件。

NodeReady - 直接受网络插件影响（例如，CNI 或 kubenet 或远程运行时，如 dockershim/CRI-O）。

需要考虑三个独立的问题：

  1. Cloud Routes - 如果云基础设施和网络插件需要云路由，那么缺少云路由（例如，NodeNetworkUnavailable=true）需要阻塞调度 hostNetwork=false pods
  2. 网络插件 - 如果插件尚未准备好，则需要阻止 hostNetwork=false pod 的调度。 这与 NodeNetworkUnavailable 是分开的，因为插件可能没有与路由控制器的直接交互，因为它不依赖于云路由。 例如，如果您有其他东西（云路由、法兰绒等）设置节点路由，则 kubenet 可以在节点上本地使用。
  3. hostNetwork=true Pod 应忽略所有这些条件并进行调度，但受任何其他适用条件（磁盘空间等）的约束

NodeReady 太大了。 我想我们可能需要一个额外的 NetworkPluginReady 条件来为网络插件准备就绪（与云路由准备分开！）然后我们必须将它引导到关心的地方:(或者，真的，新的污点而不是条件。

dcbw picture dcbw 于 2017-03-31

我发现的另一个工作。

虽然 kubeadm 不断打印“[apiclient] 第一个节点已注册，但尚未准备好”，但我部署了安装 flanneld 的“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 picture bhtak 于 2017-03-31

@dcbw我对本期讨论的具体问题了解不够，无法准确告诉您该怎么做。 我只是想解释污点的当前状态以及它们如何在这里应用。

davidopp picture davidopp 于 2017-03-31

请测试打补丁的debs

kubernetes-xenial-unstable现在有一个补丁版本1.6.1-beta.0.5+d8a384c1c5e35d-00 ， @pipejakob和我今天一直在测试。 节点在创建 pod 网络之前仍未准备好（例如，通过应用编织/法兰绒配置）。 一致性测试通过。 PTAL。

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

抄送@luxas @jbeda

mikedanese picture mikedanese 于 2017-03-31
👍1

是 taints 几乎可以表达一切的大方向吗？
条件可以，因此在各方面都更好？

我同意我们需要更细粒度的信号。 我们还需要整理
kubelet、网络驱动程序、云控制器和云提供商之间的相互作用
解锁 hostNetwork=false pods，但 hostNetwork=true 不应该是
阻止。

2017 年 3 月 30 日星期四晚上 7:24，Dan Williams通知@github.com
写道：

请注意，如果您希望新的 taint 替换当前的自动
过滤掉具有 NetworkUnavailable 的节点，您将需要修改
我之前提到的函数（即从条件集中删除它
过滤掉一个节点）。 不知道还有什么副作用
有，因为该函数可以在节点列表器中使用，而不仅仅是
调度程序。

@davidopp https://github.com/davidopp我们需要小心
NetworkUnavailable 与 NodeReady。 有两个独立的条件
真的应该清理一下：

nodeNetworkUnavailable - 这特定于云路由，并且仅适用于云
当节点之间的云路由具有时，路由控制器清除此条件
被设置。 创建覆盖或不执行 L3 的网络插件
节点之间的路由不希望或使用这种条件。 这个条件是
不是由任何网络插件添加的； 它是由 kubelet 特别添加的
GCE 或 AWS 被选为云提供商。 不影响 NodeReady 因为
这是一个单独的条件。

NodeReady - 直接受网络插件影响（例如，CNI 或 kubenet
或远程运行时，如 dockershim/CRI-O）。

需要考虑三个独立的问题：

  1. Cloud Routes - 如果云基础架构和网络插件
    需要云路由，然后缺少云路由（例如，
    NodeNetworkUnavailable=true) 需要阻塞调度 hostNetwork=false
    豆荚
  2. 网络插件 - 如果插件尚未准备好，则需要
    hostNetwork=false pod 的块调度
  3. hostNetwork=true pods 应该忽略所有这些条件并且
    计划，但受任何其他适用条件（磁盘空间等）的约束

NodeReady 太大了。 我想我们可能想要一个
网络插件就绪的附加 NetworkPluginReady 条件
（与云路由准备分开！）然后我们必须查明
通过到关心的地方:(

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

thockin picture thockin 于 2017-03-31

对于仍然通过删除 kubelet KUBELET_NETWORK_ARGS 配置行来尝试临时修复的任何人， @jc1arke找到了一个更简单的解决方法 - 与新主节点建立两个会话，并在等待第一个节点准备就绪的同时，在第二个节点应用节点网络配置会议：
运行 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
...

第二个会话（使用 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 picture zatricky 于 2017-03-31
👍3

是 taints 几乎可以表达一切的大方向吗？
条件可以，因此在各方面都更好？

差不多。 由于向后兼容性问题，我们可能无法摆脱任何节点条件，但我们可以摆脱 master 中基于它们采取行动的所有逻辑（例如阻塞调度或驱逐 pod）。 除了使行为更加明显（无需记住哪些条件会阻止调度、哪些导致驱逐、我们等待驱逐的时间等），对条件的反应可以在每个 Pod 的基础上进行配置。

davidopp picture davidopp 于 2017-03-31

刚刚测试了来自@mikedanese和@pipejakob 的 deb ，这些工作正常。

在 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 picture coeki 于 2017-03-31

刚刚测试了@mikedanese和@pipejakob的 debs，它仍然冻结在
[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{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d",GitCommit:"d8a384c1c5e35d5118f79808deb7bab97TreeState2", GitState:" -03-31T04:20:36Z", GoVersion:"go1.7.5", 编译器:"gc", 平台:"linux/amd64"}

myqq0000 picture myqq0000 于 2017-03-31

@myqq0000你能贴出你使用的版本吗？

kubeadm version

coeki picture coeki 于 2017-03-31

@coeki哦，我忘了。 我刚刚编辑并在我之前的评论中发布了版本。 :)

myqq0000 picture myqq0000 于 2017-03-31

@mikedanese你有更新 centos yum repo 的计划吗？ 或者它是否已经部署到 yu​​m repo ？

bhtak picture 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://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml而不是“默认” https:// /git.io/weave-kube

mausch picture mausch 于 2017-03-31

@mausch你能告诉我如何获得这些债务吗？

srinat999 picture srinat999 于 2017-03-31

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

jimmycuadra picture 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 picture webwurst 于 2017-03-31

@mausch谢谢。 他们也与编织网络提供商一起为我工作。

srinat999 picture srinat999 于 2017-03-31

有机会为 Centos 构建相同的修复程序吗？ 我们的门控系统主要使用 centos 作为 kubernetes 集群基础。 如果我有 centos 版本，我可以保证大约。 每天运行 100 次 kubeadm init 作为测试。

sbezverk picture sbezverk 于 2017-03-31
👍13

@mikedanese修补的 debs 对我来说部分kubeadm通知集群已准备就绪，但节点本身尚未准备就绪。

squall0gd picture squall0gd 于 2017-03-31

@squall0gd节点应该在应用 pod 网络时准备就绪，例如 kubectl apply -f https://git.io/weave-kube-1.6

mikedanese picture mikedanese 于 2017-03-31

在我的测试环境中（在 vagrant 中，基于 centos/7 机器），kubeadm 只是挂起。 使用 strace 我可以看到它尝试连接到 master 上的 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 上找到了本期引用的 kubeadm 的一个（声称的）补丁版本（补丁版本是这样的：https://heptio-aws-quickstart test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm），但这对我不起作用。 行为仍然相同（没有任何输出）......

obnoxxx picture obnoxxx 于 2017-03-31

@squall0gd你能告诉我们你看到的确切信息吗？ 根据您的描述，我想知道您是否真的选择了新的 .debs 或正在使用旧的缓存版本。

pipejakob picture pipejakob 于 2017-03-31

@thockin @davidopp所以根据 Tim 的建议，我将https://github 的大部分内容中#issuecomment -290597988 进去。

dcbw picture 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 picture thenayr 于 2017-03-31
👍3

我们不在 1.6 分支上运行这些测试吗？

bgrant0607 picture bgrant0607 于 2017-03-31

@davidopp节点条件旨在为人类提供额外信息，以了解正在发生的事情，例如原因、消息和转换时间。

bgrant0607 picture bgrant0607 于 2017-03-31

kubeadm 看起来不像是在发布分支上测试的：
https://k8s-testgrid.appspot.com/release-1.6-all

bgrant0607 picture bgrant0607 于 2017-03-31

@bgrant0607显然 kubeadm e2e 测试在 1.6 版本发布前的大约一周内被禁用/不起作用，IIRC

dcbw picture dcbw 于 2017-03-31

节点条件旨在为人类提供附加信息，以了解正在发生的事情，例如原因、消息和转换时间。

@bgrant0607它们主要用于人类信息，还是只是一个快乐的副作用？ 如果主要用于人类，它们是否应该像现在一样用于调度决策，还是应该远离它？

dcbw picture dcbw 于 2017-03-31

@dcbw 污点旨在成为

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

bgrant0607 picture bgrant0607 于 2017-03-31

请注意，如果我们要向节点添加污点，我们需要考虑

a) 向后兼容性，与主污点一样： https :

b) 版本偏差。 将集群升级到 1.6 时，kubelets 将是混合版本，有些可能与 1.4 一样旧。

bgrant0607 picture bgrant0607 于 2017-03-31

所以回顾一下或者我解析这个：

基于@dcbw

nodeNetworkUnavailable 是云提供商的事情，与 kubeadm atm 无关，我们可能会遇到这个问题。

但是作为循环根源的 NodeReady 需要更细化。 这就是@davidopp想要成为一个污点，基于一个勾选框的列表，关于探针/活性，CNI 准备等。

好吧，虽然你可以争论，为什么不贴标签？

但是@dcbw您是否找到了更适合此讨论的主题？ 因为这个成为部署问题的一个桶，而不是真正的根源。

我知道，我没有真正解决问题，并围绕它发布黑客：)

但无论如何，我们应该在另一个地方讨论基本原理，确保在这里放置了修复的预计到达时间，然后继续前进。

不活泼，但很好:)

PS是的@bgrant0607我们应该更多地测试这个
PS2 如果我看错了，你可以怪我;)

coeki picture coeki 于 2017-04-01

@coeki我还会添加一个请求，要求将 N-1 版本保存在 rpm/deb 存储库中。 所有主要版本最终都会出现一两个问题。 出于这个原因，运营商长期以来一直避免将 N.0 版本用于生产。 如果将以前的版本保留一段时间，它会很好地工作。 但这一次 1.5.x 在 1.6 稳定之前就被完全删除了。 这使得没有充分准备的运营商（本地回购镜像等）在问题得到解决时无法取得进展。 颠簸的 N+1 版本的痛苦通常可以通过简单地将 N 保留一段时间来解决。

kfox1111 picture kfox1111 于 2017-04-01
👍2

@kfox1111门控也是一个问题......我们需要一个更好的策略:)

coeki picture coeki 于 2017-04-01

为什么甚至要删除旧版本？ 这很容易破坏人们的自动化并阻止可重复安装。

jimmycuadra picture jimmycuadra 于 2017-04-01

节点条件旨在为人类提供附加信息，以了解正在发生的事情，例如原因、消息和转换时间。

同意。 UX 绝对是我们可能无法摆脱节点条件的主要原因。 但是，我确实相信我们可以摆脱所有使用节点条件作为主操作（如驱逐和阻塞调度）的触发器，并使用污点来代替。

从长远来看（如 v2 API 长期运行），可以想象我们可以向污点添加原因和消息，然后摆脱节点条件，但我还没有真正考虑过，也绝对没有正式提议这样做。 （我们已经在一个方向上有了等价的过渡时间，即 TimeAdded。）

davidopp picture davidopp 于 2017-04-01

@coeki不，我所说的与门控无关。 除非您有一个可以测试所有可能完成的门的门，否则门无法找到所有问题。 操作员喜欢在他们的环境中做一些奇怪的事情。 :) 测试所有可能的东西的成本高得惊人。

我要求在新版本至少通过第一个错误修复版本发布之前不要删除旧版本。 对于此示例，1.6.1。 至少。 保留更多旧版本会更好。 这是允许操作员在解决新版本中的错误时继续取得进展的最佳实践。

kfox1111 picture kfox1111 于 2017-04-01

@kfox1111 ，这就是门控的作用，不要采用看起来不错的方法，并抛弃旧的可靠方式，现在发生了什么。

@davidopp我确实同意标签和污点可能与 api 看待它的方式、用户体验和机器有不同的区别，但现在它很普遍。 太我了，那就是:)

coeki picture coeki 于 2017-04-01

不管怎样，你引诱我讨论，我们真的不要在这个问题上有过，那是我的观点。

coeki picture coeki 于 2017-04-01

我想再问一次：如果我看到“kubeadm init”只是挂在那里而没有输出（尝试连接到 kubelet 服务器，但启动失败），我是否遇到了这个问题？ 如果是这种情况，#43835 是否适合我？

现在我在哪里可以得到：

  • kubeadm / kubectl / kubelet 的旧版本（1.6.0 之前）
  • 还是 kubeadm 的补丁版本（包括 #43835 或其他任何修复程序）？

谢谢！

obnoxxx picture obnoxxx 于 2017-04-01

（注：在提及引用kubeadm的修补版本以上承诺，我不工作...）

obnoxxx picture 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 picture mikedanese 于 2017-04-01
❤1

@mikedanese谢谢！ 试...

obnoxxx picture 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 picture mikedanese 于 2017-04-01

@mikedanese谢谢。 我正在安装 os 包（来自 kube repo），然后安装来自 web url 的二进制文件到来自 rpms 的二进制文件......

在1.6.1-beta.0.12版本并没有为我工作，虽然：
kubeadm init 仍然挂起，没有任何输出。 （尝试连接到 kubelet）

obnoxxx picture obnoxxx 于 2017-04-01

如果是 centos，也不要忘记 systemd 驱动程序。

kfox1111 picture kfox1111 于 2017-04-01

系统驱动？

obnoxxx picture obnoxxx 于 2017-04-01

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

mikedanese picture mikedanese 于 2017-04-01

天哪，谢谢，那更好！ :-)

obnoxxx picture obnoxxx 于 2017-04-01

@pipejakob我没有访问该日志的权利，但我已经检查kubeadm版本，这是同样的版本@webwurst得到了。 此外，我已经用apt-cache policy kubeadm检查了可能的kubeadm版本。 而且只有一个条目 - 来自 kubernetes-xenial-unstable。
@mikedanese我在发帖前试过法兰绒；)
编辑：我重建了整个平台， kubadm工作正常：+1：

squall0gd picture squall0gd 于 2017-04-01

伙计们，修复的现状是什么？ 它会很快转移到稳定的存储库吗？

miadabrin picture miadabrin 于 2017-04-01
👍6

@mikedanese打补丁的

ChipmunkV picture ChipmunkV 于 2017-04-03

有人能告诉我如何为 rhel (rpm) 构建 kubeadm 的补丁版本吗？

discostur picture discostur 于 2017-04-03
👍2

@mikedanese带有补丁 debs init 报告成功，但“网络插件未准备好：cni 配置未初始化”消息仍然存在。

主节点在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 pod 位于0/3 Pending 。

ChipmunkV picture ChipmunkV 于 2017-04-03

@ChipmunkV您可能需要配置 kube-proxy 以在用户空间中运行。 这在 1.5 中也是一个问题。

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

就其价值而言， kubernetes-xenial-unstable对我来说效果很好。

pstadler picture pstadler 于 2017-04-03

@pstadler ，感谢@errordeveloper在聊天中指出我有重叠的网络，我重新配置了编织中的IPALLOC_RANGE 。

ChipmunkV picture ChipmunkV 于 2017-04-03

谢谢@thenayr。 我可以调出 Kubernetes master，也可以使用 kubeadm join 将一个 worker 连接到它。 将很快发布更多更新

yugesha picture 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 picture errordeveloper 于 2017-04-03

@errordeveloper我们正在尝试发布一个版本，以便我们可以将修复程序推送到稳定分支，我希望应该在 O(days) 内完成。 在这个问题的描述中有一个链接到不稳定的补丁 debs。

mikedanese picture mikedanese 于 2017-04-03

以前的版本 1.5.6 在 CentOs 7 上对我有用，但现在我什至无法回滚，因为http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 中唯一的 kubeadm 版本是损坏的 1.6。 0. 关于如何获得 kubeadm 1.5.6 RPM 的任何建议？

bostone picture bostone 于 2017-04-03

确实，很可惜。 旧版本似乎已被完全删除。 :-(

obnoxxx picture obnoxxx 于 2017-04-03

我的结果是这些在 centos 7 上：

  • 我根本无法让 kubadm init 给我任何结果，即使使用修补过的最新 kubeadm，也没有对 kubectl 做任何事情。
  • 我已经能够得到kubectl与@coeki的指示开始，然后kubeadm甚至通过。 但在那之后，没有什么对我有用。 kubectl 说
The connection to the server localhost:8080 was refused - did you specify the right host or port?

任何提示发生了什么？

obnoxxx picture obnoxxx 于 2017-04-03

@obnoxxx默认情况下 apiserver 不侦听 8080，它侦听安全的 6443 端口，您可以使用 netstat -tunlp 进行检查。
您需要将 admin.conf 从 /etc/kubernetes 复制到您的 $HOME/.kube/config
确保您更改了 $HOME/.kube/ 中文件的权限，之后您的 kubectl 应该能够正确联系 apiserver。 哈。 塞尔盖

sbezverk picture sbezverk 于 2017-04-03

@apsinha你知道这个线程吗？ 有一些产品人员跟随可能会很好，因为我认为未来会有一些重要的收获。

在我的头顶：

  • 1.6.0 从未经过自动化测试： https :
  • 旧版本的二进制文件/包被删除，因此人们无法安全回滚； 打破了假设它们继续可用的任何安装自动化： https :
  • 没有公开宣布（我已经看到）这被打破的事实
  • 没有给出关于修复的时间表（我是一名开发人员，所以我知道被问到“什么时候修复？”是多么令人讨厌，但尽管如此，人们还是会问这个，所以至少提供一个估计的时间段是好的）
  • 继续加入对话的用户对事情的状态、解决方法和修复计划感到困惑
  • 贡献者之间的大量技术讨论，其中许多是关于长期战略的，与试图弄清楚正在发生的事情以及如何处理眼前问题的用户在同一线程中相结合

对所有成就 Kubernetes 的伟大人物没有任何不尊重的意思。 我只是希望这里有一些“可教的时刻”向前推进，因为就公众对 Kubernetes 可靠/稳定的看法而言，这看起来很糟糕。 （当然 kubeadm 是 alpha/beta，但它仍然有很多可见性。）

jimmycuadra picture 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 picture bostone 于 2017-04-03

@bostone需要adjus代表.spec这里。

gtirloni picture gtirloni 于 2017-04-03
👍1

@sbezverk感谢您的提示！ 现在好多了...

这很好奇：

  • 我不记得在早期版本中复制 admin.conf 对我来说是必要的。
  • 我之前尝试过kubectl -s localhost:6443但这还不够。

不管怎样，现在我可以继续了。 再次感谢

obnoxxx picture obnoxxx 于 2017-04-03

v1.6.1 正在发布中。 它将由 EOD 完成。

mikedanese picture mikedanese 于 2017-04-03
👍5

一些注意事项：

  1. 删除旧包的问题在这里跟踪： https : @bostone你的问题也在那里被引用）
  2. 在此处跟踪 PR 的 kubeadm e2e 测试： https :
  3. 至于公开声明——我在推特上发布过，但这几乎不是官方的。 不清楚针对此类关键问题的正确渠道是什么。

这些都是在 PM 中提出的好问题。 @pipejakob慷慨地自愿将事后分析放在一起。

jbeda picture jbeda 于 2017-04-03

@obnoxxx 之前需要复制/修改 admin.conf 的要求，因为在 1.5 中，我们让 API 服务器暴露了一个不安全的端口。 我们在 1.6 中改变了它。 现在您必须使用安全凭证来访问 API 服务器（请参阅 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2）

jbeda picture jbeda 于 2017-04-03

@mikedanese听起来很棒，谢谢！
只是为了我这个傻瓜 - 这个版本 1.6.1 对这个问题有什么影响？
kubelet 是否会在不更改/etc/systemd/system/kubelet.service.d/10-kubeadm.conf （ @coeki的解决方法）的情况下启动，还是会包含 #43835 的修复（这似乎对我没有任何影响）？

obnoxxx picture obnoxxx 于 2017-04-03

@jbeda感谢您的解释！

obnoxxx picture obnoxxx 于 2017-04-03

@jbeda我认为混淆来自官方 kubadm 安装文档将 YUM 存储库设置为http://yum.kubernetes.io/repos/kubernetes-el7-x86_64。 该 repo 只有 kubeadm-1.6.0

bostone picture bostone 于 2017-04-03

再次令我失望的是，构建 1.5.6 rpms 并安装最终遇到了同样的问题。 运行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 picture bostone 于 2017-04-03

1.6.1 出来了。

mikedanese picture mikedanese 于 2017-04-04
🎉5

@mikedanese你在关闭这个 bug 之前测试过 kubeadm 吗？ 现在我已经盯着[apiclient] Created API client, waiting for the control plane to become ready看了 10 分钟。 在安装了全新 1.6.1 的 CentOS 7 上

bostone picture bostone 于 2017-04-04

@bostone你可能会遇到这个问题：#43805

尝试编辑/etc/systemd/system/kubelet.service.d/10-kubeadm.conf并添加--cgroup-driver=systemd

记得运行systemctl daemon-reload; systemctl restart kubelet

gtirloni picture 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 picture 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
Active：自 2017-04-03 星期一 17:31:07 PDT 起处于活动状态（正在运行）； 11 分钟前
文档： http :
主PID：10382（kubelet）
C组：/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
└─10436 journalctl -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插件消息：未初始化```

bostone picture bostone 于 2017-04-04

是的，我们测试过。 e2e 测试正在发布分支上通过。 您可能会遇到其他问题。

mikedanese picture 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

您还需要按照此处描述的步骤 3 进行操作。 这似乎与您收到的 cni 配置错误有关。

gtirloni picture gtirloni 于 2017-04-04
👍1

还盯着 [apiclient] 创建的 API 客户端，等待控制平面准备好 10 分钟，Ubuntu 16.04 和 1.6.1 的全新安装

TechauraIO picture TechauraIO 于 2017-04-04

@pingthings我建议加入 Slack Kubernetes 和kubeadm频道。 我们可以帮助您在那里调试。

LaurentDumont picture 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
=> 为最新的 Kubernetes 1.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 使用 systemd 作为 cgroup-driver 而 kubelet 使用 cgroupfs 作为 cgroup-driver。
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/
须藤 chown $(id -u):$(id -g) $HOME/admin.conf
导出 KUBECONFIG=$HOME/admin.conf
=> 如果没有这一步，kubectl get 可能会报错
=> 我没有用 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
=> 创建一个 Flannel 守护进程
9) (在每个从节点上) kubeadm join --token (你的令牌) (ip):(port)
=> 如 kubeadm init 的结果所示

以上所有步骤都是结合 Kubernetes-1.6.0，尤其是 kubeadm 的各种问题的建议的结果。

希望这会节省您的时间。

eastcirclek picture eastcirclek 于 2017-04-04
👍9

这似乎没有解决（Ubuntu LTS，kubeadm 1.6.1）。

首先，我在使用--apiserver-advertise-address标志时也遇到了 kubeadm 挂在“已创建 API 客户端，等待控制平面准备就绪”的情况。日志日志说：

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 picture 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难以降级，实际上破坏了向后兼容性

sheerun picture sheerun 于 2017-04-04

@bostone

你有没有发现“等待控制平面准备就绪”的问题？ 在尝试了 1.6.1 的所有更改后，我看到了同样的事情。

ghost picture 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 picture bostone 于 2017-04-04

@bostone这不是你需要的 kubelet 端口，它是 kube-apiserver，它应该在 6443 端口上监听。

sbezverk picture sbezverk 于 2017-04-04

@sbezverk就端口

bostone picture bostone 于 2017-04-04

@bostone如果您没有修改 apiserver 清单中的任何内容，那么默认情况下它将侦听 6443 端口。 您只需要将 /etc/kubernetes/admin.conf 复制到 $HOME/.kube/config 中，更改配置文件的权限即可。

sbezverk picture sbezverk 于 2017-04-04

@sbezverk BTW - 我正在以 root 身份运行所有安装步骤，但是kubeadm init输出中的这 3 条指令行建议使用 sudo 用户。 对此有何建议？ 是否也应该将所有安装步骤作为 sudo 运行？

bostone picture bostone 于 2017-04-04

好的，我从头开始做了所有步骤，似乎更好。 以下是迄今为止对我有用的步骤，我在 CentOS 7 上以 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之外的 minion 的所有步骤，而是运行kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443生成的kubeadm init
这一步完成，我可以看到 master 和 minion(s) 节点

现在 - 问题：

# 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 picture bostone 于 2017-04-04
🎉1

我想你的编织没有正确部署，因为你正在使用
1.6 之前的 yaml 文件。

尝试“kubectl apply -f https://git.io/weave-kube-1.6 ”

2017 年 4 月 4 日星期二下午 12:24，Bo Stone [email protected]写道：

好的，我从头开始做了所有步骤，似乎更好。 这里有
到目前为止对我有用的步骤，我以 root 身份运行。

猫 <

[kubernetes]
名称=Kubernetes
baseurl= http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
启用=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

设置强制 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 启用 docker && systemctl 启动 docker

systemctl 启用 kubelet && systemctl 启动 kubelet

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

systemctl 停止 firewalld； systemctl 禁用 firewalld

kubeadm 初始化

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 nodes 并在
列表。
重复 minion 的所有步骤，当然运行 kubeadm join 除外
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 由 kubeadm 生成
在里面
这一步完成，我可以看到 master 和 minion(s) 节点

现在 - 问题：

kubectl 获取节点

姓名 状态 年龄 版本
abc02918 未就绪 42m v1.6.1
abc04576 未就绪 29m v1.6.1

kubectl 描述节点 abc02918

事件：
来自 SubObjectPath 类型原因消息的 FirstSeen LastSeen 计数
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet, sdl02918 正常启动 启动 kubelet。
43m 43m 1 kubelet, sdl02918 警告 ImageGCFailed 无法找到容器的数据 /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk Node 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 picture 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 picture dcowden 于 2017-04-04

@sjenning就是这样！ 我仍然需要部署一些图像以查看是否一切正常，但我可以看到所有节点具有Ready状态！ 谢谢你们，伙计们（现在：）

bostone picture bostone 于 2017-04-04

@bostone我遵循了您使用的相同配方，但得到了不同的结果——我没有通过 kubeadm init。 您使用的是什么 docker 版本？ 也许这就是我的情况的不同之处？

dcowden picture dcowden 于 2017-04-04

@dcowden这是 yum 在我的系统上选择的任何Docker version 1.12.6, build 96d83a5/1.12.6 。 另外帮助我的是重新配置我正在使用的所有虚拟机，而不是尝试在我以前的安装之上进行修复

bostone picture bostone 于 2017-04-04

@bostone谢谢。 我会降级到那个版本，看看我是否可以得到一个工作设置。 在我的系统上，最新的是一个奇怪的 17.03.1.ce 版本（显然是最新的最好的）

dcowden picture dcowden 于 2017-04-04
👍1

不确定它是否通常有用，但我有一个可靠的剧本
完成 CentOS 7 的所有步骤

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

YMMV，但它至少记录了过程。 我也做一些事情，比如
切换 docker 以使用 json 文件日志记录和覆盖存储。

即使您没有实际运行剧本，也可能作为参考很有用。

2017 年 4 月 4 日，星期二，下午 12:55，Dave Cowden通知@ github.com
写道：

@bostone https://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 picture sjenning 于 2017-04-04
👍4

@sjenning谢谢！ 这很有帮助！

dcowden picture dcowden 于 2017-04-04

好的，这是一个并发症。 在 master 和 minion 上运行kubeadm reset并重新启动 docker 和 kubelet 服务后， kubeadm init再次挂在Created API client, waiting for the control plane to become ready 。 有人可以提供重置 kubeadm 的完整步骤吗？
@sjenning您是否尝试过在最初运行剧本后重新运行剧本？

bostone picture bostone 于 2017-04-04

@bostone在我的情况下移动/var/lib/etcd/做到了。

autostatic picture autostatic 于 2017-04-05

@autostatic目录是空的，重命名它没有帮助。 @sjenning你的剧本挂了，我为你创建了一张票

bostone picture bostone 于 2017-04-05

有没有人试过在 v1.6.1 上运行仪表板？ 我收到一个错误，指出以下内容：

`禁止（403）

用户“ system:serviceaccount :kube- system:default ”无法列出集群范围内的命名空间。 （获取命名空间）
`

我想我需要配置更多的 RBAC，就像运行 Flannel 一样？

ghost picture ghost 于 2017-04-06

@srzjulio你能

jbeda picture jbeda 于 2017-04-06

@srzjulio你需要更新 RBAC 规则，我们使用这些来让我们继续：

api版本：rbac.authorization.k8s.io/v1alpha1
种类：ClusterRoleBinding
元数据：
名称：集群管理员
角色参考：
apiGroup: rbac.authorization.k8s.io
种类：集群角色
名称：集群管理员
科目：

sbezverk picture sbezverk 于 2017-04-06
👎6

小心—— @sbezverk的绑定

jbeda picture jbeda 于 2017-04-07
👍3 
kind: Group
name: system:unauthenticated

这是特别糟糕的。 这意味着任何可以联系您的 API 服务器的人，即使没有任何凭据，也可以运行任意命令。

ericchiang picture ericchiang 于 2017-04-07

@jbeda它与我们在 1.5.6 中开箱即用的行为相匹配。 它让人们有机会审查和逐步调整安全配置，而不是无法对新的安全规则做任何事情。

sbezverk picture sbezverk 于 2017-04-07

实际上，使system:unauthenticated集群管理员远比 1.5.6 差

如果不需要授权，请使用 AlwaysAllow 授权器

liggitt picture liggitt 于 2017-04-07

如果您想在审核时允许所有，请使用 RBAC,AlwaysAllow 的组合

这将禁用匿名请求，在 API 服务器日志中记录 RBAC 拒绝，但继续允许所有经过身份验证的请求做任何他们想做的事

liggitt picture liggitt 于 2017-04-07

抱歉，我再次重复此问题，这与原始问题无关。 尽管存在有效的问题和问题，但我们应该将话题转移到其他地方。

再次抱歉，按 Enter 键太早了，但就目前情况而言：

1 - 发布 1.6.0 导致问题
2 - 并非都是固定的
3 - 转向 RBAC（在我看来很好）但有问题，为什么？ 见第 4 点
4 - 这不是很好的沟通，也没有很多文档/博客或任何解释它的东西
5 - 我向所有试图打捞的人鞠躬，但我们需要一个更好的方法来做到这一点

coeki picture coeki 于 2017-04-07

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions 是一个很好的指南，介绍了用于打开权限的最细化选项。

liggitt picture 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 picture ReSearchITEng 于 2017-04-12

@ReSearchITEng为什么不将 docker 更新到 1.12.6？ 使用这个版本就像一个魅力。

sbezverk picture sbezverk 于 2017-04-12

@sbezverk ：我刚刚更新到 1.12.5，现在可以使用了！ 非常感谢！

ReSearchITEng picture ReSearchITEng 于 2017-04-12

感谢大家的帮助。
最终使用法兰绒完全运行 k8s 1.6.1。 现在一切都在 ansible playbook 中。
在 Centos/RHEL 上测试。 基于 Debian 的准备工作也已开始（例如 Ubuntu），但可能需要一些改进。

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

PS：基于 sjenning/kubeadm-playbook 的工作 - 非常感谢@sjenning ！

ReSearchITEng picture ReSearchITEng 于 2017-04-15

@sjenning @ReSearchITEng
嗨，我有一个 vagrant+ansible playbook [0] 与你创建的非常相似，但我仍然无法让它工作，对我来说它在网络设置上失败了。 我尝试过印花布、编织和法兰绒，但三种都失败了（尽管症状不同）。

我正在运行这些版本：
[ 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{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"0403:" 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 picture thiagodasilva 于 2017-04-26

我无法确定你到底出了什么问题。
我强烈建议您尝试使用此处的剧本创建单独的安装： https :
PS：我最近的测试是 1.6.2 ，kube* 和图像，看起来都很好。

ReSearchITEng picture ReSearchITEng 于 2017-05-02

@kelseyhightower

davidopp picture davidopp 于 2017-05-20

@ReSearchITEng对不起，我忘了报告，但我最终让它工作了，我的 vagrant+ansible 文件在这里： https :

thiagodasilva picture thiagodasilva 于 2017-05-22

我也遇到了同样的问题，但是我只是将master节点上的cni配置复制到worker节点的相应位置，然后就OK了。

systemctl status kubelet.service -l

● kubelet.service - kubelet：Kubernetes 节点代理
已加载：已加载（/etc/systemd/system/kubelet.service；已启用；供应商预设：已禁用）
插入：/etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active：自 2017-06-06 星期二 10:42:00 CST 起处于活动状态（正在运行）； 18 分钟前
文档： http :
主PID：4414（kubelet）
内存：43.0M
C组：/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
└─4493 journalctl -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 获取节点
姓名 状态 年龄 版本
contiv1.com Ready 1h v1.6.4
contiv2.com Ready 1h v1.6.4
swarm.com Ready 1h v1.6.4

frankruizhi picture frankruizhi 于 2017-06-06

对此有任何决议吗？ 即使在尝试了所有提到的决议之后，我也无法做到这一点。

vaibhavjain882 picture vaibhavjain882 于 2017-06-08

作为设置 Kubernetes 的新手，我感到非常困惑。 我尝试关注https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 使用 weave-kube 进行网络，但我也遇到了同样的问题. 有什么办法可以解决这个问题？
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 picture tirithen 于 2017-06-12

为什么这仍然是一个问题？ 带有最新更新的 Ubuntu 16.04/CentOS 7.3 使用官方 k8s 存储库和 1.6.4 并按照此处概述的步骤操作： 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 picture datamattsson 于 2017-06-13

@drajen不，这影响了_only v1.6.0_ 。 由于您尚未安装任何网络，因此预计 kubelet 找不到网络。 例如，只需运行

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

安装 Weave Net，这些问题就会消失。 如果您愿意，您可以选择安装 Flannel、Calico、Canal 或任何 CNI 网络

luxas picture luxas 于 2017-06-13
👍2

@luxas我一直看到对此的引用，但是我该如何将某些内容应用于未运行的集群？ 我没有什么可连接的。

datamattsson picture datamattsson 于 2017-06-13

@drajen我认为@luxas的观点是，这是询问设置的错误地方。
各种设置指南将使您通过这一点 - 旧指南中典型的缺失步骤，luxas 很有帮助地提到，因为您需要应用网络配置，然后一切才能开始正常工作。

zatricky picture zatricky 于 2017-06-13

是的，这可能不明显，对此我们深表歉意，但我们也不能只有一个供应商名称。

在 Slack 上与@drajen 聊天，问题与​​ cgroup 相关，kubelet 不健康并且无法创建任何 Pod，因此出现了问题。

luxas picture luxas 于 2017-06-13
👍1

感谢@luxas 解决了我的特殊问题： https :

datamattsson picture datamattsson 于 2017-06-14
👍1

仍然在 1.7 上遇到这个问题，有什么地方可以快速修复吗？

编辑：

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

成功了，看起来我们只需要运行 CNI

kris-nova picture 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
（这是必需的，特别是如果您使用法兰绒）
如果你想合而为一，你可能想使用整个项目： https :

ReSearchITEng picture ReSearchITEng 于 2017-07-03

我遇到了这个问题，我上面读到的绝对没有任何效果。 所以我再次尝试了一个更可控的设置，从 Ubuntu 切换到最新的 CoreOS，从早期版本的 k8s 开始，并且通常对每个 VM 中安装的最后一个东西都非常敏感。 我没有使用 kubeadm，而是使用 vagrant 和 ansible 的组合。

（为什么？因为我不知道 kubeadm 中发生了什么，并且这样想至少我可以控制并能够绕过任何过分热情的预检检查，更不用说感觉我有更多的自动化控制，而且不必担心生产中不应用 alpha 软件的警告。）

当我使用旧版 (1.4.3) 的 k8s 尝试此设置时，这种方法非常有用。 然后我尝试升级到 1.71。 再一次，尽管根本没有使用 kubeadm，我仍然遇到同样的问题。

我已经确认我正在我的每个节点中运行 calico，包括 Master 和三个潜在的 Workers。 我的所有节点都报告为 NotReady，所以我不确定如何应用编织（或其他任何东西）来让它运行。

这整个事情看起来像鸡/蛋……无法分配 pod，因为网络失败，但需要运行网络以在 /etc/cni/net.d 中创建网络，以便能够分配 pod。 再一次，所有这些在几个小时前用 k8s 1.4.3 工作。 我非常沮丧！

我很感激任何人可以提供的任何见解。

脚注：

在 master 上： journalctl -r -u kubelet 给了我

7 月 24 日 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] 容器运行时网络未就绪：NetworkReady=false原因：NetworkPluginNotReady message网络插件没有
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 中找不到网络.d

码头工人印花布

（为了可读性而被截断）
CDE ... quay.io/calico/领袖，选民@ SHA256 ：...... “/run.sh --election = C” 13小时前最多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 框中：
kubectl 获取节点
10.0.0.111 NotReady,SchedulingDisabled 8h v1.7.1+coreos.0
10.0.0.121 未就绪 8h v1.7.1+coreos.0
10.0.0.122 未就绪 8h v1.7.1+coreos.0
10.0.0.123 未就绪 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
已创建服务帐户“织网”
集群角色绑定“织网”已创建
守护进程“weave-net”已创建
服务器错误（禁止）：clusterroles.rbac.authorization.k8s.io“weave-net”被禁止：尝试授予额外权限：[PolicyRule{Resources:["pods"], APIGroups:[""], Verbs: ["get"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs: ["watch"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["get"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs: ["list"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["watch"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs: ["get"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs: ["watch"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verbs:["get"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verbs:["list"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verbs:["watch"]}] user=&{kube-admin [system:a 已验证] map[]} ownerrules=[] ruleResolutionErrors=[]

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl get pods --namespace=kube-system
名称就绪状态重新开始年龄
kube-apiserver-10.0.0.111 1/1 运行 1 8h
kube-controller-manager-10.0.0.111 1/1 运行 1 8h
kube-dns-v20-fcl01 0/3 待定 0 8h
kube-proxy-10.0.0.111 1/1 运行 1 8h
kube-proxy-10.0.0.121 1/1 运行 1 8h
kube-proxy-10.0.0.122 1/1 运行 1 8h
kube-proxy-10.0.0.123 1/1 运行 1 8h
kube-scheduler-10.0.0.111 1/1 运行 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 待定 0 8h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 运行 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

对编织错误的深入调查表明它们要么 (a) 无法连接到 apiserver，要么 (b) 在标记为“正在运行”的情况下，它抱怨它无法连接到自己。

billmilligan picture billmilligan 于 2017-07-24

@billmilligan 遇到类似问题，dns 在容器启动几分钟后停止工作

Paxa picture Paxa 于 2017-07-24

@Paxa @billmilligan如果您想获得帮助，请不要对此问题发表评论。 相反，在请求足够详细信息的 kubeadm 存储库中打开新的。

luxas picture luxas 于 2017-07-24

@luxas 恕我没有kubeadm 的与其他人

billmilligan picture billmilligan 于 2017-07-24

@billmilligan恭敬地，既然问题是关于 kubeadm 的，而且您可以在没有 kubeadm 的情况下复制它，那么它是错误的归档位置吗？ 我认为这个线程解决了 kubeadm 问题。 这是一个新问题。 我认为它将作为一个新问题受到更多关注。 由于该线程上的人们认为它已经解决并忽略它。

我使用 kubeadm 并受到此问题的影响，自 1.6.1 以来已解决。 我已经部署了 k8s 的丢失，所以我真的认为你有一个单独的问题。

kfox1111 picture kfox1111 于 2017-07-24

@kfox1111感谢您的反馈。 我将提交一个新问题，但在 1.7.x 的其他地方似乎仍然面临它的人数仍然让我感到疑惑。

billmilligan picture billmilligan 于 2017-07-24

TL; 博士;

错误信息

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

不一定是坏事。

该错误消息告诉您必须插入第三方 CNI 规范实现提供程序。

什么是 CNI，如何与 Kubernetes 集成？

CNI 代表容器网络接口，定义了kubelet 用于为集群创建网络此页面。

只要满足 CNI 规范， Kubernetes并不关心网络是如何创建的。

kubelet负责将新 Pod 连接到网络（例如可以是覆盖网络）。
kubelet读取 CNI 网络使用的配置目录（通常/etc/cni/net.d ）。
创建新 Pod 时，kubelet 读取配置目录中的文件， exec输出到配置文件中指定的 CNI 二进制文件（二进制文件通常在/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 入门指南中的下一步是“安装 Pod 网络”。
这意味着， kubectl apply来自您首选的 CNI 网络提供商的清单。

DaemonSet 会将所需的 CNI 二进制文件复制到/opt/cni/bin并将所需的配置复制到/etc/cni/net.d/ 。 它还将运行在节点之间建立网络的实际守护进程（例如通过编写 iptables 规则）。

安装 CNI 提供程序后，kubelet 会注意到“哦，我有一些如何设置网络的信息”，并将使用第 3 方配置和二进制文件。

当网络由第 3 方提供者（通过 kubelet 调用）设置时，节点将标记自己Ready 。

这个问题与 kubeadm 有什么关系？

在 v1.6 周期后期，合并了一个 PR，改变了 kubelet 报告Ready/NotReady状态的方式。 在早期版本中， kubelet始终报告Ready状态，无论 CNI 网络是否设置。 这实际上有点错误，并更改为尊重 CNI 网络状态。 也就是说，CNI 未初始化时为NotReady ，初始化时为Ready 。

v1.6.0 中的 kubeadm 在继续执行其余的kubeadm init任务之前错误地等待主节点处于Ready状态。 当 kubelet 行为更改为在 CNI 未初始化时报告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所以你只需要kubectl apply一个 CNI 提供者的清单就可以让你的集群启动并运行我认为

我几乎总结了上面所说的内容，但希望以更清晰和详细的方式。
如果您对 CNI 的工作方式有疑问，请参考常规支持渠道，如 StackOverflow、问题或 Slack。

（最后，对于这么粗体的文字感到抱歉，但我觉得需要引起人们的注意。）

luxas picture luxas 于 2017-07-24
👍2
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

jason-riddle picture jason-riddle  ·  3评论
errordeveloper picture errordeveloper  ·  3评论
mml picture mml  ·  3评论
tbchj picture tbchj  ·  3评论
jadhavnitind picture jadhavnitind  ·  3评论