@lavalamp Saya telah membuat ini untuk mencoba memiliki tempat di mana kita setidaknya dapat mengkonsolidasikan pemikiran kita dan melacak kemajuan pada sumber daya pihak ketiga. Saya sudah mencoba membuat daftar kekurangan yang diketahui untuk diselesaikan sebelum promosi ke stabil.

Saya tidak memikirkan pemilik, tetapi mengenali masalahnya sepertinya seperti langkah 1.

@deads2k Saya baru-baru ini mempelajari sumber daya pihak ketiga, juga ingin membantu dengan sesuatu.

@deads2k Saya baru-baru ini mempelajari sumber daya pihak ketiga, juga ingin membantu dengan sesuatu.

Saya telah menyusun ulang daftar dalam hal apa yang saya lihat sebagai prioritas taktis. Orang-orang mencoba menggunakan ini sekarang dan masalah ini akan membakar mereka dengan buruk.

Jika Anda merasa nyaman mengambil item "banyak sumber daya", itu akan menjadi awal yang baik. Anda dapat membuat masalah terpisah dan kita dapat berbicara tentang implementasi di sana.

@deads2k Saya menghabiskan beberapa waktu mencoba mereproduksi masalah pertama:

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

tapi dengan ketidakberuntungan. Di bawah ini adalah langkah-langkah reproduksi saya:

1. buat sumber daya pihak ketiga khusus&tunggu muncul

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. setelah beberapa saat (lebih dari 10 detik), buat sumber daya pihak ketiga khusus lainnya

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. verifikasi kedua sumber daya ada

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

sepertinya kami sudah mendukung banyak sumber daya, versi tunggal.

Dan saya melihat lebih dalam pada kode terkait TPR. thirdparty_controller akan melakukan sinkronisasi secara berkala (setiap 10 detik), ia akan menginstal setiap TPR baru, dan juga melakukan beberapa pekerjaan penghapusan. ThirdPartyResourceServer berisi semua pemetaan TPR yang diinstal. Seperti yang dapat kita lihat dari SyncOneResource dan InstallThirdPartyResource , meskipun grup ini ada, grup ini akan tetap diperbarui dengan API baru.

Saya juga menemukan bahwa saya dapat menghapus skema TPR def bahkan ada contoh TPR dalam sistem. Saya pikir ini tidak boleh dibiarkan.

@deads2k Saya menghabiskan beberapa waktu mencoba mereproduksi masalah pertama:

Coba aktifkan tes ini: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Jika berhasil, kami baik-baik saja. Jika gagal, ada yang salah.

@deads2k Hai David, tolong lihat pesan yang saya kirim di Slack. Selain itu, saya menambahkan perbaikan pada tes integrasi yang gagal, pengontrol sumber daya pihak ketiga akan menghapus penangan rute yang sesuai ketika TPR dihapus, ini akan membantu dengan tes integrasi, tetapi saya tidak yakin apakah ini akan membawa masalah lain .

Untuk masalah #1, sudah diperbaiki di sini:

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

@brendandburns sebenarnya tidak, Anda dapat menjalankan tes integrasi komentar, dan itu akan gagal.

@brendandburns Lebih tepatnya, kami mendukung banyak sumber daya, versi tunggal, tetapi penghapusan logis memiliki beberapa masalah.

@AdoHe apakah Anda mengajukan masalah? Saya bisa melihat-lihat.

@brendandburns Anda dapat melihat di sini:

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

aktifkan tes ini, dan Anda akan melihatnya gagal. Saya telah mencoba untuk memperbaiki ini di lokal saya, dan saya akan membuka PR hari ini.

@brendandburns Saya khawatir saya tidak mengajukan masalah.

Juga ref https://github.com/kubernetes/kubernetes/issues/32306 (TPR harus dihapus ketika namespace dihapus)

@deads2k dapatkah Anda memperbarui daftar periksa?

@deads2k dapatkah Anda memperbarui daftar periksa?

Semua masalah masih beredar. Ini sebenarnya adalah fitur untuk melacak masalah dalam implementasi (sudah) beta thirdparyresources dari 1.3. Kami membutuhkan tempat untuk melacak masalah kami, tetapi harus mencurahkan energi untuk upaya lain di 1.5.

@deads2k Saya sudah mengerjakan Multiple Resources, single version dan Multiple versions , saya pikir banyak kode yang perlu diperbarui.

@deads2k apakah fitur masih menargetkan 1.5?

@idvoretskyi saya takut tidak :(

@deads2k : ThirdPartyResources harus ditambahkan ke API

@deads2k : Saat ini penyeleksi bidang tidak berfungsi saat menanyakan ThirdPartyObjects, apakah itu sesuatu untuk daftar Anda?

@deads2k @rmohr kubectl masih memiliki banyak kemampuan luar biasa melawan TPR, daftar di atas harus diperbarui untuk melacaknya.

@deads2k : Saat ini penyeleksi bidang tidak berfungsi saat menanyakan ThirdPartyObjects, apakah itu sesuatu untuk daftar Anda?

Itu masalah yang lebih umum dari dukungan pemilih bidang yang tidak konsisten di semua jenis API.

Saya mulai melihat ini juga. ThirdPartyResources sangat penting untuk mendukung pengontrol "eksternal" seperti spark , dan sebelum kita dapat menambahkan hal-hal seperti sub-sumber daya, kita harus memperbaikinya.

Pemilih bidang hanya berfungsi pada bidang yang dikurasi dengan tangan di objek API biasa. Saya tidak berharap mereka bekerja untuk bidang apa pun di TPR - apiserver tidak dibuat untuk melakukan kueri sewenang-wenang. Jika Anda membutuhkan perilaku itu, TPR tidak akan bekerja untuk Anda.

Apakah langkah selanjutnya di sini untuk memindahkan TPR ke server addon API ?
Sepertinya ada beberapa PR luar biasa untuk memperbaiki beberapa masalah dalam daftar di sini yang mungkin diblokir pada item ini.

/cc @liggitt @deads2k @AdoHe

Untuk mengurangi kompleksitas TPR dalam kode apiserver dan membuat logika TPR jauh lebih eksplisit, saya pasti akan memilih tpr-apiserver mandiri. Tapi IMO ini tidak benar-benar memblokir perbaikan apa pun.

Saya menambahkan beberapa item tentang menangani semantik API (dapatkan, daftar, tonton, perbarui, tambalan) saat menangani beberapa Jenis yang tidak dapat dikonversi. Saya pikir itu mungkin memerlukan dokumen desain, karena semantik tidak mungkin cocok dengan semantik API normal.

Saya akan mencoba (lagi) untuk memperbaiki beberapa masalah ini...

https://github.com/kubernetes/kubernetes/pull/40260 dan https://github.com/kubernetes/kubernetes/pull/40096 akan membuat kita dalam kondisi yang layak di sisi kubectl

Masalah sisi server yang paling parah saat ini adalah pengumpul sampah kehilangan akal atas pemilikRefs yang mengarah ke TPR.

Setelah kami menyelesaikannya, kami harus memutuskan apa semantik API di sekitar beberapa versi TPR yang diberikan, dan memastikan jenis TPR memiliki data yang kami butuhkan. Itu kemungkinan akan mempengaruhi impl penyimpanan sisi server, jadi saya lebih suka memakukan desain sebelum kita melakukan terlalu banyak pekerjaan sisi server.

@liggitt Saya akan melihat

Adakah yang punya petunjuk tentang cara merujuk TPR dalam aturan RBAC? Saya memiliki TPR bernama seperti foo-bar.something.example.com. Sebagai admin cluster, saya bisa mendapatkan daftar foobar di namespace tertentu dengan kubectl get foobars .

Ketika pengguna biasa mencoba hal yang sama, mereka mendapatkan Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

Saya telah mencoba setiap variasi foobar, foo-bar, dll. yang dapat saya pikirkan dalam aturan RBAC sejauh ini tidak berhasil.

Dalam aturan, Anda mencari resource=foobars apigroup=something.example.com verb=get,list,watch

@deads2k Itu berhasil. Terima kasih!

@liggitt

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

ada yang berhubungan dengan masalah pembersihan TPR?

Tidak, itu adalah masalah dengan pengumpul sampah yang tidak tahu cara mencari ownerRefs selain yang dikompilasi dalam tipe. Masalah sebaliknya juga ada, dengan pengumpul sampah tidak memperhatikan finalizer pada apa pun selain tipe yang dikompilasi.

Kedua masalah pengumpul sampah tersebut berbeda dari kebutuhan untuk membersihkan objek ThirdPartyResourceData secara andal saat objek ThirdPartyResource dihapus.

@liggitt Terima kasih atas penjelasan pasien, jadi apa rencana TPR di 1.6?

GC sekarang hanya mencatat 1.000 kali per detik, bukan 50 ribu kali per detik,
sehingga tidak lagi memenangkan perlombaan dengan log rotator. Tapi perbaikan nyata akan terjadi
segera hadir, semoga.

Pada Sabtu, 4 Februari 2017 pukul 23.54, TonyAdo [email protected] menulis:

@liggitt https://github.com/liggitt Terima kasih atas penjelasan pasien, jadi
apa rencana TPR di 1.6?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/features/issues/95#issuecomment-277503470 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAnglmGf00K6W7SsJ1aSqWOI_M-A7Hf2ks5rZYBPgaJpZM4KLBmK
.

Beberapa isu terbuka terkait TPR. Tidak lengkap.

Masalah grup/versi: https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
Tonton: https://github.com/kubernetes/kubernetes/issues/25340
Tautan mandiri :
Penghapusan namespace: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
Finalizer: https://github.com/kubernetes/kubernetes/issues/40715
Pembersihan data TPR: https://github.com/kubernetes/kubernetes/issues/35949
Validasi metadata yang lebih kuat: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
Kurangnya tes unit: https://github.com/kubernetes/kubernetes/pull/40956
Pembersihan: https://github.com/kubernetes/kubernetes/issues/36998

Fitur yang menurut pengguna adalah bug karena berfungsi untuk sumber daya lain:
Perilaku asinkron: https://github.com/kubernetes/kubernetes/issues/29002
Bilangan bulat: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
Output kubectl yang layak: https://github.com/kubernetes/kubernetes/issues/31343
Sederhanakan penamaan resource: https://github.com/kubernetes/kubernetes/issues/29415
Terapkan: https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
Sunting: https://github.com/kubernetes/kubernetes/issues/35993

/cc

Berlangganan saat kami mencoba menangani TPR di Dasbor.

Masalah pelacakan adalah https://github.com/kubernetes/dashboard/issues/1671 dan https://github.com/kubernetes/dashboard/issues/1504.

@kubernetes/dashboard-maintainers

Apa status/paket untuk TPR non-namespace? Saya tidak menemukan diskusi tentang hal itu, mungkin melewatkan sesuatu?

@sttts Untuk memulai, saya tertarik dengan perkembangan di Kubernetes. Dan saya ingin berkontribusi untuk itu, tetapi Go adalah bahasa baru bagi saya. Apa yang kalian sarankan agar saya lakukan agar saya bisa mendapatkan proyek ini untuk GSoC 2017?

Untuk menambahkan sesuatu tentang saya, saya cukup baik di C++ dan Java dan saya memegang gelar Sarjana Ilmu Komputer. Saya juga sudah mulai membaca dokumentasi dan mengambil kursus Udacity yang melibatkan Kubernetes.

@grpndrs kami memiliki daftar masalah berlabel yang merupakan titik awal yang baik untuk masuk ke kode: https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -kontributor. Jangan ragu untuk menghubungi saya di slack dan kita bisa membahas beberapa di antaranya.

@enisoc

Apakah Multiple Resources, single version, different add times masih menjadi masalah? Saya dapat membuat dan menghapus beberapa TPR tanpa masalah.

Juga, bisakah kita memberi nomor pada kotak centang di Outstanding Capabilities sehingga lebih mudah untuk dirujuk? @deads2k saya pikir Anda bisa melakukannya seperti ini:

1. - [ ] ...
2. - [ ] ...

Adakah yang tahu bagaimana komponen validasi ini datang? Saya sering bekerja dengan TPR dan fitur ini akan sangat berharga dan menghemat BANYAK kode khusus. Saya ingin berkontribusi pada fitur ini tetapi ingin tahu apakah ada yang berlangganan masalah ini mengetahui statusnya

Adakah yang tahu bagaimana komponen validasi ini datang?

Saya tidak berharap itu terjadi untuk 1.7. Saat ini, kami sedang mendiskusikan beberapa masalah pertumbuhan struktural di sini https://github.com/kubernetes/community/pull/524 untuk memberikan dasar yang lebih stabil untuk tumbuh.

Saya tidak berharap itu terjadi untuk 1.7. Saat ini, kita sedang mendiskusikan beberapa masalah pertumbuhan struktural di sini kubernetes/community#524 untuk memberikan dasar yang lebih stabil untuk tumbuh.

Kami berencana untuk bergerak maju dengan https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md dalam jangka waktu 1.7. Saya akan membuat pembaruan di sini dan di panggilan sig-apimachinery saat kita melanjutkan.

@deads2k Saya tidak melihat apa pun di sana tentang validasi tpr. Tidakkah Anda menganggap itu sebagai sesuatu yang diperlukan untuk beta?

@frankgreco proposalnya adalah tentang fondasi yang kuat untuk dibangun oleh TPR. Fitur seperti validasi dapat ditambahkan nanti, tetapi di luar cakupan di sini.

Saya telah mengedit komentar induk dari utas ini untuk menggunakan templat baru, dan untuk memperjelas ruang lingkup pekerjaan yang direncanakan untuk 1.7, seperti yang saya pahami. Silakan lihat dan perbaiki / komentar.

@deads2k @enisoc Kami baru-baru ini mulai menggunakan TPR, dan validasi TPR akan menjadi sangat penting untuk beberapa proyek kami yang akan datang. Jika kami memiliki sumber daya untuk mengerjakannya, apakah Anda akan mempertimbangkan untuk menerima kontributor komunitas untuk mewujudkannya?

@deads2k @enisoc Kami baru-baru ini mulai menggunakan TPR, dan validasi TPR akan menjadi sangat penting untuk beberapa proyek kami yang akan datang. Jika kami memiliki sumber daya untuk mengerjakannya, apakah Anda akan mempertimbangkan untuk menerima kontributor komunitas untuk mewujudkannya?

Sangat. Untuk hal seperti ini, kami menginginkan proposal desain sebelum kami mulai melihat permintaan tarik. Juga, mengingat berapa banyak pendekatan berbeda yang mungkin, saya sarankan Anda membuat daftar tiga atau lebih ide teratas dan memberikan penjelasan singkat mengapa yang Anda pilih adalah yang terbaik. Karena sisi servernya, pertimbangan kinerja dan keamanan sangat penting.

Juga, karena ini adalah fitur yang menjangkau jauh, penting untuk tidak menjadi kontribusi drive-by. Kontribusi aktif (ulasan, pengujian, kode, migrasi) untuk transisi ke https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md akan membantu. Saya mati-matian jika Anda tertarik dan ingin berbicara.

Terima kasih @deads2k! Itu sangat masuk akal. Kami akan mengajukan beberapa proposal desain untuk validasi TPR, apa cara terbaik untuk membagikannya? Aku akan mengendur juga

@xiao-zhou kami senang menerima proyek Google Summer of Code seputar topik ini (diumumkan baru kemarin). Mari mengobrol di Slack tentang cara berkolaborasi dalam hal ini. Sangat keren bahwa Anda juga tertarik dengan ini, jadi kami memiliki cukup kekuatan untuk mendorong ini ke depan!

@xiao-zhou @sttts @deads2k segera setelah Anda memiliki proposal untuk validasi TPR (dan idealnya default), beri tag saya di ulasan proposal? Terima kasih

@sdminonne itu akan diposting di sig-apimachinery. Jika Anda berlangganan grup google itu, Anda akan mendapatkan pemberitahuan.

@sttts terima kasih

@deads2k apakah Anda akan menambahkan ObservedGeneration untuk TPR?

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@deads2k apakah Anda akan menambahkan ObservedGeneration untuk TPR?

Saya tidak berencana untuk melakukannya. Tidak bisakah klien yang peduli hanya membandingkan nama spesifikasi dan status?

membandingkan nama spesifikasi dan status?

Tidak yakin apa yang Anda maksud di sini. Perbaiki saya Jika saya salah tetapi saya pikir ada dua bagian dari ObservedGeneration: 1) server API perlu memperbarui metadata.generation setiap kali ada pembaruan dalam Spesifikasi TPR dan 2) pengontrol yang bertanggung jawab atas TPR memperbarui status.observedGeneration berdasarkan metadata.Generation . Saya kira 1) adalah apa yang saya tanyakan kepada Anda dan 2) adalah sesuatu yang perlu diperhatikan oleh penulis TPR?

Tidak yakin apa yang Anda maksud di sini. Perbaiki saya Jika saya salah tetapi saya pikir ada dua bagian dari Generasi yang Diperhatikan: 1) server API perlu memperbarui metadata.generasi setiap kali ada pembaruan dalam Spesifikasi TPR dan 2) pengontrol yang bertanggung jawab atas status pembaruan TPR .observedGeneration berdasarkan metadata.Generation. Saya kira 1) adalah apa yang saya tanyakan kepada Anda dan 2) adalah sesuatu yang perlu diperhatikan oleh penulis TPR?

Oh, saya salah paham tentang hal apa yang Anda tanyakan. Anda ingin ObservasiGeneration untuk CustomResource, bukan CustomResourceDefinition. Saya pikir yang diamatiGeneration hanya terbentur untuk perubahan spesifikasi yang memerlukan tindakan. Artinya pembaruan metadata tidak memicunya dan pembaruan ke beberapa bidang spesifikasi dapat menghindari menabraknya juga.

Dalam komentar saya yang ditautkan di atas, saya meminta dukungan Generasi untuk instans TPR, bukan untuk TPR itu sendiri (walaupun itu akan menyenangkan juga. Ada alasan untuk tidak menambahkannya ke semua objek?).

Misalnya jika saya memiliki Kind: TPR; name: foo.example.com dan instance dari TPR itu Kind: Foo; name: foo123 , saya tertarik pada Generation/ObservedGeneration untuk foo123 sehingga pengontrol Foo dapat memberi tahu konsumen Foo jika telah diproses pembaruan ke instance foo123 . Apakah masuk akal? Saya tidak melihat bagaimana ini dapat dicapai tanpa dukungan yang tepat di sisi server k8s.

Ya, generasi/pengamatanGenerasi masuk akal untuk skema pengguna TPR dan bukan untuk sumber daya TPR yang sebenarnya seperti yang telah berkembang.

@kargakis Aturannya adalah hanya menambah pembuatan objek pada pembaruan spesifikasi, bukan status, bukan? Jika demikian, berarti pertama-tama kita harus secara resmi mendukung pemisahan Spec/Status pada instans TPR. Saya berencana untuk menulis proposal untuk Status TPR, menargetkan 1,8. Saya dapat memastikan untuk memasukkan pembuatan objek yang bertambah dalam proposal.

Aturannya adalah hanya menambah pembuatan objek pada pembaruan spesifikasi, bukan status, bukan?

Benar.

Jika demikian, berarti pertama-tama kita harus secara resmi mendukung pemisahan Spec/Status pada instans TPR.

Ya, saya berharap menemukan perpecahan itu sebagai bagian dari masalah yang ada tetapi tampaknya ada lebih banyak pekerjaan yang perlu dilakukan sebelum kita sampai di sana..

@kargakis Saya telah mengedit komentar tingkat atas untuk menyebutkan item-item ini, meskipun mereka berada di luar cakupan untuk 1.7.

/cc

@deads2k Haruskah kita menambahkan nama pendek untuk CustomResourceDefinition?

Menambahkan CRD nama pendek untuk CustomResourceDefinition .

Proposal desain untuk validasi CustomResources: https://github.com/kubernetes/community/pull/708 :smile:

@deads2k @enisoc @lavalamp
bertanya-tanya apakah pengguna dapat mengonfigurasi pengontrol k8s DAN (ATAU) metode CURD untuk objek CRD

Dalam kasus penggunaan khusus saya, saya membuat networks.stable.example.com CRD & menggunakannya untuk membuat objek Jaringan net1:

Saya perlu memastikan objek Network CRD baru tidak boleh dibuat jika objek Network CRD dengan rentang subnet yang tumpang tindih sudah ada

Jika mekanisme seperti itu tidak ada, saya akan dengan senang hati menyatukan beberapa pemikiran dalam dokumen desain.

Seperti yang disebutkan dalam catatan rilis dan dokumen 1.7, TPR sekarang tidak digunakan lagi dan kami berencana untuk menghapusnya di versi 1.8. Pengguna harus beralih ke CRD selama jangka waktu 1.7.

Silakan komentari masalah pelacakan untuk dihapus jika Anda memiliki pertanyaan atau masalah.

Pembaruan/Rencana untuk 1.8:

• Mendukung validasi dan default berbasis Skema JSON untuk CustomResources ( proposal )
• Tambahkan sub-sumber daya (seperti status dan skala) untuk CR (~proposal akan segera keluar~ proposal )

Terima kasih @nikhita. Saya telah mengedit komentar teratas untuk mencerminkan 1,8 paket.

Discovery mengembalikan informasi yang benar untuk CR tetapi REST mapper tidak menggunakannya - https://github.com/kubernetes/kubernetes/issues/49948

Proposal untuk SubResources untuk CustomResources: https://github.com/kubernetes/community/pull/913 :tada:

Maafkan kesalahan posting saya, tetapi saya datang ke halaman ini dari beberapa halaman kubernetes lain dengan berpikir bahwa kubernetes menyertakan kerangka layanan mikro, lebih dari sekadar mengelola sumber daya wadah pihak ketiga.

Redhat memasarkan OpenShift kubernetes sebagai platform layanan mikro, tetapi sepertinya saya tidak dapat menemukan fitur ini. Saya mencari server aplikasi seperti itu, untuk meng-host suite saya sendiri dari layanan mikro aplikasi independen yang sangat ringan.

Apakah hal seperti itu ada, atau apakah kita diturunkan untuk membuat aplikasi perang java gemuk di springboot dan menyebarkannya di server Tomcat yang berada di dalam wadah terkelola kuberenetes, yang sulit dikelola dan sulit diterapkan. Saya memerlukan platform layanan mikro tempat 1 administrator dapat mengelola dan mengoperasikan 100-an layanan mikro.

Apakah pertanyaan ini masuk akal?

@hectoralicea repo ini digunakan untuk merencanakan fitur yang dikerjakan oleh pengembang Kubernetes.

Untuk pertanyaan umum seperti ini, silakan kirim ke grup pengguna Kubernetes. Mereka biasanya jauh lebih membantu untuk diskusi tingkat tinggi semacam ini :)

Lihat https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ , atau Stack Overflow.

@colemickens @deads2k @nikhita @enisoc Saya telah menambahkan bagian untuk 1.9.

@sttts Peningkatan versi beta di v1.9, kan?

@luxas perbaikan bug tentu saja. Tapi saya rasa kita tidak perlu mencantumkannya di sini.

@sttts Saya sedang memikirkan validasi CRD... apakah yang tercakup dalam masalah fitur ini dan akan lulus ke beta di v1.9 atau?

@luxas dari postingan awal

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

Oh, terima kasih @kargakis , tidak melihat ke sana :facepalm: :smile:

@deads2k , @enisoc tidak ada rencana untuk "stabil" di 1.9, kan?

@idvoretskyi Benar.

@deads2k :wave: Silakan buka PR dokumentasi dan tambahkan tautan ke spreadsheet pelacakan. Terima kasih sebelumnya!

@deads2k Silakan buka PR dokumentasi dan tambahkan tautan ke spreadsheet pelacakan. Terima kasih sebelumnya!

@zacharysarah sepertinya saya salah menaruh tautan spreadsheet. Dokumen untuk validasi CRD di sini https://github.com/kubernetes/website/pull/6066

Sebagai catatan, masalah versi CRD ada di sini: https://github.com/kubernetes/features/issues/544.

Daftar tugas untuk CRD pindah ke GA: https://github.com/kubernetes/kubernetes/issues/58682

@nikhita apakah itu berarti seluruh fitur CRD pindah ke GA?

apakah itu berarti seluruh fitur CRD pindah ke GA?

API akan pindah ke GA, yaitu ke v1, mungkin dengan beberapa sub-fitur beta/alfa. Itu tidak dihentikan meskipun kapan ini akan terjadi, yaitu apakah 1,10 layak.

@sttts @nikhita dapatkah Anda mendefinisikan peta jalan fitur dengan lebih tepat?

dapatkah Anda mendefinisikan peta jalan fitur dengan lebih tepat?

Untuk 1.10:

• subsumber daya untuk sumber daya khusus dan perbaikan bug (setidaknya yang tidak dicoret) yang tercantum di https://github.com/kubernetes/kubernetes/issues/58682.

Tidak ada _exact_ set kiriman yang direncanakan untuk rilis berikutnya tetapi rencananya adalah untuk GA pada akhir tahun (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

Kami akan pergi ke GA setelah semua masalah yang tidak dicoret di https://github.com/kubernetes/kubernetes/issues/58682 akan selesai.

Ketika api CRD berjalan GA, mungkin ada fitur di dalamnya (contoh: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35) yang bisa dalam alfa/beta.

@sttts @nikhita @deads2k
Ada rencana untuk ini di 1.11?

Jika demikian, dapatkah Anda memastikan bahwa fitur tersebut mutakhir dengan yang sesuai:

• Keterangan
• Tonggak pencapaian
• Penerima Tugas
• Label:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Ada rencana untuk ini di 1.11?

Saya tidak memiliki izin untuk mengedit badan PR (jika seseorang bisa melakukannya, itu bagus!). Tapi rencananya adalah:

• Menerapkan versi CRD. Ini memiliki masalah fitur lain: https://github.com/kubernetes/features/issues/544. Proposal desain: https://github.com/kubernetes/community/pull/2026.
• Tambahkan pemangkasan dan pengaturan default untuk sumber daya khusus.
• Peta dukungan dalam skema validasi CRD. https://github.com/kubernetes/kubernetes/issues/59485
• Terapkan dukungan kuota untuk sumber daya khusus (ini juga dapat dianggap sebagai perbaikan bug) https://github.com/kubernetes/kubernetes/issues/53777

Jika demikian, dapatkah Anda memastikan bahwa fitur tersebut mutakhir dengan yang sesuai:
Keterangan

Deskripsi satu baris harus diperbarui untuk menyertakan "Tambahkan validasi, default, subsumber daya, dan pembuatan

Proposal desain yang disebutkan dalam deskripsi harus mencakup:

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

Bisakah seseorang menambahkan ini di badan PR juga?

Label:

/jenis fitur

/ cc @mbohlool

Bisakah seseorang menambahkan ini di badan PR juga?

selesai

@nikhita @sttts @mbohlool -- hanya untuk memperjelas, apakah kami menargetkan beta untuk siklus 1.11?

@nikhita @sttts @mbohlool -- ping lagi ini...
Apakah kami menargetkan beta untuk 1.11? Hanya ingin memastikan sebagai fitur pembekuan hari ini.

@justaugutus CRD sudah beta. GA tidak direncanakan untuk 1.11.

Semua fitur/ekstensi yang terdaftar (pemangkasan, default, pembuatan versi) mungkin akan dimulai sebagai alfa.

@sttts Hmmm, dalam hal ini, haruskah kita memiliki masalah terpisah untuk melacak fitur/ekstensi tersebut dan tahapannya secara mandiri?

Untuk merekam - @nikhita telah membuat masalah untuk subfitur https://github.com/kubernetes/features/issues/571

@sttts @justaugutus

Masalah sub-fitur default dan Pemangkasan: https://github.com/kubernetes/features/issues/575

@justaugutus @idvoretskyi untuk tujuan pelacakan 1.12: akan ada penambahan dan mungkin perbaikan bug tetapi ini akan tetap dalam versi beta untuk 1.12 (jadi tidak ada perubahan dari perspektif fitur).

Ada sub-fitur baru yang direncanakan sebagai alfa, tetapi dibuat sebagai edisi terpisah: https://github.com/kubernetes/features/issues/575.

Hai
Peningkatan ini telah dilacak sebelumnya, jadi kami ingin memeriksa dan melihat apakah ada rencana untuk menyelesaikan tahap ini di Kubernetes 1.13. Rilis ini ditargetkan lebih 'stabil' dan memiliki timeline yang agresif. Harap sertakan peningkatan ini hanya jika ada tingkat kepercayaan yang tinggi bahwa perangkat tersebut akan memenuhi tenggat waktu berikut:

• Dokumen (PR placeholder terbuka): 11/8
• Kode Lumpur: 11/9
• Pembekuan Kode Dimulai: 11/15
• Dokumen Lengkap dan Diulas: 27/11

Harap luangkan waktu sejenak untuk memperbarui pencapaian pada pos asli Anda untuk pelacakan di masa mendatang dan ping ke @kacole2 jika perlu disertakan dalam Lembar Pelacakan Peningkatan 1.13

Terima kasih!

Peningkatan ini telah dilacak sebelumnya, jadi kami ingin memeriksa dan melihat apakah ada rencana untuk menyelesaikan tahap ini di Kubernetes 1.13.

Tidak, tidak ada rencana untuk lulus ini di 1.13. CRD API akan tetap dalam versi beta.

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

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

@claurence CRD API akan tetap dalam versi beta untuk 1,14 juga.

Halo @nikhita @deads2k , 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. KEP perlu digabungkan untuk penyertaan 1,15 juga. Terima kasih!

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

ini akan tetap dalam tahap beta. bekerja pada validasi, konversi, dan penerbitan OpenAPI terjadi di 1.15

deskripsi yang diperbarui dengan tautan ke KEP yang relevan untuk 1,15

Hei, @liggitt @deads2k @jpbetz @sttts Saya adalah bayangan rilis dokumen

Apakah peningkatan ini (atau pekerjaan yang direncanakan untuk v1.15) 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! 😄

@deads2k @jpbetz @sttts @liggitt

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! 😄

Dokumen PR untuk 1.15: https://github.com/kubernetes/website/pull/14583

@deads2k dapatkah Anda memperbarui deskripsi masalah?

/tonggak sejarah v1.16
/stadium stabil

Hei, @liggitt @jpbetz @sttts Saya pemimpin rilis dokumen v1.16.

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

Sekedar pengingat bahwa kami sedang mencari PR terhadap k/website (cabang dev-1.16) yang jatuh tempo pada hari Jumat, 23 Agustus. Beri tahu saya jika Anda memiliki pertanyaan!

@simonswine PR pengganti https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts Kamis adalah pembekuan kode. Apakah ada PR k/k yang luar biasa yang akan mencegah hal ini untuk lulus ke Stabil? Segala sesuatu di pos asli untuk pekerjaan 1,15* yang direncanakan tampaknya digabungkan.

Saya percaya PR yang luar biasa hanyalah benjolan versi gerbang fitur (https://github.com/kubernetes/kubernetes/pull/81965) dan dua perbaikan bug luar biasa yang harus dilakukan dalam minggu ini: https://github.com/kubernetes /kubernetes/pull/81436 , https://github.com/kubernetes/kubernetes/issues/78707

dokumen siap ditinjau di https://github.com/kubernetes/website/pull/15982

Dirilis sebagai stabil di v1.16.0

Pekerjaan pasca-GA dilacak di https://github.com/orgs/kubernetes/projects/28

/Menutup

@liggitt : Menutup masalah ini.