/ cc @lukemarsden @luxas @mikedanese

Jika kita mengembalikan #43474 sepenuhnya, kita berada dalam situasi lagi di mana kita merusak plugin 0.2.0 CNI (lihat https://github.com/kubernetes/kubernetes/issues/43014)

Haruskah kita mempertimbangkan untuk melakukan sesuatu seperti https://github.com/kubernetes/kubernetes/pull/43284?

Juga /cc @thockin

/ cc @ kubernetes / sig-network-bugs

Ref: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda bisakah saya mendapatkan beberapa log kubelet dengan --loglevel=5?

@yujuhong -- Anda menyebutkan bahwa menurut Anda ini berfungsi sebagaimana mestinya. Bagaimanapun, kubeadm bergantung pada perilaku ini. Kami memperkenalkan perubahan besar dengan #43474. Kita dapat berbicara tentang cara yang tepat untuk memperbaikinya untuk 1.7 tetapi, untuk saat ini, kita perlu membuat kubeadm berfungsi kembali.

Diskusi kendur sedang berlangsung sekarang -- https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Sepertinya DaemonSets akan tetap dijadwalkan meskipun node belum siap. Ini benar-benar, dalam hal ini, kubeadm menjadi sedikit terlalu paranoid.

Rencana saat ini yang akan kita uji adalah membuat kubeadm tidak lagi menunggu master node siap tetapi hanya mendaftarkannya. Ini harus cukup baik untuk memungkinkan CNI DaemonSet dijadwalkan untuk menyiapkan CNI.

@kensimon sedang menguji ini.

@jbeda ya, sepertinya pengontrol DaemonSet masih akan mengantrekan mereka terutama karena sama sekali tidak mengetahui jaringan. Kita harus benar-benar memperbaiki ini secara lebih umum. Apakah ada sesuatu yang harus segera dilakukan di kube atau semuanya ada di kubeadm untuk saat ini?

Saya mencoba menginstal kubernetes dengan kubeadm di Ubuntu 16.04. Apakah ada perbaikan cepat untuk ini?

@jbeda jika Anda memiliki versi yang ditambal dengan senang hati mengujinya..

Saya memiliki kubeadm yang melewati status NotReady node, tetapi penyebaran dummy yang dibuatnya tidak berfungsi karena taint node.alpha.kubernetes.io/notReady mencegahnya berjalan. Menambahkan toleransi sepertinya tidak membantu, saya tidak yakin bagaimana melanjutkannya pada saat ini. Adakah yang bisa menjelaskan cara men-deploy pod yang mentolerir taint notReady ?

Saya sedang menjajaki beberapa opsi lain seperti tidak menandai node sebagai notReady, tetapi tidak jelas apa yang ingin kami lakukan.

kami mengatasinya dengan menghapus KUBELET_NETWORK_ARGS dari baris perintah kubelet. setelah itu kubeadm init berfungsi dengan baik dan kami dapat menginstal plugin canal cni.

@sbezverk tolong jelaskan bagaimana melakukan itu?

Dapat mengkonfirmasi temuan @sbezverk (good find :) ), menyesuaikan /etc/systemd/system/10-kubeadm.conf dan menghapus KUBELET_NETWORK_ARGS akan membuatnya berjalan di centos. Diuji dengan menenun.

@overip Anda perlu mengedit /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

hapus $ KUBELET_NETWORK_ARGS

dan kemudian restart kubelet setelah itu bebeadm init akan berfungsi.

ini yang saya lakukan

reset kubeadm

hapus entri ENV dari:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

muat ulang layanan systemd dan kube

systemctl daemon-reload
systemctl restart kubelet.service

jalankan kembali init

kubeadm init

Semua benar, dan sementara kita melakukannya

Jika Anda melihat ini:
kubelet: error: gagal menjalankan Kubelet: gagal membuat kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" berbeda dengan docker cgroup driver: "systemd"

anda harus mengedit /etc/systemd/system/kubelet.service.d/10-kubeadm.conf dan menambahkan flag --cgroup-driver="systemd"

dan lakukan seperti di atas

kuebadm reset
systemctl daemon-reload
systemctl restart kubelet.service
kubeadm init.

Saya akan berhati-hati menghapus --network-plugin=cni dari flag kubelet CLI, ini menyebabkan kubelet menggunakan plugin no_op secara default... Saya akan terkejut jika plugin umum seperti calico/weave akan bekerja dalam kasus ini (tetapi sekali lagi pemahaman saya tentang bagaimana plugin ini beroperasi di bawahnya agak terbatas.)

@kensimon hm, belum melihat masalah apa pun pada pengaturan saya, saya menggunakan plugin canal cni dan berfungsi dengan baik ..

@sbezverk Apakah jaringan lintas host juga berfungsi dengan baik?

@resouer tidak dapat mengonfirmasi, saya hanya memiliki 1.6.0 sebagai All-In-One.

@resouer @sbezverk Saya berhasil bergabung dengan mesin.

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

``` [ root@deploy-01 x86_64]# kubectl get pod -n kube-system
NAMA STATUS SIAP RESTART USIA
etcd-deploy-01 1/1 Menjalankan 0 50m
kube-apiserver-deploy-01 1/1 Menjalankan 0 51m
kube-controller-manager-deploy-01 1/1 Berjalan 0 50m
kube-dns-3913472980-6plgh 3/3 Lari 0 51m
kube-proxy-mbvdh 1/1 Berjalan 0 4m
kube-proxy-rmp36 1/1 Berjalan 0 51m
kube-scheduler-deploy-01 1/1 Lari 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 Berjalan 0 24m
weave-net-3t487 2/2 Lari 0 44m
weave-net-hhcqp 2/2 Lari 0 4m

```

solusi bekerja tetapi tidak bisa membuat flanel berjalan ...

@stevenbower skenario terburuk, Anda dapat mengembalikan pengaturan ini dan memulai ulang kubelet ketika Anda selesai dengan bisnis kubeadm..

Saya mendapatkan kluster tiga simpul dengan weave berfungsi. Tidak yakin seberapa stabil ini dengan peretasan ini, tetapi terima kasih! :senyum:

Di simpul samping, Anda dapat meletakkan kembali $KUBELET_NETWORK_ARGS, setelah init pada master lewat. Saya sebenarnya tidak menghapusnya di mesin tempat saya bergabung, hanya cgroup-driver, jika tidak kubelet dan buruh pelabuhan tidak akan bekerja bersama.

Tetapi Anda tidak perlu mengatur ulang kubeadm, cukup ubah /etc/systemd/system/kubelet.service.d/10-kubeadm.conf dan lakukan dance systemctl:

systemctl daemon-reload
systemctl restart kubelet.service

Bagi Anda yang menjatuhkan KUBELET_NETWORK_ARGS dan melaporkannya berhasil untuk Anda:

Bagi saya, saya memiliki 2 cluster: satu di mana saya menerapkan tambalan dari https://github.com/kubernetes/kubernetes/pull/43824 dan membiarkan kubeadm melanjutkan secara normal pada inisialisasi, dan satu dengan KUBELET_NETWORK_ARGS dihapus. Pada cluster dengan KUBELET_NETWORK_ARGS dihapus, lalu lintas apa pun di antara pod akan gagal.

Pada kluster dengan KUBELET_NETWORK_ARGS dihapus:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

Pada cluster dengan KUBELET_NETWORK_ARGS normal tetapi dengan kubeadm yang ditambal:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Jika Anda salah satu dari mereka yang menonaktifkan KUBELET_NETWORK_ARGS, periksa apakah hal di atas berhasil untuk Anda.

Saya menyarankan agar kita menjatuhkan node ready dan dummy deployment check
sama sekali untuk 1.6 dan memindahkannya ke fase validasi untuk 1.7.

Pada 29 Mar 2017 10:13, "Dan Williams" [email protected] menulis:

@jbeda https://github.com/jbeda ya, sepertinya DaemonSet
pengontrol masih akan membuat mereka mengantre terutama karena itu benar-benar bodoh
dari jaringan-iness. Kita harus benar-benar memperbaiki ini secara lebih umum. Disana
sesuatu yang harus segera dilakukan di kube atau semuanya ada di kubeadm untuk saat ini?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Adakah orang lain yang menjalankan Ubuntu 16.04? Saya telah menghapus KUBELET_NETWORK_ARGS dari layanan systemd dan memuat ulang daemon systemd . Saya dapat memunculkan simpul master tetapi tidak dapat bergabung dengan simpul. Gagal dengan kesalahan The requested resource is unavailable

KUBELET_NETWORK_ARGS dihapus, lalu lintas antar pod gagal.

Saya tidak akan terkejut karena KUBELET_NETWORK_ARGS memberi tahu kubelet plugin apa yang digunakan, di mana mencari konfigurasi dan binari. Anda MEMBUTUHKAN mereka.

Saya merekomendasikan #43835 (dan 1.6 cherry pick #43837) sebagai perbaikan yang kami buat untuk 1.6. Saya menguji keduanya dan mereka bekerja. Saya telah menugaskan @jbeda dan @luxas untuk meninjau ketika mereka bangun.

Kedua PR itu terlihat masuk akal. Tapi saya pikir kita harus melihat pergi dengan https://github.com/kubernetes/kubernetes/pull/43824 sebagai gantinya. Meskipun sedikit lebih rumit, ia mempertahankan jalur kode itu sehingga pengguna yang melakukan prakonfigurasi CNI di luar menggunakan Daemonset (saya melakukan ini di https://github.com/jbeda/kubeadm-gce-tf meskipun saya belum melakukannya memperbaruinya ke 1.6) masih menunggu node siap.

Sebagai bonus, ini adalah @kensimon 's PR pertama yang Kubernetes dan dia telah mengeluarkan berhenti untuk menguji hal ini. Tapi, sejujurnya, keduanya bisa diterapkan dan saya benar-benar ingin melihatnya diperbaiki. :)

Maaf saya melewatkan https://github.com/kubernetes/kubernetes/pull/43824. Saya juga senang jika keduanya bekerja.

Saya juga senang jika keduanya bekerja juga

@kensimon Ini berfungsi untuk saya, ketika saya hanya menonaktifkan KUBELET_NETWORK_ARGS selama kubadm init . Berkat instruksi Anda, saya dapat memverifikasi itu.

Dikonfirmasi @webwurst untuk bekerja ketika Anda hanya menonaktifkan KUBELET_NETWORK_ARGS selama kubadm init . Saya harus me-restart kube-dns untuk mengambilnya. Pemeriksaan dari @kensimon berfungsi, dns

Meskipun saya setuju bahwa ini adalah peretasan yang mengerikan, dan terlalu mengerikan bagi kebanyakan orang untuk diikuti, melihat saluran yang kendur.

Solusi yang lebih baik disajikan oleh tambalan dari @kensimon atau @mikedanese.

@coeki bagaimana tepatnya Anda me-restart kube-dns. Saya mencoba kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system dan sekarang kube-dns tetap menunggu kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Itu persis seperti yang dijelaskan: hapus KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , tambahkan KUBELET_NETWORK_ARGS , lagi sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
Tapi kemudian tuanku tetap di NotReady . Dalam describe saya mendapatkan

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Saya mencoba restart kube-dns seperti dijelaskan di atas, tetapi tidak berhasil. Ada ide? Saya sekarat dalam hal ini, mencoba menjalankan cluster kami lagi setelah 1.6.0 gagal memutakhirkan morging ini :(

@patte Jadi saya hanya delete pods kube-dns-3913472980-3ljfx -n kube-system Dan kemudian kube-dns muncul lagi.

Apakah Anda setelah kubeadm init, menambahkan KUBELET_NETWORK_ARGS , lagi sudo systemctl daemon-reload && sudo systemctl restart kubelet.service menginstal jaringan pod, seperti weave atau belacu? Tambahkan itu dulu, Anda harus bisa membuatnya berfungsi.

Saya mencoba dan menguji pada centos7 dan baru saja melakukannya di ubuntu/xenial, jadi seharusnya berfungsi.

Untuk rekap apa yang saya lakukan:

hapus KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

tambahkan KUBELET_NETWORK_ARGS lagi
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

Bergabung dengan mesin, biasanya harus menambahkan rute statis ke 10.96.0.0 (cluster ip) karena saya gelandangan.
Gunakan dengan $TOKEN, tetapi langkah ini ekstra.

Kemudian:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Menunggu untuk itu

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

Bekerja untuk saya, meskipun ini adalah peretasan yang mengerikan;)

Saya sangat terkejut bahwa komunitas pengembangan kubernetes belum menyediakan ETA untuk perbaikan resmi. Maksud saya ini adalah bug mengerikan yang seharusnya mudah ditangkap selama pengujian kode. Karena belum, setidaknya, 1.6.1 harus didorong secepatnya dengan perbaikan sehingga orang akan berhenti meretas cluster mereka dan mulai melakukan hal-hal produktif ;). Apakah saya salah di sini?

Hai semua,

Saya sedikit terganggu minggu ini, dan ini adalah utas panjang yang penuh dengan
kubeadm hal-hal yang saya tidak tahu dengan baik. Dapatkah seseorang meringkas untuk saya? Saya
pikir saya mendapatkan inti dari bug, tetapi apa solusi yang diusulkan dan
apa yang membuat mereka mengerikan?

Pada Kam, 30 Mar 2017 jam 8:13, Serguei Bezverkhi < [email protected]

menulis:

Saya sangat terkejut bahwa komunitas pengembangan kubernetes belum
memberikan ETA apa pun untuk perbaikan resmi. Maksud saya ini adalah bug yang mengerikan yang
harus mudah ditangkap selama pengujian kode. Karena belum, di
paling tidak, 1.6.1 harus didorong secepatnya dengan perbaikan sehingga orang-orang akan
berhenti meretas kluster mereka dan mulailah melakukan hal-hal produktif ;). Apakah saya?
salah disini?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Perubahan pada kubelet (#43474) menyebabkan kubelet memulai dengan benar melaporkan jaringan yang belum siap sebelum plugin cni diinisialisasi. Ini memecahkan beberapa pemesanan yang kami andalkan dan menyebabkan kebuntuan dalam inisialisasi master kubeadm. Kami tidak menangkapnya karena tes kubeadm e2e telah rusak selama beberapa hari menjelang perubahan ini.

Perbaikan yang diusulkan saat ini adalah #43824 dan #43835.

oke, itu yang saya mengerti. Interlock antara plugin jaringan
datang dan kesiapan node sedikit buruk sekarang.

Pada Kam, 30 Mar 2017 jam 08:28, Mike Danese [email protected]
menulis:

Perubahan pada kubelet (#43474
https://github.com/kubernetes/kubernetes/pull/43474 ) menyebabkan kubelet
mulai dengan benar melaporkan jaringan yang belum siap sebelum plugin cni
diinisialisasi. Ini merusak beberapa pemesanan yang kami andalkan dan sebabkan
kebuntuan dalam inisialisasi master kubeadm. Kami tidak menangkapnya karena
tes kubeadm e2e telah rusak selama beberapa hari menjelang perubahan ini.

Perbaikan yang diusulkan saat ini adalah #43824
https://github.com/kubernetes/kubernetes/pull/43824 dan #43835
https://github.com/kubernetes/kubernetes/pull/43835 .

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

Saya masih lebih suka #43835. Ini adalah perubahan yang lebih sederhana, saya tidak berpikir pemeriksaan e2e harus dilakukan di tempat mereka berada, dan ada laporan #43824 masih tidak berfungsi. Saya akan mendorong untuk menyelesaikan ini hari ini.

+1 untuk menyelesaikannya hari ini karena banyak upaya yang terbuang untuk berurusan dengan jaminan dari solusi.

Saya tidak percaya tidak ada yang benar-benar mencoba kubeadm 1.6.0 sebelum 1.6.0 dirilis....

Dan, kubelet 1.5.6 + kubeadm 1.5.6 juga rusak, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf referensi /etc/kubernetes/pki/ca.crt tetapi kubeadm tidak menghasilkan ca.crt, ada cap.pem sekalipun.

Saat ini 1.6.0 dan 1.5.6 adalah satu-satunya rilis yang tersisa di repositori k8s apt...

"pecah dari kotak", kata-kata dipelajari hari ini.

Saya masih lebih suka #43835. Ini adalah perubahan yang lebih sederhana, saya tidak berpikir pemeriksaan e2e harus dilakukan di tempat mereka berada, dan ada laporan #43824 masih tidak berfungsi. Saya akan mendorong untuk menyelesaikan ini hari ini.

Setuju dengan Mike yang satu ini. #43835 adalah perubahan yang lebih sederhana, dan validasi (jika diperlukan) dapat dilakukan dalam fase terpisah.

@thockin kami sangat membutuhkan kondisi dan status yang lebih baik untuk jaringan, terutama dengan ho stNetwork:true. Node dapat siap untuk beberapa pod, tetapi tidak untuk yang lain.

Kami tidak dapat menggunakan nodeNetworkUnavailable, karena itu khusus untuk penyedia cloud. Kita mungkin membutuhkan yang lain, atau cara agar penjadwal mengizinkan ho stNetwork:true pod pada node dengan Net workReady:false , atau membuat taint berfungsi untuk node yang belum siap. Dan mengerjakan tes kubeadm e2e :(

Setuju. Saya telah menunda masalah karena saya tidak memiliki jawaban yang bagus,
tapi kita perlu mendapatkan ini dalam 1.7

Pada Kam, 30 Mar 2017 jam 10:02, Dan Williams [email protected]
menulis:

@thockin https://github.com/thockin kami benar-benar membutuhkan yang lebih halus
kondisi dan status untuk jaringan, terutama dengan ho stNetwork:true.
Node dapat siap untuk beberapa pod, tetapi tidak untuk yang lain.

Kami tidak dapat menggunakan nodeNetworkUnavailable, karena itu khusus untuk cloud
penyedia. Kami mungkin membutuhkan yang lain, atau cara untuk penjadwal untuk
izinkan ho stNetwork:true pod pada node dengan Net workReady:false , atau buat
taints berfungsi untuk node yang belum siap.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin ada solusi pilihan? Kita dapat memblokir kesiapan node dan mencari tahu siapa yang menggunakan IsNodeReady() seperti yang telah kita lakukan, atau kita dapat menambahkan kondisi node lain dan kemudian memperbaiki bit who-knows-how-many dari basis kode di tempat lain untuk itu. Atau mungkin ada pilihan lain.

Kami tidak dapat menggunakan nodeNetworkUnavailable, karena itu khusus untuk penyedia cloud. Kita mungkin membutuhkan yang lain, atau cara agar penjadwal mengizinkan ho stNetwork:true pod pada node dengan Net workReady:false , atau membuat taint berfungsi untuk node yang belum siap.

Saya pikir penjadwal dapat diperbaiki untuk menghormati noda dan toleransi, alih-alih mengesampingkan semua node yang belum siap sepenuhnya.
Seseorang harus menerapkan toleransi pada ho stNetwork:true pod. Saya tidak tahu siapa tetapi seharusnya bukan penjadwal karena mengajar penjadwal untuk memahami spesifikasi pod tampaknya terlalu banyak.

/cc @davidopp @dchen1107

Juga, bagi siapa saja yang telah mencoba patch saya atau michael dan sedang terpaku pada control plane yang akan datang, tampaknya membangun kubeadm dari master tidak akan berhasil jika ia mengelola cluster v1.6.0 , karena kubeadm mencoba meluncurkan kube-apiserver dengan argumen yang tidak valid:

unknown flag: --proxy-client-cert-file

Jika Anda ingin menguji perubahan milik saya atau michael terhadap kluster v1.6.0, pilihlah dengan cermat terhadap v1.6.0 alih-alih membangun di atas master untuk saat ini.

@yujuhong penjadwal sudah menerapkan toleransi secara otomatis ke pod (lihat https://github.com/kubernetes/kubernetes/pull/41414), ini sepertinya kasus penggunaan yang cukup mirip

Saya tidak memiliki gambaran yang jelas tentang semua noda dan kesiapan wrt
jaringan, pada titik ini. Dan, apakah Anda punya waktu setengah jam untuk menulis
keadaan saat ini, jadi kita bisa mulai memisahkannya? Saya pikir Anda tahu itu
terbaik. Saya merasa kami memiliki sejumlah masalah terperinci yang baru saja kami alami
tertutup selimut sejauh ini.

Pada Kam, 30 Mar 2017 jam 10:22, Ken Simon [email protected]
menulis:

@yujuhong https://github.com/yujuhong penjadwal sudah
menerapkan toleransi secara otomatis ke pod (lihat #41414
https://github.com/kubernetes/kubernetes/pull/41414 ), ini sepertinya
kasus penggunaan yang cukup mirip

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin saya bisa melakukan itu, di mana saya harus meletakkannya?

ada beberapa masalah terkait, bisakah kita memberi judul ulang salah satunya, posting a
ringkasan keadaan saat ini dan pergi dari sana?

Pada Kam, 30 Mar 2017 jam 10:50, Dan Williams [email protected]
menulis:

@thockin https://github.com/thockin Saya bisa melakukannya, di mana saya harus meletakkannya
dia?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

Apakah kita memiliki garis kapan saja tentang kapan perbaikan ini akan di-porting ke repositori CentOS?

Di 1.6 secara default, inti Kubernetes tidak secara otomatis menerapkan noda apa pun ke node. Penjadwal tidak menghargai taint yang ditambahkan oleh sistem penerapan seperti kubeadm, kops, dll. atau ditambahkan secara manual oleh pengguna (dan menghormati toleransi terkait yang ditambahkan ke pod).

Di 1.6 secara default, penjadwal Kubernetes mengecualikan node dari pertimbangan jika mereka melaporkan kondisi node tertentu, termasuk jaringan tidak tersedia. Kode untuk itu ada di sini . Ini tidak ada hubungannya dengan taint -- ini hanya melihat kondisi node.

Di 1.6 Anda dapat mengaktifkan fitur alfa yang menyebabkan inti Kubernetes (NodeController) menambahkan noda NoExecute setiap kali ada NodeReady == "False" atau NodeReady == "Unknown". Hal ini akan menyebabkan Pod yang berjalan di Node akan digusur (jika mereka tidak mentolerir taint) dan mencegah Pod baru menjadwalkan ke node (jika mereka tidak mentolerir taint).

Rencana jangka panjang adalah memindahkan semua logika "bagaimana inti Kubernetes bereaksi terhadap kondisi node, sehubungan dengan penjadwalan dan pengusiran" untuk menggunakan noda dan toleransi (misalnya #42001). Tapi kita belum sampai dan tidak akan ada untuk sementara waktu. Jadi untuk waktu dekat tidak ada cara bagi pod untuk "menoleransi" NetworkUnavailable atau kondisi node lain yang mungkin Anda putuskan untuk ditambahkan.

Jika saya mengerti apa yang dikatakan @davidopp dengan benar, maka fungsinya adalah NodeReady, yang sekarang mengembalikan benar atau salah atau tidak dikenal, mencentang daftar dengan apa yang diperlukan. Jika itu bisa mengembalikan daftar nilai yang tidak terpenuhi, Anda bisa mengujinya.

Dalam kasus kubeadm, jika NetworkUnavailable, adalah satu-satunya. kubeadm dapat mengembalikan nilai true. Itu jika kita tidak ingin plugin networking/cni diteruskan pada waktu kubeadm init.

Karena jika saya mengerti dengan baik, taint dan toleransi diatur berdasarkan fungsi ini, setidaknya untuk kubeadm.

Koreksi saya jika saya salah ;)

Melompat ke utas ini karena saya mengalami masalah ini dan itu menjengkelkan:

Mengapa kesiapan jaringan tidak dapat menjadi noda yang ditambahkan dan dihapus oleh kubelet berdasarkan status jaringan pada node?
Dengan begitu node dapat "Siap" untuk semua pod yang mentolerir taint kesiapan jaringan (aplikasi jaringan pod).

Adapun pod jaringan host, pengontrol penerimaan dapat menyuntikkan toleransi ke noda kesiapan jaringan pod.

Saya pikir itu sejalan dengan rencana jangka panjang dalam komentar davidopp.

Saya pikir itu sejalan dengan rencana jangka panjang dalam komentar davidopp.

Iya benar sekali. Rencana jangka panjangnya adalah memiliki taint untuk setiap kondisi node dan menghentikan segala sesuatu yang internal di Kubernetes memperhatikan kondisi node. Kami memulai pekerjaan itu dengan fitur 1.6 alpha yang saya sebutkan.

ak. Apakah ada alasan untuk tidak beralih ke taints di rilis patch v1.6?

Kode untuk secara otomatis menambahkan taint berdasarkan kondisi node baru saja masuk ke alpha di 1.6. Ia belum siap untuk diandalkan. (Dan itu hanya menangani kondisi siap node saat ini, bukan jaringan).

Jadi, jika saya mengerti dengan benar, untuk saat ini, karena https://github.com/kubernetes/features/issues/166 membutuhkan waktu lebih lama untuk dapat merusak ketersediaan jaringan dengan benar, kita harus menyelesaikannya. Jika kita dapat mendorong perbaikan ASAP untuk kubeadm, seperti #43835, dengan komentar untuk memperbaikinya dengan https://github.com/kubernetes/features/issues/166 , banyak ppl akan senang.

@davidopp Saya berasumsi Anda bermaksud mengatakan " tidak diandalkan ". Saya masih kehilangan hubungan antara kondisi otomatis untuk logika taint yang Anda sebutkan dengan taint posting kubelet secara langsung untuk masalah jaringan.

Ya terima kasih, itu salah ketik, diperbaiki sekarang

Ya, Anda bisa meminta Kubelet menambahkan noda. Kubelet mungkin tidak ideal untuk menambahkan taint untuk beberapa kondisi node dan NodeController menambahkannya untuk kondisi node lainnya (yang terakhir diperlukan karena hanya master yang dapat mendeteksi node yang tidak dapat dijangkau), tetapi itu hanya argumen rekayasa perangkat lunak, bukan sesuatu yang mendasar. Rencana saya adalah agar NodeController menambahkan noda untuk semua kondisi simpul tetapi tidak ada persyaratan kuat untuk melakukannya seperti itu.

ak. Dalam hal ini, kondisi Node tunggal memiliki beberapa atribut yang terkait dengannya yang mungkin tidak dapat dilihat oleh Pengendali Node.
@mikedanese Saya merasa perilaku kubeadm init menghasilkan simpul yang berfungsi menarik. Saya harap persyaratan untuk menambahkan fase validation terutama tidak didorong berdasarkan masalah ini.
@dcbw @thockin @yujuhong ada pemikiran tentang penggunaan taints untuk mewakili masalah konfigurasi node di kubelet?

Perhatikan bahwa jika Anda ingin noda baru Anda mengganti pemfilteran otomatis saat ini dari node dengan NetworkUnavailable, Anda perlu memodifikasi fungsi yang saya sebutkan sebelumnya (yaitu menghapusnya dari kumpulan kondisi yang menyaring sebuah node). Saya tidak tahu apa efek samping lain yang akan terjadi, karena fungsi itu dapat digunakan dalam daftar simpul selain hanya penjadwal.

Apakah ada cara untuk menginstal 1.5.6 yang seharusnya berfungsi di Ubuntu? Jika ada bisa tolong jelaskan bagaimana melakukannya? Terima kasih!

Perhatikan bahwa jika Anda ingin noda baru Anda mengganti pemfilteran otomatis saat ini dari node dengan NetworkUnavailable, Anda perlu memodifikasi fungsi yang saya sebutkan sebelumnya (yaitu menghapusnya dari kumpulan kondisi yang menyaring sebuah node). Saya tidak tahu apa efek samping lain yang akan terjadi, karena fungsi itu dapat digunakan dalam daftar simpul selain hanya penjadwal.

@davidopp kita harus berhati-hati tentang NetworkUnavailable vs. NodeReady. Ada dua kondisi terpisah yang harus benar-benar dibersihkan:

nodeNetworkUnavailable - ini khusus untuk rute cloud, dan hanya pengontrol rute cloud yang menghapus kondisi ini saat rute cloud antar node telah disiapkan. Plugin jaringan yang membuat overlay atau yang tidak melakukan perutean L3 antar node tidak menginginkan atau menggunakan kondisi ini. Kondisi ini tidak ditambahkan oleh plugin jaringan apapun; itu ditambahkan oleh kubelet secara khusus ketika GCE atau AWS dipilih sebagai penyedia cloud. Tidak mempengaruhi NodeReady karena ini adalah kondisi yang terpisah.

NodeReady - dipengaruhi langsung oleh plugin jaringan (misalnya, CNI atau kubenet atau runtime jarak jauh seperti dockershim/CRI-O).

Ada tiga masalah terpisah yang perlu dipertimbangkan:

1. Rute Cloud - jika infrastruktur cloud dan plugin jaringan memerlukan rute cloud, maka kekurangan rute cloud (mis., NodeNetworkUnavailable=true) perlu memblokir penjadwalan hostNetwork=pod palsu
2. Plugin jaringan - jika plugin belum siap, itu perlu memblokir penjadwalan hostNetwork=false pod. Ini terpisah dari NodeNetworkUnavailable karena plugin mungkin tidak memiliki interaksi langsung dengan Pengontrol Rute karena tidak bergantung pada rute cloud. Misalnya, kubenet dapat digunakan secara lokal di node jika Anda memiliki sesuatu yang lain (rute cloud, flanel, dll) yang mengatur rute node.
3. hostNetwork=true pod harus mengabaikan semua kondisi ini dan dijadwalkan, tetapi tunduk pada kondisi lain yang berlaku (ruang disk, dll)

NodeReady terlalu besar untuk palu. Saya pikir kita mungkin menginginkan kondisi NetworkPluginReady tambahan untuk kesiapan plugin jaringan (terpisah dari kesiapan rute cloud!)

Pekerjaan lain di sekitar saya temukan.

Sementara kubeadm terus mencetak '[apiclient] Node pertama telah terdaftar, tetapi belum siap', saya menggunakan 'kube-flannel.yml' yang menginstal flanneld. Dan itu berhasil tanpa mengubah file konfigurasi.

1) kubeadm init --pod-network-cidr=10.244.0.0/16 &
2) cp /etc/kubernetes/admin.conf ~/.kube/config
3) kubectl apply -f kube-flannel-rbac.yml (Diperlukan di kubeadm 1.6)
4) kubectl apply -f kube-flannel.yaml
Gunakan kube-flannel.yaml di https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

Saya bisa membuat master node 'Siap'. Tapi, kube-dns gagal dengan pesan,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

Setelah saya mengubah plug-in jaringan menjadi weave-net, itu berhasil.

@dcbw Saya tidak cukup tahu tentang masalah spesifik yang dibahas dalam masalah ini untuk memberi tahu Anda apa yang harus dilakukan. Saya hanya ingin menjelaskan status noda saat ini dan bagaimana mereka bisa diterapkan di sini.

SILAKAN UJI DEBS YANG DIPATCH

kubernetes-xenial-unstable sekarang memiliki build yang ditambal 1.6.1-beta.0.5+d8a384c1c5e35d-00 yang @pipejakob dan saya uji hari ini. Node tetap tidak siap sampai jaringan pod dibuat (misalnya dengan menerapkan konfigurasi weave/flanel). Lulus uji kesesuaian. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

Apakah arahan umum bahwa noda dapat mengekspresikan hampir semua hal
kondisi bisa, dan karena itu lebih baik dalam segala hal?

Saya setuju kita membutuhkan lebih banyak sinyal granular. Kita masih perlu memilah-milah
interaksi antara kubelet, driver net, pengontrol cloud, dan penyedia cloud
untuk membuka kunci hostNetwork=false pod, tetapi hostNetwork=true seharusnya tidak
diblokir.

Pada Kam, 30 Mar 2017 jam 19:24, Dan Williams [email protected]
menulis:

Perhatikan bahwa jika Anda ingin noda baru Anda menggantikan otomatis saat ini
menyaring node dengan NetworkUnavailable, Anda perlu memodifikasi
fungsi yang saya sebutkan sebelumnya (yaitu menghapusnya dari kumpulan kondisi
yang menyaring sebuah simpul). Saya tidak tahu apa efek samping lain yang akan terjadi
miliki, karena fungsi itu dapat digunakan dalam daftar simpul selain dari hanya
penjadwal.

@davidopp https://github.com/davidopp kita harus berhati-hati
NetworkUnavailable vs. NodeReady. Ada dua kondisi terpisah yang
harus benar-benar dibersihkan:

nodeNetworkUnavailable - ini khusus untuk rute cloud, dan hanya cloud
pengontrol rute menghapus kondisi ini ketika rute cloud antar node memiliki
telah diatur. Plugin jaringan yang membuat overlay atau yang tidak melakukan L3
routing antar node tidak ingin atau menggunakan kondisi ini. Kondisi ini adalah
tidak ditambahkan oleh plugin jaringan apa pun; itu ditambahkan oleh kubelet secara khusus ketika
GCE atau AWS dipilih sebagai penyedia cloud. Tidak mempengaruhi NodeReady sejak
itu syarat tersendiri.

NodeReady - terpengaruh langsung oleh plugin jaringan (misalnya, CNI atau kubenet
atau runtime jarak jauh seperti dockershim/CRI-O).

Ada tiga masalah terpisah yang perlu dipertimbangkan:

1. Rute Cloud - jika infrastruktur cloud dan plugin jaringan
   memerlukan rute cloud, lalu kekurangan rute cloud (mis.
   NodeNetworkUnavailable=true) perlu memblokir penjadwalan hostNetwork=false
   polong
2. Plugin jaringan - jika plugin belum siap, itu perlu
   blokir penjadwalan hostNetwork=pod palsu
3. hostNetwork=pod yang benar harus mengabaikan semua kondisi ini dan menjadi
   dijadwalkan, tetapi tunduk pada kondisi lain yang berlaku (ruang disk, dll)

NodeReady terlalu besar untuk palu. Saya pikir kita mungkin ingin
kondisi NetworkPluginReady tambahan untuk kesiapan plugin jaringan
(terpisah dari kesiapan rute cloud!) dan kemudian kita harus menyelami itu
melalui ke tempat-tempat yang peduli :(

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Bagi siapa pun yang masih mencoba perbaikan sementara dengan menghapus baris konfigurasi kubelet KUBELET_NETWORK_ARGS, @jc1arke menemukan solusi yang lebih sederhana -
Sesi pertama setelah menjalankan kubeadmin init:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
...

Sesi kedua (menggunakan Calico. Pilihan Anda tentu saja mungkin berbeda):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Kembali ke sesi pertama:

...
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

Apakah arahan umum bahwa noda dapat mengekspresikan hampir semua hal
kondisi bisa, dan karena itu lebih baik dalam segala hal?

Kurang lebih. Kami mungkin tidak dapat menghilangkan salah satu kondisi node karena masalah kompatibilitas ke belakang, tetapi kami dapat menghilangkan semua logika di master yang mengambil tindakan berdasarkan kondisi tersebut (seperti memblokir penjadwalan atau mengeluarkan pod). Selain membuat perilaku lebih jelas (tidak perlu mengingat kondisi mana yang memblokir penjadwalan, yang menyebabkan pengusiran, berapa lama kita menunggu pengusiran, dll.), reaksi terhadap kondisi dapat dikonfigurasi pada basis per-pod.

Baru saja menguji deb dari @mikedanese dan @pipejakob , ini berfungsi dengan baik.

Diuji di ubuntu/xenial:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Baru saja menguji deb dari @mikedanese dan @pipejakob , masih membeku di
[apiclient] Created API client, waiting for the control plane to become ready

Saya telah menunggu sekitar lima menit, tetapi tidak ada yang berubah.
Dan kemarin itu terus berulang
[apiclient] First node has registered, but is not ready yet

TTI pikir masalahnya masih ada solusi?

Diuji pada Ubuntu 16.04:
versi kubeadm: version.Info{Mayor:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean" -03-31T04:20:36Z", GoVersion:"go1.7.5", Kompilator:"gc", Platform:"linux/amd64"}

@myqq0000 dapatkah Anda memposting versi yang Anda gunakan?

kubeadm version

@coeki Oh, saya lupa. Saya telah mengedit sekarang dan memposting versi di komentar saya sebelumnya. :)

@mikedanese Apakah Anda punya rencana untuk memperbarui centos yum repo? Atau sudah di-deploy ke yum repo ?

Baru saja mencoba 1.6.1-beta.0.5+d8a384c1c5e35d-00 ( 1.6.1-beta.0.5+48c6a53cf4ff7d-00 disebutkan di https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 tampaknya tidak ada).

Tampaknya bekerja dengan baik.
Tidak terkait: perhatikan bahwa jika Anda menggunakan weave, Anda harus menerapkan https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml alih-alih 'default' https:/ /git.io/weave-kube

@mausch Bisakah Anda memberi tahu saya cara mendapatkan deb ini?

@srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

Deb yang ditambal

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Terima kasih. Mereka bekerja untuk saya juga dengan penyedia jaringan tenun.

Adakah peluang untuk membuat perbaikan yang sama untuk Centos juga? Sistem gating kami sebagian besar menggunakan centos untuk basis cluster kubernetes. Jika saya memiliki versi centos, saya dapat menjamin sekitar. 100 menjalankan kubeadm init sehari sebagai pengujian.

Deb yang ditambal kubeadm memberi tahu bahwa cluster sudah siap, tetapi node itu sendiri belum.

Node @squall0gd harus siap ketika jaringan pod diterapkan, misalnya kubectl apply -f https://git.io/weave-kube-1.6

Di lingkungan pengujian saya (di gelandangan, berdasarkan mesin centos/7), kubeadm hanya hang. Menggunakan strace saya dapat melihatnya mencoba terhubung ke server kubelet pada master , dan melakukan FUTEX_WAIT, epoll_wait retry loops. Tetapi tidak ada satu baris keluaran ouf yang berasal darinya.

kubelet gagal memulai, yang tampaknya menjadi alasannya.
(Tetapi saya tidak dapat melihat alasan mengapa kublet gagal memulai..)

Apakah ini masalah dari masalah ini?

Saya mendapatkan binari dari http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 repo.
Saya juga mencoba memperbarui binari dari https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> Di mana saya bisa mendapatkan versi patch dari kubeadm untuk pengujian? <==

Catatan: Saya menemukan satu (diklaim) versi patch dari kubeadm yang dirujuk dalam masalah ini di https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (versi yang ditambal adalah ini: https://heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), tetapi itu tidak berhasil untuk saya. Tingkah lakunya masih sama (tidak ada output sama sekali)...

@squall0gd Bisakah Anda menunjukkan kepada kami pesan persis yang Anda lihat? Berdasarkan apa yang Anda jelaskan, saya ingin tahu apakah Anda benar-benar mengambil .debs baru atau menggunakan versi cache yang lebih lama.

@thockin @davidopp jadi sesuai saran Tim, saya akan menyita masalah yang ada atau mengajukan yang baru untuk melacak kondisi kesiapan jaringan yang terurai dan untuk mengubahnya menjadi noda alih-alih kondisi aktual, dan menyalin di sebagian besar https://github. com/kubernetes/kubernetes/issues/43815#issuecomment -290597988 ke dalamnya.

Inilah yang tampaknya bekerja untuk saya dengan repo unstable (hanya menguji master itu sendiri):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Ini memang mengeluarkan error: taint "dedicated:" not found pada satu titik, tetapi tampaknya terus berlanjut.

Apakah kita tidak menjalankan tes ini di cabang 1.6?

@davidopp Node condition dimaksudkan untuk memberikan informasi tambahan bagi manusia, untuk memahami apa yang sedang terjadi, seperti alasan, pesan, dan waktu transisi.

kubeadm sepertinya tidak diuji pada cabang rilis:
https://k8s-testgrid.appspot.com/release-1.6-all

@bgrant0607 rupanya tes kubeadm e2e dinonaktifkan/tidak berfungsi selama sekitar satu minggu menjelang rilis 1.6, IIRC

Kondisi node dimaksudkan untuk memberikan informasi tambahan bagi manusia, untuk memahami apa yang sedang terjadi, seperti alasan, pesan, dan waktu transisi.

@ bgrant0607 apakah mereka ditujukan terutama untuk info manusia, atau apakah itu hanya efek samping yang menyenangkan? Jika terutama untuk manusia, haruskah mereka digunakan untuk menjadwalkan keputusan seperti saat ini atau haruskah kita menjauh dari itu?

@dcbw Taints dimaksudkan untuk menjadi GUT ketidakterjadwalan dan gangguan. Akhirnya, penjadwal harus mengabaikan kondisi.

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

Perhatikan bahwa jika kita akan menambahkan noda ke node, kita perlu mempertimbangkan

a) Kompatibilitas mundur, seperti halnya master taint: https://github.com/kubernetes/kubernetes/pull/43537

b) Versi miring. Saat mengupgrade cluster ke 1.6, kubelet akan menjadi rilis campuran, dan beberapa mungkin setua 1.4.

jadi untuk rekap atau saat saya menguraikan ini:

berdasarkan @dcbw

nodeNetworkUnavailable adalah hal penyedia cloud, tidak terikat dengan kubeadm atm, kita mungkin mengalami ini.

Tetapi NodeReady, yang merupakan akar penyebab loop, perlu lebih terperinci. Inilah yang @davidopp ingin menjadi noda, berdasarkan daftar yang mencentang kotak, sehubungan dengan penyelidikan/keaktifan, CNI ready dan lain-lain.

baiklah, meskipun Anda bisa berdebat, mengapa tidak memberi label?

Tapi @dcbw apakah Anda menemukan utas yang lebih cocok untuk diskusi ini? Penyebab yang satu ini menjadi ember untuk masalah dengan penyebaran dan tidak benar-benar akar masalah.

Saya tahu, saya adalah bagian dari tidak benar-benar menyelesaikan masalah, dan memposting peretasan di sekitarnya :)

Tapi bagaimanapun, kita harus mendiskusikan dasar-dasarnya di tempat lain, pastikan ETA untuk perbaikan ditempatkan di sini, dan lanjutkan.

Tidak tajam, tapi baik :)

PS ya @bgrant0607 kita harus menguji ini lebih banyak
PS2 Jika saya melihat ini salah, Anda bisa menyalahkan saya;)

@coeki Saya juga menambahkan permintaan untuk versi N-1 untuk disimpan di repo rpm/deb. Semua rilis besar akhirnya berakhir dengan satu atau dua masalah. Operator telah lama menghindari rilis N.0 untuk produksi karena alasan itu. Ini berfungsi dengan baik jika versi sebelumnya dibiarkan untuk sementara waktu. Tapi kali ini 1.5.x telah dihapus seluruhnya sebelum 1.6 dibuat stabil. Itu membuat operator yang tidak terlalu siap (pencerminan repo lokal, dll) dari membuat kemajuan saat masalah diselesaikan. Rasa sakit dari pelepasan N+1 yang bergelombang sering kali dapat diatasi hanya dengan menahan N untuk sementara waktu.

@kfox1111 gating juga masalah.... kita perlu strategi yang lebih baik untuk itu :)

Mengapa bahkan menghapus rilis lama sama sekali? Itu dapat dengan mudah merusak otomatisasi orang dan mencegah pemasangan berulang.

Kondisi node dimaksudkan untuk memberikan informasi tambahan bagi manusia, untuk memahami apa yang sedang terjadi, seperti alasan, pesan, dan waktu transisi.

Sepakat. UX jelas merupakan alasan utama mengapa kami mungkin tidak dapat menghilangkan kondisi node. Namun, saya yakin kita dapat menyingkirkan semua penggunaan kondisi node sebagai pemicu tindakan utama (seperti penggusuran dan penjadwalan pemblokiran), dan menggunakan taints untuk itu.

Dalam jangka panjang (seperti v2 API jangka panjang) dapat dibayangkan kita dapat menambahkan alasan dan pesan ke noda dan kemudian menyingkirkan kondisi simpul, tetapi saya belum benar-benar memikirkannya dan saya jelas tidak secara resmi mengusulkan untuk melakukannya. (Kami sudah memiliki waktu transisi yang setara dalam satu arah, yaitu TimeAdded.)

@coeki tidak, apa yang saya bicarakan tidak ada hubungannya dengan gating. Gerbang tidak dapat menemukan semua masalah kecuali Anda memiliki gerbang yang menguji segala sesuatu yang mungkin dapat dilakukan. Operator suka melakukan hal-hal aneh di lingkungan mereka. :) Sangat mahal untuk menguji segala sesuatu yang mungkin.

Saya meminta untuk tidak menghapus rilis lama sebelum yang baru berhasil setidaknya melalui rilis perbaikan bug pertama. Untuk contoh ini, 1.6.1. Minimal. Menyimpan lebih banyak versi yang lebih lama bahkan lebih baik. Ini adalah praktik terbaik untuk memungkinkan operator terus membuat kemajuan sementara bug di versi baru diselesaikan.

@kfox1111 , itulah yang dilakukan gating, tidak mengikuti sesuatu yang tampaknya baik, dan membuang cara lama yang tepercaya, apa yang terjadi sekarang.

@davidopp Saya setuju bahwa label dan noda mungkin memiliki perbedaan yang berbeda dari cara pandang api, UX, dan mesin, tetapi sekarang sedang menyebar. Begitu juga dengan saya :)

Bagaimanapun, Anda memikat saya ke dalam diskusi, kami benar-benar tidak ada dalam masalah ini, itu poin saya.

Saya ingin bertanya lagi: jika saya melihat "kubeadm init" hanya menggantung di sana tanpa output (mencoba terhubung ke server kubelet, yang gagal memulai), apakah saya mengalami masalah ini? Dan jika ini masalahnya, apakah #43835 merupakan perbaikan untuk saya?

Sekarang di mana saya bisa mendapatkan:

• baik versi kubeadm / kubectl / kubelet yang lebih lama (sebelum 1.6.0)
• atau kubeadm versi patch (termasuk #43835 atau perbaikan lainnya)?

Terima kasih!

(catatan: versi kubeadm yang ditambal yang dirujuk dalam komit yang disebutkan di atas tidak berfungsi untuk saya ...)

@obnoxxx coba ujung cabang rilis-1.6.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese terima kasih! mencoba...

Jika Anda menjalankan kubeadm tanpa menginstal paket os, Anda perlu

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

dari https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese terima kasih. Saya menginstal paket os (dari kube repo) dan kemudian menginstal binari dari url web di atas binari dari rpms...

versi 1.6.1-beta.0.12 tidak berfungsi untuk saya:
kubeadm init masih hang tanpa output apa pun . (mencoba terhubung ke kubelet)

Jangan lupa driver systemd juga jika centos.

driver sistem?

https://github.com/kubernetes/release/issues/306

astaga, terima kasih, itu lebih baik! :-)

@pipejakob Saya tidak memiliki akses ke log ini sekarang, tetapi saya telah memeriksa versi kubeadm dan itu adalah versi yang sama dengan yang dimiliki @webwurst . Selain itu, saya telah memeriksa kemungkinan versi kubeadm dengan apt-cache policy kubeadm . Dan hanya ada satu entri - dari kubernetes-xenial-unstable.
@mikedanese Saya sudah mencoba dengan kain flanel sebelum memposting ;)
EDIT: Saya telah membangun kembali seluruh platform dan kubadm berfungsi dengan baik :+1:

Guys apa status quo untuk perbaikannya? apakah itu akan pindah ke repositori stabil dalam waktu dekat?

@mikedanese deb yang ditambal melakukan hal yang sama "plugin jaringan tidak siap".

Adakah yang bisa memberi tahu saya cara membuat versi kubeadm for rhel (rpm) yang ditambal?

@mikedanese dengan deb yang ditambal, init melaporkan keberhasilan, tetapi pesan "plugin jaringan tidak siap: cni config uninitialized" tetap ada.

Node master ada di NotReady .

weave-net (weaveworks/weave-kube:1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) ada di 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

Pod kube-dns ada di 0/3 Pending .

@ChipmunkV Anda mungkin perlu mengkonfigurasi kube-proxy untuk berjalan di userspace. Ini telah menjadi masalah di 1.5 juga.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Untuk apa nilainya, kubernetes-xenial-unstable bekerja dengan baik untuk saya.

@pstadler , terima kasih kepada @errordeveloper dalam obrolan yang telah menunjukkan bahwa saya memiliki jaringan yang tumpang tindih, saya telah mengkonfigurasi ulang IPALLOC_RANGE di weave.

Terima kasih @thenayr. Saya dapat memunculkan master Kubernetes tetapi juga dapat menghubungkan satu pekerja dengannya menggunakan kubeadm join. Akan segera memposting lebih banyak pembaruan

@mikedanese butuh waktu lama untuk mengetahui versi apa yang digunakan, sampai saya membaca semua komentar di sini. Kami benar-benar perlu membuatnya lebih mudah untuk menemukan binari untuk versi tertentu. Saya telah mencoba menggunakan apa yang ditunjukkan ci-cross/latest.txt (yaitu v1.7.0-alpha.0.1982+70684584beeb0c ), dan itu terjadi untuk memperkenalkan flag kube-apiserver (yaitu --proxy-client-key-file di d8be13fee85075abfc087632b3dbc586a10897ad), yang tidak berfungsi dengan salah satu tag terbaru di gcr.io/google_containers/kube-apiserver-amd64 ...

Bagaimana kita bisa membuatnya lebih mudah untuk mengetahui revisi apa yang memiliki binari di ember? Mampu membuat daftar direktori akan menyenangkan, atau memiliki file peta sederhana atau apa saja yang tidak perlu diketahui atau harus ditebak.

@errordeveloper kami mencoba melakukan rilis sehingga kami dapat mendorong perbaikan ke cabang stabil, harus dilakukan dalam O(hari) saya harap. Ada tautan dalam deskripsi masalah ini ke deb yang ditambal di tidak stabil.

Rilis sebelumnya 1.5.6 bekerja untuk saya di CentOs 7 tetapi sekarang saya bahkan tidak dapat memutar kembali karena satu-satunya versi kubeadm di http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 adalah versi 1.6 yang rusak. 0. Adakah saran tentang cara mendapatkan kubeadm 1.5.6 RPM?

Memang, sangat disayangkan. Versi lama tampaknya telah dihapus seluruhnya. :-(

Hasil saya adalah ini di centos 7:

• Saya belum bisa mendapatkan kubadm init untuk memberi saya hasil sama sekali, bahkan dengan kubeadm terbaru yang ditambal, tanpa melakukan sesuatu tentang kubectl.
• Saya sudah bisa memulai kubectl dengan instruksi dari @coeki , dan kemudian kubeadm bahkan lulus. Tapi setelah itu, tidak ada yang berhasil untuk saya. kubectl mengatakan

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Ada petunjuk apa yang terjadi?

@obnoxxx secara default apiserver tidak mendengarkan pada 8080, ia mendengarkan pada port 6443 yang aman, Anda dapat memeriksa dengan netstat -tunlp.
Anda perlu menyalin admin.conf dari /etc/kubernetes kepada Anda $HOME/.kube/config
pastikan Anda mengubah hak akses pada file di $HOME/.kube/ Anda, setelah itu kubectl Anda harus dapat menghubungi apiserver dengan benar. HTH. Serguei

@apsinha Apakah Anda mengetahui utas ini? Mungkin bagus untuk memiliki beberapa orang produk yang mengikuti, karena saya pikir akan ada beberapa takeaways penting untuk masa depan.

Dari atas kepala saya:

• 1.6.0 tidak pernah melalui pengujian otomatis: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Binari/paket untuk versi yang lebih lama telah dihapus, sehingga orang tidak dapat memutar kembali dengan aman; memecahkan otomatisasi instalasi apa pun yang menganggapnya terus tersedia: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Tidak ada pengumuman publik (yang pernah saya lihat) tentang fakta bahwa ini rusak
• Tidak ada garis waktu yang diberikan tentang perbaikan (saya seorang pengembang, jadi saya tahu betapa menjengkelkannya ditanya "kapan akan diperbaiki?", namun demikian, orang akan menanyakan ini, jadi ada baiknya setidaknya menawarkan perkiraan periode waktu)
• Pengguna yang terus bergabung dalam percakapan bingung tentang status, solusi, dan jadwal perbaikan
• Banyak diskusi teknis di antara para kontributor, banyak di antaranya tentang strategi jangka panjang, digabungkan dalam utas yang sama ketika pengguna mencoba mencari tahu apa yang terjadi dan bagaimana menangani masalah langsung

Tidak ada rasa tidak hormat yang ditujukan kepada semua orang hebat yang menjadikan Kubernetes apa adanya. Saya hanya berharap ada beberapa "momen yang dapat diajarkan" di sini untuk bergerak maju, karena ini terlihat buruk dalam hal persepsi publik tentang Kubernetes yang dapat diandalkan/stabil. (Memang kubeadm adalah alfa/beta, tetapi masih memiliki banyak visibilitas.)

Saya membangun kubeadm-1.5.6 menggunakan kubernetes/release.rpm hanya untuk menemukan (yang membuat saya kecewa) itu

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone Anda perlu menyesuaikan .spec di sini .

@sbezverk terima kasih atas petunjuknya! Lebih baik sekarang...

Ini penasaran:

• Saya tidak ingat menyalin admin.conf diperlukan untuk saya di rilis sebelumnya.
• Saya mencoba dengan kubectl -s localhost:6443 sebelumnya tetapi itu tidak cukup.

Bagaimanapun, sekarang saya bisa melanjutkan. Terima kasih lagi

v1.6.1 sedang dalam proses rilis. Itu akan dilakukan oleh EOD.

Beberapa catatan:

1. Masalah dengan paket lama yang dihapus telah dilacak di sini: https://github.com/kubernetes/release/issues/234. Karena beberapa versi kubeadm yang aneh dan bagaimana hal-hal ini diurutkan berdasarkan abjad, tampaknya kubeadm versi 1.5.x tidak dapat disimpan dalam repo. ( @bostone masalah Anda juga dirujuk di sana)
2. pengujian kubeadm e2e pada PR yang dilacak di sini: https://github.com/kubernetes/kubeadm/issues/190
3. Adapun pengumuman publik -- saya memposting di twitter tapi itu hampir tidak resmi. Tidak jelas apa saluran yang benar untuk masalah kritis seperti ini.

Ini semua adalah masalah bagus untuk dibawa ke PM. @pipejakob dengan murah hati menawarkan diri untuk menarik post mortem itu bersama-sama.

@obnoxxx Persyaratan untuk menyalin/menyalin admin.conf diperlukan sebelumnya karena dengan 1.5 kami memiliki server API yang memperlihatkan port yang tidak aman. Kami mengubahnya di 1.6. Sekarang Anda harus menggunakan kredensial aman untuk mengakses server API (lihat https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese kedengarannya bagus, terima kasih!
Hanya untuk dummy saya - apa yang akan menjadi efek dari rilis 1.6.1 ini sehubungan dengan masalah ini?
Apakah kubelet akan dimulai tanpa perubahan ke /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( solusi @coeki ) atau akankah berisi perbaikan #43835 (yang tampaknya tidak berpengaruh untuk saya)?

@jbeda terima kasih atas penjelasannya!

@jbeda Saya pikir kebingungan berasal dari pengaturan dokumen instalasi kubadm resmi repo YUM ke http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. Repo itu hanya memiliki kubeadm-1.6.0

Dan sekali lagi kekecewaan saya membangun 1.5.6 rpms dan menginstal berakhir dengan masalah yang sama persis. Menjalankan kubeadm init tergantung pada baris yang sama:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Saya kira saya hanya akan menunggu rilis 1.6.1 dan berharap ...

1.6.1 keluar.

@mikedanese apakah Anda menguji kubeadm sebelum menutup bug ini? Saat ini saya sudah menatap [apiclient] Created API client, waiting for the control plane to become ready selama 10 menit. Pada CentOS 7 dengan instalasi 1.6.1 yang baru

@bostone Anda mungkin mengalami masalah ini: #43805

Coba edit /etc/systemd/system/kubelet.service.d/10-kubeadm.conf dan tambahkan --cgroup-driver=systemd

Ingatlah untuk menjalankan systemctl daemon-reload; systemctl restart kubelet

@gtirloni dengan saran kami, saya sampai di akhir kubeadm init namun setiap upaya untuk menjalankan kubectl menghasilkan kesalahan ini: The connection to the server localhost:8080 was refused - did you specify the right host or port? Saya tidak yakin di mana dan bagaimana mengubahnya atau apa port yang tepat di titik ini?

Tidak yakin apakah ini terkait tetapi inilah yang saya lihat saat menjalankan systemctl status kubelet :
``` systemctl status kubelet -l
● kubelet.service - kubelet: Agen Node Kubernetes
Dimuat: dimuat (/etc/systemd/system/kubelet.service; diaktifkan; preset vendor: dinonaktifkan)
Drop-In: /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
Aktif: aktif (berjalan) sejak Senin-04-03 17:31:07 PDT; 11 menit yang lalu
Dokumen: http://kubernetes.io/docs/
PID Utama: 10382 (kubelet)
CGroup: /system.slice/kubelet.service
10382 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true - -network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain =cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=systemd
10436 jurnalctl -k -f

03 Apr 17:41:56 sdl02269 kubelet[10382]: W0403 17:41:56.645299 10382 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
03 Apr 17:41:56 sdl02269 kubelet[10382]: E0403 17:41:56.645407 10382 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady= alasan salah pesan:docker : plugin jaringan belum siap: cni config tidak diinisialisasi```

Ya kami menguji. tes e2e melewati cabang rilis. Anda mungkin memukul masalah lain.

@bostone mungkin Anda melewatkan langkah-langkah ini setelah kubeadm init ?

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Anda juga harus mengikuti langkah 3 yang dijelaskan di sini . Itu sepertinya terkait dengan kesalahan konfigurasi cni yang Anda dapatkan.

Juga menatap klien API yang dibuat [apiclient], menunggu bidang kontrol siap selama 10 menit dengan Ubuntu 16.04 dan instalasi baru 1.6.1

@pingthings Saya sarankan untuk bergabung dengan Slack Kubernetes dan saluran kubeadm . Kami dapat membantu Anda melakukan debug di sana.

Saya berhasil mengatur cluster Kubernetes saya di centos-release-7-3.1611.el7.centos.x86_64 dengan mengambil langkah-langkah berikut (saya berasumsi Docker sudah diinstal):

1) (dari /etc/yum.repo.d/kubernetes.repo) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Untuk menggunakan repositori yang tidak stabil untuk Kubernetes 1.6.1 terbaru
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) tambahkan "--cgroup-driver=systemd" di akhir baris terakhir.
=> Ini karena Docker menggunakan systemd untuk cgroup-driver sedangkan kubelet menggunakan cgroupfs untuk cgroup-driver.
4) systemctl aktifkan kubelet && systemctl start kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Jika Anda biasa menambahkan --api-advertise-addresses, Anda harus menggunakan --apiserver-advertise-address sebagai gantinya.
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
ekspor KUBECONFIG=$HOME/admin.conf
=> Tanpa langkah ini, Anda mungkin mendapatkan kesalahan dengan kubectl get
=> Saya tidak melakukannya dengan 1.5.2
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 memperkenalkan kontrol akses berbasis peran sehingga Anda harus menambahkan ClusterRole dan ClusterRoleBinding sebelum membuat daemonset Flannel
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Buat daemonset Flanel
9) (pada setiap node slave) kubeadm join --token (token Anda) (ip):(port)
=> seperti yang ditunjukkan pada hasil kubeadm init

Semua langkah di atas merupakan hasil penggabungan saran dari berbagai isu seputar Kubernetes-1.6.0, khususnya kubeadm.

Semoga ini akan menghemat waktu Anda.

Ini sepertinya tidak terselesaikan (Ubuntu LTS, kubeadm 1.6.1).

Pertama, saya juga mengalami kubeadm tergantung pada "Membuat klien API, menunggu control plane siap" saat menggunakan flag --apiserver-advertise-address .. Log jurnal mengatakan:

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Jika saya tidak memberikan tanda ini, kubeadm lolos, tetapi meskipun demikian saya mendapatkan kesalahan berikut untuk memulai kubelet:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet menolak untuk memulai dengan benar, dan saya tidak dapat terhubung ke cluster dengan kubectl dengan cara apa pun

Tampaknya versi 1.5.x kubeadm telah dihapus tidak hanya dari repositori centos, tetapi juga dari Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It membuatnya sulit untuk diturunkan, dan benar-benar merusak kompatibilitas ke belakang

@bostone

Apakah Anda memahami istilah "menunggu pesawat kontrol siap"? Saya melihat hal yang sama setelah mencoba semua perubahan dengan 1.6.1.

@gtirloni @srzjulio menambahkan langkah-langkah ini setelah kubeadm init tidak membantu. Itu memang membuat layanan kubelet berubah dari failed menjadi active (running) tetapi saya masih memiliki pesan The connection to the server localhost:8080 was refused - did you specify the right host or port? . Dan jika saya melihat layanan mendengarkan, saya tidak dapat melihat 8080 di mana pun. Apa yang saya lihat adalah bahwa kubelet mendengarkan pada port ini:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Jadi ada pengaturan yang salah (berubah?) yang salah menunjuk ke 8080?

@bostone itu bukan port kubelet yang Anda butuhkan, itu adalah kube-apiserver, itu harus mendengarkan di port 6443.

@sbezverk Saya tidak mengubah default apa pun sejauh port (tidak ada dalam instruksi apa pun) Apa yang harus saya lakukan untuk beralih dari 8080 ke 6443?

@bostone jika Anda tidak mengubah apa pun dalam manifes apiserver maka secara default akan mendengarkan pada port 6443. Anda hanya perlu menyalin /etc/kubernetes/admin.conf ke $HOME/.kube/config, ubah izin pada file konfigurasi dan Anda harus siap.

@sbezverk BTW - Saya menjalankan semua langkah instalasi sebagai root tetapi 3 baris instruksi ini dari output kubeadm init menyarankan menggunakan pengguna Sudo. Apa rekomendasi tentang ini? Haruskah menjalankan semua langkah instalasi sebagai sudo juga?

Ok, saya melakukan semua langkah dari awal dan tampaknya lebih baik. Berikut adalah langkah-langkah yang berhasil bagi saya sejauh ini dan saya menjalankannya sebagai root pada CentOS 7.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Tambahkan -cgroup-driver=systemd ke 10-kubeadm.conf dan simpan

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

Pada titik ini saya dapat menjalankan kubectl get nodes dan melihat master node saya dalam daftar.
Ulangi semua langkah untuk minion kecuali kubeadm init dan sebagai gantinya jalankan kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 seperti yang dihasilkan oleh kubeadm init
Langkah ini selesai dan saya dapat melihat node master dan minion

Dan sekarang - masalahnya:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

Jadi sepertinya node tidak pernah siap. Ada saran?

Saya membayangkan tenun Anda tidak digunakan dengan benar karena Anda menggunakan
pra-1.6 yaml file.

Coba "kubectl apply -f https://git.io/weave-kube-1.6 "

Pada Selasa, 4 April 2017 pukul 12:24, Bo Stone [email protected] menulis:

Ok, saya melakukan semua langkah dari awal dan tampaknya lebih baik. Di sini adalah
langkah-langkah yang berhasil untuk saya sejauh ini dan saya menjalankannya sebagai root.

kucing <

[kubernet]
nama=Kubernetes
baseurl= http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
diaktifkan = 1
gpgcheck=1
repo_gpgcheck=1
gpgkey= https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:// /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Tambahkan -cgroup-driver=systemd ke 10-kubeadm.conf dan simpan

systemctl aktifkan buruh pelabuhan && systemctl mulai buruh pelabuhan

systemctl aktifkan kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables=1

systemctl stop firewalld; systemctl menonaktifkan firewalld

kubeadm init

cp /etc/kubernetes/admin.conf $HOME/

chown $(id -u):$(id -g) $HOME/admin.conf

ekspor KUBECONFIG=$HOME/admin.conf

kubectl apply -f https://git.io/weave-kube

Pada titik ini saya dapat menjalankan kubectl get node dan melihat master node saya di
Daftar.
Ulangi semua langkah untuk minion kecuali menjalankan kubeadm join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 seperti yang dihasilkan oleh kubeadm
init
Langkah ini selesai dan saya dapat melihat node master dan minion

Dan sekarang - masalahnya:

kubectl dapatkan node

NAMA STATUS USIA VERSI
abc02918 Tidak Siap 42m v1.6.1
abc04576 Tidak Siap 29m v1.6.1

kubectl mendeskripsikan simpul abc02918

Acara:
FirstSeen LastSeen Hitungan Dari SubObjectPath Type Alasan Pesan
--------- -------- ----- ---- ------------- -------- --- ---------
43m 43m 1 kubelet, sdl02918 Mulai Normal Memulai kubelet.
43m 43m 1 kubelet, sdl02918 Gambar PeringatanGCGagal tidak dapat menemukan data untuk container /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk Node sdl02918 statusnya sekarang: NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientMemory Node sdl02918 statusnya sekarang: NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 Normal NodeHasNoDiskPressure Node sdl02918 statusnya sekarang: NodeHasNoDiskPressure
42m 42m 1 kube-proxy, sdl02918 Mulai Normal Memulai kube-proxy.

Jadi sepertinya node tidak pernah siap. Ada saran?

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

Menggunakan CentOS, dan kubeadm versi 1.6.1-1, dan mengikuti langkah-langkah di atas, saya mendapatkan perilaku yang sedikit berbeda: cluster dilaporkan sebagai siap tetapi kemudian saya terjebak pada pesan ini:

[apiclient] Temporarily unable to list nodes (will retry)

Namun, di log, kami masih memiliki kesalahan yang sama:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning Itu dia! Saya masih perlu menerapkan beberapa gambar untuk melihat apakah semuanya berfungsi tetapi saya dapat melihat semua node dengan status Ready ! Terima kasih semuanya (untuk saat ini :)

@bostone Saya mengikuti resep yang sama dengan yang Anda gunakan, tetapi mendapatkan hasil yang berbeda-- saya tidak berhasil melewati kubeadm init. Versi buruh pelabuhan apa yang Anda gunakan? mungkin thats perbedaan dalam kasus saya?

@dcowden Itu apa pun yang dipilih yum di sistem saya Docker version 1.12.6, build 96d83a5/1.12.6 . Juga yang membantu saya adalah menyediakan kembali semua VM yang saya gunakan alih-alih mencoba memperbaiki di atas pemasangan saya sebelumnya

@bostone terima kasih. saya akan menurunkan versi ke versi itu untuk melihat apakah saya bisa mendapatkan pengaturan yang berfungsi. di sistem saya yang terbaru adalah versi 17.03.1.ce yang aneh (ternyata yang terbaru adalah yang terbaik)

Tidak yakin apakah ini secara umum berguna, tetapi saya memiliki buku pedoman yang memungkinkan itu
melakukan semua langkah untuk CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, tapi setidaknya mendokumentasikan prosesnya. Saya juga melakukan beberapa hal seperti
alihkan buruh pelabuhan untuk menggunakan logging file json dan penyimpanan overlay.

Mungkin berguna sebagai referensi meskipun Anda tidak benar-benar menjalankan buku pedoman.

Pada Tue, Apr 4, 2017 at 12:55, Dave Cowden [email protected]
menulis:

@bostone https://github.com/bostone terima kasih. saya akan menurunkan versi ke itu
versi untuk melihat apakah saya bisa mendapatkan pengaturan yang berfungsi. di sistem saya yang terbaru adalah
versi aneh 17.03.1.ce (ternyata yang terbesar terbaru)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning Terima kasih! itu sangat membantu!

Oke, inilah salah satu komplikasinya. setelah menjalankan kubeadm reset pada master dan minion dan me-restart layanan docker dan kubelet kubeadm init hang pada Created API client, waiting for the control plane to become ready sekali lagi. Adakah yang bisa memberikan langkah lengkap untuk mengatur ulang kubeadm?
@sjenning sudahkah Anda mencoba menjalankan kembali buku pedoman Anda setelah Anda menjalankannya pada awalnya?

@bostone dalam kasus saya memindahkan /var/lib/etcd/ berhasil.

@autostatic direktori kosong dan mengganti namanya tidak membantu. @sjenning kamu playbook hang, aku

Adakah yang mencoba menjalankan dasbor di v1.6.1? Saya mendapatkan kesalahan yang menyatakan sebagai berikut:

`Terlarang (403)

Pengguna " system:serviceaccount :kube- system:default " tidak dapat membuat daftar namespace pada lingkup cluster. (dapatkan ruang nama)
`

Saya kira saya perlu mengonfigurasi lebih banyak RBAC, seperti yang harus Anda lakukan untuk menjalankan Flannel?

@srzjulio Bisakah Anda mengajukan masalah baru untuk itu? Dugaan saya adalah bahwa SIG Auth dan tim Dashboard harus bekerja sama. Ini mungkin perubahan YAML sederhana.

@srzjulio Anda perlu memperbarui aturan RBAC, kami menggunakan ini untuk memulai:

apiVersion: rbac.authorization.k8s.io/v1alpha1
jenis: ClusterRoleBinding
metadata:
nama: cluster-admin
peranRef:
apiGroup: rbac.authorization.k8s.io
jenis: Peran Cluster
nama: cluster-admin
mata pelajaran:

• jenis: Grup
  nama: sistem: master
• jenis: Grup
  nama: sistem: diautentikasi
• jenis: Grup
  nama: sistem: tidak diautentikasi

Hati-hati -- Ikatan yang dimiliki @sbezverk pada dasarnya mematikan RBAC. Anda akan memiliki cluster yang sangat tidak aman jika Anda melakukannya.

kind: Group
name: system:unauthenticated

Ini sangat buruk. Itu berarti siapa pun yang dapat menghubungi server API Anda, bahkan tanpa kredensial apa pun, dapat menjalankan perintah arbitrer.

@jbeda itu cocok dengan perilaku yang kami miliki dengan 1.5.6 langsung. Ini memberi orang kesempatan untuk meninjau dan secara bertahap menyesuaikan konfigurasi keamanan alih-alih tidak dapat melakukan apa pun dengan aturan keamanan baru.

Sebenarnya, membuat sistem: tidak diautentikasi sebagai admin cluster jauh lebih buruk daripada 1.5.6

Jika Anda tidak menginginkan otorisasi, gunakan otorisasi AlwaysAllow

Jika Anda ingin mengizinkan semua saat Anda mengaudit, gunakan kombinasi RBAC,AlwaysAllow

Itu akan menonaktifkan permintaan anonim, mencatat penolakan RBAC di log server API, tetapi terus mengizinkan semua permintaan yang diautentikasi untuk melakukan apa pun yang mereka inginkan

Maaf, dan saya mengulangi ini lagi, ini tidak ada hubungannya dengan masalah aslinya. Dan meskipun masalah dan masalah valid, kita harus mengalihkan pembicaraan ke tempat lain.

Sekali lagi maaf, tekan enter terlalu cepat, tetapi seperti yang terjadi:

1 - rilis 1.6.0 menyebabkan masalah
2 - tidak semuanya tetap
3 - pindah ke RBAC (menurut saya bagus) tapi bermasalah, kenapa? lihat poin 4
4 - Ini tidak dikomunikasikan dengan baik, dan tidak banyak dokumen/blog atau apa pun untuk menjelaskannya
5 - Saya tunduk pada semua ppl yang mencoba menyelamatkan, tetapi kami membutuhkan cara yang lebih baik untuk melakukan ini

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions adalah panduan yang baik untuk opsi granular paling kecil yang Anda miliki untuk membuka izin.

menambahkan " --cgroup-driver=systemd " di kublet menyebabkan masalah baru pada Centos/RHEL 7.3 (sepenuhnya mutakhir - alias buruh pelabuhan 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

sementara kita dapat melihat dengan jelas bahwa native.cgroupdriver=systemd diatur dalam daemon buruh pelabuhan:

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng mengapa Anda tidak memperbarui buruh pelabuhan ke 1.12.6? Bekerja seperti pesona dengan versi ini.

@sbezverk : Saya baru saja memperbarui ke 1.12.5 dan sekarang berfungsi! Terimakasih banyak!

Terima kasih semua atas bantuannya.
Akhirnya k8s 1.6.1 bekerja penuh dengan kain flanel. Semuanya sekarang ada dalam buku pedoman yang memungkinkan.
Diuji pada Centos/RHEL. Persiapan dimulai untuk berbasis Debian juga (misalnya Ubuntu), tetapi mungkin perlu beberapa penyempurnaan.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS: bekerja berdasarkan sjenning/kubeadm-playbook - Terima kasih banyak @sjenning !

@sjenning @ReSearchITEng
Hai, Saya memiliki buku pedoman gelandangan+ansible [0] yang sangat mirip dengan yang Anda buat, tetapi saya masih tidak dapat membuatnya berfungsi, meskipun bagi saya itu gagal pada pengaturan jaringan. Saya sudah mencoba dengan belacu, tenun dan kain flanel, dan ketiganya gagal (walaupun dengan gejala yang berbeda).

Saya menjalankan versi ini:
[ gelandangan@master ~]$ buruh pelabuhan --versi
Docker versi 1.12.6, build 3a094bd/1.12.6
[ gelandangan@master ~]$ kubelet --version
Kubernetes v1.6.1
[ gelandangan@master ~]$ versi kubeadm
kubeadm versi: version.Info{Mayor:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"04-03T20:33: 27Z", GoVersion:"go1.7.5", Kompilator:"gc", Platform:"linux/amd64"}

kesalahan:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Ini terlihat seperti informasi penting, tetapi saya tidak yakin bagaimana cara memperbaikinya:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Bantuan apa pun akan sangat dihargai...

[0]- https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

Saya tidak dapat mengidentifikasi apa yang salah di pihak Anda.
Saya sangat menyarankan Anda mencoba membuat instalasi terpisah menggunakan buku pedoman di sini: https://github.com/ReSearchITEng/kubeadm-playbook dan coba lihat apa bedanya.
PS: tes terakhir saya adalah dengan 1.6.2 , baik kube* dan gambar dan tampaknya baik-baik saja.

@kelseyhightower

@ReSearchITEng maaf saya lupa melaporkan kembali, tetapi akhirnya saya berhasil, file gelandangan+ansible saya ada di sini: https://github.com/thiagodasilva/kubernetes-swift

Saya juga mendapatkan masalah yang sama, tetapi saya hanya menyalin konfigurasi cni pada node master ke lokasi node pekerja yang sesuai, kemudian menjadi OK.

systemctl status kubelet.service -l

● kubelet.service - kubelet: Agen Node Kubernetes
Dimuat: dimuat (/etc/systemd/system/kubelet.service; diaktifkan; preset vendor: dinonaktifkan)
Drop-In: /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
Aktif: aktif (berjalan) sejak Selasa-06-06 10:42:00 CST; 18 menit yang lalu
Dokumen: http://kubernetes.io/docs/
PID Utama: 4414 (kubelet)
Memori: 43.0M
CGroup: /system.slice/kubelet.service
4414 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --network-plugin=cni - -cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorizatio -ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=cgroupfs
4493 jurnalctl -k -f

06 Juni 10:59:46 contiv1.com kubelet[4414]: W0606 10:59:46.215827 4414 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
06 Jun 10:59:46 contiv1.com kubelet[4414]: E0606 10:59:46.215972 4414 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady=false ready pesan:docker : plugin jaringan belum siap: cni config tidak diinisialisasi
06 Juni 10:59:51 contiv1.com kubelet[4414]: W0606 10:59:51.216843 4414 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
06 Jun 10:59:51 contiv1.com kubelet[4414]: E0606 10:59:51.216942 4414 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady=false ready pesan:docker : plugin jaringan belum siap: cni config tidak diinisialisasi
06 Juni 10:59:56 contiv1.com kubelet[4414]: W0606 10:59:56.217923 4414 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
06 Jun 10:59:56 contiv1.com kubelet[4414]: E0606 10:59:56.218113 4414 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady=false ready pesan:docker : plugin jaringan belum siap: cni config tidak diinisialisasi
06 Juni 11:00:01 contiv1.com kubelet[4414]: W0606 11:00:01.219251 4414 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
06 Jun 11:00:01 contiv1.com kubelet[4414]: E0606 11:00:01.219382 4414 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady=false ready pesan:docker : plugin jaringan belum siap: cni config tidak diinisialisasi
06 Juni 11:00:06 contiv1.com kubelet[4414]: W0606 11:00:06.220396 4414 cni.go:157] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net.d
06 Jun 11:00:06 contiv1.com kubelet[4414]: E0606 11:00:06.220575 4414 kubelet.go:2067] Jaringan runtime container tidak siap: NetworkReady=false ready pesan:docker : plugin jaringan belum siap: konfigurasi cni tidak diinisialisasi

Status semua node:
[ root@swarm net.d]# kubectl get node
NAMA STATUS USIA VERSI
contiv1.com Siap 1 jam v1.6.4
contiv2.com Siap 1 jam v1.6.4
swarm.com Siap 1 jam v1.6.4

Ada resolusi tentang ini? Saya tidak dapat melakukan ini bahkan setelah mencoba semua resolusi yang disebutkan.

Karena baru dalam menyiapkan Kubernetes, saya menjadi sangat bingung. Saya mencoba mengikuti https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 yang menggunakan weave-kube untuk jaringan tetapi saya juga terjebak dengan masalah yang sama . Adakah cara untuk menyelesaikan ini?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Mengapa ini masih menjadi masalah? Ubuntu 16.04/CentOS 7.3 dengan pembaruan terbaru menggunakan repo k8s resmi dengan 1.6.4 dan mengikuti langkah-langkah yang diuraikan di sini: https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen Tidak, ini mempengaruhi _only v1.6.0_ . Kubelet diharapkan tidak menemukan jaringan karena Anda belum menginstalnya. Misalnya, jalankan saja

kubectl apply -f https://git.io/weave-kube-1.6

untuk menginstal Weave Net dan masalah tersebut akan hilang. Anda dapat memilih untuk menginstal Flanel, Calico, Canal atau jaringan CNI apa pun jika Anda mau

@luxas Saya terus melihat referensi untuk ini, tetapi bagaimana saya bisa menerapkan sesuatu ke cluster yang tidak berjalan? Saya tidak punya apa-apa untuk dihubungkan.

@drajen Saya pikir poin @luxas adalah bahwa ini adalah tempat yang salah untuk bertanya tentang pengaturan.
Berbagai panduan penyiapan akan membantu Anda melewati titik ini - langkah khas yang hilang dalam panduan lama, yang disebutkan dengan sangat membantu luxas, di mana Anda perlu menerapkan konfigurasi jaringan sebelum semuanya mulai bekerja dengan benar.

Ya, itu mungkin tidak jelas dan kami minta maaf untuk itu, tetapi kami juga tidak dapat memiliki satu nama penyedia di sana.

Mengobrol dengan @drajen di Slack dan masalahnya terkait dengan cgroup, kubelet tidak sehat dan tidak dapat membuat Pod apa pun, oleh karena itu masalahnya.

Terima kasih kepada @luxas karena telah https://github.com/kubernetes/kubeadm/issues/302

Masih mengenai ini di lengkungan pada 1.7, apakah ada perbaikan cepat di mana saja?

Sunting:

kubectl apply -f https://git.io/weave-kube-1.6

berhasil, sepertinya kita hanya perlu menjalankan CNI

Setidaknya untuk CentOS/RHEL, pastikan Anda memperbarui /etc/systemd/system/kubelet.service.d/10-kubeadm.conf dan menambahkan flag --cgroup-driver="systemd"

Jika Anda menginstal ulang lagi pada mesin yang sama, ini adalah reset penuh yang tepat:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(ini diperlukan terutama jika Anda menggunakan kain flanel)
Jika Anda ingin melakukan semuanya dalam satu, Anda mungkin ingin menggunakan seluruh proyek: https://github.com/ReSearchITEng/kubeadm-playbook/

Saya mengalami masalah ini, dan sama sekali tidak ada yang saya baca di atas yang berfungsi. Jadi saya mencoba lagi dengan pengaturan yang jauh lebih terkontrol, beralih dari Ubuntu ke CoreOS terbaru, pergi ke versi k8s yang lebih lama untuk memulai, dan secara umum sangat anal tentang setiap hal terakhir yang diinstal ke setiap VM. Saya TIDAK menggunakan kubeadm, melainkan kombinasi gelandangan dan mungkin.

(mengapa? karena saya tidak tahu apa yang terjadi di kubeadm dan berpikir dengan cara ini setidaknya saya akan memiliki kontrol dan dapat melewati pemeriksaan preflight yang terlalu bersemangat, belum lagi perasaan seperti saya memiliki lebih banyak kontrol otomatisasi secara umum, dan juga tidak perlu khawatir tentang peringatan untuk melakukan-tidak-menerapkan-alpha-software-in-production.)

Ketika saya mencoba pengaturan ini dengan edisi k8s (1.4.3) yang lebih lama, pendekatan ini sangat bagus. Saya kemudian mencoba memutakhirkan ke 1.71. Sekali lagi, saya MASIH menghadapi masalah yang sama meskipun tidak menggunakan kubeadm sama sekali.

Saya telah mengkonfirmasi bahwa saya menjalankan belacu di setiap node saya, termasuk Master dan tiga Pekerja potensial. SEMUA node saya melaporkan sebagai NotReady, jadi saya tidak begitu yakin bagaimana saya bisa menerapkan weave (atau apa pun) untuk menjalankannya.

Semua ini sepertinya ayam/telur ... tidak dapat mengalokasikan pod karena jaringan gagal, tetapi perlu menjalankan jaringan untuk membuat jaringan di /etc/cni/net.d agar dapat mengalokasikan pod. Dan lagi, semua ini bekerja beberapa jam yang lalu dengan k8s 1.4.3. Saya sangat frustrasi!

Saya akan menghargai setiap wawasan yang bisa diberikan siapa pun.

Catatan kaki:

Pada master: journalctl -r -u kubelet memberi saya

24 Jul 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] Jaringan runtime container tidak siap: NetworkReady= alasan salah pesan:docker : plugin jaringan tidak
24 Jul 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: W0724 00:48:16.590588 7647 cni.go:189] Tidak dapat memperbarui konfigurasi cni: Tidak ada jaringan yang ditemukan di /etc/cni/net .D

buruh pelabuhan ps | grep calico

(dipotong agar mudah dibaca)
cde... quay.io/calico/ leader-elector@sha256 :... "/run.sh --election=c" 8 jam yang lalu Naik 8 jam
f72... calico/ kube-policy-controller@sha256 :... "/dist/controller" 8 jam lalu Naik 8 jam
c47... gcr.io/google_containers/pause-amd64:3.0 "/pause" 8 jam yang lalu Naik 8 jam

Tidak ada /etc/cni/net.d

Dari kotak kubectl saya:
kubectl dapatkan node
10.0.0.111 Tidak Siap, Penjadwalan Dinonaktifkan 8 jam v1.7.1+coreos.0
10.0.0.121 Tidak Siap 8h v1.7.1+coreos.0
10.0.0.122 Tidak Siap 8h v1.7.1+coreos.0
10.0.0.123 Tidak Siap 8h v1.7.1+coreos.0

kubectl apply -f https://git.io/weave-kube-1.6

TIDAK memperbaiki apa pun dan pada kenyataannya sepertinya hanya menciptakan lebih banyak masalah.

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl apply -f https://git.io/weave-kube-1.6
akun layanan "weave-net" dibuat
clusterrolebinding "weave-net" dibuat
daemonset "weave-net" dibuat
Kesalahan dari server (Terlarang): clusterroles.rbac.authorization.k8s.io "weave-net" dilarang: upaya untuk memberikan hak istimewa tambahan: [PolicyRule{Resources:["pods"], APIGroups:[""], Kata kerja: ["get"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["pods"], APIGroups:[""], Kata kerja: ["watch"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["get"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Kata kerja: ["list"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["watch"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Kata kerja: ["get"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Kata kerja: ["watch"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Kata kerja:["get"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Kata kerja:["list"]} PolicyRule{Sumber daya:["networkpolicies"], APIGroups:["extensions"], Kata kerja:["watch"]}] user=&{kube-admin [system:a diautentikasi] peta[]} ownerrules=[] ruleResolutionErrors=[]

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl dapatkan pod --namespace=kube-system
NAMA STATUS SIAP RESTART USIA
kube-apiserver-10.0.0.111 1/1 Berjalan 1 8j
kube-controller-manager-10.0.0.111 1/1 Menjalankan 1 8j
kube-dns-v20-fcl01 0/3 Tertunda 0 8j
kube-proxy-10.0.0.111 1/1 Berjalan 1 8j
kube-proxy-10.0.0.121 1/1 Berjalan 1 8j
kube-proxy-10.0.0.122 1/1 Berjalan 1 8j
kube-proxy-10.0.0.123 1/1 Berjalan 1 8j
kube-scheduler-10.0.0.111 1/1 Berjalan 1 8j
kubernetes-dashboard-v1.4.1-29zzk 0/1 Tertunda 0 8j
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 Berjalan 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

Penyelidikan yang lebih dalam dari kesalahan menenun menunjukkan bahwa mereka (a) tidak dapat terhubung ke apiserver, atau (b) dalam kasus yang ditandai "Berjalan" itu mengeluh bahwa itu tidak dapat terhubung ke dirinya sendiri.

@billmilligan Memiliki masalah serupa, dns berhenti bekerja beberapa menit setelah wadah dimulai

@Paxa @billmilligan Jika Anda ingin mendapatkan bantuan, jangan mengomentari masalah ini. Sebagai gantinya, buka yang baru di repo kubeadm dengan detail yang cukup diminta.

@luxas Dengan hormat, saya harus mempertanyakan apakah ini masalah baru. Karena saya mendapatkan hasil yang sama persis dengan pengaturan k8s tanpa kubeadm seperti yang didapatkan orang lain dengan kubeadm, ini tampaknya menghilangkan kubeadm sebagai sumber masalahnya. Mungkin masalah ini harus diganti namanya?

@billmilligan dengan hormat, karena masalahnya adalah tentang kubeadm, dan Anda dapat mereproduksinya tanpa kubeadm, maka itu adalah tempat yang salah untuk mengajukannya? Saya pikir utas ini menyelesaikan masalah kubeadm. Ini adalah masalah baru. Saya pikir itu akan mendapat lebih banyak perhatian sebagai masalah baru. Karena orang-orang di utas ini menganggapnya sudah terpecahkan dan mengabaikannya.

Saya menggunakan kubeadm dan dipengaruhi oleh masalah ini, dan telah diselesaikan sejak 1.6.1. Saya telah menggunakan k8 yang hilang sejak itu, jadi saya benar-benar berpikir Anda memiliki masalah terpisah.

@kfox1111 Terima kasih atas umpan baliknya. Saya akan mengajukan masalah baru, tetapi jumlah orang yang tampaknya masih menghadapinya di tempat lain di 1.7.x masih membuat saya bertanya-tanya.

TL; DR;

Pesan kesalahan

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

TIDAK selalu buruk.

Pesan kesalahan itu memberi tahu Anda bahwa Anda harus memasang plugin di penyedia implementasi spesifikasi CNI pihak ketiga .

Apa itu CNI dan bagaimana integrasinya dengan Kubernetes?

CNI adalah singkatan dari Container Network Interface dan mendefinisikan spesifikasi yang kubelet gunakan untuk membuat jaringan untuk cluster. Lihat halaman ini untuk informasi lebih lanjut tentang bagaimana Kubernetes menggunakan spesifikasi CNI untuk membuat jaringan untuk cluster.

Kubernetes tidak peduli bagaimana jaringan dibuat selama memenuhi spesifikasi CNI.

kubelet bertanggung jawab untuk menghubungkan Pod baru ke jaringan (bisa berupa jaringan overlay misalnya).
kubelet membaca direktori konfigurasi (biasanya /etc/cni/net.d ) untuk digunakan oleh jaringan CNI.
Saat Pod baru dibuat, kubelet membaca file di direktori konfigurasi, exec 's keluar ke biner CNI yang ditentukan dalam file konfigurasi (biner sering di /opt/cni/bin ). Biner yang akan dieksekusi adalah milik dan diinstal oleh pihak ketiga (seperti Weave, Flannel, Calico, dll.).

kubeadm adalah alat generik untuk menjalankan cluster Kubernetes dan tidak tahu solusi jaringan apa yang Anda inginkan dan tidak mendukung siapa pun secara spesifik. Setelah kubeadm init dijalankan, tidak ada biner atau konfigurasi CNI seperti itu . Ini berarti kubeadm init TIDAK CUKUP untuk mengaktifkan dan menjalankan cluster yang berfungsi penuh.

Artinya, setelah kubeadm init , log kubelet akan mengatakan

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

ini sangat diharapkan. Jika bukan ini masalahnya, kami akan memilih penyedia jaringan tertentu.

Jadi bagaimana saya "memperbaiki" kesalahan ini?
Langkah selanjutnya dalam panduan memulai kubeadm adalah "Menginstal jaringan Pod".
Ini berarti, kubectl apply manifes dari penyedia jaringan CNI pilihan Anda.

DaemonSet akan menyalin binari CNI yang diperlukan ke /opt/cni/bin dan konfigurasi yang diperlukan ke /etc/cni/net.d/ . Juga akan menjalankan daemon aktual yang mengatur jaringan antara Node (dengan menulis aturan iptables misalnya).

Setelah penyedia CNI terinstal, kubelet akan melihat bahwa "oh saya punya beberapa informasi tentang cara mengatur jaringan", dan akan menggunakan konfigurasi dan binari pihak ketiga.

Dan ketika jaringan diset oleh penyedia pihak ke-3 (dengan memanggilnya kubelet), Node akan menandai dirinya sendiri Ready .

Bagaimana masalah ini terkait dengan kubeadm?

Di akhir siklus v1.6, sebuah PR digabungkan yang mengubah cara kubelet melaporkan status Ready/NotReady . Dalam rilis sebelumnya, kubelet selalu melaporkan status Ready , terlepas dari apakah jaringan CNI telah disiapkan atau tidak. Ini sebenarnya agak salah, dan diubah untuk menghormati status jaringan CNI. Yaitu, NotReady saat CNI tidak diinisialisasi dan Ready saat diinisialisasi.

kubeadm di v1.6.0 salah menunggu node master berada dalam status Ready sebelum melanjutkan dengan tugas kubeadm init lainnya. Ketika perilaku kubelet berubah menjadi report NotReady ketika CNI tidak diinisialisasi, kubeadm akan menunggu selamanya sampai Node mendapatkan Ready .

BAHWA SALAH SATU TUNGGU DI SISI KUBEADM ADALAH MASALAH INI

Namun, kami dengan cepat memperbaiki regresi di v1.6.1 dan merilisnya beberapa hari setelah v1.6.0.

Silakan baca retrospektif untuk informasi lebih lanjut tentang ini, dan mengapa v1.6.0 dapat dirilis dengan cacat ini.

Jadi, apa yang Anda lakukan jika Anda merasa melihat masalah ini di kubeadm v1.6.1+?

Yah, saya benar-benar berpikir Anda tidak. Masalah ini tentang saat kubeadm init menemui jalan buntu.
Tidak ada pengguna atau pengelola yang melihatnya di v1.6.1+.

Apa yang AKAN Anda lihat adalah

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

setelah setiap kubeadm init di semua versi di atas v1.6, tapi itu TIDAK BURUK

Bagaimanapun, tolong buka edisi baru jika Anda melihat sesuatu yang tidak terduga dengan kubeadm

Tolong jangan berkomentar lebih banyak tentang masalah ini. Alih-alih membuka yang baru.

@billmilligan Jadi, Anda hanya perlu kubectl apply manifes penyedia CNI untuk mengaktifkan dan menjalankan cluster Anda, saya pikir

Saya cukup meringkas apa yang telah dikatakan di atas, tetapi mudah-mudahan dengan cara yang lebih jelas dan terperinci.
Jika Anda memiliki pertanyaan tentang cara kerja CNI, lihat saluran dukungan normal seperti StackOverflow, masalah, atau Slack.

(Terakhir, maaf untuk teks yang terlalu tebal, tetapi saya merasa itu diperlukan untuk mendapatkan perhatian orang.)