Kubeadm: マスターIPアドレスの変更

これはkubeadmによる制限ではなく、一般的なセキュリティ慣行です。
証明書は{your-old-IP-here}用に署名されているため、{your-new-ip-here}に対して安全な通信を行うことはできません。

ただし、事前に証明書にIPを追加することができます...

ご返信ありがとうございます。

IPアドレスはクラウドプロバイダーによって割り当てられるため、事前に証明書を生成することは、ワイルドカードに設定できる場合にのみ機能します。 （申し訳ありませんが、証明書については何も知りません。）

リファレンスガイドに記載されていないため、 kubeadm reset実際に存在することを見逃しました。 リセットと初期化は私にとって十分に機能し、マスターマシンのシャットダウンは回避すると思います。私の問題はまれであり、実稼働のユースケースからはほど遠いと思います。 それでも、もっと良い方法があるのだろうか。 kubeadm reset手順を模倣できると思いますが、クラスターの設定を維持するためにetcdデータフォルダーを保持しますか？

いずれにせよ、kubeadmで行われたすべての作業に感謝します！ クラスターが数分で起動するのを見るのは不思議です-私は0.14からKubernetesを使用しており、1.0から本番環境で使用しています。

@analytik私はあなたとまったく同じ問題を抱えています。 私の企業ネットワークはgcr.ioをブロックしています。 だから私はインストールにドングルを使用しています。 ただし、プロバイダーIPは動的に変化し続け、私の制御下にはありません。 だから私も解決策を探しています。 ドングルを接続したままにしても、ネットワークのリセットが原因でIPが変更されることがあります。 これに対する解決策はありますか？ これをどのように処理していますか？
@luxas私がどのように進めることができるかについて提案して

変更されたマスターIPにどのように対処しますか？

この問題に関する更新はありますか？

ここでも同じ問題があります。 クラスタ全体をリセットせずにマスターIPの変更を進めるためのドキュメントはありますか？

私はこれを次の方法で達成することができました：

• / etc / kubernetes内のすべての設定ファイルのIPアドレスを置き換える
• / etc / kubernetes / pkiのバックアップ
• 古いIPアドレスを代替名として持つ/ etc / kubernetes / pki内の証明書を特定する[1]
• それぞれの証明書とキーの両方を削除します（私にとっては、apiserverとetcd / peerだけでした）
• kubeadm alpha phase certsを使用して証明書を再生成する[2]
• 古いIP [3]を参照するkube-system名前空間のconfigmapを識別します
• それらの構成マップを手動で編集する
• kubeletとdockerを再起動します（すべてのコンテナーを強制的に再作成するため）

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

うわー、私はこれらのコマンドに気づいていませんでした。 素晴らしい情報、それはトリックをしました。 ありがとうございました ！

構成マップを手動で見つけて変更する方法はありますか？

kubeadmが将来のリリースでこのプロセスをカバーできることを願っています。

@patricklucas真剣に、その記事をありがとう。 それは私の命を救った。

さらに明確なものを探している人のために、ここに私の経験があります：

1. /etc/kubernetes内のすべての構成ファイルのIPアドレスを置き換えます
   bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. /etc/kubernetes/pkiバックアップ
   bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. 古いIPアドレスを代替名として持つ/etc/kubernetes/pki内の証明書を識別する（これはクリーンアップされる可能性があります）
   bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. 古いIPを参照したkube-system名前空間のconfigmapを特定し、それらを編集します。

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. IPアドレスを変更します（ディストリビューションのcliまたはguiを介して）

6. 前の手順でgrepによって識別されたそれぞれの証明書とキーの両方を削除し、それらの証明書を再生成します

   注： kubeadm admin phase certs ...を介して証明書を再作成する前に、新しいIPアドレスを適用する必要があります

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. kubeletとdockerを再起動します
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. 新しい設定をコピーします
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

もう1つの注意点として、オフラインモードでは、構成ファイルでk8sバージョンを指定することで、証明書を変更できました： https ：

@weisjohnまた、次の点に注意してコメントを更新してください。

kubectl edit cm -nkube-public cluster-info

kubeadmにも必要ですか？

そうしないと、プロセスの途中で古い/間違ったapiserver IPを使用して、kubeadmjoinコマンドが失敗し続けます。

ありがとう！

私は@weisjohnでからのすべてのステップを適用してきました（https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755）と@michaelfig（https://github.com/kubernetes/kubeadm/issues/ 338＃issuecomment-428340099）すべてのアドレスを置き換えます。

これは、kubernetesがeth0のパブリックIPではなく、eth1に新しく作成されたVPCアドレスを使用できるようにするために使用されます。 それでも、 kubeadm upgrade diff v1.12.3を実行すると、 /etc/kubernetes/manifests/kube-apiserver.yaml --advertise-addressに変更を戻したいのです。

手がかりはありますか？

kubectl get all --export=true --all-namespaces -o yamlでも、古いIPはどこにも存在しません

更新： kubeadm upgrade diffは変更を示唆していましたが、 kubeadm upgrade applyは実際にはアドレスをまったく変更していません

@weisjohnありがとうございます

@patricklucas真剣に、その記事をありがとう。 それは私の命を救った。

さらに明確なものを探している人のために、ここに私の経験があります：

1. /etc/kubernetes内のすべての構成ファイルのIPアドレスを置き換えます
   shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. /etc/kubernetes/pkiバックアップ
   shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. 古いIPアドレスを代替名として持つ/etc/kubernetes/pki内の証明書を識別する（これはクリーンアップされる可能性があります）
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. 古いIPを参照したkube-system名前空間のconfigmapを特定し、それらを編集します。

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. IPアドレスを変更します（ディストリビューションのcliまたはguiを介して）

6. 前の手順でgrepによって識別されたそれぞれの証明書とキーの両方を削除し、それらの証明書を再生成します

   注： kubeadm admin phase certs ...を介して証明書を再作成する前に、新しいIPアドレスを適用する必要があります

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. kubeletとdockerを再起動します
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. 新しい設定をコピーします
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

手順をありがとうございます。
マスターノードで行う必要のある変更と、その後、再構成されたマスターノードに参加するために古いワーカーノードに適用する必要のある手順のようなものを提供できますか？

前もって感謝します ：）

おそらく言及するのは良いことですが、マスターIPをプライベートネットワークに移動するときは、オーバーレイネットワークも更新すると便利です。 Calicoは、VPCインターフェイスにバインドされるまで、そのインターフェイスを使用していませんでした。

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadmアルファフェーズ証明書apiserver

@weisjohn kubeadm alpha phase certs apiserverはv1.13.0で機能せず、「このコマンドは単独で実行するためのものではありません。使用可能なサブコマンドのリストを参照してください。」を示しています。 利用可能な更新されたコメントはありますか？

1.13では、コマンドはkubeadm init phase certs apiserverと呼ばれます。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

改善するための非常に便利な手順- @ patricklucasと@weisjohnに感謝し

私のように、IPアドレスがすでに変更されている状態から開始する場合は、追加のヒントが1つあります。そのため、手順4でAPIサーバーに接続して構成マップを変更することはできません。
api-server証明書はホスト名kubernetesで署名されているため、 /etc/hostsの新しいIPアドレスにエイリアスとして追加してからkubectl --server=https://kubernetes:6443 ...ます。

@bboreham @ weisjohn @ patricklucasご経験ありがとうございます。 マスターノードのIPを変更した後、ワーカーノードで何をすればよいですか？
削除/クラスターに追加しますか？ または、_ / etc / kubernetes /kubelet.conf_と_ / etc / kubernetes / pki / ca.crt_を手動で変更しますか？

私はそれが古い問題であることを知っていますが、多分私のコメントは誰かに役立つでしょう。
残念ながら、 @ patricklucasと@weisjohnによって提案された解決策は私にはうまくいかなかったので、私は自分で作成しました：

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@ valerius257ありがとうございます、あなたは私たちの週末を救います）

ありがとう@valerius257👍
@patricklucasと@weisjohnからのすべての記事/指示を試しました。 それらは私のクラスターでは機能しませんでした。 良い点は、これらの手順で、証明書とキーの重要な側面のいくつかと、それらがどのタイムラインで注意を払う必要があるかを強調していることです。

@ valerius257で言及されている命令は、kubeadmマスターノードに非常に固有の問題が発生するまで、シームレスに

@ valerius257によって言及されたステップの継続後
1つのマスターノードでフランネルn / wプラグインを使用していました。
フランネルの問題：kube-flannel-ds-xxxxバックオフで失敗したコンテナの再起動
ポッドの状態：CrashLoopBackOff。 このため、core-dns-xxxのような他のポッドも表示されません。

解決策：cidr n / wを使用してkubeadminitを使用してクラスターを開始したため（IPが古い場合、またはマスターノードのコミッショニング中に）、次の手順で「/ etc / kubernetes / manifests / kube-controller-manager」からcidr設定をワイプしました.yaml "ファイル。
kubeadm init --ignore-preflight-errors = DirAvailable--var-lib-etcd。

したがって、コマンド「kubeadm init --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16」」を使用して（1回目のIPアドレスで）kubeadmマスターノードを開始した場合は、新しいIPは、-pod-network-cidr = 10.244.0.0 / 16を使用して次のコマンドを実行する必要があります。
"kubeadm init --ignore-preflight-errors = DirAvailable--var-lib-etcd --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16"

または、 Spec：containers ：command：で不足している場合は、次のパラメーターを含めてファイル "/etc/kubernetes/manifests/kube-controller-manager.yamlを変更します。

• --allocate-node-cidrs = true
• --cluster-cidr = 10.244.0.0 / 16
  
  
  
  • --node-cidr-mask-size = 24
    
    参照： https ： ください
    
    上記の変更が行われると、
    
    systemctl stop kubelet docker
    
    睡眠20
    
    systemctl start docker kubelet
    
    フランネルを含むすべてのポッドが稼働していることを確認します。
    
    kubect get pods -n kube-system
  
  

問題2：
アプリケーション名前空間またはkube-systemのすべてのポッドで、describepodコマンドに次のようなエラーが表示され始めます。
「警告FailedSchedulingdefault-scheduler 0/1ノードが使用可能です：1つのノードにポッドが許容できない汚染がありました。」
次のコマンドを実行します。kubectltaintnodes--all node-role.kubernetes.io / master-
アプリのワークスペースまたはkube-system名前空間で実行されているすべてのポッドについて説明します。記載されているエラーは観察されません。 マルチノードクラスターでは、特に注意が必要な場合があります。

@patricklucas真剣に、その記事をありがとう。 それは私の命を救った。

さらに明確なものを探している人のために、ここに私の経験があります：

1. /etc/kubernetes内のすべての構成ファイルのIPアドレスを置き換えます
   shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. /etc/kubernetes/pkiバックアップ
   shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. 古いIPアドレスを代替名として持つ/etc/kubernetes/pki内の証明書を識別する（これはクリーンアップされる可能性があります）
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. 古いIPを参照したkube-system名前空間のconfigmapを特定し、それらを編集します。

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. IPアドレスを変更します（ディストリビューションのcliまたはguiを介して）

6. 前の手順でgrepによって識別されたそれぞれの証明書とキーの両方を削除し、それらの証明書を再生成します

   注： kubeadm admin phase certs ...を介して証明書を再作成する前に、新しいIPアドレスを適用する必要があります

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. kubeletとdockerを再起動します
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. 新しい設定をコピーします
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

newipの代わりにどのIPを与えるべきですか？
独自のIPを作成できますか？

@VipinKrizzこの問題のコンテキストは、インフラストラクチャ内の要因によりIPがすでに変更されていることです。 あなたの特定の設定に精通している人を除いて、誰もあなたがどのIPを使うべきか答えることができません。

たぶん、Slackでこれについてチャットできる人を見つけることができますか？ Kubeadmの問題は適切な場所ではありません。

@ valerius257そのスクリプトに感謝します。今では、私のアプローチにいくつかの欠点があります。 ソリューションが機能したことは確認できますが、（すべてのk8のように）小さなエッジがたくさんあります。 有効なサービス/ビルトイン、DNS、特別なストレージクラスなどにパッチを再適用する必要がありました。

しかし、ええ、あなたのスクリプトは今日私のベーコンを救いました。

@ valerius257私はあなたのステップに従いましたが、問題を下回りました

root @ ubuntu ：/ etc / kubernetes / pki＃kubeadm init --ignore-preflight-errors = DirAvailable--var-lib-etcd
W0122 10：15：34.819150 102032 version.go：101]インターネットからKubernetesバージョンをフェッチできませんでした：URL " https://dl.k8s.io/release/stable-1.txt "を取得できません： httpsを取得
W0122 10：15：34.819340 102032 version.go：102]ローカルクライアントバージョンへのフォールバック：v1.16.3
[init] Kubernetesバージョンの使用：v1.16.3
[プリフライト]プリフライトチェックの実行
[警告IsDockerSystemdCheck]：Dockercgroupドライバーとして「cgroupfs」が検出されました。 推奨されるドライバーは「systemd」です。 https://kubernetes.io/docs/setup/cri/のガイドに従って
[警告DirAvailable--var-lib-etcd]：/ var / lib / etcdは空ではありません
[プリフライト] Kubernetesクラスターのセットアップに必要な画像のプル
[プリフライト]インターネット接続の速度によっては、1〜2分かかる場合があります
[プリフライト]このアクションは、事前に「kubeadm configimagespull」を使用して実行することもできます。
[kubelet-start]フラグ付きのkubelet環境ファイルをファイル「/var/lib/kubelet/kubeadm-flags.env」に書き込む
[kubelet-start]ファイル「/var/lib/kubelet/config.yaml」へのkubelet設定の書き込み
[kubelet-start] kubeletサービスのアクティブ化
[証明書] certificateDirフォルダー「/ etc / kubernetes / pki」を使用する
[証明書]既存のCA認証局を使用する
[証明書]「apiserver」証明書とキーの生成
[certs] apiserverサービング証明書は、DNS名[ubuntu kubernetes kubernetes.default kubernetes.default.svckubernetes.default.svc.cluster.local]およびIP [10.96.0.1192.168.120.137]に対して署名されています。
[証明書]ディスク上の既存のapiserver-kubelet-client証明書とキーを使用する
[証明書]既存のfront-proxy-ca認証局を使用する
[証明書]ディスク上の既存のフロントプロキシクライアント証明書とキーを使用する
[証明書]既存のetcd / ca認証局を使用する
[証明書]ディスク上の既存のetcd /サーバー証明書とキーを使用する
[証明書]「etcd / peer」証明書とキーの生成
[証明書] etcd /ピアサービング証明書は、DNS名[ubuntulocalhost]およびIP [192.168.120.137 127.0.0.1 :: 1]に対して署名されています
[証明書]ディスク上の既存のetcd / healthcheck-client証明書とキーを使用する
[証明書]ディスク上の既存のapiserver-etcd-client証明書とキーを使用する
[証明書]既存の「sa」キーを使用する
[kubeconfig] kubeconfigフォルダー「/ etc / kubernetes」を使用する
[kubeconfig]「admin.conf」kubeconfigファイルの書き込み
[kubeconfig]「kubelet.conf」kubeconfigファイルの書き込み
[kubeconfig]「controller-manager.conf」kubeconfigファイルの書き込み
[kubeconfig]「scheduler.conf」kubeconfigファイルの書き込み
[コントロールプレーン]マニフェストフォルダー「/ etc / kubernetes / manifests」を使用する
[コントロールプレーン]「kube-apiserver」の静的ポッドマニフェストを作成する
[コントロールプレーン]「kube-controller-manager」の静的ポッドマニフェストを作成する
[コントロールプレーン]「kube-scheduler」の静的ポッドマニフェストを作成する
[etcd]「/ etc / kubernetes / manifests」にローカルetcdの静的ポッドマニフェストを作成する
[wait-control-plane] kubeletがディレクトリ「/ etc / kubernetes / manifests」から静的ポッドとしてコントロールプレーンを起動するのを待機しています。 これには最大4分0秒かかる場合があります
[kubelet-check] 40秒の初期タイムアウトが過ぎました。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp 127.0.0.1:10248：connect：connection拒否した。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp 127.0.0.1:10248：connect：connection拒否した。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp 127.0.0.1:10248：connect：connection拒否した。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp 127.0.0.1:10248：connect：connection拒否した。
[kubelet-check] kubeletが実行されていないか正常ではないようです。
[kubelet-check] 'curl -sSL http：// localhost ：10248 / healthz'に等しいHTTP呼び出しがエラーで失敗しました：Get http：// localhost ：10248 / healthz：dial tcp 127.0.0.1:10248：connect：connection拒否した。

残念ながら、エラーが発生しました：
状態を待ってタイムアウトしました

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

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

さらに、コンテナランタイムによって開始されたときに、コントロールプレーンコンポーネントがクラッシュまたは終了した可能性があります。
トラブルシューティングを行うには、Dockerなどの優先コンテナランタイムCLIを使用してすべてのコンテナを一覧表示します。
Dockerで実行されているすべてのKubernetesコンテナを一覧表示する方法の一例を次に示します。
-'docker ps -a | grep kube | grep -v pause '
障害のあるコンテナを見つけたら、次の方法でログを調べることができます。
-'dockerログCONTAINERID '
エラー実行フェーズwait-control-plane：Kubernetesクラスターを初期化できませんでした
このエラーのスタックトレースを確認するには、-v = 5以上で実行します。

親切に助けて

私はこれを次の方法で達成することができました：

• / etc / kubernetes内のすべての設定ファイルのIPアドレスを置き換える
• / etc / kubernetes / pkiのバックアップ
• 古いIPアドレスを代替名として持つ/ etc / kubernetes / pki内の証明書を特定する[1]
• それぞれの証明書とキーの両方を削除します（私にとっては、apiserverとetcd / peerだけでした）
• kubeadm alpha phase certsを使用して証明書を再生成する[2]
• 古いIP [3]を参照するkube-system名前空間のconfigmapを識別します
• それらの構成マップを手動で編集する
• kubeletとdockerを再起動します（すべてのコンテナーを強制的に再作成するため）

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

私のために働いてくれてありがとう

唯一のことはあなたが使用する必要があるということです

 kubeadm init phase ..

最新のkubectlバージョンの場合

@bboreham
@patricklucasが言及した手順に従いました
手順4で述べたように、IPはすでに変更されており、api-serverに接続できないため、/ etc / hostsでいくつかの構成を行う必要があります。

を使用して証明書を生成する
kubeadm init --kubernetes-version = v1.16.3フェーズ証明書apiserver

/ etc / hostsで変更しました

kubectl --server = https：//を試しました：6443はまだ機能していません:(

/ etc / hostsで行う必要のある特定の構成はありますか？