Kubeadm: livenessprobeが攻撃的すぎるため、apiserverが起動に失敗する

現在、コントロールプレーンポッドのInitialDelaySecondsとTimeoutSeconds両方を15に設定しているようです。これは、 kube-up.shと同じです。 すべての画像が一度にプルされるため、最初の起動が遅いことは理解していますが、すべての画像がプルされた後、起動後、apiserverが/healthzチェックに応答するのにどのくらい時間がかかりますか？

間違いなく、これらの値の両方を微調整して、低電力のマシンに対応する必要があります。

開始すると、<< 15秒でヘルスチェックに応答できます。これは、実際には、apiserverがexec（）と実際にafaicsを提供する準備ができている間に行うすべての追加作業です。

ああ、Dockerのプル時間はInitialDelaySeconds afaicsにはカウントされません（良い）。 遅いネットワークリンク上でより大きな（一般的なubuntu）イメージを使用する他の例では、プルに数分かかる場合がありますが、プルが完了してDockerの実行が開始されるまで、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

（私は通常、古い/再起動ループのapiserverコンテナーを手動でdocker killしますが、静的ポッドで自動的にクリーンアップされるかどうかはわかりません）

@anguslees素晴らしい！ 確認ありがとうございます。

私の場合はラズベリーパイ3でも、この問題が発生したことを確認できます。180に変更すると修正されましたが、私の場合は次のように問題が発生したため、問題＃106も発生したと思います。

9月1日10：47：30raspberrypi kubelet [6053]：W0901 10：47：30.020409 6053 kubelet.go：1596]ミラーポッドの削除 "kube-apiserver-raspberrypi_kube-system（7c03df63-8efa-1
1e7-ae86-b827ebdd4b52）」古いので

kubeletプロセスを手動でHUPして、元の状態に戻す必要がありました。

私もこれを持っていたことを確認でき、私の正気を救ってくれてありがとうと言いたいと思いました。 私はRaspberryPi 2Bを持っていて、先月は初期化フェーズで立ち往生していました。 コントロールプレーンを待ち始めたら、そのワンライナーを実行した後、私はそれを前進させました。

この問題はkubeadm v1.8.0でも引き続き存在し、 kubeadm自体のほとんどのアクションで1分のタイムアウトが発生するため、さらに悪化します。 1分のタイムアウトは任意に選択されているようですが、残念ながらa）問題に飛び込んでデバッグ/回避するのに十分な時間がありません（例：上記のsed hack）、b）apiserverが起動するのに十分な時間（〜私にとっては90年代）、initialDelaySecondsが拡張された場合でも、c） kubeadm afaicsをハッキング/再構築せずに増やすことはできません。

タイムアウトは、特に複雑な結果整合性のあるシステムでは、そうでなければ正しいロジックを壊します。「理由だけで」タイムアウトを追加しないでください:(私の理解では、 kubeadmは、大規模な展開システムが依存できるビルディングブロックを意味します。したがって、kubeadm自体からすべてのタイムアウトを削除することを大胆に提案し（さまざまなフェーズは永久に再試行し続ける必要があります）、上位レベルのプロセスに依存して、上位レベルのコンテキストで適切な場合は全体的なタイムアウトを追加します。単純/直接の使用例では、 「ユーザーが諦めて^ cを押すまで再試行する」という意味です。そのようなPRは受け入れられますか？

@anguslees以前は「永遠に待つ」動作をしていました。 しかし、それはUX PoVからは非常に最適ではなかったため、タイムアウトが発生しました。 必要に応じて、これらのタイムアウトの一部を増やしたい場合があります。

問題は、kubeadmの使用法が2つあることです。 どちらも、kubeadmをインタラクティブに入力しているユーザーがいて、何かが起こっているかどうかを知りたいと思っています。

..では、ここではどの方向に進むのでしょうか。 現在、私はkubeadmフォークを使用しており、タイムアウトが10倍になっています。ある時点で、標準のkubeadmバイナリの使用に戻ることができると信じています。

@anguslees以前は「永遠に待つ」動作をしていました。 しかし、それはUX PoVからは非常に最適ではなかったため、タイムアウトが発生しました。 必要に応じて、これらのタイムアウトの一部を増やしたい場合があります。

それらを構成可能にするのはどうですか？ それらすべてを所有する単一のオプションを持つことは理にかなっていますか？

/ priorityimportant-まもなく

それらすべてを所有する単一のオプションを持つことは理にかなっていますか？

おそらく、またはすべてのタイムアウトを乗算するためのある種の「重み」...それ以外の場合は、20種類のタイムアウトフラグを使用して構成地獄に入ります:)

ラズベリーパイ2クラスターでkubeadmアップグレードを使用して同じ問題が発生しました。 積極的なタイムアウトが原因でアップグレードが失敗します。 マニフェストの活性プローブ設定を変更しても効果はありません。 何か案は？

kubeadmコードベースの下位レベル全体に任意のタイムアウトを振りかけるのではなく、kubeadmタイムアウトが呼び出しコンテキスト（またはより高度なエラー回復戦略の一部）から継承されるパターンを提案します。

最も単純な形式では、これはkubeadmからすべてのタイムアウトを削除し、それらを1つの全体的な「xx分間実行し、終了していない場合は中止する」グローバルタイマーに置き換えるのとほぼ同じように動作します（kubeadmはエラーの方法で多くのことを実行できないため）ただ長く待つ以外の回復）。

元のマニフェストlivenessProbeタイムアウトの場合、これは文字通りワンライナーパッチです。 残念ながら、「通常の==エラーからの逸脱」の誤謬がkubeadmコードベース全体に広がっているため、livenessProbeだけを修正するだけではもはや十分ではありません。 文化的認識を変えるのは難しいので、ラズベリーパイにインストールしたい人がいれば、その間に私はここにkubeadmのフォークバージョンを持っていmake cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/armビルド）

@angusleesパッチを適用したkubeadmのコンパイル済み1.9.4バージョンはありますか？ パッチを適用したバージョンのコンパイルに問題があります。

kubeadmがフラグの背後でこの動​​作をしていないことに驚いています。 おそらくPRは順調ですか？

/ assign @liztio

そのため、これに影響を与える可能性のある2つの問題を1.11で修正しました。

1. 起動する前にetcdイメージをプリプルします。
2. 起動時の競合状態チェックを修正しました。
   ..。

これがラズベリーパイギアでのみ発生している場合は、最小公分母を修飾する何らかの方法が必要です。

サポートを計画している最低のターゲットプラットフォームは何ですか？

Raspberry Pi 2は、Kubernetesを実行したい（s）最も低いプラットフォームだと思います。 ハードウェアを利用しないQEMUを

PiのI / Oが非常に遅いことを考えると、すべての画像を事前にプルすることはすでに大いに役立ちますが、実際のタイムアウトを決定するためにいくつかの実際のテストが必要になります。

芋ラズベリーPI2がサポートに古すぎる- http://socialcompare.com/en/comparison/raspberrypi-models-comparison 、2015年に出てきました。

>= 3はより合理的なimoのようです。

画像を事前にプルしても効果はありません。 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を起動した場合、最初の起動時にポイントの測定を試みることができます。 たぶん、最初の初期化の測定に適合したタイムアウトのために、後の段階で構成を変更します。 また、ログを確認するhealtzチェックによってapiserverがキックされていることを確認するのは困難です。少なくとも、問題を認識するために、より適切なログを取得できる可能性があります。 活性プローブが問題であることに気付くのにかなりの時間がかかりました。 私は初心者であることに言及する必要があります。それは、少なくともkubeadmの失敗出力のどこかで言及するのに役立ちます。

RaspberryPi 3は、事前にプルされた画像を使用した場合でも、この問題を示しています。 APIサーバーは、ページを提供できる場所に到達するのに2〜3分かかります...

これを構成できると便利です。現在、kubeadmの実行中にバックグラウンドでYAMLファイルにモンキーパッチを適用しているからです。

@carlosedpアップグレード中に行うことは、apiserverの起動中にkubeletを削除することです。 これは一種のハッキーですが、apiserverが起動するまでヘルスチェックが実行されないようにします。

しかし、正直なところ、 kubeadm upgradeとARMは、私の経験ではそれほどうまく機能しません...

@ brendandburns1.9までは完全に機能しました。 1.8クラスターを問題なくデプロイしてから、1.9に2回アップグレードしました。 この問題を引き起こすために1.10で何が変更されたのかはわかりません。

タイムアウトが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分くらいだと思いますが、正しく測定する方法がわかりません。

さらに、マスターが操作可能になったので、別のタイムアウトの問題と思われるノードの追加に失敗しました。
`[プリフライト]プリフライトチェックの実行
[警告RequiredIPVSKernelModulesAvailable]：次の必須カーネルモジュールがロードされていないため、IPVSプロキシは使用されません：[ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs]または組み込みカーネルipvsサポートなし：map [ip_vs_rr：{} ip_vs_wrr：{} ip_vs_ 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]カーネル構成の検証
[警告SystemVerification]：dockerのバージョンが最近検証されたバージョンよりも大きくなっています。 Dockerバージョン：18.03.1-ce。 最大検証バージョン：17.03
[発見] APIサーバー「192.168.2.2:6443」に接続しようとしています
[検出]「 https://192.168.2.2:6443 」から情報を要求するクラスター情報検出クライアントを作成しました
[発見]ピン留めされた公開鍵に対してTLSを検証するために、「 https://192.168.2.2:6443 」からの情報を再度要求する
[検出]クラスター情報の署名と内容は有効であり、TLS証明書は固定されたルートに対して検証され、APIサーバー「192.168.2.2:6443」を使用します
[発見] APIサーバー「192.168.2.2:6443」との接続が正常に確立されました
[kubelet] kube-system名前空間の「kubelet-config-1.11」ConfigMapからkubeletの構成をダウンロードしています
[kubelet]ファイル「/var/lib/kubelet/config.yaml」へのkubelet設定の書き込み
[kubelet]フラグ付きのkubelet環境ファイルをファイル「/var/lib/kubelet/kubeadm-flags.env」に書き込む
【プリフライト】kubeletサービスの有効化
[tlsbootstrap] kubeletがTLSブートストラップを実行するのを待っています...
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
残念ながら、エラーが発生しました：
状態を待ってタイムアウトしました

このエラーの原因は次のとおりです。
-kubeletが実行されていません
-何らかの方法でノードの構成が誤っているため、kubeletが異常です（必要なcgroupが無効になっています）

systemdを利用したシステムを使用している場合は、次のコマンドを使用してエラーのトラブルシューティングを試みることができます。
-'systemctl status kubelet '
-'journalctl -xeu kubelet '
状態を待つためにタイムアウトしました `

この間、ノードにDockerコンテナが1つも表示されません。

[警告RequiredIPVSKernelModulesAvailable]：

オフトピック、私たちはここでこれについて話している：
https://github.com/kubernetes/kubeadm/issues/975

さらに、マスターが操作可能になったので、別のタイムアウトの問題と思われるノードの追加に失敗しました。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp [:: 1]：10248：connect ： 接続拒否。

kubeletを起動できませんでした。 kubeletログをよく見てください。

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

活性プローブは構成可能にする必要がありますが、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

では、次の良いステップは何でしょうか？

では、次の良いステップは何でしょうか？

前に述べたように：

活性プローブは構成可能にする必要がありますが、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 joinが機能しないことです。そして、私が見る限り、kubeadm joinは、パッチを適用するためのyamlファイルをどこにも配置しません：-/

別の問題が発生している可能性があります。 言いにくい。

これらは使用される値なので、kubeadmを自分で構築している場合は、次のことを試してみてください。
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

したがって、ここでのInitialDelaySecondsタイムアウトは1年後の_まだ_ 15秒であり、実際に現実を表すものに増加されていない理由がわかりません。 このバグレポートは何か目的を果たしていますか？ すでにkubeadmの内輪にいる誰かが数分でそれを成し遂げてマージできると感じたので、私は最初にこの番号を自分で変更するだけのPRを提案しませんでしたが、「PRの欠如」があれば喜んでそうします私たちが前進しなかった唯一の理由。

誰もが元のバグレポートを無効と宣言する理由を考え出そうとしているように感じます（おそらくrPi2をサポートすべきではなく、initialdelayを構成可能にする必要があり、画像やその他の無関係な変更を事前にプルする必要があります。速い不透明なタイムアウトの失敗は、遅い成功よりも優れたUXです）、バイナリが明確に示す実際のinitialDelayを反映するために、initialDelayタイムアウトを増やすだけでなく、実際に議論に値する他の何かに移ります。

したがって、ここでのInitialDelaySecondsタイムアウトはまだ1年後の15秒であり、実際に現実を表すものに増加されていない理由がわかりません。 このバグレポートは何か目的を果たしていますか？ すでにkubeadmの内輪にいる誰かが数分でそれを成し遂げてマージできると感じたので、私は最初にこの番号を自分で変更するだけのPRを提案しませんでしたが、「PRの欠如」があれば喜んでそうします私たちが前進しなかった唯一の理由。

問題全体が私にとって新しいので、私はあなたの質問に答えることができませんが、今週それについて話すことを試みることができます。 kubeadmの背後にあるチームは大きな目標を持つ小さなチームであり、このような特定のタスクに取り組む人がいない場合が多いことに注意してください。

誰もが元のバグレポートを無効と宣言する理由を考え出そうとしているように感じます（おそらくrPi2をサポートすべきではなく、initialdelayを構成可能にする必要があり、画像やその他の無関係な変更を事前にプルする必要があります。速い不透明なタイムアウトの失敗は、遅い成功よりも優れたUXです）、バイナリが明確に示す実際のinitialDelayを反映するために、initialDelayタイムアウトを増やすだけでなく、実際に議論に値する他の何かに移ります。

はい、オプションについてはこのスレッドですでに説明しています。 適切なオプションを選択して実装を行うことが重要です。

私は実際、プロセス全体のタイムアウトを設定するオプションを使用して、デフォルトで「タイムアウトなし」に設定するのが理にかなっていると信じています（この号の前半で提案されたように）。

理由は、分散システムで気になるのは結果整合性だけなので、特定のステップがX秒で実行されるかどうかは、私が考えることができるほとんどのユースケースは実際には気にしないからです（万が一の場合に備えて別のノードをスプールする方が安い）設定をいじるよりも）。

ただし、暫定的な解決策として、kubeadm initと同じように、構成ファイルからkubeadm joinのタイムアウト設定を実際に読み取って、実行中のタイムアウト置換によるハックが機能するようにするだけで十分です。 これはハックです。違いはないと思いますが、回避策がまったくないよりも、ひどいハックの方が優れています。

私は個人的に、適切なタイムアウトを「推測」しようとすることに反対しています。推測は常に間違っている可能性があり、この場合は実際には目的を果たさないため（タイムアウトの経過に対する対処戦略は単純に解決されるため）、エラーの再現が苦痛になります。 2つの同一のシステムが無数の理由で異なる動作を開始する可能性があるため、お尻。

@ anguslees @ DJGummikuh最近のSIGミーティングでそれについて話しました。

これは厄介な問題ですが、以下にいくつかのランダムなメモがあります。

ノート：

• 一部の人々は多くの経験を持っており、これはapiserverの開始を停止させる競合状態のようなにおいがすると言っています。 それほど長くはかからないはずです。 これは、ARMとGOLANGの違いである可能性があります。
• SIG API Machineryに質問しましたが、提案された活性プローブ値と、ここで別のタイプの問題が疑われる場合は応答がありません。
• 構成オプション、環境変数、またはコマンドラインパラメーターを公開することは、kubeadmにとって悪い考えであることに同意しました。 その背後にある理由は、ユーザーにとって完全に恣意的な意味を持つ可能性のあるパラメーターを公開したくないということです。
• チームの誰も、遅いマシン（遅いVMなど）でこのような問題を見たことがありません。これは、これがRPiに関連している可能性があり、これが「遅い」ハードウェアによるものであるという議論全体が無効であることを意味します。
• これを見てください： //github.com/kubernetes/kubernetes/issues/64357ユーザーは活性プローブの問題をまったく報告していません。 それはなぜですか？
• https://www.scaleway.com/のような問題を見た人はいますか？このスレッドの理論によれば、そこでも問題が発生するはずです。
• 結論として、より大きなタイムアウト/遅延値をハードコーディングすることはkubeadmにとってそれほど重要ではないことを説明しました。したがって、誰かがそのためのPRを提出したい場合は、先に進んでください。 （ @anguslees ）

これを見てください：kubernetes / kubernetes＃64357ユーザーは活性プローブの問題をまったく報告していません。 それはなぜですか？

いいえ、今では私のハードウェアで実際に再現できるようには見えません。 ノードに参加するためのトークンが経過したので、「一体何が」とkubeadmがクラスターマスターをリセットし、それを再初期化しようとしました（そのウォッチの回避策が実行されている）-今ではその回避策を使用してもプルアップできません私のラズベリーパイ3+のマスター。 設定されたタイムアウトを180秒から300秒に変更することなく増やしました。 ですから、これが競合状態であるという考えが好きです。
それでも、リクエストのタイムアウトを長くするという提案を歓迎します。 それほど傷つくことはなく、pi（これは遅いハードウェアです。私たち全員がそれに同意できると思います:-)）にもう少し呼吸スペースを与えます。

apiserverのARM64に関連する問題：
https://github.com/kubernetes/kubernetes/issues/64649

週末に私の（まだ失敗している:-(）PiClusterでさらに調査を行いました。

OSを再インストールせずにPi2からPi3 +に更新すると問題が発生する可能性があるため、ノードの1つを再インストールしました。 これは当てはまりません。問題は新しいOSでも同じです。
さらに、タイムアウトを増やしてkubernetesをコンパイルするように努力し、それをテストしました。 また、これは実際には何の結果ももたらしませんでした。
マスターを起動することはできましたが（構成ファイルにパッチを適用するためのウォッチの回避策を使用して）、2番目のノードでクラスターに参加することはできませんでした。

この問題を突き止めるために、いくつかの追加の有用なログ出力があると本当に便利です。 ただし、kubernetesコンポーネントがどのように相互作用して行を追加するかを知る方法については十分に理解していません。

挑戦する人はいますか？ ^^

これは本当にkubeadmの外の問題です...

このすでに誰かが1つにログインする必要がありますするための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 nice私はなんとかそれをパッチすることができました、そして今私のクラスターも起動しています。 最後に、数週間の苦痛の後！ ありがとうございました ：-）

@joejulian調査してくれてありがとう！
潜在的な修正はhttps://github.com/kubernetes/kubernetes/pull/66264で見つけることができ

追って通知があるまで閉鎖。

/閉じる

kubeadm initファイルでそのような設定を渡す方法はありますか？ 多分apiServerExtraArgs ？ ファイルにパッチを適用するためにファイルを監視するのは面倒で、自動化するのはちょっと難しいです。

存在しない。 おそらくそれは追加するのに良い機能でしょう。

その後の更新により、チェックするものがさらに追加され、PRが提供した延長タイムアウトではもはや十分ではありませんでした。 タイムアウトの管理をあきらめました。 私にとっての解決策は、ecdsa証明書を使用することでした。

さらに、etcdを含むコントローラーサービスは、Raspberry Piよりも多くのRAMを使用するため、コントロールプレーンをホストするノードの数を2倍にするのではなく、Rock64にアップグレードしました。

駄洒落すみませんが、それ以来、私のコントロールプレーンは堅実です。

Raspberry Pi 3+にインストールしようとしていますが、インストールが実際に失敗することを確認できます。 上記のkube-apiserver.yamlで「watch」トリックを使用すると、一貫して機能するように見えますが、initialDelaySecondsを360に変更した場合に限ります。推奨値の180は、私のマシンでは限界のようです。

簡単になりすぎると、kubeadmはDockerのバージョン（18.09）がサポートされていないと不平を言っています。 18.06にすばやく戻すと、問題が修正されました。

kubeadm 1.13では、APIサーバーのタイムアウトを制御できるClusterConfig-> ApiServerの下に構成フラグを追加しています。
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

ClusterConfig-> ApiServerの下にある構成フラグで、APIサーバーのタイムアウトを制御できます。

コードベースでTimeoutForControlPlane検索すると、これはデフォルトで4分に設定されていると思います。これは、apiserverが正常になるのを待つためにkubeadm自体が使用する遅延にのみ使用されます。 特に、kubelet自体が使用するapiserverlivenessprobeを変更しません。 あれは正しいですか？

この問題に関する議論のどこにも反論が提起されたのを見たことがないと思います。 livenessProbe initialDelaySecondsを増やして、他の問題に進むだけではない理由はありますか？

余談ですが、クイックリードからわかる限り、 TimeoutForControlPlaneは、複数のイメージのプル中の輻輳や追加のタイムアウト+再試行ループなど、apiserverの起動遅延が増加する他の障害以外の原因も考慮していません。すべてが初期インストール時に収束している間の反復（タイムアウト+再試行はk8sデザインパターンです...これはロードされたシステムで時々発生しますが、これは予想どおりで問題ありません）。 個人的には、4分は、速い失敗を期待するせっかちなインタラクティブユーザーには長すぎ、期待される成功をより長く待つ準備ができているロード済み/低速/自動化システムへのインストールプロセスには短すぎるように感じます。 これはどのようにして到達したのですか？デフォルトで5分にできますか？ SIGINTまで再試行を続けることはできますか？ 呼び出し環境から継承するのではなく、内部で人為的な壁時計の期限を課すのはなぜですか？

Afaics TimeoutForControlPlaneは、任意の致命的な内部期限をパラメーターとして公開しているだけです。目的のUXは、期限に達することがなくなるまでパラメーターを増やすことだけです。 あるいは、そもそもその恣意的な致命的な内部期限を課すことはできません...

それは素晴らしい点であり、私は心から同意します。

特に、kubelet自体が使用するapiserverlivenessprobeは変更されません。 あれは正しいですか？

はい、まだkubeadmの活性プローブを変更する予定はありません。

このrpiの問題は、sig-cluster-lifecyleの会議で、「発生してはならないこと」、「kubeletの競合状態のように見える」、「なぜrpiでのみ発生し、他の低速デバイスでは発生しないのか」と認定されました。 私は自分で遅いデバイスをテストしていないことを認めなければなりません。

つまり、この値を増やすという合意がありました。
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
これは適切な修正ではなく、別のバグの回避策のようです。

これはどのようにして到達したのですか？デフォルトで5分にできますか？

1.11より前の画像のプルを考慮していたため、タイムアウトは4分になる前に30分でした。
4分と5分について意見がある場合は、その主題に長所がある、よく概説されたPRが1.14で成功する可能性があります。

このrpiの問題は、sig-cluster-lifecyleの会議で、「発生してはならないこと」、「kubeletの競合状態のように見える」、「なぜrpiでのみ発生し、他の低速デバイスでは発生しないのか」と認定されました。

これらはすべて、別の場所で別のバグを探し続ける理由でもありますが、initialDelaySecondsを増やす理由ではありません。 initialDelaySecondsを増やすことには実際にマイナス面がありますか？

別の方向からアプローチするために、kubernetesの他の場所で、kubeadmで使用できる回避策の問題があることがわかっている場合、純度を「維持」し、既知の壊れた結果を生成するのはkubeadmの役割ですか？ これは、人々が実際の展開に実際に使用することを期待するツールであるという目標と矛盾しているようです。 これまでのところ、タイムアウトを増やすためにパッチを適用せずにクラスターでkubeadmを使用することはできませんでした（1年以上前にパッチを適用して報告したにもかかわらず）。

（この問題に関する私の不満の一部が私の口調に漏れてしまったことをお詫びします）

4分と5分について意見がある場合

はぁ。 私はkubeadmで_no_タイムアウトを主張しようとしていましたが、その提案を説得力を持って表現する方法をまだ見つけていません（たとえば、この問題で失敗したこの試みや他の試みを参照してください）:(

これらはすべて、他の場所でも別のバグを探し続ける理由ですが、initialDelaySecondsを増加させない理由はありません。 initialDelaySecondsを増やすことには実際にマイナス面がありますか？

これは小さな変更ですが、問題が発生しないシステムにも適用されるため、この増加を追加しないことが合意されました。

別の方向からアプローチするために、kubernetesの他の場所で、kubeadmで使用できる回避策の問題があることがわかっている場合、純度を「維持」し、既知の壊れた結果を生成するのはkubeadmの役割ですか？ これは、人々が実際の展開に実際に使用することを期待するツールであるという目標と矛盾しているようです。

エンドユーザーと向き合うことがkubeadmの目標です。それは本当です。
ただし、これもrpisのレポートにすぎず、実際のバグはsig-api-machinery（apiサーバー）とsig-node（kubelet）にエスカレーションし、kubeadmの外部で再現する必要があります。

これまでのところ、タイムアウトを増やすためにパッチを適用せずにクラスターでkubeadmを使用することはできませんでした（1年以上前にパッチを適用して報告したにもかかわらず）。

kubeadmにパッチを適用する必要はありません。代わりに、マニフェストファイルにパッチを適用できます。
kubeadm 1.13は、初期化フェーズをトップレベルのコマンドに段階的に移行します-例： kubeadm init phase [phase-name]
フェーズは主に、ユーザーがコントロールプレーンノードの作成方法をカスタム制御する必要があるために発生します。

kubeadm init --helpを実行すると、フェーズが実行される順序が表示されます。

kubeadm initコマンドを適切なフェーズに分割できるように、コントロールプレーンコンポーネントにカスタムマニフェストを使用し、 control-planeフェーズをスキップします。 現在--skip-phasesます。

1.11と1.12ですでにそれを行うことができますが、それはそれほど単純ではありません。

問題を起こさないシステムにも適用されるからです。

だから..それの何が問題になっていますか？ 一部のシステムでのみトリガーされるバグを常に修正しています。 タイムアウトがある場合は、環境のサブセットだけでなく、これまでで最も遅いシステムに合わせてタイムアウトを調整する必要があります。

これに関する別の見方は、私はopsの人として、特にapiserver自体で、過負荷状態でのカスケード障害を恐れているということです。 Afaics、livenessprobeのタイムアウトは、誰かの「正常」の考えから逸脱したときだけでなく、initialDelaySecondsを小さくすることに利点はありません。 kubeadmのデフォルトのlivenessprobeは、すべてのプラットフォームで不必要に攻撃的です。

申し訳ありませんが、同じ点を繰り返し続けていますが、初期遅延秒を拡張するための強力な実用的および理論的理由があり、それを小さく保つための反対の議論を理解していません:(

このために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 / lbIPがなくても同じようになります。

アレックス

私はしばらくの間、人々にkubeadmを使用するように促してきました。学校でさえ、piクラスターでそれを実行したいと思っています。 コードベースを複雑にしたくないことは理解していますが、ユーザーベースがこれらの小さなデバイスでの実行をサポートすることはおそらく良いことだと思います。 これにより、若い人たちは、他の方法ではできないかもしれない安価なハードウェアでKubernetesタイヤを蹴ることができます。 上記の回避策は有効ですが、このユースケースでははるかに困難です。

妥協はどうですか？ 構成可能にする代わりに、x86_64でない場合は、デフォルトのタイムアウトを高く設定するという単純なヒューリスティックを追加しますか？

[kubeconfig]「admin.conf」kubeconfigファイルの書き込み
[kubeconfig]「kubelet.conf」kubeconfigファイルの書き込み
パニック：ランタイムエラー：無効なメモリアドレスまたはnilポインタの逆参照
[信号SIGSEGV：セグメンテーション違反コード= 0x1addr = 0x8 pc = 0xaa7204]

奇妙なことに、 admin.confはマシンで生成され、コンテキストを指すcurrent-contextファイルを含む有効なConfigタイプを含む必要があります。

パニックはこの行から来ています：
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でスクリプトを実行できませんでしたあまり詳しくないので、おそらく私のせいです。

そこで、誰かが興味を持った場合に備えて、スクリプトを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