/tandatangani simpul
/jenis fitur
cc @ConnorDoyle @balajismaniam @nolancon

Saya dapat membantu menginformasikan desain ini berdasarkan pembelajaran dari Borg. Jadi, anggap saya sebagai pengulas/pemberi persetujuan.

Saya dapat membantu menginformasikan desain ini berdasarkan pembelajaran dari Borg. Jadi, anggap saya sebagai pengulas/pemberi persetujuan.

Apakah ada dokumentasi publik tentang cara kerja fitur ini di borg?

Bukan tentang NUMA AFAIK.

Pada Senin, 11 Februari 2019, 07:50 Jeremy Eder < [email protected] menulis:

Saya dapat membantu menginformasikan desain ini berdasarkan pembelajaran dari Borg. Jadi hitung aku
sebagai pengulas/pemberi persetujuan.

Apakah ada dokumentasi publik tentang cara kerja fitur ini di borg?

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

FYI @claurence

Masalah pelacakan ini dan KEP (https://github.com/kubernetes/enhancements/pull/781) tidak tepat waktu untuk pembekuan peningkatan v1.14 atau tenggat waktu yang diperpanjang. Saya menghargai bahwa Anda membuka ini sebelum tenggat waktu, tetapi tampaknya tidak mendapatkan ulasan atau tanda tangan yang memadai. Ini harus melalui proses pengecualian.

Sampai kami memutuskan apakah ini layak untuk pengecualian, saya cenderung untuk menahan semua PR yang terkait dengan peningkatan ini.

ref: https://github.com/kubernetes/kubernetes/issues/72828

/cc @jiayingz @dchen1107

@lmdaly Saya melihat Anda memiliki 1,14 terdaftar dalam deskripsi sebagai tonggak alfa - karena tidak ada KEP yang dapat diimplementasikan, masalah ini tidak dilacak untuk 1,14 - jika ada niat untuk memasukkannya ke dalam rilis itu, silakan mengajukan permintaan pengecualian.

@lmdaly Saya melihat Anda memiliki 1,14 terdaftar dalam deskripsi sebagai tonggak alfa - karena tidak ada KEP yang dapat diimplementasikan, masalah ini tidak dilacak untuk 1,14 - jika ada niat untuk memasukkannya ke dalam rilis itu, silakan mengajukan permintaan pengecualian.

@claurence KEP sekarang digabung (KEP sebelumnya telah digabungkan di repo komunitas. ini hanya untuk memindahkannya ke repo perangkat tambahan baru sesuai pedoman baru), apakah kita masih perlu mengirimkan permintaan pengecualian untuk mendapatkan masalah ini dilacak untuk 1,14?

Sementara setelah membaca desain & PR WIP secara menyeluruh, saya khawatir bahwa implementasi saat ini tidak umum seperti desain topologi asli yang kami usulkan di https://github.com/kubernetes/enhancements/pull/781. Yang ini saat ini lebih mirip topologi NUMA di tingkat simpul.

Saya meninggalkan beberapa komentar untuk diskusi lebih lanjut di sini: https://github.com/kubernetes/kubernetes/pull/74345#discussion_r264387724

implementasi saat ini tidak generik

Berbagi keprihatinan yang sama tentang itu :) Bagaimana dengan yang lain, misalnya tautan antar perangkat (nvlinke untuk GPU)?

@resouer @k82cn Proposal awal hanya berurusan dengan menyelaraskan keputusan yang dibuat oleh manajer cpu dan manajer perangkat untuk memastikan kedekatan perangkat dengan cpu tempat wadah berjalan. Memuaskan afinitas antar-perangkat bukanlah tujuan proposal.

Namun, jika implementasi saat ini menghalangi penambahan afinitas antar-perangkat di masa mendatang, maka saya akan dengan senang hati mengubah implementasi setelah saya memahami cara melakukannya,

Saya pikir masalah utama yang saya lihat dengan implementasi saat ini dan kemampuan untuk mendukung afinitas antar-perangkat adalah sebagai berikut:

Untuk mendukung afinitas antar-perangkat, Anda biasanya harus terlebih dahulu mencari tahu perangkat mana yang ingin Anda alokasikan ke wadah _sebelum_ memutuskan afinitas soket apa yang Anda inginkan untuk dimiliki wadah.

Misalnya, dengan GPU Nvidia, untuk konektivitas yang optimal, Anda harus terlebih dahulu menemukan dan mengalokasikan kumpulan GPU dengan NVLINK yang paling terhubung _sebelum_ menentukan afinitas soket yang dimiliki kumpulan tersebut.

Dari apa yang saya dapat katakan dalam proposal saat ini, asumsinya adalah bahwa operasi ini terjadi dalam urutan terbalik, yaitu afinitas soket diputuskan sebelum melakukan alokasi perangkat.

Itu belum tentu benar @klueska. Jika petunjuk topologi diperluas untuk menyandikan topologi perangkat titik-ke-titik, Pengelola Perangkat dapat mempertimbangkannya saat melaporkan afinitas soket. Dengan kata lain, topologi lintas perangkat tidak perlu bocor keluar dari cakupan pengelola perangkat. Apakah itu tampak layak?

Mungkin saya bingung dengan alurnya. Begini cara saya memahaminya:

1) Pada inisialisasi, plugin perangkat (bukan devicemanager ) mendaftarkan dirinya sendiri dengan topologymanager sehingga dapat mengeluarkan panggilan balik di lain waktu.

2) Ketika sebuah pod disubmit, kubelet memanggil lifecycle.PodAdmitHandler pada topologymanager .

3) lifecycle.PodAdmitHandler memanggil GetTopologyHints pada setiap plugin perangkat yang terdaftar

4) Kemudian menggabungkan petunjuk-petunjuk ini untuk menghasilkan TopologyHint konsolidasi yang terkait dengan pod

5) Jika memutuskan untuk menerima pod, ia berhasil mengembalikan dari lifecycle.PodAdmitHandler menyimpan TopologyHint konsolidasi untuk pod di toko negara bagian lokal

6) Di beberapa titik di masa depan, cpumanager dan devicemanager memanggil GetAffinity(pod) pada manajer topology untuk mengambil TopologyHint terkait dengan polong

7) cpumanager menggunakan TopologyHint` ini untuk mengalokasikan CPU

8) devicemanager menggunakan TopologyHint` ini untuk mengalokasikan satu set perangkat

9) Inisialisasi pod berlanjut...

Jika ini benar, saya kira saya sedang berjuang dengan apa yang terjadi antara titik waktu ketika plugin perangkat melaporkan TopologyHints dan waktu ketika devicemanager melakukan alokasi yang sebenarnya.

Jika petunjuk ini dimaksudkan untuk menyandikan "preferensi" untuk alokasi, maka saya pikir apa yang Anda katakan adalah memiliki struktur yang lebih seperti:

type TopologyHints struct {
    hints []struct {
        SocketID int
        DeviceIDs []int
    }
}

Di mana kami tidak hanya memberikan daftar preferensi afinitas soket, tetapi bagaimana preferensi afinitas soket tersebut berpasangan dengan preferensi GPU yang dapat dialokasikan.

Jika ini adalah arah yang Anda pikirkan, maka saya pikir kita dapat membuatnya bekerja, tetapi entah bagaimana kita perlu mengoordinasikan antara cpumanager dan devicemanager untuk memastikan mereka "menerima" hal yang sama petunjuk ketika membuat alokasi mereka.

Apakah ada sesuatu di tempat yang memungkinkan ini yang saya lewatkan?

@klueska

Saya pikir apa yang terjadi, membuat beberapa koreksi _minor_ pada aliran Anda adalah:

1. Pada inisialisasi, plugin perangkat mendaftarkan dirinya sendiri dengan devicemanager sehingga dapat mengeluarkan panggilan balik di lain waktu.

2. lifecycle.PodAdmitHandler memanggil GetTopologyHints pada setiap komponen topologi di Kubelet, saat ini devicemanager dan cpumanager .

Dalam hal ini, apa yang akan direpresentasikan sebagai topology-aware di Kubelet adalah cpumanager dan devicemanager . Manajer topologi hanya dimaksudkan untuk mengoordinasikan alokasi antara komponen yang sadar topologi.

Untuk ini:

tetapi entah bagaimana kita perlu berkoordinasi antara cpumanager dan devicemanager untuk memastikan mereka "menerima" petunjuk yang sama ketika membuat alokasi mereka.

Inilah yang ingin dicapai oleh topologymanager itu sendiri. Dari salah satu draf sebelumnya ,

Komponen-komponen ini harus berkoordinasi untuk menghindari penugasan NUMA silang. Masalah yang terkait dengan koordinasi ini rumit; permintaan lintas domain seperti "Inti eksklusif pada node NUMA yang sama dengan NIC yang ditetapkan" melibatkan CNI dan manajer CPU. Jika manajer CPU memilih terlebih dahulu, ia dapat memilih inti pada node NUMA tanpa NIC yang tersedia dan sebaliknya.

Jadi begitu.

Jadi devicemanager dan cpumanager keduanya mengimplementasikan GetTopologyHints() serta memanggil GetAffinity() , menghindari interaksi arah dari topologymanager dengan plugin perangkat yang mendasarinya . Melihat lebih dekat pada kode, saya melihat bahwa devicemanager hanya mendelegasikan kontrol ke plugin untuk membantu mengisi TopologyHints , yang pada akhirnya lebih masuk akal.

Berputar kembali ke pertanyaan/masalah awal yang saya angkat ....

Dari sudut pandang Nvidia, saya pikir kita dapat membuat semuanya bekerja dengan aliran yang diusulkan ini, dengan asumsi lebih banyak informasi ditambahkan ke struct TopologyHints (dan akibatnya antarmuka plugin perangkat) untuk melaporkan informasi tautan titik-ke-titik di masa mendatang .

Namun, saya pikir memulai dengan SocketMask sebagai struktur data utama untuk afinitas soket iklan dapat membatasi kemampuan kami untuk memperluas TopologyHints dengan informasi titik-ke-titik di masa mendatang tanpa merusak antarmuka yang ada. Alasan utamanya adalah (setidaknya dalam kasus GPU Nvidia) soket pilihan bergantung pada GPU mana yang akan dialokasikan pada akhirnya.

Misalnya, perhatikan gambar di bawah ini, saat mencoba mengalokasikan 2 GPU ke pod dengan konektivitas optimal:

Kombinasi GPU (2, 3) dan (6, 7) keduanya memiliki 2 NVLINK dan berada di bus PCIe yang sama. Oleh karena itu, mereka harus dianggap sebagai kandidat yang setara ketika mencoba mengalokasikan 2 GPU ke sebuah pod. Tergantung pada kombinasi mana yang dipilih, bagaimanapun, soket yang berbeda jelas akan lebih disukai karena (2, 3) terhubung ke soket 0 dan (6, 7) terhubung ke soket 1.

Informasi ini entah bagaimana perlu dikodekan dalam TopologyHints struct sehingga devicemanager dapat melakukan salah satu dari alokasi yang diinginkan ini pada akhirnya (yaitu yang mana pun topologymanager mengkonsolidasikan petunjuk ke). Demikian juga, ketergantungan antara alokasi perangkat yang disukai dan soket pilihan perlu dikodekan dalam TopologyHints sehingga cpumanager dapat mengalokasikan CPU dari soket yang benar.

Solusi potensial khusus untuk GPU Nvidia untuk contoh ini akan terlihat seperti:

type TopologyHint struct {
    SocketID int
    DeviceIDs []int
}

type TopologyHints []TopologyHint

devicemanagerhints := &TopologyHints{
    {SocketID: 0, DeviceIDs: []int{2, 3}},
    {SocketID: 1, DeviceIDs: []int{6, 7}},
}

cpumanagerhints := &TopologyHints{
    {SocketID: 1},
}

Di mana topologymanager akan menggabungkan petunjuk ini untuk mengembalikan {SocketID: 1, DeviceIDs: []int{6, 7}} sebagai petunjuk pilihan ketika devicemanager dan cpumanager kemudian memanggil GetAffinity() .

Meskipun ini mungkin atau mungkin tidak memberikan solusi yang cukup umum untuk semua akselerator, mengganti SocketMask di TopologyHints struct dengan sesuatu yang lebih terstruktur seperti berikut akan memungkinkan kita untuk memperluas setiap petunjuk individu dengan lebih banyak bidang di masa depan:

Perhatikan bahwa GetTopologyHints() masih mengembalikan TopologyHints , sementara GetAffinity() telah dimodifikasi untuk mengembalikan satu TopologyHint daripada TopologyHints .

type TopologyHint struct {
    SocketID int
}

type TopologyHints []TopologyHint

&TopologyHints{
    {SocketID: 0},
    {SocketID: 1},
}

type HintProvider interface {
    GetTopologyHints(pod v1.Pod, container v1.Container) TopologyHints
}

type Store interface {
    GetAffinity(podUID string, containerName string) TopologyHint
}

Pikiran?

@klueska Mungkin saya melewatkan sesuatu, tetapi saya tidak melihat perlunya ID perangkat untuk GPU NV Link terisi hingga TopologyManager.

Jika Device Plugin API diperluas untuk memungkinkan perangkat mengirim kembali informasi tentang konektivitas perangkat titik ke titik seperti yang disarankan @ConnorDoyle , maka manajer perangkat akan dapat mengirim kembali informasi soket berdasarkan ini.

Dalam contoh Anda devicemanagerhints dapat berupa informasi yang dikirim kembali oleh plugin perangkat ke devicemanager. Manajer perangkat kemudian mengirimkan kembali informasi soket kembali ke TopologyManager seperti sekarang dan TopologyManager menyimpan petunjuk soket yang dipilih.

Pada alokasi, devicemanager memanggil GetAffinity untuk mendapatkan alokasi soket yang diinginkan (katakanlah soket adalah 1 dalam kasus ini), menggunakan informasi ini dan informasi yang dikirim kembali oleh plugin perangkat, ia dapat melihat bahwa pada soket 1 ia harus menetapkan perangkat ( 6,7) karena merupakan perangkat NV Link.

Apakah itu masuk akal atau ada sesuatu yang saya lewatkan?

Terima kasih telah meluangkan waktu untuk mengklarifikasi hal ini dengan saya. Saya pasti salah mengartikan saran asli

Jika petunjuk topologi diperluas untuk menyandikan topologi perangkat titik-ke-titik, Pengelola Perangkat dapat mempertimbangkannya saat melaporkan afinitas soket.

Saya membaca ini sebagai keinginan untuk memperluas TopologyHints struct dengan informasi point-to-point secara langsung.

Sepertinya Anda lebih menyarankan bahwa hanya API plugin perangkat yang perlu diperluas untuk memberikan informasi titik-ke-titik ke devicemanager , sehingga dapat menggunakan informasi ini untuk menginformasikan SocketMask untuk mengatur di TopologyHints struct setiap kali GetTopologyHints() dipanggil.

Saya pikir ini akan berhasil, selama ekstensi API ke plugin perangkat dirancang untuk memberi kita informasi yang mirip dengan apa yang saya uraikan dalam contoh saya di atas dan devicemanager diperluas untuk menyimpan informasi ini antara penerimaan pod dan perangkat alokasi waktu.

Saat ini kami memiliki solusi khusus di Nvidia yang menambal kubelet untuk melakukan apa yang Anda sarankan (kecuali bahwa kami tidak mengeluarkan keputusan apa pun untuk plugin perangkat -- devicemanager telah membuat GPU sadar dan membuat keputusan alokasi GPU berbasis topologi itu sendiri).

Kami hanya ingin memastikan bahwa solusi jangka panjang apa pun yang diterapkan akan memungkinkan kami untuk menghapus tambalan khusus ini di masa mendatang. Dan sekarang saya memiliki gambaran yang lebih baik tentang bagaimana aliran di sini bekerja, saya tidak melihat apa pun yang akan menghalangi kita.

Sekali lagi terima kasih telah meluangkan waktu untuk mengklarifikasi semuanya.

Halo @lmdaly , saya Pemimpin Peningkatan untuk 1.15. Apakah fitur ini akan lulus tahap alfa/beta/stabil di 1.15? Tolong beri tahu saya agar dapat dilacak dengan benar dan ditambahkan ke spreadsheet.

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

fitur ini akan menjadi gerbang fiturnya sendiri, dan akan menjadi alpha.

/tonggak sejarah 1.15

@derekwaynecarr : Tonggak yang diberikan tidak valid untuk repositori ini. Tonggak sejarah dalam repositori ini: [ keps-beta , keps-ga , v1.14 , v1.15 ]

Gunakan /milestone clear untuk menghapus pencapaian.

/ tonggak sejarah v1.15

/assign @lmdaly

https://github.com/kubernetes/kubernetes/issues/72828

Kode PR

@lmdaly
https://github.com/kubernetes/kubernetes/issues/72828
Tim saya dan saya mempertimbangkan untuk menguji manajer topologi untuk aplikasi sensitif numa.
Jadi, kami punya beberapa pertanyaan.
Di atas PR, apakah ini implikasi penuh untuk manajer topologi?
Dan apakah sudah teruji atau stabil sekarang?

@bg-chun Kami melakukan hal yang sama di Nvidia. Kami telah menarik WIP PR ini ke dalam tumpukan internal kami dan telah membangun strategi alokasi sadar topologi untuk CPU/GPU di sekitarnya. Dalam melakukannya, kami menemukan beberapa masalah dan memberikan beberapa umpan balik khusus tentang PR ini.

Silakan lihat utas diskusi di sini untuk lebih jelasnya:
https://kubernetes.slack.com/archives/C0BP8PW9G/p1556371768035800

Hei, @lmdaly , saya adalah bayangan rilis dokumen

Saya melihat bahwa Anda menargetkan versi alfa dari peningkatan ini untuk rilis 1,15. Apakah ini memerlukan dokumen baru (atau modifikasi)?

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

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

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

Akan melihat https://github.com/kubernetes/kubernetes/issues/72828 untuk melihat apakah semuanya digabungkan.

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

@daminisatya saya sudah push doc PR. https://github.com/kubernetes/website/pull/14572

Beri tahu saya jika itu dilakukan dengan benar dan jika ada item tambahan yang perlu dilakukan. Terima kasih untuk pengingatnya!

Terima kasih @lmdaly

Hai @lmdaly , hari ini adalah pembekuan kode untuk siklus rilis 1,15. Masih ada beberapa k/k PR yang belum digabungkan dari masalah pelacakan Anda https://github.com/kubernetes/kubernetes/issues/72828. Sekarang sedang ditandai sebagai Berisiko di Lembar Pelacakan Penyempurnaan 1.15 . Apakah ada keyakinan yang tinggi ini akan digabung oleh EOD PST hari ini? Setelah titik ini, hanya masalah pemblokiran rilis dan PR yang akan diizinkan dalam pencapaian dengan pengecualian.

/pencapaian jelas

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

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

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

Terima kasih.

@kacole2 terima kasih atas pengingatnya. Fitur ini akan masuk sebagai Alpha di 1.16.

Daftar PR yang sedang berlangsung dapat ditemukan di sini: https://github.com/kubernetes/kubernetes/issues/72828

Terima kasih!

Setuju ini akan mendarat di alfa untuk 1,16, kami akan menutup upaya yang dimulai dan ditangkap di kep yang sebelumnya digabungkan untuk 1,15.

Hai @lmdaly , saya bayangan rilis dokumen v1.16.

Apakah peningkatan ini 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!

Terima kasih!

Dokumentasi PR: https://github.com/kubernetes/website/pull/15716

@lmdaly Akankah manajer topologi memberikan informasi atau API apa pun untuk memberi tahu pengguna konfigurasi NUMA untuk pod yang diberikan?

@mJace sesuatu yang terlihat melalui deskripsi kubectl untuk pod?

@lmdaly Ya, kubectl describe bagus. atau beberapa api untuk mengembalikan informasi terkait.
Karena kami sedang mengembangkan layanan untuk menyediakan beberapa informasi terkait topologi untuk pod, seperti status penyematan cpu untuk pod, dan numa node untuk VF yang dilewatinya.
Dan beberapa alat monitor seperti lingkup weave dapat memanggil api untuk melakukan beberapa pekerjaan mewah.
Admin dapat mengetahui apakah VNF berada di bawah konfigurasi numa yang tepat, misalnya.

Hanya Ingin tahu apakah Topology Manager akan mencakup bagian ini.
atau jika ada pekerjaan yang dapat kami lakukan jika Manajer Topologi berencana untuk mendukung fungsi semacam ini.

@mJace Oke, jadi saat ini belum ada API seperti itu untuk Topology Manager. Saya tidak berpikir ada prioritas untuk ini, karena dengan CPU & Device Manager tidak ada visibilitas ke dalam apa yang sebenarnya telah ditetapkan ke pod.

Jadi saya pikir akan baik untuk memulai diskusi tentang ini dan melihat pandangan seperti apa yang dapat kami berikan kepada pengguna.

Begitu, saya pikir CPU & Device Manager dapat melihat informasi ini.

Mungkin cadvisor adalah peran yang baik untuk memberikan informasi ini.
Karena pada dasarnya cadvisor mendapatkan informasi container seperti PID, dll dengan ps ls .
Dan dengan cara yang sama kita memeriksa informasi terkait topologi container.
Saya akan menerapkan ini di cadvisor dan membuat pr untuk itu.

Saya telah membuat masalah terkait di cadvisor.
https://github.com/google/cadvisor/issues/2290

/menetapkan

+1 untuk proposal cadvisor @mJace.

Untuk menggunakan lib DPDK di dalam wadah dengan CPU Manager dan Topology Manager , menguraikan afinitas cpu wadah kemudian meneruskannya ke lib dpdk, keduanya diperlukan untuk menyematkan utas lib DPDK.

Untuk lebih jelasnya, Jika sebuah cpus tidak diperbolehkan dalam subsistem cpuset cgroup container, panggilan ke sched_setaffinity untuk proses pin pada cpus akan difilter.
DPDK lib menggunakan pthread_setaffinity_np untuk menyematkan utas, dan pthread_setaffinity_np adalah pembungkus tingkat utas sched_setaffinity .
Dan Manajer CPU Kubernetes menetapkan cpus eksklusif pada subsistem cpuset cgroup container.

@bg-chun Saya memahami perubahan cadvisor sebagai tujuan yang berbeda: pemantauan. Untuk kebutuhan Anda, dimungkinkan untuk membaca CPU yang ditetapkan dari dalam wadah dengan mem-parsing 'Cpus_Allowed' atau 'Cpus_Allowed_List' dari '/proc/self/status'. Apakah pendekatan itu akan berhasil untuk Anda?

@ConnorDoyle informasi di /proc/*/status seperti Cpus_Allowed dipengaruhi oleh sched_setaffinity . Jadi, jika aplikasi menyetel sesuatu, itu akan menjadi bagian dari apa yang benar-benar diizinkan oleh pengontrol cpuset Cgroup.

@kad , saya menyarankan cara peluncur di dalam wadah untuk mengetahui nilai cpu id untuk diteruskan ke program DPDK. Jadi ini terjadi sebelum afinitas tingkat utas disetel.

@ConnorDoyle
Terima kasih atas saran Anda, saya akan mempertimbangkannya.
Rencana saya adalah menggunakan server tiny-rest-api untuk memberi tahu info alokasi CPU eksklusif ke dpdk-container.

Soal perubahan, saya belum melihat perubahan cadvisornya, saya hanya melihat proposalnya saja .
Proposal mengatakan able to tell if there is any cpu affinity set for the container. di Goal dan to tell if there is any cpu affinity set for the container processes. di Future work.

Setelah membaca proposal, saya hanya berpikir akan sangat bagus jika cadvisor dapat mengurai info pinning cpu dan kubelet meneruskannya ke dalam wadah sebagai variabel lingkungan seperti status.podIP , metadata.name , dan limits.cpu .
Itulah alasan utama mengapa saya meninggalkan +1.

@bg-chun Anda dapat memeriksa PR pertama saya di cadvisor
https://github.com/google/cadvisor/pull/2291

Saya telah menyelesaikan beberapa fungsi serupa di.
https://github.com/mJace/numacc
tetapi tidak begitu yakin apa cara yang tepat untuk mengimplementasikannya di cadvisor
Itu sebabnya saya hanya membuat PR dengan satu fitur baru -> tampilkan PSR.

tetapi tidak begitu yakin apa cara yang tepat untuk mengimplementasikannya di cadvisor

Mungkin kita bisa mendiskusikan ini di bawah proposal itu? Jika menurut Anda para ahli fitur ini diperlukan :)

Pembekuan kode https://github.com/kubernetes/kubernetes/issues/72828 untuk PR k/k yang tersisa

@kacole2 semua PR yang diperlukan untuk fitur ini digabungkan atau dalam antrian gabungan.

Hai @lmdaly -- 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

@lmdaly apakah ada tautan langsung ke GPU dengan diskusi RDMA?

@nickolaev , Kami juga melihat kasus penggunaan ini. Kami memang memulai beberapa pemikiran internal tentang bagaimana melakukan ini, tetapi kami ingin berkolaborasi dalam hal ini.

@moshe010 @nickolaev @lmdaly , Kami juga melihat kasus penggunaan ini yang berkaitan dengan RDMA dan GPU langsung. Kami ingin bekerja sama dalam hal ini. Mungkinkah memulai utas/diskusi seputar ini?

Halo! Saya punya pertanyaan tentang NTM dan scheduler. Seperti yang saya pahami, penjadwal tidak tahu tentang NUMA dan dapat memilih node yang tidak memiliki sumber daya (cpu, memori, dan perangkat) pada NUMA yang diinginkan. Jadi manajer topologi akan menolak alokasi sumber daya pada node itu. Apakah itu benar?

@nickolaev @Deepthidharwar , saya akan memulai google doc dengan kasus penggunaan dan kita dapat memindahkan diskusi ke sana. Saya akan memposting sesuatu minggu depan. Jika itu baik-baik saja dengan Anda.

Saya sangat senang melihat fitur ini. Kami juga membutuhkan CPU, Hugepage, SRIOV-VFs dan perangkat keras lainnya dalam satu node NUMA.
Tapi largepage tidak disadari sebagai sumber daya skalar oleh plugin perangkat, apakah fitur ini perlu mengubah fitur hugepage di k8s?
@iamneha

@ConnorDoyle Hanya untuk mengonfirmasi, fitur ini memerlukan petunjuk topologi dari manajer cpu dan manajer perangkat? Saya mengujinya pada 1.16 dan tidak berhasil, sepertinya hanya mendapat petunjuk dari manajer cpu tetapi tidak ada petunjuk dari sisi perangkat.

@ConnorDoyle di sini adalah sedikit lebih detail:
https://Gist.githubusercontent.com/jianzzha/c2a66a2514c178cca76a432029ff3387/raw/264f13dfcd06f1f80c48c113aa235fab7c33d81e/hyper%2520threading%2520diaktifkan

@jianzzha , Plugin Perangkat apa yang Anda gunakan? Misalnya jika Anda menggunakan plugin perangkat SR-IOV, Anda harus memastikannya melaporkan simpul NUMA, lihat [1]

[1] https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b7c2f9feb180c3051aa3f7aea.

@andyzheung Integrasi halaman besar saat ini sedang dibahas dan telah dipresentasikan dalam pertemuan sig-node dua minggu terakhir. Berikut adalah beberapa tautan yang relevan:

https://docs.google.com/presentation/d/1H5xhCjgCZJjdTm-mGUFwqoz8XmoVd8xTCwJ1AfVR_54/edit?usp=sharing
https://github.com/kubernetes/enhancements/pull/1245
https://github.com/kubernetes/enhancements/pull/1199

@jianzzha Mengenai plugin perangkat tidak memberikan petunjuk. Apakah plugin Anda telah diperbarui untuk melaporkan informasi NUMA tentang perangkat yang dihitungnya? Perlu menambahkan bidang ini ke pesan Perangkat https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/deviceplugin/v1beta1/api.proto#L100

terima kasih teman-teman. Tetap dan berfungsi sekarang.

@klueska
Mengenai nvidia-gpu-device-plugin..
Saya hanya dapat melihat satu PR(WIP) aktif untuk memperbarui nvidia-gpu-device-plugin untuk Topology Manger.
Akankah nvidia-gpu-divice-plugin diperbarui untuk memberikan petunjuk topologi dengan PR di atas? atau ada yang saya lewatkan?

@bg-chun Ya seharusnya begitu. Barusan ping ke penulisnya. Jika dia tidak kembali pada hari berikutnya atau lebih, saya akan memperbarui plugin sendiri.

@bg-chun @klueska Saya telah memperbarui tambalan.

@klueska @carmark
Terima kasih telah memperbarui dan pemberitahuannya.
Saya akan memperkenalkan pembaruan sr-iov-plugin dan pembaruan gpu-plugin kepada pengguna di ruang kerja saya.

Saya akan mengusulkan peningkatan untuk rilis berikutnya.
Ini pada dasarnya tentang menghapus "penyelarasan topologi hanya terjadi jika Pod berada dalam batasan Jaminan QoS".
Pembatasan semacam ini membuat Manajer Topologi tidak dapat digunakan untuk saya saat ini, karena saya tidak ingin meminta CPU eksklusif dari K8, namun saya ingin menyelaraskan soket beberapa perangkat, yang berasal dari beberapa kumpulan (mis. GPU + SR -IOV VF dll.)
Juga bagaimana jika beban kerja saya tidak sensitif terhadap memori, atau tidak ingin membatasi penggunaan mem-nya (kriteria lain dari Guaranteed QoS).
Di masa depan ketika semoga halaman besar juga diselaraskan, pembatasan ini akan terasa semakin membatasi IMO.

Apakah ada argumen yang menentang penyelarasan sumber daya "yang dapat disejajarkan" secara individual? Tentu saja, mari kita hanya mengumpulkan petunjuk dari Manajer CPU jika CPU eksklusif digunakan, tetapi secara mandiri mari kita kumpulkan petunjuk dari Pengelola Perangkat jika pengguna memerlukan Perangkat yang memiliki informasi soket, atau dari manajer memori saat pengguna meminta halaman besar, dll.

Entah ini, atau jika beban komputasi ekstra yang tidak perlu selama startup Pod menjadi perhatian mungkin membawa kembali flag konfigurasi tingkat Pod asli untuk mengontrol apakah penyelarasan terjadi, atau tidak (yang saya terkejut melihat dihapus selama implementasi)

Saya akan mengusulkan peningkatan untuk rilis berikutnya.
Ini pada dasarnya tentang menghapus "penyelarasan topologi hanya terjadi jika Pod berada dalam batasan Jaminan QoS".

Ini adalah item nomor 8 pada daftar TODO kami untuk 1.17:
https://docs.google.com/document/d/1YTUvezTLGmVtEF3KyLOX3FzfSDw9w0zB-s2Tj6PNzLA/edit#heading =h.xnehh6metosd

Apakah ada argumen yang menentang penyelarasan sumber daya "yang dapat disejajarkan" secara individual? Tentu saja, mari kita hanya mengumpulkan petunjuk dari Manajer CPU jika CPU eksklusif digunakan, tetapi secara mandiri mari kita kumpulkan petunjuk dari Pengelola Perangkat jika pengguna memerlukan Perangkat yang memiliki informasi soket, atau dari manajer memori saat pengguna meminta halaman besar, dll.

Apakah Anda mengusulkan agar ada mekanisme untuk secara selektif memberi tahu kubelet sumber daya mana yang harus disejajarkan dan mana yang tidak (yaitu saya ingin menyelaraskan alokasi CPU dan GPU saya, tetapi bukan alokasi halaman besar saya). Saya tidak berpikir siapa pun akan langsung menentang ini, tetapi antarmuka untuk secara selektif memutuskan sumber daya mana yang akan disejajarkan dan mana yang tidak disejajarkan bisa menjadi terlalu rumit jika kita terus menentukan penyelarasan sebagai bendera di tingkat simpul.

Entah ini, atau jika beban komputasi ekstra yang tidak perlu selama startup Pod menjadi perhatian mungkin membawa kembali flag konfigurasi tingkat Pod asli untuk mengontrol apakah penyelarasan terjadi, atau tidak (yang saya terkejut melihat dihapus selama implementasi)

Tidak ada cukup dukungan untuk flag level pod untuk menjamin proposal untuk memperbarui spesifikasi pod dengan ini. Bagi saya masuk akal untuk mendorong keputusan ini ke tingkat pod karena beberapa pod membutuhkan/menginginkan penyelarasan dan beberapa tidak, tetapi tidak semua orang setuju.

+1 untuk menghapus batasan kelas QoS pada penyelarasan topologi (saya menambahkannya ke daftar: smiley :). Saya tidak mengerti @Levovar meminta untuk mengaktifkan topologi berdasarkan sumber daya, hanya saja kita harus menyelaraskan semua sumber daya yang dapat disejajarkan yang digunakan oleh wadah tertentu.

Sejauh yang saya ingat, tidak pernah ada bidang tingkat pod untuk memilih topologi di KEP. Alasan untuk tidak memperkenalkannya sejak awal adalah alasan yang sama untuk meninggalkan inti eksklusif secara implisit -- Kubernetes sebagai sebuah proyek ingin bebas untuk menafsirkan spesifikasi pod secara bebas dalam hal manajemen kinerja tingkat node. Saya tahu sikap itu tidak memuaskan bagi beberapa anggota komunitas, tetapi kita selalu dapat mengangkat topik itu lagi. Ada ketegangan alami antara mengaktifkan fitur-fitur canggih untuk beberapa vs. memodulasi beban kognitif untuk sebagian besar pengguna.

IMO pada tahap awal desain setidaknya ada flag level Pod jika ingatan saya baik, tapi itu sekitar 1,13 :D
Saya pribadi setuju dengan mencoba menyelaraskan semua sumber daya sepanjang waktu, tetapi "dulu" biasanya ada komunitas yang menolak fitur yang akan menyebabkan penundaan startup, atau keputusan penjadwalan semua Pod, terlepas dari apakah mereka benar-benar membutuhkan peningkatan, atau tidak.

Jadi saya hanya mencoba untuk "menangani" masalah tersebut dengan dua opsi yang muncul di benak saya: pra-gerbang penyelarasan grup sumber daya berdasarkan beberapa kriteria (mudah ditentukan untuk CPU, lebih sulit untuk yang lain); atau perkenalkan beberapa flag konfigurasi.

Namun, jika tidak ada penolakan sekarang terhadap peningkatan generik, saya sangat setuju dengan itu :)

@mrbobbytables Kami berencana untuk TopologyManager menjadi beta dalam 1.17. Masalah pelacakan ada di sini: https://github.com/kubernetes/kubernetes/issues/83479

@bg-chun @klueska Saya telah memperbarui tambalan.

Patch digabungkan:
https://github.com/NVIDIA/k8s-device-plugin/commit/cc0aad87285b573127add4e487b13434a61ba0d6

Membuat rilis baru dengan tambalan:
https://github.com/NVIDIA/k8s-device-plugin/releases/tag/1.0.0-beta2

pelacakan beta untuk v1.17

Luar biasa, terima kasih @derekwaynecarr . Saya akan menambahkannya ke lembar :)
/tahap beta

@lmdaly

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

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

Terima kasih!

@VineethReddy02 ya kami telah merencanakan pembaruan dokumentasi untuk 1.17, jika Anda dapat memperbarui lembar pelacak, itu akan sangat bagus!

Kami akan pastikan untuk membuka PR itu sebelum itu, terima kasih untuk pengingatnya.

Masalah untuk dokumentasi pelacakan untuk ini ada di sini: https://github.com/kubernetes/kubernetes/issues/83482

https://github.com/kubernetes/enhancements/pull/1340
Teman-teman, saya membuka PR pembaruan KEP untuk menambahkan label simpul bawaan( beta.kubernetes.io/topology ) untuk Manajer Topologi.
Label akan mengekspos kebijakan node.
Saya pikir akan sangat membantu untuk menjadwalkan pod ke node tertentu ketika ada node dengan beberapa kebijakan di cluster yang sama.
Boleh minta reviewnya?

Hai @lmdaly @derekwaynecarr

Jeremy dari tim peningkatan 1.17 di sini . Bisakah Anda mencantumkan k/k PR yang sedang dalam penerbangan untuk ini sehingga kami dapat melacaknya? Saya melihat #83492 digabungkan, tetapi tampaknya ada beberapa masalah terkait lainnya yang menggantung dari keseluruhan item pelacakan. Kami akan menutup Code Freeze pada 14 November, jadi kami ingin mengetahui bagaimana perkembangannya sebelum itu! Terima kasih banyak!

@jeremyrickard Ini adalah masalah pelacakan untuk 1.17 seperti yang disebutkan di atas: https://github.com/kubernetes/enhancements/issues/693#issuecomment -538123786

@lmdaly @derekwaynecarr

Pengingat ramah kami mencari PR pengganti untuk Documents terhadap k/website (cabang dev-1.17) yang jatuh tempo pada hari Jumat, 8 November. Kami hanya memiliki 2 hari lagi untuk batas waktu ini.

Dokumen PR ada di sini btw: https://github.com/kubernetes/website/pull/17451

@klueska Saya melihat beberapa pekerjaan menabrak 1.18. Apakah Anda masih berencana untuk meningkatkan ini ke beta di 1.17, atau akan tetap sebagai alfa tetapi berubah?

Tidak apa-apa, saya melihat di https://github.com/kubernetes/kubernetes/issues/85093 bahwa Anda akan melompat ke beta di 1.18 sekarang, bukan sebagai bagian dari 1.17. Apakah Anda ingin kami melacak ini sebagai perubahan besar pada versi alfa sebagai bagian dari pencapaian 1,17 @klueska? Atau hanya menunda kelulusan ke 1,18?

/tonggak sejarah v1.18

Hai @klueska

1.18 tim peningkatan check-in! Apakah Anda masih berencana untuk lulus ini ke beta di 1.18? Enhancement Freeze akan dilakukan pada 28 Januari, jika KEP Anda memerlukan pembaruan, sedangkan Code Freeze akan dilakukan pada 5 Maret.

Terima kasih!

Ya.

@klueska terima kasih atas pembaruannya! Memperbarui lembar pelacakan.

@klueska saat kami meninjau KEP untuk rilis ini, kami melihat bahwa ini tidak memiliki rencana pengujian. Untuk lulus ke beta dalam rilis, itu perlu memiliki rencana pengujian yang ditambahkan. Saya akan menghapusnya dari pencapaian untuk saat ini, tetapi kami dapat menambahkannya kembali jika Anda mengajukan Permintaan Pengecualian dan menambahkan rencana pengujian ke KEP. Maaf atas pemberitahuan yang terlambat.

/pencapaian jelas

@vpickard silakan lihat di atas

@vpickard silakan lihat di atas

@klueska Terima kasih atas perhatiannya. Akan bekerja untuk menambahkan rencana pengujian ke KEP dan mengajukan Permintaan Pengecualian. Kami secara aktif mengembangkan kasus uji dan melakukan beberapa pengujian PR, dan beberapa sedang berlangsung, termasuk yang ini:

https://github.com/kubernetes/kubernetes/pull/87645

@jeremyrickard Apakah ada templat rencana pengujian yang dapat Anda tunjuk untuk referensi?

@vpickard Anda dapat melihat:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190530-pv-health-monitor.md#test -plan
dan
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-skip-permission-change.md#test -plan

Sertakan ikhtisar tes unit dan tes e2e.

Jika Anda memiliki sesuatu yang muncul di kisi uji, akan sangat bagus untuk disertakan.

Pengecualian disetujui.

/tonggak sejarah v1.18

@jeremyrickard Rencana pengujian digabungkan: https://github.com/kubernetes/enhancements/pull/1527

Hai @klueska @vpickard , sekedar mengingatkan bahwa Code Freeze akan mulai berlaku pada hari Kamis tanggal 5 Maret.

Bisakah Anda menautkan semua PR k/k atau PR lainnya yang harus dilacak untuk peningkatan ini?

Terima kasih :)

Hai @palnabarun

Masalah pelacakan di sini untuk 1.18:
https://github.com/kubernetes/kubernetes/issues/85093

PR terbuka saat ini:
https://github.com/kubernetes/kubernetes/pull/87758 (Disetujui, tes pengelupasan)
https://github.com/kubernetes/kubernetes/pull/87759 (WIP)
https://github.com/kubernetes/kubernetes/pull/87650 (

https://github.com/kubernetes/kubernetes/pull/87645 (PR tes e2e, perlu persetujuan)

@vpickard dapatkah Anda menambahkan PR e2e yang saya lewatkan.

Terima kasih

Terima kasih @nolancon telah menautkan PR dan masalah payung di sini. Saya telah menambahkan PR ke lembar pelacakan.

Hai @palnabarun , @nolancon ,

Beberapa PR terbuka tambahan terkait dengan tes E2E:
https://github.com/kubernetes/test-infra/pull/16062 (perlu ditinjau dan disetujui)
https://github.com/kubernetes/test-infra/pull/16037 (perlu ditinjau dan disetujui)

Terima kasih @vpickard untuk pembaruan tambahan. :)

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

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

Hai @irvifa , terima kasih atas perhatiannya. Saya telah membuka PR di sini kubernetes/website#19050 dengan beberapa perubahan kecil. PR ini adalah WIP untuk saat ini, saya akan menghapusnya dari WIP setelah kriteria untuk pindah ke Beta terpenuhi (PR di atas masih dalam peninjauan).
Terima kasih.

Hai @nolancon terima kasih atas tanggapan cepat Anda, saya mengubah status menjadi Placeholder PR sekarang.. Terima kasih!

@palnabarun FYI, saya telah membagi PR ini https://github.com/kubernetes/kubernetes/pull/87759 menjadi dua PR untuk memudahkan proses peninjauan. Yang kedua ada di sini https://github.com/kubernetes/kubernetes/pull/87983 dan juga perlu dilacak. Terima kasih.

@nolancon Terima kasih atas pembaruannya.

Saya melihat ada beberapa PR yang masih menunggu untuk digabung. Saya ingin melihat apakah Anda memerlukan bantuan dari tim rilis untuk mendapatkan Reviewer dan Approvers ke PR. Beri tahu kami jika Anda membutuhkan sesuatu.

FYI, kami sangat dekat dengan Code Freeze pada tanggal 5 Maret

@nolancon Terima kasih atas pembaruannya.

Saya melihat ada beberapa PR yang masih menunggu untuk digabung. Saya ingin melihat apakah Anda memerlukan bantuan dari tim rilis untuk mendapatkan Reviewer dan Approvers ke PR. Beri tahu kami jika Anda membutuhkan sesuatu.

FYI, kami sangat dekat dengan Code Freeze pada tanggal 5 Maret

@palnabarun Satu pembaruan lagi, https://github.com/kubernetes/kubernetes/pull/87983 sekarang ditutup dan tidak perlu dilacak. Perubahan yang diperlukan disertakan dalam PR asli https://github.com/kubernetes/kubernetes/pull/87759 yang sedang ditinjau.

@nolancon Keren. Saya juga melacak masalah pelacak payung yang Anda bagikan di atas. :)

Hai @nolancon , ini pengingat bahwa kita hanya tinggal dua hari lagi dari Code Freeze pada tanggal 5 Maret .

Dengan Pembekuan Kode, semua PR yang relevan harus digabungkan jika tidak, Anda perlu mengajukan permintaan pengecualian.

Hai @nolancon ,

Hari ini EOD adalah Code Freeze .

Apakah menurut Anda https://github.com/kubernetes/kubernetes/pull/87650 akan ditinjau sebelum batas waktu?

Jika tidak, silakan ajukan permintaan pengecualian .

Hai @nolancon ,

Hari ini EOD adalah Code Freeze .

Apakah menurut Anda kubernetes/kubernetes#87650 akan ditinjau sebelum batas waktu?

Jika tidak, silakan ajukan permintaan pengecualian .

Hai @palnabarun , banyak kemajuan telah dibuat dalam beberapa hari terakhir dan kami yakin semuanya akan disetujui dan digabungkan sebelum pembekuan kode. Jika tidak, saya akan mengajukan permintaan pengecualian.

Hanya untuk memperjelas, dengan EOD maksud Anda jam 5 sore atau tengah malam PST? Terima kasih

Hanya untuk memperjelas, dengan EOD maksud Anda jam 5 sore atau tengah malam PST? Terima kasih

17:00 PST.

PR disetujui tetapi tidak ada tonggak yang perlu ditambahkan oleh sig-node untuk digabungkan. Saya telah melakukan ping dengan lambat, semoga tidak macet dan Anda tidak perlu pengecualian. =)

Semua PR untuk kep ini tampaknya telah digabungkan (dan disetujui oleh tenggat waktu), saya telah memperbarui lembar pelacakan penyempurnaan kami. :senyum:

/pencapaian jelas

(menghapus masalah peningkatan ini dari tonggak v1.18 saat tonggak selesai)

Hai @nolancon @lmdaly , peningkatan bayangan untuk 1,19 di sini. Ada rencana untuk ini di 1.19?

Satu-satunya peningkatan yang direncanakan untuk 1,19 adalah ini:
https://github.com/kubernetes/enhancements/pull/1121

Pekerjaan lainnya akan dilakukan pada pemfaktoran ulang kode/perbaikan bug jika diperlukan.

Apakah ada cara untuk mengubah pemilik masalah ini menjadi saya alih-alih @lmdaly?

Terima kasih, saya akan memperbarui kontak.

/tonggak sejarah v1.19

/assign @klueska
/batalkan penetapan @lmdaly

Ini dia, Kevin https://prow.k8s.io/command-help

Hai Kevin. Baru-baru ini format KEP telah berubah, dan juga #1620 bergabung minggu lalu, menambahkan pertanyaan tinjauan kesiapan produksi ke template KEP. Jika memungkinkan, mohon luangkan waktu untuk memformat ulang KEP Anda dan juga menjawab pertanyaan add to template . Jawaban atas pertanyaan tersebut akan sangat membantu operator yang menggunakan dan memecahkan masalah fitur tersebut (khususnya bagian pemantauan pada tahap ini). Terima kasih!

@klueska ^^

@derekwaynecarr @klueska @johnbelamaric
Saya juga berencana untuk menambahkan kebijakan topologi baru pada 1,19 rel.
Namun belum mendapatkan review dari pemilik dan pengelola.
(Jika tampaknya sulit untuk membuat di 1.19, beri tahu saya.)

• Perbarui KEP PR: https://github.com/kubernetes/enhancements/pull/1752
• PR untuk kubelet: WIP

Hai @klueska 1.19 dokumen bayangan di sini! Apakah pekerjaan peningkatan yang direncanakan untuk 1.19 ini memerlukan dokumen baru atau modifikasi?

Pengingat ramah bahwa jika baru/modifikasi dokumen diperlukan, PR placeholder terhadap k/website (cabang dev-1.19 ) diperlukan pada hari Jumat, 12 Juni.

Hai @klueska harap Anda baik-baik saja, periksa lagi untuk melihat apakah dokumen diperlukan untuk ini atau tidak. Dapatkah kamu mengkonfirmasi?

Hai @annajung. Ada 2 peningkatan tertunda yang keduanya memerlukan perubahan dokumen:

1121

1752

Kami masih memutuskan apakah ini akan membuatnya menjadi 1,19 atau didorong ke 1,20. Jika kami memutuskan untuk menyimpannya untuk 1,19, saya pasti akan membuat PR pengganti untuk dokumen paling lambat 12 Juni.

Besar! Terima kasih atas pembaruannya, saya akan memperbarui lembar pelacakan yang sesuai! Tolong beri tahu saya setelah PR placeholder dibuat. Terima kasih!

@lmdaly @ConnorDoyle
Saya harap di sini adalah tempat yang tepat untuk bertanya dan memberi masukan.

Saya mengaktifkan TopologyManager dan CPUManager pada k8s cluster v1.17.
dan kebijakan mereka adalah best-effort dan static
Ini adalah sumber daya pod saya

      resources:
        requests:
          cpu: 2
          intel.com/sriov_pool_a: '1'
        limits:
          cpu: 2
          intel.com/sriov_pool_a: '1'

PF dari sriov_pool_a ada di NUMA node 0, jadi saya berharap pod saya harus berjalan di cpu NUMA node 0 juga.
Tetapi saya menemukan proses pod saya berjalan di cpu NUMA node 1.
Juga, tidak ada topeng afinitas cpu yang disetel sesuai dengan hasil taskset -p <pid> .

Apakah ada yang salah? Saya berharap wadah harus memiliki topeng afinitas cpu yang disetel untuk cpu numa node 0.

Apakah ada contoh atau tes yang dapat saya lakukan untuk mengetahui apakah TopoloyManager berfungsi dengan benar?

@annajung Placeholder docs PR ditambahkan: https://github.com/kubernetes/website/pull/21607

Hai @klueska ,

Untuk menindaklanjuti email yang dikirim ke k-dev pada hari Senin, saya ingin memberi tahu Anda bahwa Code Freeze telah diperpanjang hingga Kamis, 9 Juli. Anda dapat melihat jadwal yang direvisi di sini: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19
Kami berharap semua PR akan digabung pada saat itu. Tolong beri tahu saya jika Anda memiliki pertanyaan. 😄

Terbaik,
Kirsten

Hai @klueska , pengingat ramah tentang tenggat waktu berikutnya yang akan datang.
Harap ingat untuk mengisi PR dokumen placeholder Anda dan menyiapkannya untuk ditinjau paling lambat Senin, 6 Juli.

Terima kasih @annajung . Karena pembekuan kode sekarang telah dipindahkan ke 9 Juli, apakah masuk akal untuk mendorong tanggal dokumen juga? Apa yang terjadi jika kita membuat dokumentasi, tetapi fitur tersebut tidak masuk tepat waktu (atau membuatnya dalam bentuk yang sedikit berbeda dari yang disarankan oleh dokumentasi)?

Hai @klueska , itu poin yang bagus! Semua tenggat waktu dokumen juga telah didorong seminggu dengan tanggal rilis baru, tetapi saya pikir Anda memiliki poin yang valid. Izinkan saya menghubungi pimpinan dokumen untuk rilis dan menghubungi Anda kembali! Terima kasih telah menunjukkan ini!

Hai @klueska , sekali lagi terima kasih telah

Namun, setelah berbicara dengan tim rilis, kami telah memutuskan untuk mempertahankan tanggal rilis 1,19 ini dengan membuat "PR siap untuk ditinjau" sebagai tenggat waktu yang lunak. Tim Dokumen akan fleksibel dan bekerja dengan Anda/orang lain yang mungkin membutuhkan waktu ekstra untuk memastikan dokumen disinkronkan dengan kode. Meskipun tenggat waktu "PR siap untuk ditinjau" tidak akan diberlakukan, "PR ditinjau dan dibaca untuk digabungkan" akan diberlakukan.

Semoga ini bisa membantu menjawab kekhawatiran Anda! Beri tahu saya jika Anda memiliki pertanyaan lagi!

Juga, hanya pengingat tanggal yang ramah:
"Batas waktu dokumen - PR siap ditinjau" paling lambat tanggal 6 Juli
"Dokumen selesai - Semua PR ditinjau dan siap digabungkan" akan jatuh tempo paling lambat 16 Juli

Hai @klueska :wave: -- 1.19 Enhancements Lead di sini,

Bisakah Anda menautkan ke semua PR implementasi di sini, sehingga tim rilis dapat melacaknya? :slightly_smiling_face:

Terima kasih.

@palnabarun
Pelacakan PR https://github.com/kubernetes/enhancements/pull/1121 dapat ditemukan di:
https://github.com/kubernetes/kubernetes/pull/92665

Sayangnya peningkatan #1752 tidak akan berhasil dirilis, jadi tidak ada PR untuk melacaknya.

Hai @klueska :wave:, Saya melihat bahwa kedua PR (https://github.com/kubernetes/enhancements/pull/1121 dan https://github.com/kubernetes/enhancements/pull/1752) yang Anda sebutkan mengacu pada peningkatan yang sama. Karena https://github.com/kubernetes/enhancements/pull/1752 memperluas persyaratan kelulusan Beta dan mereka tidak akan berhasil memasuki rilis, dapatkah kita berasumsi bahwa tidak ada perubahan lebih lanjut yang diharapkan di 1.19?

Terima kasih. :slightly_smiling_face:

Code Freeze dimulai pada Kamis, 9 Juli EOD PST

@palnabarun Ini adalah PR lanjutan ke #92665 yang akan mendarat hari ini atau besok: https://github.com/kubernetes/kubernetes/pull/92794

Setelah itu seharusnya tidak ada lagi PR untuk rilis ini, menunggu bug yang tidak terduga.

Luar biasa! Terima kasih atas pembaruannya. :+1:

Kami akan mengawasi https://github.com/kubernetes/kubernetes/pull/92794.

@annajung https://github.com/kubernetes/website/pull/21607 sekarang siap untuk ditinjau.

Selamat @klueska kubernetes/kubernetes#92794 akhirnya bergabung, saya akan memperbarui lembar pelacakan sesuai

/pencapaian jelas

(menghapus masalah peningkatan ini dari tonggak v1.19 saat tonggak selesai)

Hai @klueska

Peningkatan Pimpin di sini. Apakah ada rencana untuk lulus di 1,20?

Terima kasih!
Kirsten

Tidak ada rencana untuk lulus, tetapi ada PR yang harus dilacak untuk 1,20 terkait dengan peningkatan ini:
https://github.com/kubernetes/kubernetes/pull/92967

Meskipun tidak lulus di 1.20, harap terus hubungkan PR terkait dengan masalah ini seperti yang baru saja Anda lakukan.

@kikisdeliveryservice dapatkah Anda membantu memahami prosesnya. Fitur Topology Manager tidak lulus di 1.20, tetapi fitur baru akan ditambahkan ke dalamnya dan sedang dikerjakan sekarang: https://github.com/kubernetes/enhancements/pull/1752 k/k: https://github. com/kubernetes/kubernetes/pull/92967. Apakah ini sesuatu yang perlu kita lacak dengan tim rilis? Ini dapat menyederhanakan pelacakan pembaruan dokumen untuk 1.20 atau mungkin sesuatu yang sedang dilacak.

Perubahannya bersifat aditif sehingga tidak ada banyak alasan untuk menyebutnya beta2 atau semacamnya.

PR benjolan terkait yang mencerminkan kenyataan bahwa fitur tambahan tidak dikirimkan di 1.19: https://github.com/kubernetes/enhancements/pull/1950

Pembaruan dokumentasi web Manajer Topologi PR untuk menyertakan fitur cakupan: https://github.com/kubernetes/website/pull/24781

Saya percaya itu dapat dilacak dengan 1,20 dan tidak harus lulus. @kikisdeliveryservice silakan berpadu jika itu tidak benar. Saya akan melacak k/situs web yang dibagikan sebagai bagian dari rilis 1.20 sampai saya mendengar sebaliknya.

Hai @SergeyKanzhelev

Dilihat dari sejarahnya sebenarnya tidak demikian. Saya diberitahu bahwa ini tidak akan lulus di atas, yang baik-baik saja dan mengapa KEP ini tidak terlacak. Namun, peningkatan ini (tanpa sepengetahuan tim peningkatan) baru-baru ini ditargetkan ulang oleh @k-wiatrzyk untuk 1,20 sebagai beta (https://github.com/kubernetes/enhancements/pull/1950).

Jika Anda ingin memanfaatkan proses rilis: pelacakan peningkatan, menjadi bagian dari pencapaian rilis dan memiliki tim dokumen yang melacak ini/memiliki dokumen yang disertakan dalam rilis 1.20, permintaan pengecualian peningkatan harus diajukan ASAP.

Fitur tersebut telah digabungkan ke dalam KEP (sebelumnya sudah ada) (sebelum batas waktu penyempurnaan).
https://github.com/kubernetes/enhancements/pull/1752

Pada implementasinya PR sudah menjadi bagian dari milestone.
https://github.com/kubernetes/kubernetes/pull/92967

Saya tidak sadar ada lagi yang harus dilakukan.

Dengan siapa kita perlu mengajukan pengecualian, dan untuk apa sebenarnya?

Hai @klueska , pr yang Anda rujuk digabungkan pada bulan Juni untuk menambahkan beta ke kep di 1.19: https://github.com/bg-chun/enhancements/blob/f3df83cc997ff49bfbb59414545c3e4002796f19/keps/sig-node/0035-20190130-topology -manager.md

Batas waktu peningkatan untuk 1,20 adalah 6 Oktober tetapi perubahannya, memindahkan beta ke 1,20 dan menghapus referensi ke 1,19 digabungkan 3 hari yang lalu melalui https://github.com/kubernetes/enhancements/pull/1950

Anda dapat menemukan instruksi untuk mengirim permintaan pengecualian di sini: https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

Maaf, saya masih bingung untuk apa kami akan mengajukan pengecualian.
Saya senang melakukannya, saya hanya tidak yakin apa yang harus disertakan di dalamnya.

Fitur "Pengelola Topologi Node" sudah lulus ke beta di 1.18.
Itu tidak lulus ke GA di 1,20 (tetap dalam versi beta).

PR yang digabungkan untuk 1,20 (yaitu kubernetes/kubernetes#92967) merupakan peningkatan dari kode yang ada untuk Manajer Topologi, tetapi tidak terkait dengan "bump" dalam hal statusnya sebagai alpha/beta/ga, dll.

Saya telah mengirim surat Panggilan Pengecualian karena batas waktunya adalah hari ini (untuk berjaga-jaga): https://groups.google.com/g/kubernetes-sig-node/c/lsy0fO6cBUY/m/_ujNkQtCCQAJ

@kikisdeliveryservice @klueska @annajung
Panggilan untuk Pengecualian telah disetujui, Anda dapat menemukan konfirmasi di sini: https://groups.google.com/g/kubernetes-sig-release/c/otE2ymBKeMA/m/ML_HMQO7BwAJ

Terima kasih @k-wiatrzyk & @klueska Memperbarui lembar pelacakan.

cc: @annajung

Hai @k-wiatrzyk @klueska

Sepertinya kubernetes/kubernetes#92967 disetujui tetapi membutuhkan rebase.

Sekedar mengingatkan bahwa Code Freeze akan hadir 2 hari lagi pada hari Kamis, 12 November . Semua PR harus digabungkan pada tanggal tersebut, jika tidak, Pengecualian diperlukan.

Terbaik,
Kirsten

PR bergabung, memperbarui lembar - yay! :smile_cat: