Kubernetes: Kubelet/Kubernetes harus bekerja dengan Swap Diaktifkan

Dukungan untuk swap tidak sepele. Pod yang dijamin seharusnya tidak pernah membutuhkan swap. Pod yang dapat meledak harus memenuhi permintaannya tanpa memerlukan swap. Pod BestEffort tidak memiliki jaminan. Kubelet saat ini tidak memiliki kecerdasan untuk memberikan jumlah yang tepat dari perilaku yang dapat diprediksi di sini di seluruh pod.

Kami membahas topik ini di sumber daya mgmt tatap muka awal tahun ini. Kami tidak terlalu tertarik untuk mengatasi hal ini dalam waktu dekat dibandingkan dengan keuntungan yang dapat direalisasikan. Kami lebih memilih untuk meningkatkan keandalan seputar deteksi tekanan, dan mengoptimalkan masalah seputar latensi sebelum mencoba mengoptimalkan pertukaran, tetapi jika ini adalah prioritas yang lebih tinggi bagi Anda, kami akan sangat membantu Anda.

/jenis fitur

@derekwaynecarr terima kasih atas penjelasannya! Sulit untuk mendapatkan informasi/dokumentasi mengapa swap harus dinonaktifkan untuk kubernetes. Ini adalah alasan utama mengapa saya membuka topik ini. Pada titik ini saya tidak memiliki prioritas tinggi untuk masalah ini, hanya ingin memastikan bahwa kita memiliki tempat di mana hal itu dapat didiskusikan.

Ada lebih banyak konteks dalam diskusi di sini: https://github.com/kubernetes/kubernetes/issues/7294 - memiliki swap yang tersedia memiliki interaksi yang sangat aneh dan buruk dengan batas memori. Misalnya, wadah yang mencapai batas memorinya akan _kemudian_ mulai tumpah ke swap (ini tampaknya telah diperbaiki karena f4edaf2b8c32463d6485e2c12b7fd776aef948bc – mereka tidak akan diizinkan untuk menggunakan swap apa pun, baik itu ada atau tidak).

Ini adalah kasus penggunaan penting bagi kami juga. Kami memiliki tugas cron yang terkadang menggunakan penggunaan memori tinggi (>30GB) dan kami tidak ingin mengalokasikan 40+GB node secara permanen. Juga, mengingat bahwa kami berjalan di tiga zona (GKE), ini akan mengalokasikan 3 mesin tersebut (1 di setiap zona). Dan konfigurasi ini harus diulang dalam 3+ instans produksi dan 10+ instans pengujian yang membuat penggunaan K8 menjadi sangat mahal. Kami terpaksa memiliki 25+ 48GB node yang membutuhkan biaya besar!.
Harap aktifkan swap!.

Solusi bagi mereka yang benar-benar ingin bertukar. Jika kamu

• mulai kubelet dengan --fail-swap-on=false
• tambahkan swap ke node Anda
• kontainer yang tidak menentukan persyaratan memori maka secara default akan dapat menggunakan semua memori mesin, termasuk swap.

Itulah yang kami lakukan. Atau setidaknya, saya cukup yakin, saya tidak benar-benar menerapkannya secara pribadi, tetapi itulah yang saya kumpulkan.

Ini mungkin hanya benar-benar menjadi strategi yang layak jika tidak ada wadah Anda yang pernah menentukan persyaratan memori eksplisit ...

Kami berjalan di GKE, dan saya tidak tahu cara mengatur opsi itu.

Saya akan terbuka untuk mempertimbangkan mengadopsi zswap jika seseorang dapat mengevaluasi implikasinya terhadap pengusiran memori di kubelet.

Saya menjalankan Kubernetes di laptop Ubuntu lokal saya dan dengan setiap restart saya harus mematikan swap. Saya juga harus khawatir untuk tidak mendekati batas memori karena swap tidak aktif.

Apakah ada cara dengan setiap restart saya tidak harus mematikan swap seperti beberapa perubahan file konfigurasi pada instalasi yang ada?

Saya tidak perlu swap pada node yang berjalan di cluster.

Ini hanya aplikasi lain di laptop saya selain cluster Dev Lokal Kubernetes yang perlu swap untuk dihidupkan.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

Saat ini bendera tidak berfungsi.

# systemctl restart kubelet --fail-swap-on=false
systemctl: unrecognized option '--fail-swap-on=false'

Setel flag Kubelet berikut: --fail-swap-on=false

Pada Selasa, 30 Januari 2018 pukul 13.59, icewheel [email protected] menulis:

Saya menjalankan Kubernetes di laptop Ubuntu lokal saya dan dengan setiap restart saya
harus mematikan swap. Saya juga harus khawatir untuk tidak mendekati ingatan
batasi jika swap jika tidak aktif.

Apakah ada cara dengan setiap restart saya tidak perlu mematikan swap seperti beberapa
perubahan file konfigurasi di instalasi yang ada?

Saya tidak perlu swap pada node yang berjalan di cluster.

Ini hanya aplikasi lain di laptop saya selain Kubernetes Local Dev
cluster yang membutuhkan swap untuk diaktifkan.

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

--
Michael Taufen
Google SWE

terima kasih @mtaufen

Untuk sistem yang mem-bootstrap cluster untuk Anda (seperti terraform), Anda mungkin perlu memodifikasi file layanan

Ini berhasil untuk saya

sudo sed -i '/kubelet-wrapper/a \ --fail-swap-on=false \\\' /etc/systemd/system/kubelet.service

Tidak mendukung swap sebagai default? Saya terkejut mendengarnya -- saya pikir Kubernetes sudah siap untuk prime time? Swap adalah salah satu fitur tersebut.

Ini tidak benar-benar opsional di sebagian besar kasus penggunaan terbuka - ini adalah bagaimana ekosistem Unix dirancang untuk berjalan, dengan VMM mengganti halaman yang tidak aktif.

Jika pilihannya adalah tidak ada swap atau tidak ada batas memori, saya akan memilih untuk tetap menukar setiap hari, dan hanya memutar lebih banyak host ketika saya memulai paging, dan saya akan tetap menghemat uang.

Adakah yang bisa menjelaskan -- apakah masalah dengan pengusiran memori hanya masalah jika Anda menggunakan batas memori dalam definisi pod, tetapi sebaliknya, tidak apa-apa?

Akan menyenangkan bekerja di dunia di mana saya memiliki kendali atas cara kerja memori aplikasi sehingga saya tidak perlu khawatir tentang penggunaan memori yang buruk, tetapi sebagian besar aplikasi memiliki banyak ruang memori yang tidak aktif.

Sejujurnya saya pikir langkah baru-baru ini untuk menjalankan server tanpa swap didorong oleh penyedia PaaS yang mencoba memaksa orang ke dalam instance memori yang lebih besar - sambil mengabaikan ~ 40 tahun desain manajemen memori. Kenyataannya adalah bahwa kernel sangat bagus untuk mengetahui halaman memori mana yang aktif atau tidak -- biarkan ia melakukan tugasnya.

Ini juga memiliki efek bahwa jika memori habis pada node, itu akan berpotensi menjadi benar-benar terkunci - membutuhkan restart node, bukan hanya memperlambat dan memulihkan beberapa saat kemudian.

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

Saya memiliki jumlah pembacaan disk yang tinggi di node cluster saya( K8s Version - v1.11.2 ). Mungkin karena menonaktifkan memori swap?

https://stackoverflow.com/questions/51988566/high-number-of-disk-reads-in-kubernetes-nodes

@srevenant Di dunia cluster, RAM node lain adalah swap baru. Karena itu, saya menjalankan dua instance K8 satu simpul di mana swap masuk akal. Tapi ini bukan kasus penggunaan khas K8.

@srevenant Saya sepenuhnya setuju dengan Anda, SWAP digunakan di Unix dan Linux secara default sejak mereka lahir, saya pikir saya tidak melihat aplikasi selama 15 tahun bekerja di Linux yang meminta SWAP dimatikan.
Masalah SWAP selalu aktif secara default ketika kami menginstal distro Linux apa pun, jadi saya harus menonaktifkannya sebelum saya menginstal K8 dan itu mengejutkan.
Kernel Linux tahu betul bagaimana mengelola SWAP untuk meningkatkan kinerja server khusus sementara ketika server akan mencapai batas RAM.
Apakah ini berarti saya harus mematikan SWAP agar K8 berfungsi dengan baik?

Saya tertarik untuk membuat ini berhasil, dan saya memiliki keterampilan dan sejumlah mesin untuk diuji. Jika saya ingin berkontribusi, di mana tempat terbaik untuk memulai?

@superdave tolong kumpulkan KEP di kubernetes/komunitas yang menjelaskan bagaimana Anda ingin swap didukung, dan tunjukkan ke sig-node. kami akan senang untuk memiliki bantuan Anda.

Saya mendukung untuk mengaktifkan swap di pod Kubernete dengan benar. tidak masuk akal untuk tidak memiliki swap, karena hampir semua container adalah instance Linux khusus, dan karenanya mendukung swap secara default.
Dapat dimengerti bahwa fitur ini rumit untuk diterapkan, tetapi sejak kapan hal itu menghentikan kami untuk bergerak maju?

Saya harus setuju bahwa masalah swap harus diselesaikan di Kubernetes karena menonaktifkan swap menyebabkan kegagalan Node ketika kehabisan memori pada node. Misalnya jika Anda memiliki 3 node pekerja (masing-masing 20GB ram) dan satu node turun karena batas ram tercapai, 2 node pekerja lainnya juga akan turun setelah mentransfer semua pod ke mereka dalam waktu itu.

Anda dapat mencegahnya dengan mengatur permintaan memori sesuai dengan yang sebenarnya
kebutuhan aplikasi.

Jika sepertiga dari memori aplikasi Anda berada pada 2 kali lipat
penyimpanan yang lebih lambat, apakah ia dapat melakukan pekerjaan yang bermanfaat?

Pada Rabu, 26 Sep 2018 pukul 6:51 pagi vasicvuk [email protected] menulis:

Saya harus setuju bahwa masalah swap harus diselesaikan di Kubernetes karena
menonaktifkan swap menyebabkan kegagalan Node saat kehabisan memori pada node. Untuk
contoh jika Anda memiliki 3 node pekerja (masing-masing 20GB ram) dan satu node berjalan
turun karena batas ram tercapai 2 node pekerja lain juga akan pergi
down setelah mentransfer semua pod ke mereka dalam waktu itu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-424604731 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAICBqZApBscFl5aNA4IcYvlxcvPA88Tks5ueyPlgaJpZM4PwnD5
.

@matthiasr Anda dapat melakukannya ketika Anda memiliki 10-50 layanan. Tetapi ketika Anda memiliki Cluster yang menjalankan lebih dari 200 layanan dan setengahnya dikerahkan menggunakan grafik Helm resmi tanpa ada permintaan memori di dalamnya, tangan Anda akan pasang surut.

Tapi, bukankah memori yang hilang meminta masalah untuk diatasi?

@matthiasr dalam banyak kasus memori pernah dipetakan ke proses hanya digunakan sekali atau tidak pernah benar-benar digunakan. Itu adalah kasus yang valid dan bukan kebocoran memori. Ketika Anda telah menukar halaman-halaman itu akhirnya ditukar dan mungkin tidak akan pernah ditukar lagi, namun Anda melepaskan ram cepat untuk penggunaan yang lebih baik.

Mematikan swap juga bukan cara yang baik untuk memastikan responsivitas. Kecuali Anda menyematkan file di memori (setidaknya kemampuan yang harus dimiliki K8 untuk executable), kernel akan tetap menukar setiap dan semua halaman yang didukung file sebagai respons terhadap tekanan memori, atau bahkan hanya karena kurangnya penggunaan.

Mengaktifkan swap tidak secara nyata mengubah perilaku kernel. Yang dilakukannya hanyalah menyediakan ruang untuk menukar halaman anonim, atau halaman yang dimodifikasi yang dimuat dari file yang dipetakan COW.

Anda tidak dapat mematikan swapping sepenuhnya, jadi K8s perlu bertahan keberadaannya terlepas dari apakah kasus khusus pertukaran memori anonim diaktifkan atau tidak.

Itu membuat ini menjadi bug: Anda gagal mendukung fitur kernel yang sebenarnya tidak dapat dimatikan.

@Baughn

kernel masih akan menukar setiap dan semua halaman yang didukung file sebagai respons terhadap tekanan memori, atau bahkan hanya karena kurangnya penggunaan. Mengaktifkan swap tidak secara nyata mengubah perilaku kernel.

Anda tidak dapat menonaktifkan swapping sepenuhnya,

Bisakah Anda memberikan beberapa referensi untuk ini sehingga saya bisa mendidik diri sendiri?

Kecuali Anda menyematkan file di memori (setidaknya kemampuan yang harus dimiliki K8 untuk executable),

Apa kemampuan yang Anda ingin k8s gunakan? Jika biner statis hanya menyalinnya ke tmpfs di pod akan membantu dengan latensi paging.

@adityakali ada pemikiran tentang dampak swap di kernel saat swap dimatikan?

Bisakah Anda memberikan beberapa referensi untuk ini sehingga saya bisa mendidik diri sendiri?

Seperti semua OS memori virtual modern, Linux meminta halaman yang dapat dieksekusi dari disk ke memori. Di bawah tekanan memori, kernel menukar kode yang sebenarnya dapat dieksekusi dari program Anda ke/dari disk seperti halaman memori lainnya ("swap out" hanyalah membuang karena hanya-baca, tetapi mekanismenya sama), dan mereka akan diambil kembali jika diperlukan lagi. Hal yang sama berlaku untuk hal-hal seperti konstanta string, yang biasanya di-mmapp hanya-baca dari bagian lain dari file yang dapat dieksekusi. File mmapped lainnya (umum untuk beban kerja tipe database) juga ditukar masuk+keluar ke file pendukung yang relevan (memerlukan penghapusan aktual jika telah dimodifikasi) sebagai respons terhadap tekanan memori. _only_ swapping yang Anda nonaktifkan dengan "menonaktifkan swap" adalah "memori anonim" - memori yang _not_ terkait dengan file (contoh terbaik adalah struktur data "tumpukan" dan "tumpukan").

Tentu saja ada banyak detail yang saya lewati dalam deskripsi di atas. Secara khusus, executable dapat "mengunci" bagian dari ruang memori mereka ke ram menggunakan mlock keluarga syscalls, melakukan hal-hal pintar melalui madvise() , menjadi rumit ketika halaman yang sama dibagikan oleh banyak proses (misalnya libc.so), dll. Saya khawatir saya tidak memiliki penunjuk yang lebih berguna untuk membaca lebih banyak selain halaman manual tersebut, atau hal-hal umum seperti buku teks atau sumber kernel linux/dokumen/milis.

Jadi, efek praktis dari hal di atas adalah ketika proses Anda mendekati batas memorinya, kernel akan dipaksa untuk mengeluarkan bagian _code_ dan konstanta dari ram. Saat berikutnya bit kode atau nilai konstan diperlukan, program akan berhenti sejenak, menunggu untuk mengambilnya kembali dari disk (dan mengeluarkan sesuatu yang lain). Jadi bahkan dengan "swap dinonaktifkan", Anda masih mendapatkan degradasi yang sama ketika set kerja Anda melebihi memori yang tersedia.

Sebelum orang membaca hal di atas dan mulai menelepon untuk mengunci semuanya ke dalam memori atau menyalin semuanya ke ramdrive sebagai bagian dari perburuan penyihir anti-swap, saya ingin mengulangi bahwa sumber daya sebenarnya yang menarik di sini adalah ukuran set yang berfungsi - bukan ukuran total . Sebuah program yang bekerja secara linier melalui gigabyte data dalam ram mungkin hanya bekerja pada jendela sempit data tersebut pada suatu waktu. Program hipotetis ini akan bekerja dengan baik dengan sejumlah besar swap dan batas ram kecil - dan akan sangat tidak efisien untuk mengunci semuanya ke ram asli. Seperti yang telah Anda pelajari dari penjelasan di atas, ini persis sama dengan program yang memiliki sejumlah besar _code_ tetapi hanya mengeksekusi sejumlah kecil pada saat tertentu.

Contoh dunia nyata pribadi terbaru saya tentang sesuatu seperti itu adalah menautkan executable kubernetes. Saat ini saya (ironisnya) tidak dapat mengkompilasi kubernetes di cluster kubernetes saya karena tahap tautan go memerlukan beberapa gigabyte memori virtual (anonim), meskipun set kerja jauh lebih kecil.

Untuk benar-benar mempelajari poin "tentang set kerja, bukan memori virtual", pertimbangkan sebuah program yang melakukan banyak I/O file biasa dan tidak ada hubungannya dengan mmap. Jika Anda memiliki ram yang cukup, kernel akan men-cache struktur direktori dan data file yang digunakan berulang kali dalam ram dan menghindari masuk ke disk, dan itu akan memungkinkan penulisan meledak ke ram sementara untuk mengoptimalkan penghapusan disk. Bahkan program "naif" seperti ini akan menurun dari kecepatan ram ke kecepatan disk tergantung pada ukuran set kerja vs ram yang tersedia. Ketika Anda menyematkan sesuatu ke ram secara tidak perlu (misalnya: menggunakan mlock atau menonaktifkan swap), Anda mencegah kernel menggunakan halaman ram fisik tersebut untuk sesuatu yang benar-benar berguna dan (jika Anda tidak memiliki cukup ram untuk perangkat kerja) Anda baru saja memindahkan disk I/O ke tempat yang lebih mahal.

@superdave : Saya juga tertarik untuk meningkatkan status-quo di sini. Harap sertakan saya jika Anda ingin sepasang mata lain untuk meninjau dokumen, atau tangan di keyboard.

Contoh dunia nyata pribadi terbaru saya tentang sesuatu seperti itu adalah menautkan executable kubernetes. Saat ini saya (ironisnya) tidak dapat mengkompilasi kubernetes di cluster kubernetes saya karena tahap tautan go memerlukan beberapa gigabyte memori virtual (anonim), meskipun set kerja jauh lebih kecil.

@superdave : Saya juga tertarik untuk meningkatkan status-quo di sini. Harap sertakan saya jika Anda ingin sepasang mata lain untuk meninjau dokumen, atau tangan di keyboard.

Ringkasan yang bagus dari masalah yang ada! Swap thrashing adalah masalah utama di sini, memang; itu sesuatu yang saya berharap untuk mengatasi secara rasional. Tampaknya bagi saya, meskipun saya belum benar-benar punya waktu untuk cukup memikirkannya, bahwa semacam metrik aktivitas bertukar (pagein/keluar selama jangka waktu tertentu, mungkin dengan aturan persentil untuk menghindari menerkam terlalu bersemangat jika a proses tiba-tiba melonjak sementara) mungkin merupakan cara yang baik untuk mengevaluasi hal-hal untuk penggusuran ketika swap diaktifkan. Ada sejumlah metrik, dan saya kira kami ingin menawarkan banyak tombol untuk diputar-putar serta hati-hati mengevaluasi kemungkinan kasus penggunaan. Saya juga menduga kemampuan pod instrumen untuk interaksi memori virtual akan membantu orang menyetel lebih baik; Saya tidak cukup akrab dengan apa yang sudah ditawarkan untuk mengatakan apa yang ada sekarang, tapi saya rasa saya akan mencari tahu.

Saya juga tidak cukup akrab dengan kontrol yang harus kita ketahui seberapa baik kita dapat mengontrol perilaku swapping di pod/kontainer individu; akan sangat membantu untuk dapat "memperbaiki" hal-hal untuk retensi atau pertukaran, tetapi pengembang jelas selalu bebas untuk mencoba mlock() ketika mereka benar-benar perlu menjamin hal-hal akan tetap ada.

Bagaimanapun, ya, saya benar-benar ingin bergerak maju dalam hal ini. Saya telah kebanjiran di tempat kerja akhir-akhir ini (menangani beberapa masalah OOM dengan layanan mikro kami sendiri di bawah k8s yang akan diuntungkan karena dapat bertukar di bawah beban karena 99% dari waktu mereka tidak memerlukan gigs RAM kecuali seseorang membuat yang sangat besar permintaan), tapi jangan ragu untuk terus memberitahu saya tentang hal itu. Saya belum pernah berpartisipasi dalam proses KEP sebelumnya, jadi saya akan cukup ramah dalam hal itu, tetapi hari ini saya bekerja jauh lebih baik berdasarkan interupsi daripada polling. :-)

Saya ingin menunjukkan bahwa zram bekerja dengan membonceng swap. Jika tidak ada swap pada k8, maka tidak ada kompresi memori, yang merupakan sesuatu yang sebagian besar non-Linux OS telah aktifkan secara default (isyarat Windows, MacOS).

Kami memiliki instance Ubuntu di k8 yang menjalankan pekerjaan batch besar setiap malam yang menghabiskan banyak memori. Karena beban kerja tidak ditentukan sebelumnya, kami terpaksa (mahal) mengalokasikan 16GB ke node terlepas dari konsumsi memori aktualnya untuk menghindari OOM. Dengan kompresi memori di server dev lokal kami, pekerjaan hanya mencapai 3GB. Jika tidak pada siang hari, memori yang dibutuhkan hanya 1GB. Melarang swap dan dengan demikian kompresi memori adalah langkah yang cukup konyol.

Saya pikir perhatian utama di sini mungkin adalah isolasi. Sebuah mesin biasa dapat menampung satu ton pod, dan jika memori menjadi sempit, mereka dapat mulai bertukar dan benar-benar menghancurkan kinerja satu sama lain. Jika tidak ada swap, isolasi jauh lebih mudah.

Saya pikir perhatian utama di sini mungkin adalah isolasi. Sebuah mesin biasa dapat menampung satu ton pod, dan jika memori menjadi sempit, mereka dapat mulai bertukar dan benar-benar menghancurkan kinerja satu sama lain. Jika tidak ada swap, isolasi jauh lebih mudah.

Tetapi seperti yang dijelaskan sebelumnya, menonaktifkan swap tidak berarti apa-apa bagi kita di sini. Faktanya, karena ini meningkatkan tekanan memori secara keseluruhan, itu mungkin memaksa kernel untuk menjatuhkan bagian dari set kerja ketika itu dapat menukar data yang tidak digunakan -- sehingga membuat situasi menjadi lebih buruk .

Mengaktifkan swap, dengan sendirinya, sebenarnya akan meningkatkan isolasi.

Tapi itu membeli Anda banyak, jika Anda menjalankan sesuatu dengan cara yang seharusnya (dan cara Google menjalankan sesuatu di Borg): semua wadah harus menentukan batas memori atas. Borg memanfaatkan infra Google dan mempelajari batasannya jika Anda menginginkannya (dari penggunaan sumber daya sebelumnya dan perilaku OOM), tetapi tetap ada batasannya.

Saya sebenarnya agak bingung bahwa orang-orang K8S mengizinkan batas memori menjadi opsional. Tidak seperti CPU, tekanan memori memiliki efek yang sangat non-linear pada kinerja sistem karena siapa pun yang telah melihat sistem benar-benar terkunci karena swapping akan membuktikannya. Seharusnya benar-benar membutuhkannya secara default, dan memberi Anda peringatan jika Anda memilih untuk menonaktifkannya.

Tapi itu membeli Anda banyak, jika Anda menjalankan sesuatu dengan cara yang seharusnya (dan cara Google menjalankan sesuatu di Borg): semua wadah harus menentukan batas memori atas. Borg memanfaatkan infra Google dan mempelajari batasannya jika Anda menginginkannya (dari penggunaan sumber daya sebelumnya dan perilaku OOM), tetapi tetap ada batasannya.

Saya sebenarnya agak bingung bahwa orang-orang K8S mengizinkan batas memori menjadi opsional. Tidak seperti CPU, tekanan memori memiliki efek yang sangat non-linear pada kinerja sistem karena siapa pun yang telah melihat sistem benar-benar terkunci karena swapping akan membuktikannya. Seharusnya benar-benar membutuhkannya secara default, dan memberi Anda peringatan jika Anda memilih untuk menonaktifkannya.

Saya pikir masalah yang gagal diatasi adalah bahwa batas atas adalah variabel dan tidak selalu diketahui untuk beberapa proses. Masalah yang saya tangani secara khusus berfokus pada penggunaan k8s untuk mengelola node penyaji model 3d. Bergantung pada aset untuk model dan adegan yang dirender, jumlah ram yang dibutuhkan dapat sedikit berbeda, dan sementara sebagian besar render akan kecil, fakta bahwa _some_ bisa sangat besar berarti bahwa permintaan dan batasan kami harus mencadangkan lebih banyak memori daripada yang sebenarnya kita butuhkan 90% dari waktu untuk menghindari OOM, daripada pod yang terkadang melebihi batas yang dikonfigurasi dan dapat tumpah ke ruang swap.

Ya, dan dalam hal ini Anda kemudian akan menetapkan batas atas Anda ke "Tidak Ada" atau sesuatu seperti itu. Maksud saya adalah, seharusnya tidak menjadi default. Mengaturnya ke nol sepenuhnya mengalahkan segala jenis penjadwalan beban kerja cerdas, karena master tidak mengetahui ukuran "item" (pekerjaan) yang akan dimasukkan ke dalam "ransel" (kubelet).

Masalahnya di sini bukanlah bahwa pekerjaan Anda akan tumpah untuk ditukar, tetapi semua pekerjaan lain yang berjalan pada simpul itu juga akan terjadi. Dan beberapa (kebanyakan?) dari mereka tidak akan menyukainya sama sekali.

Program di Borg ditulis untuk dapat dihentikan (killable, bagi mereka yang tidak terbiasa dengan jargon) kapan saja tanpa mempengaruhi integritas data. Ini sebenarnya sesuatu yang tidak banyak saya lihat di luar Google, dan mengakui potensi kematian mendadak program Anda mengarah pada penulisan perangkat lunak yang jauh lebih andal. Tapi saya ngelantur.

Sistem yang dibangun dengan program seperti itu akan lebih memilih program-program tersebut untuk mati dan bereinkarnasi di tempat lain di sel (klaster Borg), daripada terus menderita pada simpul yang kelebihan permintaan. Latensi ekor bisa sangat bermasalah jika tidak, terutama bila jumlah tugas dalam suatu pekerjaan besar.

Jangan salah paham, saya tidak mengatakan ini adalah satu-satunya cara yang "benar" untuk menjalankan sesuatu. Saya hanya mencoba menjelaskan kemungkinan alasan yang masuk ke dalam desain.

Penafian: Saya adalah mantan Googler yang menggunakan Borg untuk menjalankan beberapa layanan yang sangat besar, jadi saya mengetahuinya dengan baik, dan pengetahuan itu sebagian besar diterjemahkan ke Kubernetes. Saat ini saya tidak bersama Google, dan apa pun yang saya tulis di sini adalah pemikiran saya sendiri.

@1e100 : Anda menggabungkan ukuran "total VM" dengan ukuran "set kerja". Beban kerja perlu dijadwalkan berdasarkan ukuran _working set_, dan program akan menurun setelah ukuran _working set_ terlampaui (dengan asumsi ada cukup total swap yang tersedia). Alasan yang Anda nyatakan di atas juga bergantung pada asumsi yang salah bahwa swapping (dan pengorbanan degradasi ram<->I/O lainnya) tidak akan terjadi hanya karena swap dinonaktifkan.

(Saya juga mantan Google-SRE, dan saya setuju bahwa mitos-mitos umum Google ini hampir pasti yang membuat keputusan bahwa tidak apa-apa (atau bahkan diinginkan) untuk menonaktifkan swap pada k8s juga. Saya melihat beberapa tim Google pergi melalui pembelajaran bahwa menonaktifkan swap tidak menonaktifkan swapping, dan pemborosan memori agregat yang mengikuti dari hanya menggambarkan batas "keras" (oom-kill) untuk memori - ini adalah beberapa hal yang ingin saya tingkatkan dengan k8s. adalah sejumlah tombol cgroup/swap merdu yang tersedia sekarang yang tidak kami miliki ketika model sumber daya borg awalnya dirancang, dan saya yakin kami dapat mencapai hasil yang diinginkan tanpa pendekatan membuang-bayi-out-with-bathwater seperti itu Saya juga akan mencatat bahwa Google tradeoff _sering_ menjadi kurang efisien rata-rata untuk mencapai waktu kasus terburuk yang lebih baik/terkenal (yaitu: perilaku waktu nyata) dan bahwa ini sering _bukan_ pilihan yang diinginkan di luar Google - lebih kecil/ host lebih sedikit, SLO lebih santai, anggaran lebih rendah, definisi lebih buruk pekerjaan batch ed, lebih banyak penggunaan bahasa tidak efisien heap yang tidak dikompilasi, dll.)

Pertukaran memori anonim tidak akan terjadi. Memori apa pun yang dipetakan (termasuk kode program dan data) dapat dan akan tetap bertukar jika ada tekanan memori, itu sebabnya saya menyarankan bahwa batas RAM harus diwajibkan secara default: untuk mengurangi kemungkinan tekanan memori. Untuk beban kerja yang membutuhkan jaminan yang lebih ketat, ada juga nilai mlockall() dan swappiness rendah.

Sebagai mantan Google SRE, Anda tidak dapat membantah bahwa tidak menentukan batas RAM atas, atau mengaktifkan tugas untuk menukar apa pun yang mereka inginkan secara spontan adalah hal yang baik, kecuali jika Anda hanya ingin menjadi pelawan. Bertukar file yang dipetakan memori sudah cukup buruk, memasukkan lebih banyak tebing kinerja potensial ke dalam campuran bukanlah hal yang baik.

Ini adalah lingkungan bersama berdasarkan desain, dan Anda ingin menghilangkan cara program membuat kinerja satu sama lain tidak dapat diprediksi, bukan menambahkan yang baru. Seperti yang dikatakan Google SRE "harapan bukanlah strategi". Swap thrashing adalah cara termudah yang saya tahu untuk membuat mesin Linux terkunci sepenuhnya dan tidak dapat dipulihkan, bahkan jika Anda menukar ke SSD. Itu tidak baik bahkan jika Anda hanya menjalankan satu beban kerja di mesin, apalagi beberapa lusin. Kegagalan terkait bisa sangat menyakitkan di cluster yang lebih kecil dengan sedikit tugas/pod.

Seseorang dapat mengabaikan pemeriksaan swap bahkan hari ini jika diinginkan, tetapi dengan pemahaman eksplisit bahwa semua taruhan dibatalkan dalam kasus itu.

Yap, sangat setuju bahwa kita perlu memiliki "ukuran" yang kita gunakan untuk penjadwalan dan untuk menghindari overcommit (tidak disengaja). Dan kami juga ingin menghindari thrash VM global, karena Linux memiliki waktu yang buruk untuk memulihkannya. Apa yang kami _do_ inginkan adalah agar kernel _dapat_ menukar memori anonim dan menggunakan kembali ram itu untuk sesuatu yang lain, di mana itu masuk akal, karena ini benar-benar lebih unggul daripada sistem yang tidak dapat melakukan itu. Idealnya kami ingin mengizinkan wadah individu untuk dapat mengelola pengorbanan ram/disk, dan menghadapi konsekuensi dari pilihan sumber daya mereka sendiri (over/underallocated) dengan efek minimal pada wadah lain.

Hanya untuk menunjukkan ke mana saya akan pergi dengan ini, proposal strawman saya saat ini adalah:

• Metafora adalah bahwa setiap wadah berperilaku seperti itu pada mesin dengan sendirinya dengan jumlah ram tertentu (diberikan oleh limits.memory ) dan swap.
• Sama seperti sumber daya lainnya: jadwal berdasarkan requests.memory , terapkan batas berdasarkan limits.memory . "Memori" dalam hal ini berarti "ram" - penggunaan swap gratis.
• Khususnya k8s requests.memory -> cgroup memory.low (diperkecil oleh faktor overcommit); k8s limits.memory -> cgroup memory.high .
• Jika sebuah wadah melebihi batas memori yang dikonfigurasi, maka ia mulai menukar - _terlepas dari jumlah ram gratis yang tersedia. Berkat cgroups, ini _bukan_ hanya penggunaan VM, tetapi juga termasuk cache blok, buffer soket, dll yang dikaitkan dengan wadah. Ini mencegah kami menempatkan tekanan memori pada wadah lain (atau proses host). Saat mencari halaman yang akan dikeluarkan, kernel akan mencari container yang melebihi ukuran permintaan memorinya.
• Memperkenalkan batas lunak kubelet total-swap-penggunaan di mana k8s akan berhenti menjadwalkan pod baru ke host (persis seperti "sistem file bersama" lainnya seperti imagefs).
• Jika kita mencapai hard limit total-swap-usage, maka mulailah mengeluarkan pod berdasarkan qos-class/priority dan ukuran VM di atas "requests" (persis seperti "shared filesystem" lainnya seperti imagefs).
• Jika sebuah wadah sangat melebihi set kerjanya ( requests.memory ) maka ia mungkin thrash (jika juga melebihi limits.memory atau tidak ada cukup ram yang tersedia di host). Kami secara eksplisit _tidak_ melakukan apa pun tentang hal ini melalui mekanisme sumber daya. Jika container melakukan swap-thrashing maka container tersebut (mungkin) akan gagal dalam pemeriksaan liveness/readiness dan dimatikan melalui mekanisme tersebut (yaitu: swap-thrashing tidak masalah jika kita tidak memiliki SLA responsif yang dikonfigurasi).

Hasil akhirnya adalah admin bertanggung jawab untuk mengonfigurasi swap yang "cukup" di setiap sistem. Aplikasi harus mengonfigurasi limits.memory dengan _max_ ram yang ingin mereka gunakan, dan requests.memory dengan set kerja yang diinginkan (termasuk buffer kernel, dll). Seperti sumber daya lainnya, kelas qos dijamin (batas==permintaan), dapat meledak (batas tidak ditentukan atau !=permintaan), upaya terbaik (tanpa batas atau permintaan) masih berlaku. Secara khusus, ini mendorong proses yang dapat meledak untuk menyatakan dekat dengan set kerja yang diinginkan (tidak ada buffer keamanan yang besar), yang memungkinkan alokasi yang efisien (idealnya tepat 100% dari ram yang dialokasikan untuk set kerja) dan memberikan penurunan kinerja yang mulus ketika kontainer melebihi itu - sama seperti sumber daya "memaafkan" lainnya seperti cpu.

Saya pikir ini dapat diimplementasikan dalam cgroup Linux, mengatasi masalah isolasi, melanjutkan preseden konseptual yang ditetapkan oleh sumber daya k8s lainnya, dan menurunkan perilaku yang ada ketika swap dinonaktifkan (membuat migrasi menjadi mudah). Satu-satunya pertanyaan terbuka yang saya miliki adalah apakah ini _sudah_ apa yang diterapkan (dikurangi batas lunak/keras kubelet "swapfs") - Saya harus pergi dan membaca kode cgroups kubelet/CRI yang sebenarnya sebelum saya dapat menulis proposal dan item tindakan yang konkret .

Komentar/diskusi di atas mungkin tidak sesuai dalam masalah github ini (ini adalah forum diskusi yang buruk). Jika ada sesuatu yang sangat salah dengan hal di atas, saya akan menyambut umpan balik kepada guslees tentang k8s slack, jika tidak, saya akan menulis dokumen yang tepat dan melalui diskusi desain yang biasa di beberapa titik.

Saya merekomendasikan untuk menulis dokumen formal sehingga kita dapat memiliki forum diskusi yang lebih baik.

Sepakat. Saya senang membantu menulis KEP, karena saya memiliki beberapa ide pasti untuk ini, tetapi saya belum pernah melakukannya sebelumnya dan lebih suka memiliki tangan yang lebih berpengalaman di kemudi.

Tetapi, juga, saya tidak memiliki bandwidth untuk mengikuti saluran Slack di waktu luang saya; jika ada metode koordinasi yang lebih asinkron, beri tahu saya.

Hanya untuk menjaga semuanya tetap hidup: Saya masih sangat tertarik untuk mengerjakan KEP dan/atau implementasi untuk ini; setelah semuanya beres (saya memiliki lokakarya untuk dipersiapkan untuk akhir pekan depan), saya akan mencoba dan bergabung dengan saluran Slack.

Hai apakah ada diskusi publik tentang masalah ini yang terjadi saat ini? (Kelonggaran k8s tidak terbuka untuk semua orang saat ini, dan saya berasumsi tidak akan terbuka untuk beberapa waktu).

@leonaves tidak ada diskusi tentang kendur yang terjadi saat ini AFAIK. komentar terakhir dari @guslees adalah yang terakhir dari diskusi. Perhatikan bahwa harus ada KEP dengan detail di repo kubernetes/enhancements untuk memulai dan mungkin juga utas milis.

Tampaknya ada ujung terowongan untuk pembukaan kembali kendur juga segera. menyilangkan jariku.

Ternyata, saya masih belum memiliki mental bandwidth untuk bergabung dengan saluran Slack lainnya. Saya masih akan bekerja sama dalam hal ini melalui email.

Solusi bagi mereka yang benar-benar ingin bertukar. Jika kamu

• mulai kubelet dengan --fail-swap-on=false
• tambahkan swap ke node Anda
• wadah yang _not_ menentukan persyaratan memori maka secara default akan dapat menggunakan semua memori mesin, termasuk swap.

Itulah yang kami lakukan. Atau setidaknya, saya cukup yakin, saya tidak benar-benar menerapkannya secara pribadi, tetapi itulah yang saya kumpulkan.

Ini mungkin hanya benar-benar menjadi strategi yang layak jika tidak ada wadah Anda yang pernah menentukan persyaratan memori eksplisit ...

Apakah metode ini tidak berfungsi lagi!? Saya mengaktifkan swap dan menggunakan pod tanpa pengaturan memori, dan mendapatkan wadah ini

$ docker inspect <dockerID> | grep Memory
            "Memory": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1

MemorySwap adalah "0", yang berarti wadah ini tidak dapat mengakses swap :(

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

/remove-lifecycle basi.

/hapus siklus hidup basi

Akan menjatuhkan ini di sini sebagai referensi lain untuk pembaca masalah ini: https://chrisdown.name/2018/01/02/in-defence-of-swap.html

Terkait dengan: https://serverfault.com/questions/881517/why-disable-swap-on-kubernetes

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

fitur ini sangat dibutuhkan dalam beberapa kasus penggunaan. saat ini kami menggunakan k8s untuk pembelajaran mesin dan terkadang kami perlu memuat model besar dalam memori (dalam kasus kami terkadang 500MB per permintaan api!), dan batas memori fisik menyebabkan masalah serius. Penskalaan akan berhasil dari POV teknis tetapi biayanya akan membengkak, Jika kami memiliki memori virtual sebagai opsi, itu akan sangat bagus.

Adakah kemungkinan tiket ini kembali ke peta jalan lagi?

Kedengarannya seperti kasus untuk mmap.

Saya juga sangat tertarik dengan fitur ini. Apakah ada berita tentang ini?

Saya akan senang untuk mulai melihat ini ketika saya punya waktu, yang persediaannya terbatas sekarang, tetapi akan lebih baik untuk memiliki satu atau dua kasus kanonik yang memperburuk masalah sehingga dapat dicirikan lebih lengkap (di luar "itu mulai meronta-ronta dan semuanya menjadi neraka") dan pendekatan dan perbaikan pamungkas divalidasi.

Setiap solusi prospektif juga harus mempertimbangkan implikasi keamanan dari swap. Ini, jelas, berlaku untuk semua yang berjalan di lingkungan Unix, tetapi jika orang telah terbiasa menjalankan pod k8s dengan jaminan semu tanpa swap dan menjadi malas tentang disiplin memori, ini bisa menjadi kejutan yang cukup kasar jika diaktifkan oleh bawaan.

akan lebih baik untuk memiliki satu atau dua kasus kanonik yang memperburuk masalah sehingga dapat dikarakterisasi lebih lengkap

Kedengarannya seperti KEP .

Setiap solusi prospektif juga harus mempertimbangkan implikasi keamanan dari swap. Ini, jelas, berlaku untuk semua yang berjalan di lingkungan Unix, tetapi jika orang telah terbiasa menjalankan pod k8s dengan jaminan semu tanpa swap dan menjadi malas tentang disiplin memori, ini bisa menjadi kejutan yang cukup kasar jika diaktifkan oleh bawaan.

Logika itu akan berlaku untuk semua proses yang berjalan dalam wadah campuran, terlepas dari apakah Kubernetes sedang digunakan atau tidak.

Sepakat! Tetapi Docker sudah secara eksplisit mendukung berjalan dengan swap. Kubernetes secara eksplisit tidak (meskipun Anda dapat memaksanya). Pendapat saya adalah bahwa itu setidaknya harus dipanggil, karena itu tidak ada dalam model ancaman semua orang, terutama jika mereka tidak harus memikirkannya sebelumnya.

Juga ya, @sftim , memang begitu. :-) Saya pikir apa yang saya katakan adalah bahwa saya ingin menulis/berkontribusi ke KEP, tetapi saya ingin melihat satu atau dua kasus uji minimal yang andal melatih masalah pada sistem pengujian yang diberikan sebelum menjelajah begitu bahwa kita dapat yakin bahwa kita memecahkan masalah yang tepat.

@superdave kasus uji apa yang ada dalam pikiran Anda?

Inilah tes sepele:

1. Siapkan cluster dengan 1 node, 16 GiB RAM, dan 64GiB pagefile.
2. Cobalah untuk menjadwalkan 20 Pod, masing-masing dengan permintaan memori 1GiB dan batas memori 1GiB.
3. Perhatikan bahwa tidak semua jadwal.

Ini yang lain:

1. Siapkan 6 mesin, masing-masing dengan 16 GiB RAM dan 64GiB pagefile.
2. Coba gunakan kubeadm dengan opsi default untuk mengonfigurasi mesin ini sebagai cluster Kubernetes.
3. Perhatikan bahwa kubeadm tidak senang dengan swap yang digunakan.

Ada perubahan besar untuk SSD pada platform cloud yang paling terhormat sekarang dan mengingat Linux telah mendedikasikan pengoptimalan untuk swapping pada SSD https://lwn.net/Articles/704478/ dengan kemungkinan kompresi tambahan, situasi ini membuat peluang baru untuk memanfaatkan swap sebagai sumber daya yang dapat diprediksi dan cepat untuk RAM tambahan jika terjadi tekanan memori.
Swap yang dinonaktifkan menjadi sumber daya yang terbuang dengan cara yang sama seperti RAM yang tidak digunakan akan terbuang sia-sia jika tidak digunakan untuk buffer I/O.

@superdave

Sepakat! Tetapi Docker sudah secara eksplisit mendukung berjalan dengan swap. Kubernetes secara eksplisit tidak (meskipun Anda dapat memaksanya). Pendapat saya adalah bahwa itu setidaknya harus dipanggil, karena itu tidak ada dalam model ancaman semua orang, terutama jika mereka tidak harus memikirkannya sebelumnya.

Dalam hal ini akan adil untuk mengasumsikan kubelet akan mlock() ruang memorinya dan menetapkan prioritas pembunuhan OOM rendah untuk menghindari ditukar atau OOM terbunuh, dan menjalankan semua wadah di cgroups dengan swapiness diatur ke 0 secara default. Jika seseorang ingin mendapatkan keuntungan dari pertukaran formulir, ia dapat ikut serta dengan menggunakan opsi yaitu enableSwapiness: 50 untuk wadah tertentu dalam pod.
Tidak ada kejutan, termasuk baterai.

@sftim Itu akan menunjukkan bahwa a) Kubelet tidak ingin menjadwalkan wadah dan b) Kubelet tidak akan berjalan dengan swap aktif secara default. Yang ingin saya latih adalah situasi di bagian atas utas, oleh @derekwaynecarr :

Dukungan untuk swap tidak sepele. Pod yang dijamin seharusnya tidak pernah membutuhkan swap. Pod yang dapat meledak harus memenuhi permintaannya tanpa memerlukan swap. Pod BestEffort tidak memiliki jaminan. Kubelet saat ini tidak memiliki kecerdasan untuk memberikan jumlah yang tepat dari perilaku yang dapat diprediksi di sini di seluruh pod.

Kami membahas topik ini di sumber daya mgmt tatap muka awal tahun ini. Kami tidak terlalu tertarik untuk mengatasi hal ini dalam waktu dekat dibandingkan dengan keuntungan yang dapat direalisasikan. Kami lebih memilih untuk meningkatkan keandalan seputar deteksi tekanan, dan mengoptimalkan masalah seputar latensi sebelum mencoba mengoptimalkan pertukaran, tetapi jika ini adalah prioritas yang lebih tinggi bagi Anda, kami akan sangat membantu Anda.

Dan juga tepat di bawahnya, dari @matthiasr :

Ada lebih banyak konteks dalam diskusi di sini: #7294 – memiliki swap yang tersedia memiliki interaksi yang sangat aneh dan buruk dengan batas memori. Misalnya, wadah yang mencapai batas memorinya akan _then_ mulai tumpah ke swap (ini tampaknya telah diperbaiki sejak f4edaf2 – mereka tidak akan diizinkan untuk menggunakan swap apa pun, baik itu ada atau tidak).

Keduanya memberikan pandangan yang baik tentang masalah yang sudah terlihat, tetapi akan lebih baik untuk memahami skenario yang diketahui dan dapat direproduksi yang dapat memperburuk masalah. Saya bisa membuatnya sendiri, tetapi jika orang lain sudah melakukannya, itu adalah roda yang saya tidak keberatan untuk tidak menciptakan kembali.

@superdave

Sepakat! Tetapi Docker sudah secara eksplisit mendukung berjalan dengan swap. Kubernetes secara eksplisit tidak (meskipun Anda dapat memaksanya). Pendapat saya adalah bahwa itu setidaknya harus dipanggil, karena itu tidak ada dalam model ancaman semua orang, terutama jika mereka tidak harus memikirkannya sebelumnya.

Dalam hal ini akan adil untuk mengasumsikan kubelet akan mlock() ruang memorinya dan menetapkan prioritas pembunuhan OOM rendah untuk menghindari ditukar atau OOM terbunuh, dan menjalankan semua wadah di cgroups dengan swapiness diatur ke 0 secara default. Jika seseorang ingin mendapatkan keuntungan dari pertukaran formulir, ia dapat ikut serta dengan menggunakan opsi yaitu enableSwapiness: 50 untuk wadah tertentu dalam pod.
Tidak ada kejutan, termasuk baterai.

Saya pikir saya setuju dengan semuanya di sini. Default ke perilaku saat ini untuk menghindari kejutan yang tidak menyenangkan.

Berikut adalah contoh bagaimana tampilan aplikasi sederhana, di mana untuk beberapa alasan sebagian besar memori dialokasikan tetapi tidak pernah diakses lagi. Setelah semua memori yang tersedia terisi, aplikasi akan hang atau jatuh ke dalam lingkaran tanpa akhir yang pada dasarnya memblokir sumber daya atau memaksa keluar dari pembunuh memori:

#include <iostream>
#include <vector>
#include <unistd.h>
int main() {
  std::vector<int> data;
  try
    {
        while(true) { data.resize(data.size() + 200); };
    }
    catch (const std::bad_alloc& ex)
    {
        std::cerr << "Now we filled up memory, so assume we never access that stuff again and just moved on, or we're stuck in an endless loop of some sort...";
        while(true) { usleep(20000); };
    }
  return 0;
}

Solusi bagi mereka yang benar-benar ingin bertukar. Jika kamu

• mulai kubelet dengan --fail-swap-on=false
• tambahkan swap ke node Anda
• wadah yang _not_ menentukan persyaratan memori maka secara default akan dapat menggunakan semua memori mesin, termasuk swap.

Itulah yang kami lakukan. Atau setidaknya, saya cukup yakin, saya tidak benar-benar menerapkannya secara pribadi, tetapi itulah yang saya kumpulkan.

Ini mungkin hanya benar-benar menjadi strategi yang layak jika tidak ada wadah Anda yang pernah menentukan persyaratan memori eksplisit ...

Hai @hjwp , terima kasih atas informasinya. Itu sangat membantu!

Bisakah saya mengajukan pertanyaan setelah ini?

Setelah mengatur semuanya seperti yang Anda katakan, apakah ada cara untuk membatasi penggunaan penggunaan memori swap oleh wadah?

Saya sedang berpikir untuk menyetel params --memory-swap dari Docker
https://docs.docker.com/config/containers/resource_constraints/# --memory-swap-details
Saat ini, wadah saya tidak memiliki batasan penggunaan swap ( "MemorySwap": -1 )

sudo docker inspect 482d70f73c7c | grep Memory
            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

Tetapi saya tidak dapat menemukan param ini terbuka di k8s.

Omong-omong, apakah batas memori pod juga akan menahan penggunaan swap?

Pengaturan terkait vm saya

vm.overcommit_kbytes = 0
vm.overcommit_memory = 1
vm.overcommit_ratio = 50
vm.swappiness = 20
vm.vfs_cache_pressure = 1000

Terima kasih!

@ pai911 Saya tidak berpikir itu mungkin,

saat ini, CRI tidak mendukung itu, lihat ini , tidak ada opsi seperti --memory-swap di buruh pelabuhan

ini adalah batasan CRI, spesifikasi OCI mendukung opsi ini , tetapi tidak diekspor ke lapisan CRI

satu solusi yang mungkin (secara teoritis) adalah membuat DaemonSet yang diistimewakan yang selanjutnya membaca data anotasi dari pod, dan kemudian DaemonSet mengedit nilai cgroup secara manual

grup c

Hai @win-t ,

Terima kasih atas masukannya!

Jadi untuk saat ini, opsi ini hanya untuk penggunaan internal?

Apakah Anda tahu nilai cgroup apa yang dipetakan ke opsi --memory-swap ini?

Jadi untuk saat ini, opsi ini hanya untuk penggunaan internal?

Ya, Anda tidak dapat menyetel opsi ini, karena opsi ini tidak diekspos di k8s

btw, MemorySwap dalam pemeriksaan buruh pelabuhan harus sama dengan Memory menurut this , saya tidak tahu bagaimana Anda bisa mendapatkan -1 di pemeriksaan buruh pelabuhan Anda

Apakah Anda tahu nilai cgroup apa yang dipetakan ke opsi --memory-swap ini?

• --memory di peta buruh pelabuhan ke memory.limit_in_bytes di cgroup v1
• --memory-swap di peta buruh pelabuhan ke memory.memsw.limit_in_bytes di cgroup v1

@win-t Terima kasih banyak!

Saya menggunakan versi berikut

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"1bea6c00a7055edef03f1d4bb58b773fa8917f11", GitTreeState:"clean", BuildDate:"2020-02-11T20:05:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

dan saya melihat sejarahnya. tampaknya perbaikan telah ditambahkan dalam komit ini

Mungkin itu tidak termasuk dalam versi yang saya jalankan?

Jadi untuk saat ini, opsi ini hanya untuk penggunaan internal?

Ya, Anda tidak dapat menyetel opsi ini, karena opsi ini tidak diekspos di k8s

btw, MemorySwap dalam pemeriksaan buruh pelabuhan harus sama dengan Memory menurut this , saya tidak tahu bagaimana Anda bisa mendapatkan -1 di pemeriksaan buruh pelabuhan Anda

Apakah Anda tahu nilai cgroup apa yang dipetakan ke opsi --memory-swap ini?

• --memory di peta buruh pelabuhan ke memory.limit_in_bytes di cgroup v1
• --memory-swap di peta buruh pelabuhan ke memory.memsw.limit_in_bytes di cgroup v1

Ini aneh.

Saya menggunakan kops + Debian, dan pemeriksaan Docker menunjukkan tidak ada batasan pada memori Swap
(Info inspeksi Docker yang saya posting sebelumnya)

Tapi kemudian saya beralih ke gambar Amazon Linux, dan inilah yang saya dapatkan

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

Saya akan melakukan penyelidikan lebih lanjut dan melihat apakah ini bug

Jadi untuk saat ini, opsi ini hanya untuk penggunaan internal?

Ya, Anda tidak dapat menyetel opsi ini, karena opsi ini tidak diekspos di k8s
btw, MemorySwap dalam pemeriksaan buruh pelabuhan harus sama dengan Memory menurut this , saya tidak tahu bagaimana Anda bisa mendapatkan -1 di pemeriksaan buruh pelabuhan Anda

Apakah Anda tahu nilai cgroup apa yang dipetakan ke opsi --memory-swap ini?

• --memory di peta buruh pelabuhan ke memory.limit_in_bytes di cgroup v1
• --memory-swap di peta buruh pelabuhan ke memory.memsw.limit_in_bytes di cgroup v1

Ini aneh.

Saya menggunakan kops + Debian, dan pemeriksaan Docker menunjukkan tidak ada batasan pada memori Swap
(Info inspeksi Docker yang saya posting sebelumnya)

Tapi kemudian saya beralih ke gambar Amazon Linux, dan inilah yang saya dapatkan

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

Saya akan melakukan penyelidikan lebih lanjut dan melihat apakah ini bug

Saya sekarang dapat mereproduksi masalah yang ada di gambar Debian resmi oleh kops

Tampaknya gambar resmi kops ini akan membuat memori swap tidak terbatas
kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17

Langkah-langkah reproduksi:

Grup instance kops saya didefinisikan sebagai berikut:

apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
  creationTimestamp: "2020-03-12T06:33:09Z"
  generation: 5
  labels:
    kops.k8s.io/cluster: solrcluster.k8s.local
  name: node-2
spec:
  additionalUserData:
  - content: |
      #!/bin/sh
      sudo cp /etc/fstab /etc/fstab.bak
      sudo mkfs -t ext4 /dev/nvme1n1
      sudo mkdir /data
      sudo mount /dev/nvme1n1 /data
      echo '/dev/nvme1n1       /data   ext4    defaults,nofail        0       2' | sudo tee -a /etc/fstab
      sudo fallocate -l 2G /data/swapfile
      sudo chmod 600 /data/swapfile
      sudo mkswap /data/swapfile
      sudo swapon /data/swapfile
      echo '/data/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
      sudo sysctl vm.swappiness=10
      sudo sysctl vm.overcommit_memory=1
      echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
      echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf
    name: myscript.sh
    type: text/x-shellscript
  image: kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  instanceProtection: true
  kubelet:
    failSwapOn: false
  machineType: t3.micro

Langkah:

1. Setelah cluster aktif & berjalan.

2. Terapkan Solr Helm Chart dengan pengaturan sumber daya berikut

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** Pod lain juga harus berfungsi

1. Daftar wadah untuk menemukan id wadah
   sudo docker container ls

2. Periksa parameter memori container
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

Haruskah saya mengirimkan masalah ke suatu tempat? k8s atau kops?

Langkah:

1. Setelah cluster aktif & berjalan.
2. Terapkan Solr Helm Chart dengan pengaturan sumber daya berikut

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** Pod lain juga harus berfungsi

1. Daftar wadah untuk menemukan id wadah
   sudo docker container ls
2. Periksa parameter memori container
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

Haruskah saya mengirimkan masalah ke suatu tempat? k8s atau kops?

Saya dapat mengonfirmasi bahwa saya hanya dapat melihat perilaku yang benar di Amazon Linux
ami-0cbc6aae997c6538a : amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2

            "Memory": 671088640,
            "CpusetMems": "",
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

Yaitu: "MemorySwap" == "Memory"

Dua gambar lainnya memiliki pengaturan yang sama: "MemorySwap": -1 , yang mengarah pada penggunaan swap tanpa batas.

• Debian
  
  
  
  • ami-075e61ad77b1269a7 : k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  
  
• Ubuntu
  
  
  
  • ami-09a4a9ce71ff3f20b : ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-AMD64-server-20200112
  
  

Jadi saya pikir itu mungkin masalah k8s?

Cerita pengguna:

(1) Program yang disediakan vendor saya menggunakan runtime bahasa yang mengamanatkan akses ke sumber kode program. Karena itu, saat inisialisasi, semua kode sumber program diatur dalam arena memori yang terpisah. Setelah program diinisialisasi dan wadah menjadi Siap, memori ini tidak akan diakses (Anda tidak dapat membuktikannya, tetapi tidak). Selain itu, program mengalokasikan beberapa halaman untuk dicadangkan untuk penanganan OOM khusus. Memori ini dapat ditukar. Saya tidak ingin "memori mati" ini memenuhi aplikasi cluster lainnya. Saya dapat menghitung dengan tepat jumlah memori yang akan mati dan mencantumkannya sebagai permintaan untuk swap di spesifikasi Pod.

(2) Saya menjalankan pembelajaran mesin atau beban kerja analisis data di mana penggunaan memori tiba-tiba dapat menggelembung dan menarik kembali. Tidak apa-apa jika aplikasi ini melambat, selama mereka tidak berhenti dan akhirnya selesai. Saya ingin menyediakan cluster dengan swap untuk mengurangi penggusuran ketika balon memori ini terjadi. Pod ini akan memiliki permintaan memori dan swap yang rendah, batas memori yang moderat - mungkin cukup untuk baseline + satu set kerja - dan batas swap yang besar.

(3) Saya menjalankan server web di juru bahasa (misalnya Ruby on Rails) yang kadang-kadang perlu fork+exec. Penghitungan memori yang ketat menghasilkan kegagalan garpu, yang tidak dapat diterima. Saya ingin menyediakan swap sehingga kernel memiliki ruang kepala memori yang dijamin untuk menutupi perilaku proses antara panggilan fork dan exec. Nilai vm.swappiness dapat diatur untuk sangat mencegah pertukaran, dan saya mengatur peringatan untuk memberi tahu operasi jika swap benar-benar digunakan selama produksi. Spesifikasi pod akan mengatur permintaan dan batas swap ke nilai yang sama.

Baru-baru ini kami mencoba memigrasikan semua layanan berbasis buruh pelabuhan kami ke Kubernetes, tetapi harus meninggalkan proyek karena swap tidak didukung.

Kami menemukan bahwa kami perlu menyediakan 3 kali lipat jumlah perangkat keras untuk mendukung jumlah kontainer yang sama persis yang saat ini kami jalankan dengan swap diaktifkan.

Masalah utama adalah bahwa beban kerja kami terdiri dari sejumlah wadah yang dapat menggunakan hingga 1 Gb atau lebih memori (atau swap), tetapi biasanya menggunakan sekitar 50 MB atau lebih saat beroperasi secara normal.

Tidak dapat bertukar berarti bahwa kami harus merancang segalanya untuk beban terbesar yang mungkin perlu ditangani, daripada memiliki blok swap yang tersedia ketika 'pekerjaan' besar perlu ditangani.

Kami akhirnya meninggalkan migrasi kami ke Kubernetes dan untuk sementara memindahkan semuanya ke Swarm sebagai gantinya untuk sementara waktu dengan harapan swap akan didukung di masa mendatang.

Masalah utama adalah bahwa beban kerja kami terdiri dari sejumlah wadah yang dapat menggunakan hingga 1 Gb atau lebih memori (atau swap), tetapi biasanya menggunakan sekitar 50 MB atau lebih saat beroperasi secara normal.

Orang mungkin berani mengatakan bahwa aplikasi yang berjalan di wadah tersebut ditulis dengan sangat buruk.

Orang mungkin berani mengatakan bahwa aplikasi yang berjalan di wadah tersebut ditulis dengan sangat buruk.

Ini agak tidak relevan, dan penunjuk jari jarang konstruktif. Ekosistem Kubernetes dibangun untuk mendukung berbagai profil aplikasi, dan memilih salah satunya seperti ini tidak masuk akal.

Masalah utama adalah bahwa beban kerja kami terdiri dari sejumlah wadah yang dapat menggunakan hingga 1 Gb atau lebih memori (atau swap), tetapi biasanya menggunakan sekitar 50 MB atau lebih saat beroperasi secara normal.

Orang mungkin berani mengatakan bahwa aplikasi yang berjalan di wadah tersebut ditulis dengan sangat buruk.

lol, ini adalah fitur kernel, aplikasi dapat menggunakan madvise(2) pada file shm, dan kami tidak memblokir syscall madvise,
sehingga memenuhi syarat bagi pengguna untuk memanfaatkan fitur ini pada desain mereka, Anda tidak dapat mengatakan "ditulis dengan sangat buruk",

Masalah utama adalah bahwa beban kerja kami terdiri dari sejumlah wadah yang dapat menggunakan hingga 1 Gb atau lebih memori (atau swap), tetapi biasanya menggunakan sekitar 50 MB atau lebih saat beroperasi secara normal.

Orang mungkin berani mengatakan bahwa aplikasi yang berjalan di wadah tersebut ditulis dengan sangat buruk.

Balasan Anda menunjukkan bahwa Anda tidak memahami beban kerja yang dikerjakan oleh banyak pengembang.

Beban kerja yang saya sebutkan berkaitan dengan kumpulan data berukuran berbeda yang disediakan oleh pengguna, karenanya berbagai kemungkinan persyaratan sumber daya.

Tentu, kami _bisa_ menggunakan file yang dipetakan memori agar penggunaan memori tetap konsisten. Kemudian kita perlu menulis ulang perpustakaan apa pun untuk menggunakan pemetaan memori itu sendiri, yang akan mencakup kurang lebih setiap perpustakaan yang ada... selamanya.

Tapi kemudian kita akan membuat apa yang pada dasarnya adalah file halaman khusus aplikasi, yang hampir pasti akan berkinerja lebih buruk daripada yang dikelola oleh kernel.

Beberapa Deployment Kubernetes Membutuhkan Swap

Saya memiliki kasus penggunaan yang valid - Saya sedang mengembangkan produk lokal, distro linux, yang disertakan dengan kubeadm. tidak ada penskalaan horizontal berdasarkan desain. Untuk bertahan dari puncak memori oportunistik dan masih berfungsi (tetapi lambat), saya pasti membutuhkan swap .

Untuk menginstal kubeadm dengan swap diaktifkan

1. Buat file di /etc/systemd/system/kubelet.service.d/20-allow-swap.conf dengan konten:

   [Service]
   Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
   

2. Lari

   sudo systemctl daemon-reload
   

3. Inisialisasi kubeadm dengan flag --ignore-preflight-errors=Swap

   kubeadm init --ignore-preflight-errors=Swap
   

https://stackoverflow.com/a/62158455/3191896

Sebagai pengembang perangkat lunak yang naif, tampaknya sangat masuk akal bagi saya untuk pod sistem dengan beban kerja sensitif waktu untuk meminta perilaku non-swap, dan beban kerja lainnya (secara default) dimasukkan ke dalam kategori upaya terbaik. Bukankah itu akan menyelesaikan semua kekhawatiran?

Untuk kebutuhan saya sendiri, banyak aplikasi saya mendapat manfaat dari cache. Yang mengatakan, jika sebuah aplikasi tiba-tiba membutuhkan banyak memori, akan lebih baik untuk mendorong cache terlama ke disk jika aplikasi tersebut tidak menanggapi permintaan untuk menurunkan tekanan memori daripada membiarkan beban kerja baru kehabisan memori, atau memiliki untuk mendukung ledakan dengan memori fisik + lebih banyak untuk penerapan bergulir + lebih banyak untuk potensi kegagalan simpul.

@metatick berkata:

Tentu, kita dapat menggunakan file yang dipetakan memori agar penggunaan memori tetap konsisten. Kemudian kita perlu menulis ulang perpustakaan apa pun untuk menggunakan pemetaan memori itu sendiri, yang akan mencakup kurang lebih setiap perpustakaan yang ada... selamanya.

Pustaka C standar Linux dirancang untuk menggantikan pengalokasi memori; malloc , realloc dan free dipanggil melalui pointer untuk tujuan itu. Jadi Anda bisa saja LD_PRELOAD perpustakaan yang akan menimpanya untuk dialokasikan dari file mmapped.

Tapi kemudian kita akan membuat apa yang pada dasarnya adalah file halaman khusus aplikasi, yang hampir pasti akan berkinerja lebih buruk daripada yang dikelola oleh kernel.

Itu benar-benar akan melakukan persis seperti swap normal, karena akan dikelola oleh kode yang sama di kernel. Satu-satunya perbedaan adalah kurangnya parameter swappiness untuk menyesuaikan prioritasnya.

Satu-satunya pertanyaan terbuka yang saya miliki adalah apakah ini sudah diterapkan (dikurangi batas lunak/keras kubelet "swapfs") - Saya harus pergi dan membaca kode cgroups kubelet/CRI yang sebenarnya sebelum saya dapat menulis proposal konkret dan item tindakan .

@anguslees ,
Apakah Anda pernah berkeliling untuk memeriksa perilaku. Jika demikian, bisakah Anda menambahkan beberapa resolusi atau tautan ke salah satunya?

Terima kasih,
Jan

Apakah Anda pernah berkeliling untuk memeriksa perilaku. Jika demikian, bisakah Anda menambahkan beberapa resolusi atau tautan ke salah satunya?

Aku tidak. (Saya memang sedikit menggali kode buruh pelabuhan, tetapi saya sudah melupakan semuanya sekarang dan harus memulai lagi)

Relawan lain selamat datang! Saya harap saya tidak mencuri oksigen dari seseorang dengan mengatakan saya akan mengerjakan ini dan kemudian gagal untuk menindaklanjuti :(

Untuk menambah cerita @metick :

Saat ini saya menggunakan Gigalixir sebagai Host saya, berjalan di atas Kubernetes. Ini adalah aplikasi web. Terkadang, klien mengunggah sekumpulan foto, jadi aplikasi saya menjalankan banyak proses ImageMagick (ugh) untuk mengubah ukurannya. Penggunaan memori melonjak, pembunuh OOM dipicu, dan aplikasi saya turun (singkat) dan unggahan rusak.

Saya akhirnya harus membayar lebih banyak ke Gigalixir daripada yang seharusnya hanya karena penggunaan yang berlebihan. Seperti yang telah disebutkan orang lain.

Anda mungkin tidak menyukai swap dari perspektif desain, tetapi keputusan Anda menghabiskan uang pebisnis... dan itu boros.

Tolong perbaiki. :)

Ini juga merupakan masalah yang sangat besar bagi saya. Dalam kasus penggunaan saya, saya perlu menjalankan pod yang menggunakan ~100MB hampir sepanjang waktu, tetapi dari waktu ke waktu, ketika pengguna memicu peristiwa tertentu, itu dapat meledak hingga 2GB RAM selama beberapa menit sebelum turun kembali (dan tidak, itu bukan karena ditulis dengan buruk, itu adalah kenyataan dari beban kerja).
Saya menjalankan hampir seratus beban kerja seperti itu sekaligus pada mesin 16GB dengan swap. Saya tidak bisa memindahkan beban kerja itu ke Kubernetes karena itu tidak akan berhasil sama sekali. Jadi sekarang, saya memiliki orkestra sendiri yang menjalankan beban kerja ini pada sistem non-kubernetes sementara aplikasi utama saya berjalan di Kubernetes, dan itu menggagalkan tujuan migrasi saya ke k8s. Tanpa swap, entah itu terbunuh, atau saya harus selalu membuang banyak RAM yang tersedia selama beberapa menit sehingga aplikasi mungkin (atau mungkin tidak) meledak.

Jika Anda dapat mengatur batas CPU, yang membatasi CPU untuk sebuah pod, Anda harus dapat mengatur batas memori yang membatasi memori yang digunakan oleh sebuah pod. Membunuh pod ketika mencapai batas memori sama konyolnya dengan membunuh satu jika menggunakan lebih banyak sumber daya CPU daripada batas CPU yang ditetapkan (maaf tetapi tidak setiap pod adalah replika yang dapat diturunkan tanpa konsekuensi).

Kubernetes tidak dapat bekerja dengan swap yang disetel pada node karena dapat memengaruhi keseluruhan kinerja seluruh cluster, baiklah (walaupun menurut saya itu bukan argumen yang valid). Idealnya, apa yang perlu terjadi adalah bahwa pod itu sendiri akan memiliki file swap level-pod di mana hanya proses-proses di dalam container tersebut yang akan ditukar. Ini secara teoritis akan membatasi penggunaan dan kinerja RAM (karena pertukaran) dari pod yang melebihi batas memorinya, sama seperti batas CPU yang mencekiknya.
Sayangnya, sepertinya cgroups tidak dapat menentukan file swap, hanya swappiness mereka, dan Anda tidak dapat memberi tahu kernel untuk "menukar jika penggunaan mem di atas batas ini" karena tampaknya memutuskan kapan harus menukar berdasarkan yang terakhir akses dan metrik lainnya.

Tetapi sementara itu, mengapa tidak membiarkan swap ada pada sebuah node, setel swappiness ke 0 untuk pod yang tidak memiliki batas yang ditetapkan, dan ketika batas ditetapkan (atau bidang spesifikasi lain untuk mengatakan "swapInsteadOfKill") setel swappiness ke nilai bukan nol?

Selain pembahasan tentang "swap or not to swap" yang membuat saya penasaran adalah bahwa perilaku yang dijelaskan oleh @pai911 tidak ditanggapi lebih lanjut oleh tim k8s.

Saya dapat mengkonfirmasi bahwa kubelet tampaknya berperilaku berbeda (dan pada beberapa OS tidak sesuai dengan kode yang disebutkan di atas) sehubungan dengan pengaturan memori deamon buruh pelabuhan. Cluster kami berjalan di SUSE linux dan kami mengalami penggunaan swap tak terbatas yang sama yang disebutkan di https://github.com/kubernetes/kubernetes/issues/53533#issuecomment -598056151

Detail OS: SUSE Linux Enterprise Server 12 SP4 - Linux 4.12.14-95.45-default

Tanpa dukungan yang tepat untuk Swap di k8s, saya setidaknya berharap kubelet akan menangani pengaturan memori Docker secara konsisten terlepas dari OS yang mendasarinya.

Saya menempatkan swap dalam agenda untuk melihat apakah ada selera masyarakat atau sukarelawan untuk membantu mendorong ini maju di 1,21. Saya tidak keberatan untuk mendukung swap seperti yang saya sebutkan di tahun 2017, hanya perlu memastikan untuk tidak membingungkan pengusiran kubelet, prioritas pod, kualitas layanan pod, dan yang terpenting pod harus dapat mengatakan apakah mereka mentolerir swap atau tidak. Semua hal ini penting untuk memastikan pod portabel.

Banyak energi telah difokuskan akhir-akhir ini untuk membuat hal-hal seperti memori selaras NUMA berfungsi, tetapi jika ada orang yang kurang peka terhadap kinerja dan sama-sama termotivasi untuk membantu memajukan ruang ini, kami akan senang membantu untuk memulai desain KEP rinci di ruang ini.

Saya belum mengikuti proses komunitas dengan sangat baik akhir-akhir ini karena hal-hal menjadi sangat sibuk bagi saya akhir-akhir ini, namun sepertinya mereka akan segera tenang. Apakah ada cara agar saya dapat terlibat tanpa harus bergabung dengan saluran Slack?