私の質問：K8Sを展開する場合、kubeletを開始することができませんでした。
[ルート@ jm228〜] ＃kubeadmのinit --config = kubeadm-config.yaml --experimentalアップロード-certsの--ignore-プリフライトエラー=すべて| ティーkubeadm-init.log フラッグ--experimentalアップロード-certsのは、使用--upload-廃止されている代わりに、本命を V1：Kubernetesバージョンを使用して[INIT]。15.1 [プリフライト]実行プリフライト チェック [WARNING FileAvailable --etc-kubernetes-マニフェスト-KUBE-apiserver.yaml]：の/ etc / kubernetes /マニフェスト/ kube- apiserver.yamlすでに存在している [WARNING FileAvailable --etc-kubernetes-マニフェスト-KUBEコントローラ-manager.yaml]：の/ etc / kubernetes /マニフェスト/ KUBE-controller- manager.yamlすでに存在している [WARNING FileAvailable--etc-kubernetes-マニフェスト-KUBE-scheduler.yaml]：の/ etc / kubernetes /マニフェスト/ kube- scheduler.yamlすでに存在している [WARNING FileAvailable --etc-kubernetes-マニフェスト-etcd.yaml]：の/ etc / kubernetes /マニフェスト/ etcd.yamlすでに存在して 必要なイメージを引っ張る[プリフライト]をためKubernetesのクラスタを設定し 、これは1〜2分かかる場合があります[プリフライト]あなたのインターネット接続の速度に応じて、 [プリフライト]また、このアクションを実行することができますに、あらかじめ使用「kubeadm設定画像が引く」 [kubelet -start]ファイルへのフラグと書き込みkubelet環境ファイル「/var/lib/kubelet/kubeadm-flags.env 」 [kubelet-start]ファイルにkubelet設定を書き込む" /var/lib/kubelet/config.yaml " [kubeletを - kubeletサービスのアクティブ化]スタート [本命]フォルダcertificateDirを使用する" の/ etc / kubernetes / PKI " [本命]を使用して、既存のCA証明書権威 ディスク上の既存のapiserver証明書とキーを使用して、[本命] 既存のapiserver使い方[本命] -kubelet- ディスク上のクライアント証明書とキーを 既存のフロント使い方[本命] -proxy- CA証明書の権限を [本命]を使用して、既存のフロント -proxy- のクライアント証明書そして、ディスク上のキー の既存etcdを使用して[本命] /CA証明書機関 の既存etcd使い方[本命] / ディスク上のサーバー証明書とキーを 既存のetcd使用して[本命] / healthcheck- ディスク上のクライアント証明書とキーを 既存のapiserver使用して[本命] -etcd- ディスク上のクライアント証明書とキーを 使って[本命] etcd既存 / ディスク上のピア証明書とキーを [本命]既存の使い方" SA " キーを [kubeconfig] kubeconfigフォルダ使い方" の/ etc / kubernetes " [kubeconfig]既存のkubeconfigファイルを使用：" /etc/kubernetes/admin.confを" [既存のkubeconfigファイルを使用してkubeconfig]：" /etc/kubernetes/kubelet.conf " [kubeconfig]既存のkubeconfigファイルを使用する：" /etc/kubernetes/controller-manager.conf " [kubeconfig]既存のkubeconfigファイルを使用：" /etc/kubernetes/scheduler.confを" [コントロール -plane]マニフェストフォルダを使用" の/ etc / kubernetes /マニフェスト" [制御 -plane]静的ポッドマニフェストを作成するための " KUBE-apiserver " [制御 -plane]静的ポッドマニフェストを作成するための " KUBEコントローラマネージャを" [制御 -plane]静的ポッドマニフェストの作成のために 「KUBE-スケジューラ」 [etcd]静的ポッドマニフェストを作成するためにローカルetcd に 「の/ etc / kubernetes /マニフェスト」 [待機 -controlプレーン]待ちのためのディレクトリから静的ポッドなどの制御プレーン起動するkubelet " の/ etc / kubernetes /マニフェスト」。これは4m0sに取ることができます [kubelet - チェック] 40代の初期タイムアウトが渡されました。 [kubelet - チェック]はkubeletが実行されているか、健康されていないように思えます。 [kubelet-check] HTTP呼び出しに等しいエラーで失敗しました'カール-sslのhttp：10248 / healthz：// localhostの'：取得のhttp：// localhostを：10248 / healthzを：114.114.114.114:53上のルックアップはlocalhost：TCPをダイヤル：なしこのような宿主。 [kubelet - チェック]はkubeletが実行されているか、健康されていないように思えます。 [kubeletエラーで失敗しました：GETのhttp：// localhostを：10248 / healthz：-check] HTTP呼び出しは、 '：// localhostの10248 / healthzカール-SSL HTTP'に等しいダイヤルTCP：検索localhostの114.114.114.114:53にA：いいえ、そのようなホスト。 [kubelet - チェック]はkubeletが実行されているか、健康されていないように思えます。 [kubelet-check] HTTP呼び出しに等しいエラーで失敗しました'カール-sslのhttp：10248 / healthz：// localhostの'：取得のhttp：// localhostを：10248 / healthzを：114.114.114.114:53上のルックアップはlocalhost：TCPをダイヤル：なしこのような宿主。 [kubelet - チェック]はkubeletが実行されているか、健康されていないように思えます。 [kubeletエラーで失敗しました：GETのhttp：// localhostを：10248 / healthz：-check] HTTP呼び出しは、 '：// localhostの10248 / healthzカール-SSL HTTP'に等しいダイヤルTCP：検索localhostの114.114.114.114:53にA：いいえ、そのようなホスト。 [kubelet - チェック]はkubeletが実行されているか、健康されていないように思えます。 [kubelet-check] HTTP呼び出しに等しいエラーで失敗しました'カール-sslのhttp：10248 / healthz：// localhostの'：取得のhttp：// localhostを：10248 / healthzを：114.114.114.114:53上のルックアップはlocalhost：TCPをダイヤル：なしこのような宿主。 残念ながら、エラーが発生しました： 待機中にタイムアウトのための条件 このエラーはおそらくによって引き起こされる： - kubeletが実行されていない - kubeletは、ノードの設定ミスが原因不健康であるにおけるいくつかの方法（無効のcgroupが必要） した場合、あなたがオンになっていますsystemd- パワードシステムは、次のコマンドを使用してエラーのトラブルシューティングをしようとすることができます： - 「systemctl状態kubelet」 - 「journalctl -XEU kubelet」 コンテナ・ランタイムによって起動時にまた、コントロールプレーンのコンポーネントがクラッシュまたは終了している可能性があります。 トラブルシューティングするために、お好みのコンテナを使用して、すべてのコンテナをリストすることはCLI、例えばドッキングウィンドウをランタイム。 ここでは、実行中のすべてのKubernetesコンテナを一覧表示する方法を一例にしてドッキングウィンドウ： - 「ドッキングウィンドウのps -a | grepのKUBE | grepが- Vポーズは」 あなたが失敗し、コンテナが見つかったら、あなたがそのログを調べることができます - 『ドッキングウィンドウがContainerIDの』ログに記録 エラー実行フェーズ待ち -controlプレーンを：Kubernetesクラスタを初期化できませんでした
使用 journalctl -xeu kubeletログを表示します。
3月27日午後03時15分15秒jm230 kubelet [22402]：I0327 15：15：15.075048 22402 server.go：416]バージョン：v1.17.4 年03月 27午前15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.075484 22402 plugins.go：100 ]いいえ、クラウド・プロバイダーは、指定されました。 月 27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.075528 22402 server.go：821]クライアント回転が上にある、ブートストラップうに背景 マール [15時15分15秒jm230 kubelet 27 22402]：I0327 15 ：15：15.079892 22402 certificate_store.go：から129]読み込み証明書/鍵ペア" /var/lib/kubelet/pki/kubelet-client-current.pem " 。 マー27午後三時15分15秒jm230 kubelet [22402]：I0327 15：15：15.294977 22402 server.go：641] --cgroups当たりのQoS有効、しかし--cgroupルートが指定されませんでした。/をデフォルト マール I0327：15：15：15.295878 22402 container_manager_linux.go：jm230 kubelet [22402] 27午前15時15分15秒を265]コンテナ・マネージャは、ユーザが指定したcgroup-検証ルートは存在する：[] 月 27午前15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.295937 22402 container_manager_linux.go：270 ]ノード構成に基づいて作成コンテナマネージャオブジェクト：{RuntimeCgroupsName：SystemCgroupsName：KubeletCgroupsName：ContainerRuntime：ドッキング Marは 27夜3時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296161 22402 fake_topology_manager.go：29 ] [偽のtopologymanager] NewFakeManager 月27午前15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296182 22402 container_manager_linux.go：305]マネージャプラグインの作成装置であって、真 年03月 27午前15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296230 22402 fake_topology_manager.go：39] [偽topologymanager] AddHintProvider HintProvider：＆{kubelet.sockの/ var / libに/ kubelet /デバイス・プラグイン/マップ[] {0} <ゼロ> {{} [0 0 0]} 0x1b1d7 年03月 27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296299 22402 state_mem.go：36] [cpumanager]新しい初期化中 - メモリ状態ストア 年03月 27 15時15分15秒をjm230 kubelet [22402]：I0327 15：15：15.296515 22402 state_mem.go：84] [cpumanager]更新デフォルトのcpuset："" マル27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296538 22402 state_mem.go：92] [cpumanager]更新のcpusetの割り当て：" マップ[] " Marの 27 15時15分15秒jm230 kubelet [22402]： I0327 15：15：15.296561 22402 fake_topology_manager.go：39] [偽のtopologymanager] AddHintProvider HintProvider：＆{{0} 0x6ea6db8 10000000000 0xc00090a840 <ゼロ> <ゼロ> <ゼロ> <ゼロ> [メモリマップ：{{104857 年03月 27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.296718 22402 kubelet.go：286]追加ポッドパス：の/ etc / kubernetes / マニフェスト 年03月 27 15時15分15秒jm230 kubelet [22402]：I0327 15： 15：15.296785 22402 kubelet.go：311 ] apiserver見 マル27午後三時15分15秒jm230 kubelet [22402]：E0327 15：15：15.307611 22402 reflector.go：153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:449：リストに失敗しました* v1.Service：GET https://10.41.4.230:6443/api/v1/services?limit=500&resourceVersion=0 ：DIA 年03月 27午後03時15分15秒jm230 kubelet [22402]：E0327 15：15：15.307642 22402 reflector.go：153] K8S .IO / kubernetes / PKG / kubelet / kubelet.go：458：リストに失敗しました* v1.Node：取得https://10.41.4.230:6443/api/v1/nodes?fieldSelector=metadata.name%3Djm230& 李 Marの 27午後03時15分15秒jm230 kubelet [22402]：E0327 15：15：15.307823 22402 reflector.go：153] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46：リストに失敗しました* v1.Pod：取得https://10.41.4.230:6443/api/v1/pods?fieldSelector=spec.nodeName% 3Djm 月27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.312694 22402 client.go：75] UNIX上ドッカーへの接続：/// VAR /実行/ docker.sock 年03月 27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.312745 22402 client.go：104]は、要求タイムアウトがスタートドッカークライアントは= 2m0s マール W0327：15：15：27午後3時15分15秒jm230 kubelet [22402]を15.328315 22402 docker_service.go：563 ]にヘアピンモードセット" 無差別ブリッジ"が、kubenetはにフォールバック、有効化されていない" ヘアピンのvethを" 年03月 27午後03時15分15秒jm230 kubelet [22402]：I0327 15：15：15.328393 22402 docker_service.go：240]ヘアピンモード設定「ヘアピンのveth 」 マル午後03時15分15秒jm230 kubelet 27 [22402]：W0327 15：15：15.328522 22402 cni.go：237] 更新CNIの設定できません：NOネットワークがある/ etc / CNI /見出さnet.d さらにちょうどこのエラーのため＃ネットワーク展開されていない、一時的にチューブ -Mar 27午後03時15分15秒jm230 kubelet [22402]：W0327 15：15：15.335658 22402 cni.go：237]更新CNIの設定できません：NOネットワークが発見での/ etc / CNI / net.d -Mar 27 15時15分15秒jm230 kubelet [22402]：15 I0327：15：15.335769 22402 docker_service.go：255 ]ネットワークドッカーCRI CNIによって管理 -Mar 27 15時15分15秒jm230 kubelet [22402]：W0327 15：15： 22402 15.335883 cni.go：237]更新CNIの設定にできません：NOネットワークが見つかっには/ etc / CNI / net.d -Mar27午後三時15分15秒jm230 kubelet [22402]：I0327 15：15：15.385723 22402 docker_service.go：260]ドッカー情報：＆{ID：2UFE：736H：UMTZ：W2OH：YPUJ：P5JR：4GBY：Z4QT：PCGW： FUJ5：M7SN：2PJCコンテナ：0 ContainersRunning：0 ContainersPaused：0 ContainersStoppe 月 27夜03時15分15秒jm230 kubelet [22402]：使用`--storage- 。OPT dm.thinpooldev`カスタムブロック記憶デバイスを指定する]} マル 27 15時15分15秒jm230 kubelet [22402]：I0327 15：15：15.385932 22402 docker_service.go：273 ]システムDするcgroupDriver設定 月 15時15分15秒jm230 kubelet 27 [22402]：F0327 15：15：15.390830 22402 docker_service .GO：414] ストリーミングサーバが予期せず停止：114.114.114.114:53に、ルックアップはlocalhost：TCP聞いていない、そのようなホスト： マルシステムD 27 15時15分15秒jm230 [1]：kubelet.service：メインプロセスは /ステータス= 255、終了=、コードを出/ N マルシステムD 27 15時15分15秒jm230を[1 ]：単位kubelet.serviceが失敗入力されました状態。 月にsystemd 27夜03時15分15秒jm230 [1]：kubelet.serviceに失敗しました。
各アドレス、DNSを見て、私はそうCATの/etc/resolv.confを、と何も間違っているを発見し、そして使用のpingをwww.baidu.com、ネットワークが正常であることを発見し上陸した 猫/ etc / hostsの問題を。
[ルート@ K8S-135〜] ＃1 猫の/ etc /ホスト 192.168.17.135 K8S-135 192.168.17.138 K8S-138 192.168.17.140 K8S-140
通常の状況下で、コンテンツホストは、各列が3つの部分から構成され、ホスト名（ホスト名）の定義は、各ホストを作用空間によって分離された各部分です。
それらは：ドメインホスト名のホスト名のネットワークIPアドレス（ホスト名の別名）
ここでは、最初の2行が欠落している、あること、IPv4とIPv6のループバックアドレス、ユニットは解決できない原因となる、あなたは追加できます。（セイそれは愚かである、最初に私にそれはだから今、何が悪かったのかのK8S展開だと思いました）
127.0.0.1 はlocalhost localhost.localdomainをlocalhost4 localhost4.localdomain4
:: 1 localhostのlocalhost.localdomainをlocalhost6 localhost6.localdomain6
添付：[Linuxの]一般的なパブリックDNSアドレス