Referensi Silang dengan kubernetes / kubernetes: Edisi # 62822

Terima kasih atas pembaruannya!

/assign @leblancd
/jenis fitur
/tanda tangan jaringan
/tonggak sejarah 1.11

@leblancd ada dokumen desain yang tersedia?

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi - Belum ada dokumen desain, tetapi kami akan segera mulai berkolaborasi dalam satu desain.

Apakah ini berarti Kubernetes Ingress akan mendukung Dual-Stack ?
Apakah ini berarti CNI ( Calico) perlu menjalankan Dual stack ( daemon BIRD dan BIRD6 misalnya) ?

@ sb1975 - Mengenai dukungan masuknya tumpukan ganda, itu adalah sesuatu yang perlu kita keluarkan, tetapi inilah pemikiran awal saya:

• Dukungan masuknya tumpukan ganda sebagian besar akan bergantung pada pengontrol masuk yang Anda gunakan (apakah didukung dan bagaimana penerapannya). Pengontrol masuk yang ada mungkin memerlukan beberapa perubahan untuk mendukung tumpukan ganda.
• Saya berharap konfigurasi ingress untuk pengontrol ingress tipikal tidak akan berubah (konfigurasi mungkin misalnya masih memetakan alamat L7 ke nama layanan/port layanan, tanpa menyebutkan keluarga V4/V6)
• Jika suatu layanan memiliki pod titik akhir yang merupakan tumpukan ganda, pengontrol ingress mungkin memerlukan perubahan untuk memetakan paket ingress berdasarkan keluarga paket, yaitu memetakan paket ingress IPv4 ke endpoint IPv4, dan memetakan paket ingress IPv6 ke titik akhir IPv6. Untuk tujuan pembobotan keseimbangan beban, titik akhir tumpukan ganda harus dihitung sebagai target titik akhir tunggal.

- Kami mungkin ingin mempertimbangkan dukungan FUTURE untuk memiliki peta pengontrol ingress di seluruh keluarga V4/V6 (memetakan paket IPv4 ingress ke backend IPv6, dan sebaliknya), tetapi pengembangan awal kami adalah untuk dual-stack yang ketat (yaitu terpisah, independen tumpukan).

Mengenai Calico dan plugin CNI lainnya:

• Plugin CNI tidak HARUS berjalan dalam mode dual-stack jika skenario cluster tidak memerlukan dual-stack, mereka masih dapat menjalankan IPv4-only atau IPv6-only (jika plugin mendukungnya).
• Dukungan dual-stack mungkin memerlukan perubahan di berbagai plugin CNI, tetapi pekerjaan itu dianggap di luar cakupan masalah Kubernetes ini (kami berfokus untuk membuat Kubernetes berfungsi untuk plugin dual-stack arbitrer, mungkin menggunakan plugin bridge sebagai referensi), dan pekerjaan CNI akan dilakukan secara terpisah berdasarkan kasus per kasus.
• Khusus untuk Calico, saya bukan ahli tetapi saya percaya bahwa satu daemon BIRD dapat dikonfigurasi untuk menangani rute IPv4 dan IPv6 (cari "template bgp" di sini: http://bird.network.cz/?get_doc&v= 20&f=bird-3.html#ss3.1). Meskipun demikian, meskipun Calico sudah mendukung alamat dual-stack di pod, mungkin ada perubahan yang diperlukan agar perutean BGP berfungsi untuk kedua keluarga.

@leblancd : Jadi

1. Katakanlah kita akan menggunakan pengontrol masuknya NGINX
2. Saya mengekspos layanan saya melalui Ingress.
3. Saya menjalankan pod saya yang dikonfigurasi pada dual-stack
4. Saya mencoba menjangkau layanan dari jarak jauh menggunakan A dan AAAA dns-records.
   Semoga semua ini
5. Singkatnya : Saya ingin terhubung ke antarmuka pod menggunakan alamat IPv4 atau IPv6, sebagaimana diselesaikan oleh kueri saya sendiri untuk catatan A dan/atau AAAA untuk nama layanan pod.
   Bisakah saya terlibat dalam inisiatif ini untuk menguji, dokumentasi, arsitektur: tetapi perlu bimbingan.
   Bagaimana saya bisa tahu tentang kemajuan ini, tolong.

@sb1975 - Pertanyaan bagus kembali. pengontrol masuknya NGINX dengan tumpukan ganda. Saya bukan ahli dalam pengontrol masuknya NGINX (mungkin seseorang yang lebih akrab dapat masuk), tetapi inilah cara saya melihat alur kerjanya:

• Saat Anda mencoba menjangkau layanan Kube dari luar, pengontrol DNS Anda harus menyelesaikan layanan dengan catatan DNS A dan AAAA untuk pengontrol ingress. Itu akan menjadi pilihan klien/aplikasi Anda untuk menggunakan A vs. record AAAA untuk mencapai pengontrol ingress. Jadi akses eksternal ke pengontrol ingress akan menjadi dual-stack.
• Pada pengontrol ingress NGINX, NGINX kemudian akan melihat URL L7 (terlepas dari permintaan dalam paket IPv4 atau IPv6) dan memuat keseimbangan itu ke titik akhir hulu. Jika penyeimbang beban pengontrol ingress dikonfigurasi dengan ipv6=on (yang merupakan default, lihat https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns), dan titik akhir layanan adalah tumpukan ganda, maka konfigurasi hulu harus memiliki entri IPv4 dan IPv6 untuk setiap titik akhir tumpukan ganda. Seperti yang dirancang, penyeimbang beban NGINX memperlakukan entri IPv4 dan entri IPv6 untuk titik akhir sebagai server terpisah . (Lihat baris di dokumen yang disebutkan sebelumnya "Jika nama domain ditetapkan ke beberapa alamat IP, alamat tersebut disimpan ke konfigurasi hulu dan beban seimbang.") Ini dapat dianggap sebagai kabar baik atau kabar buruk. Kabar baiknya adalah bahwa penyeimbangan beban akan dilakukan di seluruh titik akhir IPv4 dan IPv6 (memberi Anda beberapa redundansi), di mana misalnya permintaan IPv4 yang masuk dapat dipetakan ke titik akhir IPv4 atau IPv6. Tetapi potensi berita buruknya adalah dengan perincian penyeimbangan muatan: koneksi ke titik akhir IPv4 dan koneksi ke titik akhir IPv6 yang sesuai akan diperlakukan (untuk pertimbangan penyeimbangan muatan) sebagai 2 muatan ke titik akhir yang terpisah, bukan 2 muatan terpisah ke titik akhir yang sama . Jika perincian penyeimbangan beban ini menjadi perhatian, maka seseorang dapat menonaktifkan penyeimbangan beban ke IPv6 (atau ke IPv4, jika ada tombol konfigurasi untuk itu?), sehingga penyeimbangan beban akan menjadi titik akhir khusus IPv4. ATAU , mungkin penyeimbang beban NGINX dapat dimodifikasi untuk menangani koneksi ke alamat IPv4 dan koneksi ke alamat IPv6 yang sesuai sebagai 2 beban ke titik akhir yang sama.

Adapun untuk membantu dan terlibat, ini akan sangat dihargai! Kami akan mulai bekerja dengan sungguh-sungguh pada dual-stack (sudah sedikit tertunda oleh pekerjaan dalam membuat CI bekerja untuk IPv6 saja). Saya berharap untuk segera keluar dengan garis besar untuk spesifikasi (Google Doc atau KEPs WIP doc), dan akan mencari bantuan dalam meninjau, dan mungkin menulis beberapa bagian. Kami juga PASTI membutuhkan bantuan dengan dokumentasi resmi (di luar spesifikasi desain), dan dengan mendefinisikan dan mengimplementasikan pengujian E2E tumpukan ganda. Beberapa area yang saya masih agak samar untuk desainnya meliputi:

• Bagaimana probe kesehatan/keaktifan/kesiapan terpengaruh atau ditangani dengan tumpukan ganda
• Apakah akan ada dampak pada kebijakan jaringan?
• Masalah penyeimbang beban?
• Masalah plugin penyedia cloud?
• Kekhawatiran masuknya L3/L4?
  Jika Anda telah memikirkan salah satu dari ini, mungkin Anda dapat membantu dengan bagian-bagian itu?

Kami juga mempertimbangkan pendekatan "dual-stack at the edge" perantara (dengan IPv6-only di dalam cluster), di mana akses dari luar cluster ke layanan K8 akan berupa dual-stack, tetapi ini akan dipetakan (misalnya melalui NGINX ingress controller) ke endpoint khusus IPv6 di dalam cluster (atau gunakan NAT46 stateless). Pod dan layanan dalam cluster harus semuanya IPv6, tetapi keuntungan besar adalah akses eksternal dual-stack akan tersedia jauh lebih cepat dari perspektif waktu-ke-pasar.

/tonggak sejarah 1.12

@leblancd / @caseydavenport - Saya melihat banyak diskusi di sini dan perubahan penting.
Haruskah ini ditarik dari tonggak 1,11?

@justaugutus - Ya, ini harus dipindahkan ke 1.12. Apakah saya perlu menghapus satu baris di lembar bentang rilis, atau adakah yang perlu saya lakukan untuk mengubahnya?

@leblancd saya sudah membahasnya. Terima kasih telah menindaklanjuti! :)

@leblancd @kubernetes/sig-network-feature-requests --

Fitur ini telah dihapus dari pencapaian sebelumnya, jadi kami ingin memeriksa dan melihat apakah ada rencana untuk ini di Kubernetes 1.12.

Jika demikian, pastikan bahwa masalah ini mutakhir dengan SEMUA informasi berikut:

• Deskripsi fitur satu baris (dapat digunakan sebagai catatan rilis):
• Kontak utama (penerima tugas):
• SIG yang bertanggung jawab:
• Tautan proposal desain (repo komunitas):
• Tautan ke e2e dan/atau pengujian unit:
• Peninjau - (untuk LGTM) merekomendasikan agar 2+ pengulas (setidaknya satu dari file PEMILIK area kode) setuju untuk meninjau. Peninjau dari beberapa perusahaan lebih disukai:
• Penyetuju (kemungkinan dari SIG/area tempat fitur tersebut dimiliki):
• Target fitur (target mana yang sama dengan pencapaian yang mana):
  
  
  
  • Target rilis alfa (xy)
  
  
  • Target rilis beta (xy)
  
  
  • Target rilis stabil (xy)
  
  

Tetapkan berikut ini:

• Keterangan
• Penerima Tugas
• Label:
  
  
  
  • tahap/{alfa, beta, stabil}
  
  
  • tanda tangan/*
  
  
  • jenis/fitur
  
  

Harap dicatat bahwa Pembekuan Fitur adalah 31 Juli, setelah itu setiap masalah Fitur yang tidak lengkap akan memerlukan permintaan Pengecualian untuk diterima ke dalam pencapaian.

Selain itu, harap perhatikan tenggat waktu yang relevan berikut ini:

• Batas waktu dokumen (PR placeholder terbuka): 21/8
• Pembekuan kasus uji: 8/28

Pastikan semua PR untuk fitur memiliki catatan rilis yang relevan juga disertakan.

Selamat pengiriman!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@leblanc --
Fitur Freeze adalah hari ini. Apakah Anda berencana untuk meloloskan ini ke Beta di Kubernetes 1.12?
Jika demikian, dapatkah Anda memastikan semuanya mutakhir, sehingga saya dapat memasukkannya ke dalam spreadsheet Pelacakan fitur 1.12?

Hai @justaugutus - Status beta perlu dimasukkan ke Kubernetes 1.13. Kami membuat (meskipun lambat) kemajuan pada desain KEP (https://github.com/kubernetes/community/pull/2254), dan kami semakin dekat untuk terlibat kembali dengan PR uji CI, tetapi Kubernetes 1.12 target agak terlalu optimis.

Saya akan memperbarui deskripsi/ringkasan di atas dengan informasi yang Anda minta sebelumnya. Terima kasih atas kesabaran Anda.

/hapus tahap alfa
/tahap beta

Jangan khawatir, @leblancd. Terima kasih atas pembaruannya!

Hai, @justaugutus @leblancd

Saya baru saja membaca pembaruan bahwa beta dipindahkan ke 1,13 untuk tumpukan ganda. Berapa tanggal rilis yang diharapkan dari 1.13? Kami sebenarnya mencari dukungan tumpukan ganda. Ini adalah keputusan go-nogo untuk produk kami pindah ke kontainer.

@navjotsingh83 - Saya tidak berpikir tanggal rilis untuk Kubernetes 1.13 telah dipadatkan. Saya tidak melihat 1,13 tercantum dalam dokumentasi rilis Kubernetes .

@navjotsingh83 @leblancd 1.13 jadwal rilis dipublikasikan . Ini adalah siklus rilis singkat dengan pembekuan Kode pada 15 November. Apakah menurut Anda ini cukup waktu untuk meningkatkan fitur ini ke Beta. Bisakah Anda memperbarui masalah ini dengan tingkat kepercayaan Anda, apa yang tertunda dalam hal penyelesaian kode, pengujian, dan dokumen?

Sesuai diskusi dalam pertemuan Jaringan SIG, meskipun akan ada banyak pekerjaan yang dilakukan pada fitur ini di 1.13, itu tidak diharapkan untuk pergi ke Beta di 1.13. menghapus tonggak sesuai.

/pencapaian jelas

@kacole2 untuk menghapus ini dari 1.13 peningkatan spreadsheet

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

@leblancd Halo - Saya memimpin peningkatan untuk 1.14 dan saya memeriksa masalah ini untuk melihat pekerjaan apa (jika ada) yang direncanakan untuk rilis 1.14. Pembekuan perangkat tambahan adalah 29 Januari dan saya ingin mengingatkan bahwa semua perangkat tambahan harus memiliki KEP

@leblancd Ingin menindaklanjuti komentar Anda sebelumnya terkait dengan membuat penggambaran di tepi cluster untuk IPv4/IPv6:

“Kami juga mempertimbangkan pendekatan perantara "dual-stack at the edge" (dengan IPv6-only di dalam cluster), di mana akses dari luar cluster ke layanan K8 akan menjadi dual-stack, tetapi ini akan dipetakan (mis. NGINX ingress controller) ke endpoint khusus IPv6 di dalam cluster (atau gunakan NAT46 stateless). Pod dan layanan dalam cluster harus semuanya IPv6, tetapi keuntungan besarnya adalah akses eksternal dual-stack akan tersedia jauh lebih cepat dari perspektif waktu-ke-pasar.”

Kasus penggunaan ini akan menjadi salah satu yang bagus untuk proyek saat ini, jadi ingin melihat pemikiran Anda seputar jangka waktu, lihat apakah ada sesuatu yang saya atau seseorang dalam grup kami dapat berkontribusi untuk membantu dengan waktu yang lebih cepat ke jalur pasar ini.

@KevinAtDesignworx Jika pendekatan edge-dual-stack tetapi hanya ipv6 internal masih dapat mencapai permintaan ipv4 eksternal dari dalam wadah (yaitu curl -v 93.184.216.34 -H "Host: example.com" ), saya benar-benar berpikir itu pendekatan terbaik. Jika infrastruktur Anda dapat menggunakan ipv6, mengapa repot-repot menggunakan ipv4 kecuali di tepi untuk alasan kompatibilitas. Namun, jika pendekatan ini berarti saya tidak dapat menjangkau situs web lama hanya menggunakan ipv4 dari dalam cluster saya, saya tidak begitu yakin lagi.

baik ada 464XLAT jadi ipv6 hanya di dalam wadah yang layak.

@KevinAtDesignworx - Jika menggunakan pengontrol ingress akan berfungsi dalam skenario Anda, dimungkinkan untuk mengonfigurasi pengontrol ingress NGINX untuk operasi tumpukan ganda dari luar (proksi ke keluarga tunggal di dalam cluster): https://github.com/leblancd/ kube-v6#menginstal -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

Pengontrol ingress perlu dijalankan di jaringan host pada setiap node, sehingga pengontrol perlu diatur sebagai daemonset (satu pengontrol ingress pada setiap node). Ini mengasumsikan:

• Node Anda adalah tumpukan ganda (berlawanan dengan pod dan layanan yang bersifat keluarga tunggal)
• /etc/hosts Anda di setiap node memiliki entri IPv6, dan hanya entri IPv6 (tanpa alamat IPv4) untuk nama host node tersebut.

Ini akan menjadi tambahan untuk NAT64/DNS64 untuk koneksi dari klien V6 di dalam cluster ke server khusus IPv4 eksternal.

Stateless NAT46 juga merupakan opsi, tetapi saya belum mencobanya, jadi saya tidak memiliki panduan konfigurasi untuk itu.

@leblancd ada pekerjaan yang direncanakan di sini untuk 1,15? Sepertinya KEP juga belum diterima saat ini. Terima kasih!

@leblancd Ingin menindaklanjuti komentar Anda sebelumnya terkait dengan membuat penggambaran di tepi cluster untuk IPv4/IPv6:

“Kami juga mempertimbangkan pendekatan perantara "dual-stack at the edge" (dengan IPv6-only di dalam cluster), di mana akses dari luar cluster ke layanan K8 akan menjadi dual-stack, tetapi ini akan dipetakan (mis. NGINX ingress controller) ke endpoint khusus IPv6 di dalam cluster (atau gunakan NAT46 stateless). Pod dan layanan dalam cluster harus semuanya IPv6, tetapi keuntungan besarnya adalah akses eksternal dual-stack akan tersedia jauh lebih cepat dari perspektif waktu-ke-pasar.”

Kasus penggunaan ini akan menjadi salah satu yang bagus untuk proyek saat ini, jadi ingin melihat pemikiran Anda seputar jangka waktu, lihat apakah ada sesuatu yang saya atau seseorang dalam grup kami dapat berkontribusi untuk membantu dengan waktu yang lebih cepat ke jalur pasar ini.

Dari dalam wadah (yang hanya ipv6) mengirimkan permintaan curl (yaitu curl -v 93.184.216.34 -H "Host: example.com") ke luar cluster. Saya pikir itu akan memberikan kesalahan tujuan yang tidak diketahui atau tujuan yang tidak dapat dijangkau, kecuali jika ada rute ipv4 di Host tempat wadah ada.

@ GeorgeGuo2018 jika k8s akan mengimplementasikan DNS64/NAT64 itu akan berhasil. itu sangat tergantung pada seberapa jauh k8 akan masuk ke solusi 464xlat/plat dan apa yang perlu ditangani di router tepi, dll ...

sebenarnya saya pikir itu mungkin dengan menggunakan DaemonSet/Deployment yang menggunakan jaringan host dan Tayga di dalam namespace sistem kube sehingga DNS64 internal akan menggunakan tayga untuk pergi ke luar jaringan.

Kedengarannya seperti solusi bagi saya.

Kami menjalankan jaringan khusus IPv6 secara internal dan NAT64/DNS64 bekerja cukup baik untuk kami. Untuk beberapa hal warisan di mana tidak ada dukungan IPv6 sama sekali, kami akhirnya menggunakan clatd secara langsung di tempat yang dibutuhkan. (Dalam kasus kami langsung di VM.)

@kacole2 - Saya ingin ini dilacak untuk 1,15. Saya sedang berupaya untuk menggabungkan PR berikut - https://github.com/kubernetes/enhancements/pull/808

Khusus untuk 1,15 kami akan menambahkan dukungan untuk hal-hal berikut:

• Modifikasi jenis API
  
  
  
  • Jenis Kubernetes
  
  
  • jenis CRI
  
  
• jaringan pod tumpukan ganda (pod multi-IP)
• dukungan multi-keluarga kubenet

cc @caseydavenport untuk pelacakan pencapaian ^

@kacole2 KEP sekarang digabung. Beri tahu saya jika ada hal lain yang kami perlukan untuk melacak ini di 1.15

Hai @leblancd @lachie83 Sekedar pengingat kami sedang mencari PR terhadap k/website (cabang dev-1.15) yang jatuh tempo pada hari Kamis, 30 Mei. Akan lebih bagus jika ini adalah awal dari dokumentasi lengkap, tetapi bahkan pengganti PR dapat diterima. Beri tahu saya jika Anda memiliki pertanyaan!

@kacole2 KEP sekarang digabung. Beri tahu saya jika ada hal lain yang kami perlukan untuk melacak ini di 1.15

@lachie83 Hai, Lachie, maksud Anda dukungan dual-stack IPv4/IPv6 KEP ini telah selesai?

@kacole2 KEP sekarang digabung. Beri tahu saya jika ada hal lain yang kami perlukan untuk melacak ini di 1.15

Sebenarnya, saya ingin mencari tahu apakah dukungan dual stack pasti akan ditambahkan di k8s 1.15.

@leblancd PR placeholder melawan k8s.io dev-1.15 jatuh tempo Kamis 30 Mei.

@leblancd PR placeholder melawan k8s.io dev-1.15 jatuh tempo Kamis 30 Mei.

Bisakah saya mempertimbangkan bahwa dukungan tumpukan ganda akan tersedia di rilis-1.15?

@GeorgeGuo2018 Masih ada di lembar peningkatan untuk 1,15 tetapi hanya petunjuk peningkatan @kacole2 yang dapat memberi Anda detail yang lebih baik tentang itu.

Hai @lachie83 @leblancd. Code Freeze hari Kamis, 30 Mei 2019 @ EOD PST . Semua penyempurnaan yang masuk ke rilis harus lengkap kode, termasuk tes , dan membuka PR dokumen.

Harap cantumkan semua PR k/k saat ini sehingga dapat dilacak saat membeku. Jika PR tidak digabungkan dengan pembekuan, fitur ini akan tergelincir untuk siklus rilis 1,15. Hanya masalah pemblokiran rilis dan PR yang akan diizinkan dalam pencapaian tersebut.

Saya melihat kubernetes/kubernetes#62822 di pos asli masih terbuka. Apakah ada PR lain yang kami harapkan untuk digabungkan juga?

Jika Anda tahu ini akan tergelincir, balas kembali dan beri tahu kami. Terima kasih!

@simplytunde - Hargai perhatiannya. Saya sedang mengerjakan PR dokumen bersama minggu ini.

@GeorgeGuo2018 - Ini akan menjadi KEP multi-rilis. Kami berencana mendarat fase 1 di 1.15. Silakan lihat rencana implementasi di KEP untuk detail lebih lanjut - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -rencana.

@simplytunde - Saya telah membuat PR dokumen placeholder awal di sini dengan WIP https://github.com/kubernetes/website/pull/14600 . Saya berencana untuk menyelesaikannya dan menyiapkannya untuk ditinjau selama beberapa hari ke depan.

@kacole2 Terima kasih atas

@kacole2 setelah berdiskusi dengan @claurence dan tim rilis, kami memutuskan untuk menghapus ini dari pencapaian 1,15. Silakan lanjutkan dan hapus dan perbarui spreadsheet yang sesuai. Terima kasih atas semua bantuan Anda selama ini.

/pencapaian jelas

@simplytunde Saya juga mengomentari PR dokumen. Bisakah Anda memastikan itu dihapus dari tonggak 1,15 juga?

Hai @lachie83 @leblancd , saya adalah Enhancement Shadow 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 .

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

Terima kasih.

https://github.com/kubernetes/dns/issues/315 mencakup penambahan IPv6 / AAAA ke spesifikasi penemuan layanan DNS .

@lachie83 @leblancd ada ide apakah ini akan lulus dalam 1,16 untuk melacaknya?

@evillgenius75 @kacole2 Ini perlu dilacak di 1.16. Fitur ini akan berada dalam status alfa. Kami akan mengimplementasikan fase 1 dan fase 2 seperti yang didefinisikan dalam KEP adalah 1,16

Pelacakan KEP

• https://github.com/kubernetes/enhancements/pull/808

k/k PR yang digabungkan (saat ini di master akan berada di 1.16)

• [DIGABUNG] Fase 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [DIGABUNG] Tes e2e Fase 1 - https://github.com/kubernetes/kubernetes/pull/78801
• [DIGABUNG] Pembersihan uji e2e Fase 1 - https://github.com/kubernetes/kubernetes/pull/80001
• Layanan Tahap 2/Titik Akhir - https://github.com/kubernetes/kubernetes/pull/79386
• Kube-proxy fase 2 - https://github.com/kubernetes/kubernetes/pull/79576

PR terkait

• Dukungan untuk IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Dokumen fase 1 – akan dibuka kembali setelah kami menyelesaikan contoh perkakas - https://github.com/kubernetes/website/pull/14600
• [DIGABUNG] pembersihan - node dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Mendukung beberapa Ukuran Masker untuk cluster cidrs - https://github.com/kubernetes/kubernetes/pull/79993
• Pekerjaan Prow E2e untuk dualstack https://github.com/kubernetes/test-infra/pull/12966

Hei, @leblancd Saya pemimpin rilis dokumen v1.16.

Apakah peningkatan ini (atau pekerjaan yang direncanakan untuk v1.16) memerlukan dokumen baru (atau modifikasi)?

Sekedar pengingat bahwa kami sedang mencari PR terhadap k/website (cabang dev-1.16) yang jatuh tempo pada hari Jumat, 23 Agustus. Akan sangat bagus jika ini adalah awal dari dokumentasi lengkap, tetapi bahkan PR pengganti dapat diterima. Beri tahu saya jika Anda memiliki pertanyaan!

@simplytunde di sini adalah PR dokumen - https://github.com/kubernetes/website/pull/16010

Pembekuan kode pengingat ramah
Layanan/Endpoint Fase 2 - kubernetes/kubernetes#79386
Kube-proxy fase 2 - kubernetes/kubernetes#79576

Terkait:
Mendukung beberapa Ukuran Masker untuk cluster cidrs - kubernetes/kubernetes#79993
E2e Prow Job untuk dualstack kubernetes/test-infra#12966

Hai @lachie83 @leblancd sepertinya https://github.com/kubernetes/kubernetes/pull/79576 dan https://github.com/kubernetes/kubernetes/pull/79993 tidak bergabung sebelum kode dibekukan dan tidak di Tide Merge Pool . Fitur ini akan dibenturkan dari v1.16. Jika Anda masih ingin ini menjadi bagian dari rilis 1.16, silakan ajukan pengecualian

@kacole2 Mohon maaf atas keterlambatan tanggapan. PR utama yang dilacak adalah https://github.com/kubernetes/kubernetes/pull/79386. Adapun kubernetes/kubernetes#79576 kami membuat keputusan untuk menunda itu menjadi 1,17 dan sebagai gantinya fokus pada https://github.com/kubernetes/kubernetes/pull/82091 (sesuai dengan sig-network) yang memenuhi tujuan phase2 yang sama yang dituangkan dalam KEP. PR terkait lainnya yang dilacak dalam rilis ini adalah https://github.com/kubernetes/kubernetes/pull/80485 yang juga digabungkan. kubernetes/kubernetes#79993 juga telah ditangguhkan ke 1.17

Hai @lachie83 @leblancd -- 1.17 Peningkatan memimpin di sini. Saya ingin memeriksa dan melihat apakah menurut Anda Peningkatan ini akan ditingkatkan ke alfa/beta/stabil 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, harap cantumkan semua PR k/k yang relevan dalam edisi ini sehingga dapat dilacak dengan benar. 👍

Terima kasih!

/pencapaian jelas

Hai Bob. Terima kasih telah menghubungi kami. Saya masih merencanakan fase 3 dari peningkatan ini yang akan melengkapi peningkatan hingga selesai. Peningkatan ini masih dalam tahap alfa pada akhir rilis ini tetapi akan ada pekerjaan terkait fase 3 yang akan mendarat di k/k sebagai bagian dari 1.17.

Berikut adalah daftar kiriman tingkat tinggi untuk 1,17 untuk tumpukan ganda. Saya akan memperbarui daftar ini sepanjang rilis.

• Proksier tumpukan ganda IPtables - https://github.com/kubernetes/kubernetes/pull/79576
• dukungan api ke bawah untuk Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e menguji satu plugin CNI
• Perubahan file host (alamat IPv6 untuk nama host perlu ditambahkan /etc/hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Jenis tumpukan ganda - https://github.com/kubernetes-sigs/kind/pull/692
• Perbarui suite e2e - https://github.com/kubernetes/kubernetes/pull/80725
• Dukungan irisan titik akhir
• Dukungan Dual-Stack untuk Kubeadm - https://github.com/kubernetes/kubeadm/issues/1612

Sangat dihargai, terima kasih @lachie83 ❤️ Saya akan melanjutkan dan menambahkannya ke lembar pelacakan.

/ tonggak sejarah v1.17

@mrbobbytables Saya juga telah menambahkan PR untuk merinci pekerjaan yang tercantum di atas sebagai bagian dari fase 3 di KEP setelah mengkomunikasikan rencana melalui jaringan tanda tangan. KEP itu sendiri masih dalam status implementable dan perubahan ini hanya mendokumentasikan pekerjaan yang direncanakan sebagai bagian dari 1.17 secara khusus.

Pada titik tertentu, saya ingin memastikan bahwa https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ mencakup DNS IPv6. https://github.com/kubernetes/website/issues/15434 melacak perubahan itu; menyebutkannya di sini untuk mencatat referensi silang.

Memperbarui KEP untuk menambahkan tes e2e fase 2 - https://github.com/kubernetes/enhancements/pull/1311

Halo @lachie83 Saya salah satu bayangan dokumen v1.17.
Apakah peningkatan ini untuk (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!

@lachie83

Karena kami mendekati batas waktu PR placeholder Dokumen pada 8 November. Silakan coba untuk mendapatkannya di cabang k/website dev-1.17.

Hai @lachie83 , saya tahu Anda terus mengawasi, tapi saya tetap harus mampir dan menyebutkannya
Pembekuan kode sudah dekat (14 November). Bagaimana keadaannya? Apakah semuanya di jalur untuk digabungkan sebelum itu?

Terima kasih!

Hai @mrbobbytables! Terima kasih untuk pingnya. Kami melacak PR berikut untuk mendarat di 1.17. Mungkin ada satu atau dua PR lagi yang terkait dengan perubahan ini yang masuk juga. Perubahan ini membutuhkan dokumen. Saya akan meningkatkan PR dokumen placeholder

• Dukungan dualstack untuk mode iptables kube-proxy pr/82462
• Dualstack api ke bawah pr/82462
• tambahkan dukungan ipvs metaproxier endpointslice pr/84089
• Izinkan beberapa node cidr mask di kube-controller-manager pr/79993

@irvifa - Ini adalah PR docs placeholder. https://github.com/kubernetes/website/pull/17457

Keren terima kasih @lachie83

@lacie83 besok adalah pembekuan kode untuk siklus rilis 1,17. Sepertinya PR k/k belum digabung. Kami menandai ini sebagai Berisiko di Lembar Pelacakan Peningkatan 1.17.
Apakah menurut Anda mereka akan digabungkan pada EoD tanggal 14 (Kamis)? Setelah titik itu, hanya masalah pemblokiran rilis dan PR yang akan diizinkan dalam pencapaian dengan pengecualian.

Terima kasih Bob - Saya akan mendiskusikan ini dengan sig-network hari ini dan akan memberikan pembaruan.

Hai @mrbobbytables. Berikut adalah daftar PR yang sedang kami kerjakan untuk digabungkan oleh EoD hari ini dan telah disetujui oleh sig-network.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

PR yang tersisa kemungkinan besar akan disepak ke 1,18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables baru saja mengkonfirmasi bahwa semua PR yang disebutkan di atas telah digabungkan dan bahwa kita memang akan menyepak kubernetes/kubernetes#82462 ke 1.18. Peningkatan ini masih dapat dilacak karena PR ini menambahkan perubahan makna pada perilaku dualstack di 1.17. Sekarang saya hanya perlu menyiapkan PR dokumen! Kami berharap untuk mendapatkan kubernetes/kubernetes#82462 di 1.18 dan melanjutkan pekerjaan ini ke versi beta

Bagus, terima kasih @lacie83!

Dan itu hidup! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

Kami berencana untuk memindahkan peningkatan ini ke beta di 1.18. Kriteria kelulusan peningkatan dan rencana tes dapat ditemukan di KEP bersama dengan PR ini - https://github.com/kubernetes/enhancements/pull/1429

/tonggak sejarah 1.18

@lachie83 : Pencapaian yang diberikan tidak valid untuk repositori ini. Tonggak sejarah dalam repositori ini: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Gunakan /milestone clear untuk menghapus pencapaian.

/ tonggak sejarah v1.18

Kami berencana untuk memindahkan peningkatan ini ke beta di 1.18. Kriteria kelulusan peningkatan dan rencana ujian dapat ditemukan di KEP bersama dengan PR ini - #1429

Terima kasih atas pembaruannya @lachie83 , saya telah menandai ini sebagai terlacak di spreadsheet 1,18!

Harap lacak PR berikut sebagai bagian dari pekerjaan untuk mendarat di 1.18. https://github.com/kubernetes/kubernetes/pull/82462

Menambahkan PR terkait lainnya untuk pelacakan:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

Terima kasih @lachie83!

Hai @lachie83 , apakah Anda memiliki PR lain yang harus kami lacak selain yang disebutkan di atas?

Halo, @lachie83 @leblancd - Saya bayangan Dokumen di tim rilis 1.18.

Apakah pekerjaan peningkatan ini direncanakan untuk 1.18 memerlukan dokumen baru atau modifikasi pada dokumen yang ada?

Jika tidak, dapatkah Anda memperbarui Lembar Pelacak Peningkatan 1.18 (atau beri tahu saya dan saya akan melakukannya)

Jika pembaruan dokumen diperlukan, pengingat bahwa PR placeholder terhadap k/website (cabang dev-1.18) akan jatuh tempo pada hari Jumat, 28 Februari.

Beri tahu saya jika Anda memiliki pertanyaan!

Jika ada yang ingin bantuan mendokumentasikan IPV6 atau hal-hal dual-stack untuk v1.18, beri saya dorongan. Saya mungkin bisa membantu.

Hai @lachie83 ,

Sepertinya kubernetes-sigs/kind#692 belum bergabung. Apakah itu penting untuk kelulusan Beta Anda?

Hei @jeremyrickard @sethmccombs kita harus menarik ini dari lulus ke beta mengingat PR ini https://github.com/kubernetes/kubernetes/pull/86895. Sampai kami memiliki cara yang masuk akal ke depan, saya pikir tidak bijaksana untuk memindahkan ini ke beta untuk 1,18

/pencapaian jelas

@lachie83 Terima kasih atas pembaruannya. Saya telah menghapus peningkatan ini dari tonggak sejarah. Nantikan ini pada 1,19. :)

Saya ingin mengonfirmasi bahwa status peningkatan dualstack tetap di alpha di 1.18. Saat ini saya bekerja dengan masyarakat untuk menilai pekerjaan yang direncanakan akan selesai pada 1,19. Kemungkinan peningkatan ini masih akan tetap dalam kondisi alfa di 1,19 namun saya ingin mengonfirmasi. Saya juga akan mengambil tindakan untuk memperbarui dokumen untuk mencerminkan status peningkatan di 1.18 dokumen.

Jika ada halaman di situs web yang menampilkan Kubernetes tumpukan ganda sebagai beta, harap laporkan ke k/website sebagai bug prioritas/penting-segera.

Hai @lachie83 -- 1,19 Enhancements Lead di sini, saya ingin melapor masuk jika menurut Anda peningkatan ini akan lulus dalam 1,19?

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

Jika ada halaman di situs web yang menampilkan Kubernetes tumpukan ganda sebagai beta, harap laporkan ke k/website sebagai bug prioritas/penting-segera.

@sftim Saya telah mengangkat dua PR untuk mengatasi pelabelan rilis di 1.17 dan 1.18

@palnabarun Kami sedang berupaya untuk memperbarui KEP dualstack dalam kerangka waktu rilis 1,19 namun saat ini kami tidak berpikir bahwa kami akan mendaratkan perubahan kode dalam rilis 1,19. Kami memiliki satu masalah pemblokiran dengan pekerjaan yang telah dilakukan (berkat memilikinya dalam status alpha ). Masalah pemblokiran adalah https://github.com/kubernetes/kubernetes/pull/86895. Kami berencana untuk mengatasinya melalui pembaruan KEP berikut https://github.com/kubernetes/enhancements/pull/1679 tetapi akan membutuhkan waktu untuk mendapatkan konsensus tentang perubahan yang diusulkan. Pada tahap ini, peningkatan dualstack akan tetap dalam status alpha sampai kami mengatasi masalah pemblokiran ini dengan implementasi saat ini. Saya akan memberikan pembaruan seiring berjalannya waktu.

Terima kasih, Lachie atas pembaruannya. Saya menghargai semua upaya! :slightly_smiling_face:

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

Kami ingin peningkatan ini dilacak di 1.20. Ini akan diimplementasikan kembali dalam status alfa sesuai dengan kep yang diperbarui - https://github.com/kubernetes/enhancements/pull/1679. Harap lacak PR berikut untuk implementasi - https://github.com/kubernetes/kubernetes/pull/91824. Kami berencana untuk menyelesaikan tinjauan dan menggabungkan PR di awal siklus rilis 1.20.

Kelulusan tumpukan ganda terbaru ke status Beta seperti yang dibahas dalam pertemuan Jaringan SIG 17 September, bagi mereka yang bermain bersama di rumah:

• Harus menyelesaikan ambiguitas pemeriksaan kesehatan tumpukan ganda kubelet; melalui https://github.com/kubernetes/enhancements/pull/1975
• Harus menyelesaikan dan menggabungkan PR layanan dual-stack yang ada (dalam tinjauan aktif); melalui https://github.com/kubernetes/kubernetes/pull/91824
• Harus menyelesaikan perilaku IP node tumpukan ganda; melalui https://github.com/kubernetes/enhancements/pull/1665
• Harus menentukan perubahan apa (jika ada) yang diperlukan untuk bidang Spec.LoadBalancerIPs Layanan

Semua item ini sedang dikerjakan secara aktif, dan 1,20 masih menjadi target kelulusan Beta API tumpukan ganda. Namun terlepas dari upaya terbaik kami, selalu ada kemungkinan sesuatu tidak akan diselesaikan tepat waktu, dan jika demikian, Jaringan SIG akan memutuskan apakah akan melanjutkan kelulusan ke Beta atau tidak dalam pertemuan publik kami. Semua bisa bergabung.

@dcbw terima kasih banyak atas pembaruannya (maaf saya tidak bisa menelepon). Apakah masuk akal untuk meningkatkan ini ke beta di 1.20 atau tetap dalam alfa? Jika kita ingin pergi ke beta apakah kriteria kelulusan di KEP masih masuk akal mengingat ini adalah implementasi ulang https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#kelulusan -kriteria

@dcbw terima kasih banyak atas pembaruannya (maaf saya tidak bisa menelepon). Apakah masuk akal untuk meningkatkan ini ke beta di 1.20 atau tetap dalam alfa? Jika kita ingin pergi ke beta apakah kriteria kelulusan di KEP masih masuk akal mengingat ini adalah implementasi ulang https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#kelulusan -kriteria

Ini sebenarnya bukan implementasi ulang. Semua pekerjaan sebelumnya masih berlaku dan pekerjaan di 1.20 sedang dibangun di atasnya untuk menyelesaikan perubahan terakhir yang diperlukan yang telah diidentifikasi. Interpretasi saya dari diskusi jaringan tanda tangan adalah bahwa daftar yang diposting @dcbw adalah kumpulan masalah yang diketahui yang perlu diselesaikan untuk kelulusan.

Halo semua,

1.20 Peningkatan Lead di sini, saya akan mengatur ini sebagai dilacak, harap perbarui saya jika ada perubahan :)

Sebagai pengingat, Enhancements Freeze adalah 6 Oktober.

Sebagai catatan, KEP menggunakan format lama yang telah kami perbarui ke: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Terbaik,
Kirsten

/tonggak sejarah v1.20

Hai, @russellb -

Ini sebenarnya bukan implementasi ulang. Semua pekerjaan sebelumnya masih berlaku dan pekerjaan di 1.20 sedang dibangun di atasnya untuk menyelesaikan perubahan terakhir yang diperlukan yang telah diidentifikasi.

Mengingat perubahan API di https://github.com/kubernetes/kubernetes/pull/91824 , cukup berbeda bahwa menandai tumpukan ganda sebagai alfa untuk 1.20 akan memberikan ruang untuk implementasi ulang lebih lanjut yang terbukti perlu. Saya tahu kita semua bersemangat untuk versi beta, tapi mari kita dapatkan PR dengan +9,319 −3,261 dan biarkan debunya mengendap. :)

Mengingat perubahan API di kubernetes/kubernetes#91824 , cukup berbeda bahwa menandai dual-stack sebagai alpha untuk 1.20 akan memberikan ruang untuk implementasi ulang lebih lanjut yang terbukti perlu. Saya tahu kita semua bersemangat untuk versi beta, tapi mari kita dapatkan PR dengan +9,319 −3,261 dan biarkan debunya mengendap. :)

@bridgetkromhout ya, kita perlu mendarat https://github.com/kubernetes/kubernetes/pull/91824 sebelum kita dapat membuat keputusan tentang kesiapan API. Saya sangat berharap kita bisa melakukannya secepatnya.

Halo semua,

1.20 Peningkatan bayangan di sini

Karena Peningkatan ini dijadwalkan pada 1.20, harap diingat tanggal-tanggal penting yang akan datang ini:
Jumat, 6 November: Minggu 8 - Batas waktu PR Placeholder Dokumen
Kamis, 12 November: Minggu 9 - Pembekuan Kode

Sebagai pengingat, harap tautkan semua PR k/k Anda serta PR dokumen ke masalah ini sehingga kami dapat melacaknya.

Terima kasih!

Hai @kinarashah @kikisdeliveryservice - Saya telah mengonfirmasi pada panggilan jaringan sig bahwa kami memerlukan reklasifikasi ini ke alfa untuk 1.20. Ini adalah implementasi ulang lengkap yang membutuhkan waktu untuk meresap dan diuji dalam tahap alfa.

Halo @lachie83 , 1.20 Docs shadow di sini.

Apakah pekerjaan peningkatan ini direncanakan untuk 1.20 memerlukan dokumen baru atau modifikasi pada dokumen yang ada?

Jika demikian, ikuti langkah-langkah di sini untuk membuka PR terhadap cabang dev-1.20 di repo k/website . PR ini hanya dapat menjadi pengganti saat ini dan harus dibuat sebelum 6 November .

Lihat juga Mendokumentasikan rilis untuk membiasakan diri Anda dengan persyaratan dokumen untuk rilis.

Terima kasih!

Terima kasih @reylejano-rxm - kami telah membuka kubernetes/website#24725

Hai @lachie83

Terima kasih telah membuat PR dokumen!

Harap diingat tanggal penting yang akan datang:

• Jumat, 6 November: Minggu 8 - Batas waktu PR Placeholder Dokumen SELESAI!
• Kamis, 12 November: Minggu 9 - Pembekuan Kode
• Senin, 23 Nov: Minggu 11 - PR Dokumen Siap Ditinjau

Sebagai pengingat, harap tautkan semua PR k/k Anda serta PR dokumen ke edisi ini untuk dilacak oleh tim rilis.

Hai @kinarashah @kikisdeliveryservice - Saya telah mengonfirmasi pada panggilan jaringan sig bahwa kami memerlukan reklasifikasi ini ke alfa untuk 1.20. Ini adalah implementasi ulang lengkap yang membutuhkan waktu untuk meresap dan diuji dalam tahap alfa.

Hai @lachie83

Mengingat hal di atas, saya menganggap bahwa ini masih ditujukan untuk alpha apa adanya? Saya tidak melihat ada PR luar biasa yang perlu digabungkan/pekerjaan sudah digabung.

_Hanya pengingat bahwa Code Freeze akan datang dalam 2 hari pada hari Kamis, 12 November . Semua PR harus digabungkan pada tanggal tersebut, jika tidak, Pengecualian diperlukan._

Terima kasih!
Kirsten

Hai, @kikisdeliveryservice - ya, dukungan dual-stack IPv4/IPv6 (diimplementasikan kembali) akan menjadi alfa untuk 1.20.

Inilah kemajuan yang kami miliki untuk peningkatan ini:

1) Kode digabungkan dari https://github.com/kubernetes/kubernetes/pull/91824 - akan menjadi alfa untuk 1,20
2) Pembaruan dokumentasi yang mencakup perubahan kode itu ada di https://github.com/kubernetes/website/pull/24725/ - ditinjau dan digabungkan ke cabang dev-1.20

Apakah ada hal lain yang diperlukan untuk 1.20 yang belum kami selesaikan pada peningkatan ini?

@bridgetkromhout Terima kasih atas pembaruan yang jelas, Anda semua baik-baik saja!

Sepertinya LoadBalancerIP di ServiceSpec belum menjadi bagian dari implementasi tumpukan ganda. Apakah ada rencana untuk mendukungnya atau saya melewatkannya?

Hai @chenwng - Perubahan pada kode penyedia cloud untuk Loadbalancer saat ini berada di luar cakupan seperti yang didefinisikan dalam KEP di sini - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#load -balancer-operation.

Anda dapat membantu dengan memberikan kasus penggunaan Anda dan perubahan yang disarankan untuk memahami dan memutuskan apakah kami perlu melakukan modifikasi pada KEP.

@chenwng Ada KEP yang sedang dikerjakan untuk LoadBalancerIPs di cluster dual-stack - https://github.com/kubernetes/enhancements/pull/1992

Terima kasih atas infonya, @aramase , @lachie83 .