@bravinash Apa keluaran dari kubectl -n kube-system describe pod <coredns-pod-name> ?

Saya akan mencobanya nanti hari ini, saya sendiri.

@bravinash saya tidak dapat mengonfirmasi masalah:

NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   calico-node-x2l7f                    2/2     Running   0          93s
kube-system   coredns-576cbf47c7-6qn92             1/1     Running   0          93s
kube-system   coredns-576cbf47c7-vk2h5             1/1     Running   0          93s
kube-system   etcd-luboitvbox                      1/1     Running   0          41s
kube-system   kube-apiserver-luboitvbox            1/1     Running   0          35s
kube-system   kube-controller-manager-luboitvbox   1/1     Running   0          45s
kube-system   kube-proxy-np5s4                     1/1     Running   0          93s
kube-system   kube-scheduler-luboitvbox            1/1     Running   0          58s

semuanya 1.12.1, control-plane, kubeadm, kubelet.
berikan detail lebih lanjut tentang penyiapan Anda.

/ prioritas menunggu-lebih banyak bukti

@bravinash dapatkah Anda menampilkan log dari pod crashlooping: kubectl logs -n kube-system <coredns pod name> .
Anda dapat melihat pod core-dns seperti ini: kubectl get pods -n kube-system |grep coredns

Direproduksi:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

$ dpkg -l |grep kube
ii  kubeadm                               1.12.1-00                         amd64        Kubernetes Cluster Bootstrapping Tool
ii  kubectl                               1.12.1-00                         amd64        Kubernetes Command Line Tool
ii  kubelet                               1.12.1-00                         amd64        Kubernetes Node Agent
ii  kubernetes-cni                        0.6.0-00                          amd64        Kubernetes CNI

$ uname -a
Linux ed-ipv6-1 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# kubeadm init --pod-network-cidr=192.168.0.0/16
...
You can now join any number of machines by running the following on each node
as root:
...

$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

$ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
clusterrole.rbac.authorization.k8s.io/calico-node created
$ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
configmap/calico-config created
service/calico-typha created
deployment.apps/calico-typha created
daemonset.extensions/calico-node created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
serviceaccount/calico-node created

$ kubectl get pods -n kube-system
NAME                                READY   STATUS             RESTARTS   AGE
calico-node-q6k75                   2/2     Running            0          2m20s
coredns-576cbf47c7-gk59b            0/1     CrashLoopBackOff   3          27m
coredns-576cbf47c7-vz5kc            0/1     CrashLoopBackOff   3          27m
etcd-ed-ipv6-1                      1/1     Running            0          26m
kube-apiserver-ed-ipv6-1            1/1     Running            0          26m
kube-controller-manager-ed-ipv6-1   1/1     Running            0          26m
kube-proxy-8dw78                    1/1     Running            0          27m
kube-scheduler-ed-ipv6-1            1/1     Running            0          26m

$ kubectl logs -n kube-system coredns-576cbf47c7-gk59b
.:53
2018/10/09 10:41:59 [INFO] CoreDNS-1.2.2
2018/10/09 10:41:59 [INFO] linux/amd64, go1.11, eb51e8b
CoreDNS-1.2.2
linux/amd64, go1.11, eb51e8b
2018/10/09 10:41:59 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/10/09 10:42:05 [FATAL] plugin/loop: Seen "HINFO IN 
XXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXX." more than twice, loop detected 

sepertinya ini disebabkan oleh penyelesaian systemd:

# grep nameserver /etc/resolv.conf 
nameserver 127.0.0.53

@bravinash tolong, konfirmasikan bahwa masalahnya sama di penyiapan Anda.

Jika sama, Anda dapat mencoba mengarahkan kubelet ke resolv.conf asli dengan cara ini:

$ echo -e '[Service]\nEnvironment="KUBELET_EXTRA_ARGS=--resolv-conf=/run/systemd/resolve/resolv.conf"\n' | sudo tee /etc/systemd/system/kubelet.service.d/99-local.conf
$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet

dan hapus coredns pod:

$ kubectl get pods -n kube-system -oname |grep coredns |xargs kubectl delete -n kube-system

Kubelet akan memulainya lagi dengan konfigurasi baru.

Setidaknya ini memperbaiki masalah di penyiapan saya:

$ kubectl get pods -n kube-system
NAME                                READY   STATUS    RESTARTS   AGE
calico-node-cpsqz                   2/2     Running   0          5m20s
coredns-576cbf47c7-2prpv            1/1     Running   0          18s
coredns-576cbf47c7-xslbx            1/1     Running   0          18s
etcd-ed-ipv6-1                      1/1     Running   0          17m
kube-apiserver-ed-ipv6-1            1/1     Running   0          17m
kube-controller-manager-ed-ipv6-1   1/1     Running   0          17m
kube-proxy-8dkqt                    1/1     Running   0          17m
kube-scheduler-ed-ipv6-1            1/1     Running   0          17m

hai, @ bart0sh
bukankah --resolv-conf=/run/systemd/resolve/resolv.conf diisi dengan benar di kubeadm init di /var/lib/kubelet/kubeadm-flags.env ?

https://kubernetes.io/docs/setup/independent/kubelet-integration/#the -kubelet-drop-in-file-for-systemd

/ hapus-prioritas-menunggu-lebih-bukti

@ neolit123 itu adalah:

$ cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=cgroupfs --network-plugin=cni --resolv-conf=/run/systemd/resolve/resolv.conf

Terima kasih telah menunjukkan hal itu kepada saya. Bisa jadi masalahnya berbeda atau resolv.conf asli juga memicunya.

aneh, ini berfungsi dengan baik pada VM saya - ini adalah Ubuntu 17.10 dan juga telah diselesaikan systemd.

Pada resolv.conf asli sistem saya juga memicu masalah yang sama. Ini mulai berfungsi setelah menyalinnya ke file lain, menghapus salah satu dari 3 baris server nama darinya dan mengubah opsi --resolv-conf di /var/lib/kubelet/kubeadm-flags.env

Bagaimanapun, kami memerlukan konfirmasi dari @bravinash bahwa masalahnya sama.
Sepertinya bukan masalah Kubeadm bagi saya.

/var/lib/kubelet/kubeadm-flags.env ditulis ulang setiap kali kubeadm init berjalan, btw.
itu poin saya dari sebelumnya.

/ jenis bug
/ sig network
/ ekosistem area

Ini sangat aneh, saya secara konsisten dapat mereproduksi masalah ini hingga sekarang. Saya menerapkan ulang Ubutnu 18.04 saya dengan 1.12.1 (kubelet kubeadm kubectl)
Sekarang ini berhasil ..

root @ k8s-1121 : ~ # cat /etc/resolv.conf

File ini dikelola oleh man: systemd-diselesaikan (8). Jangan diedit.

#

Ini adalah file resolv.conf dinamis untuk menghubungkan klien lokal ke

pemecah rintisan DNS internal dari systemd-diselesaikan. File ini mencantumkan semua

domain pencarian yang dikonfigurasi.

#

Jalankan "systemd-resol --status" untuk melihat detail tentang server DNS uplink

sedang digunakan.

#

Program pihak ketiga tidak boleh mengakses file ini secara langsung, tetapi hanya melalui

symlink di /etc/resolv.conf. Untuk mengelola man: resolv.conf (5) dengan cara yang berbeda,

ganti symlink ini dengan file statis atau symlink yang berbeda.

#

Lihat man: systemd-diselesaikan.service (8) untuk detail tentang mode yang didukung dari

operasi untuk /etc/resolv.conf.

server nama 127.0.0.53
cari exu.ericsson.se

root @ k8s-1121 : ~ # cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS = - cgroup-driver = systemd --network-plugin = cni --resolv-conf = / run / systemd / selesaikan / resolv.conf

root @ k8s-1121 : ~ # kubectl dapatkan pods --all-namespaces
NAMESPACE NAMA STATUS SIAP DIMULAI USIA
kube-system calico-etcd-r5wrw 1/1 Berjalan 0 6m52s
kube-system calico-kube-controllers-f4dcbf48b-7lvvn 1/1 Berjalan 0 7m7s
kube-system calico-node-qw9kx 2/2 Menjalankan 2 7m7s
kube-system coredns-576cbf47c7-wdxv2 1/1 Berjalan 0 7m52s
kube-system coredns-576cbf47c7-wjf2m 1/1 Berjalan 0 7m52s
kube-system etcd-k8s-1121 1/1 Berjalan 0 7m16s
kube-system kube-apiserver-k8s-1121 1/1 Berjalan 0 7m14s
kube-system kube-controller-manager-k8s-1121 1/1 Berjalan 0 7m8s
kube-system kube-proxy-g879x 1/1 Menjalankan 0 7m52s
kube-system kube-scheduler-k8s-1121 1/1 Berjalan 0 7m

Saya akan mencoba beberapa hal lagi untuk mereproduksi ini lagi ..

Salam,
Avinash

Dari: Ed Bartosh [email protected]
Dikirim: Selasa, 9 Oktober 2018 06.56
Ke: kubernetes / kubeadm [email protected]
Cc: Avinash Raghavendra [email protected] ; Sebutkan [email protected]
Subjek: Re: [kubernetes / kubeadm] CoreDNS Crashloop Error - 1.12.1 (# 1162)

Pada resolv.conf asli sistem saya juga memicu masalah yang sama. Ini mulai berfungsi setelah menyalinnya ke file lain, menghapus salah satu dari 3 baris server nama darinya dan mengubah opsi --resolv-conf di /var/lib/kubelet/kubeadm-flags.env

Bagaimanapun, kami memerlukan konfirmasi dari @bravinash https://github.com/bravinash bahwa masalahnya sama.
Sepertinya bukan masalah Kubeadm bagi saya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/kubernetes/kubeadm/issues/1162#issuecomment-428163873 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AdD2Qj7- CqRCRK8rWeHWoULUMGlim2IQks5ujI7igaJpZM4XMP-f .

Saya akan mengusulkan untuk menutup masalah ini karena 2 alasan:

• ini lebih banyak inti daripada masalah Kubeadm
• itu tidak dapat direproduksi lagi

@bravinash Anda dapat membuka kembali masalah ini jika Anda melihatnya lagi

Saya akan menutup masalah ini untuk saat ini karena ini tidak dapat direkonstruksi lagi.

FWIW (terlambat ke percakapan, mengomentari masalah tertutup), Di CoreDNS kesalahan ini diharapkan ketika loop terdeteksi ... dan perilaku, seperti yang dirancang, untuk keluar ketika ini terjadi. K8s mendeteksi ini sebagai "crash".

2018/10/09 10:41:59 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/10/09 10:42:05 [FATAL] plugin/loop: Seen "HINFO IN XXX.XXX." more than twice, loop detected 

ini lebih banyak inti daripada masalah Kubeadm

CoreDNS tidak dapat secara otomatis menyelesaikan lingkungan yang dikonfigurasi dengan buruk. Jadi, masalahnya terletak pada apa pun / siapa pun yang bertanggung jawab untuk mengonfigurasi berbagai hal.

FWIW, saya mendapatkan masalah yang sama persis saat mencoba membuat master kube dengan kubeadm init di ubuntu 18.04.
Jika memang demikian, systemd dns menghalangi, maka itu masih membutuhkan beberapa jenis penyelesaian ...

@jwatte sayangnya kami tidak dapat mereproduksi masalah tersebut. Jika Anda dapat menunjukkan kepada kami log dari core-dns pod, saya akan dengan senang hati menjelaskan masalah ini lebih jauh.

@jwatte , Dengan asumsi Anda melihat kesalahan "loop terdeteksi" di log, kubeadm seharusnya secara otomatis mendeteksi masalah systemd-resolved , dan mengatur kubelet dengan file resolv.conf . Jika tidak, Anda dapat mencoba salah satu solusi manual yang tercantum dalam dokumen plugin loop CoreDNS.

@tokopedia

kubeadm seharusnya secara otomatis mendeteksi masalah yang terselesaikan systemd, dan mengatur kubelet dengan file resolv.conf yang benar

ini sudah selesai

Silakan, periksa apakah sudah selesai di penyiapan Anda. btw, versi kubeadm mana yang Anda gunakan?

Saya menggunakan versi rilis hari ini untuk semuanya.
versi kubeadm: & version.Info {Mayor: "1", Minor: "12", GitVersion: "v1.12.1", GitCommit: "4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState: "clean", BuildDate: "2018-10-05T16: 43: 08Z ", GoVersion:" go1.10.4 ", Penyusun:" gc ", Platform:" linux / amd64 "}

Namun, hal khusus yang saya lakukan adalah mengedit perintah kubelet start-up untuk menggunakan kubenet daripada gcn, karena itu konfigurasi prod kami dan saya ingin tetap dekat.
Namun, tidak peduli bagaimana saya mengotak-atik konfigurasi dan replikasi coredns, saya tidak bisa membuatnya tidak berputar. Saya akhirnya menyeka dan memasang gcn dan flanel, dan itu berfungsi seperti yang diharapkan.

Saya akhirnya menyeka dan memasang gcn dan flanel, dan itu berfungsi seperti yang diharapkan.

Saya biasanya menggunakan Weave Net dalam pengaturan pengembangan saya dan berfungsi dengan baik. Ketika saya beralih ke calico untuk mereproduksi bug ini pod core-dns mulai crashlooping karena deteksi loop. Menghapus salah satu server nama dari resolv.conf memperbaiki masalah saya.

Jadi, maksud saya adalah: sampai kami dapat mereproduksi ini dan memahami cara memperbaikinya, saya rasa kita tidak dapat melangkah lebih jauh dengan ini. Saya masih mendapat kesan bahwa ini bukan masalah kubeadm. Dalam kasus saya, itu adalah masalah infrastruktur.

Pandangan saya adalah bahwa itu ada di suatu tempat di bagian "dokumentasi" dan "diagnosabilitas", yang dapat diselesaikan dengan kubernetes. Ketika saya mendapatkan kesalahan ini: Lalu apa? Apa penyebabnya? Apa masalah umum? Apa yang dapat saya lakukan untuk mendapatkan wawasan lebih jauh tentang penyebab masalah ini? Googling pesan kesalahan dan mendapatkan utas ini sebagai referensi utama menunjukkan bahwa kebutuhan tersebut belum diselesaikan oleh penawaran kubernetes secara keseluruhan.

Secara terpisah: Mengapa dua server nama di resolv.conf menyebabkan masalah ini? Sems itu seperti konfigurasi yang benar-benar sah dan umum yang harus ditoleransi oleh komponen kubernetes.

Mengapa dua server nama di resolv.conf menyebabkan masalah ini?

Ada 3 server nama di resolv.conf saya. Menghapus satu server tertentu memecahkan masalah. Menghapus yang lain tidak. Jadi, saya memutuskan bahwa loop entah bagaimana dibuat oleh server itu.

Pandangan saya adalah bahwa itu ada di suatu tempat di bagian "dokumentasi" dan "diagnosabilitas", yang dapat diselesaikan dengan kubernetes. Ketika saya mendapatkan kesalahan ini: Lalu apa? Apa penyebabnya? Apa masalah umum?

Ada ini ... bagian yang baru ditambahkan tentang pemecahan masalah dalam plugin loop. Versi terbaru dari CoreDNS menunjukkan hal ini dalam pesan kesalahan.

Saya baru saja memperhatikan bahwa proses konversi README.md -> webpage.html kami bermasalah, jadi beberapa pemformatan rusak pada versi coredns.io. Yang asli ada di sini ... https://github.com/coredns/coredns/blob/master/plugin/loop/README.md

juga sebagai referensi (jika belum diposting)

halaman pemecahan masalah kubeadm memiliki bagian yang terkait dengan CrashLoopBackoff dari CoreDNS yang disebabkan oleh SELinux:
https://kubernetes.io/docs/setup/independent/troubleshooting-kubeadm/#coredns -pods-have-crashloopbackoff-or-error-state

kubectl -n kube-system mendeskripsikan pod

Acara:
Ketik Alasan Usia Dari Pesan
---- ------ ---- ---- -------
Normal Scheduled 114s default-scheduler Berhasil menetapkan kube-system / coredns-5b4dd968b9-mqhvc ke cap166
Normal Pulled 49s (x4 over 114s) kubelet, cap166 Container image "k8s.gcr.io/ coredns: 1.2.2 " sudah ada di mesin
Normal Dibuat 49s (x4 selama 114s) kubelet, cap166 Membuat container
Normal Dimulai 49s (x4 selama 114s) kubelet, cap166 Container dimulai
Peringatan BackOff 9s (x8 lebih dari 100s) kubelet, cap166 Back-off restart container gagal

Saya membagikan solusi yang berhasil untuk saya di sini: https://stackoverflow.com/a/53414041/1005102

@utku

ps auxww | grep kubelet
Anda mungkin melihat baris seperti:
/ usr / bin / kubelet ... --resolv-conf = / run / systemd / resolv.conf

kalau tidak:
cat /var/lib/kubelet/kubeadm-flags.env
kubeadm menulis flag --resolv-conf di file itu setiap kali menjalankan join dan init.

Kesalahan loop CoreDNS baru saja terjadi pada saya dengan Ubuntu 18.04 / kubeadm ketika saya telah menentukan IP node seperti ini:
cat> / etc / default / kubelet < KUBELET_KUBEADM_ARGS = "- node-ip = 192.168.10.11"
EOF

Memindahkan perintah --node-ip ke /etc/systemd/system/kubelet.service.d/10-kubeadm.conf menyelesaikan masalah pengulangan:
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --node-ip=192.168.10.11
(konten file / etc / default / kubelet sekarang adalah "KUBELET_EXTRA_ARGS =")

core-dns saya ada di CrashLoopBackOff.
lognya adalah:

E0401 16: 54: 47.487196 1 reflector.go: 134] github.com/coredns/coredns/plugin/kubernetes/controller.go:317: Gagal mencantumkan * v1.Endpoints: Dapatkan https://10.96.0.1 : 443 / api / v1 / endpoints? limit = 500 & resourceVersion = 0: dial tcp 10.96.0.1:443: i / o timeout
log: keluar karena kesalahan: log: tidak dapat membuat log: buka /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: tidak ada file atau direktori seperti itu

Saya memiliki ubuntu 18 dan kubernetes v1.14 + flanel, semua pod lainnya sedang berjalan

@pmehdinejad , Kesalahan itu berarti kubernetes API Anda tidak dapat dijangkau.

@pmehdinejad , Kesalahan itu berarti kubernetes API Anda tidak dapat dijangkau.

Saya pikir itu untuk sebelum saya mengatur flanel, kesalahan terbaru adalah yang ini:
log: keluar karena kesalahan: log: tidak dapat membuat log: buka /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: tidak ada file atau direktori seperti itu

versi coredns?

versi coredns?

k8s.gcr.io/ coredns: 1.3.1

Coba 1.4.0 untuk melihat apakah ada yang berperilaku berbeda. Mungkin terkait dengan masalah glog / klog yang kami perbaiki di 1.4.0.

Coba 1.4.0 untuk melihat apakah ada yang berperilaku berbeda. Mungkin terkait dengan masalah glog / klog yang kami perbaiki di 1.4.0.

Tampaknya diperbaiki dengan 1.4
Hargai bantuannya

@pmehdinejad , Kesalahan itu berarti kubernetes API Anda tidak dapat dijangkau.

Saya pikir itu untuk sebelum saya mengatur flanel, kesalahan terbaru adalah yang ini:
log: keluar karena kesalahan: log: tidak dapat membuat log: buka /tmp/coredns.coredns-fb8b8dccf-v6wkw.unknownuser.log.ERROR.20190401-165447.1: tidak ada file atau direktori seperti itu

Masih mendapatkan kesalahan ini:
Dapatkan https://10.96.0.1 : 443 / api / v1 / namespaces? Limit = 500 & resourceVersion = 0: dial tcp 10.96.0.1:443: i / o timeout

Aneh karena semua pod lain sedang berjalan termasuk kube-proxy, kube-apiserver, dan flannel

@pmehdinejad , kesalahan ini berarti CoreDNS tidak dapat menjangkau API Kubernetes. Mungkin ada yang salah dengan flanel atau kube-proxy (yang memungkinkan koneksi).

@pmehdinejad , kesalahan ini berarti CoreDNS tidak dapat menjangkau API Kubernetes. Mungkin ada yang salah dengan flanel atau kube-proxy (yang memungkinkan koneksi).

Ya, saya melakukan telnet dari host, saya mencoba menerapkan pod dan menjalankannya dari cangkangnya, tetapi sebagian besar gambar minimal dan tanpa inti saya tidak dapat menginstal apa pun di container.

Aneh karena baik flanel dan proxy berfungsi dan yang dapat saya lihat di log mereka adalah ini:

Flanel:

I0402 14: 24: 26.014844 1 iptables.go: 155] Menambahkan aturan iptables: -s 10.244.0.0/16 -d 10.244.0.0/16 -j RETURN
I0402 14: 24: 26.113264 1 iptables.go: 155] Menambahkan aturan iptables: -s 10.244.0.0/16! -d 224.0.0.0/4 -j MASQUERADE --random-fully
I0402 14: 24: 26.115211 1 iptables.go: 155] Menambahkan aturan iptables:! -s 10.244.0.0/16 -d 10.244.1.0/24 -j RETURN
I0402 14: 24: 26.117448 1 iptables.go: 155] Menambahkan aturan iptables:! -s 10.244.0.0/16 -d 10.244.0.0/16 -j MASQUERADE --random-fully

kube-proxy:

E0402 15: 11: 19.584081 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Gagal mencantumkan * v1. Titik akhir: Tidak sah
E0402 15: 11: 20.585880 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Gagal mencantumkan * v1. Layanan: Tidak Resmi
E0402 15: 11: 20.586590 1 reflector.go: 126] k8s.io/client-go/informers/factory.go:133: Gagal mencantumkan * v1. Titik akhir: Tidak sah

Saya bukan ahli kube-proxy, tapi menurut saya pesan kesalahan itu tidak normal untuk kube-proxy.

Saya bertemu masalah serupa. Coredns crashloop dan juga menyebabkan dashboard crashloop. Ini berfungsi setelah saya mengatur jaringan ke flanel, dan semua nama host PC di / etc / hosts.

Saya memiliki 3 PC dan saya mengonfigurasi ketiga PC sebagai master dan node. Satu PC berada di belakang gateway rumah saya, dua lainnya di belakang firewall corp. Ketiga PC tersebut terhubung dalam VPN. Jika pengaturan jaringan default digunakan oleh kubespray, pod coredns berfungsi saat diterapkan pada PC di rumah saya, dan akan macet jika tidak.

Saya mencoba yang berikut ini:

• (GAGAL) resolv.conf: Saya mengubah file /etc/systemd/system/kubelet.service.d/99-local.conf, dan /run/systemd/resolve/resolv.conf, atau /etc/resolv.conf tidak akan berhasil
• (GAGAL) /var/lib/kubelet/kubeadm-flags.env, menyetel ke /etc/resolv.conf
• (GAGAL) /etc/systemd/resolved.conf, mengubah DNS, dan tidak berfungsi.
• (SUKSES) menggunakan flanel, dan meletakkan semua nama host PC ke / etc / hosts

Jadi apakah ini masalah jaringan default calico?