Perhatikan bahwa kami mungkin juga harus mengganti nama layanan menjadi lbservice atau semacamnya untuk membedakannya dari jenis layanan lainnya.

Sebagai bagian dari ini, saya akan menghapus objek layanan dari apiserver inti dan memfasilitasi penggunaan penyeimbang beban lainnya, seperti HAProxy dan nginx.

Alangkah baiknya jika definisi logis dari suatu layanan (kueri dan/atau nama global) dapat digunakan/dikhususkan dalam berbagai cara - sebagai penyeimbang beban sederhana yang dipasang melalui infrastruktur, sebagai penyeimbang beban lengkap yang lebih berfitur seperti nginx atau haproxy juga ditawarkan oleh infrastruktur, sebagai titik akhir yang dapat ditanyakan, integrator dapat melakukan polling/menunggu (GET /services/foo -> { endpoints: [{host, port}, ...] }), atau sebagai informasi yang tersedia untuk host untuk mengekspos penyeimbang beban lokal. Jelas ini bisa menjadi beberapa kasus penggunaan yang berbeda dan dengan demikian dipecah menjadi sumber daya mereka sendiri, tetapi memiliki beberapa fleksibilitas untuk menentukan maksud (bersatu di bawah lb) yang berbeda dari mekanisme membuatnya lebih mudah untuk memenuhi berbagai permintaan.

@smarterclayton Saya setuju dengan pemisahan kebijakan dan mekanisme.

Primitif yang kita butuhkan:

1. Kemampuan untuk melakukan polling/menonton satu set yang diidentifikasi oleh pemilih label. Tidak yakin apakah ada masalah yang diajukan.
2. Kemampuan untuk menanyakan alamat IP pod (#385).

Ini akan cukup untuk menulis dengan mekanisme penamaan/penemuan lain dan/atau penyeimbang beban. Kami kemudian dapat membangun lapisan tingkat yang lebih tinggi di atas inti yang menggabungkan pola umum dengan API sederhana.

Dua primitif yang dijelaskan oleh @ bgrant0607 apakah layak untuk membiarkan masalah ini tetap terbuka? Atau ada masalah yang lebih spesifik yang bisa kami ajukan?

Saya tidak berpikir penjaga kebun binatang terpecahkan - karena Anda memerlukan pengidentifikasi unik di setiap wadah. Saya _think_ Anda dapat melakukan ini dengan 3 pengontrol replikasi terpisah (satu per instance) atau mode pada pengontrol replikasi.

Desain layanan yang menurut saya layak untuk didiskusikan seperti yang dicatat oleh Brian. Saat ini ia memasangkan abstraksi infrastruktur (proksi lokal) dengan mekanisme eksposur (variabel lingkungan di semua wadah) dengan kueri label. Ada kasus penggunaan yang sama validnya untuk proxy tepi yang mengambil host/jalur L7 dan menyeimbangkannya ke kueri label, serta protokol pendukung seperti http dan soket web. Selain itu, saat ini layanan memiliki batas skala keras sebesar 60 ribu backend, yang dibagikan di seluruh cluster (jumlah IP yang dialokasikan). Seharusnya dimungkinkan untuk menjalankan proxy lokal pada minion yang hanya mem-proxy layanan yang dibutuhkan oleh container pada host tersebut, dan juga untuk menghindari container harus tahu tentang port eksternal. Kita bisa memindahkan diskusi ini ke #494 jika perlu.

Mengatasi masalah layanan tunggal dan layanan non-skala otomatis dengan replikasi tetap, seperti database master-slave yang direplikasi, penyimpanan nilai kunci dengan grup rekan ukuran tetap (mis., etcd, zookeeper), dll.

Kasus replikasi tetap memerlukan perilaku seperti array yang dapat diprediksi. Rekan-rekan harus dapat menemukan dan menangani satu sama lain secara individual. Layanan ini umumnya memiliki pustaka dan/atau protokol kliennya sendiri, jadi kita tidak perlu memecahkan masalah dalam menentukan instans mana yang harus disambungkan klien, selain membuat instans dapat dialamatkan secara individual.

Proposal: Kita harus membuat layanan baru, yang disebut layanan Kardinal, yang memetakan N alamat IP, bukan hanya satu. Layanan utama akan melakukan penetapan alamat IP ini secara stabil ke N instans yang ditargetkan oleh pemilih labelnya (yaitu, N yang ditentukan, bukan hanya seberapa banyak target yang ada). Setelah kita memiliki DNS ( #1261, #146 ), itu akan menetapkan nama DNS yang dapat diprediksi berdasarkan awalan yang disediakan, dengan sufiks 0 hingga N-1. Tugas dapat direkam dalam anotasi atau label dari pod yang ditargetkan.

Ini akan mempertahankan pemisahan penugasan peran dari identitas pod dan pengontrol replikasi, sambil memberikan nama dan alamat IP yang stabil, yang dapat digunakan dalam mekanisme konfigurasi aplikasi standar.

Beberapa diskusi tentang berbagai jenis penyeimbangan beban terjadi dalam desain layanan v2: #1107.

Saya akan mengajukan masalah terpisah untuk pemilihan master.

/cc @smarterclayton @thockin

Penugasan harus dibawa ke dalam pod melalui beberapa mekanisme parameterisasi lingkungan (hampir pasti).

Untuk contoh etcd, saya akan membuat:

• pengontrol replikasi kardinalitas 1: 1 pod, menunjuk ke volume penyimpanan yang stabil A
• Kardinalitas pengontrol replikasi 2: 1 pod, menunjuk ke volume penyimpanan yang stabil B
• Kardinalitas pengontrol replikasi 3: 1 pod, menunjuk ke volume penyimpanan yang stabil C
• layanan utama 'etcd' menunjuk ke pod

Jika pod 2 mati, pengontrol replikasi 2 membuat salinan baru darinya dan menyambungkannya kembali ke volume B. Cardinal service 'etcd' mengetahui bahwa pod itu baru, tetapi bagaimana ia mengetahui bahwa pod itu seharusnya kardinalitas 2 (yang berasal dari data yang disimpan pada volume B)?

Daripada 3 pengontrol replikasi, mengapa bukan pengontrol sharding, yang
melihat label seperti "kubernetes.io/ShardIndex" saat membuat keputusan. Jika
Anda ingin sharding 3 arah, itu membuat 3 pod dengan indeks 0, 1, 2. Saya merasa seperti
ini ditembak jatuh sebelumnya, tetapi saya tidak dapat merekonstruksi masalah yang disebabkannya
kepalaku.

Tampaknya salah untuk menempatkan beban itu pada pengguna jika ini relatif
skenario umum.

Apakah menurut Anda penting jika IP nominal untuk pod tertentu berubah karena
perubahan yang tidak terkait di set? Sebagai contoh:

pada waktu 0, pod (A, B, C) membentuk layanan utama, dengan IP
10.0.0.{1-3} masing-masing

pada waktu 1, node yang menampung pod B mati

pada waktu 2, pengontrol replikasi yang mengemudikan B membuat pod baru D

pada waktu 3, layanan utama berubah menjadi (A, C, D) dengan IP 10.0.0.{1-3}
masing-masing

NB: "IP stabil" pod C berubah dari 10.0.0.3 menjadi 10.0.0.2 saat disetel
keanggotaan berubah. Saya berharap ini akan melakukan hal-hal buruk untuk berlari
koneksi.

Untuk menghindari ini, kita perlu memiliki nilai ordinal yang ditentukan
di luar layanan, atau sesuatu yang lain pintar. Mungkin tidak apa-apa, tapi itu
tampaknya rapuh dan mudah salah jika orang harus menghadapinya.

Pada Kam, 2 Okt 2014 jam 10:17, Clayton Coleman [email protected]
menulis:

Tugas harus dibawa ke dalam pod melalui beberapa
mekanisme parameterisasi lingkungan (hampir pasti).

Untuk contoh etcd, saya akan membuat:

• Kardinalitas pengontrol replikasi 1: 1 pod, menunjuk ke stable
  volume penyimpanan A
• Kardinalitas pengontrol replikasi 2: 1 pod, menunjuk ke stable
  volume penyimpanan B
• Kardinalitas pengontrol replikasi 3: 1 pod, menunjuk ke stable
  volume penyimpanan C
• layanan utama 'etcd' menunjuk ke pod

Jika pod 2 mati, pengontrol replikasi 2 membuat salinan baru darinya dan
menyambungkannya kembali ke volume B. Cardinal service 'etcd' mengetahui bahwa pod tersebut adalah
baru, tetapi bagaimana ia tahu bahwa itu harus menjadi kardinalitas 2 (yang berasal dari
data yang tersimpan di volume B)?

Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

Saya pikir pengontrol sharding masuk akal dan mungkin lebih berguna dalam konteks layanan utama.

Saya benar-benar berpikir bahwa perubahan IP berdasarkan keanggotaan menakutkan dan saya dapat memikirkan banyak kasus tepi yang merosot. Namun, jika kardinalitas disimpan dengan pod, keputusannya tidak terlalu sulit.

Pertama-tama, saya tidak bermaksud ini tentang sharding -- itu #1064. Mari pindahkan diskusi sharding ke sana. Kami telah melihat banyak kasus mencoba menggunakan mekanisme analog untuk sharding, dan kami menyimpulkan bahwa itu bukan cara terbaik untuk mengimplementasikan sharding.

Kedua, maksud saya adalah tidak perlu menjalankan pengontrol replikasi N. Seharusnya dimungkinkan untuk menggunakan hanya satu, meskipun jumlah yang diperlukan bergantung pada detail penerapan (canary, beberapa track rilis, pembaruan bergulir, dll.).

Ketiga, saya setuju kita perlu mempertimbangkan bagaimana ini akan berinteraksi dengan proposal data yang tahan lama (#1515) -- @erictune .

Empat, saya setuju kita mungkin perlu mencerminkan identitas ke dalam pod. Sesuai #386, idealnya mekanisme standar akan digunakan untuk membuat penetapan nama IP dan DNS terlihat oleh pod. Bagaimana IP dan alias host biasanya muncul di Linux?

Kelima, saya menyarankan agar kita memastikan stabilitas penugasan dengan merekam penugasan di pod melalui label atau anotasi.

Keenam, masalah dengan "pengontrol sharding" yang menggantikan pengontrol replikasi adalah saya ingin memisahkan penetapan peran dari manajemen gambar/lingkungan. Saya melihat pengontrol replikasi menyediakan yang terakhir (lihat https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

Dalam hal data tahan lama, sesuai #1515:

1. Untuk pod yang tahan lama, proposal ini hanya akan berfungsi. Penugasan akan stabil untuk pod yang tahan lama.
2. Untuk objek data yang terpisah, layanan kardinal juga perlu mengelola penetapan peran untuk objek data, dan akan menunda penetapan peran ke pod sampai mereka dicocokkan dengan data. Saya pikir ini akan langsung.

/cc @erictune

Saya pikir Anda mencoba membuat percakapan lebih mudah dilakukan, tetapi saya tidak yakin itu berhasil.

Re: sharding - bukankah "satu set replika dengan identitas berbeda" pada dasarnya adalah sharding?

Re: 1 pengontrol replikasi - kami tidak memiliki pengontrol replikasi yang menetapkan indeks hari ini. Saya tidak berpikir kita menginginkan itu, bukan?

Re: memberi tahu pod identitasnya sendiri - layanan adalah lapisan bersih di atas pod. Akan berantakan untuk memberi tahu layanan tentang pod yang akan datang sehingga dapat menetapkan IP sebelum ada. Saya pikir ID harus menjadi bagian dari pod, misalnya label ShardIndex atau semacamnya. Kami dapat merefleksikannya ke dalam pod (entah bagaimana) dan layanan dapat menggunakannya untuk menetapkan IP. Jika kita membiarkan layanan Cardinal melakukannya sendiri, maka pod akan sudah dimulai pada saat ditugaskan. Kami dapat memiliki metadata per-pod seperti yang kami lakukan dengan VM di GCE, tetapi itu adalah proposal yang lebih besar.

Tidak, memberikan identitas yang stabil dan berbeda tidak diperlukan atau tidak cukup untuk sharding. Lihat #1064 untuk detailnya, yang baru saja saya tambahkan di sana.

Tidak, kami tidak ingin pengontrol replikasi menetapkan indeks. Saya sengaja mengusulkan agar layanan Kardinal melakukan itu sebagai gantinya.

Ya, saya berharap pod ada (dan berpotensi sudah dimulai) sebelum mereka diberi peran (indeks). Itu disengaja. Itu juga perlu dimungkinkan untuk mencabut tugas.

Kemungkinan pendekatan identitas: Buat alias IP non-persisten dalam wadah dan berikan pencarian DNS terbalik dalam implementasi DNS.

Namun, saya tidak berpikir memasukkan identitas ke dalam wadah pod sangat penting untuk banyak kasus penggunaan. Jika aplikasi menggunakan self-registration, mungkin tidak memerlukan mekanisme ini.

Jika manajer layanan bersedia untuk menjaga beberapa keadaan selain dari apa itu
saat ini, kami hanya dapat mengingat pemetaan yang dibuat sebelumnya
dan mencoba untuk menghormati mereka.

Pada Kam, 2 Oktober 2014 jam 20:59, bgrant0607 [email protected] menulis:

Kemungkinan pendekatan identitas: Buat alias IP non-persisten di
wadah dan menyediakan pencarian DNS terbalik dalam implementasi DNS.

Namun, saya tidak berpikir memasukkan identitas ke dalam wadah pod adalah
penting untuk banyak kasus penggunaan. Jika aplikasi menggunakan
pendaftaran sendiri, mungkin bahkan tidak memerlukan mekanisme ini.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Ulang. mengingat pemetaan, saya setuju -- lihat https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Saya tidak tahu bagaimana itu relevan dengan komentar yang Anda balas.

GitHub dan email tidak bercampur. Maaf

Pada Thu, 2 Oktober 2014 di 09:39, bgrant0607 [email protected] menulis:

Ulang. mengingat pemetaan, saya setuju -- lihat #260 (komentar)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Saya tidak tahu bagaimana itu relevan dengan komentar yang Anda balas.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim menyarankan "nominal", yang menurut saya lebih cocok.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

Saya juga suka nominalnya. Akan benci menjelaskannya kepada pengguna, tetapi akan sangat sering digunakan untuk hal-hal yang dibuat konfigurasi (yaitu set replika mongodb nominal akan menjadi pengontrol replikasi, layanan nominal, volume, jadi itu sudah agak rumit).

----- Pesan asli -----

Tim menyarankan "nominal", yang menurut saya lebih cocok.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Dua masalah yang saya lihat:

1. Penetapan peran melibatkan pengaturan setidaknya variabel lingkungan atau pengaturan volume per pod (yaitu pod pertama perlu mendapatkan volume a, dan jika dihapus, penggantiannya membutuhkan volume yang sama)
2. Jika pod untuk layanan nominal berasal dari pengontrol repl tunggal, template harus dimodifikasi setelah pembuatan tetapi sebelum pod diikat.

Ini tampaknya menyiratkan penetapan peran adalah pengontrol yang berada di antara apiserver dan penjadwal sebagai langkah alur kerja. Ini juga menyiratkan beberapa bentuk transformasi atau penggantian template, sehingga template tanpa penetapan peran tidak selalu masuk akal.

Pengontrol shard sepertinya merupakan varian dari masalah ini, hanya untuk penetapan peran yang lebih rumit.

Contoh menjalankan zookeeper dengan satu layanan per instance: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Jadi saya tahu ini adalah utas lama, tetapi ini menyentuh topik yang dekat dan saya sukai ;-)

Asalkan sistem dapat mendorong catatan maju+mundur untuk "layanan nominal" non-nat ke skydns dan menggunakan nama sebagai injeksi ENV ke dalam pod yang menggunakan layanan itu, apakah ada batasan lain?

Mungkin terlihat sedikit aneh dalam kasus ZK di mana setiap elemen dalam kuorum akan menggunakan elemen lain, misalnya:
zk1 menggunakan: zk2, zk3
zk2 menggunakan: zk1, zk3
zk3 menggunakan: zk1, zk2

tapi secara teori itu harus bekerja kan? Asalkan kita dapat menambahkan catatan terbalik untuk layanan nominal.

@ bgrant0607 apakah saya melewatkan sesuatu?

Ini menjadi sedikit lebih aneh ketika aplikasi lain ingin menggunakan layanan keseluruhan yang disediakannya. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc Apa yang Anda usulkan akan berfungsi jika zk1, zk2, dan zk3 adalah layanan, setidaknya sekali layanan multi-port didukung.

Ya, ada yang jelek di sini.

Pod yang sedang berjalan tidak mengetahui layanan apa yang "didepankan". Misal diberikan jasa
dari satu instance backend, VIP yang digunakan untuk mengakses layanan tidak diketahui oleh
backend (kecuali mencari informasi itu dengan mengetahui layanannya
nama). Dalam layanan nominal (N), Anda akan memiliki N backend dan N VIP (dan
mungkin N nama DNS atau nama N-alamat), tetapi backend akan tetap
tidak tahu VIP mereka sendiri. Mereka mungkin mengamati kumpulan nama DNS, tapi
tidak tahu (tanpa menyelidik) yang mana diri. Ini akan membuat ZK . Anda
kasus sulit untuk menggunakan VIP (juga VIP secara nyata diproksi sekarang).

Alternatif:

1) atur 1 layanan (N) dan minta setiap instans memeriksa semua VIP untuk diri sendiri

2) mengatur N service(1) instance dan menggunakan label dan flag cmdline untuk
tetapkan indeks secara manual, buat setiap backend ZK tahu (apriori) nama DNS
dari satu sama lain ZK backend

3) Lakukan DNS untuk penyeleksi label, tetapkan nama DNS ke set replika ZK,
berharap klien menggunakan DNS dengan benar

4) Jalankan jembatan kube2zk di samping setiap ZK yang menyinkronkan titik akhir kubernetes ->
konfigurasi ZK

5) Rancang cara alternatif untuk menetapkan VIP atau indeks yang lebih
replcation-controller-centric daripada service centric. Brendan dan aku
melakukan brainstorming beberapa ide di sini beberapa waktu lalu, tetapi tidak punya waktu untuk mengikuti
di atasnya.

Adapun DNS terbalik - Saya tidak yakin saya melihat perannya? Saya tidak menentang
mendukungnya (yaitu meminta @bketelsen untuk mendukungnya :) tapi saya rasa tidak
berlaku di sini. Lalu lintas tidak pernah datang "dari" IP layanan.

Tim

Pada Sat, Mar 7, 2015 at 08:56, Brian Hibah [email protected]
menulis:

@timothysc https://github.com/timothysc Apa yang Anda usulkan akan berhasil jika
zk1, zk2, dan zk3 adalah layanan, setidaknya sekali layanan multi-port adalah
didukung.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) terdengar seperti proposal ini.

Saya penggemar berat 5 - pod mengetahui peran mereka adalah langkah pertama, pod memiliki keunikan yang memiliki DNS mengidentifikasi atau menggunakan titik akhir untuk mendapatkan ip orang lain dan bereaksi terhadapnya adalah dua. Mampu mencari ip pod di titik akhir dengan id peran yang stabil akan menjadi yang ketiga.

Pada 8 Maret 2015, pukul 11:06, Tim Hockin [email protected] menulis:

Ya, ada yang jelek di sini.

Pod yang sedang berjalan tidak mengetahui layanan apa yang "didepankan". Misal diberikan jasa
dari satu instance backend, VIP yang digunakan untuk mengakses layanan tidak diketahui oleh
backend (kecuali mencari informasi itu dengan mengetahui layanannya
nama). Dalam layanan nominal (N), Anda akan memiliki N backend dan N VIP (dan
mungkin N nama DNS atau nama N-alamat), tetapi backend akan tetap
tidak tahu VIP mereka sendiri. Mereka mungkin mengamati kumpulan nama DNS, tapi
tidak tahu (tanpa menyelidik) yang mana diri. Ini akan membuat ZK . Anda
kasus sulit untuk menggunakan VIP (juga VIP secara nyata diproksi sekarang).

Alternatif:

1) atur 1 layanan (N) dan minta setiap instans memeriksa semua VIP untuk diri sendiri

2) mengatur N service(1) instance dan menggunakan label dan flag cmdline untuk
tetapkan indeks secara manual, buat setiap backend ZK tahu (apriori) nama DNS
dari satu sama lain ZK backend

3) Lakukan DNS untuk penyeleksi label, tetapkan nama DNS ke set replika ZK,
berharap klien menggunakan DNS dengan benar

4) Jalankan jembatan kube2zk di samping setiap ZK yang menyinkronkan titik akhir kubernetes ->
konfigurasi ZK

5) Rancang cara alternatif untuk menetapkan VIP atau indeks yang lebih
replcation-controller-centric daripada service centric. Brendan dan aku
melakukan brainstorming beberapa ide di sini beberapa waktu lalu, tetapi tidak punya waktu untuk mengikuti
di atasnya.

Adapun DNS terbalik - Saya tidak yakin saya melihat perannya? Saya tidak menentang
mendukungnya (yaitu meminta @bketelsen untuk mendukungnya :) tapi saya rasa tidak
berlaku di sini. Lalu lintas tidak pernah datang "dari" IP layanan.

Tim

Pada Sat, Mar 7, 2015 at 08:56, Brian Hibah [email protected]
menulis:

@timothysc https://github.com/timothysc Apa yang Anda usulkan akan berhasil jika
zk1, zk2, dan zk3 adalah layanan, setidaknya sekali layanan multi-port adalah
didukung.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

—
Balas email ini secara langsung atau lihat di GitHub.

Saya harus meluangkan waktu untuk menulis ide ini sedikit lagi, kalau begitu.

Pada Minggu, 8 Maret 2015 pukul 10:25, Clayton Coleman [email protected]
menulis:

Saya penggemar berat 5 - pod mengetahui peran mereka adalah langkah pertama, pod
memiliki DNS unik yang mengidentifikasi atau menggunakan titik akhir untuk mendapatkan ip orang lain dan
bereaksi terhadapnya adalah dua. Mampu mencari ip pod di titik akhir oleh a
id peran stabil akan menjadi yang ketiga.

Pada 8 Maret 2015, pukul 11:06, Tim Hockin [email protected]
menulis:

Ya, ada yang jelek di sini.

Pod yang sedang berjalan tidak mengetahui layanan apa yang "didepankan". Misal diberikan
melayani
dari satu instance backend, VIP yang digunakan untuk mengakses layanan tidak diketahui
oleh
backend (kecuali mencari informasi itu dengan mengetahui layanannya
nama). Dalam layanan nominal (N), Anda akan memiliki N backend dan N VIP
(dan
mungkin N nama DNS atau nama N-alamat), tetapi backend akan
tetap
tidak tahu VIP mereka sendiri. Mereka mungkin mengamati kumpulan nama DNS, tapi
tidak tahu (tanpa menyelidik) yang mana diri. Ini akan membuat ZK . Anda
kasus sulit untuk menggunakan VIP (juga VIP secara nyata diproksi sekarang).

Alternatif:

1) atur 1 layanan (N) dan minta setiap instans memeriksa semua VIP untuk diri sendiri

2) mengatur N service(1) instance dan menggunakan label dan flag cmdline untuk
menetapkan indeks secara manual, membuat setiap backend ZK mengetahui (apriori) DNS
nama
dari satu sama lain ZK backend

3) Lakukan DNS untuk penyeleksi label, tetapkan nama DNS ke set replika ZK,
berharap klien menggunakan DNS dengan benar

4) Jalankan jembatan kube2zk di samping setiap ZK yang menyinkronkan titik akhir kubernetes
->
konfigurasi ZK

5) Rancang cara alternatif untuk menetapkan VIP atau indeks yang lebih
replcation-controller-centric daripada service centric. Brendan dan aku
melakukan brainstorming beberapa ide di sini beberapa waktu lalu, tetapi tidak punya waktu untuk
mengikuti
di atasnya.

Adapun DNS terbalik - Saya tidak yakin saya melihat perannya? Saya tidak menentang
mendukungnya (yaitu meminta @bketelsen untuk mendukungnya :) tapi saya rasa tidak
berlaku di sini. Lalu lintas tidak pernah datang "dari" IP layanan.

Tim

Pada Sat, Mar 7, 2015 at 08:56, Brian Hibah [email protected]
menulis:

@timothysc https://github.com/timothysc Apa yang Anda usulkan akan berhasil
jika
zk1, zk2, dan zk3 adalah layanan, setidaknya sekali layanan multi-port adalah
didukung.

—
Balas email ini secara langsung atau lihat di GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

—
Balas email ini secara langsung atau lihat di GitHub.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: reverse DNS, mari kita melambaikan tangan dan menganggapnya sebagai persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

RC yang menerapkan label unik (members=#) ke setiap pod yang dibuatnya, dan mencoba membuat urutan hingga N replika, dan kemudian layanan tanpa kepala yang membuat nama A dan CNAME untuk setiap nilai label "anggota" (# .service.namespace.local), di mana root melayani semua service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local tampaknya lokal.

Kami _bisa_ menggunakan IP pod yang ketat untuk masing-masing label DNS tersebut. Membuat IP palsu untuk masing-masing menjadi mahal dan wadah tidak akan dapat mengirim IP sendiri ke seseorang.

----- Pesan asli -----

@thockin re: reverse DNS, mari kita melambaikan tangan dan menganggapnya sebagai
persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: reverse DNS - apa itu DNSing terbalik? Sumber-IP dari
koneksi? Tidak ada yang berfungsi di kube. Koneksi melalui layanan adalah
diproksi, jadi source-ip tidak berfungsi sejak awal (bisa diperbaiki).

Saya tidak tahu ZK - dapatkah Anda menjelaskan apa yang mereka coba dapatkan secara terbalik?
DNS? Sepertinya asumsi yang sangat rapuh.

Pada Mon, Mar 9, 2015 at 09:05, Timothy St. Clair [email protected]
menulis:

@thockin https://github.com/thockin re: reverse DNS, ayo melambai
tangan kita tentang dan menganggapnya sebagai persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Saya pikir pengalaman saya (dan mungkin Tim) adalah bahwa sebagian besar perangkat lunak berkerumun saat ini mengharapkan yang berikut:

• setiap node memiliki identitas yang stabil
• identitas itu adalah nama DNS
• IP dari identitas yang mendasarinya tidak harus stabil
• node berharap untuk mengidentifikasi dirinya ke node lain baik dengan identitas stabil (DNS) atau IP publiknya
• beberapa perangkat lunak berkerumun mengharapkan IP dari node yang dijangkau klien untuk mencocokkan IP yang dapat diumumkannya sendiri kepada orang lain di dalam cluster dan agar IP tersebut dapat dijangkau.

----- Pesan asli -----

@timothysc re: reverse DNS - apa itu DNSing terbalik? Sumber-IP dari
koneksi? Tidak ada yang berfungsi di kube. Koneksi melalui layanan adalah
diproksi, jadi source-ip tidak berfungsi sejak awal (bisa diperbaiki).

Saya tidak tahu ZK - dapatkah Anda menjelaskan apa yang mereka coba dapatkan secara terbalik?
DNS? Sepertinya asumsi yang sangat rapuh.

Pada Mon, Mar 9, 2015 at 09:05, Timothy St. Clair [email protected]
menulis:

@thockin https://github.com/thockin re: reverse DNS, ayo melambai
tangan kita tentang dan menganggapnya sebagai persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

Pada Senin, 9 Mar 2015 pukul 12:49, Clayton Coleman
[email protected] menulis:

RC yang menerapkan label unik (members=#) ke setiap pod yang dibuatnya, dan mencoba membuat urutan hingga
N replika, lalu layanan tanpa kepala yang membuat nama A dan CNAME untuk setiap nilai "anggota"
label (#.service.namespace.local), tempat root melayani semua service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local tampaknya lokal.

Gagasan bahwa Brendan dan saya terpental pada dasarnya adalah sebuah kolam
token, mungkin bagian dari RC, mungkin tidak, bahwa setiap elemen dari RC
akan ditugaskan. Mengingat token itu, hal-hal lain dapat ditugaskan

• VIP, PD, indeks generik, dll. Yang menyenangkan adalah ketika sebuah pod
  mati, token dikembalikan ke pool, dan ketika pod itu diganti
  token itu digunakan kembali.

Masalahnya muncul dengan mencari tahu bagaimana mengubah "token sewenang-wenang" menjadi
sesuatu yang berarti.

Kami _bisa_ menggunakan IP pod yang ketat untuk masing-masing label DNS tersebut. Membuat IP palsu untuk masing-masing menjadi mahal dan wadah tidak akan dapat mengirim IP sendiri ke seseorang.

Saya belum mencoba, tapi saya yakin kita bisa membuat layanan nominal melakukan SNAT penuh
dan DNAT karena mereka 1:1. Ini akan menjadi cara untuk menjadi stabil
IP per-pod tanpa IP yang dapat dipindahkan.

----- Pesan asli -----

@thockin re: reverse DNS, mari kita melambaikan tangan dan menganggapnya sebagai
persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

—
Balas email ini secara langsung atau lihat di GitHub.

Jauh dari saya untuk berenang ke hulu - jika cukup banyak aplikasi yang benar-benar mengharapkan DNS untuk
bekerja dengan cara ini, kita dapat membuatnya bekerja dengan cara ini.

Sketsa:

Membuat pengontrol replikasi R membuat nama DNS "$R.rc" yang merupakan
kumpulan IP pod yang "di bawah" RC itu. Setiap pod P mendapatkan nama DNS
"$P.$R.rc". Tapi apa itu P? Itu bisa berupa indeks sederhana, tetapi itu memiliki
menggigit kita dengan keras secara internal. Itu bisa berupa string acak seperti GenerateName,
tetapi mereka harus selamat dari kematian/restart pod (dan mungkin nama host pod harus
cocok?).

Pada Tue, Mar 10, 2015 at 07:59, Clayton Coleman [email protected]
menulis:

Saya pikir pengalaman saya (dan mungkin Tim) adalah bahwa mayoritas berkerumun
perangkat lunak hari ini mengharapkan yang berikut:

• setiap node memiliki identitas yang stabil
• identitas itu adalah nama DNS
• IP dari identitas yang mendasarinya tidak harus stabil
• node mengharapkan untuk mengidentifikasi dirinya ke node lain baik dengan stabilnya
  identitas (DNS) atau IP publiknya
• beberapa perangkat lunak berkerumun mengharapkan IP dari node klien
  menjangkaunya untuk mencocokkan IP yang dapat diumumkannya kepada orang lain di
  cluster dan agar IP tersebut dapat dijangkau.

----- Pesan asli -----

@timothysc re: reverse DNS - apa itu DNSing terbalik? Sumber-IP dari
koneksi? Tidak ada yang berfungsi di kube. Koneksi melalui layanan adalah
diproksi, jadi source-ip tidak berfungsi sejak awal (bisa diperbaiki).

Saya tidak tahu ZK - dapatkah Anda menjelaskan apa yang mereka coba dapatkan secara terbalik?
DNS? Sepertinya asumsi yang sangat rapuh.

Pada Senin, 9 Mar 2015 jam 09:05, Timothy St. Clair <
[email protected]>
menulis:

@thockin https://github.com/thockin re: reverse DNS, ayo melambai
tangan kita tentang dan menganggapnya sebagai persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

—
Balas email ini secara langsung atau lihat di GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Balas email ini secara langsung atau lihat di GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

Saya lebih suka DNS dilampirkan ke layanan nominal daripada RC.

Apa titik nyeri dengan indeks sederhana secara internal? P > 5000?

----- Pesan asli -----

Jauh dari saya untuk berenang ke hulu - jika cukup banyak aplikasi yang benar-benar mengharapkan DNS untuk
bekerja dengan cara ini, kita dapat membuatnya bekerja dengan cara ini.

Sketsa:

Membuat pengontrol replikasi R membuat nama DNS "$R.rc" yang merupakan
kumpulan IP pod yang "di bawah" RC itu. Setiap pod P mendapatkan nama DNS
"$P.$R.rc". Tapi apa itu P? Itu bisa berupa indeks sederhana, tetapi itu memiliki
menggigit kita dengan keras secara internal. Itu bisa berupa string acak seperti GenerateName,
tetapi mereka harus selamat dari kematian/restart pod (dan mungkin nama host pod harus
cocok?).

Pada Tue, Mar 10, 2015 at 07:59, Clayton Coleman [email protected]
menulis:

Saya pikir pengalaman saya (dan mungkin Tim) adalah bahwa mayoritas berkerumun
perangkat lunak hari ini mengharapkan yang berikut:

• setiap node memiliki identitas yang stabil
• identitas itu adalah nama DNS
• IP dari identitas yang mendasarinya tidak harus stabil
• node mengharapkan untuk mengidentifikasi dirinya ke node lain baik dengan stabilnya
  identitas (DNS) atau IP publiknya
• beberapa perangkat lunak berkerumun mengharapkan IP dari node klien
  menjangkaunya untuk mencocokkan IP yang dapat diumumkannya kepada orang lain di
  cluster dan agar IP tersebut dapat dijangkau.

----- Pesan asli -----

@timothysc re: reverse DNS - apa itu DNSing terbalik? Sumber-IP dari
koneksi? Tidak ada yang berfungsi di kube. Koneksi melalui layanan adalah
diproksi, jadi source-ip tidak berfungsi sejak awal (bisa diperbaiki).

Saya tidak tahu ZK - dapatkah Anda menjelaskan apa yang mereka coba dapatkan secara terbalik?
DNS? Sepertinya asumsi yang sangat rapuh.

Pada Senin, 9 Mar 2015 jam 09:05, Timothy St. Clair <
[email protected]>
menulis:

@thockin https://github.com/thockin re: reverse DNS, ayo melambai
tangan kita tentang dan menganggapnya sebagai persyaratan.

ZK akan rusak tanpanya, seperti halnya banyak sistem terdistribusi lainnya.

—
Balas email ini secara langsung atau lihat di GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Balas email ini secara langsung atau lihat di GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 ke casing khusus 1:1 VIP. Saya pikir itu akan menjadi kasus umum.

Saya masih khawatir tentang mengubah pemetaan DNS secara dinamis. Saya lebih suka pendekatan yang tidak memerlukan itu.

Sesuatu yang perlu diingat ketika mengevaluasi alternatif adalah bahwa saya 100% yakin bahwa pada akhirnya kita akan membutuhkan 2 pod dengan peran yang sama untuk hidup berdampingan pada waktu yang sama, yang lama dan yang baru. Oleh karena itu, peran tidak dapat dikaitkan dengan nama objek atau hal lain yang harus unik dan harus ditetapkan pada saat pembuatan pod.

Jika kita mengikat mekanisme penetapan peran ke pengontrol replikasi, itu cukup banyak mengesampingkan pembaruan, kenari, dll. Saya ingin menghindarinya jika memungkinkan.

@smarterclayton Indeks sederhana tidak bermasalah karena skala. Itu karena modelnya. Lihat komentar saya dari beberapa menit yang lalu. Indeks sederhana adalah cara untuk pergi jika mereka dapat ditugaskan secara dinamis independen dari pod dan identitas RC.

Mengingat bahwa salah satu masalahnya adalah asumsi berorientasi sistem, apakah ada sesuatu yang dapat dilakukan Linux untuk kita di sini? Misalnya, bisakah kita membuat alias IP atau semacamnya dalam wadah untuk layanan VIP?

Hai teman-teman,

Saya keluar sepanjang minggu ini. Ini adalah percakapan yang sangat menyenangkan, tetapi membutuhkan
lebih banyak waktu daripada yang saya miliki. Saya akan senang untuk duduk dan berdiskusi secara nyata
waktu minggu depan.

Pada Tue, Mar 10, 2015 at 03:56, Brian Hibah [email protected]
menulis:

Mengingat bahwa salah satu masalahnya adalah asumsi berorientasi sistem, apakah ada?
sesuatu yang bisa dilakukan Linux untuk kita di sini? Misalnya, bisakah kita membuat IP
alias atau semacamnya dalam wadah untuk layanan VIP?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Saya kehabisan uang dua hari ke depan - minggu depan.

Pada 10 Maret 2015, pukul 23.33, Tim Hockin [email protected] menulis:

Hai teman-teman,

Saya keluar sepanjang minggu ini. Ini adalah percakapan yang sangat menyenangkan, tetapi membutuhkan
lebih banyak waktu daripada yang saya miliki. Saya akan senang untuk duduk dan berdiskusi secara nyata
waktu minggu depan.

Pada Tue, Mar 10, 2015 at 03:56, Brian Hibah [email protected]
menulis:

Mengingat bahwa salah satu masalahnya adalah asumsi berorientasi sistem, apakah ada?
sesuatu yang bisa dilakukan Linux untuk kita di sini? Misalnya, bisakah kita membuat IP
alias atau semacamnya dalam wadah untuk layanan VIP?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

—
Balas email ini secara langsung atau lihat di GitHub.

+1 untuk minggu depan, mungkin hangout.

Mencolek utas ini lagi karena topik terkait bermunculan (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, #6393).

1. Bagaimana kita menetapkan identitas jaringan (nama DNS dan/atau alamat IP) ke pod individu, yang mungkin tunggal atau bagian dari kumpulan nominal?
2. Bagaimana cara kita menyampaikan identitas ke container di dalam pod?

Haruskah kita menjadwalkan hangout, atau menggunakan hangout komunitas mingguan?

Juga https://github.com/openshift/mongodb/pull/14 yang kami mulai membuat prototipe pola generik untuk inisialisasi set keanggotaan (sesuatu yang dapat kami masukkan ke dalam wadah, atau perpustakaan, atau ...)

@danmcp @mfojtik

----- Pesan asli -----

Mencolek utas ini lagi karena topik terkait bermunculan
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. Bagaimana kami menetapkan identitas jaringan (nama DNS dan/atau alamat IP) ke
   pod individu, yang mungkin tunggal atau bagian dari set nominal?
2. Bagaimana cara kita menyampaikan identitas ke container di dalam pod?

Haruskah kita menjadwalkan hangout, atau menggunakan hangout komunitas mingguan?

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, salah satu bagian dari teka-teki itu adalah pemilihan master #1542.

Ya, kami membahasnya. Untuk sebagian besar cluster yang dapat melakukan pemilihan sendiri, keanggotaan adalah yang paling penting (mendeteksi keanggotaan dari titik akhir Kube, berlaku untuk cluster), tetapi selalu ada cara berbeda untuk mendekatinya. Misalnya, Cassandra pada dasarnya menggunakan Kube sebagai sumber kebenaran eksternal untuk keanggotaan, jadi ini adalah SEP dan itu membuat pemilihan kepemimpinan lebih mudah. Meskipun saya percaya tergantung pada bagaimana anggota lag Anda bisa berakhir dengan partisi jika flaps keanggotaan.

Untuk mongo, Anda ingin menghubungi setiap anggota dan meminta mereka bergabung dengan cluster yang ada atau membentuk cluster baru. Jika ada beberapa cluster, Anda tidak ingin memperburuknya.

Perhatikan bahwa masalah mengomunikasikan IP layanan ke wadah mirip dengan mengomunikasikan IP eksternal ke VM: https://cloud.google.com/compute/docs/networking. GCE menerjemahkan alamat eksternal ke/dari alamat internal, dan alamat eksternal dikomunikasikan melalui server metadata: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS serupa: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton Saya memperbarui PR prototipe mongo: https://github.com/openshift/mongodb/pull/17

sekarang menggunakan One Shot Pod yang menginisialisasi ReplikaSet

Ulang. mengikat mekanisme ini ke pengontrol replikasi/shard:

Mencoba nama DNS ke pengontrol replikasi dan/atau ke nama objek pod memaksa model pembaruan di tempat. Jenis pembaruan bergulir "di tempat" yang sama sekali berbeda perlu diterapkan, sementara entah bagaimana mendukung beberapa templat secara bersamaan dengan satu pengontrol. Ini juga berarti bahwa untuk melakukan beberapa jenis pembaruan (termasuk pindah ke host baru), Pod perlu dihapus dan kemudian dibuat ulang dengan nama yang sama, yang akan meningkatkan waktu henti dibandingkan dengan pendekatan di mana kita menambahkan yang baru. pod sebelum mengambil yang lama.

Ide kumpulan token terdengar hebat. Saya hanya berpikir itu perlu dipisahkan dari RC.

Ini dapat digabungkan ke pengontrol tingkat yang lebih tinggi, jika kita ingin menambahkannya. Akan berkomentar lebih lanjut tentang #1743 dan/atau #503.

Ini seharusnya tidak benar-benar digabungkan ke DeploymentController yang diusulkan di #1743. Ini tidak akan berfungsi untuk skenario beberapa trek rilis independen, atau dalam kasus di mana seseorang ingin mengontrol peluncuran mereka dengan mekanisme yang berbeda, seperti pembaruan bergulir pertukaran nama yang diusulkan. Untuk alasan yang sama, saya tidak akan mengikat nama DNS dengan nama objek pod/RC/DC.

Jadi kami kembali ke beberapa rasa layanan, atau pengontrol yang sepenuhnya terpisah. Mungkin pengontrol titik akhir dapat menetapkan indeks ke titik akhir layanan? Apakah Endpoints sendiri merupakan tempat yang cukup andal untuk merekam data ini? Jika hilang, semua pod akan diindeks ulang.

Untuk memfasilitasi komunikasi identitas hingga ke container dalam pod (seperti melalui substitusi env. var. yang dibahas di #2316), akan berguna untuk menyetel bidang pada pod saat peran ditetapkan/tidak ditetapkan, melalui subsumber daya. Itu juga bisa mengatasi masalah daya tahan.

Kita harus memesan ruang dalam skema DNS untuk contoh nominal -- #6666.

Saya dapat membeli bahwa kami dapat mencoba menggunakan IP pod dan hanya memetakan ulang DNS untuk instance nominal, per https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406 .

Juga, saya menghapus ini dari tonggak 1.0 pada Februari (meskipun bukan roadmap.md), tetapi diskusi di #6393 menyarankan bahwa itu dapat ditambahkan kembali.

Disarankan oleh @thockin :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Ya, akan membuat "siapa saya" sangat mudah melalui alat nama standar.

Pada 10 April 2015, pukul 20:11, Brian Grant [email protected] menulis:

Disarankan oleh @thockin :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

—
Balas email ini secara langsung atau lihat di GitHub.

/langganan

Saya tidak yakin saya mengerti persyaratan di sini, lagi.

Ada hubungan N-ke-M yang melekat antara layanan dan pod, oleh
desain sistem. Hal-hal seperti DNS terbalik umumnya mengharapkan untuk mendapatkan
respons tunggal: diberi IP pod, dapatkan nama kanonik. Setiap dokumen tertulis
tentang DNS mengatakan "jangan kembalikan beberapa catatan terbalik". Karena pod bisa menjadi
dalam layanan N, respons tunggal ini tidak dapat benar-benar terkait dengan layanan. Kami
bisa melakukan pencarian terbalik ke nama kanonik dan kemudian pencarian TXT tentang itu
nama untuk "layanan apa yang Anda gunakan", tetapi itu sulit untuk dipertahankan dan
pada dasarnya protokol khusus.

Alasan saya berpikir untuk melampirkan nominal apa pun ke RC adalah karena itu adalah
hubungan yang lebih konkrit. Tapi itu tidak seimbang. Pod dapat dibuat dengan
satu RC, yatim piatu, diadopsi oleh RC lain, dan dihancurkan oleh itu. Atau
dihancurkan secara manual

Jadi saya tidak yakin apa yang ingin kami lakukan dengan ini, selain membatasi jumlahnya
layanan pod dapat "di bawah", yang terdengar mengerikan.

Apa persyaratan perilaku? Apa yang kita coba capai. Kami
dapat menyediakan semantik set sederhana dengan DNS dan layanan tanpa kepala. Apakah itu
memadai? Jika tidak, mengapa?

Kita bisa pergi ke ekstrim dan mengatur aturan iptables ke pod SNAT/DNAT di a
layanan sehingga mereka semua melihat satu sama lain di VIP. Misalnya diberi satu set polong
(P1, P2, P3) mereka akan mendapatkan VIP (V1, V2, V3). Lalu lintas dari P1 ke V2 akan
tampaknya berasal dari V1, dll. Klien akan mengakses V{1,2,3}. Tapi apa
masalah apakah itu memecahkan, benar-benar? Ini memberikan IP yang stabil tetapi bukankah ini?
masalah umum untuk layanan tanpa kepala di mana-mana?

Pada Selasa, 21 Apr 2015 pukul 14:17, David Oppenheimer < [email protected]

menulis:

/langganan

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

Tujuannya sangat konkret. Sistem berkerumun nyata memiliki anggota yang memiliki "identitas" yang diharapkan terus menerus dengan adanya kegagalan node. Identitas itu mungkin dilampirkan ke persistent disk atau "nama", tetapi nama yang diidentifikasi ke sistem lain tidak dapat diubah.

Contoh, penjaga kebun binatang memiliki identitas per simpul. Identitas tersebut harus tetap stabil dalam keanggotaan cluster - _bisa saja_ ada dua pod yang mengira mereka adalah host1, tetapi jika host1 hilang, host435 tidak dapat menggantikannya. Mungkin ada persistent disk yang digunakan kembali untuk pod tersebut yang berpindah dari satu tempat ke tempat lain, tetapi ketika itu terjadi, pod harus dapat mendefinisikan identitas itu. Tetapi kita membutuhkan cara untuk menetapkan # itu.

Saya menduga bahwa cara saya berpikir tentang layanan nominal selalu tentang mengaktifkan perangkat lunak yang ada dengan keanggotaan kecil (3/5/7), bukan kasus penggunaan multi-seratus yang sepenuhnya fleksibel. Mungkin kita harus memisahkan use case itu dari diskusi ini.

Pada 22 April 2015, pukul 1:59 pagi, Tim Hockin [email protected] menulis:

Saya tidak yakin saya mengerti persyaratan di sini, lagi.

Ada hubungan N-ke-M yang melekat antara layanan dan pod, oleh
desain sistem. Hal-hal seperti DNS terbalik umumnya mengharapkan untuk mendapatkan
respons tunggal: diberi IP pod, dapatkan nama kanonik. Setiap dokumen tertulis
tentang DNS mengatakan "jangan kembalikan beberapa catatan terbalik". Karena pod bisa menjadi
dalam layanan N, respons tunggal ini tidak dapat benar-benar terkait dengan layanan. Kami
bisa melakukan pencarian terbalik ke nama kanonik dan kemudian pencarian TXT tentang itu
nama untuk "layanan apa yang Anda gunakan", tetapi itu sulit untuk dipertahankan dan
pada dasarnya protokol khusus.

Alasan saya berpikir untuk melampirkan nominal apa pun ke RC adalah karena itu adalah
hubungan yang lebih konkrit. Tapi itu tidak seimbang. Pod dapat dibuat dengan
satu RC, yatim piatu, diadopsi oleh RC lain, dan dihancurkan oleh itu. Atau
dihancurkan secara manual

Jadi saya tidak yakin apa yang ingin kami lakukan dengan ini, selain membatasi jumlahnya
layanan pod dapat "di bawah", yang terdengar mengerikan.

Apa persyaratan perilaku? Apa yang kita coba capai. Kami
dapat menyediakan semantik set sederhana dengan DNS dan layanan tanpa kepala. Apakah itu
memadai? Jika tidak, mengapa?

Kita bisa pergi ke ekstrim dan mengatur aturan iptables ke pod SNAT/DNAT di a
layanan sehingga mereka semua melihat satu sama lain di VIP. Misalnya diberi satu set polong
(P1, P2, P3) mereka akan mendapatkan VIP (V1, V2, V3). Lalu lintas dari P1 ke V2 akan
tampaknya berasal dari V1, dll. Klien akan mengakses V{1,2,3}. Tapi apa
masalah apakah itu memecahkan, benar-benar? Ini memberikan IP yang stabil tetapi bukankah ini?
masalah umum untuk layanan tanpa kepala di mana-mana?

Pada Selasa, 21 Apr 2015 pukul 14:17, David Oppenheimer < [email protected]

menulis:

/langganan

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

—
Balas email ini secara langsung atau lihat di GitHub.

Beberapa jenis pengontrol dapat secara dinamis mengatur/menghapus beberapa bidang pada pod. Itu tidak bisa digabungkan dengan pod atau identitas RC. Mengikat identitas jaringan ke pod atau identitas RC benar-benar rusak.

Saya tidak akan mencoba membuat pencarian DNS terbalik berfungsi untuk layanan biasa atau tanpa kepala, dan menurut saya tidak masuk akal untuk memaksakan maksimal satu layanan nominal per pod -- yang tidak harus membatasi jenis layanan lain sama sekali .

Ada sejumlah batasan DNS yang ingin kami terapkan dalam jangka panjang (pembatalan cache, dukungan untuk polling panjang, dll.). Beberapa catatan PTR mungkin hanyalah item lain yang ditambahkan ke daftar itu.

Alternatif lainnya adalah kita dapat memberikan IP layanan ke setiap pod dari layanan nominal dan kemudian menyelesaikan masalah yang muncul.

----- Pesan asli -----

Beberapa jenis pengontrol dapat secara dinamis mengatur/menghapus beberapa bidang pada pod. Dia
tidak bisa digabungkan dengan pod atau identitas RC. Mengikat identitas jaringan
untuk pod atau identitas RC benar-benar rusak.

Saya tidak akan mencoba membuat pencarian DNS terbalik berfungsi untuk biasa atau tanpa kepala
layanan, dan saya tidak berpikir itu tidak masuk akal untuk memaksakan maksimal satu nominal
layanan per pod -- yang tidak harus membatasi jenis layanan lain di
semua.

Ada sejumlah batasan DNS yang ingin kami dorong dalam jangka panjang
(pembatalan cache, dukungan untuk polling panjang, dll.). Beberapa catatan PTR
mungkin hanya item lain yang ditambahkan ke daftar itu.

Alternatif lainnya adalah kita dapat memberikan IP layanan ke setiap pod dari
layanan nominal dan kemudian memecahkan masalah yang menciptakan.

Banyak dari layanan ini mengharapkan bahwa IP yang mereka miliki (nama mereka) di-resolve ke IP yang mereka sambungkan - jadi jika mereka terhubung ke X pada 172.1.1.1, maka X menganggapnya 172.1.1.1. Itu tidak semua perangkat lunak, tetapi beberapa di antaranya. Biasanya itu nama DNS, yang berarti IP dapat berubah di bawahnya.

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

Saya khawatir ini semua masih agak abstrak bagi saya.

Sistem berkerumun nyata memiliki anggota yang memiliki "identitas" yang
diharapkan akan terus menerus dengan adanya kegagalan node. Identitas itu
mungkin dilampirkan ke persistent disk atau "nama", tetapi nama itu
mengidentifikasi ke sistem lain tidak dapat berubah.

Ini bukan persyaratan. Ini sangat kabur sehingga tidak bisa diterapkan.

Contoh, penjaga kebun binatang memiliki identitas per simpul. Identitas itu harus tetap ada
stabil dalam keanggotaan cluster

Apa itu identitas? Alamat IP? Bendera string diteruskan ke perangkat lunak?
dan envvar? Bagaimana proses zk mempelajari identitasnya sendiri?

Beberapa jenis pengontrol dapat secara dinamis mengatur/menghapus beberapa bidang pada pod

Yang akan memicu pod tersebut untuk memulai kembali, dan masih tidak menjawab
pertanyaan tentang bidang apa, nilai apa, dan logika apa yang harus diberitahukan ke pod?

Saya bisa melihat sesuatu seperti memperluas anotasi menjadi flag baris perintah
(seperti yang sedang kita diskusikan dengan env vars) atau hanya ke env vars. Misalnya
controller menulis anotasi["zookeeper.com/index"] = 9, kami mengonversi
$.metatdata["zookeeper.com/index"] ke dalam ZK_INDEX env. Tapi saya membuat ini
up, saya belum melihat tuntutan konkret yang mengatakan apa sebenarnya penjaga kebun binatang (atau
apapun) perlu.

Saya tidak berpikir tidak masuk akal untuk memaksakan maksimal satu layanan nominal
per polong

Saya pikir akan sulit untuk menerapkan pembatasan seperti itu. Sistemnya begitu
digabungkan secara longgar dan tidak sinkron bahwa memaksakan batasan ini mungkin lebih buruk daripada
hanya memecahkan masalah.

kami dapat memberikan IP layanan untuk setiap pod dari layanan nominal

Di sinilah kita mulai, tapi...

Banyak dari layanan ini mengharapkan IP yang mereka miliki (nama mereka)
memutuskan ke IP tempat mereka terhubung - jadi jika mereka terhubung ke X pada 172.1.1.1,
maka X menganggapnya 172.1.1.

IP layanan tidak memenuhi ini, kecuali jika kita melakukan sesuatu yang lebih mendalam seperti
Saya sebutkan dengan SNAT/DNAT. Dan bahkan itu memiliki kekurangan yang nyata.

Saya tidak mencoba untuk menjadi sakit di leher, hanya saja kami memiliki sangat sedikit
waktu menjelang 1.0, dan tidak ada apa pun di sini yang cukup jelas untuk
bahkan pembuktian konsep, apalagi menerapkan dengan benar.

Saya mencoba untuk menjelaskan dengan tepat apa yang ingin kita alami sehingga saya bisa melihat
apa yang bisa kita terapkan. Mengingat referensi berulang ke DNS, saya memegang
dari pengerjaan ulang DNS sampai saya tahu apa yang terjadi di sini.

Pada hari Rabu, 22 Apr 2015 jam 10:12, Clayton Coleman [email protected]
menulis:

----- Pesan asli -----

Beberapa jenis pengontrol dapat secara dinamis mengatur/menghapus beberapa bidang pada
polong. Dia
tidak bisa digabungkan dengan pod atau identitas RC. Mengikat jaringan
identitas
untuk pod atau identitas RC benar-benar rusak.

Saya tidak akan mencoba membuat pencarian DNS terbalik berfungsi untuk biasa atau tanpa kepala
layanan, dan saya tidak berpikir itu tidak masuk akal untuk memaksakan maksimal satu
nominal
layanan per pod -- yang tidak harus membatasi jenis layanan lain di
semua.

Ada sejumlah batasan DNS yang ingin kami dorong dalam jangka panjang
Lari
(pembatalan cache, dukungan untuk polling panjang, dll.). Beberapa PTR
catatan
mungkin hanya item lain yang ditambahkan ke daftar itu.

Alternatif lainnya adalah kita dapat memberikan IP layanan ke setiap pod dari
layanan nominal dan kemudian memecahkan masalah yang menciptakan.

Banyak dari layanan ini berharap bahwa IP yang mereka miliki (nama mereka) dapat diselesaikan
ke IP mereka terhubung - jadi jika mereka terhubung ke X pada 172.1.1.1, maka X
berpikir itu 172.1.1.1. Itu tidak semua perangkat lunak, tetapi beberapa di antaranya. Biasanya itu
nama DNS, yang berarti IP dapat berubah di bawahnya.

---

Balas email ini secara langsung atau lihat di GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

Sebagian besar contoh multi-port adalah sistem berkerumun. Sebagai contoh:
ZK : nama host atau alamat IP yang dapat diselesaikan dalam file konfigurasi, ditambah "id" (yaitu, indeks: 1, 2, 3, ...) dalam file

Kita juga harus melihat melalui beberapa DB.

Apa pun yang kita lakukan tidak akan berhasil untuk semuanya. Kita hanya perlu menemukan sweet spot.

----- Pesan asli -----

Saya khawatir ini semua masih agak abstrak bagi saya.

Sistem berkerumun nyata memiliki anggota yang memiliki "identitas" yang
diharapkan akan terus menerus dengan adanya kegagalan node. Identitas itu
mungkin dilampirkan ke persistent disk atau "nama", tetapi nama itu
mengidentifikasi ke sistem lain tidak dapat berubah.

Ini bukan persyaratan. Ini sangat kabur sehingga tidak bisa diterapkan.

Contoh, penjaga kebun binatang memiliki identitas per simpul. Identitas itu harus tetap ada
stabil dalam keanggotaan cluster

Apa itu identitas? Alamat IP? Bendera string diteruskan ke perangkat lunak?
dan envvar? Bagaimana proses zk mempelajari identitasnya sendiri?

Beberapa jenis pengontrol dapat secara dinamis mengatur/menghapus beberapa bidang pada pod

Yang akan memicu pod tersebut untuk memulai kembali, dan masih tidak menjawab
pertanyaan tentang bidang apa, nilai apa, dan logika apa yang harus diberitahukan ke pod?

Saya bisa melihat sesuatu seperti memperluas anotasi menjadi flag baris perintah
(seperti yang sedang kita diskusikan dengan env vars) atau hanya ke env vars. Misalnya
controller menulis anotasi["zookeeper.com/index"] = 9, kami mengonversi
$.metatdata["zookeeper.com/index"] ke dalam ZK_INDEX env. Tapi saya membuat ini
up, saya belum melihat tuntutan konkret yang mengatakan apa sebenarnya penjaga kebun binatang (atau
apapun) perlu.

Saya tidak berpikir tidak masuk akal untuk memaksakan maksimal satu layanan nominal
per polong

Saya pikir akan sulit untuk menerapkan pembatasan seperti itu. Sistemnya begitu
digabungkan secara longgar dan tidak sinkron bahwa memaksakan batasan ini mungkin lebih buruk daripada
hanya memecahkan masalah.

kami dapat memberikan IP layanan untuk setiap pod dari layanan nominal

Di sinilah kita mulai, tapi...

Banyak dari layanan ini mengharapkan IP yang mereka miliki (nama mereka)
memutuskan ke IP tempat mereka terhubung - jadi jika mereka terhubung ke X pada 172.1.1.1,
maka X menganggapnya 172.1.1.

IP layanan tidak memenuhi ini, kecuali jika kita melakukan sesuatu yang lebih mendalam seperti
Saya sebutkan dengan SNAT/DNAT. Dan bahkan itu memiliki kekurangan yang nyata.

Saya tidak mencoba untuk menjadi sakit di leher, hanya saja kami memiliki sangat sedikit
waktu menjelang 1.0, dan tidak ada apa pun di sini yang cukup jelas untuk
bahkan pembuktian konsep, apalagi menerapkan dengan benar.

Saya mencoba untuk menjelaskan dengan tepat apa yang ingin kita alami sehingga saya bisa melihat
apa yang bisa kita terapkan. Mengingat referensi berulang ke DNS, saya memegang
dari pengerjaan ulang DNS sampai saya tahu apa yang terjadi di sini.

Saya pikir itu bijaksana, kita harus secara khusus mencurahkan waktu untuk memecahkan serangkaian contoh yang diketahui. Kami memiliki 3 pihak yang dapat kami manfaatkan untuk contoh konkret (set replika MongoDB, Zookeeper, Mysql Master/Slave) serta contoh yang ada di kube/examples. Mungkin sesi kerja untuk menyelesaikan item, menetapkan batasan pada masalah yang tidak dapat dipecahkan, mengidentifikasi apa yang tersisa.

Sarankan untuk mengubah nama fitur ini karena fitur ini juga dapat digunakan untuk tugas batch untuk menetapkan nomor ID pecahan.

Pekerjaan batch memiliki persyaratan yang agak berbeda, jadi saya ingin memisahkannya.

Contoh penjaga kebun binatang: https://github.com/openshift/origin/pull/1965

Contoh kebutuhan layanan nominal https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Saya agak bingung mengapa arahnya masih belum jelas di sini - terutama dari para Googler. Google telah menjalankan layanan stateful di bawah Borg selama bertahun-tahun, dan cukup jelas apa yang diperlukan untuk jenis beban kerja ini:

• Pengidentifikasi stabil yang salah satu set "pecahan" (replika non-identik) pod saat ini mewakili (dalam borg, ini adalah "nomor tugas" - bilangan bulat sederhana). Pengenal ini harus tetap konstan di seluruh penjadwalan ulang/restart pod.
• Cara untuk menghitung dan menghubungi semua pecahan "rekan", mungkin dengan menggunakan pengidentifikasi stabil mereka dalam beberapa cara (di borg, ini adalah awalan gemuk bersama dengan nomor tugas)

.. dan kita selesai.

Catatan: Jika pengecualian sumber daya sangat penting untuk setiap shard, maka aplikasi perlu melakukan penguncian terdistribusi mereka sendiri karena selalu ada kemungkinan bahwa masa pakai pod dapat tumpang tindih selama kegagalan/restart (mungkin menggunakan kunci etcd berdasarkan pengenal shard). Ekstensi fitur eksotis yang potensial adalah untuk mengizinkan lebih dari satu replika identik dalam setiap pecahan, untuk redundansi/muatan.

Ini dapat dipalsukan sekarang dengan membuat layanan/port unik untuk setiap pecahan dan menjalankan pengontrol replikasi dengan replika:1 tetapi agak canggung untuk mengelola pecahan dalam jumlah besar "dengan tangan" seperti ini.

Cara alami untuk mengimplementasikan ini di kubernetes mungkin:

• Pod mendapatkan variabel lingkungan tambahan dengan memberikan indeks shard (integer) dan jumlah total shard (atau mungkin mengkomunikasikannya melalui API ke bawah?).
• ReplicationControllers mendapatkan jumlah "pecahan" (default: 1), dan "replika" ditafsirkan ulang menjadi "replika dalam setiap pecahan" (default: 1). Saat mengecilkan set replika, mereka harus membunuh dari akhir (untuk menjaga agar indeks pecahan tetap berdekatan). Catatan mengubah "pecahan" akan membutuhkan restart pod terkontrol untuk memperbarui "total pecahan" env var (baik, Anda tidak ingin itu terjadi secara instan).
• Layanan mendapatkan jumlah "pecahan" serupa yang memetakan rentang port yang berdekatan ke pemilih reguler ditambah pemilih "indeks pecahan" implisit.
• Pod dapat menemukan shard lain dengan menggunakan SERVICE_PORT (atau env var baru?) + offset indeks shard.

Perhatikan hal di atas dengan anggun menurun ke perilaku saat ini ketika shards=1.

Saya biasanya setuju dengan ini (dan seperti yang Anda katakan, ini telah menguji waktu di Borg), meskipun saya akan menyarankan untuk tidak menggunakan "ekstensi fitur eksotis" dari beberapa replika per pecahan (meskipun kami mungkin memerlukan sesuatu seperti itu di bawah perlindungan untuk migrasi).

Seperti yang saya sebutkan sebelumnya, ini terkait erat dengan apa yang perlu kita lakukan untuk mendukung pekerjaan batch dengan tugas pekerjaan statis (apa yang saya sebut "tipe 1" di sini: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142 )

Fitur lain yang perlu kita selaraskan jika kita mengubah RC (atau menambahkan sesuatu yang baru) adalah bagaimana penerapannya cocok, khususnya:

Bagaimana cara melakukan pembaruan bergulir ke:

1. RC biasa
2. Sebuah PerNodeController
3. RC yang terpotong
4. Pekerjaan batch?

Kami mungkin ingin menahan penerapan penerapan sampai kami memiliki pekerja keras untuk masing-masingnya, karena saya yakin penerapan yang hanya berfungsi melawan RC sederhana memiliki beberapa masalah.

----- Pesan asli -----

Saya biasanya setuju dengan ini (dan seperti yang Anda katakan, itu telah teruji oleh waktu
di Borg), meskipun saya menyarankan untuk tidak menggunakan "fitur eksotis
ekstensi" dari beberapa replika per pecahan (meskipun kami mungkin membutuhkan sesuatu
seperti itu di bawah selimut untuk migrasi).

Seperti yang saya sebutkan sebelumnya, ini terkait erat dengan apa yang perlu kita lakukan untuk
mendukung pekerjaan batch dengan tugas kerja statis (apa yang saya sebut "tipe 1"
di sini:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

Kami telah memilih untuk tidak memprioritaskan ini (dan secara otomatis membuat klaim volume persisten) untuk 1.0 karena ada beberapa solusi, seperti membuat satu layanan, RC, dan klaim volume persisten per instans.

Meskipun indeks tugas yang ditetapkan secara statis dan padat di Borg sangat banyak digunakan, kami telah mengetahui bahwa indeks tersebut memiliki sejumlah kekurangan, dan telah menghabiskan beberapa waktu selama beberapa tahun terakhir untuk mengembangkan alternatif. Banyak masalah berasal dari fakta bahwa indeks digabungkan dengan siklus hidup dan identitas tugas itu sendiri. Ini mempersulit penerapan sejumlah strategi penerapan, migrasi, manajemen tugas dinamis, dan banyak skenario lainnya. Kompleksitas lainnya berasal dari menghasilkan konfigurasi per indeks secara statis untuk setiap pra-penempatan tugas -- ini sama saja dengan menghasilkan satu RC per nilai indeks. Itu akan mudah dilakukan seseorang jika mereka benar-benar menginginkannya. Label masih bisa digunakan untuk meruntuhkan seluruh rangkaian.

Pengontrol per-node/daemon: Poin bagus. Indeks yang ditetapkan secara padat adalah model yang buruk untuk kasus itu. Apa yang Anda lakukan ketika sebuah simpul hilang secara permanen, misalnya? Indeks menjadi jarang. Saya sarankan kami tidak mendukung itu.

Pekerjaan batch: Seperti yang dibahas di #1624, kami ingin menetapkan indeks berdasarkan penyelesaian, bukan pod yang sedang berjalan.

Seperti dibahas di atas, penetapan indeks perlu mempertimbangkan penyimpanan terkait, seperti klaim volume persisten -- identitas berasal dari identitas jaringan (nama DNS dan/atau alamat IP) dan penyimpanan.

Tugas tidak dapat didorong oleh pengontrol replikasi tunggal. Ini tidak bekerja. Pengontrol replikasi bukanlah entitas yang tahan lama, dan kami berharap akan ada beberapa RC per layanan, untuk kenari, pembaruan bergulir, beberapa track rilis, beberapa cluster, dll. Bahkan objek Deployment yang diusulkan (#1743) tidak memiliki cakupan yang tepat .

Ada 3 alternatif untuk penugasan:

1. Mengaitkan tugas dengan jenis Layanan khusus. Layanan memiliki cakupan yang tepat. (Kami juga pada akhirnya akan membutuhkan layanan regional.) Ini akan menjadi semacam campuran antara layanan reguler dan layanan tanpa kepala. Itulah yang saya bayangkan ketika saya awalnya mengusulkan mekanisme ini. Tugas akan dicatat di Endpoints. Titik akhir dan/atau DNS tanpa kepala akan menjadi cara yang jelas untuk menghitung semua rekan.
2. Buat jenis objek baru yang mirip dengan Layanan, tetapi hanya untuk layanan nominal. Kami mungkin juga membutuhkan objek baru untuk merekam tugas. Ini akan memperluas permukaan API kami secara tidak perlu, IMO.
3. "Tarik" bukannya "dorong". Pod dijadwalkan untuk dihosting tanpa pengontrol eksplisit, bahkan dengan batasan node (selector) atau salah satu mekanisme anti-afinitas yang diusulkan (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Ini juga mirip dengan tugas layanan VIP. Kami dapat melakukan hal serupa untuk layanan nominal. Sebuah pod (atau template pod) akan menentukan kumpulan indeks dari mana ia menginginkan indeks ditetapkan. Tidak seperti layanan umum, kami tidak mengharapkan pod perlu diberi beberapa indeks dari kumpulan yang berbeda. Tugas akan direkam dalam spesifikasi pod.
4. Kelebihan: Lebih sederhana bagi pengguna. Tidak memerlukan objek lain. Mengizinkan penugasan oleh pengguna.
5. Kekurangan: Berbeda dengan jenis layanan lainnya.

Penugasan PVC idealnya akan menggunakan model yang sama.

Penting juga untuk mempertimbangkan bagaimana migrasi pod #3949 akan diatur. Pod pengganti HARUS dibuat sebelum menghapus pod yang diganti untuk mentransfer status container. Ini mungkin membuat model tarikan sedikit bermasalah. Terlepas dari itu, mekanisme alokasi perlu dibuat sadar migrasi.

Pertimbangan lainnya:

1. Bagaimana mengkomunikasikan indeks/identitas kepada rekan-rekan. DNS adalah jawaban yang jelas.
2. Cara mengomunikasikan indeks/identitas ke wadah di pod. Variabel lingkungan, DNS balik, ... Indeks yang ditetapkan tidak akan berubah secara dinamis, meskipun pengikatan DNS dapat diubah saat pod masih ada. Saya ingin memilih mekanisme yang diharapkan aplikasi untuk bekerja di lingkungan lain, dan seperti pada diskusi API ke bawah yang lebih luas (#386), saya tidak ingin memasangkan aplikasi ke variabel lingkungan khusus Kubernetes, tetapi EnvVarSource baru dan substitusi env var (#7936) akan membantu menghindarinya.

Saya tidak setuju dengan beberapa dari apa yang Anda katakan, tetapi mari kita tunggu untuk melanjutkan diskusi ini sampai setelah 1.0.

Menghidupkan kembali utas lama ini untuk mengajukan pertanyaan. Apakah ada minat dalam kebijakan penamaan pengontrol replikasi? Secara khusus penamaan nominal seperti yang dibahas di atas, di mana semua Pod yang dikendalikan oleh pengontrol replikasi ini akan memiliki sufiks bernomor, kira-kira seperti 0001, 0002 ....

Contoh kasus penggunaan adalah penyeimbang beban nginx yang menunjuk ke kumpulan pod ini dengan nama domain. Jadi saat pod datang dan pergi, nama domain diharapkan selalu diperbaiki dari xxx-0001 hingga xxx-000N.

@ravigadde Silakan baca komentar terakhir saya tentang masalah ini: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

Mengalami masalah ini saat mencoba menyiapkan wadah RabbitMQ. Kegigihan kelinci tergantung pada nama host, jadi memiliki nama host variabel berarti Anda kehilangan database Mnesia saat wadah dimulai ulang.

Mencoba memperbaiki dengan konfigurasi gambar (nama host secara langsung dan Kelinci), variabel ENV, dan API ke Bawah. Tidak bisa mendapatkan apapun untuk memecahkan masalah - Kelinci masih mengambil nama Pod yang dihasilkan. Memecahkan sementara dengan beralih dari menggunakan Pengontrol Replikasi sesuai saran @mikedanese .

Jika saya mengerti dengan benar, pod rabbitmq (dibuat dengan pengontrol replikasi) dalam contoh celerey-rabbit akan kehilangan data pada kegagalan pod bahkan jika data disimpan di persistent disk. Dari kelincimq doc:

RabbitMQ memberi nama direktori database menggunakan nama host sistem saat ini. Jika nama host berubah, database kosong baru dibuat. Untuk menghindari kehilangan data, sangat penting untuk menyiapkan nama host yang tetap dan dapat dipecahkan.

Tidak ada solusi yang baik untuk ini sekarang, tetapi Anda dapat membuat pod (tidak terikat ke rc) dengan persistent disk yang dapat dipindahkan, peringatan bahwa pod perlu dijadwal ulang secara manual dalam kasus kegagalan tertentu. Itulah satu-satunya cara yang dapat saya pikirkan untuk menjaga nama host tetap statis.

Atau saat startup, hubungkan direktori nama host ke lokasi yang stabil

Pada 11 Juli 2015, pukul 17:26, Mike Danese [email protected] menulis:

Jika saya mengerti dengan benar, pod rabbitmq (dibuat dengan replikasi
controller) di clerey-kelinci
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
contoh akan kehilangan data pada kegagalan pod bahkan jika data disimpan di a
disk yang persisten. Dari kelincimq doc:

RabbitMQ memberi nama direktori database menggunakan nama host saat ini dari
sistem. Jika nama host berubah, database kosong baru dibuat. Menghindari
kehilangan data, sangat penting untuk menyiapkan nama host yang tetap dan dapat dipecahkan.

Tidak ada solusi yang baik untuk ini sekarang, tetapi Anda dapat membuat pod (bukan
terikat ke rc) dengan persistent disk yang dapat dipindahkan, peringatannya adalah pod
akan perlu dijadwal ulang secara manual dalam kasus kegagalan tertentu. Itu adalah
satu-satunya cara yang dapat saya pikirkan untuk menjaga nama host tetap statis.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

Itulah contoh mengapa nama host tidak boleh diturunkan dari nama pod -- #4825

Untuk memberikan ini sedikit tendangan:

Ada beberapa masalah mendasar yang perlu dipecahkan:

1. Beberapa komponen perlu memiliki identitas unik per pod yang terkait dengan penyimpanannya di disk
   
   
   
   1. Sebagai kerutan lebih lanjut, beberapa dari mereka (penjaga kebun binatang dalam beberapa kasus) membutuhkan nama host yang dapat dipecahkan dan cocok
   
   
2. Beberapa komponen yang diskalakan perlu memiliki penyimpanan persisten yang berbeda per pod (pod menunjuk ke PVC yang berbeda per pod, terikat kembali ke identitas)
   
   
   
   1. Terkadang volume tersebut harus dibuat sesuai permintaan saat ditingkatkan
   
   
   2. Terkadang volume itu harus digunakan kembali dari kolam dan tidak dibuat ulang
   
   
3. Beberapa komponen dapat ditingkatkan hingga puluhan ribu contoh, di mana pelacakan identitas individu yang dialokasikan menjadi tidak praktis
   
   
   
   1. Sebagian besar penggunaan untuk nominal mungkin antara 2-7 instance pod (DB skalabel terkini, sebagian besar pengaturan multi-master sharded)
   
   
4. Beberapa komponen ingin tidak harus mengimplementasikan pemilihan master mereka sendiri, tetapi biarkan platform mengaturnya dengan membuat salah satu identitas menjadi sewenang-wenang (identitas 1 menjadi master)
5. Saat kami menyelesaikan masalah ini, pengguna masih perlu meluncurkan perubahan pada pod (melalui penerapan) dan memastikan bahwa identitas apa pun dipertahankan atau dialokasikan kembali.

Ini tidak semua harus diselesaikan dalam solusi yang sama. Misalnya, saya pikir ada perbedaan yang signifikan antara identitas klaster berukuran kecil (2-7) dan identitas klaster skala besar (>7). Misalnya, dalam kasus besar, perangkat lunak itu tidak terlalu peduli dengan celah, atau memiliki protokol konsensus/keanggotaan yang ada. Dalam kasus kecil, perangkat lunak membutuhkan lebih banyak bantuan dalam membangun identitas. Saya akan memisahkan ini menjadi perangkat lunak cloud-native (>7) dan cluster yang ada (2-7).

Saya setuju dengan 1a, 1b, dan 2a. 2b terdengar seperti masalah yang berbeda, meskipun mungkin solusinya dapat menggunakan kembali pola yang sama.

Saya pikir skala (3) terutama menunjukkan bahwa solusi kami untuk satu layanan dan RC per instance tidak memadai, meskipun saya setuju dengan perbedaan antara cloud-native vs tidak.

Pemilihan induk (4) dapat ditangani secara terpisah.

Juga setuju dengan (5).

Saya pikir sebagian besar persyaratan desain sudah jelas pada saat ini.

Pertanyaan desain yang tersisa:

I. Alokasikan VIP atau izinkan IP berubah? Terkait erat dengan ini adalah apakah wadah harus dapat menemukan IP mereka sendiri melalui Linux atau tidak, karena VIP saat ini tidak dapat ditemukan melalui sistem. Saya berasumsi mereka harus dapat menemukan IP mereka, tetapi dapat menggunakan API ke bawah, seperti IP pod (#12595). Mengizinkan IP berubah (karena menggunakan IP pod) menyiratkan batas laju perubahan IP, karena TTL DNS dan "bug" caching. Namun, pada titik tertentu, kami juga bermaksud membuat IP pod dapat dimigrasikan (#3949), jadi mengubah IP tidak akan selamanya.

II. Dorong (ke pod) vs. tarik (dari pod). Layanan dan RC sengaja digabungkan secara longgar ke pod, dan oleh karena itu keduanya menggunakan model "push". Layanan nominal akan lebih terikat secara intrinsik dengan identitas pod (meskipun tidak secara permanen -- pod harus dapat diganti). Akibatnya, saya melihat lebih sedikit motivasi untuk model push. Kasus alokasi lainnya, seperti penjadwalan, dan khususnya. pengikatan eksklusif, seperti klaim volume persisten ke volume persisten, gunakan model permintaan/ack, alias "tarik". Itu adalah model yang saya sukai untuk layanan nominal.

Ada yang punya pendapat tentang (saya)?

Pemilihan master adalah #1542, dan sedang dibahas sebagai bagian dari implementasi HA (misalnya, #12884).

Saya tidak tahu apa yang Anda maksud dengan mendorong dan menarik.

Saya telah membaca ulang sebagian besar masalah ini, dan saya yakin tidak ada satu pun
larutan. Kami akan membutuhkan serangkaian fitur untuk membangun jembatan untuk
aplikasi semacam ini.

Saya mulai dengan aksioma bahwa sekali pod berjalan Anda tidak bisa benar-benar
mengubah pod yang sedang berjalan. Ada beberapa pengecualian untuk ini (misalnya virtual
isi sistem file) tetapi hal-hal yang tampaknya penting (env vars, IP,
hostname) Anda terjebak dengan apa pun yang Anda mulai.

Saya juga mulai dengan pernyataan bahwa kopling longgar antara
Layanan dan Pod tetap, membuat hal yang kita bicarakan ini tidak terlalu
Melayani. Pod tidak benar-benar tahu Layanan apa yang ada di depan mereka. Jika kita berubah
itu, itu bukan Layanan lagi.

Saya hanya akan melakukan aliran kesadaran dan melihat apa yang tidak berbau busuk.

Ide 1: ThingPools dan Patch.

Tentukan objek API baru atau sesuatu yang memungkinkan Anda menentukan kumpulan
hal-hal. Apa itu sesuatu? A Thing adalah string (atau mungkin gumpalan JSON) yang
memiliki tipe enumerasi. Anda dapat membuat kumpulan Hal dan Hal-hal itu
adalah milik Anda untuk digunakan. Jenis hal termasuk VUID (nama host), string, VIP.

Tentukan konstruksi API baru yang dapat diteruskan untuk membuat operasi - a
tambalan. Patch adalah instruksi tentang cara menambal objek yang sedang
dibuat. Salah satu opsi tambalan adalah "mengalokasikan dari ThingPool".

Untuk menggabungkan ini:

Tentukan ThingPool { meatadata.name: my-quorum-hostnames, ketik: VUID,
autogenerate: 5, } // membuat kumpulan 5 VUID yang valid

Tentukan RC { replika: 5 ...}

Di RC's buat (POST) juga kirim Patch: { apa:
"podTemplate.spec.containers[*].metadata.VUID", kumpulan: "my-quorum-hostnames"
}

Operasi POST akan menerapkan patch ke RC - mengalokasikan satu VUID
per kontainer dari ThingPool. Setiap kali pod dibunuh dan dibuat ulang,
VUID dikembalikan ke pool dan pod berikutnya yang akan dijalankan akan mendapatkannya.

Anda dapat menggunakan ini untuk menghasilkan kumpulan string ("0" hingga "99") dan stick
mereka menjadi env var. Anda bisa menggunakan ini untuk mengalokasikan kumpulan VIP dan
lalu tetapkan VIP tersebut ke pod (akan menjadi fitur baru - pod tahan lama
IP - tidak yakin bagaimana skalanya :) Anda dapat menghasilkan kumpulan
PersistentVolumeClaim menamai dan menambal volume claim yang digunakan setiap pod.

Ide ini tidak sempurna dalam banyak hal, tetapi menurut saya ide ini paling baik menangkap
ide satu set pod tanpa langsung mendefinisikan satu set pod.

Ide 2: Tentukan satu set pod. Jangan berpura-pura itu adalah layanan. Ini lebih dekat
ke Pekerjaan Borg. Ini seperti RC tetapi memberikan ordinalitas ke podnya
kontrol - nomor pecahan. Ini mengontrol kumpulan VUID (tetapi kami tidak ingin
hostname menjadi sesuatu yang dapat diatur pengguna, hmmm...).

Saya pikir saya punya lebih banyak ide, tapi ternyata tidak. Saya bergulat dengan abstraksi
dan implementasi - tidak ada gunanya mendefinisikan abstraksi yang tidak dapat kami lakukan
melaksanakan. VIP untuk nominal terdengar bagus, tapi saya pikir itu akan mendorong
batas iptables. Menyediakan satu set nama host yang stabil untuk satu set pod
tampaknya menjadi hal yang paling penting, dengan satu set penyimpanan untuk satu set
polong panas di ekornya.

Pada Tue, 18 Agustus 2015 di 07:28, Brian Hibah [email protected]
menulis:

Saya setuju dengan 1a, 1b, dan 2a. 2b terdengar seperti masalah yang berbeda
mungkin solusinya dapat menggunakan kembali pola yang sama.

Saya pikir skala (3) terutama menunjukkan bahwa solusi kami untuk satu layanan dan
RC per instance tidak memadai, meskipun saya setuju dengan perbedaan antara
cloud-asli vs tidak.

Pemilihan induk (4) dapat ditangani secara terpisah.

Juga setuju dengan (5).

Saya pikir sebagian besar persyaratan desain sudah jelas pada saat ini.

Pertanyaan desain yang tersisa:

I. Alokasikan VIP atau izinkan IP berubah? Terkait erat dengan ini adalah apakah
container harus dapat menemukan IP mereka sendiri melalui Linux atau tidak,
karena VIP saat ini tidak dapat ditemukan melalui sistem. Saya berasumsi mereka melakukannya
harus dapat menemukan IP mereka, tetapi dapat menggunakan API ke bawah, seperti
dengan IP pod (#12595 https://github.com/kubernetes/kubernetes/pull/12595).
Mengizinkan IP berubah (karena menggunakan IP pod) menyiratkan batasan tarif
perubahan IP, karena TTL DNS dan caching "bug". Pada titik tertentu, kita
juga bermaksud membuat IP pod dapat dimigrasikan (#3949
https://github.com/kubernetes/kubernetes/issues/3949), jadi ganti IP
tidak akan selamanya.

II. Dorong (ke pod) vs. tarik (dari pod). Layanan dan RC adalah
sengaja digabungkan secara longgar ke pod, dan karena itu keduanya menggunakan "push"
model. Layanan nominal akan lebih terikat secara intrinsik dengan identitas pod
(meskipun tidak secara permanen -- pod harus dapat diganti). Akibatnya, saya melihat
kurang motivasi untuk model push. Kasus alokasi lainnya, seperti
penjadwalan, dan esp. pengikatan eksklusif, seperti klaim volume persisten untuk
volume persisten, gunakan model permintaan/ack, alias "tarik". Itu saat ini
model yang saya sukai untuk layanan nominal.

Ada yang punya pendapat tentang (saya)?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

Saya mungkin tidak benar-benar bermaksud pemilihan master seperti yang Anda pikirkan - lebih dari itu
saat membangun fungsionalitas di mana serangkaian instance perlu diinisialisasi
(tanpa berkoordinasi secara eksplisit) hanya memiliki instance yang berpikir itu
"1" berbicara dengan pod lain biasanya cukup untuk mem-bootstrap sebuah cluster. Sebuah
contohnya adalah mongodb di mana Anda perlu memulai set replika - if pods
yang mengira mereka adalah inisiasi "2" atau "3", Anda bisa mendapatkan kasus di mana Anda
memulai perpecahan. Tapi "1" dapat dengan aman memulai dirinya sendiri setiap kali, dan kemudian
coba tambahkan anggota lain (yang memiliki status persisten yang dapat mereka gunakan untuk
menentukan apakah mereka sudah menjadi bagian dari sebuah cluster). Tergantung pada
jaminan yang diberikan oleh layanan identitas yang mungkin sebenarnya tidak Anda dapatkan
cluster yang berhasil, tetapi Anda tidak perlu membuat pod terpisah di luar untuk
inisialisasi layanan Anda (walaupun itu juga tidak buruk).

Pada Selasa, 18 Agustus 2015 pukul 23.59, Brian Grant [email protected]
menulis:

Pemilihan master adalah #1542
https://github.com/kubernetes/kubernetes/issues/1542 , dan sedang
dibahas sebagai bagian dari implementasi HA (misalnya, #12884
https://github.com/kubernetes/kubernetes/pull/12884).

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

Clayton Coleman | Insinyur Utama, OpenShift

@smarterclayton Ini selain masalah layanan nominal, tetapi tidak aman untuk bootstrap seperti yang Anda gambarkan. Jika "1" di-restart pada mesin baru dan kebetulan tidak dapat mencapai node yang ada, maka itu akan mem-bootstrap ulang dan sekarang Anda memiliki dua mongodb yang mengklaim sebagai otoritatif. Anda perlu mengubah definisi pekerjaan untuk menghapus kemampuan bootstrap setelah bootstrap selesai.

Seperti yang mungkin disinggung oleh

Saya melihat dua kasus penggunaan yang sangat berbeda yang dijelaskan di atas - berbeda berdasarkan sumber kebenaran:

_Prescriptive:_ "Saya ingin N shard berjalan, dan jika ada lebih atau kurang dari itu, maka buat perubahan untuk mengembalikannya ke N."
_Descriptive:_ "Saya hanya ingin menemukan semua shard yang tersedia secara otomatis, dan biarkan saya mengetahuinya saat mereka datang dan pergi."

Saya pikir ini berbeda dan harus dijelaskan secara berbeda (walaupun mereka mungkin menyajikan metadata yang mirip dengan pod yang sedang berjalan).

Diskusi juga telah memasukkan pagar sumber daya dan jaminan akses tunggal. Afaics, kasus _only_ di mana ini perlu dilakukan dalam k8s adalah memasang volume persisten jarak jauh (karena pemasangan fs perlu dilakukan di luar wadah), dan ini cukup mudah dilakukan melalui kunci etcd jika layanan volume jarak jauh yang mendasarinya tidak' t sudah menyediakan pagar internal. Semua kasus lain dapat ditangani oleh pekerjaan pengguna itu sendiri, menggunakan layanan kunci terdistribusi (atau mengakses layanan yang menyediakan penguncian secara internal). Meminta pekerjaan untuk melakukan penguncian mereka sendiri membuka segala macam pola (tugas tetap, tugas oportunistik, "suku cadang panas", dll) dan strategi tidak terjangkau/pemulihan (gagal keras, lanjutkan dengan yang terakhir diketahui, dll).

Saya menyarankan untuk memindahkan permintaan fitur pagar sumber daya umum dari bug ini (dan kami menerapkan pagar hanya dengan menyediakan resep untuk menjalankan berbagai layanan penguncian terdistribusi pada k8s tanpa keterlibatan lebih lanjut oleh k8s itu sendiri).

Sekedar pengingat: ada _lot_ port di belakang satu VIP. Saya setuju kami tidak ingin memigrasikan IP karena kedengarannya sulit pada skala jaringan yang mendasarinya, dan canggung bagi jaringan untuk menangani duplikat sementara selama kasus tepi kegagalan/pemulihan. Namun, saya pikir _is_ cukup layak untuk menetapkan port layanan unik untuk setiap anggota shard dan data proxy untuk setiap instans pod - bahkan untuk pekerjaan yang sangat besar. (Saran ini mengasumsikan proxy masih merupakan arah yang ingin kita tuju dengan k8s - saya belum mengikuti diskusi terbaru di sekitar area ini)

Dengan push, maksud saya sumber daya lain, seperti Layanan atau pengontrol, akan memantau kumpulan pod melalui pemilih label dan memberikan "sesuatu" (nama DNS yang dapat diselesaikan, VIP, PVC) kepada mereka.

Dengan tarik, maksud saya pod akan secara eksplisit meminta alokasi "sesuatu", yang kemudian akan terikat padanya melalui sesuatu seperti /binding.

Mengenai mengganti pod yang sedang berjalan: Mengubah pod setelah pembuatan berbeda dengan mengganti pod dengan container yang sedang berjalan. Penjadwal melakukan async. inisialisasi, misalnya. PodIP ditugaskan terlambat, juga. Dibahas lebih umum di #3585.

Mengenai apakah ini benar-benar "layanan" atau tidak:

• Hal-hal perlu dialokasikan di seluruh set pod
• Hal (misalnya, nama DNS) tidak boleh terikat secara intrinsik dengan nama sumber daya pod
• Sesuatu perlu dipindahkan dari satu pod ke pod lainnya
• Pod perlu "mengetahui" (atau dapat mengetahui melalui API ke bawah) hal apa (terutama nama DNS dan VIP) yang ditugaskan.
• Satu hal yang perlu kita dukung adalah DNS yang dapat diselesaikan
• Apakah kami membutuhkan VIP adalah satu-satunya pertanyaan saya yang luar biasa. Saya baik-baik saja dengan tidak menggunakan VIP.
• Ini tidak ideal, tetapi pengguna dapat membuat layanan tanpa kepala kedua yang menargetkan seluruh rangkaian untuk penemuan rekan melalui DNS dan/atau Titik Akhir.

Ide (1), ThingPools + Patch adalah ide yang menarik. Saya akan menggambarkannya sebagai pendekatan "tarik". ThingPool tidak buruk, tetapi saya khawatir Patch akan sulit digunakan, dan saya tidak ingin merekayasa balik informasi semantik dari patch di dalam sistem untuk memberikan perilaku yang dapat diterima seputar siklus hidup penyimpanan, dll. Saya' d lebih suka sesuatu yang lebih spesifik untuk domain. Juga, ThingPools independen untuk nama DNS dan PVC tidak akan berfungsi, karena mereka perlu dialokasikan bersama.

Saya akan menggambarkan ide (2) sebagai pendekatan "dorong". Saya tidak ingin menduplikasi pekerjaan pada RC dan Deployment, jadi sebaiknya kita tidak memperkenalkan pengontrol pod lain. Pemberi tugas akan baik-baik saja, tetapi lebih longgar digabungkan daripada yang diperlukan dan tidak cocok dengan preseden untuk cara kami menangani penugasan.

Ulang. memasukkan info ke env vars: Ini juga muncul untuk Job. Saya ingin memasukkan info ke dalam anotasi dan memperluas API ke bawah untuk dapat meminta anotasi tertentu. Saya ingin terus mengizinkan pengguna untuk hanya meminta info yang mereka butuhkan dan memilih nama env var.

Ulang. menetapkan port yang berbeda untuk setiap instance: Itu tidak akan berfungsi untuk banyak aplikasi lawas, dan juga tidak kompatibel dengan desain sistem kami.

Ulang. preskriptif: Menjaga N tetap berjalan adalah apa yang dilakukan ReplicationController.

Ulang. deskriptif: Itu layanan tanpa kepala, yang sudah ada.

Ulang. penguncian: Ya, itulah API sewa yang sedang berlangsung.

Penyediaan penyimpanan sedang dibahas di #6773 (push) dan #12450 (tarik).

Sudah terlambat sekarang, tetapi entah bagaimana saya akan mencoba meluangkan waktu untuk membuat proposal setelah tidur.

Pengamatan cepat: layanan tanpa kepala tidak mengalokasikan VIP

Kami dapat memisahkan alokasi/penugasan dari publikasi DNS. Mengabaikan bagaimana alokasi/penugasan terjadi untuk saat ini, kita dapat memiliki rasa khusus dari layanan tanpa kepala yang mengambil nama dari beberapa bidang pada pod yang mewakili nama host.

Dan, masalah penyimpanan lokal yang tahan lama relevan: #7562, #1515, #598

Pembaruan lebih cepat karena saya kebanyakan melakukan ulasan PR lainnya:

Salah satu keuntungan menggunakan layanan adalah kita tidak perlu menjamin bahwa nama host yang diminta untuk pod unik secara global, karena layanan akan mencakup nama yang dipublikasikan ke DNS.

Ulang. alokasi/penugasan: Saya ingin menghindari menambahkan lebih banyak jenis templat ke ReplicationController, Deployment, Daemon, dll., dan saya ingin penyimpanan dan nama dapat bermigrasi lintas pengontrol semudah melintasi pod (jika itu yang diinginkan pengguna).

Pada 19 Agustus 2015, pukul 01:04, Angus Lees [email protected] menulis:

@smarterclayton https://github.com/smarterclayton Ini selain untuk
masalah layanan nominal, tetapi tidak aman untuk melakukan bootstrap seperti Anda
menggambarkan. Jika "1" dihidupkan ulang pada mesin baru dan kebetulan tidak dapat
untuk mencapai node yang ada, maka akan di-bootstrap ulang dan sekarang Anda memiliki dua
mongodb mengklaim sebagai otoritatif. Anda perlu mengubah pekerjaan
definisi untuk menghapus kemampuan bootstrap setelah bootstrap adalah
menyelesaikan.

Sangat mungkin Anda akan memiliki tumpang tindih dalam kasus itu - tetapi sebagian besar
kasus kita berbicara tentang penyimpanan persisten dengan kunci sehingga Anda akan memblokir
tetap sampai gce/AWS melepaskan pagar Anda dan Anda dapat memasangnya. Jadi
Anda mengorbankan ketersediaan saat bootstrap tetapi tidak harus saat runtime
(kecuali jika Anda menggunakan penyimpanan tanpa pagar, dalam hal ini saya setuju bahwa ini tidak akan terjadi
aman)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

Pada 19 Agustus 2015, pukul 1:35 pagi, Angus Lees [email protected] menulis:

Seperti yang mungkin disinggung oleh https://github.com/thockin , saya pikir
kami tidak perlu menggabungkan beberapa fitur serupa tetapi berbeda di sini

• dan kami menyertakan lebih dari yang benar-benar diperlukan di tingkat k8s.

Saya melihat dua kasus penggunaan yang sangat berbeda yang dijelaskan di atas - berbeda berdasarkan sumber
kebenaran:

_Prescriptive:_ "Saya ingin N shard berjalan, dan jika ada lebih atau kurang
dari itu, lalu buat perubahan untuk mengembalikannya ke N."
_Descriptive:_ "Saya hanya ingin menemukan semua pecahan yang tersedia secara otomatis, dan
biarkan aku mencari tahu entah bagaimana saat mereka datang dan pergi."

Saya pikir ini berbeda dan harus dijelaskan secara berbeda (walaupun

mereka mungkin menyajikan metadata yang mirip dengan pod yang sedang berjalan).

Diskusi juga telah memasukkan pagar sumber daya dan akses tunggal
jaminan. Afaics, kasus _only_ di mana ini perlu dilakukan dalam k8s
(afaics) sedang memasang volume jarak jauh - karena pemasangan fs perlu dilakukan
di luar wadah. Semua kasus lain dapat ditangani oleh pekerjaan pengguna
sendiri, menggunakan layanan kunci terdistribusi (atau mengakses layanan yang
menyediakan penguncian internal). Meminta pekerjaan untuk melakukan penguncian mereka sendiri terbuka
up segala macam pola (tugas tetap, tugas oportunistik, "panas
suku cadang", dll) dan strategi tidak terjangkau/pemulihan (gagal berat,
lanjutkan-dengan-terakhir diketahui, dll).

Saya sarankan untuk memindahkan permintaan fitur pagar sumber daya umum dari ini
bug (dan kami menerapkan pagar hanya dengan memberikan resep untuk berlari
berbagai layanan penguncian terdistribusi pada k8s tanpa keterlibatan lebih lanjut oleh
k8s itu sendiri).

Saya tidak berpikir kita dapat memisahkan tujuan untuk menjalankan jenis tertentu
perangkat lunak keluar - desain mengatakan layanan nominal tetapi kasus penggunaan kami
menggambarkan adalah menggunakan kembali identitas dan disk. Saya setuju, pagar adalah milik
volume - tetapi mengikat perolehan volume ke properti tertentu dari
instance pod tidak.

Sekedar pengingat: ada _lot_ port di belakang satu VIP. saya setuju kita
tidak ingin memigrasikan IP karena kedengarannya sulit di jaringan yang mendasarinya
dalam skala besar, dan canggung bagi jaringan untuk menangani duplikat sementara
selama kasus tepi kegagalan/pemulihan. Namun, saya pikir itu _is_ cukup layak
untuk menetapkan port layanan unik ke setiap anggota shard dan data proxy untuk masing-masing
pod instance - bahkan untuk pekerjaan yang sangat besar. (Saran ini mengasumsikan
proxy masih merupakan arah yang ingin kita tuju dengan k8s - saya belum mengikuti
dengan diskusi terbaru di sekitar area ini)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

Sedikit twist pada ide ThingPool + Patch @thockin:

Template: daftar sumber daya + parameter dan substitusi. Lihat https://github.com/openshift/origin/blob/master/pkg/template/api/types.go untuk inspirasi. Ref #503, #1743, #4210, #6487.

Kolam Template. Pada dasarnya ThingPool. Menghasilkan contoh Template yang diindeks secara padat sesuai permintaan, bukan berdasarkan jumlah replika.

Untuk kesenangan/konsistensi: v2 ReplicationController dapat mereplikasi Template arbitrer, bukan hanya pod. ref #170 (semacam). Mungkin tidak diperlukan jika semua alokasi didorong oleh replikasi pod.

Alternatif utama adalah sesuatu yang lebih spesifik untuk domain, berfokus pada nama host dan kumpulan PVC, tetapi kumpulan terpisah untuk masing-masing tidak akan berfungsi. Satu kumpulan harus dapat mengalokasikan tupel nama host dan (berpotensi banyak) PVC. Salah satu keuntungan dari TemplatePool adalah bahwa seseorang dapat menggunakannya untuk mengalokasikan satu layanan (mungkin eksternal) per replika, mengotomatiskan solusi Zookeeper saat ini. Tidak tahu apakah mungkin ada sumber daya lain yang ingin direplikasi secara serupa 1-ke-1 dengan pod, tetapi mengingat tingkat pertumbuhan API kami, saya yakin tidak akan ada.

@smarterclayton FYI ketika Anda membalas melalui email dengan komentar sebaris, tanggapan Anda tidak dapat dibaca, baik di gmail maupun di github. Di gmail, tidak ada jeda baris dan di github tidak ada awalan kutipan, jadi respons Anda sulit untuk dipisahkan dari teks yang dikutip.

Ya, ada yang salah dengan gmail + github + iPhone.

Pada Kamis, 20 Agustus 2015 pukul 14:24, Brian Grant [email protected]
menulis:

@smarterclayton https://github.com/smarterclayton FYI ketika Anda membalas
melalui email dengan komentar sebaris, tanggapan Anda tidak dapat dibaca, baik di
gmail dan di github. Di gmail, tidak ada jeda baris dan di github ada
tidak ada awalan yang mengutip, jadi tanggapan Anda sulit untuk diejek selain dari
teks yang dikutip.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Insinyur Utama, OpenShift

Kami mengobrol singkat hari ini, beberapa sorotan:

Berbicara tentang tiga kelas aplikasi:

• Aplikasi yang merupakan aplikasi web tanpa kewarganegaraan (hanya berfungsi dengan RC)
• Aplikasi skala raksasa yang menggunakan master eksternal dan memiliki koherensi yang ada
  protokol (Cassandra, Infiniband) untuk menangani konsensus
• Perangkat lunak stateful berkerumun kecil seperti Mongodb, rethinkdb, volt, dll,
  penjaga kebun binatang, riak, redis cluster, yang membutuhkan beberapa pola untuk bekerja dengan baik
  
  
  
  • Identitas unik (biasanya)
  
  
  • Volume persisten unik per instans yang digunakan kembali (biasanya)
  
  
  • Alamat IP atau nama DNS yang stabil (umumnya) - Nama DNS biasanya a
    
    berdiri untuk alamat IP yang stabil
  
  
  • Nama host yang stabil (jarang)
  
  

Hari ini, Anda dapat memecahkan identitas unik dan volume persisten dengan memiliki N
pengontrol replikasi, alamat IP stabil dengan layanan N. Kami ingin
untuk tidak memerlukan N RC dan layanan untuk beberapa kasus penggunaan tersebut.

Kami berbicara tentang saran Tim dan Brian, tanpa urutan tertentu:

• TemplatePool bermasalah karena replikator harus memiliki
  otoritas untuk membuat objek di seluruh cluster, dan harus tahu
  di mana setiap titik akhir api berada.
  
  
  
  • Anda dapat memiliki titik akhir template instantiate, tetapi masih perlu
    
    menyelesaikan masalah pendelegasian wewenang (dengan akun layanan?)
  
  
  • Menemukan objek dan membatasi izin adalah hal jangka panjang
  
  
• "Identitas pod" alias bidang vuid yang kita bicarakan - argumen dibuat
  dan umumnya setuju bahwa itu tidak perlu unik secara global, hanya
  unik di dalam domain yang diharapkan Pod untuk menggunakannya.
  
  
  
  • Pemberi indeks hipotetis (jarang atau padat) dapat menetapkan nilai itu
    
    pasca pembuatan, dan kubelet dapat menunggu untuk memulai pod sampai mereka memiliki
    
    identitas (mungkin perlu menunjukkan bahwa mereka sedang menunggu)
  
  
  • Indeks padat umumnya berguna untuk hal-hal sederhana, tetapi karena ini
    
    adalah pembuatan pos dan dipisahkan dari kubelet yang bisa Anda miliki berbeda
    
    jenis algoritma penugasan (numerik padat, cincin hash konsisten,
    
    acak, dll)
  
  
• Pembuatan template sederhana pada pod sepertinya merupakan tempat yang baik untuk memulai, tetapi kita perlu
  untuk membuatnya konsisten dengan rantai alat kami yang ada dengan cara yang tidak
  benar-benar merusaknya
  
  
  
  • Gunakan bidang identitas untuk membuat templat bidang lain
  
  
• Tambahkan bidang nama host pada spesifikasi pod yang dapat diatur sendiri oleh pengguna dan
  parameterisasi dengan identitas
• Izinkan layanan tanpa kepala untuk menanggapi kueri dns untuk titik akhir oleh
  identitas (suruh pengontrol titik akhir mewujudkan identitas dari sebuah pod
  ke titik akhir) yang menjamin stabilitas
• Entah bagaimana memungkinkan klaim volume persisten untuk diparameterisasi, atau diubah menjadi
  menggambar dari kolam (atau minta pengontrol kolam memastikan ada satu volume per
  identitas, atau minta pengontrol identitas mengambil dari kumpulan), perlu dipikirkan
• Butuh alat yang memudahkan untuk mengubah lingkungan / api ke bawah menjadi
  file konfigurasi (ortogonal, tetapi seharusnya lebih mudah)
• Masih ada kekhawatiran tentang polanya

Pada Kam, 20 Agustus 2015 jam 15:34, Clayton Coleman [email protected]
menulis:

Ya, ada yang salah dengan gmail + github + iPhone.

Pada Kamis, 20 Agustus 2015 pukul 14:24, Brian Grant [email protected]
menulis:

@smarterclayton https://github.com/smarterclayton FYI ketika Anda membalas
melalui email dengan komentar sebaris, tanggapan Anda tidak dapat dibaca, baik di
gmail dan di github. Di gmail, tidak ada jeda baris dan di github ada
tidak ada awalan yang mengutip, jadi tanggapan Anda sulit untuk diejek selain dari
teks yang dikutip.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Insinyur Utama, OpenShift

Clayton Coleman | Insinyur Utama, OpenShift

Satu masalah lagi: sertifikat TLS untuk anggota layanan nominal

Sertifikat TLS untuk layanan secara umum juga akan menjadi hal yang baik (ditandatangani
oleh cluster CA secara otomatis berdasarkan permintaan).

Pada Thu, 20 Agustus 2015 di 17:19, Brian Hibah [email protected] menulis:

Satu masalah lagi: sertifikat TLS untuk anggota layanan nominal

—
Balas email ini secara langsung atau lihat di GitHub.

Clayton Coleman | Insinyur Utama, OpenShift

Ya: #11725

Ulang:

• Tambahkan bidang nama host pada spesifikasi pod yang dapat diatur sendiri oleh pengguna dan
  parameterisasi dengan identitas
• Izinkan layanan tanpa kepala untuk menanggapi kueri dns untuk titik akhir oleh
  identitas (suruh pengontrol titik akhir mewujudkan identitas dari sebuah pod
  ke titik akhir) yang menjamin stabilitas

Saya percaya bahwa kami sepakat bahwa dns harus didukung menggunakan nama host yang ditetapkan pada spesifikasi pod (yang mungkin diparameterisasi oleh identitas mereka setelah kami menambahkan fungsionalitas itu), sehingga nama host yang dilihat oleh wadah akan dapat dipecahkan oleh wadah lain.

Untuk menyetel subdomain, kita harus memberi tahu pod layanan apa yang menargetkannya, secara eksplisit atau implisit. Kerugian dari eksplisit adalah membutuhkan lebih banyak lem konfigurasi / templating. Kerugian dari implisit adalah bahwa itu akan rentan terhadap tantangan yang kita miliki dengan kopling longgar dalam sistem: ras dan inkonsistensi urutan penciptaan, kesulitan penegakan 1-ke-1, dll. Saya condong ke arah eksplisit. Kami hanya harus bekerja untuk meningkatkan pelingkupan referensi silang.

Sesuatu seperti:

Hostname string
Subdomain string

di atas HostNetwork di PodSpec.

Kami hanya akan mengirimkan DNS berbasis Hostname jika Subdomain cocok dengan itu untuk layanan dengan jenis yang tepat. Kami juga bisa menghaluskan keduanya menjadi satu bidang.

Saya pikir kita harus menggunakan kembali masalah #4825 untuk itu dan meminta seseorang untuk mengerjakannya. Ini jauh lebih konkret dan lebih sedikit pekerjaan daripada yang lain.

Entah bagaimana memungkinkan klaim volume persisten untuk diparameterisasi, atau diubah menjadi
menggambar dari kolam (atau minta pengontrol kolam memastikan ada satu volume per
identitas, atau minta pengontrol identitas mengambil dari kumpulan), perlu dipikirkan

Dua hal tentang klaim yang menurut saya dapat membantu di sini:

1. Ubah pengikatan dari 1:1 menjadi 1:N
   
   
   
   1. pvc.Spec.VolumeName ke pvc.Spec.VolumeNames[] sebagai referensi pengikatan
   
   
2. pvc.Spec.Singelton boolean yang menunjukkan jika suatu klaim harus diikat tepat satu kali untuk dibagikan atau mengizinkan klaim untuk diikat berkali-kali.

RC dapat mengikat volume baru sesuai kebutuhan. Saya akan mencari cara untuk menangani ini di binder.

Masih penting untuk mencocokkan volume yang benar dengan pod yang tepat.

Anda harus memiliki peta identitas untuk nama volume.

Pada Jumat, 21 Agustus 2015 jam 15:17, Mark Turansky [email protected]
menulis:

Entah bagaimana memungkinkan klaim volume persisten untuk diparameterisasi, atau diubah menjadi
menggambar dari kolam (atau minta pengontrol kolam memastikan ada satu volume per
identitas, atau minta pengontrol identitas mengambil dari kumpulan), perlu dipikirkan

Dua hal tentang klaim yang menurut saya dapat membantu di sini:

1. Ubah pengikatan dari 1:1 menjadi 1:N
   
   
   
   1. pvc.Spec.VolumeName ke pvc.Spec.VolumeNames[] sebagai pengikat
      
      referensi
   
   
2. pvc.Spec.Singelton boolean yang menunjukkan jika suatu klaim harus diikat
   tepat sekali untuk dibagikan atau mengizinkan klaim untuk diikat berkali-kali.

RC dapat mengikat volume baru sesuai kebutuhan. Saya akan mencari cara untuk menangani ini
dalam pengikat.

Masih penting untuk mencocokkan volume yang benar dengan pod yang tepat.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Clayton Coleman | Insinyur Utama, OpenShift

Pada Jumat, 21 Agustus 2015 pukul 12:56, Brian Grant [email protected] menulis:

Untuk menyetel subdomain, kita harus memberi tahu pod layanan apa yang menargetkannya,
eksplisit atau implisit. Kerugian dari eksplisit adalah membutuhkan lebih banyak
lem konfigurasi / templating. Kerugian dari implisit adalah bahwa itu akan menjadi
rentan terhadap tantangan yang kita miliki dengan kopling longgar dalam sistem: penciptaan-
urutan balapan dan inkonsistensi, kesulitan penegakan 1-1, dll. Saya bersandar
menuju eksplisit. Kami hanya harus bekerja untuk meningkatkan pelingkupan referensi silang.

Mari kita perjelas - jika kami TIDAK menyetel subdomain, kami tidak dapat membiarkan pengguna menyediakan
nama host mereka sendiri. Jika kita DO mengatur subdomain, kita harus melakukannya di a
cara yang cukup unik (dalam ruang DNS, yang saat ini berarti seberang
ruang nama). Menjadikan subdomain menjadi nama Layanan adalah
cukup unik.

Mengingat beberapa keterbatasan DNS kami (satu TLD), ini
secara realistis berarti kami memberi pengguna dua bidang DNS_LABEL - nama host
dan nominal-set. Untuk contoh konkrit:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

Ini akan mengakibatkan pod melihat:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

dan DNS yang melayani catatan A dan PTR untuk foo.bar.my-app.nom.cluster.local

Ini satu tingkat lebih dalam dari struktur DNS kami saat ini, tapi saya pikir
ndots=5 kami saat ini mencakup ini. Sebagai alternatif, kita dapat mengatakan bahwa a
namespace IS nama keluarga, dan meletakkannya kembali pada pengguna untuk menetapkan unik
nama host di namespace. Hasil DNSnya adalah
foo.my-app.pod.cluster.local yang mencerminkan Layanan. Kita bahkan bisa
buat mereka lebih mirip dengan menambahkan bidang nama host opsional ke Layanan.

Kami hanya akan mengirimkan DNS berbasis Hostname jika Subdomain cocok dengan itu untuk
layanan dari jenis yang tepat. Kami juga bisa menghaluskan keduanya menjadi satu bidang.

Bagian yang paling tidak saya sukai dari ini adalah Pod menyatakan "Saya adalah bagian
Layanan 'bar'" (dalam contoh di atas). Di depan. Apriori.

Lereng yang licin mengapa tidak memungkinkan secara umum? Itu akan
menyederhanakan banyak hal yang tidak dapat membuat asumsi hari ini (karena
kopling longgar) meskipun dalam praktiknya kita jarang melihat satu Pod
di belakang lebih dari satu Layanan. Jika setiap Pod berada di bawah nol-atau-satu
Layanan, apakah sistem menjadi lebih sederhana?

Saya pikir kita harus menggunakan kembali masalah #4825 untuk itu dan meminta seseorang untuk mengerjakannya. Ini jauh lebih konkret dan lebih sedikit pekerjaan daripada yang lain.

Itu pasti sesuatu yang bisa segera dimulai, tapi (untuk mereka
mengikuti di rumah) itu hanya mekanisme untuk mengimplementasikan pod
identitas, bukan kebijakan mengelola set identitas.

Pada Jumat, 21 Agustus 2015 pukul 15.17, Mark Turansky [email protected] menulis:

Dua hal tentang klaim yang menurut saya dapat membantu di sini:

1. Ubah pengikatan dari 1:1 menjadi 1:N

Di sinilah saya mulai, tapi ...

Pada Jum, 21 Agustus 2015 jam 12:38, Clayton Coleman
[email protected] menulis:

Anda harus memiliki peta identitas untuk nama volume.

Ya. Ini benar-benar hanya berubah menjadi masalah templating.
Apakah Anda menganggap masalahnya sebagai "templat pod" di mana beberapa
bidang memiliki tempat penampung yang diisi oleh "tupel pengganti"
diambil dari kumpulan saat runtime atau Anda menganggapnya sebagai pod yang sepenuhnya direifikasi
spec yang "ditambal" dengan "tupel pengganti" yang diambil dari kumpulan
saat runtime - mereka isomorfik dan sama-sama tidak menyenangkan.

Namun, saya pikir ini adalah salah satu masalah besar yang perlu kita pecahkan.
Haruskah kita mulai membuat proposal manusia jerami untuk ini?

Kami memiliki beberapa contoh pod yang berada di bawah dua atau tiga layanan, satu untuk
menyebar, satu untuk eksposur, dan satu untuk pengujian eksposur.

Mengenai identitas, setiap pod yang dibuat oleh pengontrol daemon harus memiliki identitas yang ditetapkan yang berasal dari identitas node dan identitas pengontrol. Ini mungkin kasus di mana identitas jelas (pod x pada host y memiliki identitas f(y)) dan bagian dari tanggung jawab daemon.

@smarterclayton jadi kebutuhan umum (tetapi tidak universal) di sini adalah mempertahankan daftar anggota grup yang stabil dan teratur. Bagaimana itu bisa bekerja ketika identitas diikat ke simpul tempat pod dijadwalkan?

Pengendali daemon _only_ memiliki identitas dalam konteks simpul tempat pod itu
berjalan terus. Pengontrol dan layanan replikasi berbeda. daemon
controller mengatakan "harus ada salah satu dari ini yang berjalan di setiap node". Di sana
tidak ada identitas lain yang dapat dimiliki pod kecuali node-nya.

Pada Jum, 11 Sep 2015 jam 01:13, Angus Lees [email protected]
menulis:

@smarterclayton https://github.com/smarterclayton jadi umum (tapi tidak
universal) yang dibutuhkan di sini adalah untuk mempertahankan daftar grup yang stabil dan teratur
anggota. Saya pikir itu menyiratkan identitas harus _tidak_ dikaitkan dengan
node tempat pod tersebut dijadwalkan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Clayton Coleman | Insinyur Utama, OpenShift

@smarterclayton ah, masalah ini jelas telah berubah menjadi sesuatu yang lebih dari permintaan fitur asli - saya kehilangan apa yang mencoba untuk membangun di sini, jadi saya akan mundur daripada terus menambahkan kebisingan...

Maaf, tidak bermaksud menyiratkan bahwa poinnya tidak relevan. Tantangannya adalah kita perlu mendefinisikan set dan menyebarkannya ke dalam pod. Kami membutuhkan pod untuk reaktif terhadap keanggotaan di set (mount volume X yang cocok dengan identitas pod di set). Ada pertanyaan terbuka - dapatkah sebuah pod menjadi anggota dari dua set secara bersamaan dan memiliki identitas unik di keduanya?

Mungkin saja pod yang dijalankan oleh daemon controller memiliki identitas yang "jelas" (daemon controller beroperasi pada satu set node, RC beroperasi pada satu set pod).

Salah satu persyaratan identitas adalah bahwa identitas itu unik dalam himpunan. Bisakah kita memanfaatkan nama pod dan pembuatan nama pod untuk memastikan keunikan itu? Misalnya, RC menghasilkan nama acak. Bisakah RC menghasilkan nama untuk pod dengan cara deterministik berdasarkan kumpulan pod yang dipilihnya?

Pertimbangkan RC yang memilih pod dengan label a=b. Untuk menghitung pod berikutnya yang akan dibuat, ia harus mengambil pod dan menguranginya menjadi hitungan. Bagaimana jika kita mereduksinya menjadi kumpulan nama yang unik, dan kemudian RC mencoba mengikuti pola pembuatan nama di dalam kumpulan itu? Dua RC yang tidak tumpang tindih, tetapi membuat pod ke dalam label layanan, tidak akan dapat menghasilkan nama unik (mereka mungkin memperebutkan nama, tetapi itu tersirat). Nama dapat digunakan kembali setelah dihapus

Kemudian volume persisten dalam pod dapat menggunakan PVC berdasarkan nama pod. Pengumpul pvc dapat memastikan ada cukup klaim untuk kumpulan RC yang diamati. Pengontrol daemon dapat memilih nama yang deterministik untuk nama node. Kami juga dapat mentransfer nama DNS ke nama pod dalam layanan berdasarkan beberapa pola.

Ini terasa lebih hemat daripada menambahkan bidang identitas yang berbeda pada pod. Ini berarti bahwa pod masih bukan hewan peliharaan, tetapi namanya bisa (yang bukan merupakan pernyataan yang tidak masuk akal). Kami tidak dapat mencegah dua instance dari proses pod yang sama berjalan di cluster pada saat yang sama, tetapi kami dapat membuat jaminan keras (dan memang) bahwa nama tersebut hanya digunakan di satu tempat hari ini.

Dimaksudkan "kumpulan nama yang diamati" di atas. DNS titik akhir akan menjadi hashpodname.ept.service.namespace.svc.cluster.local. Kami sudah memiliki nama pod di titik akhir, jadi kami bahkan tidak perlu menambahkan apa pun.

terkait dengan https://github.com/kubernetes/contrib/tree/master/service-loadbalancer yang mengusulkan penyelesaian masalah ini sebagai kemungkinan iterasi berikutnya

Mengapa kita membahas DaemonSet di sini? Itu diselesaikan oleh #12893, IMO.

@smarterclayton Mari kita tidak meninjau kembali mendapatkan identitas dari nama pod, atau menggunakan RC untuk menetapkan identitas. Masalah dengan pendekatan tersebut dibahas di sini: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Salah satu kemungkinannya adalah memiliki opsi RC yang memungkinkan Anda membuat nama seperti yang dijelaskan @smarterclayton jika Anda mau, dan serangkaian fitur berbeda yang tersedia untuk Anda bergantung pada cara Anda menyetel opsi. Jadi hal-hal yang sulit diterapkan dengan pendekatan "indeks tugas" tidak akan tersedia jika Anda mengaktifkan opsi tersebut, tetapi fitur yang dijelaskan di sini akan tersedia. Dan sebaliknya, perilaku default (opsi dinonaktifkan) akan memberi Anda fitur-fitur lain itu tetapi bukan yang dijelaskan di sini.

Tampaknya utilitas sesuatu seperti abstraksi indeks tugas Borg terus muncul _untuk kasus penggunaan tertentu_ dan tidak jelas bagi saya mengapa kami tidak dapat menawarkannya sebagai opsi.

DaemonSet Saya tidak berpikir memecahkan kasus penyimpanan sistem file terdistribusi
(Gluster) di mana setiap host harus memiliki identitas yang konsisten untuk bergabung kembali
cluster. Saya akan menggali lebih banyak tetapi saya pikir itu mungkin masih membutuhkan sesuatu
kebutuhan #260 - Saya tidak tahu apakah nama host cukup jika Anda memasang kembali
disk host pada instance baru. Mungkin saya tidak mengerti apa itu DaemonSet
disediakan dan #12893 terkirim, tapi saya rasa itu bukan masalah untuk a
host sistem yang ingin menggunakan kembali disk.

Pada hari Rabu, 16 Sep 2015 jam 12:22, Brian Grant [email protected]
menulis:

@smarterclayton https://github.com/smarterclayton Jangan berkunjung lagi
mendapatkan identitas dari nama pod, atau menggunakan RC untuk menetapkan identitas.
Masalah dengan pendekatan tersebut dibahas di sini: #260 (komentar)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Insinyur Utama, OpenShift

Sebagai contoh nyata, bayangkan sebuah cluster etcd. Ini memiliki 7 contoh, dan 7
volume. Saya ingin (demi argumen), nama dan volume dlld-1
melalui etcd-7 dan etcd-pvc-1 melalui etc-pvc-7.

Penerapan bergulir memiliki MaxUnavailable 90% (atau setara), MaxSurge 0%. Dia
menurunkan RC lama, dan meningkatkan RC baru. RC lama dengan anggun
menghapus etcd-5. Itu langsung keluar dari set RC yang efektif. Yang baru
RC mencoba membuat etcd-5 (dengan mengamati celah yang ditetapkan). Ia menerima
"Sudah Ada Pengecualian". Ini memperlakukan itu sebagai backoff dan requeues. Sekali
etcd-5 benar-benar hilang, ia dapat melanjutkan. Setelah etcd-5 siap, DC
bergerak ke langkah berikutnya.

Untuk alternatif - set identitas pada pod - RC lama diperkecil. SEBUAH
pod baru dibuat secara instan dengan nama baru. Pod baru tidak dapat diluncurkan
karena memerlukan identitas yang ditetapkan untuk mengetahui PVC mana yang akan dipasang untuknya
volume. Itu masuk ke loop tunggu di Kubelet. Pengendali identitas
menonton beberapa set pemilih label dan mengamati identitas dlld-5 tidak
dialokasikan. Ini menetapkan identitas etcd-5 ke pod baru. kubelet mengamati
perubahan itu dan kemudian dapat mengetahui PVC mana yang akan dipasang, memulai pod
(dengan asumsi volume telah terlepas dari node lain).

Secara struktural, ini sangat mirip. Yang terakhir memungkinkan mulai tumpang tindih.
Keduanya membutuhkan pemetaan PVC.

Pada Rabu, 16 Sep 2015 pukul 12:39, Clayton Coleman [email protected]
menulis:

DaemonSet Saya tidak berpikir memecahkan kasus penyimpanan sistem file terdistribusi
(Gluster) di mana setiap host harus memiliki identitas yang konsisten untuk bergabung kembali
cluster. Saya akan menggali lebih banyak tetapi saya pikir itu mungkin masih membutuhkan sesuatu
kebutuhan #260 - Saya tidak tahu apakah nama host cukup jika Anda memasang kembali
disk host pada instance baru. Mungkin saya tidak mengerti apa itu DaemonSet
disediakan dan #12893 terkirim, tapi saya rasa itu bukan masalah untuk a
host sistem yang ingin menggunakan kembali disk.

Pada hari Rabu, 16 Sep 2015 jam 12:22, Brian Grant [email protected]
menulis:

@smarterclayton https://github.com/smarterclayton Jangan berkunjung lagi
mendapatkan identitas dari nama pod, atau menggunakan RC untuk menetapkan identitas.
Masalah dengan pendekatan tersebut dibahas di sini: #260 (komentar)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Insinyur Utama, OpenShift

Clayton Coleman | Insinyur Utama, OpenShift

Hal yang membuat masalah ini sulit, bagi saya, bukanlah menghasilkan kumpulan nama unik yang stabil atau menggunakan kumpulan PD. Masalahnya adalah melakukan KEDUA pada waktu yang sama. Dan jika Anda memperluasnya, mengapa hampir semua pengenal dalam spesifikasi tidak dapat digabungkan seperti ini?

Sejauh yang saya tahu (kebanyakan bekas) masalah dengan indeks yang dikemas, saya pikir mereka mungkin layak huni (terutama jika kita melakukan seperti yang disarankan David dan membuatnya saling eksklusif dengan fitur lain). Tapi juga, semakin aku memikirkannya, semakin aku membenci ide Patch yang diposting oleh beberapa orang bodoh.

Masalah ini telah berlama-lama dan berlama-lama dan saya khawatir kita punya kelumpuhan analisis.

Saya berharap kami memiliki lebih banyak contoh kasus penggunaan penyatuan lainnya. Saya pikir Gluster
akan berbeda tapi itu hanya varian lain di
cassandra/etcd/mongo/zookeeper "Saya ingin menggunakan kembali volume dan saya perlu
ingat siapa yang saya katakan sebelumnya". Kami belum benar-benar memiliki peran berbasis (saya
ingin membuat koordinator N pod pertama dan pekerja M berikutnya) contoh
untuk memanfaatkan.

Pada hari Rabu, 16 Sep 2015 jam 12:46, Tim Hockin [email protected]
menulis:

Hal yang membuat masalah ini sulit, bagi saya, adalah tidak menghasilkan kandang
kumpulan nama yang unik atau menggunakan kumpulan PD. Masalahnya adalah melakukan KEDUA di
waktu yang sama. Dan jika Anda memperpanjangnya, mengapa tidak bisa apa saja
pengenal dalam spesifikasi dikumpulkan seperti ini?

Sejauh yang saya tahu (kebanyakan bekas) masalah dengan indeks yang dikemas, saya
pikir mereka mungkin layak huni (terutama jika kita melakukan seperti yang disarankan dan dibuat David)
mereka saling eksklusif dengan fitur lainnya). Tapi juga, semakin aku direbus
itu, semakin aku membenci ide Patch yang diposting oleh orang bodoh.

Masalah ini telah berlama-lama dan berlama-lama dan saya khawatir kita punya analisis
kelumpuhan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Clayton Coleman | Insinyur Utama, OpenShift

Set Daemon:

12893 atur nama host pod ke nama host node saat menggunakan jaringan host, yang benar-benar masuk akal untuk digunakan untuk DaemonSet, karena ini juga akan menggunakan hostPort.

Selain itu, tujuannya adalah untuk mengintegrasikan DaemonSet dengan pengontrol node untuk memberikan pengampunan tak terbatas implisit #1574, dan untuk mengaktifkan "penjadwalan" sebelum penjadwalan diaktifkan untuk node secara umum. Prioritas implisit mungkin juga masuk akal.

Untuk sistem penyimpanan cluster, saya dapat membayangkan menyediakan disk tambahan pada setiap host yang diakses melalui hostPath hanya oleh sistem penyimpanan -- disk tersebut tidak akan digunakan oleh Docker atau pun emptyDir.

Sehubungan dengan identitas, saya tidak melihat masalah dengan proposal di sini: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Masalah ini tetap ada terutama karena kurangnya prioritas yang memadai, IMO.

Untuk mengoceh tentang Clayton (atau mungkin hanya untuk mengatakan hal yang sama tetapi lebih bodoh):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

Implikasinya adalah RC (atau sesuatu) menyadari bahwa ini adalah kumpulan identitas, memberikan indeks dari identityPool, menetapkan identitas itu ke nama pod, dan kemudian mengintip ke dalam untuk melihat apakah ada field identitas-sentris lain yang ditetapkan - identitas volume dalam hal ini.

Ini tidak sepenuhnya umum (Anda tidak dapat menggabungkan bidang acak apa pun) tetapi kami dapat menambahkan lebih banyak opsi pengenal sesuai kebutuhan

Saya merasa bahwa jika kami menetapkan spesifikasi yang kami sukai untuk ini, itu mungkin akan selesai lebih cepat daripada nanti.

Bahkan menulis spesifikasi membutuhkan waktu.

Sehubungan dengan IdentityPool/VolumePool, kami telah lama memutuskan bahwa beberapa kumpulan tidak akan berfungsi.

Batas waktu penyelesaian kode 1.1 adalah hari Jumat. Bisakah kita tidak melakukan ini sekarang?

Juga terkait: #170. Itu mengusulkan untuk hanya membagi templat pod, tetapi jika kita menggunakan skema templating (yang sangat saya sukai daripada tambalan), maka kita harus mempertimbangkannya bersama.

Saya menempatkan setidaknya desain pada v1.2-candidate.

Maaf saya tidak jelas dalam sketsa saya - RC (atau IC?) Memiliki konsep
kolam utama atau indeks. Setelah pod diberi indeks di IC, itu
index digunakan untuk mengindeks ke semua bidang pool-centric.

Jika kita membagi template, saya berasumsi bahwa RC tidak bisa
mengubah template. Itu sedikit lebih rumit.

Saya baik-baik saja untuk berhenti berbicara tentang ini minggu ini. Itu baru saja muncul di my
kotak masuk dan saya telah mengunyah ide ini ...

Pada hari Selasa, 15 Sep 2015 jam 22:09, Brian Grant [email protected]
menulis:

Bahkan menulis spesifikasi membutuhkan waktu.

Sehubungan dengan IdentityPool/VolumePool, kami sudah memutuskan sejak lama
lalu bahwa beberapa kumpulan tidak akan berfungsi.

Batas waktu penyelesaian kode 1.1 adalah hari Jumat. Bisakah kita tidak melakukan ini sekarang?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Ya, hanya ada hal-hal yang memicu diskusi di pihak kami.
Masalah pelanggan menunggu tanpa proses rilis.

Pada Rabu, 16 Sep 2015 jam 1:14, Tim Hockin [email protected]
menulis:

Maaf saya tidak jelas dalam sketsa saya - RC (atau IC?) Memiliki konsep
kolam utama atau indeks. Setelah pod diberi indeks di IC, itu
index digunakan untuk mengindeks ke semua bidang pool-centric.

Jika kita membagi template, saya berasumsi bahwa RC tidak bisa
mengubah template. Itu sedikit lebih rumit.

Saya baik-baik saja untuk berhenti berbicara tentang ini minggu ini. Itu baru saja muncul di my
kotak masuk dan saya telah mengunyah ide ini ...

Pada hari Selasa, 15 Sep 2015 jam 22:09, Brian Grant [email protected]
menulis:

Bahkan menulis spesifikasi membutuhkan waktu.

Sehubungan dengan IdentityPool/VolumePool, kami sudah memutuskan sejak lama
lalu bahwa beberapa kumpulan tidak akan berfungsi.

Batas waktu penyelesaian kode 1.1 adalah hari Jumat. Bisakah kita tidak melakukan ini?
sekarang?

—
Balas email ini secara langsung atau lihat di GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Clayton Coleman | Insinyur Utama, OpenShift

Diskusi adalah semua tentang nomor IP dan Pod tetapi dalam pengalaman saya dengan Mongo & Zookeeper IP Pod harus tetap tidak relevan (tidak menjadi hewan peliharaan). _volume_ persisten membutuhkan nomor nominal karena volume ini mencatat nomor IP dari 'volume' lainnya. Pod apa pun yang memasang volume itu harus dapat menggunakan nomor IP yang direkam itu. Volume adalah hewan peliharaan ...

Sebuah nama DNS yang konstan dalam waktu untuk sebuah volume dan ditugaskan ke sebuah Pod yang memasang volume akan datang jauh, saya pikir.

Mengubah keanggotaan ansambel di Mongo & ZK akan selalu membutuhkan kode khusus untuk dijalankan dan saya berharap itu sama untuk sebagian besar ansambel lainnya. Jadi Pengontrol Replikasi adalah nama yang salah, hewan peliharaan ini membutuhkan lebih banyak pengontrol Kapal Anggota. Pengontrol Kapal Anggota harus dapat menangani pengaturan awal dan kemudian perubahan tambahan pada ansambel, dan akhirnya mematikannya.

Diberikan nama DNS konstan berdasarkan volume yang dipasang & kemungkinan untuk menangani keanggotaan ansambel dengan kode khusus seharusnya memungkinkan untuk menangani jenis sistem ini, saya pikir.

Ya, IP pod lebih merupakan peretasan jangka pendek.

Ke mana arah proposal ini adalah sesuatu di atas DNS dan volume yang keduanya
dapat memanfaatkan untuk tetap berpasangan. Kekhawatirannya adalah volume yang mendefinisikan nama DNS
adalah kebalikan dari kopling yang telah kami buat, dan kami juga
ingin membiarkan bagian lain dari spesifikasi pod memanfaatkan konsep yang lebih tinggi itu
(identitas) seperti API ke bawah pada lingkungan. Itu membuat beradaptasi
identitas ke perangkat lunak ensemble yang berbeda lebih mudah (mengurangi kode kustom per
Tipe).

Kami masih perlu memastikan tidak ada kasus penggunaan di luar ansambel yang
tumpang tindih di sini (belum pernah mendengar yang disarankan) dan kemudian mencoba untuk mendapatkan a
proposal konkrit yang dirasa minim dan tepat. Tim saya pikir memiliki
diringkas yang paling baru di sini.

Pada 23 September 2015, pukul 11:33, Peter Kriens [email protected] menulis:

Diskusinya adalah tentang nomor IP dan Pod tetapi menurut pengalaman saya dengan
Mongo & Zookeeper IP Pod harus tetap tidak relevan (tidak menjadi hewan peliharaan).
_volume_ persisten membutuhkan nomor nominal karena volume ini merekam
nomor IP dari 'volume' lainnya. Pod apa pun yang memasang volume itu
harus dapat menggunakan nomor IP yang direkam itu. volumenya adalah
Peliharaan ...

Nama DNS yang konstan dalam waktu untuk suatu volume dan ditetapkan ke Pod yang
gunung volume akan datang jauh saya pikir.

Mengubah keanggotaan ensemble di Mongo & ZK akan selalu membutuhkan kustom
kode untuk dijalankan dan saya berharap itu sama untuk sebagian besar ansambel lainnya. Jadi
Pengontrol Replikasi adalah nama yang salah, hewan peliharaan ini membutuhkan lebih banyak Anggota
Pengontrol kapal. Pengendali Kapal Anggota harus mampu menangani
pengaturan awal dan kemudian perubahan tambahan pada ansambel, dan akhirnya
membunuhnya.

Diberi nama DNS konstan berdasarkan volume terpasang & kemungkinan untuk
menangani keanggotaan ensemble dengan kode khusus harus memungkinkan untuk
menangani jenis sistem yang saya pikir.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/ping

Anda dapat menemukan contoh pengaturan klaster ZK di bawah Kubernetes menggunakan kemampuan yang ada di https://hub.docker.com/r/elevy/zookeeper/. Persyaratan utama adalah alamat IP yang stabil dan nama host untuk anggota ensemble. Hal ini dicapai dengan menggunakan Layanan individu untuk setiap anggota cluster. Satu-satunya masalah adalah bahwa secara default ZK akan mencoba untuk mengikat ke IP yang ditentukan oleh nama hostnya, tetapi ini dapat dihindari melalui parameter konfigurasi.

@smarterclayton @thockin

Pikiran saat bersepeda ke kantor beberapa hari yang lalu:

Saat ini saya sedang memikirkan ini sebagai pengontrol PetSet, atau mungkin pengontrol ShardSet, jika orang ingin memikirkannya seperti itu, seperti yang dibahas kembali di awal: https://github.com/kubernetes/kubernetes/issues/260# komentar masalah -57671926.

Kasus yang kami coba atasi adalah di mana ada N hewan peliharaan yang serupa, tetapi mereka tetaplah hewan peliharaan -- mereka tidak sepadan.

Saya masih berpikir mengikat ini ke ReplicationController tidak dapat berfungsi, sebagian karena ReplicationController hanya memiliki satu templat. PetSet/ShardSet perlu abstraksi tingkat yang lebih tinggi, lebih seperti Deployment atau DaemonSet. PetSet berpotensi menghasilkan satu objek PodTemplate per instance.

Saya tidak berpikir kita bisa menggunakan kembali Deployment API. Antara lain, strategi peluncuran pembaruan bergulir sekarang di kubectl dan Deployment tidak akan berfungsi untuk kasus ini. Sebagian besar hewan peliharaan mungkin ingin membuat ulang pembaruan, dan semua yang menginginkan pembaruan bergulir tidak akan dapat menangani lonjakan apa pun di atas jumlah pecahan mereka dan akan khusus tentang urutan pembaruan.

Meskipun saya menyukai idenya, saya rasa alokasi identitas dari bawah ke atas tidak akan berhasil. Terlalu banyak kondisi balapan dengan mengembalikan identitas yang dialokasikan ke kumpulan vs. mengalokasikan yang baru. Sama seperti masalah yang dialami @erictune saat menjelajahi penggunaan RabbitMQ dengan Job.

Saya tidak ingin mewakili skala PetSet di lebih dari satu tempat, seperti di pengontrol dan di kumpulan identitas, atau di pengontrol dan di layanan, karena itu akan membuat penskalaan menjadi rumit/canggung.

Saya tidak berpikir kita membutuhkan template tujuan umum untuk kasus ini. Kami hanya perlu menghilangkan pod dengan penyimpanan terkait dan identitas jaringan yang dapat diprediksi dan tahan lama. Setara kasar sudah cukup di Borg. Oleh karena itu, saya sangat condong ke arah sesuatu di sepanjang garis #12450, tetapi di template pod daripada di pod itu sendiri. Mungkin sebuah array dari persistentVolumeClaimTemplates selain podTemplate. Saya tidak ingin menambahkan substitusi mewah untuk semua sumber volume khusus penyedia cloud, terutama karena kami tetap ingin menghentikannya. Menambahkan persyaratan tambahan dan/atau penyeleksi ke PVC harus cukup. Kami juga harus dapat menyediakan volume persisten entah bagaimana di beberapa titik.

Kami masih perlu melakukan sesuatu tentang penyimpanan lokal pada akhirnya, tetapi saya pikir itu dapat dipisahkan.

Dan kemudian nama host dan layanan tanpa kepala berubah yang disebutkan di atas, di sini:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Sedang mengerjakan proposal sekarang, akan segera ada draftnya.

Proposal sudah masuk https://github.com/kubernetes/kubernetes/pull/18016

... jadi di mana kita dengan PetSet?

Saya sedang membangun solusi database HA di atas Kubernetes. Beberapa, khususnya database master tunggal, memerlukan layanan dengan titik akhir yang memetakan ke pod tertentu berdasarkan peristiwa dari pod tersebut. Sebagai contoh:

1. service "postgres" memetakan round-robin ke semua pod di ReplicaSet, tetapi service "postgres-master" memetakan hanya ke satu pod.
2. pod master mati.
3. kegagalan terjadi. Sebagai bagian dari failover, master baru memperbarui Kube-master melalui API untuk "mengambil" layanan postgres-master.
4. Ketika melakukan ini, semua koneksi sebelumnya ke postgres-master dihentikan.

@jberkus kode alfa awal untuk mengaktifkan PetSets telah digabungkan atau sedang menunggu penggabungan. @ingvagabund dari tim saya akan mulai menyusun contoh yang menggunakan PetSet untuk melihat apa yang berfungsi dengan baik dan apa yang masih perlu ditingkatkan. Saya sarankan Anda menghubunginya jika Anda memiliki beberapa kasus penggunaan khusus yang ingin Anda kumpulkan dan uji.

@ncdc Apakah semuanya dilakukan untuk ini di v1.3? Tidak jelas karena proposalnya tidak digabungkan dan belum ada PR lain yang merujuk ini untuk sementara waktu.

@bprashanth ^

Kami sedang mendaratkan e2es dan terus mengerjakan contoh. Itu ada di alfa
sekarang, tetapi proposal akan mengambil putaran pertama dari umpan balik alfa
sebelum penggabungan.

Pada 19 Mei 2016, pukul 10:25, Brandon Philips [email protected]
menulis:

@ncdc https://github.com/ncdc Apakah semuanya dilakukan untuk ini di v1.3? Dia
tidak jelas karena proposal belum digabung dan belum ada PR lainnya
referensi ini untuk sementara waktu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

Di mana saya dapat menemukan dokumen untuk ini? Saya ingin mengujinya untuk kasus penggunaan database-failover.

Ah ha, hanya apa yang kita butuhkan ahli postgres :)

lihat https://github.com/kubernetes/contrib/pull/921 untuk contoh, saya dapat menjawab pertanyaan apa pun tentang membuat prototipe [db of choice] sebagai petset. Kami memiliki banyak sketsa di bawah "apps / stateful" label (misalnya: https://github.com/kubernetes/kubernetes/issues/23790, @philips contoh etcd akan menjadi besar). Saya belum menulis dokumen, akan melakukannya menjelang beberapa minggu terakhir 1.3 (masih 5 minggu untuk dirilis setelah kode selesai pada hari Jumat).

Saya kira Anda akan mencoba mengotomatiskan failover dengan postgres karena itu cukup umum. Saya akui bahwa saat ini masih tidak semudah yang saya inginkan, Anda mungkin membutuhkan pengawas. @jberkus Saya ingin mendengar umpan balik tentang pola apa yang membuatnya lebih mudah.

Untuk memberi Anda tinjauan singkat, petset hari ini memberi Anda identitas jaringan yang konsisten (DNS, nama host) yang cocok dengan volume yang dipasang di jaringan, dan jaminan pemesanan. Jadi jika Anda membuat petset dengan replicas: 3 , Anda akan mendapatkan:
layanan pemerintahan: *.galear.default.svc.cluster.local
mysql-0 - volume0
mysql-1 - volume1: tidak dimulai sampai 0 berjalan dan siap
mysql-2 - volume2: tidak mulai sampai 0, 1 sudah siap

Pod dapat menggunakan DNS untuk penemuan layanan dengan mencari catatan SRV yang disisipkan di bawah layanan yang mengatur. Itulah yang dilakukan pod sederhana ini: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. Jadi jika Anda menggunakan peer-finder melalui wadah init seperti pada contoh di atas, mysql-1 tidak akan mulai sampai wadah init melihat (mysql-1, mysql-0) di DNS, dan menulis konfigurasi yang sesuai.

Volume disediakan oleh penyedia dinamis (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), jadi jika Anda tidak memilikinya berjalan di cluster Anda tetapi hanya ingin membuat prototipe, Anda cukup menggunakan emptyDir. Kasing "data-gravitasi" (https://github.com/kubernetes/kubernetes/issues/7562) belum berfungsi, tetapi pada akhirnya akan berfungsi.

Saya akan menambahkan bahwa saat ini lebih mudah untuk mengirimkan pemberitahuan "saat mulai" dengan daftar rekan, melalui wadah init. Jelas bahwa kami juga memerlukan notifikasi "saat perubahan". Saat ini untuk melihat perubahan keanggotaan cluster, Anda perlu menggunakan pid1 khusus. Ruang nama pid bersama mungkin membuat ini lebih mudah, karena Anda kemudian dapat menggunakan sespan, ini juga sesuatu yang perlu berfungsi.

Saya memiliki pengawas, ini adalah kegagalan layanan yang lebih rumit daripada yang saya inginkan. Akan menguji, terima kasih!

Saya juga perlu mendukung etcd, jadi mungkin ada banyak pengujian di masa depan saya.

@ncdc Apa status kode alfa untuk ini? Saya ingin memulai pengujian/implementasi. Kita perlu segera menerapkan cluster cassandra di sini. Saya bisa melakukannya dengan basis kode yang ada tetapi akan menyenangkan untuk menguji hal-hal petset.

Anda bisa mendapatkannya jika Anda membangun dari HEAD

@bprashanth digabungkan ke dalam repo utama? Terima kasih banyak. akan melakukan.

https://github.com/kubernetes/contrib/tree/master/pets

menyematkan yaml dalam string anotasi? oof, aduh :(. terima kasih, akan menyelidiki pembuatan set cassandra.

itu json. Ini adalah fitur alfa yang ditambahkan ke objek GA (init container di pod).
@chrislovecnm sedang mengerjakan Cassandra, mungkin hanya ingin menunggunya.

@paralin inilah yang sedang saya kerjakan. Tidak ada waktu untuk mendokumentasikan dan memasukkannya ke dalam repo k8s sekarang, tetapi itu adalah rencana jangka panjang. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra Bekerja untuk saya secara lokal, di HEAD.

Gambar C* terbaru dalam demo berfungsi dengan baik.

Kami memiliki masalah terbuka untuk dokumentasi lebih lanjut. Kedip kedip, knudge @bprashanth

Contoh PetSets dengan cluster etcd [1].

[1] https://github.com/kubernetes/contrib/pull/1295

Pastikan untuk menangkap permintaan desain pada dokumen proposal setelah Anda selesai meninjau

Pada 30 Juni 2016, pukul 01.25, Jan Chaloupka [email protected] menulis:

Contoh PetSets dengan cluster etcd [1].

[1] kubernetes/contrib#1295
https://github.com/kubernetes/contrib/pull/1295

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
atau matikan utasnya
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

dokumen petset adalah https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md dan https://github.com/kubernetes/kubernetes.github. io/tree/release-1.3/docs/user-guide/petset/bootstrapping , saya berencana untuk menutup masalah ini dan membuka yang baru yang membahas pemindahan petset ke beta kecuali ada yang keberatan

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