Kubeadm: apiserver gagal memulai karena livenessprobe terlalu agresif

Tampaknya kita menyetel InitialDelaySeconds dan TimeoutSeconds menjadi 15 untuk pod bidang kontrol saat ini, yang juga cocok dengan apa yang dilakukan kube-up.sh . Saya memahami peluncuran awal berjalan lambat, dengan semua gambar ditarik sekaligus, tetapi setelah semua gambar ditarik, berapa lama apiserver Anda merespons cek /healthz setelah diluncurkan?

Tidak diragukan lagi kita mungkin harus menyesuaikan kedua nilai ini untuk mengakomodasi mesin berdaya rendah.

Setelah dimulai, ia dapat merespons health check dalam << 15s - ini benar-benar hanya semua hal tambahan yang dilakukan apiserver antara exec () dan benar-benar siap untuk melayani afaics.

oh, dan waktu tarik buruh pelabuhan tidak dihitung terhadap afaics InitialDelaySeconds (bagus). Dalam contoh lain dengan gambar yang lebih besar (ubuntu generik) melalui tautan jaringan saya yang lambat, tarikan dapat memakan waktu beberapa menit tetapi pengatur waktu initialDelaySeconds tampaknya tidak mulai berdetak sampai tarikan selesai dan pengoperasian buruh pelabuhan telah dimulai. (Saya belum melihat kode yang relevan - hanya pengalaman anekdot yang sering)

Saya menjalankan masalah yang sama. Dengan mesin lambat kubeadm duduk selamanya. Menggunakan v1.7.4

@anguslees dan @koalalorenzo , dapatkah Anda mengonfirmasi bahwa jika Anda secara manual mengubah pengaturan probe kehidupan (dengan mengedit file manifes di /etc/kubernetes/manifests/ ) bahwa ini memperbaiki masalah Anda? Saya juga baru-baru ini melihat kasus di Slack di mana pengguna memiliki gejala yang sama tetapi kemungkinan mengalami kendala memori, karena masalahnya hilang ketika mereka pindah ke jenis host dengan lebih banyak memori.

Saya hanya ingin memastikan bahwa pendekatan ini benar-benar akan memperbaiki masalah sebelum kita menginvestasikan waktu untuk mengkodekannya. Terima kasih!

Saya juga mengalami masalah ini saat mencoba menggunakan kubeadm di QEMU tanpa virtualisasi yang dibantu perangkat keras (yang merupakan ide buruk karena sangat lambat). Meningkatkan InitialDelaySeconds dan TimeoutSeconds membantu; cluster kemudian akan muncul.

@pipejakob Saya dapat mengonfirmasi bahwa (di bananapi saya) menjalankan ini di terminal lain pada titik yang tepat dalam menjalankan kubeadm membuat semuanya berhasil:

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(Saya biasanya juga secara manual docker kill wadah apiserver lama / restart-looping, saya tidak yakin apakah itu dibersihkan secara otomatis dengan pod statis)

@anguslees Hebat! Terima kasih atas konfirmasinya.

Saya dapat mengonfirmasi bahwa saya juga baru saja mengalami masalah ini, dalam kasus saya pada raspberry pi 3. Mengubah ke 180s memperbaikinya, namun saya pikir saya juga mengalami masalah # 106 seperti dalam kasus saya itu hanya mati dengan:

Sep 1 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] Menghapus mirror pod "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1)
1e7-ae86-b827ebdd4b52) "karena sudah usang

Saya harus HUP proses kubelet secara manual untuk membuatnya hidup kembali.

Saya juga dapat mengonfirmasi bahwa saya memiliki ini dan ingin mengucapkan terima kasih karena telah menyelamatkan kewarasan saya. Saya memiliki Raspberry Pi 2B dan saya terjebak di fase init selama sebulan terakhir. Setelah menjalankan one-liner itu setelah mulai menunggu pesawat kontrol, saya melanjutkannya.

Masalah ini masih ada di kubeadm v1.8.0, dan lebih buruk karena kubeadm itu sendiri sekarang memiliki waktu tunggu 1 menit untuk sebagian besar tindakan. Batas waktu 1 menit tampaknya telah dipilih secara sewenang-wenang, dan sayangnya a) tidak memberi Anda cukup waktu untuk masuk dan men-debug / mengatasi masalah (misalnya: sed hack di atas), b) cukup waktu bagi apiserver untuk memulai (~ 90-an untuk saya), bahkan ketika initialDelaySeconds diperpanjang, dan c) tidak dapat ditingkatkan tanpa meretas / membangun kembali kubeadm afaics.

Waktu tunggu mendobrak logika yang benar, terutama dalam sistem kompleks yang akhirnya konsisten - kita tidak boleh menambahkannya "hanya karena" :( Pemahaman saya adalah bahwa kubeadm dimaksudkan untuk menjadi blok bangunan yang dapat diandalkan oleh sistem penerapan yang lebih besar. Oleh karena itu, saya dengan berani mengusulkan untuk menghapus semua waktu tunggu dari kubeadm itu sendiri (berbagai fase harus terus mencoba lagi selamanya), dan mengandalkan proses tingkat yang lebih tinggi untuk menambahkan waktu tunggu keseluruhan jika / saat sesuai dalam konteks tingkat yang lebih tinggi. Dalam kasus penggunaan sederhana / langsung ini akan berarti "coba lagi sampai pengguna menyerah dan menekan ^ c". Apakah PR seperti itu dapat diterima?

@anguslees Kami memiliki perilaku "menunggu selamanya" sebelumnya; tapi itu sangat kurang optimal dari UX PoV, jadi sekarang kami punya waktu tunggu. Kami mungkin ingin menambah beberapa waktu tunggu tersebut jika Anda mau.

Masalahnya adalah penggunaan kubeadm dua kali lipat. Kami berdua memiliki pengguna yang mengetik kubeadm secara interaktif yang ingin tahu apakah sesuatu terjadi atau tidak _dan_ konsumen tingkat yang lebih tinggi.

.. Jadi ke mana kita akan pergi ke sini? Saat ini saya menggunakan garpu kubeadm yang memiliki banyak waktu tunggu yang diputar hingga 10x, dan saya _ ingin_ percaya bahwa saya dapat kembali menggunakan binari standar kubeadm di beberapa titik.

@anguslees Kami memiliki perilaku "menunggu selamanya" sebelumnya; tapi itu sangat kurang optimal dari UX PoV, jadi sekarang kami punya waktu tunggu. Kami mungkin ingin menambah beberapa waktu tunggu tersebut jika Anda mau.

Bagaimana kalau membuatnya dapat dikonfigurasi? Apakah masuk akal untuk memiliki satu opsi yang memiliki semuanya?

/ prioritas penting-segera

Apakah masuk akal untuk memiliki satu opsi yang memiliki semuanya?

Mungkin, atau semacam "bobot" untuk semua waktu tunggu yang akan dikalikan dengan ... Jika tidak, kita akan masuk ke neraka konfigurasi dengan 20 jenis tanda batas waktu yang berbeda :)

Mengalami masalah yang sama menggunakan peningkatan kubeadm pada kluster raspberry pi 2. Peningkatan gagal karena waktu tunggu yang agresif. Mengubah pengaturan probe keaktifan di manifes tidak membantu. Ada ide?

Saya masih mengusulkan pola di mana batas waktu kubeadm diwarisi dari konteks panggilan (atau bagian dari strategi pemulihan kesalahan yang lebih canggih), daripada menaburkan batas waktu sewenang-wenang di seluruh tingkat basis kode kubeadm yang lebih rendah.

Dalam bentuk yang paling sederhana, ini akan berperilaku hampir persis seperti menghapus semua waktu tunggu dari kubeadm dan menggantinya dengan satu keseluruhan "jalankan selama xx menit, kemudian batalkan jika tidak selesai" pengatur waktu global (karena kubeadm tidak dapat berbuat banyak di jalan kesalahan pemulihan selain hanya menunggu lebih lama).

Untuk batas waktu nyata livenessProbe, ini secara harfiah adalah tambalan satu baris. Sayangnya, memperbaiki livenessProbe saja tidak lagi cukup karena kekeliruan "deviasi dari normal == error" telah menyebar lebih jauh ke seluruh basis kode kubeadm. Mengubah kesadaran budaya itu sulit, jadi sementara itu saya memiliki versi kubeadm bercabang di sini , jika ada yang ingin menginstal ke raspberry pi. (Dibangun dengan make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

@anguslees Apakah Anda memiliki versi

Saya terkejut kubeadm tidak memiliki perilaku ini di balik bendera. Mungkin PR sudah beres?

/ tetapkan @liztio

Jadi kami telah memperbaiki dua masalah di 1,11 yang dapat memengaruhi ini.

1. Prepull gambar etcd sebelum startup.
2. Perbaiki pemeriksaan kondisi balapan saat memulai.
   ...

Jika ini hanya terjadi pada rasberry pi - gear maka kita memerlukan beberapa cara untuk mengkualifikasikan penyebut terkecil yang sama.

Apa platform target terendah yang kami rencanakan untuk didukung?

Saya pikir Raspberry Pi 2 adalah platform terendah yang Anda inginkan untuk menjalankan Kubernetes. Pengujian saya dengan QEMU yang dibantu non-perangkat keras terlalu eksotis untuk dipertimbangkan.

Mempertimbangkan bahwa Pi sangat menderita I / O lambat, pra-penarikan semua gambar sudah akan banyak membantu, tetapi kami memerlukan beberapa tes dunia nyata untuk menentukan batas waktu yang sebenarnya.

imo rasberry pi2 terlalu tua untuk didukung - http://socialcompare.com/en/comparison/raspberrypi-models-comparison , keluar pada tahun 2015.

>= 3 sepertinya lebih masuk akal imo.

Gambar prapulling tidak akan membantu. Timer livenessProbe tidak mulai sampai setelah gambar ditarik (seperti yang saya tunjukkan di atas ).

Perbaikannya hanya dengan memperpanjang waktu tunggu initialDelaySeconds . Nilai batas waktu saat ini di kubeadm sedang disalahgunakan untuk "menerapkan" pengalaman UX yang cepat, dan bukan deteksi kesalahan.

Sunting: Dan untuk memperjelas, hanya startup yang membutuhkan waktu lama - cluster kontrol saya beroperasi pada 3xRPi2 dengan baik, setelah saya meningkatkan batas waktu apiserver awalalDelaySeconds (dan waktu tunggu hanya-instal lainnya yang digunakan dalam kubeadm itu sendiri). Saya tidak mengerti mengapa kita masih membicarakan ini: /

Saya memiliki cluster ARM64 di 1.9.3 dan berhasil memperbarui ke 1.9.7 tetapi mendapat masalah batas waktu untuk meningkatkan dari 1.9.7 ke 1.10.2.

Saya bahkan mencoba mengedit dan mengkompilasi ulang kubeadm meningkatkan batas waktu (seperti komitmen terakhir ini https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) dengan hasil yang sama.

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

Jika kubeadm digunakan dan apiserver dijalankan, kita dapat mencoba mengukur poin pada startup pertama. Mungkin kami mengubah konfigurasi di tahap selanjutnya untuk batas waktu yang disesuaikan pada pengukuran pada inisialisasi pertama. Juga sulit untuk mengetahui, bahwa apiserver ditendang oleh pemeriksaan healtz yang melihat log, setidaknya kita bisa mendapatkan logging yang lebih baik untuk menyadari masalah tersebut. Saya butuh waktu beberapa saat untuk mengetahui bahwa livenessprobe adalah masalahnya. Saya harus menyebutkan bahwa saya seorang pemula, dan itu setidaknya akan membantu untuk disebutkan di suatu tempat pada keluaran kegagalan untuk kubeadm.

RaspberryPi 3 masih menunjukkan masalah ini, bahkan dengan gambar yang sudah ditarik sebelumnya. Server API membutuhkan waktu 2-3 menit untuk sampai ke tempat yang dapat melayani halaman ...

Akan sangat bagus jika ini dapat dikonfigurasi, karena saat ini, saya sedang menambal file YAML di latar belakang saat kubeadm berjalan.

@carlosedp yang saya lakukan selama upgrade adalah menghapus kubelet saat apiserver sedang boot. Ini agak hacky, tetapi mencegah health-check diaktifkan sampai apiserver habis.

Tapi sejujurnya kubeadm upgrade dan ARM tidak bekerja sama dengan baik dalam pengalaman saya ...

@brendandburns Ini bekerja dengan sempurna sampai 1.9. Saya menerapkan cluster 1.8 saya dengannya tanpa cegukan, lalu meningkatkan ke 1.9 dua kali. Tidak tahu apa yang mungkin berubah di 1.10 yang menyebabkan masalah ini.

Saya melihat bahwa batas waktu berubah dalam 1,11 menjadi 5 menit (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). Sudahkah Anda mencoba dengan 1,11?

Akan mencoba retasan ini setelah saya kembali dari liburan. Terima kasih atas tipnya!

@brendburn @carlosedp
ya, coba 1.11 untuk mengonfirmasi bahwa peningkatan batas waktu adalah perbaikan untuk Anda.

/ cc @ kubernetes / sig-cluster-lifecycle-bugs

Hei! Saya juga mengalami masalah ini.
Menariknya, saya berhasil membangun master cluster dari awal di Raspberry 3 saya, tetapi secara konsisten gagal di 3+ ​​saya.
Bagaimanapun, Versi yang saat ini saya gunakan (sesuai dengan dokumentasi langkah demi langkah di https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/) adalah
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

Seperti yang lainnya, wadah apiserver akhirnya bangun, tetapi tidak sebelum kubeadm keluar, meninggalkan saya dalam limbo karena saya terlalu tidak berpengalaman untuk mengambilnya secara manual dari sana.

Pembaruan Cepat: berjalan
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
di terminal terpisah memungkinkan cluster saya untuk bangun.

@Jamur_kejang
terima kasih telah menguji 1.11.

Seperti yang lainnya, wadah apiserver akhirnya bangun, tetapi tidak sebelum kubeadm keluar, meninggalkan saya dalam limbo karena saya terlalu tidak berpengalaman untuk mengambilnya secara manual dari sana.

berapa lama waktu yang dibutuhkan apiserver untuk memulai kasus Anda?
tampaknya kami harus membuat ini dapat dikonfigurasi.

Sulit untuk mengatakan, saya kira kira-kira 1 menit, namun saya tidak tahu bagaimana mengukurnya dengan benar.

Selain itu, sekarang master saya beroperasi, saya gagal menambahkan node ke sana dengan apa yang tampaknya menjadi masalah batas waktu lainnya.
`[preflight] menjalankan pemeriksaan pra-penerbangan
[PERINGATAN DiperlukanIPVSKernelModulesAvailable]: proxy IPVS tidak akan digunakan, karena modul kernel yang diperlukan berikut tidak dimuat: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] atau tidak ada dukungan ipvs kernel bawaan: map [ip_vs_rr: {} ip_vs_ nf_conntrack_ipv4: {} ip_vs: {}]
Anda dapat mengatasi masalah ini dengan metode berikut:

1. Jalankan 'modprobe -' untuk memuat modul kernel yang hilang;
   
   
   
   1. Sediakan dukungan ipv kernel bawaan yang hilang
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] Memvalidasi versi kernel
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] Memvalidasi konfigurasi kernel
[PERINGATAN SystemVerification]: versi docker lebih besar dari versi yang paling baru divalidasi. Versi Docker: 18.03.1-ce. Versi validasi maks: 17.03.0
[penemuan] Mencoba untuk terhubung ke Server API "192.168.2.2:6443"
[penemuan] Membuat klien penemuan info cluster, meminta info dari " https://192.168.2.2 : 6443"
[penemuan] Meminta info dari " https://192.168.2.2 : 6443" lagi untuk memvalidasi TLS terhadap kunci publik yang disematkan
[penemuan] Tanda tangan info cluster dan kontennya valid dan sertifikat TLS divalidasi terhadap root yang disematkan, akan menggunakan API Server "192.168.2.2:6443"
[penemuan] Berhasil membuat koneksi dengan Server API "192.168.2.2:6443"
[kubelet] Mendownload konfigurasi untuk kubelet dari ConfigMap "kubelet-config-1.11" di namespace sistem kube
[kubelet] Menulis konfigurasi kubelet ke file "/var/lib/kubelet/config.yaml"
[kubelet] Menulis file lingkungan kubelet dengan flag ke file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Mengaktifkan layanan kubelet
[tlsbootstrap] Menunggu kubelet untuk melakukan TLS Bootstrap ...
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
Sayangnya, telah terjadi kesalahan:
waktu tunggu kondisi habis

Kesalahan ini mungkin disebabkan oleh:
- Kubelet tidak bekerja
- Kubelet tidak sehat karena kesalahan konfigurasi node dalam beberapa hal (cgroup yang diperlukan dinonaktifkan)

Jika Anda menggunakan sistem yang didukung systemd, Anda dapat mencoba memecahkan masalah kesalahan dengan perintah berikut:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
batas waktu menunggu kondisi`

Selama waktu ini, tidak ada satu pun container buruh pelabuhan yang muncul di node saya.

[PERINGATAN DiperlukanIPVSKernelModulesAvailable]:

offtopic, kita membicarakannya di sini:
https://github.com/kubernetes/kubeadm/issues/975

Selain itu, sekarang master saya beroperasi, saya gagal menambahkan node ke sana dengan apa yang tampaknya menjadi masalah batas waktu lainnya.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.

kubelet tidak bisa mulai. lebih baik lihat log kubelet.

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

probe liveness harus dibuat dapat dikonfigurasi, namun kita mungkin harus berbicara tentang cara terbaik untuk melakukannya di konfigurasi kubeadm.

Saya pikir ini adalah nilai-nilai yang digunakan, jadi jika Anda membuat kubeadm sendiri, coba mainkan:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
tetapi perlu diingat bahwa ini akan menambah waktu tunggu pada semua komponen bidang kontrol.

Sunting: Saya tampaknya terlalu bodoh untuk memformat komentar dengan benar di Github :-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

harap diingat bahwa log ini tidak menunjukkan kesalahan.

Ya tapi itu bagian dari Masalah yang saya percaya. Saya tidak bisa menemukan satu baris pun dari [ERROR] di mana pun untuk memulai. Itulah yang membuat saya sangat frustasi :-)

Bagaimanapun, terima kasih telah memformat kekacauan saya :-D

Jadi, apa langkah yang baik selanjutnya?

Jadi, apa langkah yang baik selanjutnya?

seperti yang disebutkan sebelumnya:

probe liveness harus dibuat dapat dikonfigurasi, namun kita mungkin harus berbicara tentang cara terbaik untuk melakukannya di konfigurasi kubeadm.

Saya pikir ini adalah nilai-nilai yang digunakan, jadi jika Anda membuat kubeadm sendiri, coba mainkan:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
tetapi perlu diingat bahwa ini akan menambah waktu tunggu pada semua komponen bidang kontrol.

Jika saya tidak membangun kubeadm sendiri, saya menariknya melalui apt dari apt.kubernetes.io. Saya tidak memiliki apa pun yang menyerupai pipa build untuk digunakan di salah satu mesin saya (belum pernah mengutak-atiknya). Saya berharap akan ada file serupa untuk dimodifikasi ketika bergabung dengan cluster seperti yang ada untuk membuatnya, namun karena tampaknya nilai-nilai ini di-hardcode ke dalam utils.go: - |

Anda dapat mencoba solusi ini, tetapi rumit:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

masalahnya adalah bahwa ini memerlukan perubahan konfigurasi dan saya rasa itu tidak dapat dimasukkan dalam rilis 1.11.X (tapi kami dapat mencoba). itu juga harus didiskusikan dulu.

Itulah yang sudah saya lakukan di komentar di mana saya memberi tahu Anda bahwa master sudah habis (itulah yang dilakukan oleh perintah watch -n 1.0 saya). Apa yang terjadi sekarang adalah kubeadm join tidak berfungsi, dan sejauh yang saya lihat, kubeadm join tidak menempatkan file yaml untuk saya tambal di mana saja: - /

Anda mungkin mengalami masalah lain. sulit untuk dikatakan.

ini adalah nilai-nilai yang digunakan, jadi jika Anda membuat kubeadm sendiri, coba mainkan:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

Jadi saya perhatikan waktu tunggu InitialDelaySeconds di sini adalah _still_ 15s setahun kemudian, dan saya tidak mengerti mengapa itu belum ditingkatkan menjadi sesuatu yang benar-benar mewakili kenyataan. Apakah laporan bug ini memiliki tujuan apa pun? Awalnya saya tidak mengusulkan PR untuk mengubah nomor ini sendiri karena saya merasa seseorang yang sudah berada di lingkaran dalam kubeadm dapat menyelesaikannya dan bergabung dalam beberapa menit, tetapi saya senang melakukannya jika "kurangnya PR" adalah satu-satunya alasan kami belum bergerak maju.

Saya merasa semua orang mencoba mencari alasan untuk menyatakan laporan bug asli tidak valid (mungkin kita tidak mendukung rPi2, mungkin kita harus membuat penundaan awal dapat dikonfigurasi, mungkin kita harus menarik gambar atau beberapa perubahan lain yang tidak terkait, mungkin a Kegagalan batas waktu buram cepat adalah UX yang lebih baik daripada keberhasilan yang lebih lambat), alih-alih hanya meningkatkan waktu tunggu initialDelay untuk mencerminkan initialDelay aktual yang ditunjukkan dengan jelas oleh biner kami dan kemudian beralih ke hal lain yang benar-benar perlu dibahas.

Jadi saya perhatikan waktu tunggu InitialDelaySeconds di sini masih 15 detik setahun kemudian, dan saya tidak mengerti mengapa itu belum ditingkatkan menjadi sesuatu yang benar-benar mewakili kenyataan. Apakah laporan bug ini memiliki tujuan apa pun? Awalnya saya tidak mengusulkan PR untuk mengubah nomor ini sendiri karena saya merasa seseorang yang sudah berada di lingkaran dalam kubeadm dapat menyelesaikannya dan bergabung dalam beberapa menit, tetapi saya senang melakukannya jika "kurangnya PR" adalah satu-satunya alasan kami belum bergerak maju.

saya tidak dapat menjawab pertanyaan Anda karena seluruh masalah ini baru bagi saya, tetapi kami dapat mencoba membicarakannya minggu ini. harap dicatat bahwa tim di balik kubeadm adalah tim kecil dengan tujuan besar dan seringkali tidak ada orang yang mengerjakan tugas tertentu, seperti ini.

Saya merasa semua orang mencoba mencari alasan untuk menyatakan laporan bug asli tidak valid (mungkin kita tidak mendukung rPi2, mungkin kita harus membuat penundaan awal dapat dikonfigurasi, mungkin kita harus menarik gambar atau beberapa perubahan lain yang tidak terkait, mungkin a Kegagalan batas waktu buram cepat adalah UX yang lebih baik daripada keberhasilan yang lebih lambat), alih-alih hanya meningkatkan waktu tunggu initialDelay untuk mencerminkan initialDelay aktual yang ditunjukkan dengan jelas oleh biner kami dan kemudian beralih ke hal lain yang benar-benar perlu dibahas.

ya, opsi telah dibahas di utas ini. ini masalah memilih opsi yang tepat dan melakukan penerapan.

Saya benar-benar percaya akan masuk akal untuk default ke "tanpa batas waktu" dengan opsi untuk menetapkan batas waktu untuk seluruh proses (seperti yang disarankan di suatu tempat sebelumnya dalam masalah ini).

Alasannya adalah bahwa sebagian besar kasus penggunaan yang dapat saya pikirkan sebenarnya tidak peduli apakah langkah tertentu dijalankan dalam X Detik atau tidak karena semua yang diperhatikan dalam sistem terdistribusi adalah konsistensi akhirnya (menggulung node lain untuk berjaga-jaga lebih murah) daripada mengutak-atik pengaturan).

Sebagai solusi sementara, akan cukup untuk benar-benar membaca pengaturan batas waktu untuk kubeadm join dari file konfigurasi seperti yang dilakukan kubeadm init sehingga peretasan kami dengan penggantian batas waktu dalam penerbangan berfungsi. Ini adalah peretasan, jangan berpikir berbeda - tetapi peretasan yang buruk masih lebih baik daripada tidak ada solusi sama sekali.

Saya pribadi menentang mencoba untuk "menebak" waktu tunggu yang masuk akal karena tebakan selalu bisa salah, tidak akan benar-benar memenuhi tujuan dalam kasus ini (karena strategi penanggulangan untuk melewati batas waktu hanyalah bailing out) dan akan membuat reproduksi kesalahan menyebalkan di keledai karena dua sistem yang identik dapat mulai berperilaku berbeda karena berbagai alasan.

@anguslees @DJGummikuh kami telah membicarakan hal itu pada pertemuan SIG baru-baru ini.

ini adalah masalah yang sulit, tetapi berikut adalah beberapa catatan acak di bawah ini.

catatan:

• beberapa dari orang-orang kami memiliki banyak pengalaman dan mereka mengatakan bahwa ini berbau seperti kondisi balapan yang menghentikan start apiserver. seharusnya tidak butuh waktu lama. ini bisa menjadi hal ARM vs GOLANG.
• Saya telah meminta SIG API Machinery tetapi tidak mendapat tanggapan tentang nilai probe keaktifan yang disarankan dan jika mereka mencurigai jenis masalah yang berbeda di sini.
• kami telah sepakat bahwa mengekspos opsi konfigurasi atau variabel lingkungan atau parameter baris perintah adalah ide yang buruk untuk kubeadm . alasan di baliknya adalah bahwa kami tidak ingin mengekspos parameter yang dapat memiliki arti yang sewenang-wenang bagi pengguna.
• tidak ada seorang pun di tim yang pernah melihat masalah seperti itu pada mesin yang lambat (misalnya VM lambat), yang berarti bahwa ini mungkin terkait dengan RPi dan seluruh argumen bahwa hal ini disebabkan oleh perangkat keras yang "lambat" tidak valid.
• lihat ini: https://github.com/kubernetes/kubernetes/issues/64357 pengguna tidak melaporkan masalah pemeriksaan keaktifan sama sekali. tahu kenapa begitu?
• Adakah yang pernah melihat masalah pada sesuatu seperti https://www.scaleway.com/ , menurut teori di utas ini seharusnya terjadi di sana juga?
• Sebagai intinya, kita telah membahas bahwa hardcoding nilai batas waktu / penundaan yang lebih besar tidak terlalu menjadi masalah bagi kubeadm, jadi jika seseorang ingin mengirimkan PR untuk itu, silakan. ( @kontol_gt )

lihat ini: kubernetes / kubernetes # 64357 pengguna tidak melaporkan masalah probe liveness sama sekali. tahu kenapa begitu?

Tidak, bahkan tampaknya tidak dapat direproduksi lagi di perangkat keras saya sekarang. Karena token untuk bergabung dengan node telah berlalu, saya berpikir "apa-apaan" dan kubeadm mengatur ulang master cluster saya dan mencoba untuk memasukkannya kembali (menjalankan solusi jam tangan itu) - sekarang bahkan dengan solusi itu saya tidak lagi dapat menariknya master di Raspberry Pi 3+ saya. Saya bahkan meningkatkan batas waktu yang dikonfigurasi dari 180 menjadi 300 detik tanpa perbedaan apa pun. Jadi saya suka gagasan ini sebagai kondisi balapan.
Tetap saja saya menyambut saran Anda untuk menarik permintaan waktu tunggu yang lebih tinggi. Tidak akan terlalu menyakitkan dan memberikan pi (yang merupakan perangkat keras yang lambat, saya pikir kita semua dapat menyetujui bahwa :-)) sedikit lebih banyak ruang untuk bernafas.

masalah terkait pada ARM64 di apiserver:
https://github.com/kubernetes/kubernetes/issues/64649

Melakukan beberapa penelitian lagi dengan Cluster Pi saya (masih gagal :-() selama akhir pekan.

Saya menginstal ulang salah satu node saya karena saya curiga bahwa memperbarui dari Pi 2 ke Pi 3+ tanpa menginstal ulang OS dapat menyebabkan beberapa masalah. Ini bukan masalahnya, masalahnya sama dengan OS baru.
Selain itu, saya berusaha untuk mengkompilasi kubernetes dengan waktu tunggu yang meningkat dan mengujinya. Juga, ini tidak benar-benar membuahkan hasil.
Saya bisa mendapatkan master (dengan solusi jam tangan saya untuk menambal file konfigurasi) tetapi bergabung dengan cluster dengan node kedua tidak pernah berhasil.

Akan sangat rapi jika memiliki beberapa keluaran log tambahan yang berguna untuk mengatasi masalah ini. Namun saya tidak cukup mengerti tentang bagaimana komponen kubernetes berinteraksi untuk mengetahui di mana harus menambahkan baris.

Ada yang siap untuk tantangan ini? ^^

ini benar-benar masalah di luar kubeadm ...

Orang-orang mesin api tidak melihat permintaan saya untuk memberikan komentar tentang masalah ini, jadi kecuali tiket sudah dicatat untuk ini, seseorang harus memasukkannya ke dalam kubernetes/kubernetes repo dan memberi tag /sig api-machinery .

Akan sangat rapi jika memiliki beberapa keluaran log tambahan yang berguna untuk mengatasi masalah ini. Namun saya tidak cukup mengerti tentang bagaimana komponen kubernetes berinteraksi untuk mengetahui di mana harus menambahkan baris.

sebagai permulaan seseorang dapat mengaktifkan --v 4 untuk kubelet di file drop-in systemd, yang akan memberitahu logger GLOG untuk mengaktifkan verbositas tinggi.
seseorang juga dapat melakukan hal yang sama untuk komponen bidang kontrol dari konfigurasi kubeadm dengan ini:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

Ini memecahkan masalah pada cluster Raspberry Pi 3 saya: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian bagus Saya berhasil menambalnya dan sekarang cluster saya juga aktif. AKHIRNYA, setelah berminggu-minggu menderita! Terima kasih :-)

@joejulian terima kasih telah menyelidiki!
perbaikan potensial dapat ditemukan di https://github.com/kubernetes/kubernetes/pull/66264

tutup sampai pemberitahuan lebih lanjut.

/Menutup

apakah ada cara untuk melewatkan pengaturan seperti itu di file init kubeadm? mungkin di apiServerExtraArgs ? Sungguh menyakitkan melihat file untuk menambalnya, agak sulit untuk diotomatiskan.

Tidak ada. Mungkin itu akan menjadi fitur yang bagus untuk ditambahkan.

Pembaruan selanjutnya telah menambahkan lebih banyak hal untuk diperiksa dan perpanjangan waktu tunggu PR saya tidak lagi mencukupi. Saya sudah menyerah untuk mengatur batas waktu. Solusi bagi saya adalah menggunakan sertifikat ecdsa.

Selain itu, layanan pengontrol termasuk etcd membutuhkan lebih banyak ram, sekarang, daripada Raspberry Pi memiliki lebih dari dua kali lipat jumlah node untuk menjadi tuan rumah bidang kontrol, saya telah meningkatkan ke Rock64s.

Maafkan pelesetan itu, tapi bidang kendali saya telah menjadi kokoh sejak saat itu.

Saya baru saja mencoba melakukan penginstalan pada Raspberry Pi 3+ dan dapat mengonfirmasi bahwa penginstalan memang gagal. Menggunakan trik 'jam tangan' pada kube-apiserver.yaml yang tercantum di atas tampaknya bekerja secara konsisten ... tetapi hanya jika saya mengubah initialDelaySeconds menjadi 360. Nilai yang disarankan sebesar 180 tampaknya marjinal pada mesin saya.

Ketika hal-hal menjadi terlalu mudah, kubeadm sekarang mengeluh bahwa versi Docker (18.09) tidak didukung. Pengembalian cepat ke 18.06 memperbaiki masalah.

di kubeadm 1.13 kami menambahkan flag konfigurasi di bawah ClusterConfig-> ApiServer yang dapat mengontrol batas waktu server api.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

flag konfigurasi di bawah ClusterConfig-> ApiServer yang dapat mengontrol waktu tunggu server api.

Mencari melalui basis kode untuk TimeoutForControlPlane , menurut saya defaultnya adalah 4 menit, dan hanya digunakan untuk penundaan yang digunakan oleh kubeadm sendiri untuk menunggu apiserver menjadi sehat. Secara khusus, itu _tidak_ mengubah livenessprobe apiserver yang digunakan oleh kubelet itu sendiri. Apakah itu benar?

Saya rasa saya tidak pernah melihat argumen tandingan muncul di mana pun dalam diskusi seputar masalah ini. Apakah ada alasan mengapa kami _tidak hanya meningkatkan livenessProbe initialDelaySeconds dan beralih ke masalah lain?

Selain: Sejauh yang saya bisa lihat dari pembacaan singkat, TimeoutForControlPlane juga tidak memperhitungkan penyebab non-kegagalan lainnya untuk peningkatan penundaan startup apiserver, seperti kemacetan saat menarik banyak gambar, atau batas waktu tambahan + coba lagi loop iterasi sementara semuanya berkumpul pada waktu penginstalan awal (batas waktu + coba lagi berulang kali adalah pola desain k8s ... dan ini kadang-kadang terjadi pada sistem yang dimuat, yang diharapkan dan baik-baik saja). Saya pribadi merasa 4minutes terlalu lama untuk pengguna interaktif yang tidak sabar yang mengharapkan kegagalan cepat, dan terlalu pendek untuk proses penginstalan pada sistem yang dimuat / lambat / otomatis yang siap menunggu lebih lama untuk kesuksesan yang diharapkan. Bagaimana ini sampai, bisakah kita default ke 5 menit? Bisakah kita terus mencoba lagi hingga SIGINT? Mengapa kita memberlakukan tenggat waktu jam dinding buatan secara internal daripada mewarisinya dari lingkungan panggilan?

Afaics TimeoutForControlPlane hanya menampilkan deadline internal fatal yang sewenang-wenang sebagai parameter di mana satu-satunya UX yang dimaksudkan hanyalah untuk meningkatkan parameter sampai batas waktu tidak pernah tercapai. Atau, kita bisa saja _tidak_ memaksakan batas waktu internal fatal yang sewenang-wenang itu sejak awal ...

Itu poin yang sangat bagus dan saya setuju dengan sepenuh hati.

Secara khusus, ini tidak mengubah livenessprobe apiserver yang digunakan oleh kubelet itu sendiri. Apakah itu benar?

ya, belum ada rencana untuk memodifikasi probe kehidupan dari kubeadm.

Masalah rpi ini dikualifikasikan pada pertemuan sig-cluster-lifecyle sebagai "sesuatu yang seharusnya tidak terjadi", "tampaknya hampir seperti kondisi balapan di kubelet", "mengapa ini hanya terjadi pada rpi dan bukan pada perangkat lain yang lebih lambat". saya harus mengakui bahwa saya sendiri belum menguji perangkat yang lambat.

yaitu ada kesepakatan yang meningkatkan nilai ini:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
bukanlah perbaikan yang baik dan sepertinya solusi untuk bug lain.

Bagaimana ini sampai, bisakah kita default ke 5 menit?

batas waktu adalah 30 menit sebelum menjadi 4 menit, karena mengambil gambar sebagai pertimbangan sebelum 1,11.
jika Anda memiliki pendapat tentang 4 vs 5 menit, PR yang digariskan dengan baik dengan poin-poin kuat tentang subjek tersebut mungkin akan berhasil di 1,14.

Masalah rpi ini dikualifikasikan pada pertemuan sig-cluster-lifecyle sebagai "sesuatu yang seharusnya tidak terjadi", "tampaknya hampir seperti kondisi balapan di kubelet", "mengapa ini hanya terjadi pada rpi dan bukan pada perangkat lain yang lebih lambat".

Itu semua adalah alasan untuk terus mencari bug lain di tempat lain juga, tetapi tidak satupun dari itu adalah alasan _not_ untuk meningkatkan initialDelaySeconds. Apakah sebenarnya ada sisi negatif untuk meningkatkan initialDelaySeconds?

Untuk mendekatinya dari arah lain, jika kita mengetahui bahwa kita memiliki masalah di tempat lain di kubernetes dengan solusi yang dapat digunakan di kubeadm - apakah peran kubeadm untuk "menahan garis" pada kemurnian dan menghasilkan hasil yang diketahui rusak? Hal itu tampaknya bertentangan dengan tujuan untuk menjadi alat yang kami harapkan akan digunakan oleh orang-orang untuk penerapan yang sebenarnya. Sejauh ini saya tidak dapat menggunakan kubeadm di cluster saya tanpa menambalnya untuk menambah waktu tunggu (meskipun melaporkannya, dengan patch, lebih dari setahun yang lalu), yang membuat saya sedih.

(Permintaan maaf karena membiarkan beberapa frustrasi saya seputar masalah ini bocor ke nada saya)

jika Anda memiliki pendapat tentang 4 vs 5 menit

Mendesah. Saya mencoba membuat kasus untuk batas waktu _no_ di kubeadm, tetapi saya belum menemukan cara untuk mengutarakan proposal itu secara meyakinkan (lihat ini dan upaya gagal lainnya dalam masalah ini, misalnya) :(

Itu semua adalah alasan untuk terus mencari bug lain di tempat lain juga, tetapi tidak satupun dari itu adalah alasan untuk tidak meningkatkan initialDelaySeconds. Apakah sebenarnya ada sisi negatif untuk meningkatkan initialDelaySeconds?

Ini adalah perubahan kecil, tetapi telah disepakati untuk tidak menambahkan kenaikan ini karena ini juga akan berlaku untuk sistem yang tidak menjalankan masalah tersebut.

Untuk mendekatinya dari arah lain, jika kita mengetahui bahwa kita memiliki masalah di tempat lain di kubernetes dengan solusi yang dapat digunakan di kubeadm - apakah peran kubeadm untuk "menahan garis" pada kemurnian dan menghasilkan hasil yang diketahui rusak? Hal itu tampaknya bertentangan dengan tujuan untuk menjadi alat yang kami harapkan akan digunakan oleh orang-orang untuk penerapan yang sebenarnya.

menghadapi pengguna akhir adalah tujuan untuk kubeadm, itu benar.
tetapi sekali lagi ini hanya laporan untuk rpis dan bug yang sebenarnya harus ditingkatkan ke sig-api-mesin (server api) dan sig-node (kubelet) dan mungkin direproduksi di luar kubeadm.

Sejauh ini saya tidak dapat menggunakan kubeadm di cluster saya tanpa menambalnya untuk menambah waktu tunggu (meskipun melaporkannya, dengan patch, lebih dari setahun yang lalu), yang membuat saya sedih.

Anda tidak perlu menambal kubeadm, Anda dapat menambal file manifes sebagai gantinya.
kubeadm 1.13 meluluskan fase init ke perintah tingkat atas - misalnya kubeadm init phase [phase-name]
fase ada sebagian besar karena pengguna menginginkan kontrol khusus tentang bagaimana node bidang kontrol dibuat ..

jika Anda melakukan kubeadm init --help itu akan menunjukkan kepada Anda dalam urutan apa fase-fase tersebut dieksekusi.

sehingga Anda dapat memecah perintah kubeadm init ke dalam fase yang sesuai, Anda menggunakan manifes khusus untuk komponen bidang kontrol dan melewati fase control-plane . ada juga --skip-phases sekarang.

Anda sudah bisa melakukannya di 1,11 dan 1,12, tetapi itu kurang mudah.

karena itu juga akan berlaku untuk sistem yang tidak menjalankan masalah.

Jadi .. ada apa dengan itu? Kami memperbaiki bug sepanjang waktu yang hanya memicu pada beberapa sistem. Di mana pun kita memiliki waktu tunggu, kita perlu menyesuaikannya untuk sistem kita yang paling lambat, bukan hanya sebagian dari lingkungan kita, bukan?

Sudut lain dalam hal ini adalah bahwa sebagai seorang ops, saya takut kegagalan berjenjang dalam situasi kelebihan beban, terutama dengan apiserver itu sendiri. Afaics, batas waktu livenessprobe seharusnya hanya terpicu ketika segala sesuatunya benar-benar gagal , tidak hanya ketika itu menyimpang dari gagasan seseorang tentang "normal". Afaics kami _harus_ memiliki livenessprobe dikonfigurasi sangat santai, bahkan pada perangkat keras tercepat kami. DPI kecil saya hanya mendemonstrasikan kegagalan kelebihan beban ini dengan lebih mudah - tetapi juga berlaku untuk server yang lebih besar dalam skenario kelebihan beban / DoS yang lebih besar. Tidak ada keuntungan untuk memiliki initialDelaySeconds kecil . livenessprobe default kubeadm tidak perlu agresif di semua platform.

Maaf saya terus mengulangi poin yang sama, tetapi afaics ada alasan praktis dan teoritis yang kuat untuk memperpanjang initialDelaySeconds, dan saya hanya tidak memahami argumen lawan untuk membuatnya tetap kecil :(

menambahkan opsi konfigurasi kubeadm untuk ini tidak mungkin pada saat ini.

Saya mencoba menjelaskan bahwa ini sudah bisa dilakukan dengan 3 perintah di 1.13:

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

Saya tidak menginginkan opsi, saya mencoba mengatakan nilai tetap saat ini (15) harus diubah ke nilai tetap yang berbeda (360 disarankan di atas).

.. Tapi aku tidak ingin mempermasalahkan ini lebih jauh. Jelas bahwa keputusannya adalah tetap dengan nilai saat ini, jadi saya akan mundur. Terima kasih atas kesabaran Anda :)

@ neolit123 kombinasi itu tampak hebat - jauh lebih mudah daripada yang saya dokumentasikan - harus menunggu pesawat kontrol disetel kemudian dengan cepat menjalankan sed di terminal lain. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

Saya akan menguji instruksi dan ingin memperbarui panduan.

@ neolit123 inilah yang saya dapatkan dengan menggunakan konfigurasi di atas pada RPi3 B +

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

Dalam kubeadm-config.yaml - 192.168.0.26 adalah LB yang menunjuk ke 192.168.0.110

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

Saya mendapatkan hal yang sama bahkan tanpa config / lb IP eksternal.

Alex

Saya telah mendorong orang untuk menggunakan kubeadm untuk sementara waktu, bahkan sekolah ingin menjalankannya di kluster pi mereka. Meskipun saya mengerti tidak ingin mempersulit basis kode, saya pikir itu mungkin hal yang baik untuk basis pengguna Anda untuk mendukung berjalan pada perangkat kecil ini. itu memungkinkan orang-orang muda untuk menendang ban Kubernetes pada perangkat keras curang yang sebaliknya mungkin tidak. Solusi di atas, meskipun valid, jauh lebih sulit untuk kasus penggunaan ini.

Bagaimana dengan kompromi? Daripada membuatnya dapat dikonfigurasi, tambahkan heuristik sederhana yang mengatakan, jika bukan x86_64, setel batas waktu default lebih tinggi?

[kubeconfig] Menulis file "admin.conf" kubeconfig
[kubeconfig] Menulis file "kubelet.conf" kubeconfig
panic: runtime error: alamat memori tidak valid atau dereferensi penunjuk nol
[sinyal SIGSEGV: kode pelanggaran segmentasi = 0x1 addr = 0x8 pc = 0xaa7204]

aneh, admin.conf adalah mesin yang dihasilkan dan harus berisi tipe Config valid dengan current-context mengarah ke konteks.

kepanikan datang dari baris ini:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

Saya melihat kesalahan yang sama persis seperti: point_up: di atas dengan yang berikut:

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

Skrip berikut memecahkan masalah untuk saya menggunakan kubeadm versi 1.12, 1.13 ( sebagian besar waktu)

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

Saya berada dalam situasi yang sama, mendapatkan kesalahan yang sama dengan pendekatan yang disarankan oleh @ neolit123 .
Saya tidak dapat menjalankan skrip oleh @stephenmoloney , saya tidak terlalu paham dengan skrip bash, mungkin salah saya.

Jadi saya mem-porting skrip ke python (yang diinstal secara default di Raspbian, jadi tidak perlu ketergantungan tambahan), jika ada yang tertarik:

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

Untuk menjalankannya: sudo python however_you_name_the_file.py
Terima kasih telah mengarahkan saya ke solusinya, @stephenmoloney dan @ neolit123 !

Hai! masalah ini sangat membantu

Saya menemukan cara yang bagus untuk menyelesaikan masalah ini menggunakan kustomize

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom