Kubeadm: apiserver无法启动，因为livenessprobe过于激进

似乎我们目前将控制平面吊舱的InitialDelaySeconds和TimeoutSeconds为15，这也与kube-up.sh功能匹配。 我了解最初的启动速度很慢，所有图像都被立即拉出，但是在所有图像都被拉出之后，您的apiserver在启动后要花多长时间来响应/healthz支票？

毫无疑问，我们可能应该同时调整这两个值以适应低功率机器。

一旦启动，它就可以在<< 15s内响应健康检查-实际上，这是apiserver在exec（）到实际准备服务于faics之间所做的所有额外工作。

哦，泊坞窗拉动时间不计入InitialDelaySeconds afaics（好）。 在我比较低的网络链路具有较大（一般Ubuntu的）图像其他例子，上拉可以采取许多分钟，但似乎并没有计时器开始滴答作响，直到拉已经完成和泊坞窗运行已经开始initialDelaySeconds。 （我没有看过相关的代码，只是经常的轶事而已）

我遇到了同样的问题。 使用慢速机器时， kubeadm永远坐着。 使用v1.7.4

@anguslees和@koalalorenzo ，是否可以确认是否手动更改活动探针设置（通过编辑/etc/kubernetes/manifests/的清单文件）可以解决问题？ 我最近还在Slack上看到了一个案例，该案例中用户具有相同的症状，但很可能会遇到内存限制，因为当他们转移到具有更多内存的主机类型时，问题就消失了。

我只是想确保在我们花时间进行编码之前，该方法可以真正解决问题。 谢谢！

在没有硬件辅助虚拟化的情况下尝试在QEMU中使用kubeadm时，我也遇到了这个问题（这是一个很糟糕的主意，因为它的运行速度非常慢）。 增加InitialDelaySeconds和TimeoutSeconds会有所帮助； 然后，群集将最终出现。

@pipejakob我可以确认（在我的bananapi上）在kubeadm运行的正确点在另一个终端中运行此命令，可以成功完成所有操作：

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

（我通常还手动docker kill个旧/重启循环apiserver容器，我不确定是否可以使用静态容器自动清除它）

@anguslees太好了！ 感谢您的确认。

我可以确认我在树莓派3上也遇到过这个问题。更改为180s可以修复它，但是我想我也遇到了问题＃106，因为在我的情况下它死于：

9月1日10:47:30 raspberrypi kubelet [6053]：W0901 10：47：30.020409 6053 kubelet.go：1596]删除镜像容器“ kube-apiserver-raspberrypi_kube-system（7c03df63-8efa-1
1e7-ae86-b827ebdd4b52）“，因为它已过时

我必须手动启动kubelet流程才能使其恢复活力。

我也可以确认自己有这个想法，并想说谢谢您保存我的理智。 我有Raspberry Pi 2B，上个月我一直处于初始化阶段。 在开始等待班机运行后，我开始运行它。

这个问题在kubeadm v1.8.0中仍然存在，而且更糟糕的是，因为kubeadm现在本身在大多数操作上都有1分钟的超时时间。 1分钟超时似乎是任意选择的，很遗憾，a）没有给您足够的时间来调试和解决问题（例如，上面的sed hack），b）足够的时间让apiserver启动（〜 20世纪90年代对我来说），甚至当initialDelaySeconds已经扩展，以及c）不能没有黑客可以增加/重建kubeadm AFAICS。

超时中断，或正确的逻辑，特别是在复杂的最终一致的系统-我们永远不应该添加它们“只是因为” :(我的理解是， kubeadm ，就是要构建块上更大规模的部署系统可以依赖。因此，我大胆地建议从kubeadm本身中删除所有超时（各个阶段应永远重试），并在较高/较低级别的情况下（如果合适）依靠较高层的流程添加总体超时。表示“重试，直到用户放弃并按^ c”。这样的PR可以接受吗？

@anguslees我们之前有“永远等待”的行为； 但这从UX PoV来看不是很理想，所以现在我们确实有超时。 如果需要，我们可能希望增加一些超时时间。

问题在于，对kubeadm的使用有两个方面。 我们俩都有用户交互地键入kubeadm，他们想知道是否发生了什么-和-更高级别的使用者。

..那么我们要往哪个方向走？ 目前，我使用kubeadm的前叉，它的超时次数提高了10倍，我很喜欢相信我可以回到使用标准kubeadm二进制文件的地步。

@anguslees我们之前有“永远等待”的行为； 但这从UX PoV来看不是很理想，所以现在我们确实有超时。 如果需要，我们可能希望增加一些超时时间。

如何使它们可配置？ 拥有所有选项的单个选项是否有意义？

/优先级即将到来

拥有所有选项的单个选项是否有意义？

可能是所有超时都乘以某种“权重” ...否则，我们将使用20种不同类型的超时标志进入配置地狱:)

在树莓派2集群上使用kubeadm升级遇到相同的问题。 升级由于超时而失败。 更改清单中的活动探针设置无济于事。 有任何想法吗？

我仍然提出一种模式，其中任何kubeadm超时都从调用上下文继承（或作为更复杂的错误恢复策略的一部分），而不是在kubeadm代码库的较低级别上散布任意超时。

以最简单的形式，它的行为几乎就像从kubeadm中删除所有超时并用一个整体的“运行xx分钟，然后中止运行，如果未完成则终止”全局计时器来代替它们一样（因为kubeadm不能以错误的方式做很多事情）恢复，而不是等待更长的时间）。

对于原始清单livenessProbe超时，它实际上是一个单线补丁。 不幸的是，仅仅修复livenessProbe绰绰有余，因为“偏离正常==错误”谬论已经在整个kubeadm代码库中进一步蔓延。 改变文化意识非常困难，因此，与此同时，如果有人想将其安装在树莓派上，那么我在这里有kubeadm的分叉版本。 （使用make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm构建）

@anguslees您是否已安装已修补的kubeadm的1.9.4版本？ 我在编译您的补丁版本时遇到问题。

我很惊讶kubeadm在标志后面没有这种行为。 也许是公关秩序？

/ assign @liztio

因此，我们在1.11中修复了两个可能会影响此问题的问题。

1. 在启动之前预拉etcd映像。
2. 修复启动时的竞争条件检查。
   ...

如果仅在rasberry pi-gear上发生这种情况，那么我们需要某种限定最低公分母的方法。

我们计划支持的最低目标平台是什么？

我认为Raspberry Pi 2是您要在其上运行Kubernetes的最低平台。 我使用非硬件辅助QEMU进行的测试太过奇特，因此无法考虑。

考虑到Pi的I / O速度很慢，预拉所有图像已经可以帮上很多忙，但是我们需要一些实际测试来确定实际的超时时间。

伊莫树莓PI2是太老支持- http://socialcompare.com/en/comparison/raspberrypi-models-comparison ，在2015年就出来了。

>= 3似乎更合理。

预拉图像将无济于事。 livenessProbe计时器要等到图像被拉出之后才能启动（正如我在上面指出的）。

解决方法只是延长initialDelaySeconds超时。 kubeadm中的当前超时值被滥用以“增强”快速的UX体验，而不是错误检测。

编辑：而且要明确，这只是需要一段时间才能使用的启动程序-一旦增加apiserver intialDelaySeconds超时（以及在kubeadm本身中使用的其他仅安装超时），我的控制集群就可以在3xRPi2上正常运行。 我不明白为什么我们仍然在谈论这个：/

我在1.9.3上有一个ARM64群集，已成功更新到1.9.7，但是出现了从1.9.7升级到1.10.2的超时问题。

我什至尝试编辑和重新编译kubeadm以增加超时（如这些最后的提交https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork），结果相同。

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

如果使用kubeadm并启动了apiserver，我们可以尝试在首次启动时测量点。 也许我们会在以后的阶段中更改配置，以适应首次初始化时的测量超时。 同样很难发现，apiserver被healtz检查日志所踢，我们至少可以找到更好的日志记录来意识到问题所在。 我花了相当长的时间才发现活泼的问题是问题所在。 我必须提到我是一个初学者，在kubeadm的失败输出的某处提到它至少会有所帮助。

即使使用预拉图像，RaspberryPi 3仍会演示此问题。 API服务器需要2-3分钟才能到达可以提供页面的位置...

使其具有可配置性将是很棒的，因为现在，当kubeadm运行时，我正在后台修补YAML文件。

@carlosedp升级期间我要做的是在apiserver引导时关闭kubelet。 这有点骇人听闻，但可以阻止运行状况检查，直到apiserver启动为止。

但是说实话， kubeadm upgrade和ARM在我的经验中并不能很好地协同工作...

@brendandburns直到1.9

我看到超时更改为1.11到5分钟（https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45）。 您是否尝试过1.11？

我从假期回来后会尝试这种技巧。 谢谢你的提示！

@brendandburns @carlosedp
是的，请尝试1.11确认超时增加对您来说是可以解决的。

/ cc @ kubernetes / sig-cluster-lifecycle-bugs

嘿！ 我也遇到了这个问题。
不过，有趣的是，我设法在Raspberry 3上从头开始构建集群主机，但始终无法在3+上运行。
无论如何，我当前正在使用的版本（根据https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/上的分步文档）
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

与其他服务器一样，apiserver容器最终会启动，但不是在kubeadm退出之前，这使我陷入了困境，因为我缺乏经验，无法从那里手动接管。

快速更新：正在运行
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
在一个单独的终端中允许我的集群启动。

@DJGummikuh
感谢测试1.11。

与其他服务器一样，apiserver容器最终会启动，但不是在kubeadm退出之前，这使我陷入了困境，因为我缺乏经验，无法从那里手动接管。

在您的情况下，apiserver启动需要多少时间？
看来我们可能必须使它可配置。

很难说，我估计大约1分钟，但是我不知道如何正确地测量它。

此外，既然我的主服务器正在运行，我无法向其添加节点，这似乎是另一个超时问题。
`[preflight]运行飞行前检查
[WARNING RequiredIPVSKernelModulesAvailable]：将不会使用IPVS代理，因为未加载以下必需的内核模块：[ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs]或没有内置内核ipvs支持：map [ip_vs_rr：{} ip_vs_s： nf_conntrack_ipv4：{} ip_vs：{}]
您可以使用以下方法解决此问题：

1. 运行'modprobe-'加载缺少的内核模块；
   
   
   
   1. 提供缺少的内置内核ipvs支持
   
   

I0708 19：02：20.256325 8667 kernel_validator.go：81]验证内核版本
I0708 19：02：20.256846 8667 kernel_validator.go：96]验证内核配置
[WARNING SystemVerification]：泊坞窗版本大于最近验证的版本。 Docker版本：18.03.1-ce。 验证的最高版本：17.03
[发现]尝试连接到API服务器“ 192.168.2.2:6443”
[发现]创建集群信息发现客户端，从“ https://192.168.2.2：6443 ”请求信息
[发现]再次从“ https://192.168.2.2：6443 ”请求信息以针对固定的公钥验证TLS
[发现]群集信息签名和内容有效，并且TLS证书针对固定根进行了验证，将使用API​​服务器“ 192.168.2.2:6443”
[发现]与API服务器“ 192.168.2.2:6443”成功建立连接
[kubelet]从kube-system命名空间中的“ kubelet-config-1.11” ConfigMap下载kubelet的配置
[kubelet]将kubelet配置写入文件“ /var/lib/kubelet/config.yaml”
[kubelet]将带有标志的kubelet环境文件写入文件“ /var/lib/kubelet/kubeadm-flags.env”
[预检]激活kubelet服务
[tlsbootstrap]等待kubelet执行TLS Bootstrap ...
[kubelet检查]似乎kubelet不在运行或运行状况良好。
[kubelet检查]似乎kubelet不在运行或运行状况良好。
[kubelet检查]似乎kubelet不在运行或运行状况良好。
[kubelet检查]似乎kubelet不在运行或运行状况良好。
[kubelet检查]似乎kubelet不在运行或运行状况良好。
不幸的是，发生了一个错误：
等待条件超时

该错误很可能是由以下原因引起的：
-kubelet没有运行
-由于节点以某种方式错误的配置，kubelet不健康（禁用了必需的cgroups）

如果您使用的是systemd驱动的系统，则可以尝试使用以下命令对错误进行故障排除：
-'systemctl status kubelet'
-'journalctl -xeu kubelet'
等待情况超时`

在这段时间内，我的节点上没有显示任何docker容器。

[警告要求IPVSKernelModulesAvailable]：

题外话，我们在这里谈论这个：
https://github.com/kubernetes/kubeadm/issues/975

此外，既然我的主服务器正在运行，我无法向其添加节点，这似乎是另一个超时问题。
[kubelet-check]等于'curl -sSL http：// localhost ：10248 / healthz'的HTTP调用失败，并显示以下错误：Get http：// localhost ：10248 / healthz：拨打tcp [:: 1]：10248：connect ： 连接被拒绝。

kubelet无法启动。 最好看看kubelet日志。

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

liveness探针应配置为可配置，但我们可能应该在kubeadm配置中讨论实现此目的的最佳方法。

我认为这些是使用的值，因此，如果您自己构建kubeadm，请尝试使用：
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
但请注意，这会增加所有控制平面组件的超时。

编辑：我显然太愚蠢，无法正确格式化Github中的注释：-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

请注意，这些日志不会显示任何错误。

是的，但这是我认为的问题的一部分。 我在任何地方都找不到[ERROR]的结论行。 那真是让我非常沮丧:-)

无论如何，感谢您格式化我的烂摊子:-D

那么下一步将是什么好呢？

那么下一步将是什么好呢？

如前所述：

liveness探针应配置为可配置，但我们可能应该在kubeadm配置中讨论实现此目的的最佳方法。

我认为这些是使用的值，因此，如果您自己构建kubeadm，请尝试使用：
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
但请注意，这会增加所有控制平面组件的超时。

我不是一个人建造kubeadm，而是从apt.kubernetes.io中通过apt提取它。 我没有任何东西可以像在我的任何机器上使用的构建管道一样远（尚未修补过）。 我希望在加入集群时像创建该集群时一样可以修改类似的文件，但是似乎这些值已硬编码到utils.go中：-|

您可以尝试此解决方案，但这很棘手：
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

问题是，这需要进行配置更改，我不认为它可以包含在1.11.X版本中（但我们可以尝试）。 它也必须首先讨论。

这就是我在注释中已经告诉我主服务器已启动的操作（这是我的watch -n 1.0命令正在执行的操作）。 现在正在发生的事情是kubeadm联接不起作用，据我所知，kubeadm联接没有放置yaml文件供我在任何地方打补丁：-/

您可能遇到另一个问题。 很难说。

这些是使用的值，因此，如果您自己构建kubeadm，请尝试使用：
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

因此，我注意到InitialDelaySeconds超时是一年后的_still_ 15s，我不明白为什么它没有增加到实际上代表现实的程度。 此错误报告有任何作用吗？ 我最初并没有提议自己更改PR的数量，因为我认为已经在kubeadm圈子中的人可以完成该任务并在几分钟内合并，但是如果“缺少PR”很高兴，我会这样做。我们没有前进的唯一原因。

我觉得每个人都在尝试声明无效的原始错误报告的原因（也许我们不应该支持rPi2，也许我们应该使initialdelay可配置，也许我们应该预拉映像或其他不相关的更改，也许快速的不透明超时失败比缓慢的成功是更好的UX），而不是仅仅增加initialDelay超时以反映我们的二进制文件清楚显示的实际initialDelay，然后继续进行其他值得讨论的事情。

因此，我注意到此处的InitialDelaySeconds超时仍然是一年后的15s，而且我不明白为什么它没有增加到实际上代表现实的程度。 此错误报告有任何作用吗？ 我最初并没有提议自己更改PR的数量，因为我认为已经在kubeadm圈子中的人可以完成该任务并在几分钟内合并，但是如果“缺少PR”很高兴，我会这样做。我们没有前进的唯一原因。

由于整个问题对我来说都是新问题，因此我无法回答您的问题，但是我们可以尝试在本周进行讨论。 请注意，kubeadm背后的团队是一个有大目标的小团队，通常没有人可以从事某项任务，例如这样的任务。

我觉得每个人都在尝试声明无效的原始错误报告的原因（也许我们不应该支持rPi2，也许我们应该使initialdelay可配置，也许我们应该预拉映像或其他不相关的更改，也许快速的不透明超时失败比缓慢的成功是更好的UX），而不是仅仅增加initialDelay超时以反映我们的二进制文件清楚显示的实际initialDelay，然后继续进行其他值得讨论的事情。

是的，该线程中已经讨论了选项。 这是选择正确的选项并进行实施的问题。

我实际上认为，默认情况下将“无超时”设置为整个过程设置超时是有意义的（如本问题前面提到的那样）。

原因是我能想到的大多数用例实际上并不关心某个特定的步骤是否在X秒内执行，因为在分布式系统中关心的所有事情都是最终的一致性（为了节省成本而将另一个节点缓存起来）而不是摆弄设置）。

但是，作为一个临时解决方案，只需从配置文件中读取kubeadm连接的超时设置就足够了，就像kubeadm init东西所做的那样，这样我们的机上飞行超时替换就可以正常工作了。 这是骇客，别无所求-但是可怕的骇客总比没有解决办法要好。

我个人反对尝试“猜测”合理的超时，因为猜测总是错误的，在这种情况下并没有真正的目的（因为避免超时的应对策略只是在纾困），并且会使错误的再现成为痛苦。因为两个相同的系统可能出于各种原因而开始表现出不同。

@anguslees @DJGummikuh在最近的SIG会议上，我们进行了讨论。

这是一个棘手的问题，但是下面是一些随机的音符。

笔记：

• 我们中的一些人有很多经验，他们说这闻起来像是使apiserver启动停止的竞赛条件。 它不应该花那么长时间。 这可能是ARM vs GOLANG的事情。
• 我已经问过SIG API机械公司，但是对建议的活度探测值以及他们是否怀疑这里存在其他类型的问题均未得到任何回应。
• 我们已经同意，公开配置选项，环境变量或命令行参数对于kubeadm是个坏主意。 其背后的原因是我们不想向用户公开可能具有完全任意含义的参数。
• 团队中没有人在慢速计算机（例如，慢速VM）上见过这样的问题，这意味着这可能与RPi有关，并且整个说法都归因于“慢速”硬件是无效的。
• 看一下这个： https :
• 有人在https://www.scaleway.com/上看到过问题吗，根据该线程中的理论，它也应该在那里发生吗？
• 作为底线，我们已经讨论了对kubeadm硬编码较大的超时/延迟值并不重要，因此，如果有人要为此提交PR，请继续。 （ @anguslees ）

看一下这个：kubernetes / kubernetes＃64357用户根本没有报告活动探测问题。 知道为什么吗？

不，它现在在我的硬件上甚至似乎还不能真正再现。 由于加入节点的令牌已用完，所以我认为“到底是什么”和kubeadm重置了群集主节点，并尝试重新初始化它（运行了监视解决方法）-现在即使有了该解决方法，我也无法继续进行操作我的Raspberry Pi 3+上的大师。 我什至将配置的超时从180秒增加到300秒，没有任何差异。 因此，我喜欢将其作为比赛条件的想法。
不过，我仍然欢迎您提出要求延长超时时间的建议。 不会给您带来太大的痛苦，并且会给pi（这是一个缓慢的硬件，我认为我们都可以同意:-)）。

apiserver中有关ARM64的相关问题：
https://github.com/kubernetes/kubernetes/issues/64649

周末对我的（仍然失败的:-(）Pi Cluster进行了更多研究。

我重新安装了一个节点，因为我怀疑在不重新安装操作系统的情况下从Pi 2升级到Pi 3+可能会引起一些问题。 事实并非如此，问题与全新的OS相同。
另外，我花了更多的时间来尝试编译kubernetes并对此进行了测试。 同样，这并没有真正产生任何结果。
我能够启动主服务器（使用我的监视解决方法来修补配置文件），但是将群集与第二个节点一起加入只是永远不会成功。

拥有一些有用的日志输出来解决此问题真的很不错。 但是我对kubernetes组件如何交互以了解在何处添加行的理解还不够。

有人要挑战吗？ ^^

这确实是kubeadm以外的问题...

api机械人员没有看我对这个问题的评论请求，因此，除非为此已记录了工单，否则，应该在kubernetes/kubernetes回购中记录一个工单并标记/sig api-machinery 。

拥有一些有用的日志输出来解决此问题真的很不错。 但是我对kubernetes组件如何交互以了解在何处添加行的理解还不够。

首先，可以在systemd插入文件中为kubelet启用--v 4 ，这将告诉GLOG记录器启用较高的详细程度。
使用kubeadm配置，还可以对控制平面组件执行相同的操作：
https://kubernetes.io/docs/setup/independent/control-plane-flags/

这解决了我的Raspberry Pi 3集群上的问题： https :

@joejulian不错，我设法打了补丁，现在我的集群也启动了。 最后，经过数周的痛苦！ 谢谢 ：-）

@joejulian感谢您的调查！
可以在https://github.com/kubernetes/kubernetes/pull/66264中找到潜在的修复程序

关闭，直至另行通知。

/关闭

有没有办法在kubeadm初始化文件中传递此类设置？ 也许在apiServerExtraArgs ？ 看着文件打补丁很痛苦，有点难以自动化。

那没有。 也许这将是一个很好的功能。

以后的更新添加了更多要检查的内容，我提供的PR延长的超时时间不再足够。 我已放弃管理超时。 对我来说，解决方案是使用ecdsa证书。

另外，与Raspberry Pi相比，包括etcd在内的控制器服务现在占用的内存更多，而不是Raspberry Pi承载控制平面的节点数量加倍，我已经升级到Rock64s。

对不起，双关语，但自那时以来，我的控制飞机一直坚如磐石。

我一直在尝试在Raspberry Pi 3+上进行安装，并且可以确认安装确实失败。 在上面列出的kube-apiserver.yaml上使用“监视”技巧似乎确实可以正常工作……但是仅当我将initialDelaySeconds更改为360时。在我的计算机上建议的180值似乎是微不足道的。

就在事情变得太容易的时候，kubeadm现在抱怨不支持Docker（18.09）版本。 快速恢复到18.06可解决此问题。

在kubeadm 1.13中，我们在ClusterConfig-> ApiServer下添加了可控制api服务器超时的配置标志。
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

可以控制api服务器超时的ClusterConfig-> ApiServer下的配置标志。

我在代码库中搜索TimeoutForControlPlane ，我认为这默认为4分钟，并且仅用于kubeadm自身等待apiserver正常运行所使用的延迟。 特别是，它不会更改kubelet本身使用的apiserver livenessprobe。 那是对的吗？

我认为在有关此问题的讨论中，没有出现任何反驳的论点。 我们有理由不只是增加livenessProbe initialDelaySeconds并继续处理其他问题吗？

顺便说一句：据我快速阅读所见， TimeoutForControlPlane还没有考虑到导致apiserver启动延迟增加的其他非失败原因，例如拉多个图像时出现拥塞，或其他超时+重试循环迭代，而一切都在初始安装时收敛（超时+重试是k8s设计模式...有时在加载的系统上会发生这种情况，这是预期的并且很好）。 我个人觉得对于需要快速失败的不耐烦的交互式用户来说，4分钟既太长，又对准备等待更长的等待成功的已加载/慢速/自动化系统上的安装过程来说太短了。 这是怎么达到的，我们可以默认为5分钟吗？ 我们可以一直重试直到SIGINT吗？ 为什么我们在内部施加一个人造的挂钟截止日期，而不是从调用环境中继承它？

Afaics TimeoutForControlPlane只是公开了一个致命的内部截止日期作为参数，而唯一的目标用户体验只是增加该参数，直到从未达到截止日期。 另外，我们可以_not_首先强加任意致命的内部截止日期...

这是一个很好的观点，我全心全意地同意。

特别是，它不会更改kubelet本身使用的apiserver livenessprobe。 那是对的吗？

是的，还没有计划从kubeadm修改活动度探针。

这个rpi问题在sig-cluster-lifecyle会议上被认为是“不应该发生的事情”，“似乎就像在kubelet中的竞赛条件”，“为什么它仅在rpi而不是在其他较慢的设备上发生”。 我不得不承认我自己还没有测试过慢速设备。

即，已达成协议，可以增加该价值：
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
这不是一个很好的解决方案，它似乎是另一个错误的解决方法。

这是怎么达到的，我们可以默认为5分钟吗？

超时时间是30分钟，而不是4分钟，因为在1.11之前考虑了拉取图像。
如果您对4分钟和5分钟有自己的见解，那么在主题上有强项的，轮廓分明的PR可能会在1.14中取得成功。

这个rpi问题在sig-cluster-lifecyle会议上被认为是“不应该发生的事情”，“似乎就像在kubelet中的竞赛条件”，“为什么它仅在rpi而不是在其他较慢的设备上发生”。

这些都是在其他地方继续寻找另一个错误的原因，但这些都不是不增加initialDelaySeconds的原因。 增加initialDelaySeconds实际上有不利之处吗？

从另一个方向解决这个问题，如果我们知道我们在kubernetes的其他地方存在一个可以在kubeadm中使用的解决方法的问题-kubeadm的作用是“坚持到底”并产生已知的错误结果吗？ 这似乎与我们希望人们实际用于实际部署的工具这一目标背道而驰。 到目前为止，我无法在群集上使用kubeadm而不对其进行修补以增加超时（尽管一年多前通过修补程序进行了报告），这让我很难过。

（很抱歉让我对这个问题感到有些沮丧，这很抱歉）

如果您对4分钟和5分钟有意见

叹。 我试图在kubeadm中提出_no_超时的理由，但是我还没有找到一种有说服力的方式表达该建议的方法（例如，请参阅此问题以及此问题中其他失败的尝试）：

这些都是在其他地方继续寻找另一个错误的原因，但是这些都不是不增加initialDelaySeconds的原因。 增加initialDelaySeconds实际上有不利之处吗？

这是一个很小的更改，但由于不适用此问题，因此同意不增加此费用，因为它也适用于不存在此问题的系统。

从另一个方向解决这个问题，如果我们知道我们在kubernetes的其他地方存在一个可以在kubeadm中使用的解决方法的问题-kubeadm的作用是“坚持到底”并产生已知的错误结果吗？ 这似乎与我们希望人们实际用于实际部署的工具这一目标背道而驰。

面对最终用户是kubeadm的目标，这是事实。
但同样，这只是rpis的报告，实际错误应升级为sig-api-machinery（api服务器）和sig-node（kubelet），并可能在kubeadm之外复制。

到目前为止，我无法在群集上使用kubeadm而不对其进行修补以增加超时（尽管一年多前通过修补程序进行了报告），这让我很难过。

您不必修补kubeadm，而可以修补清单文件。
kubeadm 1.13从初始化阶段毕业到顶级命令-例如kubeadm init phase [phase-name]
主要是因为用户希望对控制平面节点的创建方式进行自定义控制。

如果您执行kubeadm init --help ，则会显示执行阶段的顺序。

因此您可以将kubeadm init命令分解为适当的阶段，对控制平面组件使用自定义清单，然后跳过control-plane阶段。 现在还有--skip-phases 。

您已经可以在1.11和1.12中做到这一点，但是不太直接。

因为它也适用于不解决问题的系统。

所以..那是怎么回事？ 我们会始终修复仅在某些系统上触发的错误。 在超时的任何地方，我们都需要针对有史以来最慢的系统进行调整，而不仅仅是环境的某些子集，对吗？

另一个角度是，作为运维人员，我对过载情况下的级联失败感到恐惧，尤其是对于apiserver本身。 在狂热中，仅当事情明显失败时才触发活动探针超时，而不仅仅是在偏离某人“正常”的想法拥有较小的initialDelaySeconds没有任何好处。 kubeadm的默认livenessprobe在所有平台上都是不必要的。

抱歉，我一直重复着同样的观点，但是从理论上讲，扩展initialDelaySeconds有很强的实践和理论上的理由，而我只是不理解使它变小的相反论点:(

目前不太可能为此添加kubeadm配置选项。

我试图解释这已经可以在1.13中使用3个命令来实现：

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

我不想使用任何选项，我想说的是将当前的固定值（15）更改为其他固定值（以上建议为360）。

..但是我不想再拖下去了。 显然，决定是坚持当前值，所以我将退出失败的行列。 谢谢你的耐心 ：）

@ neolit123组合看起来很棒-比我记录的要容易得多-必须等待控制平面设置然后在另一个终端中快速运行sed。 https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

我将测试说明，并期待更新指南。

@ neolit123这是我在RPi3 B +上使用上面的配置得到的

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

在kubeadm-config.yaml中-192.168.0.26是指向192.168.0.110的LB

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

即使没有外部config / lb IP，我也能得到相同的结果。

亚历克斯

我一直在敦促人们使用kubeadm一段时间，甚至学校都希望在其pi集群上运行它。 虽然我知道不想使代码库复杂化，但我认为对于您的用户群来说，支持在这些小型设备上运行可能是一件好事。 它允许年轻人在廉价的硬件上踢Kubernetes轮胎，否则可能不会。 上面的变通办法虽然有效，但对于此用例而言要困难得多。

妥协呢？ 而不是使其可配置，而是添加一个简单的试探法，说如果不是x86_64，则将默认超时设置得更高？

[kubeconfig]编写“ admin.conf” kubeconfig文件
[kubeconfig]编写“ kubelet.conf” kubeconfig文件
紧急情况：运行时错误：无效的内存地址或nil指针取消引用
[信号SIGSEGV：细分违规代码= 0x1 addr = 0x8 pc = 0xaa7204]

奇怪的是， admin.conf是机器生成的，应该包含有效的Config类型，并带有指向上下文的current-context 。

恐慌来自这一行：
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

我看到与上面的：point_up：完全相同的错误

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

以下脚本确实使用kubeadm版本1.12和1.13（大多数情况下）为我解决了此问题

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

我在相同的情况下，使用@ neolit123建议的方法遇到相同的错误。
我无法通过@stephenmoloney运行脚本，我对bash脚本并不十分熟悉，这可能是我的错。

所以我将脚本移植到python（默认情况下安装在Raspbian上，因此不需要额外的依赖项），以防有人感兴趣：

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

运行它： sudo python however_you_name_the_file.py
感谢您为我指出解决方案@stephenmoloney和@ neolit123 ！

你好！ 这个问题很有帮助

我找到了一种使用kustomize解决此问题的理想方法

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom