@enisoc @dchen1107 @fejta @thockin @kow3ns @derekwaynecarr , buka masalah pelacakan ini agar kita bisa berdiskusi.

/menetapkan

@derekwaynecarr Saya telah melakukan beberapa scoping dari perubahan kubelet yang diperlukan untuk pertemuan sig-node minggu depan, saya _percaya_ bahwa perubahan hanya diperlukan dalam paket kuberuntime , khususnya kuberuntime_manager.go in dan kuberuntime_container.go .

Di kuberuntime_manager.go Anda dapat memodifikasi computePodActions untuk mengimplementasikan pemicu shutdown (matikan sidecars ketika semua non-sidecars telah keluar secara permanen), dan jalankan sidecars terlebih dahulu.

Di kuberuntime_container.go Anda dapat memodifikasi killContainersWithSyncResult untuk mengakhiri sidecars terakhir dan mengirim kait preStop (bit kait preStop agak bisa diperdebatkan, tidak diputuskan apakah itu harus dilakukan atau tidak. @ thockin punya poin bagus tentang mengapa Anda mungkin tidak ingin mendorong perilaku itu, lihat komentar ).

Beri tahu saya jika Anda ingin saya menyelidiki lebih lanjut.

@kow3ns Diskusi lebih masuk akal bagi saya jika mungkin kita dapat mendefinisikan deskripsi lengkap tentang urutan container di spesifikasi Pod (sig-app), dan bagaimana menangani urutan di kubelet untuk pertimbangan awal, restart dan cascading (sig-node). Mari kita saksikan pertemuan sig-node 5 Februari untuk memberikan lebih banyak masukan.

cc @Joseph-Irving

Proposal mengatakan bahwa sespan hanya berjalan setelah wadah init berjalan. Tetapi bagaimana jika kasus penggunaan mengharuskan sespan berjalan saat/sebelum wadah init berjalan. Misalnya, jika Anda ingin merutekan lalu lintas pod melalui proxy yang berjalan sebagai sespan (seperti pada Istio), Anda mungkin ingin proxy itu berada di tempatnya sementara wadah init berjalan jika wadah init sendiri melakukan panggilan jaringan.

@luksa Saya pikir ada kemungkinan melihat memiliki sespan yang berjalan di fase init di beberapa titik tetapi saat ini proposal tidak akan mencakup kasus penggunaan itu. Saat ini tidak ada cara untuk menjalankan wadah bersamaan di fase init sehingga berpotensi menjadi perubahan yang jauh lebih besar/lebih berantakan daripada yang disarankan di sini.

Pembaruan pada KEP ini:
Saya telah berbicara dengan @derekwaynecarr dan @dchen1107 dari sig-node tentang ini dan mereka tidak mengungkapkan kekhawatiran besar tentang proposal tersebut. Saya akan mengajukan PR ke KEP dengan menambahkan beberapa catatan awal seputar detail implementasi dan mengklarifikasi beberapa poin yang muncul selama diskusi.

Kita masih perlu menyepakati API, tampaknya ada konsensus bahwa cara sederhana menandai kontainer sebagai sidecar lebih disukai daripada flag pemesanan yang lebih mendalam. Memiliki bool agak membatasi, jadi mungkin sesuatu yang lebih seperti containerLifecycle: Sidecar akan lebih disukai sehingga kami memiliki opsi untuk memperluas di masa mendatang.

@Joseph-Irving Sebenarnya, baik boolean maupun containerLifecycle: Sidecar tidak sesuai untuk perpanjangan masa depan yang tepat. Sebaliknya, containerLifecycle harus menjadi objek, seperti deployment.spec.strategy , dengan type: Sidecar . Ini akan memungkinkan kami untuk kemudian memperkenalkan bidang tambahan. Untuk solusi "sespan untuk seluruh masa pakai pod", itu akan diekspresikan di sepanjang baris ini:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

sebagai lawan

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Maafkan penamaan saya yang buruk - saya harap nama-nama itu menyampaikan idenya.

Tetapi ada satu masalah dengan pendekatan di mana kami memperkenalkan containerLifecycle ke pod.spec.containers . Yaitu, memiliki sespan yang berjalan paralel dengan wadah init yang ditentukan di bawah pod.spec.containers . Jadi, jika Anda benar-benar ingin dapat memperluas ini ke wadah init pada akhirnya, Anda harus menemukan solusi alternatif - solusi yang memungkinkan Anda menandai wadah sebagai sespan pada tingkat yang lebih tinggi - yaitu tidak di bawah pod.spec.containers atau pod.spec.initContainers , tetapi sesuatu seperti pod.spec.sidecarContainers , yang saya yakin sudah Anda diskusikan, tetapi diabaikan. Masalah wadah init pasti membutuhkan solusi di sepanjang garis ini.

@luksa Anda juga dapat menyelesaikan masalah init dengan hanya mengizinkan wadah init ditandai sebagai sespan dan menjalankannya di samping wadah init. Seperti yang saya pahami, masalahnya adalah wadah init terkadang membutuhkan sespan, yang berbeda dengan membutuhkan wadah yang berjalan sepanjang masa pakai pod.

Masalah dengan pod.spec.sidecarContainers adalah bahwa ini adalah perubahan yang jauh lebih kompleks, perkakas perlu diperbarui dan kubelet akan membutuhkan banyak modifikasi untuk mendukung kumpulan kontainer lainnya. Proposal saat ini jauh lebih sederhana, hanya membangun apa yang sudah ada.

@Joseph-Irving Kita bisa bekerja dengan itu ya. Tidak ideal jika sespan dimatikan setelah wadah init berjalan dan kemudian sespan yang sama dinyalakan kembali, tetapi lebih baik daripada tidak memiliki opsi itu. Masalah yang lebih besar adalah bahwa Kubelet lama tidak akan menangani container init-sidecar dengan benar (seperti halnya container main-sidecar).

Saya hanya ingin Anda mengingat init-sidecars saat menyelesaikan proposal. Intinya, Anda memperkenalkan konsep "sespan" ke dalam k8s (sebelumnya, pada dasarnya kami hanya memiliki satu set wadah yang semuanya sama). Sekarang Anda memperkenalkan sespan yang sebenarnya, jadi IMHO, Anda benar-benar harus memikirkan ini secara menyeluruh dan tidak mengabaikan kasus penggunaan sespan yang sangat penting.

Saya akan dengan senang hati membantu menerapkan ini. Tanpa itu, Istio tidak dapat menyediakan fitur-fiturnya ke init container (sebenarnya, dalam cluster Kubernetes yang diamankan dengan baik yang menjalankan Istio, init container benar-benar kehilangan kemampuan untuk berbicara dengan layanan _any_).

Sehubungan dengan pembahasan implementasi di https://github.com/kubernetes/enhancements/pull/841 , saya telah membuka WIP PR yang berisi PoC dasar untuk proposal ini https://github.com/kubernetes/kubernetes/pull /75099. Ini hanya draf pertama dan jelas tidak sempurna tetapi fungsionalitas dasarnya berfungsi dan memberi Anda gambaran tentang jumlah perubahan yang diperlukan.

cc @enisoc

Saya membuat video pendek yang hanya menunjukkan bagaimana perilaku PoC saat ini https://youtu.be/4hC8t6_8bTs. Melihatnya dalam tindakan bisa lebih baik daripada membacanya.
Penafian: Saya bukan youtuber pro.

Saya telah membuka dua PR baru:

• https://github.com/kubernetes/enhancements/pull/918 adalah tentang kriteria kelulusan, versi miring, peningkatan/penurunan versi
• https://github.com/kubernetes/enhancements/pull/919 adalah untuk memutuskan implementasi API

Setiap pemikiran atau saran akan sangat dihargai.

@Joseph-Irving Maaf jika saya terlambat berkomentar dalam proses desain, tetapi saya memiliki kasus penggunaan potensial untuk wadah sespan yang mungkin tidak didukung dalam proposal desain saat ini. Saya hanya ingin mengangkatnya untuk dipertimbangkan. Intinya adalah saya memiliki skenario di mana pada penghentian pod, 1 sespan harus dihentikan sebelum wadah utama, sementara sespan lain harus dihentikan setelah wadah utama.

Contoh konkretnya mungkin pod dengan wadah aplikasi Django, sespan konsul untuk pendaftaran layanan, dan sespan pgbouncer untuk mengelola koneksi ke database. Ketika pod dihentikan, saya ingin sespan konsul dihentikan terlebih dahulu (sehingga tidak ada lagi lalu lintas yang dialihkan ke pod), lalu wadah aplikasi (idealnya setelah masa tenggang singkat), dan kemudian sespan pgbouncer. Proposal saat ini tampak bagus untuk menangani ketergantungan wadah pgbouncer aplikasi <->, tetapi tampaknya tidak cukup ekspresif untuk menangkap kasus di mana saya ingin merobohkan sespan _sebelum_ wadah utama.

@currankaushik , dalam skenario yang Anda gambarkan, Anda berpotensi menggunakan pengait pra-stop untuk memberi tahu wadah konsul untuk mempersiapkan shutdown dan menghentikan permintaan perutean kepada Anda (dengan asumsi itu dapat mendukung sesuatu seperti itu). kait pre stop akan dikirim ke sespan terlebih dahulu sebelum penghentian peti kemas dimulai.

Motivasi untuk ini adalah agar proxy sidecars seperti istio dapat memasuki keadaan di mana mereka tidak mengarahkan lalu lintas ke Anda tetapi masih mengizinkan lalu lintas keluar saat aplikasi Anda selesai dan dimatikan.

Kedengarannya bagus, terima kasih @Joseph-Irving. Jadi hanya untuk mengkonfirmasi pemahaman saya di tingkat tinggi: pengait pra-stop akan dikirim ke sespan terlebih dahulu, diikuti oleh pengait pra-berhenti ke non-samping, SIGTERM ke non-sespan, dan kemudian (setelah semua non-sidecars keluar ) SIGTERM ke sespan? Proposal desain (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) tampaknya menyiratkan ini tetapi juga mengatakan:

PreStop Hooks akan dikirim ke sidecars dan container secara bersamaan.

@currankaushik ya apa yang Anda gambarkan adalah perilaku yang dimaksudkan.

Baris yang Anda kutip perlu ditulis ulang. Saya memiliki beberapa kesalahpahaman tentang bagaimana kait prestop dikirim ke wadah ketika saya menulis itu. Terima kasih telah menunjukkannya.

@Joseph-Irving apakah fitur ini menargetkan inklusi alfa untuk 1,15?

@kacole2 ya itu rencananya, dengan asumsi kita bisa membuat KEP dapat diimplementasikan tepat waktu untuk pembekuan peningkatan (30 April). Setelah api diselesaikan https://github.com/kubernetes/enhancements/pull/919 dan rencana pengujian disetujui https://github.com/kubernetes/enhancements/pull/951 Saya pikir kita harus siap.

/ tonggak sejarah v1.15
/tahap alfa

@Joseph-Irving Kubernetes 1.15 Peningkatan Pembekuan adalah 30/4/2019. Untuk dimasukkan ke dalam milestone Kubernetes 1.15, KEP harus berada dalam status "Implementable" dengan rencana tes dan kriteria kelulusan yang tepat. Harap kirimkan PR apa pun yang diperlukan untuk membuat KEP ini memenuhi kriteria inklusi. Jika ini akan tergelincir dari tonggak 1,15, beri tahu kami agar kami dapat membuat perubahan pelacakan yang sesuai.

@mrbobbytables sayangnya PR yang dibuka untuk mendapatkan ini ke keadaan yang dapat diimplementasikan belum memiliki banyak gerakan, jadi saya pikir kita perlu menunda ini hingga 1.16.

Jangan khawatir. Terima kasih telah merespons dengan sangat cepat dan memberi tahu kami!
/pencapaian jelas

Perlu diingat, KEP ini sangat penting untuk Istio !

Ini adalah show stopper untuk semua proyek yang menggunakan kerangka kerja layanan dengan bootstrap/shutdown terkoordinasi (akka cluster, lagom, dll.) bersama dengan istio service mesh see .

cc @jroper

@Joseph-Irving maaf tentang komentar yang terlambat, tetapi saya tidak melihat yang berikut di dokumen desain, dan saya bertanya-tanya apa perilaku yang dimaksudkan dari ini:

jika kita melihat sidecar gagal, apakah kita selalu me-restart mereka jika container utama belum selesai (mengabaikan restartPolicy di pod)? Ini akan berguna sebagai sespan yang digunakan untuk bekerja sebagai proxy, load balancing, peran menjaga rumah, dan tidak masalah jika gagal beberapa kali selama wadah utama dapat terus bekerja

Juga, ketika menghitung fase pod, jika semua kontainer utama berhasil, dan sespan gagal (yang sangat umum jika sespan tidak menangkap SIGTERM kode kembalinya akan seperti 143 atau sesuatu), apakah fase pod masih "Berhasil"?

@zhan849 kontainer sespan saat ini mematuhi kebijakan restart pod dan dihitung saat menghitung fase pod seperti Succeeded .

Kami memang memperdebatkan ini sedikit lebih awal dalam proses tetapi perasaan umumnya adalah bahwa kami harus menyimpang dari wadah normal sesedikit mungkin, hanya melakukannya jika memungkinkan kasus penggunaan yang dijelaskan.

Berkenaan dengan fase pod: Saya berpendapat bahwa semua aplikasi yang berjalan di kubernetes harus menangani SIGTERM (terutama sidecars), tetapi juga terkadang Anda ingin tahu apakah sidecars Anda keluar dengan cara yang buruk dan itu harus tercermin dalam fase pod, menyembunyikan info itu dapat menyebabkan kebingungan.

Untuk kebijakan restart, sepertinya itu hanya akan menjadi masalah jika kebijakan restart tidak pernah dan sespan Anda cenderung mogok. Saya tidak yakin apakah komplikasi dari memisahkan mereka dari kebijakan restart pod sepadan, terutama karena beberapa orang mungkin ingin sidecar mereka mematuhi kebijakan restart pod.

Kedua hal ini sejalan dengan apa yang dilakukan wadah normal dan apa yang terjadi saat ini.
Mengubah mereka tampaknya tidak diperlukan untuk mencapai tujuan yang tercantum dalam Kep.

Jika Anda memiliki beberapa kasus penggunaan yang tersebar luas mengapa mengubahnya diperlukan untuk mencapai tujuan tersebut, itu akan berguna. Karena membuatnya lebih mudah untuk membenarkan perubahan yang lebih rumit pada basis kode.

@Joseph-Irving kami memiliki beberapa mobil sampingan yang lebih sederhana yang telah berjalan secara internal untuk beberapa kebutuhan mendesak (kami tidak berkontribusi karena ini sudah berlangsung di komunitas), dan inilah yang kami pelajari.

Mengenai fase pod:

1. Status container ada sudah tercermin dalam pod.status.containerStatuses sehingga kami tidak kehilangan informasi. Selain itu, karena kasus penggunaan sidecar yang besar ada di Job (atau pod run-to-finish seperti yang ada di Kubeflow), beban kerja yang berarti hanya akan diterapkan ke container utama dan jika fase pod ditandai sebagai Failed karena kegagalan sidecar , akan ada percobaan ulang yang tidak perlu dan menyebabkan konsekuensi menyesatkan lainnya seperti Job gagal, dll.

2. Meskipun ideal untuk sidecars untuk menangani SIGTERM, dalam produksi, mungkin ada banyak sidecars yang hanya dibangun di atas perangkat lunak opensource dan mereka tidak menangani SIGTERM dengan baik, termasuk kube-proxy , postfix , rsyslogd , dan banyak lainnya (dan bahkan jika SIGTERM ditangani, untuk SIGKILL yang tidak dapat ditangkap, itu pasti bukan 0)

Mengenai kebijakan restart (bisa diperdebatkan tetapi memiliki sidecars yang secara ketat mematuhi restartPolicy agak tidak realistis dalam produksi):

1. Memaksa sespan untuk memulai ulang saat kontainer utama masih berjalan dengan menyetel "OnFailure" bukanlah opsi karena ini akan memulai ulang kontainer utama yang gagal dan membingungkan bersama dengan batas coba ulang level Pekerjaan.

2. Biasanya saat menangani sespan, peti kemas utama biasanya memiliki banyak logika coba lagi untuk sespan yang tidak tersedia, dan ini dilakukan sebelum komunitas memiliki dukungan gerbong dengan urutan awal peti kemas yang eksplisit. Penanganan kesalahan historis seperti itu tidak mudah diubah mengingat cakupannya. Tidak memulai kembali sespan akan menyebabkan kontainer utama hang dan mencoba lagi

3. Menyebarkan kegagalan ke pengontrol tingkat atas akan memicu rantai rekonsiliasi dan banyak panggilan api sehingga eskalasi kesalahan yang tidak perlu dapat membuat kubernetes kurang terukur.
   Contoh yang lebih spesifik: jika container utama job masih berjalan dan sidecar gagal, memulai ulang sidecar hanya akan memiliki 1 operasi status pod PATCH dan paling banyak 1 panggilan api terkait peristiwa. Tetapi jika pod gagal sepenuhnya akan menghasilkan rekonsiliasi Job, dan lebih banyak menyewa pengontrol level seperti CronJob dan CRD lainnya dan mungkin ada lebih banyak panggilan API.

ingin juga melihat apakah orang lain telah melihat masalah serupa (/cc @kow3ns )

Akankah perubahan ini menggabungkan perilaku yang diinginkan di https://github.com/kubernetes/community/pull/2342 , sehingga akan ada cara untuk mengonfigurasi seluruh pod (atau hanya wadah non-sidecar) untuk memulai kembali jika sespan gagal?

@JacobHenner saat ini tidak ada rencana untuk menerapkan mekanisme semacam itu di KEP ini, kami memang mendiskusikan untuk memasukkannya, tetapi tidak terlalu bergantung pada KEP ini dan dapat dikembangkan secara independen dari ini. Jadi sepertinya lebih cocok punya KEP sendiri.

@Joseph-Irving hanya untuk membagikan impl kami yang membahas perangkap yang disebutkan di atas untuk referensi Anda (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar) karena kami tujuan kami adalah menunggu dukungan resmi, kami mencoba untuk menjaga perubahan selokal mungkin dalam komit ini.

jadi untuk kebijakan restart pekerjaan == Tidak pernah, dengan 1 wadah utama, 1 sespan buruk yang terus-menerus mogok, 1 sespan baik yang terus berjalan, status pod akan terlihat seperti ini setelah wadah utama berhenti dengan impl di atas.

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

Saya secara umum setuju bahwa KEP sespan perlu mempertimbangkan fase pod dan memulai kembali kebijakan sebelum dapat masuk ke status yang dapat diterapkan. Saya tidak peduli apakah ini KEP atau bukan, tapi saya setuju secara umum dengan argumen @zhan849 dan itu perlu ditangani di sini.

terima kasih @smarterclayton !
@Joseph-Irving beri tahu kami jika ada hal lain yang Anda ingin kami bagikan dengan sespan dalam praktik.

@smarterclayton @zhan849 , saya tidak terlalu setuju dengan poin yang Anda buat, hanya mencoba memberikan beberapa poin balasan. Itu adalah pilihan sadar untuk tidak mengubah Fase Pod/Kebijakan Restart karena itu akan semakin meningkatkan cakupan proposal ini dan tidak ada yang merasa sangat yakin tentang hal itu.

Saya akan mengambil umpan balik ini kembali ke sig-apps/sig-node dan melihat apa yang mereka pikirkan. sig-node khususnya sangat ingin menjaga sespan sedekat mungkin dengan wadah normal, jika @derekwaynecarr atau @dchen1107 ingin berpadu, itu akan dihargai.

Rencana pengujian https://github.com/kubernetes/enhancements/pull/951 dan desain API https://github.com/kubernetes/enhancements/pull/919 PR kini telah digabungkan.

Saya telah membuka https://github.com/kubernetes/enhancements/pull/1109 untuk mendapatkan KEP yang ditandai sebagai dapat diterapkan, setelah semua orang senang dengan itu, kita harus dapat memulai pengembangan untuk ini sebagai alfa di 1.16

Kep ini telah ditandai dapat diterapkan jadi saya akan meningkatkan PR untuk membuatnya menjadi 1,16 mulai minggu depan!

Saya telah mengangkat https://github.com/kubernetes/kubernetes/pull/79649 untuk mengimplementasikan API, saya akan memiliki PR terpisah untuk perubahan Kubelet.

Hai @Joseph-Irving, saya Pemimpin Peningkatan 1,16. Apakah fitur ini akan lulus tahap alfa/beta/stabil di 1.16? Tolong beri tahu saya agar dapat ditambahkan ke 1,16 Pelacakan Spreadsheet . Jika tidak lulus, saya akan menghapusnya dari tonggak sejarah dan mengubah label yang dilacak.

Setelah pengkodean dimulai atau jika sudah, harap cantumkan semua PR k/k yang relevan dalam edisi ini sehingga dapat dilacak dengan benar.

Tanggal pencapaian adalah Enhancement Freeze 30/7 dan Code Freeze 29/8.

Terima kasih.

@Joseph-Irving Jika Anda ingin/membutuhkan beberapa orang tambahan untuk menerapkan ini, saya memiliki banyak minat dalam arahan ini, jadi saya senang untuk membantu.

Hai @kacole2 ini menargetkan Alpha untuk 1,16, KEP telah ditandai dapat diterapkan.
Satu-satunya PR untuk ini saat ini adalah kubernetes/kubernetes#79649 untuk API

@mhuxtable Saya akan menaikkan PR untuk perubahan kubelet segera, baru saja menyelesaikan beberapa hal, saya akan sangat menghargai bantuan untuk melihatnya. Saya akan menautkannya di sini jika sudah dimunculkan.

Saya telah membuka https://github.com/kubernetes/kubernetes/pull/80744 yang mengimplementasikan perubahan kubelet.

Harap dicatat bahwa kubernetes/kubernetes#79649 (api) masih terbuka sehingga PR ini berisi komit darinya, membuatnya tampak besar. Saya telah memecahnya menjadi komit yang masing-masing mengimplementasikan sedikit fungsionalitas yang berbeda sehingga seharusnya mudah untuk meninjaunya seperti itu.

Saya belum selesai melakukan semua kasus uji untuk ini, tetapi draf pertama implementasi kerja sudah selesai jadi saya ingin orang-orang melihatnya.

cc @kacole2

@Joseph-Irving

Saya salah satu dari bayangan dokumen v1.16.
Apakah peningkatan ini (atau pekerjaan yang direncanakan untuk v1.16) memerlukan dokumen baru (atau modifikasi pada dokumen yang ada)? Jika tidak, bisakah Anda memperbarui 1.16 Enhancement Tracker Sheet (atau beri tahu saya dan saya akan melakukannya)

Jika demikian, hanya pengingat ramah kami sedang mencari PR terhadap k/website (cabang dev-1.16) yang jatuh tempo pada hari Jumat, 23 Agustus, itu hanya bisa menjadi PR placeholder saat ini. Beri tahu saya jika Anda memiliki pertanyaan!

Hai @daminisatya , ya ini perlu pembaruan untuk Documents, saya telah mengangkat https://github.com/kubernetes/website/pull/15693 sebagai PR pengganti.
Saya tertarik untuk mengetahui apakah ada yang memiliki pendapat tentang ke mana harus pergi Dokumen, saya telah memasukkan sesuatu ke dalam content/en/docs/concepts/workloads/pods/pod-lifecycle.md untuk saat ini.

Dengan waktu kurang dari satu minggu sebelum Code Freeze, tampaknya sangat tidak mungkin bahwa ini akan berhasil menjadi 1,16.
Kami masih memiliki dua PR terbuka yang relatif besar kubernetes/kubernetes#80744 dan kubernetes/kubernetes#79649 yang telah berjuang untuk mendapatkan ulasan.
Semoga akan ada lebih banyak bandwidth resensi siklus rilis berikutnya untuk melihat ini.

/menetapkan

Bisakah ini memungkinkan untuk menulis sespan yang dapat memulai layanan aktual sesuai permintaan (dan menghancurkannya)?

Seperti skala ke nol, tetapi satu-satunya hal yang berjalan saat idle adalah sespan. Ketika permintaan datang, itu memutar layanan yang sebenarnya dan setelah respons terakhir, misalnya 30 detik, itu akan menutupnya. Ini memungkinkan cara sederhana untuk melakukan penskalaan hingga mendekati nol (dengan hanya sespan yang dibiarkan berjalan).

@Ciantic Dengan Operator Framework Anda dapat melakukan itu dan banyak lagi. Lihatlah

@janosroden Saya melihat, tetapi tampaknya cukup sulit untuk memahami bagaimana saya meningkatkan layanan yang berjalan ke skala nol.

Masalahnya bukan tidak ada pilihan yang tersedia misalnya Osiris , Keda atau knative . Saya mencoba yang terakhir, tetapi memiliki memori 8Gb, sulit untuk mengatakan itu 'tanpa server' pada saat itu.

Masalahnya adalah sebagian besar implementasi tersebut membutuhkan sumber daya baru, dll. Jauh lebih mudah untuk memikirkan hal ini sehingga seseorang dapat menyuntikkan sespan yang dapat mengontrol seluruh siklus hidup (termasuk memulai dan memulai ulang sesuai permintaan) sehingga dapat mengontrol layanan lebih dari sekadar duduk di sana.

Mengapa ini bermanfaat? Ini sangat berguna dalam situasi pemanfaatan rendah dan memori rendah, misalnya k3s dengan Raspberry Pi, atau tetesan Digital Ocean untuk proyek hobi. Banyak dari kita memiliki banyak layanan web yang tidak perlu dijalankan sepanjang waktu, hanya memiliki sespan yang dapat membangunkannya sesuai permintaan sudah cukup.

Tidak yakin ini benar-benar berfungsi untuk kasus penggunaan Anda. Saya benar-benar melihat keinginan untuk melakukan apa yang ingin Anda lakukan pada sistem dengan sumber daya terbatas seperti itu. Tetapi agar benar-benar stabil, Anda perlu menggunakan permintaan sumber daya untuk membantu menjadwalkan beban kerja. Ini perlu ditentukan di muka sehingga terlepas dari apakah beban kerja sedang berjalan atau tidak, itu harus memesan sumber daya.

Untuk menyiasatinya, Anda cukup membutuhkan pod sendiri untuk melakukan penerimaan koneksi awal dan membuat permintaan pod baru ke k8s, tunggu hingga pod berputar, lalu kirim lalu lintas ke sana. Peningkatan wadah sespan tidak diperlukan dalam kasus ini saya pikir. Anda membutuhkan sesuatu yang lebih seperti xinetd untuk k8 saya pikir.

Hai @Joseph-Irving -- 1.17 Peningkatan memimpin di sini. Saya ingin check-in dan melihat apakah menurut Anda Peningkatan ini akan lulus ke alfa di 1.17?

Jadwal rilis saat ini adalah:

• Senin, 23 September - Siklus Rilis Dimulai
• Selasa, 15 Oktober, EOD PST - Enhancements Freeze
• Kamis, 14 November, EOD PST - Pembekuan Kode
• Selasa, 19 November - Dokumen harus dilengkapi dan ditinjau
• Senin, 9 Desember - Kubernetes 1.17.0 Dirilis

Jika ya, setelah pengkodean dimulai, harap cantumkan semua PR k/k yang relevan dalam edisi ini sehingga dapat dilacak dengan benar. 👍

Terima kasih!

Hai @mrbobbytables , dengan asumsi kami dapat meninjau semuanya tepat waktu, rencananya adalah lulus ke alfa dalam 1,17.

PR terbuka saat ini adalah:
https://github.com/kubernetes/kubernetes/pull/79649 - Perubahan API
https://github.com/kubernetes/kubernetes/pull/80744 - Perubahan Kubelet

Beri tahu saya jika Anda membutuhkan yang lain!

Besar! Terima kasih @Joseph-Irving Saya akan menambahkan info ke lembar pelacakan 👍

@Joseph-Irving

Saya salah satu dari bayangan dokumen v1.17.
Apakah peningkatan ini (atau pekerjaan yang direncanakan untuk v1.17) memerlukan dokumen baru (atau modifikasi pada dokumen yang ada)? Jika tidak, bisakah Anda memperbarui 1.17 Enhancement Tracker Sheet (atau beri tahu saya dan saya akan melakukannya)

Jika demikian, hanya pengingat ramah kami sedang mencari PR terhadap k/website (cabang dev-1.17) yang jatuh tempo pada hari Jumat, 8 November, itu hanya bisa menjadi PR placeholder saat ini. Beri tahu saya jika Anda memiliki pertanyaan!

Terima kasih!

Hai @VineethReddy02 ya ini akan memerlukan dokumentasi, PR placeholder ada di sini https://github.com/kubernetes/website/pull/17190

Saya telah mengajukan PR untuk memperbarui KEP https://github.com/kubernetes/enhancements/pull/1344 ini berdasarkan beberapa diskusi yang kami lakukan dalam implementasi PR https://github.com/kubernetes/kubernetes/pull /80744.

Saya akan menghargai komentar apa pun

Hai @Joseph-Irving 1.17 Enhancement Shadow di sini! Saya menghubungi Anda untuk melihat bagaimana peningkatan ini berjalan.

Tim Enhancement sedang melacak kubernetes/kubernetes#79649 dan kubernetes/kubernetes#80744 di lembar pelacakan. Apakah ada PR k/k lain yang perlu dilacak juga?

Juga, pengingat ramah lainnya bahwa kita akan segera mendekati pembekuan kode (14 November).

Hai @annajung , ya hanya itu PR yang perlu dilacak.

Hai @Joseph-Irving, Besok adalah pembekuan kode untuk siklus rilis 1,17 . Sepertinya PR k/k belum digabungkan. Kami menandai peningkatan ini sebagai At Risk di lembar pelacakan 1,17.

Apakah menurut Anda semua PR yang diperlukan akan digabung dengan EoD tanggal 14 (Kamis)? Setelah itu, hanya masalah pemblokiran rilis dan PR yang akan diizinkan dalam pencapaian dengan pengecualian.

Hai @annajung , sayangnya tampaknya sangat tidak mungkin bahwa mereka akan digabungkan sebelum pembekuan kode. Kami telah membuat banyak kemajuan dalam siklus rilis ini, jadi semoga kami dapat menggabungkannya lebih awal menjadi 1.18.

Hai @Joseph-Irving Terima kasih atas pembaruannya. Saya akan memperbarui pencapaian tersebut dan menandai peningkatan ini sebagai ditangguhkan ke 1,18. Terima kasih!

/ tonggak sejarah v1.18

Hai @Joseph-Irving. 1.18 Peningkatan Pimpin di sini .

Rilis 1.18 dimulai kemarin, jadi saya menghubungi untuk melihat apakah Anda berencana untuk mendaratkan ini di rilis 1.18? Saya pikir ini melewatkan 1,17 karena pembekuan kode. Bagaimana hal-hal mencari 1,18? Saya melihat PR masih terbuka.

Terima kasih!

Hai @jeremyrickard ,

Ya rencananya adalah untuk mendapatkan ini di rilis 1.18.

API PR (https://github.com/kubernetes/kubernetes/pull/79649) mendapat ulasan dari thockin, tempo hari, dia memiliki beberapa poin tetapi setelah itu ditangani kami akan menutup PR itu dan memasukkan komit ke (https://github.com/kubernetes/kubernetes/pull/80744) sehingga kami dapat menggabungkan API dan implementasi bersama-sama.

Sedangkan untuk Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744) hanya perlu ditinjau, saya harap kita bisa mendapatkan bandwidth sig-node untuk meninjaunya siklus ini.

Terima kasih atas pembaruannya @Joseph-Irving

Menambahkannya ke dalam lembar pelacakan!

Maaf karena terlambat ke pesta. Ini adalah peningkatan yang signifikan untuk kasus umum. Tapi sepertinya tidak mencakup kasus yang lebih maju.

Pertimbangkan kasus sespan yang mengekspor kayu gelondongan yang juga bergantung pada sespan Istio. Jika sespan Istio dimatikan terlebih dahulu, beberapa log sensitif mungkin tidak dapat diekspor.

Pendekatan yang lebih umum adalah dengan mendefinisikan dependensi eksplisit di seluruh wadah. Terlepas apakah mereka sidecars atau bukan.

Apa pendapat Anda tentang definisi api seperti itu:

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@rubenhak yang menjadi sangat cepat berantakan. Apa yang perlu dipenuhi agar ketergantungan menjadi jelas untuk dilanjutkan? Seringkali ada celah antara memulai dan siap yang menurut saya dependOn akan sangat peduli dengan api yang tidak ditangani.

@kfox1111 Bagaimana desain yang diusulkan menentukan bahwa sespan dimulai dan siap untuk meluncurkan wadah utama? Satu-satunya perbedaan yang saya usulkan adalah bahwa alih-alih menandai wadah sebagai "sespan" adalah menggunakan cara yang lebih umum untuk mendefinisikan ketergantungan.

Saya tidak berpikir dependOn harus menentukan kriteria. Itu bisa ditentukan dalam wadah dependen. Bukankah readyProbe dan/atau livenessProbe sudah cukup? Jika tidak, mungkin ada startupProbe - keberhasilan yang menunjukkan bahwa container dependen dapat dimulai.

Halo @Joseph-Irving Saya salah satu dari bayangan dokumen v1.18.
Apakah peningkatan ini untuk (atau pekerjaan yang direncanakan untuk v1.18) memerlukan dokumen baru (atau modifikasi pada dokumen yang ada)? Jika tidak, bisakah Anda memperbarui 1.18 Enhancement Tracker Sheet (atau beri tahu saya dan saya akan melakukannya)

Jika demikian, hanya pengingat ramah kami sedang mencari PR terhadap k/website (cabang dev-1.18) yang jatuh tempo pada hari Jumat, 28 Februari, itu hanya bisa menjadi PR placeholder saat ini. Beri tahu saya jika Anda memiliki pertanyaan!

Hai @irvifa Saya telah mengangkat PR placeholder di sini https://github.com/kubernetes/website/pull/19046

Hai @Joseph-Irving Terima kasih atas tanggapan cepat Anda!

@rubenhak - Saya setuju dengan @kfox1111 bahwa memiliki grafik dependensi yang lengkap bisa menjadi sangat berantakan dengan cepat. Bagaimana dengan memulai wadah dalam urutan dalam spesifikasi pod, dan kemudian merobohkannya dalam urutan terbalik (seperti tumpukan)? Ini akan jauh lebih sederhana untuk diterapkan, dan mencakup sebagian besar kasus penggunaan pemesanan umum yang dapat saya pikirkan.

@rgulewich , bisakah Anda menjelaskan lebih lanjut, apa sebenarnya yang bisa menjadi berantakan? Menurunkan urutan dari grafik adalah tugas sepele, terutama mengingat fakta bahwa tidak ada operator waras akan menjalankan lebih dari 15 sespan (sudah peregangan).

Ide pemesanan boleh saja, tetapi karena sebagian besar sespan disuntikkan menggunakan pengontrol masuk, akan sangat sulit untuk menjamin kebenaran pesanan. Ada kebutuhan untuk tipuan.

@rubenhak mungkin ada siklus dalam urutan ketergantungan wadah, bagaimana k8s/kubelet memutuskan untuk memutus siklus dan memutuskan urutan apa untuk memulai/menghentikan wadah? Berpikir keras mungkin ini bisa menjadi validasi sisi API.

Hai @Joseph-Irving,

Sekadar pengingat ramah bahwa pembekuan kode untuk 1,18 adalah 05 Maret 2020 .

Saat kami melacak pembekuan kode, harap cantumkan/tautkan ke PR apa pun yang sedang Anda kerjakan untuk menyelesaikan peningkatan ini!

Hai @jeremyrickard ,

Apakah pr untuk dilacak https://github.com/kubernetes/kubernetes/pull/80744
PR ini berisi perubahan API tetapi komit akan digabungkan ke dalam PR di atas setelah peninjauan selesai https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak mungkin ada siklus dalam urutan ketergantungan wadah, bagaimana k8s/kubelet memutuskan untuk memutus siklus dan memutuskan urutan apa untuk memulai/menghentikan wadah? Berpikir keras mungkin ini bisa menjadi validasi sisi API.

@bjhaid , sisi API dapat melakukan validasi. Deteksi loop adalah algoritma sepele dengan kompleksitas waktu linier (seperti traversal DFS).

Mungkin juga ada kebutuhan untuk menjalankan kembali validasi setelah injeksi sespan juga.

Saya telah memikirkan hal ini untuk sementara waktu... Sebagian besar masalah dengan dependensi benar-benar bermuara pada layanan mesh. (mungkin seseorang dapat memikirkan contoh lain)

Proxy mesh layanan adalah sespan yang perlu dimulai dan siap sebelum hal lain, dan perlu keluar setelah hal lain. Mereka berjalan lama sehingga lebih merupakan sespan daripada wadah init.

Tapi initContainers idealnya semua bisa menggunakan service mesh juga.

Tapi initContainers mungkin perlu init container sespan lainnya.

Meskipun kita dapat merancang semacam sistem ketergantungan yang rumit yang melibatkan wadah init, wadah sespan, dan wadah biasa, mungkin kita hanya perlu memiliki dua kelas sespan? sespan biasa, dan sespan jaringan?

sidecars jaringan semua harus siap sejak awal. proxy mesh layanan buka di sini.
wadah init dijalankan berikutnya secara berurutan.
sidecars semua mulai dan menjadi siap. Ini dapat mencakup hal-hal seperti proxy auth, logger, dll.
wadah biasa mulai dan menjadi siap.

meruntuhkan adalah sebaliknya.

Apakah ini akan menghilangkan masalah ketergantungan sambil tetap menyelesaikan semua masalah yang tampaknya dimiliki oleh mesh layanan dengan pemesanan kontainer? Saya berpikir begitu?

@kfox1111 , Vault sekarang melakukan injeksi rahasia menggunakan sespan. Harus masuk ke kelas mana? Juga, tergantung pada kasusnya, vault dapat bergantung pada mesh layanan, atau sebaliknya.

Yang saya katakan adalah bahwa desain seperti itu pada akhirnya akan meledak menjadi 10 kelas sespan. Pendekatan semacam itu menyiratkan pendapat yang lebih kuat tentang bagaimana segala sesuatunya harus berjalan. Orang-orang akan mulai meretas dengan kelas, hanya untuk mencapai pesanan perlu meluncurkan aplikasi.

Jika satu-satunya tujuan dari kelas-kelas itu adalah untuk menentukan urutannya, mengapa tidak melakukannya secara eksplisit?

Menjawab pertanyaan Anda, sementara desain seperti itu akan mencakup beberapa kasus penggunaan, itu tidak membantu kasus lain seperti sidecars vault, logging sidecars, dll. Ini sudah merupakan proposal untuk mendesain ulang fitur asli. Karena ini adalah upaya kedua, ada baiknya untuk memperbaikinya kali ini.

Saya tidak tahu betapa rumitnya ketergantungan. Bisakah Anda menguraikan lebih lanjut tentang ini? Dependensi membuat definisi YAML lebih jelas, tidak ada logika tersembunyi. Pendekatan dengan kelas yang di-hardcode akan membutuhkan logika tersembunyi dan lebih banyak dokumentasi yang menjelaskan mengapa sidecar jaringan harus dijalankan setelah sidecar lain, dll.

Bagaimana jika kita memasukkan sebuah field ke dalam Container ?

    // +optional
    Priority int

Kolom ini efektif untuk kontainer dengan tipe yang sama (sespan, normal).
Untuk peti kemas sespan, peti kemas sespan dengan prioritas lebih tinggi akan dipakai terlebih dahulu / dibongkar terakhir.

@tedyu , ketergantungan memiliki lebih banyak metadata dan nilai dibandingkan dengan "prioritas". Dibutuhkan 30 baris kode c++ untuk menghasilkan urutan prioritas yang diberikan ketergantungan https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . Sebaliknya tidak mungkin.

Manfaat lain adalah bahwa grafik ketergantungan yang diberikan wadah tertentu dapat dimulai pada waktu yang sama.
Dalam contoh berikut: wadah "A -> B, B -> C, D -> C" B dan D dapat dimulai pada saat yang sama jika C diinisialisasi. Saya tidak mengatakan implementasi harus mendukung itu, tetapi setidaknya itu bisa sangat berharga jika API mengizinkan definisi seperti itu.

Prioritas bilangan bulat tidak akan berfungsi dengan baik – orang akan menggunakan semua jenis nomor yang berbeda dan tidak standar seperti yang mereka lakukan dengan properti indeks-z CSS (seperti -9999 ).

@rubenhak Apa yang Anda sarankan saat ini pada dasarnya adalah fitur yang sama sekali berbeda dengan yang dijelaskan dalam KEP ini, ini bukan tweak kecil, ini adalah penulisan ulang total. Semua orang yang sebelumnya telah menyetujui fitur ini (membutuhkan waktu satu tahun untuk disetujui oleh semua pihak) harus mengevaluasi kembali fitur ini.
Jika Anda tertarik dengan fitur seperti itu, saya sarankan Anda membuat KEP Anda sendiri dan membawanya ke berbagai SIG untuk mendapatkan umpan balik mereka.

Gagasan grafik ketergantungan dibahas panjang lebar ketika proposal ini dimulai pada tahun 2018, kesimpulannya bulat bahwa meskipun akan memungkinkan lebih banyak kasus penggunaan, mereka tidak memiliki kasus penggunaan yang cukup kuat dan bahwa kompleksitas tambahan tidak sepadan.

Saya pikir Anda agak meremehkan tingkat perubahan yang diperlukan untuk mengimplementasikan apa yang Anda gambarkan. Tetapi jika ini sesederhana yang Anda pikirkan, Anda dapat membuat Bukti Konsep Anda sendiri dari ini bekerja di Kubernetes dan menyajikannya kepada SIG untuk membantu memperkuat kasus Anda.

KEP ini belum menjadi fitur GA, jika KEP Anda disetujui dan diimplementasikan maka kami dapat menghapus yang ini. Mereka belum saling eksklusif.

Perubahan ini mungkin bukan solusi yang sempurna untuk setiap kasus penggunaan, tetapi secara dramatis meningkatkan pengalaman untuk sebagian besar dan saya pikir kita akan jauh lebih baik menggabungkan ini kemudian berdebat selama satu tahun lagi tentang implementasi.

jika KEP Anda disetujui dan diterapkan maka kami dapat menghapus yang ini. Mereka belum saling eksklusif.

Apakah mereka _pernah_ saling eksklusif?

Saya bertanya pada diri sendiri apakah fitur ini memiliki nilai _bahkan jika_ pemesanan startup/shutdown container yang lebih eksplisit (yang menurut saya akan bagus) diaktifkan melalui peningkatan lain di masa mendatang ... dan saya pikir ya.

Setiap urutan startup / shutdown, yang tersirat oleh klasifikasi container sebagai init, sidecar, atau "reguler" disisihkan, klasifikasi ini juga mengungkapkan _other_ berguna, dan bisa dibilang aspek yang tidak terkait dari perilaku yang diinginkan container, bukan?

Sebagai contoh, ini berguna dalam sebuah pod dengan restartPolicy != Always (sebuah pod yang mengimplementasikan suatu pekerjaan, mungkin), bahwa container yang ditunjuk sebagai sidecars tidak ada hubungannya dengan sebuah pod yang memasuki status selesai.

@kfox1111 , Vault sekarang melakukan injeksi rahasia menggunakan sespan. Harus masuk ke kelas mana? Juga, tergantung pada kasusnya, vault dapat bergantung pada mesh layanan, atau sebaliknya.

Kami bekerja melalui driver csi ephemeral sehingga hal-hal seperti vault tidak memerlukan sidecars/init container. Saya percaya ada driver lemari besi dalam pekerjaan.

Meskipun sespan biasa dengan emptyDir sepertinya cocok untuk sespan yang perlu menggunakan sespan jaringan?

@Joseph-Irving, saya sama sekali tidak mencoba untuk memblokir KEP ini masuk. Saya menyadari bahwa Anda memulainya hampir 2 tahun yang lalu dan ada cukup banyak orang yang menunggu ini untuk dirilis.

Apakah Anda memiliki tautan ke diskusi sebelumnya terkait dengan grafik ketergantungan?

Hai @Joseph-Irving,

Pengingat yang ramah bahwa kami akan segera menutup pembekuan kode pada 05 Maret 2020 . Sepertinya PR Anda belum bergabung, apakah Anda masih merasa berada di jalur untuk pembekuan kode untuk peningkatan ini?

Hai @jeremyrickard , Tinjauan API (https://github.com/kubernetes/kubernetes/pull/79649) pada dasarnya sudah selesai. Kami akan menutup PR itu dan pindah seluruhnya ke PR implementasi sehingga semua (API dan Implementasi) bisa digabung menjadi satu PR.

Implementasi PR (https://github.com/kubernetes/kubernetes/pull/80744) telah ditinjau secara menyeluruh, jadi saya mencoba untuk mendapatkan pemberi persetujuan sig-node untuk melihat persetujuan akhir.

Apakah ini terjadi tepat waktu untuk pembekuan kode agak sulit untuk saya katakan, itu sangat tergantung pada apakah saya berhasil mendapatkan perhatian dari beberapa pemberi persetujuan tepat waktu.

Akan senang melihat ini masuk dengan pembekuan kode. Itu akan membuat solusi Istio untuk https://github.com/istio/istio/issues/7136 lebih sederhana dan lebih baik.

Adakah gerakan ini masuk ke 1,18? Tampaknya perlu bagi istio sespan untuk bekerja seperti yang diharapkan dengan pekerjaan yang berjalan cepat.

Saya sudah mencoba menjangkau pemberi persetujuan sig-node dengan berbagai cara tetapi saya tidak mendapat tanggapan apa pun. Jadi saya tidak terlalu optimis bahwa ini akan menjadi 1,18.

@Joseph-Irving saluran slack #pr-reviews dibuat untuk kasus ini. Sudahkah Anda mencoba itu? Ini adalah cara untuk mendapatkan eskalasi ulasan pr. (Saya tidak melihatnya di sana)

Hai @Joseph-Irving ,

Kami hanya beberapa hari keluar dari pembekuan kode sekarang. Apakah Anda ingin menunda ini ke 1,19 berdasarkan bandwidth pengulas? Atau mencoba dan mendorong?

Hai @jeremyrickard ,

Tidak ada yang menanggapi saya tentang penggabungan PR ini di 1,18 jadi saya sangat ragu itu akan terjadi.

Kita bisa menunda ke 1,19 tapi saya mulai bertanya-tanya apakah ada gunanya melakukannya.
KEP ini telah terbang selama hampir dua tahun (target alpha asli adalah 1,15), PR yang bersangkutan telah terbuka selama hampir 1 tahun, tidak pernah ada "bandwidth reviewer" untuk mereka.
Saya telah mengirim email dengan sopan, mengendur, pergi ke pertemuan, dan bahkan menemukan orang secara langsung untuk mendapatkan ulasan namun kami hanya membuat sedikit kemajuan.
Setiap ulasan yang berhasil saya dapatkan hanya menyarankan perubahan kecil, itu tidak seperti penulisan ulang besar yang diminta, PR semua pada dasarnya sama seperti setahun yang lalu hanya sedikit lebih dipoles.
Saya tidak tahu apakah saya dimaksudkan untuk secara agresif mem-ping orang setiap hari sampai mereka merespons saya, tetapi itu benar-benar bukan sesuatu yang nyaman saya lakukan.

Saya pikir masalahnya lebih karena tidak ada yang benar-benar peduli dengan fitur ini, saya satu-satunya yang mendorong fitur ini maju, tidak ada seorang pun di SIG yang tampaknya tertarik untuk melihat ini. Jika perlu dua tahun untuk masuk ke alfa, berapa lama waktu yang dibutuhkan untuk sampai ke beta/GA? (seperti ketika kebanyakan orang benar-benar dapat menggunakan ini)

Dengan frustrasi tampaknya ada minat dari masyarakat luas dan pengguna akhir untuk mendapatkan fitur ini, alasan saya melakukan ini adalah karena saya melihatnya sebagai masalah, menanyakan SIG apakah mereka akan memperbaikinya, dan mereka mengatakan "kami tidak memiliki kapasitas tetapi kami akan senang jika Anda melakukannya".
Jadi saya melakukan semua yang mereka minta, saya menulis KEP, saya mendapatkannya disetujui oleh semua pihak, saya menulis semua kode, semua tes, terus memperbaruinya saat setiap rilis berlalu, namun di sinilah kita.

Setiap kali kita menunda ini, aku merasa seperti mengecewakan banyak orang, apakah ini semua salahku? apakah kodenya sangat buruk sehingga tidak ada yang akan berkomentar? apakah saya hanya tidak cukup agresif dalam mencoba untuk mendapatkan perhatian?
Saya hanya merasa bahwa saya tidak dapat menyelesaikan ini sendiri, dan saya mulai lelah mengalahkan kuda mati ini.

Saya minta maaf untuk kata-kata kasar yang panjang (tidak ditujukan pada Anda secara pribadi Jeremy atau siapa pun secara pribadi dalam hal ini), tetapi ini perlahan-lahan menggerogoti jiwa saya untuk waktu yang lama sekarang.

Dengan frustrasi tampaknya ada minat dari masyarakat luas dan pengguna akhir untuk mendapatkan fitur ini, alasan saya melakukan ini adalah karena saya melihatnya sebagai masalah, menanyakan SIG apakah mereka akan memperbaikinya, dan mereka mengatakan "kami tidak memiliki kapasitas tetapi kami akan senang jika Anda melakukannya".

@Joseph-Irving Tentang ini. Sebagai pengguna aktif, menonton utas ini karena saya tertarik (dan begitu juga dua rekan saya). Aktivitas pada masalah, permintaan tarik, saluran kendur, atau tanda mungkin bukan indikator minat terbaik dalam fitur ini.

@dims Mungkin Anda bisa menjelaskan?

@thockin Saya mendengarkan Anda diwawancarai di Podcast Kubernetes ~setahun yang lalu dan Anda berbicara tentang berkontribusi pada Kubernetes. Mungkin Anda atau orang lain di episode podcast lain yang merasa sangat sedih karena KEP sespan ini tidak berhasil mencapai 1,16. Nah, di sini kita lagi.

Masalah ini tampaknya menjadi contoh utama betapa sulitnya untuk berkontribusi jika Anda bukan karyawan misalnya. Google, RedHat atau pemain besar lainnya.

Saya juga meminta bantuan di Slack untuk meninjaunya tetapi baru saja diberi tahu bahwa ada penangguhan eksplisit oleh @thockin jadi saya juga tidak yakin jalan ke depan.

Saya menghabiskan banyak waktu pada fitur driver csi singkat. Menyelesaikannya juga membuat frustrasi dan ada saat-saat di mana saya tidak yakin itu akan berhasil setelah begitu banyak penundaan dan desain ulang. Jadi, aku merasakan sakitmu. Akan sangat bagus jika kita bisa menemukan cara untuk membuatnya tidak terlalu menyakitkan. Meskipun demikian, kami juga akhirnya mendapatkannya setelah melewatkan beberapa rilis utama. Jadi tolong jangan menyerah/putus asa! Kapal mungkin sulit untuk berbelok, tetapi pada akhirnya akan terjadi.

Siapa pun yang menjalankan segala jenis topologi yang bergantung pada sidecar jaringan kemungkinan besar akan mengalami masalah pemesanan startup/shutdown container yang berpotensi dipecahkan oleh KEP ini. Ctrl-F untuk "Istio" pada tiket ini, dan Anda akan melihat banyak gangguan terkait dengan pemesanan kontainer.

Apakah ada pengelola Istio di sini? Banyak karyawan Google, dan mungkin memiliki pengaruh lebih besar dengan orang-orang K8 secara internal.

Sebagai toko Istio / K8s, kami benar-benar mendukung Anda untuk mendapatkan ini, @Joseph-Irving! ❤️

pujian untuk @Joseph-Irving untuk membuat sespan sejauh ini.

Bahkan untuk manajemen siklus hidup sidecar, pekerjaan batch apa pun akan memerlukan fitur ini atau Kubernetes tidak berfungsi untuk mereka, dan itulah sebabnya kami menghabiskan banyak waktu juga membantu tinjauan kode dan memberikan umpan balik!

Kami telah forking k8s untuk sementara waktu karena ini dan kami sangat menantikan untuk melihat fitur penting tersebut didukung secara resmi.

Sebagai toko Istio + Kubernetes, kami juga telah menunggu dengan cemas fitur ini. Dan semakin frustrasi bahwa itu tergelincir dari rilis ke rilis. Kami tidak senang harus menggunakan peretasan untuk membunuh sidecars pada beban kerja pekerjaan. Untuk kebutuhan kami, ini adalah satu-satunya fitur terpenting yang kami butuhkan di Kubernetes, selama lebih dari setahun.

@thockin Telah dilaporkan di atas bahwa Anda secara eksplisit menahan ini. Bisa tolong jelaskan kenapa.

Ada banyak pengguna Linkerd yang sangat menantikan ini juga. Bertahanlah @Joseph-Irving, kami mendukungmu.

Tidak yakin apakah semua orang di sini melihat tetapi setelah melakukan penggalian dan menonton video kubecon, saya menemukan bahwa Lyft telah melakukan sesuatu yang mirip dengan ini. Inilah komit yang disebutkan dari garpu kubernetes mereka: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Sebagai toko Istio + Kubernetes, kami juga telah menunggu dengan cemas fitur ini. Dan semakin frustrasi bahwa itu tergelincir dari rilis ke rilis.

Saya adalah pengguna istio potensial tetapi harus sedikit absen karena menunggu fitur seperti ini. Selama diskusi di atas, saya terus melihat hal-hal yang membuat saya berpikir bahwa fitur sespan saja seperti yang dibahas di sini tidak akan memperbaiki semua masalah yang dimiliki istio sespan dengan alur kerja. Ini mungkin membantu. Yang menurut saya merupakan bagian dari alasan mengapa ini terhenti.

Bagaimana cara menjalankan istio di sespan saat menggunakan driver istio cni bekerja? Saya percaya wadah init yang mencoba menjangkau jaringan masih akan gagal berfungsi dengan baik seperti yang didokumentasikan dalam dokumentasi istio.

maka pertanyaan saya di atas apakah sidecars jaringan adalah miliknya sendiri.

Masalah ini tampaknya menjadi contoh utama betapa sulitnya untuk berkontribusi jika Anda bukan karyawan misalnya. Google, RedHat atau pemain besar lainnya.

Hah! Apa yang tidak Anda ketahui adalah bahwa orang-orang itu terkadang juga terjebak!

Serius, saya minta maaf. Saya punya alasan, tapi itu menyebalkan jadi saya tidak akan repot.

Untuk klarifikasi:
Saya tidak menyiratkan bahwa kita tidak boleh menggabungkan ini sebagai alfa untuk mendapatkan umpan balik tentang pendekatan tersebut. Secara umum saya pikir itu suara. Saya pikir ada beberapa lubang dalam kasus penggunaan seperti jerat layanan yang tidak cukup tertutup. Tapi itu bukan alasan untuk memblokirnya secepatnya sehingga kami dapat menemukan semua kasus penggunaan lain yang tidak tercakup sehingga kami dapat membuat versi beta dari fitur tersebut berfungsi dengan baik untuk semua orang. Itulah tepatnya alpha untuk IMO.

Saya hanya menyebutkan apa yang saya lakukan, khususnya kepada orang-orang yang berharap ini akan menjadi peluru perak untuk masalah mesh layanan yang ada. Saya tidak berpikir alpha seperti yang diusulkan akan sepenuhnya memperbaiki masalah khusus itu. Jadi jangan terlalu berharap terlalu tinggi dulu. Tapi tolong, jangan blokir fitur ini hanya karena belum mendukung semua orang.

Saya telah meminta pengecualian, mari kita lihat apakah kita dapat mencoba memasukkan ini:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

Mungkin Anda atau orang lain di episode [Kubernetes Podcast] lain yang merasa sangat sedih karena KEP sespan ini tidak mencapai 1,16

Silakan lihat episode 72, dengan Lachie Evenson , dan 83, dengan Guinevere Saenger . Saya bahkan menyerukan minggu ini bahwa tinjauan PR diperlukan untuk menyelesaikan masalah yang satu ini. Kita bisa melakukannya!

Apakah ada pengelola Istio di sini? Banyak karyawan Google, dan mungkin memiliki pengaruh lebih besar dengan orang-orang K8 secara internal.

@duderino dan @howwardjohn sudah mengomentari utas ini.

Agar jelas, kita perlu digabungkan:
kubernetes/kubernetes#79649
kubernetes/kubernetes#80744

Apakah ada PR lain yang harus kami lacak?

Terima kasih!

• Tim Peningkatan

Terima kasih banyak kepada semua orang yang memposting pesan dukungan (secara publik atau pribadi) yang sangat kami hargai ❤️

Ada upaya yang berani dari anggota komunitas untuk mencoba dan memasukkan ini ke 1,18, termasuk tim rilis yang menerima permintaan perpanjangan, tetapi sayangnya, keputusan telah dibuat untuk menunda ini ke 1,19. Anda dapat melihat percakapan yang relevan mulai dari komentar ini: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

Meskipun tidak masuk ke 1,18, ini mendapat lebih banyak perhatian dalam beberapa hari terakhir daripada yang cukup lama, jadi saya berharap momentum ini akan berlanjut ke 1,19.

cc @jeremyrickard , @kikisdeliveryservice

Hal-hal hebat @Joseph-Irving, sepertinya beberapa frustrasi Anda bermanfaat dan didengarkan. Terima kasih telah bertahan.

/tonggak sejarah v1.19

Halo semua. Sekelompok dari kami telah mendiskusikan topik ini selama seminggu terakhir.

Pertama, kami mohon maaf atas apa yang terjadi di sini. Kami tidak senang tentang itu.

Humas ini dan KEP terkait telah menjelaskan beberapa hal yang dapat dilakukan proyek dengan lebih baik. Kami ingin memisahkan masalah sosial, prosedural, dan teknis.

Secara sosial, fitur ini menjadi korban keinginan kami untuk menyenangkan satu sama lain. Derek menyetujui KEP, meskipun keberatan dinyatakan dalam SIG, karena Clayton dan Tim mendorongnya. Kami semua percaya satu sama lain, tetapi tampaknya kami tidak selalu merasa bisa mengatakan "tidak". Kami tahu ini karena kami semua telah melakukan hal yang sama persis. Tak satu pun dari kita ingin menjadi penghalang untuk ide bagus berikutnya.

Saling percaya harus mencakup percaya bahwa kita dapat mengatakan "tidak" dan percaya bahwa ketika seseorang mengatakan "tidak", mereka melakukannya untuk alasan yang baik. Area teknis ini mencakup SIG, dan kita TIDAK boleh menekan sig-node, yang pada akhirnya akan menjadi orang yang menangani masalah, untuk menerima fitur baru yang belum nyaman mereka dukung. Ini bukan tentang Tim atau Derek atau Clayton pada khususnya, tetapi SEMUA pemberi persetujuan tingkat tinggi dan prospek SIG dan kontributor "senior".

Fitur ini juga menjadi korban ketidakpastian prosedural seputar KEP. Sebagai reviewer KEP, apakah saya wajib menjadi code reviewer? Untuk mendelegasikan ke peninjau kode? Atau hanya untuk membaca KEP? Saat rilis rentang KEP, bagaimana kami memastikan gembala tersedia untuk serangkaian perubahan yang dianggarkan dalam rentang rilis tertentu. Jika KEP mencakup SIG, bagaimana kita menganggarkan dan mengalokasikan waktu di seluruh SIG? Kita perlu mengklarifikasi ini. Kami akan mengerjakan beberapa proposal perubahan KEP (KEP KEP) untuk memperkuat definisi peran dalam proses KEP.

Secara teknis, fitur ini menjadi korban waktu dan perhatian. Peninjau tidak menyediakan cukup waktu untuk meninjaunya, atau itu bukan prioritas yang cukup tinggi bagi mereka. Diskusi bolak-balik membutuhkan waktu. Keadaan dan pemahaman kita tentang ruang masalah berubah seiring waktu.

Karena semakin banyak pengguna yang mengadopsi Kubernetes, kami melihat semakin banyak kasus tepi aneh atau serpihan yang dilaporkan ke sig-node. Karena siklus hidup Pod adalah inti dari Kubernetes, setiap perubahan yang dibuat pada subsistem tersebut HARUS dilakukan dengan hati-hati. Kemampuan kami untuk menggabungkan fitur baru harus diimbangi dengan keinginan kami untuk meningkatkan keandalan. Cara kami berpikir tentang siklus hidup Pod hari ini sedikit berbeda dari cara kami memikirkannya saat fitur ini dimulai. Ini tidak mengurangi kasus penggunaan yang mengarah ke hal ini dengan cara apa pun, tetapi ini menunjukkan bahwa KEP yang sudah berjalan lama perlu ditinjau ulang secara berkala dari waktu ke waktu.

Kami pikir kami perlu melakukan sedikit prinsip pertama tentang siklus hidup Pod. Apa yang sebenarnya kita inginkan? Kami mencoba untuk tidak turun ke terlalu banyak kerumitan, tetapi kami khawatir kami hanya memecah kompleksitas itu menjadi beberapa fase, dan hasil akhirnya mungkin LEBIH kompleks daripada hanya menanganinya secara langsung.

Apa artinya bagi Humas ini dan KEP terkait? Kami tidak 100% yakin. Ini mungkin berarti kita TIDAK harus mendorong ini terlebih dahulu.

Derek mengangkat beberapa kekhawatiran seputar urutan penutupan. KEP memanggil mereka keluar dari ruang lingkup untuk saat ini, tapi ada beberapa keraguan. Kami sudah tidak menghormati penghentian anggun pada node shutdown, dan itu telah mengejutkan banyak pengguna. Itu bukan salah KEP ini, tapi sebut saja “keadaan luar biasa”. Jika seseorang menggunakan sidecars untuk “membersihkan” pod mereka (misalnya untuk menguras log yang di-cache ke layanan logging), mereka akan mengharapkan (cukup) beberapa semantik yang jelas dan berguna seputar shutdown, yang tidak dijamin oleh KEP ini.

Tim memiliki kekhawatiran bahwa init-sidecars perlu menjadi sesuatu, dan itu tidak terasa benar. Dia mengabaikan kekhawatiran itu di masa lalu, tetapi itu masih mengganggunya.

Kami membutuhkan SIG Node untuk membantu menentukan tujuan jangka menengah dari siklus hidup pod, dan keinginan mereka untuk menggunakannya. Jika kita dapat menyetujui bahwa ini adalah langkah bertahap menuju tujuan, kita dapat membuka blokirnya, tetapi kecuali kita mengetahui tujuannya, kita mungkin terlalu memaksakan lampu depan kita.

Mari kita semua menjadi yang pertama mengatakan bahwa ini bau. Kami memiliki pernyataan masalah yang nyata, kontributor yang bersemangat, dan serangkaian pengelola yang bermaksud baik, dan kami berakhir ... di sini. Tim akan menyumbangkan waktunya untuk membantu brainstorming dan desain. Derek akan mendorong pekerjaan node-shutdown untuk siklus hidup pod saat ini untuk memastikan kami memiliki basis yang stabil untuk mengembangkannya lebih jauh. Kami harus menentukan dengan sangat hati-hati jaminan apa yang dapat dan tidak dapat kami buat dalam menghadapi kegagalan mesin yang tidak direncanakan.

Terima kasih,
Clayton, David, Fajar, Derek, John, Tim

Untuk mencoba memacu beberapa gerakan ke depan: Derek atau Dawn - adakah orang yang dapat meluangkan waktu untuk melakukan brainstorming tentang siklus hidup pod dan container yang lebih holistik?

@thockin akan menambahkan ini ke agenda sig-node.

@thockin @derekwaynecarr apa tl; dr mengapa ini tidak bisa masuk?

Deskripsi peningkatan satu baris: Kontainer sekarang dapat ditandai sebagai sidecars sehingga kontainer tersebut mulai sebelum kontainer normal dan dimatikan setelah semua kontainer lain dihentikan.

Kedengarannya seperti sesuatu yang akan membuat hidup lebih mudah di era baru service mesh sidecars ini.

Selain itu, adakah rekomendasi untuk memulai sespan sebelum wadah aplikasi utama dan dimatikan setelah penghentian wadah aplikasi utama hari ini?

... apa tl; dr mengapa ini tidak bisa masuk?

@naseemkullah Dari https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ...

Apa artinya bagi Humas ini dan KEP terkait? Kami tidak 100% yakin. Ini mungkin berarti kita TIDAK harus mendorong ini terlebih dahulu.

Derek mengangkat beberapa kekhawatiran seputar urutan penutupan. KEP memanggil mereka keluar dari ruang lingkup untuk saat ini, tapi ada beberapa keraguan. Kami sudah tidak menghormati penghentian anggun pada node shutdown, dan itu telah mengejutkan banyak pengguna. Itu bukan salah KEP ini, tapi sebut saja “keadaan luar biasa”. Jika seseorang menggunakan sidecars untuk “membersihkan” pod mereka (misalnya untuk menguras log yang di-cache ke layanan logging), mereka akan mengharapkan (cukup) beberapa semantik yang jelas dan berguna seputar shutdown, yang tidak dijamin oleh KEP ini.

[...]

Kami membutuhkan SIG Node untuk membantu menentukan tujuan jangka menengah dari siklus hidup pod, dan keinginan mereka untuk menggunakannya. Jika kita setuju bahwa ini _adalah_ langkah inkremental menuju tujuan, kita dapat membuka blokirnya, tetapi kecuali kita mengetahui tujuannya, kita mungkin mengemudikan lampu depan kita secara berlebihan.

Dengan hormat, saya ingin tahu apakah ada prospek yang berencana memprioritaskan penyelesaian ini. @Joseph-Irving melakukan banyak pekerjaan dalam hal ini dan sejumlah besar orang yang akan senang dengan solusinya sangat ingin mendengar beberapa solusi superior dari mereka yang memperbaiki ini.

Minimal, meskipun ada keraguan dengan beberapa aspek, saya pikir masih masuk akal untuk masuk sebagai Alpha untuk menemukan masalah apa yang akan muncul dalam praktik. Bisakah kita menggabungkan ini? Masalah dapat menghalanginya untuk menjalankan Beta jadi saya tidak berpikir itu penting untuk menjadi sempurna sebelum Alpha awal dibuat.

akan menambahkan ini ke agenda sig-node.

@thockin @derekwaynecarr apakah ada pembaruan tentang keadaan saat ini? Saya melihat melalui catatan pertemuan tanda-simpul dan tidak melihat apa-apa tentang ini.

Ada banyak pengembang di utas ini yang akan dengan senang hati menyumbangkan waktu untuk mengimplementasikan ini, karena ini sangat penting untuk banyak kasus penggunaan (KEP itu sendiri memiliki 2,5x lebih banyak :+1: seperti KEP lainnya). Apa yang bisa kita lakukan untuk mewujudkannya? Memiliki daftar prasyarat untuk stabilitas area ini, bahkan jika itu mungkin mencakup banyak rilis untuk diselesaikan, yang dapat kita mulai kerjakan secara aktif akan menjadi peningkatan besar dari tempat kita sekarang.

Hai @Joseph-Irving @thockin @khenidak @kow3ns -- 1.19 Enhancements Lead di sini, saya ingin memeriksa apakah menurut Anda peningkatan ini akan lulus di 1.19?

Untuk mendapatkan bagian rilis ini:

1. KEP PR harus digabung dalam keadaan yang dapat diimplementasikan
2. KEP harus memiliki rencana pengujian
3. KEP harus memiliki kriteria kelulusan.

Jadwal rilis saat ini adalah:

• Senin, 13 April: Minggu 1 - Siklus rilis dimulai
• Selasa, 19 Mei: Minggu 6 - Enhancements Freeze
• Kamis, 25 Juni: Minggu 11 - Pembekuan Kode
• Kamis, 9 Juli: Minggu 14 - Dokumen harus diselesaikan dan ditinjau
• Selasa, 4 Agustus: Minggu 17 - Kubernetes v1.19.0 dirilis

@palnabarun , Sesuai dengan komentar ini https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 , KEP ini telah ditangguhkan tanpa batas waktu, jadi tidak akan lulus dalam 1,19.

Terima kasih @Joseph-Irving untuk mengklarifikasi situasi. :+1:

Hargai usaha Anda!

Kepada semua orang yang ingin mendapatkan ini, dan sekali lagi kepada @Joseph-Irving - Saya pribadi sangat menyesal atas situasi ini. Saya ingin ini (atau sesuatu seperti itu), juga, tetapi faktanya adalah bahwa sig-node memiliki lebih banyak pekerjaan yang harus dilakukan daripada orang untuk melakukannya sekarang, dan mereka tidak siap untuk mempertimbangkan ini.

Menyebalkan sekali. Saya mengerti. Saya benar-benar melakukannya.

Cara terbaik yang dapat dilakukan orang-orang adalah dengan terjun ke sig-node dan membantu meningkatkan kapasitas dengan melakukan tinjauan kode dan masalah triase, dengan memperbaiki bug dan pengujian, dan dengan membangun ke tempat di mana para ahli sig-node memiliki lebih banyak kapasitas dan keyakinan dalam membuat perubahan seperti itu.

sig-node memiliki lebih banyak pekerjaan yang harus dilakukan daripada orang yang melakukannya sekarang

Dipahami. Kami telah mempromosikan, dengan penekanan, kebutuhan kapasitas sig-node secara internal. Kami membawa dan membimbing relawan sig-node OSS, beberapa berpengalaman beberapa baru, semua dengan keinginan untuk bekerja di ruang ini (empat sejauh ini). Saya akan mengutip komentar Anda @thockin , terima kasih!

/pencapaian jelas

Cara terbaik yang dapat dilakukan orang-orang adalah dengan terjun ke sig-node dan membantu meningkatkan kapasitas dengan melakukan tinjauan kode dan masalah triase, dengan memperbaiki bug dan pengujian, dan dengan membangun ke tempat di mana para ahli sig-node memiliki lebih banyak kapasitas dan keyakinan dalam membuat perubahan seperti itu.

@thockin Bisakah Anda memberikan tautan seperti repositori, milis, panduan, dll.? Itu akan membantu orang mendapatkan ide tentang bagaimana terlibat dengan sig-node secara efektif. Permintaan fitur khusus ini berusia lebih dari 2 tahun tanpa resolusi yang terlihat.

@tariq1890 orang-orang yang menulis KEP ini telah melakukan segalanya dengan benar. mereka tidak meninggalkan kebutuhan bisnis yang terlewat. Masalahnya di sini persis seperti yang dikatakan @thockin , ada hutang teknologi yang perlu kita perbaiki terlebih dahulu dan tangan diperlukan untuk itu sebelum kita dapat mempertimbangkan yang satu ini. Jadi permintaannya adalah agar orang-orang membantu dengan apa yang perlu dilakukan.

Silakan lihat pembaruan terbaru di sini: https://github.com/kubernetes/enhancements/pull/1874

@dims saya pikir saya telah disalahpahami. Yang ingin saya katakan adalah bahwa kita membutuhkan daftar target dan sasaran yang dapat ditindaklanjuti. Jika ada utang teknologi yang harus diselesaikan, maka kami dapat mempertahankan Tonggak GitHub atau memberikan daftar butir tindakan yang tertunda di komentar OP sehingga orang yang mengunjungi masalah ini dapat langsung mengetahui apa yang perlu ditangani.

Saya pasti bersedia menawarkan bantuan saya untuk menandatangani / simpul dengan memajukan KEP ini, tetapi tidak tahu caranya

@tariq1890 pertanyaan spesifik ada di sini: "prasyarat pada (belum diajukan KEP) kubelet node graceful shutdown" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Kita perlu memulainya. Seseorang harus mengambil poin dan mewujudkannya.

-- redup

Jadi rangkuman https://github.com/kubernetes/enhancements/pull/1874 untuk mereka yang ada dalam masalah ini: Sig-node (dan lainnya) menganggap tidak bijaksana untuk memperkenalkan fitur baru seperti KEP ini, yang menambahkan perilaku yang lebih kompleks ke penghentian pod, sementara masih ada masalah yang lebih umum dari penghentian pod saat sebuah node dimatikan.
Jadi telah diputuskan bahwa fitur ini tidak akan berkembang sampai solusi untuk penghentian node telah diimplementasikan.
Saat ini ada google doc di sini: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Yang memuat banyak pembahasan seputar masalah tersebut, namun KEP untuk ini belum disampaikan.
Masih ada pertanyaan terbuka sehingga mengomentari di sana bisa membantu, saya yakin @bobbypage dan @mrunalp memimpin upaya ini sehingga mungkin mereka dapat berbagi cara lain yang dapat membantu orang untuk memajukan ini.

@Joseph-Irving terima kasih banyak untuk meringkas. Saya berharap semua energi +ve pada peningkatan ini diterjemahkan ke lebih banyak partisipasi dari semua orang di sig-node secara teratur dan bukan hanya satu untuk fitur. Ada banyak pekerjaan yang harus dilakukan dan sangat sedikit tangan.

Hai! Satu komentar lagi mengenai KEP ini, meskipun: Saya mengangkat beberapa kasus tepi tentang KEP ini dalam pertemuan-pertemuan SIG-node sebelumnya (23 Juni jika Anda ingin menonton rekamannya) dan kami memutuskan bahwa cara yang tepat untuk melanjutkan diskusi itu adalah membuka PR tentang KEP tersebut. masalah sehingga kami dapat memutuskan cara terbaik untuk melanjutkan.

Saat ini saya sedang mengerjakan PR untuk menyatakan masalah tersebut dan beberapa alternatif yang dapat saya pikirkan.

Selain itu, status KEP sekarang bersifat sementara (bukan implementable) sehingga dapat ditinjau ulang dan baru ditetapkan menjadi implementable lagi ketika semua orang setuju merasa nyaman untuk maju dengan KEP.

Saya pikir ini adalah satu-satunya informasi yang hilang dalam masalah ini. Terima kasih!

@rata Apakah Anda membuka masalah/PR dengan cara yang tepat untuk menangani masalah?

@mattfarina Ini adalah PR https://github.com/kubernetes/enhancements/pull/1913
Ini berisi sejumlah solusi yang diusulkan untuk masalah saat ini/kasus tepi di KEP
Juga berisi rincian sejumlah alternatif yang dibahas dan diputuskan, sehingga kita memiliki catatan yang lebih baik tentang mengapa keputusan tertentu telah dibuat.

Saya sangat ingin melihat fungsionalitas sespan juga mencakup penskalaan:
Saat ini, penskalaan HPA didasarkan pada metrik (seperti cpu). Jika pod berisi lebih dari satu wadah, rata-rata di semua wadah digunakan (sejauh yang saya tahu). Untuk pod dengan sespan (app+nginx dll) ini membuat sangat sulit untuk membuat fungsi penskalaan dengan benar. Saya berharap implementasi sidecar di Kubernetes akan menyertakan penandaan satu kontainer di pod sebagai "otoritatif" dalam hal metrik yang digunakan untuk penskalaan HPA.

Saya sangat ingin melihat fungsionalitas sespan juga mencakup penskalaan:

Saya setuju ini akan berguna tetapi tidak harus spesifik "sespan" dan karena implementasinya tidak dipisahkan dari ini, mungkin masuk akal untuk menjadikannya masalah terpisah - yang ini sudah sangat kompleks. Saya juga tidak yakin Anda ingin mengabaikan sespan saja. Sebagai gantinya, kami mungkin menginginkan penskalaan HPA per wadah, misalnya. Tidak yakin - saya pikir perlu dijelajahi sebagai masalahnya sendiri.

Adakah yang punya referensi, atau bisa berbaik hati untuk berbagi, solusi saat ini untuk masalah ini, khususnya untuk kasus sespan Utusan Istio?

Saya ingat kemungkinan solusi yang melibatkan:

• gambar Utusan khusus yang mengabaikan SIGTERM.
• memanggil /quitquitquit pada Utusan dari dalam wadah aplikasi saat dimatikan (mirip dengan solusi penyelesaian Pekerjaan)

Adakah yang punya referensi, atau bisa berbaik hati untuk berbagi, solusi saat ini untuk masalah ini, khususnya untuk kasus sespan Utusan Istio?

Kami menggunakan gambar daemon khusus seperti supervisor untuk membungkus program pengguna. Daemon juga akan mendengarkan port tertentu untuk menyampaikan status kesehatan program pengguna (keluar atau tidak).

Inilah solusinya:

• Menggunakan gambar daemon sebagai initContainers untuk menyalin biner ke volume bersama.
• CD akan membajak perintah pengguna, biarkan daemon memulai terlebih dahulu. Kemudian, daemon menjalankan program pengguna sampai Envoy siap.
• Juga, kami menambahkan preStop , skrip yang terus memeriksa status kesehatan daemon, untuk Envoy.

Akibatnya, proses pengguna akan dimulai jika Envoy sudah siap, dan Envoy akan berhenti setelah proses pengguna keluar.

Ini adalah solusi yang rumit, tetapi bekerja dengan baik di lingkungan produksi kami.

Tautan dalam deskripsi memberikan 404

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

Saya pikir itu harus:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

ya itu dipindahkan di https://github.com/kubernetes/enhancements/pull/1913 , saya telah memperbarui tautannya

Adakah yang punya referensi, atau bisa berbaik hati untuk berbagi, solusi saat ini untuk masalah ini, khususnya untuk kasus sespan Utusan Istio?

@shaneqld untuk masalah startup, komunitas istio datang dengan solusi yang

Kami harus mem-porting ini ke versi yang kami jalankan tetapi cukup mudah dan puas dengan hasilnya sejauh ini.

Untuk shutdown, kami juga 'menyelesaikan' dengan preStop hook tetapi menambahkan sleep arbitrer yang kami harap aplikasi akan shutdown dengan anggun sebelum melanjutkan dengan SIGTERM.

Humas terkait: https://github.com/kubernetes/enhancements/pull/1980

Hai @Joseph-Irving @thockin dan yang lainnya :smile:

Peningkatan Pimpin di sini. Saya melihat bahwa masih ada banyak percakapan yang sedang berlangsung, tetapi sebagai pengingat, harap beri tahu kami tentang rencana apa pun untuk memasukkan ini dalam 1,20 diputuskan sehingga kami dapat melacak kemajuannya.

Terima kasih!
Kirsten

@kikisdeliveryservice akan membuat Anda tetap diposting, terima kasih!

Adakah yang punya referensi, atau bisa berbaik hati untuk berbagi, solusi saat ini untuk masalah ini, khususnya untuk kasus sespan Utusan Istio?

@shaneqld untuk masalah startup, komunitas istio datang dengan solusi yang

Kami harus mem-porting ini ke versi yang kami jalankan tetapi cukup mudah dan puas dengan hasilnya sejauh ini.

Untuk shutdown, kami juga 'menyelesaikan' dengan preStop hook tetapi menambahkan sleep arbitrer yang kami harap aplikasi akan shutdown dengan anggun sebelum melanjutkan dengan SIGTERM.

Bisakah Anda menunjukkan beberapa wawasan secara rinci bagaimana melakukan ini? Bagaimana cara menambahkan 'pra-stop' ke sespan proksi Istio? Tampaknya perlu beberapa konfigurasi khusus atau menggunakan sespan khusus. Saya menghadapi masalah yang sama ketika pod berkurang, wadah utama mencoba menyelesaikan pekerjaan tetapi kehilangan koneksi ke luar mungkin karena kereta sespan Istio ditutup segera setelah SIGTERM. Saat ini saya hanya menggunakan injeksi sespan bawaan. Terima kasih!

Oke thread ini dibajak. Mari kita tetap pada topik, silakan.

Hanya pengingat lembut bahwa Enhancements Freeze minggu depan, Selasa, 6 Oktober. Pada saat itu KEP perlu diperbarui untuk ditandai dapat diterapkan.

KEP juga menggunakan format yang lebih lama, jadi pembaruan akan menjadi hal yang bagus (setelah Anda menyelesaikan detailnya): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice terima kasih untuk sisanya. Akan dilakukan jika diputuskan untuk dimasukkan untuk 1,20. Terima kasih! :)

Ini tidak akan menjadi bagian dari 1.20. Terima kasih banyak untuk ping! :)

Saya tertarik dengan masalah ini, dan ingin berterima kasih kepada @Joseph-Irving dan @howwardjohn atas wawasan mereka tentang hal ini, yang membantu menyelesaikan beberapa pertanyaan saya.

Saya tidak ingin membajak proposal ini, tetapi berdasarkan percakapan di atas, saya bertanya-tanya apakah ini mungkin masalah yang sedikit lebih luas/lebih besar daripada yang diketahui sejauh ini.

Saya dapat membayangkan solusi berikut untuk masalah ini -

1. Tetapkan entitas wadah baru "wadah sespan" yang dimulai setelah initContainers, sebelum "wadah utama", dan berakhir setelah "wadah utama" berakhir (sesuai proposal asli @Joseph-Irving)
2. Tentukan bidang tambahan pada (1) yang menetapkan apakah "wadah sespan" dimulai sebelum initContainer sesuai saran @luksa ).
3. Pergi lebih luas.

Secara pribadi, opsi (2) memecahkan masalah langsung saya.

Tapi saya ingin tahu apakah pertanyaan-pertanyaan ini tidak membahas masalah yang lebih strategis di K8 seputar penjadwalan dan bagaimana kita mendefinisikan sebuah pod. Dalam kasus khusus saya (terkait Istio) , saya menyarankan sesuatu seperti runlevel di dalam pod.

Opsi (2) memecahkan masalah saya juga, tetapi saya dapat membayangkan struktur ketergantungan yang lebih kompleks yang mungkin memerlukan penyematan DAG dependensi wadah di dalam pod/statefulSet/daemonSet/apa pun - ini adalah opsi (3) yang saya pikirkan.

Hanya ingin tahu apakah masalah ini harus benar-benar difokuskan kembali pada definisi pod itu sendiri, dengan maksud untuk menciptakan sesuatu yang lebih umum? Saya awalnya berpikir dalam hal analogi runlevel, tetapi mungkin struktur DAG seperti Aliran Udara akan memiliki penerapan terluas.

Bagaimana dengan menambahkan utusan sebagai wadah init juga? Dengan cara ini ia akan menyediakan jaringan untuk wadah init lainnya. Ketika init akan selesai itu akan 'keluar 0' juga, dan kemudian utusan biasa (bukan init) akan mengambil alih

@michalzxc Jika saya tidak salah, wadah init dieksekusi satu per satu secara berurutan, jadi saat ini Anda tidak dapat memiliki utusan di sebelah wadah lain sebagai init-container .

Hai!

Diskusi sespan berlanjut di tempat ini (Saya telah memperbarui sig-node slack, github PR yang memulai ini dan beberapa milis):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

Seperti yang Anda lihat, kami mengumpulkan kasus penggunaan sekarang, setelah memiliki beberapa kasus penggunaan lagi, kelompok kecil yang berbeda dapat membuat pra-proposal untuk menanganinya. Jangan ragu untuk menambahkan kasus penggunaan Anda (jika belum ada) atau bergabung nanti untuk bagian pra-proposal :-)

Tolong, biarkan masalah peningkatan ini tetap pada topik (dan mungkin ditutup). Anda dipersilakan untuk bergabung dengan percakapan di tempat-tempat itu :)

KEP ini tidak akan berkembang, Sig-node dan yang lainnya merasa bahwa ini bukan langkah tambahan ke arah yang benar sehingga mereka kembali ke papan gambar dan akan datang dengan beberapa KEP baru yang diharapkan dapat menyelesaikan semua penggunaan kasus-kasus yang tercantum dalam KEP ini maupun yang lainnya.

Silakan lihat @rata 's komentar sebelumnya https://github.com/kubernetes/enhancements/issues/753#issuecomment -707.014.341
Untuk tempat di mana Anda dapat berkontribusi dalam diskusi.

Sangat disayangkan bahwa semua pekerjaan yang dilakukan pada KEP ini tidak akan digunakan, tetapi sekelompok orang yang lebih luas sekarang memikirkan masalah ini, jadi semoga solusi yang mereka dapatkan adalah yang terbaik untuk semua orang.
Saya telah menghabiskan lebih dari dua tahun mencoba untuk menyelesaikan ini, jadi saya pikir ini saat yang tepat bagi saya untuk melanjutkan, @rata dan yang lainnya akan memimpin inisiatif ini ke depan.

/Menutup

@Joseph-Irving: Menutup masalah ini.