最初のエラーメッセージ：クライアントCAファイルを読み込めません/etc/kubernetes/pki/ca.crt：/etc/kubernetes/pki/ca.crtを開きます：そのようなファイルまたはディレクトリはありません

最初のエラーメッセージ：クライアントCAファイルを読み込めません/etc/kubernetes/pki/ca.crt：/etc/kubernetes/pki/ca.crtを開きます：そのようなファイルまたはディレクトリはありません

こんにちは、ここにいくつかの質問があります：
1）kubeadm initは終了し、ブーストラップトークンを出力しますか？
2）コンテナランタイムバージョン？
3）kubeletおよびkubeadmバージョン1.12ですか？

/優先度のニーズ-より多くの証拠

kubeadminitの前にsystemctlstartkubeletを実行する必要があります

カップのコアが2未満であるため、同じ問題が発生しています。

同じ問題

@javacppcどのようにしてこれを解決しましたか？ systemctl start kubeletを実行すると、 error code

kubernetes1.12.2でも同じ問題が発生します。
@Javacppcどのようにしてこれを解決しましたか？

同じ問題

同じ問題

こんにちはみんな、

ここでも同じ問題に直面しています。クラスターを起動すると、トークンからメッセージが表示されますが、クラウドウィーブをインストールできません。
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" The connection to the server 192.168.56.104:6443 was refused - did you specify the right host or port?

ログに移動すると、ノード名に関するメッセージが表示されます。

Dec 02 22:27:55 kubemaster5 kubelet[2838]: E1202 22:27:55.128645 2838 kubelet.go:2236] node "kubemaster5" not found

誰か私に光を送ってくれませんか？

ありがとうございました！

私の問題は解決されましたが、実際にはバグではありません。何らかの理由でapiserverを起動できなかったためです。

「何らかの理由でapiserverを起動できませんでした」？ 詳細を教えていただけますか？

私は数日前に問題を解決しました。 1.11.4-> 1.12.3から更新します。 私が持っている：

1. api-server -独自のネットワークを持つ特定の仮想インターフェイスで実行されます。 （ベアメタル）。
   フラグapiserver-advertise-address kubeadm init/join付いた/etc/kubernetes/manifests/kube-apiserver.yamlパラメーターbind-addressを支援しました。
2. flannel - controller 、 schedulerポッドを作成した後のネットワークでも同じ状況。 APIサーバー10.96.0.1:443 clusterIPへのconnection refusedが原因で、DNSの展開に失敗しました。 （デフォルトのルーティングテーブル）仮想インターフェイスのIPを使用して/etc/systemd/system/kubelet.service.d/10-kubeadm.confフラグ--node-ipでクラスターノードのnode-ipを指定しました。

この後、バージョン1.12.3のノードを準備しました。 最も役立つ情報はdocker logs + kubectl logs

ここでv1.13.0と同じ問題

Kubernetesv1.13.0でも同じ問題が発生します
CentOS 7
docker-ce 18.06（最新の検証済みバージョン）
dockerd：アクティブ、実行中
kubelet：アクティブ、実行中
selinux：無効
Firewalld：無効

エラーは次のとおりです。
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/ etc / hostsにはノードが含まれており、ピンジ可能であり、到達可能です。実際には、シングルマスターシングルワーカー（つまり、汚染されたノード）を実行します。

K8Sはどこでこの値を探しますか？ / etc / hostsにありますか？
トラブルシューティングを行い、必要に応じてより多くの証拠を提供できます。

-> kubeadm initは終了し、ブーストラップトークンを出力しますか？
それは長いエラーで終了します：

[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[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
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

注：タイムアウト後に提案されたコマンドのいずれも、ここで言及する価値のあるものを報告しませんでした。

kubeletとkubeadmバージョン？
---> 1.13.0
kubeadmバージョン：＆version.Info {メジャー： "1"、マイナー： "13"、GitVersion： "v1.13.0"、GitCommit： "ddf47ac13c1a9483ea035a79cd7c10005ff21a6d"、GitTreeState： "clean"、BuildDate： "2018-12-03T21：02： 01Z "、GoVersion：" go1.11.2 "、コンパイラ：" gc "、プラットフォーム：" linux / amd64 "}

また、「ノードが見つかりません」よりも優れたエラーメッセージを設定し、kubeログをもう少し明確/冗長にする必要がありますか？

ありがとう

同じ問題...

$ 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 Fri 2018-12-14 19:05:47 UTC; 2min 2s ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 9114 (kubelet)
    Tasks: 23 (limit: 4915)
   CGroup: /system.slice/kubelet.service
           └─9114 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-d

Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862262    9114 kuberuntime_manager.go:657] createPodSandbox for pod "kube-scheduler-pineview_kube-system(7f99b6875de942b000954351c4a
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862381    9114 pod_workers.go:186] Error syncing pod 7f99b6875de942b000954351c4ac09b5 ("kube-scheduler-pineview_kube-system(7f99b687
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906855    9114 remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to start san
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906944    9114 kuberuntime_sandbox.go:65] CreatePodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fai
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906981    9114 kuberuntime_manager.go:657] createPodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fa
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.907100    9114 pod_workers.go:186] Error syncing pod b7841e48f3e7b81c3cda6872104ba3de ("etcd-pineview_kube-system(b7841e48f3e7b81c3c
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.933627    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.033880    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.134064    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.184943    9114 event.go:212] Unable to write event: 'Post https://192.168.1.235:6443/api/v1/namespaces/default/events: dial tcp 192.

同じ問題：

Ubuntu 18.04.1 LTS
Kubernetes v1.13.1（cri-o 1.11を使用）

kubernetes.ioのインストール手順に従いました。
https://kubernetes.io/docs/setup/independent/install-kubeadm/
https://kubernetes.io/docs/setup/cri/#cri -o

systemctl enable kubelet.service
kubeadm init --pod-network-cidr=192.168.0.0/16 --cri-socket=/var/run/crio/crio.sock

/etc/hosts

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       master01.mydomain.tld master01
::1             master01.mydomain.tld master01

/etc/hostname

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 Tue 2018-12-18 16:19:54 CET; 20min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 10148 (kubelet)
    Tasks: 21 (limit: 2173)
   CGroup: /system.slice/kubelet.service
           └─10148 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --resolv-conf=/run/systemd/resolve/resolv.conf

Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.795313   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.896277   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.997864   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.098927   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.200355   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.281586   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://192.168.178.27:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.282143   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:444: Failed to list *v1.Service: Get https://192.168.178.27:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.283945   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:453: Failed to list *v1.Node: Get https://192.168.178.27:6443/api/v1/nodes?fieldSelector=metadata.name%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.301468   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.402256   10148 kubelet.go:2266] node "master01" not found

@fhemberger私は自分の問題を理解しました。 Dockerのインストールにsnapを使用していました。 それをアンインストールし、 aptを使用して再インストールした場合、kubeadmは正常に機能しました。

@cjbottaro私はDockerをまったく使用していませんが、cri-oを使用しています。

ここでv1.13.1と同じ問題

systemdとcri-oを使用している場合は、必ず/var/lib/kubelet/config.yaml cgroupドライバーとして設定してください（または、以下のスニペットをkubeadm init --config=config.yaml一部として渡します）。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

kubeletログでこれに気付いた場合：

remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = cri-o configured with systemd cgroup manager, but did not receive slice as parent: /kubepods/besteffort/…

私は今日同じ問題に遭遇しました。

rm -rf / var / lib / kubelet /を

@JishanXingありがとうございます！ これにより、Raspbian Sketchliteで実行する際の問題も解決しました

/etc/systemd/system/kubelet.service.d/20-etcd-service-manager.confを削除して修正しました

kubeadm resetコマンドを使用することをお勧めします。

@fhembergerそれを解決する方法、同じ質問、ありがとう

k8sを1.13.3から1.13.4にアップグレードしたときに同じ問題が発生しました...
/etc/kubernetes/manifests/kube-scheduler.yaml編集した後で解決します。 イメージバージョンを変更する
image: k8s.gcr.io/kube-scheduler:v1.13.3 ==> image: k8s.gcr.io/kube-scheduler:v1.13.4
kube-controller-manager.yamlとkube-apiserver.yamlも同じです。

最新の方法は、オプション--image-repository Registry.aliyuncs.com/google_containersを追加すること
`kubeadm init --image-repository Registry.aliyuncs.com/google_containers --kubernetes-version v1.14.0 --pod-network-cidr = 192.168.0.0 / 16
[init] Kubernetesバージョンの使用：v1.14.0
[プリフライト]プリフライトチェックの実行
[警告IsDockerSystemdCheck]：Dockercgroupドライバーとして「cgroupfs」が検出されました。 推奨されるドライバーは「systemd」です。 https://kubernetes.io/docs/setup/cri/のガイドに従って
[プリフライト] 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」を使用する
[証明書]「front-proxy-ca」証明書とキーの生成
[証明書]「front-proxy-client」証明書とキーの生成
[証明書]「ca」証明書とキーの生成
[証明書]「apiserver」証明書とキーの生成
[certs] apiserverサービング証明書は、DNS名[jin-virtual-machine kubernetes kubernetes.default kubernetes.default.svckubernetes.default.svc.cluster.local]とIP [10.96.0.1192.168.232.130]に対して署名されています。
[証明書]「apiserver-kubelet-client」証明書とキーの生成
[証明書]「etcd / ca」証明書とキーの生成
[証明書]「etcd / server」証明書とキーの生成
[証明書] etcd /サーバーサービング証明書は、DNS名[jin-virtual-machinelocalhost]およびIP [192.168.232.130 127.0.0.1 :: 1]に対して署名されています。
[証明書]「etcd / peer」証明書とキーの生成
[証明書] etcd /ピアサービング証明書は、DNS名[jin-virtual-machinelocalhost]およびIP [192.168.232.130 127.0.0.1 :: 1]に対して署名されています。
[証明書]「apiserver-etcd-client」証明書とキーの生成
[証明書]「etcd / healthcheck-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秒かかる場合があります
[apiclient]すべてのコントロールプレーンコンポーネントは17.004356秒後に正常になります
[upload-config] ConfigMap「kubeadm-config」で使用される構成を「kube-system」名前空間に格納します
[kubelet]名前空間kube-systemにConfigMap "kubelet-config-1.14"を作成し、クラスター内のkubeletsの構成を使用します
[upload-certs]フェーズをスキップします。 --experimental-upload-certsを参照してください
[mark-control-plane]ラベル「node-role.kubernetes.io/master= ''」を追加して、ノードjin-virtual-machineをコントロールプレーンとしてマークします
[mark-control-plane]汚染を追加することにより、ノードjin-virtual-machineをコントロールプレーンとしてマークします[node-role.kubernetes.io/ master：NoSchedule ]
[ブートストラップトークン]トークンの使用：xucir0.o4kzo3qqjyjnzphl
[bootstrap-token]ブートストラップトークン、cluster-info ConfigMap、RBACロールの構成
[bootstrap-token]ノードが長期の証明書資格情報を取得するためにノードブートストラップトークンがCSRを送信できるように構成されたRBACルール
[bootstrap-token] csrapproverコントローラーがノードブートストラップトークンからCSRを自動的に承認できるように構成されたRBACルール
[bootstrap-token]クラスター内のすべてのノードクライアント証明書の証明書ローテーションを許可するように構成されたRBACルール
[bootstrap-token]「kube-public」名前空間に「cluster-info」ConfigMapを作成する
[アドオン]適用される必須アドオン：CoreDNS
[アドオン]適用される必須アドオン：kube-proxy

Kubernetesコントロールプレーンが正常に初期化されました。

クラスターの使用を開始するには、通常のユーザーとして以下を実行する必要があります。

mkdir -p $ HOME / .kube
sudo cp -i /etc/kubernetes/admin.conf $ HOME / .kube / config
sudo chown $（id -u）：$（id -g）$ HOME / .kube / config

これで、ポッドネットワークをクラスターにデプロイする必要があります。
次のいずれかのオプションを使用して「kubectlapply-f [podnetwork] .yaml」を実行します。
https://kubernetes.io/docs/concepts/cluster-administration/addons/

次に、rootとしてそれぞれで以下を実行することにより、任意の数のワーカーノードに参加できます。

kubeadm join 192.168.232.130:6443 --token xucir0.o4kzo3qqjyjnzphl
--discovery-token-ca-cert-hash sha256：022048b22926a2cb2f8295ce2e3f1f6fa7ffe1098bc116f7d304a26bcfb78656
`

GCP Ubuntu 18.04VM上のkubernetesv1.14.1とcri-ov1.14.0で同じ問題が発生しました。 ただし、dockerを使用すると問題なく動作しました。 参照： https ：

私の問題は、さまざまなcgroupドライバーにありました。 CRIOはデフォルトでsystemdを使用し、kubeletはデフォルトでcgroupfsを使用します。

cat /etc/crio/crio.conf | grep cgroup
# cgroup_manager is the cgroup management implementation to be used
cgroup_manager = "systemd"

その場合は、 https： //kubernetes.io/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-nodeを参照して

ファイルを書くだけ

echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" > /etc/default/kubelet

その後、kubeadminitを実行します。 または、cgroup_managerをcgroupfs

dockerとは異なり、cri-oとcontainerdは、cgroupドライバーの検出に関して管理するのが少し難しいですが、kubeadmからそれをサポートする計画がいくつかあります。

dockerはすでに処理されています。

したがって、どうやら解決策はありませんが、クラスター$（yes | kubeadm reset）をリセットする以外に解決策はありません。これは私の意見では解決策ではありません。

画像リポジトリの変更は私にとってはうまくいきましたが、これは素晴らしい修正ではありません。
--image-repository Registry.aliyuncs.com/google_containers

私の場合はこれでうまくいきました

sed -i's / cgroup-driver = systemd / cgroup-driver = cgroupfs / g '/ etc / systemd / system / kubelet.service.d / 10-kubeadm.conf

私は同じ問題を抱えています。 kubeadm init --config=init-config.yamlを使用しましたが、失敗しました。このファイルはkubeadmによって生成されました。 ファイルには、advertiseAddressのデフォルトが1.2.3.4であるフィールドがあり、etcd contianerstartが失敗します。 127.0.0.1に変更すると、etcd contianerが正常に起動し、kubeadminitが成功します

この問題を解決するには、 docker ps -a使用して、すべてのコンテナを一覧表示し、一部が終了したかどうかを確認します。終了した場合は、 docker logs CONTIANER_IDを使用して何が起こったかを確認します。 それが役に立てば幸い

みなさん、解決策はありますか？ ここでも同じ問題がありますが、 k3sを使用してい

@MateusMacは、おそらくk3sに対してもバグレポートを開く必要があります。

kubeadm作業を1週間行いました
Ubuntu 18.04
docker 18.06-2-ce
k8s 1.15.1
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Fails with:

[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

kubeletログは、一塁を通過するノードが見つからないことを示しています。

warproot<strong i="15">@warp02</strong>:~$ 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 2019-08-04 18:22:26 AEST; 5min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 12569 (kubelet)
    Tasks: 27 (limit: 9830)
   CGroup: /system.slice/kubelet.service
           └─12569 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-dri

Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322762   12569 kuberuntime_sandbox.go:68] CreatePodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)"
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322806   12569 kuberuntime_manager.go:692] createPodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322872   12569 pod_workers.go:190] Error syncing pod ecae9d12d3610192347be3d1aa5aa552 ("kube-scheduler-warp02_kube-system(ecae9d12d36101
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.373094   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.375587   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.473295   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.573567   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.575495   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.RuntimeClass: Get https://10.1.1.4:6
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.590886   12569 event.go:249] Unable to write event: 'Post https://10.1.1.4:6443/api/v1/namespaces/default/events: dial tcp 10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.673767   12569 kubelet.go:2248] node "warp02" not found

これらのベアメタルマシンには複数のNICがあることに注意してください。

warproot<strong i="6">@warp02</strong>:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:feff:fe65:37f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:fe:65:03:7f  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 516 (516.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.2  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::32b5:c2ff:fe02:410b  prefixlen 64  scopeid 0x20<link>
        ether 30:b5:c2:02:41:0b  txqueuelen 1000  (Ethernet)
        RX packets 46  bytes 5821 (5.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70  bytes 7946 (7.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.4  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 fd42:59ff:1166:0:25a7:3617:fee6:424e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x20<link>
        inet6 fd9e:fdd6:9e01:0:1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x0<global>
        ether 18:03:73:44:56:94  txqueuelen 1000  (Ethernet)
        RX packets 911294  bytes 1361047672 (1.3 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 428759  bytes 29198065 (29.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

ib0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-10-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ib1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-20-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 25473  bytes 1334779 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25473  bytes 1334779 (1.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

それが問題かどうかはわかりませんが、 /etc/hostsファイルを次のように設定しました

warproot<strong i="7">@warp02</strong>:~$ cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
# add our host name
10.1.1.4 warp02 warp02.ad.xxx.com
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
# add our ipv6 host name
fd42:59ff:1166:0:25a7:3617:fee6:424e warp02 warp02.ad.xxx.com

warproot<strong i="8">@warp02</strong>:~$ 

したがって、NIC 10.1.1.4をk8sの「ネットワーク」と見なすように設定されています（私は思います）

node-nameに対するnslookupは正常に機能しているようです。

warproot<strong i="13">@warp02</strong>:~$ nslookup warp02
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   warp02.ad.xxx.com
Address: 10.1.1.4
Name:   warp02.ad.xxx.com
Address: fd42:59ff:1166:0:25a7:3617:fee6:424e

warproot<strong i="14">@warp02</strong>:~$ 

kubeadmインストールドキュメントを何度か読んだことがあります。

変。 ネットワークが見つかりません。

困惑。

バージョン1.15.3 Ubuntu18.04でこれを追加することで修正できました。

kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    cgroup-driver: "systemd"

私のkubeadm設定に移動し、 kubeadm init

Ubuntu18.04のバージョン1.15.3で同じ問題が発生します
@ kris-novaこの設定ファイルの場所を指定していただければ幸いです:-)

更新：理由はわかりませんが、構成を変更しなくても機能するようになりました。
（注：関連しているかどうかはわかりませんが、 kubeadm init再試行する前に、dockerをv.19.03.1からv.19.03.2に更新しました）

kubeadm initの実行中にエラーが発生していました。つまり、nodexxが見つかりませんでした。

[ root @ node01〜 ] ＃journalctl -xeu kubelet
11月7日10：34：02node01 kubelet [2968]：E1107 10：34：02.682095 2968kubelet.go：2267]ノード "node01"が見つかりません
11月7日10：34：02node01 kubelet [2968]：E1107 10：34：02.782554 2968kubelet.go：2267]ノード "node01"が見つかりません
11月7日10：34：02node01 kubelet [2968]：E1107 10：34：02.829142 2968 Reflector.go：123] k8s.io/client-go/informers/factory.go:134：*v1beta1.CSIDの一覧表示に失敗しました
11月7日10：34：02node01 kubelet [2968]：E1107 10：34：02.884058 2968kubelet.go：2267]ノード "node01"が見つかりません
11月7日10：34：02node01 kubelet [2968]：E1107 10：34：02.984510 2968kubelet.go：2267]ノード "node01"が見つかりません
11月7日10：34：03node01 kubelet [2968]：E1107 10：34：03.030884 2968 Reflector.go：123]

解決：

setenforce 0

sed -i --follow-symlinks's / SELINUX = enforcing / SELINUX = disabled / g '/ etc / sysconfig / selinux

同じ問題

私の場合、これはマスターノードの時間ドリフトが原因でした。これは_電源遮断後に発生しました_。
実行して修正しました

# Correcting the time as mentioned here https://askubuntu.com/a/254846/861548
sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start
# Then restarting the kubelet
sudo systemctl restart kubelet.service
# I also had to run daemon-reload as I got the following warning
# Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.
sudo systemctl daemon-reload
# I also made another restart, which I don't know whether needed or not
sudo systemctl restart kubelet.service

同じ問題を修正しましたnode "xxxx" not found 、コンテナログがdocker logs container_idを使用していることを確認してから、apiserverが127.0.0.1:2379に接続しようとしていることを確認し、ファイルを編集します・/etc/kubernetes/manifests/etcd.yaml 、再起動、問題が修正されました。