Dingin! Saya pikir kita pasti harus menggabungkan ini. Pada catatan terpisah, saya melihat proxy memakan ~30% inti di bawah beban berat, saya harus percaya bahwa iptables akan memberi kita kinerja yang lebih baik dari itu.

Kita harus memprioritaskan ini - ini hampir merupakan penulisan ulang total kube-proxy dan
semua ujiannya. Ini juga memiliki masalah back-compat (tidak akan berfungsi)
kernel lama atau binari iptables lama).

Pada Senin, 26 Januari 2015 pukul 11:06, Brendan Burns [email protected]
menulis:

Dingin! Saya pikir kita harus menggabungkan ini. Pada catatan terpisah,
Saya melihat proxy memakan ~ 30% dari inti di bawah beban berat, saya harus
percaya bahwa iptables akan memberi kita kinerja yang lebih baik dari itu.

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

Mungkin menerapkannya sebagai opsi paralel dan bermigrasi perlahan masuk akal?

Pada Senin, 26 Januari 2015 pukul 12:01, Tim Hockin [email protected]
menulis:

Kita harus memprioritaskan ini - ini hampir merupakan penulisan ulang total kube-proxy dan
semua ujiannya. Ini juga memiliki masalah back-compat (tidak akan berfungsi)
kernel lama atau binari iptables lama).

Pada Senin, 26 Januari 2015 pukul 11:06, Brendan Burns [email protected]
menulis:

Dingin! Saya pikir kita pasti harus menggabungkan ini. Secara terpisah
catatan,
Saya melihat proxy memakan ~ 30% dari inti di bawah beban berat, saya harus
percaya bahwa iptables akan memberi kita kinerja yang lebih baik dari itu.

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

.

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

Saya mencoba membujuk orang lain yang tidak tahu kode ini dengan baik untuk mempelajarinya
dan mengambilnya. Saya sangat _ingin_ mengatasinya, tetapi akan lebih baik jika
orang lain mempelajari ruang ini (bukan Anda! :)

Yang mengatakan, Anda juga mengirim email (baik) tentang daftar P1 besar - dan saya
jangan berpikir ini ada di daftar itu.

Pada Senin, 26 Januari 2015 pukul 13:06, Brendan Burns [email protected]
menulis:

Mungkin mengimplementasikannya sebagai opsi paralel dan bermigrasi perlahan membuat
nalar?

Pada Senin, 26 Januari 2015 pukul 12:01, Tim Hockin [email protected]
menulis:

Kita harus memprioritaskan ini - ini hampir merupakan penulisan ulang total kube-proxy
dan
semua ujiannya. Ini juga memiliki masalah back-compat (tidak akan berfungsi
pada
kernel lama atau binari iptables lama).

Pada Sen, Jan 26, 2015 jam 11:06, Brendan Burns <
[email protected]>
menulis:

Dingin! Saya pikir kita pasti harus menggabungkan ini. Secara terpisah
catatan,
Saya melihat proxy memakan ~ 30% dari inti di bawah beban berat, saya harus
percaya bahwa iptables akan memberi kita kinerja yang lebih baik dari itu.

Balas email ini secara langsung atau lihat di GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

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

.

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

Apakah ini P2? Mungkinkah layak menjadikannya P3 untuk saat ini?

Saya berharap untuk membuatnya berfungsi, tetapi kami mungkin belum menurunkannya

Pada hari Rabu, 11 Februari 2015 jam 14:49, Satnam Singh [email protected]
menulis:

Apakah ini P2? Mungkinkah layak menjadikannya P3 untuk saat ini?

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

Bukankah "harapan" sama dengan P3 yang akan kita dapatkan jika kita bisa?

Dari diskusi dengan @thockin : Ini adalah persyaratan untuk mendukung rentang port layanan, yang tidak diperlukan untuk 1.0, tetapi pada akhirnya kami ingin mendukung.

@thockin "Ini memiliki kelemahan karena tidak kompatibel dengan iptables dan kernel yang lebih lama." Seberapa 'baru' kernel itu?

Tidak TERLALU baru, tetapi kami memiliki beberapa pengguna yang BENAR-BENAR menginginkan iptables dari 2012 hingga
kerja.

Pada Senin, 23 Februari 2015 pukul 14:44, Sidharta Seethana < [email protected]

menulis:

@thockin https://github.com/thockin "Ini memiliki kelemahan karena tidak
kompatibel dengan iptables dan kernel lama." Seberapa 'baru' kernel
harus?

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

@thockin terima kasih. Kami menggunakan/menguji dengan RHEL/CentOS 6, misalnya - jadi alangkah baiknya jika kami tidak memiliki ketergantungan keras pada kernel 3.x terbaru.

@pweil- kami mendiskusikan ini beberapa hari yang lalu
Pada Senin, 23 Februari 2015 pukul 23:40 Sidharta Seethana [email protected]
menulis:

@thockin https://github.com/thockin terima kasih. Kami menggunakan/menguji dengan
RHEL/CentOS 6, misalnya - jadi alangkah baiknya jika kita tidak kesulitan
ketergantungan pada kernel 3.x terbaru.

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

Nah, Anda memang membutuhkan Docker untuk dijalankan, dan pada titik tertentu kita harus menghentikannya.
Dukungan back-rev iptables tidak akan menghentikan saya dari (akhirnya) membuat
perubahan ini, dan itu akan menyengat bagi sebagian orang.

Pada Senin, 23 Februari 2015 pukul 20:40, Sidharta Seethana < [email protected]

menulis:

@thockin https://github.com/thockin terima kasih. Kami menggunakan/menguji dengan
RHEL/CentOS 6, misalnya - jadi alangkah baiknya jika kita tidak kesulitan
ketergantungan pada kernel 3.x terbaru.

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

Dengan bantuan @thockin , kami mencoba hal yang sama dengan udp.

Kami membuat cluster GCE Kubernetes dengan 3 pengontrol replikasi sky-dns.
Di kubernetes-master, kami mengatur yang berikut di iptables:
IP layanan dns adalah 10.0.0.10, dan titik akhir pod yang menjalankan dns adalah 10.244.0.5:53, 10.244.3.6:53, 10.244.0.6:53

iptables -t nat -N TESTSVC
iptables -t nat -F TESTSVC
iptables -t nat -N TESTSVC_A
iptables -t nat -F TESTSVC_A
iptables -t nat -N TESTSVC_B
iptables -t nat -F TESTSVC_B
iptables -t nat -N TESTSVC_C
iptables -t nat -F TESTSVC_C
iptables -t nat -N KUBE-PORTAL-HOST
iptables -t nat -F KUBE-PORTAL-HOST

iptables -t nat -A TESTSVC -m recent --name hostA --rcheck --seconds 1 --reap -j TETSVC_A
iptables -t nat -A TESTSVC -m baru-baru ini --nama hostB --rcheck --detik 1 --reap -j TESTSVC_B
iptables -t nat -A TESTSVC -m recent --name hostC --rcheck --seconds 1 --reap -j TETSVC_C

iptables -t nat -A TESTSVC -m statistik --mode acak --probabilitas 0,333 -j TESTSVC_A
iptables -t nat -A TESTSVC -m statistik --mode acak --probabilitas 0,5 -j TETSVC_B
iptables -t nat -A TESTSVC -m statistik --mode acak --probabilitas 1.000 -j TESTSVC_C

iptables -t nat -A TESTSVC_A -m recent --name hostA --set -j DNAT -p udp --to-destination 10.244.0.5:53
iptables -t nat -A TESTSVC_B -m recent --name hostB --set -j DNAT -p udp --to-destination 10.244.3.6:53
iptables -t nat -A TESTSVC_C -m recent --name hostC --set -j DNAT -p udp --to-destination 10.244.0.6:53
iptables -t nat -A KUBE-PORTAL-HOST -d 10.0.0.10/32 -p udp -m udp --dport 53 -j TESTSVC
iptables -t nat -A OUTPUT -j KUBE-PORTAL-HOST

kubernetes-master>nslookup kubernetes.default.kuberenetes.local 10.0.0.10

Kami mendapat tanggapan kembali!

Barang bagus! Sekedar informasi (mengkonfirmasi dari percakapan tatap muka kami), tidak aman untuk menjalankan beberapa perintah iptables bersamaan secara umum (rantai yang berbeda terdengar seperti itu mungkin baik-baik saja). iptables adalah pembungkus di sekitar libiptc, dan lihat komentar di iptc_commit: http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

Ini tampaknya diperbaiki pada tahun 2013, tetapi mungkin hanya jika Anda lulus --wait (?): http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

Akar penyebabnya adalah iptables secara efektif memanggil iptables-save / iptables-restore (setidaknya per rantai); Saya telah melihat banyak kode yang hanya memanggil iptables-save & iptables-restore daripada melakukan sesuatu melalui penambahan dan penghapusan. Saya bahkan mungkin memiliki beberapa kode untuk dilakukan yang dapat saya gali jika itu membantu.

Ini mengejutkan pikiran saya bahwa tidak ada cara untuk melakukan operasi semacam CAS atau LL/SC.

Kita harus menambahkan dukungan untuk --wait, meskipun baru-baru ini GCE
debian-backports tidak memilikinya.

Mungkin kita harus melakukan penguncian sendiri di dalam kode kita untuk setidaknya mencegah kita
dari menginjak diri kita sendiri.

Pada Kam, 26 Februari 2015 pukul 13:56, Justin Santa Barbara <
[email protected]> menulis:

Barang bagus! Sekedar FYI (mengkonfirmasi dari percakapan tatap muka kami),
tidak aman untuk menjalankan beberapa perintah iptables secara bersamaan secara umum
(rantai yang berbeda terdengar seperti itu mungkin baik-baik saja). iptables adalah pembungkusnya
libiptc, dan lihat komentar di iptc_commit:
http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

Ini tampaknya diperbaiki pada tahun 2013, tetapi mungkin hanya jika Anda lulus --wait (?):
http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

Akar penyebabnya adalah iptables secara efektif memanggil iptables-save /
iptables-restore (setidaknya per rantai); Saya telah melihat banyak kode yang hanya
oleh karena itu memanggil iptables-save & iptables-restore daripada melakukan sesuatu
melalui penambahan dan penghapusan. Saya bahkan mungkin memiliki beberapa kode untuk dilakukan yang bisa saya gali
up jika itu membantu.

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

Apa yang terjadi jika terjadi kegagalan di tengah pembuatan banyak aturan?

Pertanyaan yang wajar - kita mungkin harus berpikir keras tentang apa artinya
menemukan kesalahan di tengah-tengah ini

Pada Kam, 26 Februari 2015 jam 20:47, Brian Grant [email protected]
menulis:

Apa yang terjadi dalam kasus kegagalan di tengah menciptakan sekelompok
aturan?

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

@thockin Dari irc hari ini:

net.ipv4.conf.all.route_localnet mengizinkan 127.0.0.1 menjadi target aturan DNAT . Dari dokumen :

route_localnet - BOOLEAN

Jangan anggap alamat loopback sebagai sumber atau tujuan Mars
saat perutean. Ini memungkinkan penggunaan 127/8 untuk tujuan perutean lokal.
default SALAH

Apakah kita akan mengintegrasikan ini ke dalam kubelet, atau menyimpannya di daemon yang terpisah? Kubelet sudah melihat layanan untuk mengisi env vars.

Saya ingin menyimpannya sebagai biner terpisah. Ada alasan kenapa kamu
mungkin ingin menjalankan ini di mesin lain (misalnya pet VM) di luar k8s
cluster untuk mendapatkan akses ke layanan k8s.

--brendan

Pada Jum, 13 Mar 2015 jam 11:37, Brian Grant [email protected]
menulis:

Apakah kita akan mengintegrasikan ini ke dalam kubelet, atau menyimpannya di daemon yang terpisah?
Kubelet sudah melihat layanan untuk mengisi env vars.

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

Menangkap. Mengenai apa yang terjadi dalam kasus kegagalan (yang akan ada banyak, percayalah), saya penggemar berat pendekatan anti-entropi - simpan keadaan yang diinginkan di suatu tempat, dan secara berkala rekonsiliasi keadaan yang diinginkan dan aktual (dengan mengubah keadaan aktual ). Dalam hal ini, mungkin sesederhana:

sementara (benar) {
status aktual = iptablesSave()
jika keadaan aktual != keadaan yang diinginkan { iptablesRestore(keadaan yang diinginkan))
tidur_a_sementara()
}

Setuju 100% itu cara yang tepat untuk mengatasi kegagalan dalam menulis iptables
aturan.

Pada Jum, 13 Mar 2015 jam 13:16, Quinton Hoole [email protected]
menulis:

Menangkap. Mengenai apa yang terjadi dalam kasus kegagalan (yang
akan ada banyak, percayalah), saya penggemar berat pendekatan anti-entropi

• menyimpan keadaan yang diinginkan di suatu tempat, dan secara berkala mendamaikan dan
  keadaan sebenarnya (dengan mengubah keadaan sebenarnya). Dalam hal ini, mungkin sesederhana:

sementara (benar) {
status aktual = iptablesSave()
jika keadaan aktual != keadaan yang diinginkan { iptablesRestore(keadaan yang diinginkan))
tidur_a_sementara()
}

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

Kurang lebih itulah yang terjadi sekarang, bukan? Untuk setiap aturan yang diharapkan,
periksa apakah itu ada dan jika tidak, buatlah.

Pada Jum, 13 Mar 2015 jam 14:02, Brendan Burns [email protected]
menulis:

Setuju 100% itu cara yang tepat untuk mengatasi kegagalan dalam menulis iptables
aturan.

Pada Jum, 13 Mar 2015 jam 13:16, Quinton Hoole [email protected]
menulis:

Menangkap. Mengenai apa yang terjadi dalam kasus kegagalan (yang
akan ada banyak, percayalah), saya penggemar berat anti-entropi
mendekati

• menyimpan keadaan yang diinginkan di suatu tempat, dan secara berkala mendamaikan dan
  keadaan sebenarnya (dengan mengubah keadaan sebenarnya). Dalam hal ini, mungkin sesederhana
  sebagai:

sementara (benar) {
status aktual = iptablesSave()
jika keadaan aktual != keadaan yang diinginkan { iptablesRestore(keadaan yang diinginkan))
tidur_a_sementara()
}

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

.

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

Saya setuju ada utilitas dalam biner terpisah, tapi mungkin kami menautkannya ke
kubelet (sama seperti cAdvisor) dan membuatnya mandiri di
waktu yang sama.

Pada Jum, 13 Mar 2015 jam 12:03, Brendan Burns [email protected]
menulis:

Saya ingin menyimpannya sebagai biner terpisah. Ada alasan kenapa kamu
mungkin ingin menjalankan ini di mesin lain (misalnya pet VM) di luar k8s
cluster untuk mendapatkan akses ke layanan k8s.

--brendan

Pada Jum, 13 Mar 2015 jam 11:37, Brian Grant [email protected]
menulis:

Apakah kita akan mengintegrasikan ini ke dalam kubelet, atau menyimpannya di daemon yang terpisah?
Kubelet sudah melihat layanan untuk mengisi env vars.

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

.

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

Saya ingin tahu apa yang dikatakan orang-orang Kubernetes-Mesos tentang apakah komponen node harus lebih terintegrasi atau modular. @jdef?

[[EDITED]] Saya sangat menyukai modularitas komponen k8s, misalnya menjalankan proses proxy yang terpisah dari proses kubelet. Jika proxy gagal karena alasan apa pun, ia tidak menghapus kubelet. Itu cukup bagus karena eksekutor Mesos tidak memiliki model failover yang sangat bagus sekarang -- dan eksekutor framework kubernetes-mesos adalah hibrida kubelet/executor. Model ini juga memungkinkan saya menjalankan layanan proxy pada master mesos dan menggunakannya sebagai penyeimbang round-robin untuk klien eksternal (seperti dalam panduan memulai yang kami kirimkan).

Dalam hal binari pengepakan/pengiriman, saya pikir cukup berguna untuk memiliki fungsionalitas yang dikemas bersama, seperti pada hyperkube. Saya juga memikirkan cara mengemas komponen kerangka kerja kubernetes-mesos ke dalam wadah Docker minimal . Iptables memiliki dependensi perpustakaan eksternal dan itu memperumit banyak hal. Jadi kompromi yang bagus adalah mengirimkan kerangka kerja k8sm sebagai Docker yang berisi satu gambar hyperkube - tetapi ketika kerangka kerja itu dijalankan dan mulai mendistribusikan eksekutor kubelet di seluruh cluster, pada dasarnya ia mengirimkan gambar hyperkube yang dapat berubah menjadi kubelet- eksekutor atau proxy - dan setiap proses dapat berjalan langsung di host. Ini pada dasarnya melakukan penyelesaian akhir di sekitar masalah ketergantungan iptables-{binararies,libraries}-in-Docker.

+1 untuk fungsionalitas modular, +1 untuk gambar biner tunggal

@thockin re: anti-entropi: Ah ya. Saya melihat proxier.SyncLoop() melakukan itu. Dalam hal apa bukan jawaban atas pertanyaan @bgrant0607 pada 26 Februari bahwa kesalahan dapat diabaikan dan akan diperbaiki pada iterasi berikutnya dari SyncLoop() (saat ini 1 menit)? Atau mungkin saya melewatkan sesuatu?

@thockin

1. Apakah kita khawatir tentang lalu lintas jaringan lubang hitam atau apakah itu sesuatu yang perlu diperhatikan oleh pembuat layanan/pod?

Dengan proxy ruang pengguna
Asumsikan Virtual IP 10.0.0.11 memiliki 3 titik akhir katakanlah, 10.240.1.1, 10.240.1.2, 10.240.1.3
Dengan proxy ruang pengguna, jika satu titik akhir mengatakan, 10.240.1.1 tidak berfungsi, proxy akan menyadari bahwa koneksi tcp tidak dibuat dengan 10.240.1.1, dan itu bisa mundur ke salah satu dari 2 titik akhir lainnya.

Dengan iptables
Saat kita menggunakan iptables, tidak ada mekanisme fallback karena kubernetes tidak menyadari apakah endpoint berfungsi atau tidak.
Kami dapat mengurangi ini jika kami memiliki semacam pemeriksaan kesehatan untuk titik akhir, yang akan menghapus titik akhir yang tidak responsif.

Atau mungkin, mengkhawatirkan endpoint yang tidak responsif bukanlah tanggung jawab sistem kubernetes dan merupakan tanggung jawab pembuat pod?

Pengguna dapat mengatur probe kesiapan, yang dilakukan oleh Kubelet. Kegagalan probe akan menyebabkan titik akhir dihapus dari daftar titik akhir oleh pengontrol titik akhir. Proxy layanan kemudian harus menghapus titik akhir dari set target.

Saya telah mencari ini untuk GSoC, dan saya bertanya-tanya:

Jadi idealnya kami mendeteksi apakah iptables cukup baru untuk digunakan dan jika tidak, terus menggunakan kube-proxy?

Dari https://github.com/GoogleCloudPlatform/kubernetes/issues/5419 sepertinya ini akan menjadi pendekatan yang ideal; dengan kubelet menentukan apakah akan menggunakan ip-tables atau memulai kube-proxy.

Saya juga agak terlambat ke GSoC (sedang liburan musim semi....), jadi saya juga bertanya-tanya apakah saya masih bisa mengajukan proposal GSoC untuk itu besok/lambat hari ini (selain tentu saja batas waktu ke-27, adalah ini masih buka)?

@BenTheElder Ya, Anda memiliki waktu hingga hari Jumat untuk mengirimkan proposal. Ada satu orang lain yang berpotensi tertarik dengan topik ini, tetapi belum ada proposal khusus untuk itu.

Saya tidak khawatir tentang kernel yang lebih tua dari 2012 seperti halnya saya tentang OS tanpa iptables sepenuhnya, meskipun itu sudah rusak sampai tingkat tertentu.

@bgrant0607 terima kasih!
Saya pikir saya dapat memilih masalah ini. Ini terlihat menarik.

Probe kesiapan akan bekerja dengan baik untuk startup aplikasi tetapi saya tidak yakin kesiapan cocok untuk mengurangi kegagalan aplikasi. Saat pod gagal, sinyal harus lewat dari aplikasi -> kubelet -> apiserver -> endpoints_controller -> apiserver -> kube-proxy. Saya tertarik untuk memahami latensi antara kegagalan aplikasi dan penghapusan titik akhir dari rotasi kube-proxy. Selama periode ini, permintaan akan diproksikan ke titik akhir yang tidak responsif.

Coba lagi saat koneksi gagal adalah strategi umum, dan fitur yang cukup berguna dari banyak penyeimbang beban populer (misalnya haproxy, AWS ELB) dan ditangani oleh implementasi kube-proxy saat ini. Haruskah tanggung jawab ini dipindahkan ke LB eksternal? Bagaimana dengan lalu lintas intra-cluster?

Pemikiran lain, dengan iptables kita kemungkinan akan menghadapi masalah koneksi yang terkuras dengan anggun saat konfigurasi ulang vs LB yang sebenarnya.

Mike meningkatkan poin bagus.

Pada Mon, Mar 23, 2015 at 11:00, Mike Danese [email protected]
menulis:

Pikiran lain, kita kemungkinan akan menghadapi masalah koneksi dengan anggun
terkuras pada konfigurasi ulang vs LB yang sebenarnya.

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

Saya telah membaca sumber untuk kube-proxy dan proxy pkg; apakah iptables belum digunakan dalam revisi saat ini?

Apa sebenarnya yang perlu dilakukan dalam hal ini? Dari sumber master saat ini, sepertinya iptables sudah digunakan cukup luas di proxy.

Kesiapan @mikedanese @thockin paling berguna untuk pemadaman terencana. Pemadaman yang tidak direncanakan akan selalu menyebabkan beberapa kesalahan yang dapat diamati. Interval polling umumnya relatif panjang untuk memperbarui latensi, tetapi kita juga dapat menerapkan aturan penerusan ulang pada node tujuan melalui komunikasi langsung antara Kubelet dan kube-proxy, jika latensi melalui apiserver dan etcd terlalu panjang dan/atau itu jalan tidak cukup dapat diandalkan.

@BenTheElder Aturan yang ada merutekan lalu lintas melalui proxy. Idenya di sini adalah menggunakan aturan untuk mem-bypass proxy.

@ bgrant0607 Terima kasih, itu masuk akal sekarang. Yang lain membaca sumber dan dokumen desain dan saya hampir selesai menulis draf proposal.

Draf Proposal GSoC: https://Gist.github.com/BenTheElder/ac61900595a7ea9ea9b5

Saya sangat menghargai umpan balik di bagian jadwal. Saya tidak yakin tentang itu.
Haruskah saya selesai lebih awal, saya ingin mengerjakan beberapa masalah GSoC lainnya (lebih kecil?) yang belum diambil seperti:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1651.

Sekali lagi terima kasih, Kubernetes mengambil kue untuk grup yang paling ramah.

Saya hanya ingin mengatakan bahwa saya sangat senang untuk mengatakan bahwa proposal saya telah diterima dan saya akan mengerjakan ini selama musim panas. :senyum:

Saya sangat gembira. Sayangnya saya berada di tengah-tengah final saya sekarang, tetapi mulai akhir pekan ini saya harus lebih banyak dan mengerjakannya, kemungkinan besar dimulai dengan mendapatkan https://github.com/GoogleCloudPlatform/kubernetes/pull/7032 selesai.

@thockin @brendanburns Adakah yang bisa mempertimbangkan apakah kita ingin melakukan ini secara paralel dengan proxy userspace atau bagaimana migrasi ke implementasi ulang akan berhasil?

Sepertinya kita sudah lebih suka iptables >= 1.4.11(dirilis 2011-Mei-26).

// Executes the rule check without using the "-C" flag, instead parsing iptables-save.
// Present for compatibility with <1.4.11 versions of iptables.  This is full
// of hack and half-measures.  We should nix this ASAP.
func (runner *runner) checkRuleWithoutCheck(table Table, chain Chain, args ...string) (bool, error) {

Sumber: https://github.com/GoogleCloudPlatform/kubernetes/blob/aec41967416cf3463b188d72c97e71465e00719d/pkg/util/iptables/iptables.go#L206

Apakah kita benar-benar melihat host yang lebih tua dari itu?

Salah satu pendekatan jelas adalah mendeteksi pada saat dijalankan versi iptables apa yang kami jalankan, dan melakukan "hal terbaik" yang dapat kami berikan pada versi tersebut misalnya sesuatu seperti:

jika (versi lama) {
memuat modul proxy ruang pengguna
}
lain {
memuat modul proxy iptables
}

Saya akan berhati-hati agar tidak memiliki terlalu banyak cabang dalam pernyataan if di atas (idealnya hanya 2), dan sejauh mungkin menghindari pernyataan if semacam ini di lebih dari satu tempat dalam kode.

Saya belum menyaring kode secara detail untuk mengetahui seberapa layak pendekatan di atas.

Juga, apakah semua node perlu menerapkan strategi yang sama (ruang pengguna vs proxy iptables), atau dapatkah masing-masing memutuskan secara independen?

Jika setiap node memutuskan secara independen, kami berpotensi meningkatkan luas permukaan uji sebanding dengan kuadrat jumlah cabang dalam pernyataan if di atas (yaitu source_mode x dest_mode), tetapi jika kami dapat mempertahankan jumlah mode menjadi 2, saya pikir itu baik-baik saja .

Q

Oh, dan jawaban atas pertanyaan Anda apakah kami melihat node lama adalah "ya", sayangnya.

Ada banyak diskusi di atas dalam masalah terpisah., Saya akan mencoba menggalinya untuk Anda.

@quinton-hoole Terima kasih!

Saya juga cukup yakin kita dapat menjalankan ruang pengguna di satu node dan iptables di node lain.

Jumlah mode seharusnya hanya 2 kecuali untuk peretasan itu ketika kita tidak memiliki -C tetapi node yang memiliki -C harus dapat menjalankan versi iptables murni (saya pikir).

Ah ya, #7528 membahas versi kernel dan semacamnya.

Terima kasih.
Saya tidak melihatnya ketika saya mencari persyaratan untuk kubernetes. Satu-satunya persyaratan yang saya temukan adalah di dokumen jaringan yang membahas bagaimana kami menganggap ip unik.

Kami mungkin harus mendapatkan beberapa dokumentasi yang ditulis untuk persyaratan setelah kami memiliki gagasan yang lebih baik tentang apa itu.

Saya sudah mulai meretas ini di sini: https://github.com/BenTheElder/kubernetes/tree/iptables_proxy

Secara khusus saya telah memindahkan implementasi ruang pengguna di belakang antarmuka di sini:
https://github.com/BenTheElder/kubernetes/commit/4e5d24bb74aca43b0dd37cf5cfee8a34f8eff2bf

Saya tidak yakin sekarang jika pemilihan implementasi harus di cmd/kube-proxy atau di pkg/proxy jadi saya dapat menghapus ini dan implementasinya dipilih oleh kube-proxy sebagai gantinya.

Sunting: Saya pikir dalam retrospeksi bahwa mungkin lebih masuk akal untuk memilih implementasi dari kube-proxy.

@BenTheElder Saya menguji aturan Tim dengan Calico dan mereka berfungsi dengan baik. Kami melakukan semua pekerjaan kami di tabel filter, jadi aturan DNAT di sini telah menetapkan IP src yang sesuai pada titik itu.

Secara umum, akan lebih baik untuk berdiskusi untuk menentukan bagaimana plugin jaringan dapat dengan aman mengubah iptables jika Kubernetes juga akan memasukkan aturan di sana. Tidak ingin menginjak-injak (atau diinjak-injak) aturan Kubernetes jika mereka berubah di tengah jalan.

@Simetris Ya. Saya belum yakin tentang bagian plugin sama sekali, tetapi itu tampaknya cukup penting.

Saya mungkin akan sedikit sibuk akhir pekan ini, tetapi hari Senin saya harus mulai bekerja penuh waktu ini untuk GSoC yang mengimplementasikan iterasi pertama.
Saya ingin mengingat hal ini saat melakukannya, tetapi setelah melihat-lihat api plugin jaringan, saya tidak begitu yakin apa cara terbersih untuk menangani ini.

Apakah Anda tahu seperti apa tampilannya / bagaimana seharusnya ini bekerja?

FWIW, saya melakukan sesuatu yang berhasil untuk kami karena kube-proxy menjadi hampir tidak responsif. Ada di sini: https://github.com/MikaelCluseau/kubernetes-iptables-proxy/blob/master/iptables-routing.rb.

Saya tidak melihat utas ini sebelumnya, tetapi saya berakhir dengan sesuatu yang dekat, kecuali bahwa saya melakukan kesalahan dengan bobot kecocokan statistik acak saya :-)

Saya juga ingin berbagi bahwa kita telah mencapai nf_conntrack_max dengan cepat. Mungkin harus ditingkatkan.

# cat /etc/sysctl.d/nf_conntrack.conf 
net.netfilter.nf_conntrack_max = 1000000
net.nf_conntrack_max           = 1000000

Saya mungkin belum memahami semua kebutuhan iptables , tetapi mengapa tidak menggunakan IPVS saja?
Tampaknya lebih relevan untuk proxing daripada iptables ...
Berikut ini adalah implementasi go sederhana: https://github.com/noxiouz/go-ipvs
Dan hanya untuk menyelesaikan #561, ada juga proyek ktcpvs .

IPVS tampaknya juga merupakan abstraksi pada netfilter (seperti iptables). Kami dapat berbagi beberapa fungsi dengan kode yang ada dengan menggunakan iptables; dan iptables sepertinya solusi yang lebih fleksibel/umum untuk mengelola netfilter.

Adapun #561 dan ktcpvs: ktcpvs tampaknya tidak memiliki perkembangan apa pun sejak 2004 dan tampaknya tidak memiliki fitur yang diinginkan pengguna seperti penulisan ulang URL. Terlepas dari #561 sedang mencari solusi umum untuk dapat digunakan dengan penyeimbang yang dapat dicolokkan.

Catatan tambahan: proyek go itu tampaknya tidak memiliki lisensi.

iptables akan ditinggalkan "suatu hari" demi nftables ( nft cli).
Juga menggunakan iptables CLI untuk membuat aturan tampaknya tidak cukup kuat ...

Pencarian cepat temukan saya proyek MIT lainnya ini: https://github.com/vieux/go-libipvs
Tetapi tampaknya sangat mudah untuk membuat yang sederhana karena semua kerumitan sudah antipeluru di dalam kode kernel.

Saya ragu iptables akan dihapus dari salah satu distro utama dalam waktu dekat, dan iptables CLI khusus untuk membuat dan mengelola aturan untuk netfilter ... ?

Pembungkus cgo yang tidak lengkap seperti yang ditautkan tampaknya jauh lebih tidak aman daripada mengeluarkan iptables dan iptables-restore dan kita sudah membutuhkan iptables untuk aturan lain (misalnya nodeports) dan dengan iptables-restore kita dapat melakukan pembaruan massal dengan beberapa atomisitas.

IPVS lebih lanjut tampaknya dirancang untuk digunakan pada mesin host penyeimbang beban secara terpisah dari server "nyata".
Ini menunjukkan bahwa menjadi satu-satunya penggunaan yang didukung:

2.2. Gotchas: Anda memerlukan klien luar (direktur dan server nyata tidak dapat mengakses layanan virtual)

Untuk menyiapkan dan menguji/menjalankan LVS, Anda memerlukan minimal 3 mesin: klien, direktur, server nyata.

Dari luar, LVS berfungsi sebagai satu mesin. Klien tidak dapat menjadi salah satu mesin di LVS (direktur, atau server nyata). Anda membutuhkan klien luar. Jika Anda mencoba mengakses layanan yang dikontrol LVS (mis. http, smtp, telnet) dari salah satu mesin di LVS; akses dari direktur akan hang, akses dari server nyata akan terhubung ke layanan secara lokal, melewati LVS.

Sepertinya IPVS/LVS menambahkan beberapa persyaratan tambahan seperti daemon detak jantung dan proses pemantauan ekstra. Kami sudah menangani informasi titik akhir dan pemantauan kesehatan pod dll dari dalam kubernetes.

+1 untuk pendekatan iptables. Kami menggunakan iptables secara ekstensif di Calico dan mereka telah terbukti kuat dan mereka berkinerja dan berskala dengan baik (dengan asumsi Anda merancang aturan Anda dengan baik). @BenTheElder , jika Anda memerlukan bantuan apa pun tentang pekerjaan iptables, beri tahu kami, karena kami akan dengan senang hati ikut serta.

+1 untuk iptables dan iptables-restore, ini adalah pendekatan yang jauh lebih ringan
daripada IPVS/LVS dan mendikte lebih sedikit persyaratan sistem (daemon detak jantung,
dll.)

Pada Sabtu, 13 Juni 2015 pukul 11:27, Alex Pollitt [email protected]
menulis:

+1 untuk pendekatan iptables. Kami menggunakan iptables secara ekstensif di Calico dan
mereka telah terbukti kuat dan mereka melakukan dan menskalakan dengan baik (dengan asumsi Anda
rancang aturan Anda dengan baik). @BenTheElder https://github.com/BenTheElder ,
jika Anda memerlukan bantuan apa pun tentang pekerjaan iptables, silakan beri tahu
kami tahu, karena kami akan senang untuk ikut serta.

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

Terima kasih Alex, saya akan memberi tahu Anda jika saya melakukannya.

Saya dapat menggunakan beberapa umpan balik/masukan pada implementasi saat ini (https://github.com/GoogleCloudPlatform/kubernetes/pull/9210) jika ada yang punya waktu.

Sebagian besar lengkap dan saat ini penuh dengan master hulu, saya harus menyelesaikan penulisan kode yang membandingkan aturan yang dihasilkan dengan iptables-save dan mengembalikan penghitung dll, tetapi aturan dibuat dan (kebanyakan) berfungsi, cukup banyak mengikuti aturan yang diuraikan dalam OP di sini dengan perubahan terbesar hanya menjadi nama rantai, yang diperlukan untuk pembuatan nama otomatis yang akan diterima iptables.

Ada kasus Edge yang dilaporkan di sini: https://github.com/BenTheElder/kubernetes/issues/3 yang mungkin memerlukan perubahan untuk menangani pod yang terhubung ke dirinya sendiri.

Saya memiliki beberapa umpan balik dan diskusi yang sangat baik dengan @MikaelCluseau dan @Symmetric khususnya tentang melakukan beberapa desain ulang untuk menangani ini dan hal-hal lain (terima kasih lagi!); tapi kita bisa menggunakan lebih banyak masukan pada desain aturan pada khususnya. Jika ada orang lain yang punya waktu untuk melihatnya, itu akan sangat dihargai karena saya tidak yakin apa rute terbaik yang harus diambil dan saya ingin menghindari membuat perubahan besar tanpa masukan lebih lanjut.

PR itu sendiri cukup besar tetapi pembuatan aturan yang relevan semuanya ada di pkg/proxy/proxieriptables.go syncProxyRules() di: https://github.com/BenTheElder/kubernetes/blob/iptables_proxy/pkg/proxy/proxieriptables. pergi#L286

Diskusi yang ada dapat dilihat (di sini tentu saja) serta di komentar PR dan di https://github.com/BenTheElder/kubernetes/issues/3 serta sedikit lebih banyak di https://github.com/ BenTheElder/kubernetes/issues/4.

Satu masalah lain yang membutuhkan masukan:

Dalam kode saat ini, kube-proxy masih disertakan, untuk menangani HANYA kasus nodePort. Saya pikir kita dapat menghapus kube-proxy dalam kasus ini juga, dan telah mengusulkan beberapa aturan iptables sederhana untuk melakukannya pada PR Ben .

Tetapi aturan ini masih mengaburkan IP sumber dari LB eksternal apa pun, sehingga tidak ideal. Masalahnya adalah jika kita hanya DNAT lalu lintas dari LB ketika menyentuh sebuah node, maka paket respons bisa datang dari node yang berbeda, jadi saya tidak berpikir LB akan dapat mengkorelasikan respons dengan sesi TCP asal. . Apakah kekhawatiran ini valid? Implementasinya akan lebih sederhana jika kita tidak perlu khawatir tentang hal ini.

Saya menduga ada beberapa keajaiban yang bisa kita lakukan untuk membuat proxy HTTP senang, tapi saya tidak melihat cara untuk membuat ini umum di L4.

Saya mencoba sihir hitam dari PR Anda, tetapi itu tidak menghasilkan apa pun untuk saya, sepertinya aturan mulai dibuat dengan panggilan ke iptables kemudian file iptables-restore diproduksi.

Ada kesalahan di bagian header di file yang dihasilkan, biasanya yang telah diisi dengan panggilan iptables, Ada bagian yang relevan dari log:

I0807 11:41:24.560063 8369 iptables.go:327] menjalankan iptables -N [KUBE-PORTALS-CONTAINER -t nat]
I0807 11:41:24.562361 8369 iptables.go:327] menjalankan iptables -C [PREROUTING -t nat -m comment --comment menangani ClusterIPs; CATATAN: ini harus sebelum aturan NodePort -j KUBE-PORTALS-CONTAINER]
I0807 11:41:24.563469 8369 iptables.go:327] menjalankan iptables -N [KUBE-PORTALS-HOST -t nat]
I0807 11:41:24.565452 8369 iptables.go:327] menjalankan iptables -C [OUTPUT -t nat -m comment --comment handle ClusterIPs; CATATAN: ini harus sebelum aturan NodePort -j KUBE-PORTALS-HOST]
I0807 11:41:24.566552 8369 iptables.go:327] menjalankan iptables -N [KUBE-NODEPORT-CONTAINER -t nat]
I0807 11:41:24.568363 8369 iptables.go:327] menjalankan iptables -C [PREROUTING -t nat -m addrtype --dst-type LOCAL -m comment --comment handle service NodePorts; CATATAN: ini harus menjadi aturan terakhir dalam rantai -j KUBE-NODEPORT-CONTAINER]
I0807 11:41:24.569564 8369 iptables.go:327] menjalankan iptables -N [KUBE-NODEPORT-HOST -t nat]
I0807 11:41:24.571458 8369 iptables.go:327] menjalankan iptables -C [OUTPUT -t nat -m addrtype --dst-type LOCAL -m comment --comment menangani layanan NodePorts; CATATAN: ini harus menjadi aturan terakhir dalam rantai -j KUBE-NODEPORT-HOST]
I0807 11:41:24.573392 8369 iptables.go:327] menjalankan iptables -C [POSTROUTING -t nat -m comment --comment menangani pod yang terhubung ke self -s 10.240.240.78/32 -d 10.240.240.78/32 -j MASQUERADE ]
I0807 11:41:24.574447 8369 proxier.go:349] Menyinkronkan aturan iptables.
I0807 11:41:24.575592 8369 proxier.go:399] Rantai: PREROUTING, Aturan: :PREROUTING ACCEPT [0:0]
I0807 11:41:24.575615 8369 proxier.go:401] Rule: -A PREROUTING -m comment --comment "handle ClusterIPs; CATATAN: ini harus sebelum aturan NodePort" -j KUBE-PORTALS-CONTAINER
I0807 11:41:24.575625 8369 proxier.go:401] Aturan: -A PREROUTING -m addrtype --dst-type LOCAL -m comment --comment "handle service NodePorts; CATATAN: ini harus menjadi aturan terakhir dalam rantai" -j KUBE-NODEPORT-CONTAINER
I0807 11:41:24.575633 8369 proxier.go:399] Rantai: INPUT, Aturan: :INPUT ACCEPT [0:0]
I0807 11:41:24.575646 8369 proxier.go:399] Rantai: OUTPUT, Aturan: :OUTPUT ACCEPT [0:0]
I0807 11:41:24.575658 8369 proxier.go:401] Rule: -A OUTPUT -m comment --comment "handle ClusterIPs; NOTE: ini harus sebelum aturan NodePort" -j KUBE-PORTALS-HOST
I0807 11:41:24.575670 8369 proxier.go:401] Aturan: -A OUTPUT -m addrtype --dst-type LOCAL -m comment --comment "handle service NodePorts; CATATAN: ini harus menjadi aturan terakhir dalam rantai" -j KUBE-NODEPORT-HOST
I0807 11:41:24.575683 8369 proxier.go:399] Rantai: POSTROUTING, Aturan: :POSTROUTING ACCEPT [0:0]
I0807 11:41:24.575691 8369 proxier.go:401] Rule: -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
I0807 11:41:24.575699 8369 proxier.go:401] Rule: -A POSTROUTING -s 10.240.240.78/32 -d 10.240.240.78/32 -m comment --comment "handle pod connected to self" -j MASQUERADE
I0807 11:41:24.575709 8369 proxier.go:399] Rantai: KUBE-NODEPORT-CONTAINER, Aturan: :KUBE-NODEPORT-CONTAINER - [0:0]
I0807 11:41:24.575720 8369 proxier.go:399] Rantai: KUBE-NODEPORT-HOST, Aturan: :KUBE-NODEPORT-HOST - [0:0]
I0807 11:41:24.575729 8369 proxier.go:399] Rantai: KUBE-PORTALS-CONTAINER, Aturan: :KUBE-PORTALS-CONTAINER - [0:0]
I0807 11:41:24.575740 8369 proxier.go:399] Rantai: KUBE-PORTALS-HOST, Aturan: :KUBE-PORTALS-HOST - [0:0]
I0807 11:41:24.581897 8369 proxier.go:603] Aturan sinkronisasi: :KUBE-PORTALS-HOST - [0:0]
:KUBE-PORTAL-CONTAINER - [0:0]
:KUBE-NODEPORT-HOST - [0:0]
:KUBE-NODEPORT-CONTAINER - [0:0]
:KUBE-SVC-VO8JL93ZeRSf8cnsLpl - [0:0]
:KUBE-SVC-L26cB3JYuxdW5TF84ct - [0:0]
:KUBE-SVC-j2SF8q3nUajS8vOx2qL - [0:0]
:KUBE-SVC-shln2urO8W1aBiB2bWJ - [0:0]
:KUBE-SVC-8jQ3IvijvhJ4ppFj3Ui - [0:0]
[... SNIP ...]

Menggabungkan iptable-save dengan hasil yang dihasilkan dalam mode verbose dapat diimpor dan melakukan hal-hal baik.

@bnprss terima kasih atas laporannya, baru-baru ini ada sejumlah perubahan yang belum diuji termasuk menggunakan file temp dan menggunakan tanda "-T table" untuk iptables-restore selama beberapa penulisan ulang untuk proses peninjauan. Saya akan memperbaikinya setelah saya tahu apa yang menyebabkan regresi.

@bnprss Seperti yang Anda katakan, header tabel tidak ada ("* nat" harus menjadi baris pertama), itu salah dihapus dan setelah memasukkannya kembali semuanya tampaknya berfungsi dengan baik lagi tanpa tampaknya tidak ada bug lain (tidak termasuk: https:/ /github.com/BenTheElder/kubernetes/issues/3). Terima kasih sekali lagi, maaf tentang itu. Saya telah mendorong perbaikannya.

Kerja bagus, aturan sedang memuat dan sepertinya berfungsi dari dalam tetapi tidak berhasil dengan externalloadbalancer tidak ada komunikasi dari luar yang memberikan jawaban.

Hah. Bisakah Anda pindah ke PR dan memberikan beberapa rincian lebih lanjut? Sejauh ini
sudah bekerja dengan baik tetapi saya tidak menggunakan diri saya di luar pengujian lokal dan saya
jangan berpikir ada penguji lain yang menggunakan penyeimbang beban eksternal.
Pada 7 Agustus 2015 13:29, "bnprss" [email protected] menulis:

Kerja bagus, aturan sedang dimuat dan sepertinya berfungsi dari dalam tetapi tidak berhasil
dengan externalloadbalancer tidak ada komunikasi dari luar memberikan jawaban.

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

Yap, untuk detailnya saya akan melakukan penyelidikan lebih lanjut dan akan menghasilkan beberapa log atau prospek tentang PR, tetapi tidak sebelum besok, saya ingin memiliki beberapa pekerjaan cadangan yang baik untuk dijalankan sebelum berpotensi merusak sesuatu.

Bisakah Anda menghitung token aturan tanpa pemisah "-_" ?

@bnprss , bagus.
Rantai aturan yang dihasilkan untuk layanan adalah hash dari port layanan/titik akhir dan kemudian url base64 dikodekan dan dipotong. KUBE-SVC-. Kodenya ada di sini: https://github.com/GoogleCloudPlatform/kubernetes/pull/9210/files#diff -d51765b83fe795b469e8a86276b12dc9R321
Kami memilih ini sebagai cara untuk menghasilkan nama rantai yang valid yang akan memenuhi batas karakter di iptables sambil tetap deterministik.
Jadi harus dimungkinkan untuk mereplikasi secara eksternal.
Jika maksud Anda, bisakah kita berhenti menggunakan pemisah, kita mungkin bisa tetapi "_" berasal dari beberapa hash yang disandikan dan "-" semuanya hanya mengikuti pola dalam nama aturan dari proxy ruang pengguna yang ada.
Kami mungkin bisa menggunakan sesuatu yang lain tanpa terlalu banyak kesulitan jika itu perlu.

Saya setuju dengan itu, dan ini benar-benar kosmetik! :)
Tapi ini berbeda dari hal-hal yang saya lihat sebelumnya:
aturan gce lb : a07f76b3b2ec311e59e2642010af0479
aturan gce fw : k8s-fw-a7ecad94f3ba511e59e2642010af0479
aturan perutean gce : default-route-6973e029b504a0e8
perutean gce ke simpul: obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

yang ini bagus:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
yang itu lucu :
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

Ya, saya juga bukan penggemar mereka, kita mungkin bisa mengubah hash
pengkodean.

Pada Jumat, 7 Agustus 2015 pukul 14:16, bnprss [email protected] menulis:

Saya setuju dengan itu, dan ini benar-benar kosmetik! :)
Tapi ini berbeda dari hal-hal yang saya lihat sebelumnya:
aturan gce lb : a07f76b3b2ec311e59e2642010af0479
aturan gce fw : k8s-fw-a7ecad94f3ba511e59e2642010af0479
aturan perutean gce : default-route-6973e029b504a0e8
perutean gce ke simpul:
obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

yang ini bagus:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
yang itu lucu :
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

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

Ya, itu mungkin hanya menggunakan bagian terpotong dari SHA, git tidak masalah dengan itu, buruh pelabuhan juga, dan tampaknya menjadi cara referensi lain ke entitas kube dibuat. Jika terjadi tabrakan di hash base64 yang dihasilkan tidak akan membantu. ;)
Saya kira @thockin dapat memberi saran tentang hal itu.

Saya lebih peduli dengan karakter yang valid di iptables, yang sulit saya temukan referensi yang bagus. Saya akan melihat ini lebih lanjut segera.

Pada Jumat, 7 Agustus 2015 pukul 14.29, bnprss [email protected] menulis:

Ya, itu mungkin hanya menggunakan bagian SHA yang terpotong, git tidak masalah dengan
itu, buruh pelabuhan juga, dan tampaknya menjadi referensi lain untuk kube
entitas dibuat. Jika terjadi tabrakan di hash base64 yang dihasilkan tidak akan
Tolong. ;)
Saya kira @thockin https://github.com/thockin dapat memberi saran tentang hal itu.

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

@bnprss fyi PRnya cukup tidak stabil dan sedang dikerjakan ulang, per thockin, kami sedang memangkas NodePort dll untuk saat ini dan berfokus untuk mendapatkan versi yang lebih sederhana dan lebih bersih dengan dukungan untuk portal, kemudian bekerja kembali ke paritas penuh.

Saya akan _tidak_ mencoba menjalankan ini sekarang, tetapi semoga akan segera kembali. Memecah PR menjadi beberapa yang lebih kecil yang terkait kemudian mendorong yang bersih dengan hal-hal iptables-proxy sekarang.

Buat kalian yang main di rumah, saya yakin kita bisa maksimalkan
paritas, tetapi akan jauh lebih mudah untuk ditinjau secara bertahap :)

Pada Jumat, 7 Agustus 2015 jam 21:35, Benjamin Elder [email protected]
menulis:

Balasan saya untuk komentar di atas, juga akan segera disingkirkan:

Dibahas di IRC:

• masih perlu menangani penghitung, tetapi ingin terus menguraikan
  nyatakan dalam paket util/iptables.
• masih perlu hashing atau serupa untuk menangani batas panjang rantai

Kalau tidak, sepertinya penyederhanaan yang sangat bersih, akan diterapkan setelahnya
beberapa diskusi lagi.

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

Status: logika "utama" diperiksa dan di-flag-gated.

Saya sedang mengerjakan port simpul sekarang. Ada banyak kasus aneh yang perlu penanganan khusus. Catatan saya sejauh ini:

# Basic node ports:
iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/nodeport:p" -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

# To get traffic from node to localhost:nodeport to the service:
echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet
# Mark packets that are destined for services from localhost, then masquerade those
iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m mark --mark 0x4b000001 -j MASQUERADE

# To get traffic from a pod to itself via a service:
for intf in $(ip link list | grep veth | cut -f2 -d:); do brctl hairpin cbr0 $intf on; done
# Mark packets that are destined for each endpoint from the same endpoint, then masquerade those.
# This is hacky, but I don't really know which pods are "local" and I don't really want to right now. (but I will eventually)
iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

Telah mengerjakan alat kontribusi untuk pengujian.
Sejauh ini saya pikir saya akan menjalankan server pada sebuah node, latensi waktu
memintanya, lihat tentang mendapatkan sumber daya kube-proxy memuat dan membuangnya
data ke CSV untuk grafik dll.
Semoga selesai sebelum hari Jumat, semakin mengenal kubectl sekarang juga.

Pada hari Rabu, 12 Agustus 2015 jam 20:48, Tim Hockin [email protected]
menulis:

Status: logika "utama" diperiksa dan di-flag-gated.

Saya sedang mengerjakan port simpul sekarang. Ada banyak kasus aneh yang perlu
penanganan spesial. Catatan saya sejauh ini:

Port simpul dasar:

iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/ nodeport:p " -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

Untuk mendapatkan lalu lintas dari node ke localhost: nodeport ke layanan:

echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet

Tandai paket yang ditujukan untuk layanan dari localhost, lalu sembunyikan paket tersebut

iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m tandai --tandai 0x4b000001 -j MASQUERADE

Untuk mendapatkan lalu lintas dari pod ke dirinya sendiri melalui layanan:

untuk intf di $(ip link list | grep veth | cut -f2 -d :); lakukan brctl jepit rambut cbr0 $intf pada; selesai

Tandai paket yang ditujukan untuk setiap titik akhir dari titik akhir yang sama, lalu samarkan paket tersebut.

Ini hacky, tetapi saya tidak benar-benar tahu pod mana yang "lokal" dan saya tidak benar-benar menginginkannya sekarang. (tapi akhirnya saya akan)

iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

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

@BenTheElder Saya baru saja melakukan beberapa pengukuran kinerja jaringan yang cukup rinci di GCE -- Saya sarankan untuk melihat netperf (qperf juga memberikan pengukuran latensi).

netperf adalah alat perf klien/server, saya telah mengemas klien dan server dalam wadah buruh pelabuhan paultiplady/ netserver:ubuntu.2. Ada banyak opsi di netperf, tetapi sesuatu seperti memutar dua pod netserver dan menjalankannya

kubectl exec  -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI --  -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

harus memberi Anda penyebaran statistik yang layak termasuk latensi dan throughput. Anda dapat menjalankan wadah netserver menggunakan docker run --net=host untuk melakukan pengujian node->pod juga.

Dockerfile untuk wadah ini cukup sederhana, saya dapat mengaktifkannya jika Anda ingin memperluasnya menjadi sesuatu yang lebih ramping (misalnya wadah berbasis alpinelinux untuk penarikan yang lebih cepat).

Terima kasih, saya akan memeriksanya.

Dari komentar ini, saya pikir kami ingin melakukan semacam latensi permintaan layanan. Saat ini saya sedang mencoba menggunakan wadah nginx standar sebagai simpul X dan bekerja untuk memiliki waktu uji pod yang memukulnya berulang kali sehingga kami dapat membuat grafik pada simpul Y.

Saya akan melihat netperf/qperf, dan kami selalu dapat melakukan beberapa tes.
Saya ingin menyelesaikan grafik itu terlebih dahulu sesuai diskusi sebelumnya dengan @thockin

Pada Kam, 13 Agustus 2015 pukul 12:02, Paul Tiplady [email protected]
menulis:

@BenTheElder https://github.com/BenTheElder Saya baru saja melakukan beberapa hal yang wajar
pengukuran kinerja jaringan terperinci di GCE -- Saya sarankan untuk melihat
netperf (qperf juga memberikan pengukuran latensi).

netperf adalah alat perf klien/server, saya telah mengemas klien dan
server dalam wadah buruh pelabuhan paultiplady/ netserver:ubuntu.2. Di sana
ada banyak opsi di netperf, tetapi sesuatu seperti memutar dua
pod netserver dan berjalan

kubectl exec -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI -- -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

harus memberi Anda penyebaran statistik yang layak termasuk latensi dan throughput.
Anda dapat menjalankan wadah netserver menggunakan docker run --net=host to do
tes node->pod juga.

Dockerfile untuk wadah ini cukup sederhana, saya bisa memecatnya jika
Anda ingin memperluasnya menjadi sesuatu yang lebih ramping (misalnya berbasis alpinelinux
wadah untuk menarik lebih cepat).

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

mengenai port simpul: Di #9210 @Symmetric membawa kasus ini:

Jika lalu lintas mengalir:
LB -> node1:nodePort
Dan pod layanan ada di node2, maka aliran penuhnya adalah:
LB -> node1:nodePort -> node2 -> pod:svcPort
srcIP akan tetap menjadi LB, jadi responsnya akan pergi
pod -> node2 -> LB
Karena node2 dapat merutekan langsung ke LB.

Sekarang kita kehilangan kesempatan untuk un-DNAT untuk mengembalikan IP sumber yang benar untuk paket kembali (yang hanya dapat terjadi pada node1).

Saya telah mereproduksi masalah. ACK bahwa itu adalah masalah nyata. tcpdump menunjukkan paket-paket yang sedang DNAT'ed ke (di luar mesin) pod IP:port, dengan src utuh, tetapi tcpdump pada mesin tujuan tidak menunjukkan apa-apa. Saya tidak yakin apa yang saya harapkan terjadi bahkan jika paket-paket itu sampai di sana.

Saya pikir satu-satunya solusi adalah SNAT. Solusi yang paling tidak berdampak adalah _only_ paket SNAT dari LB yang ditakdirkan off-node, tetapi a) Saya tidak memiliki info itu di kube-proxy (bisa mendapatkannya dengan biaya kode) dan b) karena ada kebijakan harus mempertimbangkan kasus SNAT, saya dapat menyederhanakan dengan selalu meng-SNAT paket LB eksternal. Seberapa buruk itu untuk mesin kebijakan?

Akhirnya LB akan cukup pintar untuk hanya menargetkan host dengan pod dan lalu lintas akan tetap lokal, dan kemudian ini akan diperdebatkan.

Ini menjadi lebih rumit sekalipun. Kami memiliki bidang deprecatedPublicIPs yang mungkin tidak akan kami hentikan dengan beberapa penyesuaian pada perilaku. Saya kira kita perlu melakukan hal yang sama untuk itu. Tapi itu menjadi lebih rumit - saya sebenarnya tidak TAHU semua IP publik (misalnya VM memiliki IP eksternal NAT 1-ke-1). Jawaban mudah - selalu paket node-port SNAT. Apa yang dipikirkan?

Saya akan menguji lebih banyak besok.

@BenTheElder Anda dapat menjadikan pod netserver sebagai layanan, sehingga lalu lintas dari perf <->
server akan melalui layanan VIP. Dengan begitu Anda tidak perlu melakukan
pengambilan sampel/perhitungan latensi sendiri...

Pada hari Rabu, 12 Agustus 2015 jam 21:20, Benjamin Elder [email protected]
menulis:

Terima kasih, saya akan memeriksanya.

Dari komentar ini
meskipun saya pikir kami ingin melakukan semacam latensi permintaan layanan. Benar
sekarang saya sudah mencoba menggunakan wadah nginx standar sebagai simpul X dan bekerja
memiliki waktu uji coba memukulnya berulang kali sehingga kami dapat membuat grafik
simpul Y

Saya akan melihat netperf/qperf, dan kami selalu dapat melakukan beberapa tes.
Saya ingin menyelesaikan grafik itu terlebih dahulu per diskusi sebelumnya dengan
@thockin

Pada Kam, 13 Agustus 2015 pukul 12:02, Paul Tiplady [email protected]
menulis:

@BenTheElder https://github.com/BenTheElder Saya baru saja melakukan beberapa hal yang wajar
pengukuran kinerja jaringan terperinci di GCE -- Saya sarankan untuk melihat
netperf (qperf juga memberikan pengukuran latensi).

netperf adalah alat perf klien/server, saya telah mengemas klien dan
server dalam wadah buruh pelabuhan paultiplady/ netserver:ubuntu.2. Di sana
ada banyak opsi di netperf, tetapi sesuatu seperti memutar dua
pod netserver dan berjalan

kubectl exec -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O
MELALUI,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

seharusnya memberi Anda penyebaran statistik yang layak termasuk latensi dan
keluaran.
Anda dapat menjalankan wadah netserver menggunakan docker run --net=host to do
tes node->pod juga.

Dockerfile untuk wadah ini cukup sederhana, saya bisa memecatnya jika
Anda ingin memperluasnya menjadi sesuatu yang lebih ramping (misalnya berbasis alpinelinux
wadah untuk menarik lebih cepat).

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

.

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

Benar. Saya pikir @thockin akhirnya menyebutkan menginginkan tes latensi e2e sebagai
dengan baik. Waktu memungkinkan akan ada sejumlah tes yang berbeda dan kami akan
mungkin harus memperhitungkan gce vs AWS dll.
Pada 13 Agustus 2015 13:47, "Paul Tiplady" [email protected] menulis:

Anda dapat menjadikan pod netserver sebagai layanan, sehingga lalu lintas dari kinerja <->
server akan melalui layanan VIP. Dengan begitu Anda tidak perlu melakukan
pengambilan sampel/perhitungan latensi sendiri...

Pada hari Rabu, 12 Agustus 2015 jam 21:20, Benjamin Elder [email protected]
menulis:

Terima kasih, saya akan memeriksanya.

Dari [komentar ini](

https://github.com/kubernetes/kubernetes/pull/9210#issuecomment-130154261)
meskipun saya pikir kami ingin melakukan semacam latensi permintaan layanan. Benar
sekarang saya sudah mencoba menggunakan wadah nginx standar sebagai simpul X dan berfungsi
pada
memiliki waktu uji coba memukulnya berulang kali sehingga kami dapat membuat grafik
simpul Y

Saya akan melihat netperf/qperf, dan kami selalu dapat melakukan beberapa tes.
Saya ingin menyelesaikan grafik itu terlebih dahulu per diskusi sebelumnya dengan
@thockin

Pada Kam, 13 Agustus 2015 pukul 12:02, Paul Tiplady < [email protected]

menulis:

@BenTheElder https://github.com/BenTheElder Saya baru saja melakukan beberapa
cukup
pengukuran kinerja jaringan terperinci di GCE -- Saya sarankan untuk melihatnya
pada
netperf (qperf juga memberikan pengukuran latensi).

netperf adalah alat perf klien/server, saya telah mengemas kedua klien
dan
server dalam wadah buruh pelabuhan paultiplady/ netserver:ubuntu.2.
Di sana
ada banyak opsi di netperf, tetapi sesuatu seperti memutar dua
pod netserver dan berjalan

kubectl exec -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j
-H
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O

MELALUI,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

seharusnya memberi Anda penyebaran statistik yang layak termasuk latensi dan
keluaran.
Anda dapat menjalankan wadah netserver menggunakan docker run --net=host to do
tes node->pod juga.

Dockerfile untuk wadah ini cukup sederhana, saya bisa memecatnya
jika
Anda ingin memperluasnya menjadi sesuatu yang lebih ramping (misalnya berbasis alpinelinux
wadah untuk menarik lebih cepat).

—
Balas email ini secara langsung atau lihat di GitHub
<

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

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

.

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

@Symmetric tes netperf bekerja dengan baik. Terima kasih untuk sarannya :-)

Saya ingin meninjau kembali tes untuk beban "nyata" seperti layanan web nanti, tetapi setelah mendapatkan argumen yang benar, sejauh ini memberikan data yang sangat bagus. Saya akan memposting hasilnya nanti setelah saya selesai membersihkan semuanya.

Senang mendengar itu berhasil untuk Anda -- ada jumlah yang membingungkan dari
opsi pada alat itu, tetapi telah terbukti sangat berguna untuk pekerjaan pembuatan profil saya.
Pasti lebih baik daripada iperf...

Pada Kam, 13 Agustus 2015 pukul 14.32, Benjamin Elder [email protected]
menulis:

@Symmetric https://github.com/Symmetric tes netperf berfungsi
baik. Terima kasih untuk sarannya :-)

Saya ingin meninjau kembali tes untuk beban "nyata" seperti layanan web nanti
mungkin, tapi setelah mendapatkan argumen yang benar, itu memberikan data yang sangat bagus jadi
jauh. Saya akan memposting hasilnya nanti setelah saya selesai membersihkan semuanya.

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

@thockin Saya pikir kita bisa hidup dengan SNAT untuk lalu lintas LB. Pemikiran saya saat ini adalah bahwa Anda harus menentukan kebijakan akses pod sebagai salah satu dari:

• defaultnya adalah 'izinkan dari [ruang nama saya]', dalam hal ini paket LB dihapus
• 'izinkan dari [daftar ruang nama]', atau 'izinkan dari [semua ruang nama di cluster]', lagi-lagi paket LB selalu dihapus
• 'izinkan dari semua', dalam hal ini kami tidak peduli apakah itu dari LB, simpul lain, atau di mana pun

Jadi kehilangan IP sumber hanya untuk LB sebenarnya tidak terlalu merugikan kami.

Jika kami dapat menjamin bahwa LB mencapai node yang tepat untuk pod layanan, itu akan sangat bagus -- dalam hal ini kami tidak memerlukan SNAT, dan kami dapat menjalankan kapal yang lebih ketat dengan memasukkan daftar putih IP LB saat disediakan di a layanan, dan menjatuhkan lalu lintas sebaliknya.

Mengenai publicIP, saya pikir mereka akan memiliki pertimbangan yang sama dengan nodePort, jadi kita perlu SNAT sampai LB dapat mencapai host yang tepat. Yang mana di atas baik-baik saja, kecuali saya melewatkan beberapa cara bahwa mereka lebih jahat daripada nodePort ...

Sebagai tindakan pengamanan, akan sangat berguna untuk benar-benar menyertakan flag ke proxy ke MASQUERADE semuanya (bertindak sangat dekat dengan proxy ruang pengguna). Saya pikir itu tidak terlalu sulit untuk dilakukan dan cara yang sangat baik untuk mendiagnosis atau bahkan mundur jika ada masalah (saya sedang memikirkan kasus vxlan).

-------- Pesan asal --------
De : Pemberitahuan Paul [email protected]
Tanggal : 14/08/2015 12:50 (GMT+11:00)
: kubernetes/kubernetes [email protected]
Cc : Mikaël Cluseau [email protected]
Objet : Re: [kubernetes] gunakan iptables untuk proxy daripada userspace
(#3760)

@thockin Saya pikir kita bisa hidup dengan SNAT untuk lalu lintas LB. Pemikiran saya saat ini adalah bahwa Anda harus menentukan kebijakan akses pod sebagai salah satu dari:

defaultnya adalah 'izinkan dari [ruang nama saya]', dalam hal ini paket LB dihapus
'izinkan dari [daftar ruang nama]', atau 'izinkan dari [semua ruang nama di cluster]', lagi-lagi paket LB selalu dihapus
'izinkan dari semua', dalam hal ini kami tidak peduli apakah itu dari LB, simpul lain, atau di mana pun

Jadi kehilangan IP sumber hanya untuk LB sebenarnya tidak terlalu merugikan kami.

Jika kami dapat menjamin bahwa LB mencapai node yang tepat untuk pod layanan, itu akan sangat bagus -- dalam hal ini kami tidak memerlukan SNAT, dan kami dapat menjalankan kapal yang lebih ketat dengan memasukkan daftar putih IP LB saat disediakan di a layanan, dan menjatuhkan lalu lintas sebaliknya.

Mengenai publicIP, saya pikir mereka akan memiliki pertimbangan yang sama dengan nodePort, jadi kita perlu SNAT sampai LB dapat mencapai host yang tepat. Yang mana di atas baik-baik saja, kecuali saya melewatkan beberapa cara bahwa mereka lebih jahat daripada nodePort ...

—
Balas email ini secara langsung atau lihat di GitHub.

@MikaelCluseau itu bukan ide yang buruk - bisakah Anda membuka masalah baru tentang itu secara khusus, jadi saya tidak

Masih TODO: perbaiki jepit rambut, e2e, aktifkan secara default

Hai Tim, maaf karena tidak kembali kepada Anda, tetapi kami memiliki beberapa masalah yang harus ditangani di sini ... Saya akan memilih jepit rambut perbaikan Sabtu depan, saya pikir.

Ini adalah catatan untuk saya sendiri - apakah Anda berencana untuk menangani beberapa dari ini? :)

Ya, tentu, seperti yang saya katakan ketika kami berbicara tentang pengujian e2e. Saya akan membantu, Kubernetes sangat membantu saya, jadi sebaiknya saya menguasainya sebanyak mungkin, dan apa yang terbaik daripada mengambil bug? :-) Jangan ragu untuk menyarankan apa pun dengan prioritas lebih tinggi, tetapi saya pikir jepit rambut cukup bagus untuk permulaan. Itu harus terjadi di kubelet dan memiliki tanda untuk diaktifkan (dinonaktifkan secara default pada awalnya). Saya akan mencoba untuk bekerja 0,5 sampai 1 hari seminggu.

AFAIK satu-satunya bagian yang tersisa untuk dilakukan adalah menjadikannya default yang dapat terjadi (dengan asumsi tidak ada ledakan) beberapa saat setelah v1.1 dan ini memiliki beberapa mil di atasnya.

Whoo!

Pada Kamis, 24 Sep 2015 jam 11:21, Tim Hockin [email protected]
menulis:

AFAIK satu-satunya bagian yang tersisa untuk dilakukan adalah menjadikannya default yang dapat
terjadi (dengan asumsi tidak ada ledakan) beberapa saat setelah v1.1 dan ini memiliki beberapa mil
di atasnya.

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

beberapa waktu setelah v1.1 dan ini memiliki beberapa mil di atasnya.

Aduh. Kami benar-benar mengandalkannya untuk 1,1 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

@bgrieder Anda masih dapat mengaktifkannya melalui parameter.

Ini IN tetapi tidak aktif secara default. Anda dapat ikut serta dengan satu anotasi per
node (dan kube-proxy restart)

Pada Thu, Sep 24, 2015 at 08:27, Bruno G. [email protected] menulis:

beberapa waktu setelah v1.1 dan ini memiliki beberapa mil di atasnya.

Aduh. Kami benar-benar mengandalkannya untuk 1,1 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

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

@thockin @bnprss ok tapi kami berharap versi 1.1 berjalan di Google Container Engine setelah rilis. Saya ingin tahu fleksibilitas seperti apa yang kita miliki untuk 'ikut serta dengan satu anotasi per node'. Bisakah Anda memberi kami beberapa detail tentang proses yang akan terjadi atau mengarahkan kami ke beberapa dokumentasi?

Setelah ditingkatkan ke 1.1:

$ for node in $(kubectl get nodes -o name); do kubectl annotate $node net.beta.kubernetes.io/proxy-mode=iptables; done

Kemudian SSH ke setiap node dan restart kube-proxy (atau reboot setiap node).

Jika Anda ingin lebih berhati-hati, lakukan satu atau dua node lalu coba :)

Saya telah menandai masalah ini sebagai "rilis-catatan" sehingga kami tidak lupa untuk menyertakan loop ajaib itu dalam dokumentasi 1.1 kami.

@RichieEscarez

(Hanya ingin mampir dan mengatakan kami telah menggunakan proxy iptables selama seminggu sekarang dan sepertinya semuanya baik-baik saja!)

@thockin Haruskah ini ditutup, atau dihapus dari tonggak 1.1?

Saya akan memindahkannya ke 1.2 hanya untuk pengaktifan default.

Permintaan maaf untuk pertanyaan yang berpotensi bodoh, tetapi mengenai pelestarian IP klien:

@thockin Saya melihat di masalah lain pada 2 September bahwa "hanya lalu lintas intra-cluster yang mempertahankan IP klien" -- apakah ini masih berlaku untuk alfa 1.2?

Kami meluncurkan cluster 1.2 baru, menerapkan anotasi node, memulai ulang, dan masih melihat 10.244.0.1 sebagai alamat sumber untuk semua permintaan yang dibuat ke pod yang menjalankan HAProxy.

Pada titik ini saya hanya mencoba untuk mencari tahu apakah kami melewatkan pengaturan atau saya mencoba untuk mencapai sesuatu yang belum mungkin -- yaitu melihat alamat IP publik dari klien yang sebenarnya membuat permintaan dari di luar klaster.

Defaultnya masih menggunakan mode userspace. Anda harus mengatur anotasi pada
node (net.beta.kubernetes.io/proxy-mode=iptables) dan restart
proxy. Tapi itu tidak akan mengekspos IP klien eksternal, hanya intra cluster
IP.
Pada 23 Oktober 2015 17:09, "Ben Hundley" [email protected] menulis:

Permintaan maaf untuk pertanyaan yang berpotensi bodoh, tetapi mengenai pelestariannya
dari IP klien:

@thockin https://github.com/thockin Saya melihat di edisi lain pada 2 September
bahwa "hanya lalu lintas intra-cluster yang mempertahankan IP klien" -- apakah ini masih
benar untuk 1.2 alpha?

Kami meluncurkan cluster 1.2 baru, menerapkan anotasi node, memulai ulang,
dan masih melihat 10.244.0.1 sebagai alamat sumber untuk semua permintaan yang dibuat ke a
pod menjalankan HAProxy.

Pada titik ini saya hanya mencoba mencari tahu apakah kita melewatkan a
pengaturan atau saya mencoba untuk mencapai sesuatu yang belum mungkin -- itu
melihat alamat IP publik dari klien yang sebenarnya membuat permintaan
dari luar klaster.

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

Saya dapat mempertahankan IP klien eksternal dengan DNAT lalu lintas eksternal + perutean melalui kube-proxy. Misalnya, jika jaringan layanan Anda adalah 10.42.0.0/16 dan Anda memiliki kube-proxy yang sangat tersedia di IP 10.10.1.1, Anda dapat memiliki aturan iptable berikut:

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

dan rute berikut:

10.42.0.0/16 via 10.10.1.1 dev edge 

Pod di belakang kemudian melihat IP asli:

Oct 24 02:41:39 email-0yr7n mail.info postfix/smtpd[469]: connect from zed.yyy.ru.[94.102.51.96]

Anda harus memiliki jalur pengembalian paket yang benar tentu saja.

Ya, jika DNAT ini ke backend off-machine, Anda membentuk segitiga tanpa
SNAT. Ini adalah masalah mendasar.

Pada Jum, 23 Okt 2015 jam 20:12, Mikaël Cluseau [email protected]
menulis:

Saya dapat mempertahankan IP klien eksternal dengan DNAT lalu lintas eksternal +
perutean melalui kube-proxy. Misalnya, jika jaringan layanan Anda adalah
10.42.0.0/16 dan Anda memiliki kube-proxy yang sangat tersedia di IP
10.10.1.1, Anda dapat memiliki aturan iptable berikut:

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

dan rute berikut:

10.42.0.0/16 melalui tepi pengembang 10.10.1.1

Pod di belakang kemudian melihat IP asli:

24 Okt 02:41:39 email-0yr7n mail.info postfix/smtpd[469]: sambungkan dari zed.yyy.ru.[94.102.51.96]

Anda harus memiliki jalur pengembalian paket yang benar tentu saja.

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

Kedengarannya menarik, ada tautan? :-) Saya mencoba mencari cara untuk memastikan paket akan melewati aturan conntrack yang benar. Saya sedang berpikir untuk mereplikasi status conntrack melalui cluster.

Saya agak bingung dengan apa yang ingin Anda capai.

Cara proxy iptables saat ini seharusnya bekerja adalah bahwa sebuah paket
tiba di sebuah node, kami mendeteksi bahwa itu tidak dihasilkan secara lokal, tandai untuk
SNAT, pilih backend, teruskan ke backend dengan SNAT, backend merespon
kepada kami, kami un-SNAT, un-DNAT, dan menanggapi pengguna eksternal.

Pada Jum, 23 Okt 2015 jam 21:32, Mikaël Cluseau [email protected]
menulis:

Kedengarannya menarik, ada tautan? :-) Saya mencoba mencari cara untuk memastikannya
paket akan melalui aturan conntrack yang benar. Aku sedang memikirkan tentang
mereplikasi status conntrack melalui cluster.

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

Oh, maaf jika saya tidak jelas. Saya sedang berbicara tentang kasus SNAT-kurang. Jika setiap kube-proxy memiliki daftar conntrack yang sama, salah satu dari mereka harus dapat melakukan un-DNAT dengan benar saat container membalas ke pelanggan.

Saya tidak dapat melihat a tanpa replikasi yang tidak melibatkan HA untuk menjaga struktur berbentuk garis seperti ini:

[client] ----- [proxy in HA] ------ [node1]
                           `------- [node2]

Tetapi jika benda berbentuk segitiga bisa bekerja, itu akan membuka lebih banyak kemungkinan.

[client] ----- [proxy1] ------ [node1]
       `------ [proxy2] ------ [node2]

Itu akan lucu tapi sepertinya rumit gila

Pada hari Minggu, 25 Okt 2015 jam 23:20, Mikaël Cluseau [email protected]
menulis:

Oh, maaf jika saya tidak jelas. Saya sedang berbicara tentang kasus SNAT-kurang. Jika
setiap kube-proxy memiliki daftar conntrack yang sama, salah satu dari mereka harus dapat
un-DNAT dengan benar saat penampung membalas ke pelanggan.

Saya tidak dapat melihat a adalah tanpa replikasi yang tidak melibatkan HA untuk menyimpan a
struktur berbentuk garis seperti ini:

[klien] ----- [proksi di HA] ------ [node1]
`------- [simpul2]

Tetapi jika benda berbentuk segitiga bisa bekerja, itu akan membuka lebih banyak kemungkinan.

[klien] ----- [proxy1] ------ [node1]
`------ [proksi2] ------ [simpul2]

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

Cara yang harus saya jelajahi (saya belum dan tidak suka bertanya sebelum penelitian yang tepat tetapi karena subjek sekarang terbuka ...) adalah "Perutean multi-jalur asimetris" yang dapat Anda lihat di sini: http:// conntrack-tools.netfilter.org/manual.html#sync-aa . Dan ya, itu akan sangat menyenangkan :-)

Hal paling sederhana yang mungkin bisa berhasil ...

1. proxy1 menerima koneksi baru melalui iptables hook (saya pikir saya pernah melihatnya di suatu tempat), dan LB-nya memberikannya ke node proxy2.
2. proxy1 mengirimkan permintaan seperti "setup a conntrack entry for {src-ip}:{src-port} -> {pod-ip}:{pod-port}"
3. proxy2 menerima permintaan, mengatur entri conntrack, dan ACK ke proxy1
4. proxy1 biarkan paket melewati aturan DNAT (yang menempatkan entri conntrack di proxy1 juga).
5. ketika pod membalas, host proxy2 akan membatalkan DNAT yang sesuai.
6. ketika klien mengirim paket lain pada aliran ini melalui proxy1, entri conntrack juga melakukan DNAT yang benar.

Dengan cara ini, overhead adalah 2 paket per koneksi baru, dan dibayar kembali dengan cepat dengan menghindari un-SNAT + perutean ekstra (karena jika tidak, paket harus kembali melalui proxy1).

Saya bukan orang jaringan jadi saya mungkin berasumsi terlalu banyak, tapi itu tampaknya masuk akal.

Dalam kasus saya, saya bertujuan untuk membuat aturan firewall, per layanan NodePort.

Sepertinya saya dapat menambahkan aturan ALLOW IP / DROP semua yang lain dalam rantai INPUT, seperti:

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $CONTAINER_PORT -j DROP

Untuk menerapkan aturan ini, apa yang saya bayangkan adalah menggunakan anotasi pada layanan NodePort. Anotasi akan menampung IP yang masuk daftar putih.

Karena saya bisa menunggu sedikit agar aturan ini diterapkan, saya membayangkan tugas cron yang cermat pada setiap antek yang masuk dan memperbarui rantai INPUT antek dari semua anotasi Layanan.

Apakah ada sesuatu yang dapat menyebabkan masalah di sini? Apakah saya gila?

@thockin memiliki pandangan yang lebih baik daripada saya, tetapi saya tidak akan menggunakan anotasi untuk ini. Saya pikir keamanan ortogonal dan harus dikesampingkan sistem, atau mungkin plugin jaringan/proxy. Jika Anda memiliki Kubernetes, Anda memiliki etcd, jadi Anda cukup menyimpan set aturan dalam kunci dan memperbarui dengan etcdctl watch/exec:

# while true; do etcdctl watch "/iptables/$(hostname)" && etcdctl get /iptables/$(hostname) |iptables-restore --noflush; done &
# iptables -F my-filter
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination      
# ~nwrk/go/bin/etcdctl set /iptables/$(hostname) >/dev/null <<EOF
*filter
:my-filter -
-A my-filter -j ACCEPT -s 1.2.3.4 -p tcp --dport 80
-A my-filter -j DROP -p tcp --dport 80
COMMIT
EOF
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       1.2.3.4              0.0.0.0/0            tcp dpt:80
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

Saya pikir Anda ingin #14505

Pada hari Senin, 26 Oktober 2015 jam 08:53, Ben Hundley [email protected]
menulis:

Dalam kasus saya, saya bertujuan untuk membuat aturan firewall, per layanan NodePort.

Sepertinya saya dapat menambahkan ALLOW IP / DROP semua aturan sederhana di
rantai INPUT, seperti:

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $CONTAINER_PORT -j DROP

Untuk menerapkan aturan ini, apa yang saya bayangkan adalah menggunakan anotasi pada
layanan NodePort. Anotasi akan menampung IP yang masuk daftar putih.

Karena saya bisa menunggu sebentar agar aturan ini diterapkan, saya membayangkannya sebentar
tugas cron pada setiap antek yang datang dan memperbarui INPUT antek
rantai dari semua anotasi Layanan.

Apakah ada sesuatu yang dapat menyebabkan masalah di sini? Apakah saya gila?

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

Itu adalah pendekatan awal, dengan kelompok keamanan yang melekat pada penyeimbang beban. Saya baru saja mencapai batas untuk pendengar per antarmuka jaringan cukup cepat di AWS, dan mengalami beberapa logika berbulu mencoba menyebarkan aturan firewall di beberapa SG dan beberapa ELB untuk satu cluster kube.

Untungnya kami menemukan solusi yang lebih baik yang tidak melibatkan bermain-main dengan iptables.

Jika Anda baru saja bergabung, izinkan saya untuk meringkasnya. Semua masalah tentang ketidakmampuan untuk mendapatkan ip klien digabungkan ke dalam masalah ini, namun solusi yang diusulkan (dan diimplementasikan) tidak menyelesaikannya. Saat ini Anda tidak memiliki cara untuk mengakses ip klien. Ha.

@ shaylev2 tidak ada cara yang baik saat ini untuk mendapatkan IP klien saat memantul melalui cloud LB dan ke nodePort. Setelah cloud LB menyusul, saya akan langsung melakukannya. Tapi ini TIDAK mempertahankan IP klien di dalam cluster

Tapi ini TIDAK mempertahankan IP klien di dalam cluster

Itu tergantung pada bagaimana jaringan cluster diatur; misalnya, itu tidak berfungsi dengan benar di OpenShift saat ini, karena aturan iptables tidak dijalankan pada lalu lintas internal OVS. Jadi paket-paket akan di-DNAT masuk ke titik akhir layanan, tetapi karena IP sumbernya adalah cluster-internal, responsnya akan tetap berada di dalam OVS, sehingga tidak mengenai iptables lagi, sehingga DNAT-nya tidak dibalik, jadi pod klien tidak mengenali paket. Saat ini, solusi paling sederhana untuk ini adalah dengan sepenuhnya menyamarkan paket yang masuk ke titik akhir, memaksanya untuk terpental keluar dari OVS lagi saat keluar. (Saya sedang mencari cara untuk mengatasi ini.)

Apakah OVS memiliki gagasan VIP secara internal? Anda hanya bisa menyingkirkan
kube-proxy (lih opencontrail)

Pada Jumat, 20 Nov 2015 jam 07.09, Dan Winship [email protected]
menulis:

Tapi ini TIDAK mempertahankan IP klien di dalam cluster

Itu tergantung pada bagaimana jaringan cluster diatur; misalnya tidak
bekerja tepat di OpenShift saat ini, karena aturan iptables tidak dijalankan
pada lalu lintas internal OVS. Jadi paket-paket itu akan di-DNAT masuk ke layanan
titik akhir, tetapi karena IP sumber adalah cluster-internal, responsnya akan
tetap dalam OVS, sehingga tidak mengenai iptables lagi, sehingga DNAT tidak
dibalik, sehingga pod klien tidak mengenali paket. Pada
saat ini, solusi paling sederhana untuk ini adalah dengan sepenuhnya menyamarkan paket
masuk ke titik akhir, memaksa mereka untuk terpental keluar dari OVS lagi pada
jalan keluar. (Saya sedang mencari cara untuk mengatasi ini.)

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

Kami telah berbicara tentang melakukan pada dasarnya setara dengan proxy-iptables-murni sepenuhnya di dalam OVS, tetapi itu membutuhkan dukungan conntrack OVS, yang membutuhkan kernel yang sangat baru, yang belum ingin kami andalkan. Itu mungkin rencana jangka panjangnya.

(Untuk saat ini sepertinya kita dapat membuatnya bekerja dengan menambahkan hop ekstra gratis dari OVS untuk paket dengan port IP + sumber yang cocok dengan titik akhir layanan yang diketahui yang berasal dari antarmuka kontainer; node kemudian mungkin akan menghapus DNA-nya , dan kemudian memantulkannya kembali ke OVS di mana ia dapat dikirimkan kembali ke pod klien dengan benar.)

Saya berharap untuk menulis dokumen tentang abstraksi Layanan VIP dan membuatnya
jelas bahwa itu adalah abstraksi yang dapat diganti (dan harus dalam beberapa)
kasus).

Pada Senin, 23 November 2015 pukul 06:54, Dan Winship [email protected]
menulis:

Kami telah berbicara tentang melakukan pada dasarnya setara dengan
pure-iptables-proxy sepenuhnya di dalam OVS, tetapi itu membutuhkan koneksi OVS
dukungan, yang membutuhkan kernel yang sangat baru, yang tidak ingin kita andalkan
belum. Itu mungkin rencana jangka panjangnya.

(Untuk saat ini sepertinya kita bisa membuatnya bekerja dengan menambahkan ekstra serampangan
keluar dari OVS untuk paket dengan IP sumber + port yang cocok dengan layanan yang dikenal
titik akhir yang berasal dari antarmuka kontainer; node kemudian akan
mungkin un-DNAT itu, dan kemudian bangkit kembali ke OVS di mana ia bisa mendapatkannya
dikirim kembali ke pod klien dengan benar.)

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

Meskipun iptables/nftables akan menyelesaikan kasus penggunaan penyeimbangan beban TCP dan UDP, saya pribadi berpikir IPVS https://github.com/kubernetes/kubernetes/issues/17470 akan jauh lebih cocok karena dibuat khusus untuk penyeimbangan beban (baca: perubahan/pemeliharaan yang lebih sedikit untuk tim k8s), menawarkan serangkaian algoritme penyeimbangan beban yang lebih kaya, telah membuktikan stabilitas pada kecepatan mendekati garis, dan juga memiliki perpustakaan golang yang siap untuk memanipulasi aturan.

@thockin , yang lain, sesuai https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 , saya melakukan anotasi, tetapi seperti yang disebutkan dengan benar, IP klien eksternal masih belum terlihat oleh aplikasi yang duduk di wadah .

Bagaimana mencapai ini yaitu mendapatkan IP klien eksternal? Dalam pengaturan saya, tidak ada LB eksternal, layanan diekspos sebagai nodeport dan klien membuat koneksi TCP (bukan http/ Websocket) biasa ke aplikasi kemas saya.

@ashishvyas versi kube-proxy apa yang Anda jalankan?

Saya menjalankan v1.1.3

Ikuti petunjuk di https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584 dan https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 tetapi alih-alih menggunakan anotasi bernama net.beta.kubernetes.io/proxy-mode , gunakan anotasi bernama net.experimental.kubernetes.io/proxy-mode .

for node in $(kubectl get nodes -o name); do
  kubectl annotate $node net.experimental.kubernetes.io/proxy-mode=iptables;
done

Anda akan melihat pernyataan log di awal startup kube-proxy seperti 'Menemukan anotasi eksperimental' dan 'Anotasi memungkinkan iptables proxy'

Rilis pertama yang dibuat oleh https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16 adalah 1.1.4 jadi net.beta.kubernetes.io/proxy-mode tidak berfungsi untuk banyak orang. Anda bukan orang pertama yang mengalami hal ini.

Karena cara kerja proxy, kami kehilangan IP klien saat masuk
pelabuhan simpul. Saya tahu ini tidak hebat. Sangat banyak yang ada di pikiran saya bagaimana caranya
perbaiki ini dengan benar, tetapi sebagian besar bermuara pada kemampuan
load-balancer (atau cara lain dimana lalu lintas tiba di sebuah node, seperti:
sebagai DNS-RR)

Pada Rabu, 13 Januari 2016 pukul 10:25, Mike Danese [email protected]
menulis:

Ikuti petunjuk di #3760 (komentar)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584
dan #3760 (komentar)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158
tetapi alih-alih menggunakan anotasi bernama
net.beta.kubernetes.io/proxy-mode, gunakan anotasi bernama
net.experimental.kubernetes.io/proxy-mode.

untuk simpul di $(kubectl get node -o name); melakukan
kubectl membubuhi keterangan $node net.experimental.kubernetes.io/proxy-mode=iptables;
selesai

Anda akan melihat pernyataan log di awal kube-proxy startup
seperti 'Menemukan anotasi eksperimental' dan 'Anotasi memungkinkan proxy iptables'

Rilis pertama yang da9a9a9
https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16
dibuat menjadi adalah 1.1.4. Anda bukan orang pertama yang mengalami hal ini.

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

@thockin , solusi apa pun untuk sementara mengatasi ini mungkin sekarang? Jika ya, saya akan merekomendasikan memberikan langkah-langkah terperinci untuk saya dan orang lain di utas ini akan membantu.

Tidak, saat ini tidak ada solusi nyata. Masalahnya datang ke
fakta bahwa setiap kube-proxy mungkin memilih backend pada node yang berbeda.
Meneruskan lalu lintas dengan IP klien asli akan memiliki node lain
merespon langsung yang jelas tidak akan berhasil.

"Perbaikan" adalah _only_ mengirim lalu lintas untuk Layanan S ke node yang memiliki
setidaknya 1 backend untuk S _and_ untuk mengirim lalu lintas sebanding dengan berapa banyak
backend yang dimiliki setiap node. Kube-proxy kemudian dapat memilih backend lokal
khusus.

Pertimbangkan 2 node dan 3 backend. Satu simpul pasti berakhir dengan 2
backend. Apa pun rute lalu lintas harus mengirim 2x lebih banyak ke satu node daripada itu
lakukan ke node lain. Kami hanya belum menangani masalah itu - tidak satupun dari
penyeimbang beban cloud mendukung ini, jadi ini agak spekulatif dan
oleh karena itu sangat beresiko untuk mulai dikerjakan.

Pada Rabu, 13 Januari 2016 pukul 12:17, Ashish Vyas [email protected]
menulis:

@thockin https://github.com/thockin , solusi apa pun untuk sementara
alamat ini mungkin sekarang? Jika ya, saya akan merekomendasikan menyediakan
langkah-langkah terperinci untuk saya dan orang lain di utas ini akan membantu.

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

@mikedanese ,

$ sudo docker tarik gcr.io/google_containers/ hyperkube:v1.1.4
Menarik repositori gcr.io/google_containers/hyperkube
Tag v1.1.4 tidak ditemukan di repositori gcr.io/google_containers/hyperkube
$ sudo docker tarik gcr.io/google_containers/ hyperkube:v1.1.3
v1.1.3: Menarik dari google_containers/hyperkube
Intisari: sha256:004dde049951a4004d99e12846e1fc7274fdc5855752d50288e3be4748778ca2
Status: Gambar terbaru untuk gcr.io/google_containers/ hyperkube:v1.1.3

@thockin Mohon maaf atas tanggapan yang lama, saya ingin membahas kedua metode yang kami coba selesaikan ini sehingga orang lain dapat memahami tantangan yang kami hadapi dengan keduanya.

Sebagai sedikit latar belakang, aplikasi utama kami adalah platform DNS pintar berkinerja sangat tinggi (yaitu membutuhkan UDP dan perlu melakukan setidaknya 100k+ permintaan/dtk per pod), dan aplikasi pendukungnya dalam proxy SNI yang perlu melihat klien secara nyata Alamat IP (ini adalah penghenti acara bagi kami). Kami tidak ingin menggunakan pendekatan jaringan yang berbeda untuk aplikasi yang berbeda, jadi kami memutuskan untuk menstandarisasi metode jaringan tunggal untuk semua, dan kami memilih untuk menggunakan IPVS karena alasan yang saya sebutkan di atas (performa/stabilitas/fleksibilitas/tujuan membangun SLB) , tetapi Anda mungkin dapat meretas sesuatu bersama-sama hanya dengan menggunakan iptables di sepanjang baris yang sama ini juga. Kami menggunakan vxlan (cepat, mudah, bekerja antar situs) tetapi kedua metode ini juga harus bekerja dengan GRE/VXLAN dengan OVS atau dengan jaringan host Layer 2 standar juga (dengan asumsi semua host Anda berada di jaringan L2 yang sama).

Kami mendistribusikan lalu lintas pengguna akhir yang masuk menggunakan campuran anycast dan DNS, tergantung pada persyaratan kecepatan failover atau apa pun yang paling sesuai untuk jenis layanan tertentu, jadi kami memiliki distribusi lalu lintas pengguna akhir yang cukup merata yang masuk ke node kami, tetapi masalah seperti yang Anda tunjukkan, kemudian mendapatkan distribusi lalu lintas yang merata di seluruh pod, terlepas dari lokasi pod. Masalah lainnya adalah memastikan layanan yang berbicara dengan layanan lain seimbang secara efektif.

Kami mencoba dua model untuk mengatasi hal ini:

Metode pertama yang kami coba adalah 2 lapis VIP. VIP Eksternal (1 per layanan), yang mendistribusikan lalu lintas di seluruh node (berdasarkan jumlah pod untuk layanan tersebut di node), dan kemudian VIP Internal (yang berjalan di node dengan pod), yang mendistribusikan beban di dalam node (biasanya merata di seluruh polong). Keterbatasan model ini adalah bahwa node yang menjalankan VIP eksternal diperlukan untuk menjalankan dua ruang nama jaringan yang berbeda, atau menjalankan node fisik mereka sendiri. Hal yang menyenangkan dengan IPVS dalam mode DSR (pengembalian server langsung) adalah bahwa ia tidak perlu melihat lalu lintas kembali, lalu lintas berjalan:

Consumer >> (over L3) >> External VIP node >> (1) >> Internal VIP node >> (2) >> Container >> (any which way you want) >> Consumer

(1) IPVS (dalam mode DSR) pada host dengan VIP eksternal memilih _node_ untuk mengirim lalu lintas ke ("server nyata" dalam istilah IPVS), dan hanya mengubah alamat MAC DST dari paket (yaitu paket IP tiba tidak berubah di simpul k8s). Ini memuat keseimbangan di seluruh node berdasarkan jumlah pod yang menjalankan layanan itu di node.
(2) IPVS (juga dalam mode DSR) pada node k8s, beban menyeimbangkan lalu lintas di seluruh pod (melalui veth ke node). Balasan dari wadah (TCP dan UDP) langsung kembali ke konsumen layanan.

Keuntungan dari model ini, adalah sangat mudah untuk dijalankan dan aturannya sangat mudah untuk dikelola. Kelemahan dari model ini adalah ia memusatkan semua permintaan layanan kami (tetapi bukan balasan) melalui sejumlah node yang menjalankan VIP Eksternal. Kami menyukai "shared-nothing", jadi, masukkan versi 2:

Model kedua yang sekarang menghibur adalah satu lapisan VIP dengan konfigurasi IPVS dan iptables yang lebih cerdas.

Consumer >> Any node/local node >> (1) >> Container >> (any which way you want) >> Consumer
atau, mungkin pergi ke node lain:
Consumer >> Any node/local node >> (1) >> Remote Node >> (2) >> Container >> (any which way you want) >> Consumer

(1) Lalu lintas mencapai VIP Utama, lalu lintas diseimbangkan beban di semua pod dalam cluster.
(2) Lalu lintas mencapai VIP Sekunder, lalu lintas hanya diseimbangkan beban di semua pod lokal. VIP sekunder ini hanya digunakan untuk lalu lintas yang masuk dari host lain di jaringan (ini adalah FWMARK VIP). Kami menandai lalu lintas yang datang di antarmuka eksternal apa pun dengan FWMARK=1234, dan itu memaksa lalu lintas untuk pergi ke kumpulan aturan yang berbeda, yang mencegah loop antar node.

VIP utama memiliki daftar pod lokal dan host jarak jauh dengan pod (dengan bobot 100 untuk setiap pod lokal, dan 100 * jumlah pod untuk node jarak jauh). Jadi misalnya jika 3 pod berjalan secara lokal di nodeA, dan ada dua pod yang berjalan di nodeB, maka aturan di nodeA akan terlihat seperti ini:

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> interfaceip.of.nodeB:80 Route 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod3.on.nodeA.ip:80 Route 100 0 0

Namun pada nodeB, konfigurasi IPVS akan terlihat sedikit berbeda karena hanya memiliki dua pod lokal, dan tiga pod jarak jauh pada nodeA:

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0
-> interfaceip.of.nodeA:80 Route 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0

Cara lain adalah dengan mengganti FWMARK, dan menggunakan iptables ke FWMARK apa pun di antarmuka veth+ (pencocokan karakter pengganti) dan membuat kecocokan FWMARK hanya digunakan untuk penyeimbangan beban lokal.

Karena tidak ada NAT yang terlibat di sini, Anda perlu menambahkan IP SVC_XXX_YYY di lingkungan ke antarmuka loopback atau dummy ketika Anda memulai setiap pod, tetapi Anda mungkin juga dapat mengubah VIP IPVS untuk melakukan DNAT juga, saya tidak mengerti mengapa itu tidak berhasil.

Hasil akhirnya adalah jaringan yang paling langsung, tanpa perlu memusatkan pemrosesan/perutean permintaan sehingga skalanya jauh lebih baik. Kelemahannya adalah beberapa kecerdasan ekstra saat membuat aturan IPVS. Kami menggunakan sedikit daemon (golang) untuk melakukan semua ini, tetapi saya akan mempertimbangkan untuk menulis modul k8s untuk ini jika saya punya waktu dan ada cukup minat.

Saya terlambat memahami masalah ini, dan mungkin belum membaca jejak lengkapnya dengan cukup detail, tetapi untuk berjaga-jaga jika ini membantu: Jika saya telah memahami posting @qoke di atas maka mereka ingin menggunakan VIP, bukan port simpul . Salah satu masalah yang diangkat sebelumnya di utas adalah IP sumber tidak dipertahankan saat menggunakan iptables kubeproxy. Namun, itu dipertahankan jika Anda menggunakan layanan VIP dan bukan fitur port simpul yang saya yakini. (Ngomong-ngomong, seperti yang saya katakan, saya belum benar-benar membaca jejak lengkapnya, jadi jika komentar ini jelas atau tidak membantu, abaikan saja! Saya akan mencoba meluangkan waktu untuk membacanya secara mendalam minggu depan ketika saya kembali dari liburan.)

@lxpollitt Benar, IP sumber dipertahankan saat menggunakan IPVS, namun perlu diingat bahwa dengan metode ini kami harus melakukan semua jaringan sendiri, karena konfigurasi IPVS tidak didukung oleh kube-proxy. Anda juga dapat menyimpan IP sumber dengan iptables juga, namun Anda memerlukan dua lapisan DNAT IPtables sehingga Anda dapat "menghapus nat" lalu lintas dalam perjalanan kembali

Di sisi saya, dengan flannel (dalam mode vxlan) mengelola jaringan kontainer saya, saya menggunakan kube-proxy (dalam mode iptables dan tidak menyamar) + flanel di namespace di node perutean saya. Permintaan eksternal di-DNAT ke IP layanan dan kemudian diteruskan melalui namespace dengan kube-proxy. Saya belum melakukan pengujian cluster router aktif/aktif, tetapi pengaturan ini memungkinkan saya untuk menyimpan IP eksternal. Saya menyebutkannya FWIW, tetapi saya mengerti itu bukan "jaringan paling langsung".

Saya mengerti bahwa jika kube-proxy dapat mengelolanya akan menyenangkan, tetapi mengingat kebutuhan spesifik Anda dan terutama fakta bahwa penyeimbangan beban sudah berada di luar kube-proxy, bukankah masuk akal untuk mengkodekan manajer aturan iptables pelanggan menonton status cluster kubernetes dan menyiapkan aturan untuk DNAT VIP hanya untuk pod host yang sedang berjalan? Ini juga bisa menjadi mode untuk kube-proxy, seperti... yah.. Saya tidak pandai menyebut nama... --proxy-mode=iptables-to-node-pods-only.

Terima kasih untuk penulisan rinci. Solusi Anda menarik, dan saya menghabiskan
banyak waktu hari ini untuk memikirkannya. Sayangnya kamu sudah
menyeberang ke wilayah yang sangat spesifik yang tidak bekerja dalam arti umum.
Awan seperti GCE tidak dapat menggunakan mode gateway IPVS karena dirutekan
jaringan. Bahkan jika gateway berfungsi, itu tidak mendukung pemetaan ulang port,
yang dilakukan Kubernetes, jadi itu hanya berlaku jika port layanan == target
Pelabuhan.

Tantangan dengan inti kubernetes adalah menemukan cara untuk menangani
semacam situasi secara umum atau untuk menyingkir dan memberdayakan Anda untuk
mengaturnya sendiri. Mungkin kita bisa melakukan sesuatu dengan ipvs encap mode,
tapi saya tidak tahu implikasi kinerjanya.

Pada Kamis, 14 Januari 2016 jam 3:37 pagi, qoke [email protected] menulis:

@thockin https://github.com/thockin Mohon maaf atas tanggapan yang lama, saya
ingin membahas kedua metode yang kami coba selesaikan agar orang lain bisa
memahami tantangan yang kami hadapi dengan keduanya.

Sebagai sedikit latar belakang, aplikasi utama kami adalah kinerja yang sangat tinggi
platform DNS pintar (yaitu membutuhkan UDP dan perlu melakukan setidaknya 100rb+
permintaan/detik per pod), dan aplikasi pendukungnya dalam proxy SNI
yang perlu melihat alamat IP asli klien (ini adalah penghenti acara untuk
kita). Kami tidak ingin menggunakan pendekatan jaringan yang berbeda untuk yang berbeda
aplikasi, jadi kami memutuskan untuk menstandarisasi pada metode jaringan tunggal untuk
semua, dan kami memilih untuk menggunakan IPVS karena alasan yang saya sebutkan di atas
(performa/stabilitas/fleksibilitas/tujuan membangun SLB), tetapi Anda bisa
mungkin meretas sesuatu bersama-sama hanya menggunakan iptables di sepanjang baris yang sama ini
juga. Kami menggunakan vxlan (cepat, mudah, berfungsi antar situs) tetapi keduanya
metode juga harus bekerja dengan GRE/VXLAN dengan OVS atau dengan Layer 2 standar
jaringan host juga (dengan asumsi semua host Anda berada di jaringan L2 yang sama).

Kami mendistribusikan lalu lintas pengguna akhir yang masuk menggunakan campuran anycast dan
DNS, tergantung pada persyaratan kecepatan failover atau apa pun yang paling cocok untuk
jenis layanan tertentu, jadi kami memiliki distribusi yang cukup merata dari
lalu lintas pengguna akhir masuk ke node kami, tetapi masalahnya seperti yang Anda tunjukkan,
kemudian mendapatkan distribusi lalu lintas yang merata di seluruh pod, terlepas dari
lokasi polong. Masalah lainnya adalah memastikan layanan berbicara dengan yang lain
layanan adalah beban seimbang secara efektif.

Kami mencoba dua model untuk mengatasi hal ini:

Metode pertama yang kami coba adalah 2 lapis VIP. VIP Eksternal (1 per
service), yang mendistribusikan lalu lintas di seluruh node (berdasarkan jumlah pod untuk
layanan itu di node), dan kemudian VIP internal (yang berjalan di node
dengan pod), yang mendistribusikan beban di dalam node (biasanya merata
di seluruh polong). Keterbatasan model ini adalah bahwa node yang menjalankan eksternal
VIP diperlukan untuk menjalankan dua ruang nama jaringan yang berbeda, atau menjalankannya sendiri
node fisik. Hal yang menyenangkan dengan IPVS dalam mode DSR (pengembalian server langsung)
mode adalah tidak perlu melihat lalu lintas kembali, lalu lintas berjalan:

Konsumen >> (di atas L3) >> Node VIP Eksternal >> (1) >> Node VIP Internal >>
(2) >> Wadah >> (apa pun yang Anda inginkan) >> Konsumen

(1) IPVS (dalam mode DSR) pada host dengan VIP eksternal memilih _node_ untuk
mengirim lalu lintas ke ("server nyata" dalam istilah IPVS), dan hanya mengubah DST MAC
alamat paket (yaitu paket IP tiba tidak berubah pada node k8s). Ini memuat
menyeimbangkan seluruh node berdasarkan jumlah pod yang menjalankan layanan tersebut
simpul.
(2) IPVS (juga dalam mode DSR) pada simpul k8s, beban menyeimbangkan lalu lintas di seluruh
pod (melalui veth ke node). Balasan dari wadah (TCP dan UDP) pergi
langsung kembali ke konsumen layanan.

Keuntungan dari model ini, apakah sangat mudah untuk memulai dan
ruleset sangat mudah untuk dikelola. Kelemahan dari model ini adalah itu
memusatkan semua permintaan layanan kami (tetapi bukan balasan) melalui a
jumlah node yang menjalankan VIP Eksternal. Kami suka "tidak berbagi", jadi,
masukkan versi 2:

Model kedua yang sekarang menghibur adalah satu lapisan VIP dengan
konfigurasi IPVS dan iptables yang lebih cerdas.

Konsumen >> Setiap node/node lokal >> (1) >> Container >> (ke mana pun Anda
inginkan) >> Konsumen
atau, mungkin pergi ke node lain:
Konsumen >> Setiap node/node lokal >> (1) >> Remote Node >> (2) >> Container

(apa pun yang Anda inginkan) >> Konsumen

(1) Lalu lintas mencapai VIP Utama, lalu lintas diseimbangkan di semua pod di
cluster.
(2) Lalu lintas mencapai VIP Sekunder, lalu lintas hanya diseimbangkan beban di semua
polong lokal. VIP sekunder ini hanya digunakan untuk lalu lintas yang datang dari
host lain di jaringan (ini adalah FWMARK VIP). Kami menandai lalu lintas yang masuk
antarmuka eksternal apa pun dengan FWMARK = 1234, dan itu memaksa lalu lintas untuk pergi
ke aturan yang berbeda, yang mencegah loop antara node.

VIP utama memiliki daftar pod lokal dan host jarak jauh dengan pod (dengan
bobotnya adalah 100 untuk setiap pod lokal, dan 100 * jumlah pod untuk
node jarak jauh). Jadi misalnya jika 3 pod berjalan secara lokal di nodeA, dan
ada dua pod yang berjalan di nodeB, aturan di nodeA akan terlihat seperti
ini:

Alamat Lokal Prot: Bendera Penjadwal Port
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persisten 360
-> pod1.on.nodeA.ip:80 Rute 100 0 0
-> pod2.on.nodeA.ip:80 Rute 100 0 0
-> pod2.on.nodeA.ip:80 Rute 100 0 0
-> interfaceip.of.nodeB:80 Rute 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 Rute 100 0 0
-> pod2.on.nodeA.ip:80 Rute 100 0 0
-> pod3.on.nodeA.ip:80 Rute 100 0 0

Namun pada nodeB, konfigurasi IPVS akan terlihat sedikit berbeda karena
hanya memiliki dua pod lokal, dan tiga pod jarak jauh di nodeA:

Alamat Lokal Prot: Bendera Penjadwal Port
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persisten 360
-> pod1.on.nodeB.ip:80 Rute 100 0 0
-> pod2.on.nodeB.ip:80 Rute 100 0 0
-> interfaceip.of.nodeA:80 Rute 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 Rute 100 0 0
-> pod2.on.nodeB.ip:80 Rute 100 0 0

Cara lain adalah dengan mengganti FWMARK, dan menggunakan iptables untuk
FWMARK apa pun di antarmuka veth+ (pencocokan karakter pengganti) dan miliki FWMARK
pertandingan hanya digunakan untuk penyeimbangan beban lokal.

Hasil akhirnya adalah jaringan yang paling langsung, tanpa perlu terpusat
meminta pemrosesan/perutean sehingga skalanya jauh lebih baik. Kelemahannya adalah beberapa
kecerdasan ekstra saat membuat aturan IPVS.

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

Saya pikir mode iptables-to-node-pods-only akan menarik untuk dicoba,
tetapi memiliki banyak riak. Potensi ketidakseimbangan sangat nyata dan
setidaknya pengontrol layanan perlu tahu cara memprogram
penyeimbang beban eksternal.

Pada Kamis, 14 Jan 2016 jam 15:59, Mikaël Cluseau [email protected]
menulis:

Di pihak saya, dengan flanel (dalam mode vxlan) mengelola jaringan kontainer saya, saya
gunakan kube-proxy (dalam mode iptables dan tidak menyamar) + flanel di a
namespace pada node perutean saya. Permintaan eksternal di-DNAT ke layanan
IP dan kemudian diteruskan melalui namespace dengan kube-proxy. saya belum
melakukan pengujian cluster router aktif/aktif, tetapi pengaturan ini memungkinkan saya untuk tetap
IP eksternal. Saya menyebutkannya FWIW, tapi saya mengerti itu bukan yang "paling ."
jaringan langsung".

Saya mengerti bahwa jika kube-proxy bisa mengelolanya, itu akan menyenangkan, tapi
mengingat kebutuhan spesifik Anda dan terutama fakta bahwa penyeimbangan beban
sudah di luar kube-proxy, bukankah masuk akal untuk mengkodekan pelanggan?
iptables-rules manager mengawasi status cluster kubernetes dan menyiapkannya
aturan untuk DNAT VIP hanya untuk pod host yang sedang berjalan? Ini bisa
juga menjadi mode untuk kube-proxy, seperti... yah.. aku tidak pandai
nama... --proxy-mode=iptables-to-node-pods-only.

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

@thockin Maksud Anda jika 2 replika berada di simpul yang sama misalnya? Saya pikir kita bisa menempatkan kasus "memprogram penyeimbang beban eksternal" di luar cakupan kube-proxy, karena ia memiliki banyak instance dan programmer LB eksternal mungkin harus dalam mode "master tunggal". Dengan demikian, mengizinkan mode kube-proxy "iptables-to-node-pods-only" hanyalah yang pertama dari proses 2 langkah.

Saya pikir saya bisa mencoba mengimplementasikan sesuatu seperti itu besok: mode "iptables-to-node-pods-only" di kube-proxy, ditambah contrib/ip-route-elb yang akan memelihara tabel perutean Linux dengan satu rute per layanan , dengan bobot yang tepat untuk setiap node berdasarkan berapa banyak titik akhir yang dimiliki node untuk layanan tertentu.

@thockin Maksud Anda dari 2 replika berada di node yang sama misalnya? Saya pikir kita bisa menempatkan kasus "program the
load-balancer eksternal" di luar cakupan kube-proxy, karena memiliki banyak instance dan LB eksternal
programmer mungkin harus dalam mode "master tunggal". Dengan demikian, mengizinkan mode kube-proxy "iptables-to-node-
pods-only" hanyalah proses pertama dari 2 langkah.

"Hanya proxy ke pod lokal" harus menjadi langkah 2 dari proses. Langkah 1
harus mengubah pengontrol layanan untuk mengirim penyeimbang beban saja
ke Node yang memiliki 1 atau lebih backend untuk Layanan tertentu. Langkah itu
saja MUNGKIN masuk akal, tetapi akan membutuhkan banyak pengujian untuk
pastikan kita melakukannya dengan benar. Saya pikir kami ingin melakukan ini pada akhirnya,
omong-omong.

Setelah selesai, kita dapat berbicara tentang membuat port node lebih memilih lokal
backend jika memungkinkan, tetapi langkah ini membutuhkan lebih banyak kehati-hatian
pikir.. Apakah itu berarti _always_ (yaitu tidak pernah memilih remote
backend jika yang lokal tersedia) atau probabilistik? Haruskah kita melakukannya?
bahwa melalui port node yang sama (node ​​yang berbeda akan menjadi sangat
perilaku yang berbeda) atau apakah kita mengalokasikan port yang berbeda yang digunakan
jika dan hanya jika simpul ini memiliki 1 atau lebih backend? Bagaimana kita menanganinya?
masalah ketidakseimbangan?

Saya pikir saya bisa mencoba mengimplementasikan sesuatu seperti itu besok: mode "iptables-to-node-pods-only" di kube-proxy,
ditambah contrib/ip-route-elb yang akan memelihara tabel perutean Linux dengan satu rute per layanan, dengan bobot yang tepat
untuk setiap node berdasarkan berapa banyak titik akhir yang dimiliki node untuk layanan yang diberikan.

Jika ELB mendukung beban maka itu akan bekerja lebih baik dalam beberapa hal daripada
GCE, yang tidak. Tidak apa-apa, saya hanya tidak berpikir itu mendukung
bobot. Saya tidak berpikir itu bisa menjadi kontribusi, meskipun - itu cantik
bagian mendasar dari sistem.

Pada 16/01/2016 05:19, Tim Hockin menulis:

"Hanya proxy ke pod lokal" harus menjadi langkah 2 dari proses. Langkah 1
harus mengubah pengontrol layanan untuk mengirim penyeimbang beban saja
ke Node yang memiliki 1 atau lebih backend untuk Layanan tertentu. Langkah itu
saja MUNGKIN masuk akal, tetapi akan membutuhkan banyak pengujian untuk
pastikan kita melakukannya dengan benar. Saya pikir kami ingin melakukan ini pada akhirnya,
omong-omong.

Itu masuk akal.

Setelah itu selesai, [...]

Jadi mari kita lihat setelah selesai :-)

Jika ELB mendukung beban maka itu akan bekerja lebih baik dalam beberapa hal daripada
GCE, yang tidak. Tidak apa-apa, saya hanya tidak berpikir itu mendukung
bobot.

Karena itu dari manual dan Anda mungkin memiliki lebih dari 10x my
pengalaman dalam jaringan semacam ini, saya harus benar-benar mengabaikan tangkapan.
Pria ip-route mengatakan ini:

           nexthop NEXTHOP
                  the nexthop of a multipath route.  NEXTHOP is a 

nilai kompleks dengan sintaksnya sendiri mirip dengan daftar argumen tingkat atas:

                          via [ FAMILY ] ADDRESS - is the nexthop 

router.

                          dev NAME - is the output device.

                          weight NUMBER - is a weight for this 

elemen rute multipath yang mencerminkan bandwidth atau kualitas relatifnya.

Saya tidak berpikir itu bisa menjadi kontribusi, meskipun - itu cantik
bagian mendasar dari sistem.

Karena "E" adalah singkatan dari "eksternal", saya merasa itu bisa dimulai dari sana,
setidaknya untuk mendapatkan beberapa kode untuk mendukung ide.

Pada Jum, 15 Jan 2016 jam 14:55, Mikaël Cluseau
[email protected] menulis:

Pada 16/01/2016 05:19, Tim Hockin menulis:

"Hanya proxy ke pod lokal" harus menjadi langkah 2 dari proses. Langkah 1
harus mengubah pengontrol layanan untuk mengirim penyeimbang beban saja
ke Node yang memiliki 1 atau lebih backend untuk Layanan tertentu. Langkah itu
saja MUNGKIN masuk akal, tetapi akan membutuhkan banyak pengujian untuk
pastikan kita melakukannya dengan benar. Saya pikir kami ingin melakukan ini pada akhirnya,
omong-omong.

Itu masuk akal.

Saya berpikir lebih banyak tentang ini hari ini, saya tidak berpikir itu akan sangat sulit.
Keras sedang saja.

Setelah itu selesai, [...]

Jadi mari kita lihat setelah selesai :-)

cukup adil, saya hanya ingin tahu di mana serangkaian perubahan akan terjadi :)

Jika ELB mendukung beban maka itu akan bekerja lebih baik dalam beberapa hal daripada
GCE, yang tidak. Tidak apa-apa, saya hanya tidak berpikir itu mendukung
bobot.

Karena itu dari manual dan Anda mungkin memiliki lebih dari 10x my
pengalaman dalam jaringan semacam ini, saya harus benar-benar mengabaikan tangkapan.
Pria ip-route mengatakan ini:

nexthop BERIKUTNYA
nexthop dari rute multipath. BERIKUTNYA adalah
nilai kompleks dengan sintaksnya sendiri mirip dengan daftar argumen tingkat atas:

melalui [ KELUARGA ] ALAMAT - adalah nexthop
router.

dev NAME - adalah perangkat keluaran.

berat NOMOR - adalah berat untuk ini
elemen rute multipath yang mencerminkan bandwidth atau kualitas relatifnya.

Kami tidak benar-benar menggunakan gagasan linux tentang perutean IP. Tak satupun dari
Implementasi LB saya tahu menggunakannya. GCE menggunakan cloud Google
penyeimbang, yang tidak memiliki bobot. Saya tidak tahu apakah Amazon ELB
melakukan.

Saya tidak berpikir itu bisa menjadi kontribusi, meskipun - itu cantik
bagian mendasar dari sistem.

Karena "E" adalah singkatan dari "eksternal", saya merasa itu bisa dimulai dari sana,
setidaknya untuk mendapatkan beberapa kode untuk mendukung ide.

Tentu, kita bisa MULAI dalam berkontribusi :)

Juga, jika Anda ingin mengejar ini, Anda harus membuka 2 bug, seperti:

1) penyeimbang beban untuk Layanan seharusnya hanya menargetkan node yang benar-benar
memiliki backend untuk Layanan itu

2) untuk mempertahankan IP klien di seluruh load-balancer, kube-proxy harus
selalu lebih suka backend lokal jika ada (xref #1)

lalu jelaskan maksud dan arahnya

Pada Jumat, 15 Januari 2016 pukul 17:11, Tim Hockin [email protected] menulis:

Pada Jum, 15 Jan 2016 jam 14:55, Mikaël Cluseau
[email protected] menulis:

Pada 16/01/2016 05:19, Tim Hockin menulis:

"Hanya proxy ke pod lokal" harus menjadi langkah 2 dari proses. Langkah 1
harus mengubah pengontrol layanan untuk mengirim penyeimbang beban saja
ke Node yang memiliki 1 atau lebih backend untuk Layanan tertentu. Langkah itu
saja MUNGKIN masuk akal, tetapi akan membutuhkan banyak pengujian untuk
pastikan kita melakukannya dengan benar. Saya pikir kami ingin melakukan ini pada akhirnya,
omong-omong.

Itu masuk akal.

Saya berpikir lebih banyak tentang ini hari ini, saya tidak berpikir itu akan sangat sulit.
Keras sedang saja.

Setelah itu selesai, [...]

Jadi mari kita lihat setelah selesai :-)

cukup adil, saya hanya ingin tahu di mana serangkaian perubahan akan terjadi :)

Jika ELB mendukung beban maka itu akan bekerja lebih baik dalam beberapa hal daripada
GCE, yang tidak. Tidak apa-apa, saya hanya tidak berpikir itu mendukung
bobot.

Karena itu dari manual dan Anda mungkin memiliki lebih dari 10x my
pengalaman dalam jaringan semacam ini, saya harus benar-benar mengabaikan tangkapan.
Pria ip-route mengatakan ini:

nexthop BERIKUTNYA
nexthop dari rute multipath. BERIKUTNYA adalah
nilai kompleks dengan sintaksnya sendiri mirip dengan daftar argumen tingkat atas:

melalui [ KELUARGA ] ALAMAT - adalah nexthop
router.

dev NAME - adalah perangkat keluaran.

berat NOMOR - adalah berat untuk ini
elemen rute multipath yang mencerminkan bandwidth atau kualitas relatifnya.

Kami tidak benar-benar menggunakan gagasan linux tentang perutean IP. Tak satupun dari
Implementasi LB saya tahu menggunakannya. GCE menggunakan cloud Google
penyeimbang, yang tidak memiliki bobot. Saya tidak tahu apakah Amazon ELB
melakukan.

Saya tidak berpikir itu bisa menjadi kontribusi, meskipun - itu cantik
bagian mendasar dari sistem.

Karena "E" adalah singkatan dari "eksternal", saya merasa itu bisa dimulai dari sana,
setidaknya untuk mendapatkan beberapa kode untuk mendukung ide.

Tentu, kita bisa MULAI dalam berkontribusi :)

Risiko PR tanpa dokumen adalah ke arah yang salah. Dia
jauh lebih mudah untuk meninjau sesuatu sebagai proposal. Aku akan melihatmu
PR ketika saya mendapat kesempatan, segera saya harap.
Pada 15 Jan 2016 19:02, "Mikaël Cluseau" [email protected] menulis:

Apakah boleh membuka permintaan tarik untuk (1) secara langsung dengan nama ini dan beberapa
penjelasan?

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

Sayangnya Anda telah menyeberang ke wilayah yang sangat spesifik yang tidak bekerja dalam arti umum.
Awan seperti GCE tidak dapat menggunakan mode gateway IPVS karena jaringan yang dirutekan. Meskipun gateway bekerja, itu tidak mendukung pemetaan ulang port, seperti yang dilakukan Kubernetes, jadi itu hanya berlaku jika port layanan == port target.

Di sisi gateway, ini berfungsi dengan baik melalui jaringan Layer 3 (kami menggunakan overlay), dan meskipun kami dapat lolos tanpa jaringan overlay, kami membangunnya dengan cara ini karena kami ingin pendekatan yang kami gunakan portabel dan berfungsi di cloud pihak ke-3 (seperti GCE).

Perbaiki batasan dengan mode DSR adalah bahwa port layanan == port target, tetapi ini sebenarnya bukan masalah kecuali Anda memiliki dua aplikasi _dalam wadah yang sama_ yang perlu dijalankan pada port yang sama (kami menghabiskan banyak waktu untuk memikirkan ini, dan dengan asumsi pedoman "1 aplikasi per wadah", kami tidak dapat menemukan satu kasus penggunaan untuk ini). Kami memiliki banyak kontainer yang semuanya berjalan pada node yang sama dengan layanan di dalamnya semua pada port yang sama, dan semua beban seimbang dengan baik. Jika Anda _benar-benar_ perlu memetakan ulang port (saya ingin memahami alasan sebenarnya di balik mengapa), Anda dapat menggunakan mode IPVS NAT alih-alih mode "ROUTE".

Tantangan dengan inti kubernetes adalah menemukan cara untuk menangani situasi Anda secara umum atau untuk keluar dari jalan Anda dan memberdayakan Anda untuk mengaturnya sendiri. Mungkin kita bisa melakukan sesuatu dengan mode encap ipvs, tapi saya tidak tahu implikasi kinerjanya.

Apa yang telah kami lakukan adalah generik yang mungkin kami buat (berfungsi di sini, berfungsi di Amazon, dan saya yakin itu akan berfungsi di GCE ketika kami perlu memperluas), dengan satu-satunya batasan dengan DSR adalah bahwa aplikasi berjalan di pod/kontainer perlu dijalankan pada port yang sama dengan layanan yang setelah banyak diskusi internal, tidak ada yang dapat menemukan skenario di mana ini akan membatasi dari perspektif tumpukan aplikasi E2E.

Sekarang dikatakan, jika Anda menghapus DSR (Mode Rute IPVS) dari persamaan, dan menggunakan "mode NAT" IPVS sebagai gantinya, maka port dapat dipetakan ulang dan Anda masih mendapatkan manfaat dari mendapatkan fitur/kinerja IPVS/dll. Satu-satunya downside adalah bahwa NAT menambahkan beberapa pajak kinerja tetapi (a) mendukung UDP, dan (b) masih secepat kilat dibandingkan dengan solusi ruang pengguna.

@brendandburns @thockin Sebelumnya di utas Anda meminta beberapa angka kinerja. Saya tidak akan menyebut ini sebagai rangkaian tes yang paling komprehensif, tetapi saya berharap HTTP adalah salah satu beban kerja yang lebih umum dalam container, jadi berikut adalah beberapa nomor apache-bench sebagai titik awal:

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

DNAT diaktifkan pada IPVS untuk perbandingan yang adil dengan dua solusi lainnya (ini juga berarti port layanan dapat berbeda dengan port layanan target). Beban kerja kami mungkin tampak agak tidak biasa bagi sebagian orang, tetapi target kinerja kami mungkin tidak berbeda dengan yang lain (yaitu memeras perangkat keras untuk semua yang bisa Anda dapatkan).

Terima kasih!

Saya tidak yakin dari mana ide bahwa kube-proxy tidak melakukan UDP berasal - itu
benar-benar, meskipun mungkin tidak sempurna (tanpa koneksi itu datang
sampai batas waktu).

Penting juga untuk mengklarifikasi iptables (baru) kube-proxy vs ruang pengguna
modus (warisan).

Pada Sabtu, 16 Januari 2016 pukul 21:45, qoke [email protected] menulis:

@thockin https://github.com/thockin Sebelumnya di utas yang Anda minta
beberapa angka kinerja. Saya tidak akan menyebut ini set paling komprehensif
tes, tapi saya berharap HTTP adalah salah satu beban kerja yang lebih umum di
wadah, jadi berikut adalah beberapa nomor bangku apache sebagai titik awal:

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

DNAT diaktifkan pada IPVS untuk perbandingan yang adil dengan dua solusi lainnya
(ini juga berarti port layanan dapat berbeda dengan port layanan target). Kita
beban kerja mungkin tampak agak tidak biasa bagi sebagian orang, tetapi target kinerja kami
mungkin tidak berbeda dengan yang lain (yaitu memeras perangkat keras untuk semua
Anda bisa mendapatkan).

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

Panggilan bagus pada mode baru vs lama - dicatat dan diperbarui.

Juga di sisi UDP, terima kasih atas klarifikasinya; Saya tidak mengetahui bahwa UDP didukung sepenuhnya di kube-proxy sampai sekarang. Ketika kami pertama kali mencoba kube-proxy dengan UDP, kami mendapatkan banyak sekali hang. Tidak yakin mengapa, tetapi kami meningkatkan batas waktu dan masih memiliki masalah. Kami harus menemukan solusi dengan cepat sehingga kami akhirnya mengatasinya dengan IPVS daripada men-debug-nya. Pada saat itu hanya berfungsi untuk beban kerja paket per detik yang cukup rendah (di bawah 1k pps) tetapi kami belum menguji ulang baru-baru ini.

Masalah utama dengan iptables dan layanan UDP tingkat tinggi adalah pengisian tabel conntrack netfilter. Bahkan jika Anda meningkatkan ukuran conntrack menjadi 1 juta, maka beberapa DDoS pengguna akhir yang terinfeksi malware adalah Anda atau mencoba menggunakan Anda untuk serangan amplifikasi DNS dan kemudian tabel conntrack Anda terisi kembali. Secara umum, praktik terbaik untuk server DNS (atau layanan UDP tingkat tinggi apa pun) adalah dengan menonaktifkan conntrack (menggunakan -j NOTRACK dalam tabel mentah), dan jika Anda menonaktifkan conntrack, iptables NAT dan stateful stuff (-m state) rusak.

Selain repo GIT, di mana tempat terbaik untuk mencari sebelum mencoba membuat modul/paket "k8s.io/kubernetes/pkg/proxy/ipvs"? atau apakah ini sebaiknya diserahkan kepada seseorang yang mengetahui basis kode dengan lebih baik?

Juga, jika Anda ingin tolok ukur tertentu dijalankan, beri tahu saya dan saya akan melihat apa yang bisa saya lakukan.

Pada 17/01/2016 08:50, qoke menulis:

Terlepas dari repo GIT, di mana tempat terbaik untuk mencari sebelumnya?
mencoba membuat modul/paket "k8s.io/kubernetes/pkg/proxy/ipvs"?

Saya yakin Anda juga bisa mulai berkontribusi.

FWIW... Saya menggunakan jam tangan list dan toko undeleta untuk membuat toko independen
binay bereaksi terhadap keadaan cluster di
https://github.com/kubernetes/kubernetes/pull/19755. Jika informasi
di dalam
https://github.com/kubernetes/kubernetes/pull/19755/files#diff -0becc97ac222c3f2838fbfe8446d5375R26
cukup, Anda hanya perlu mengubah panggilan beberapa baris di bawah ini
(https://github.com/kubernetes/kubernetes/pull/19755/files#diff-0becc97ac222c3f2838fbfe8446d5375R44).

Harap dicatat bahwa saya hanya mendukung layanan clusterIP di PoC ini.

Sayangnya Anda telah menyeberang ke wilayah yang sangat spesifik yang tidak bekerja dalam arti umum.
Awan seperti GCE tidak dapat menggunakan mode gateway IPVS karena jaringan yang dirutekan. Bahkan jika gateway berhasil, itu tidak
mendukung pemetaan ulang port, yang dilakukan Kubernetes, jadi ini hanya berlaku jika port layanan == port target.

Di sisi gateway, ini berfungsi dengan baik melalui jaringan Layer 3 (kami menggunakan overlay), dan meskipun kami bisa lolos
tanpa jaringan overlay, kami membangunnya dengan cara ini karena kami ingin pendekatan yang kami gunakan portabel dan bekerja di pihak ketiga
awan (seperti GCE).

Saya tidak yakin bagaimana itu bisa bekerja. Rute statis tingkat mesin tidak berfungsi
di GCE. Mungkin saya melewatkan beberapa teknik yang telah Anda terapkan. Saya
dengan bebas mengakui bahwa saya BUKAN ahli dalam hal ini :)

Perbaiki batasannya adalah port layanan == port target, tetapi ini sebenarnya bukan masalah kecuali Anda memiliki dua aplikasi di
wadah yang sama yang perlu dijalankan pada port yang sama (kami menghabiskan banyak waktu untuk memikirkan hal ini, dan mengasumsikan "1 aplikasi"
per container", kami tidak dapat menemukan kasus penggunaan tunggal untuk ini). Kami memiliki banyak container yang semuanya berjalan pada node yang sama
dengan layanan di dalamnya semua pada port yang sama, dan semua beban seimbang baik-baik saja. Singkatnya, pendekatan yang kami gunakan tidak menghentikan Anda
dari menjalankan beberapa layanan pada port yang sama pada node yang sama.

Ini juga berlaku jika Anda memiliki backend yang mengubah versi (mis
transisi antara etcd1 dan etcd2) atau situasi lain di mana
port backend hanya perlu berbeda. Masalahnya adalah
Kubernetes mengizinkannya untuk diekspresikan, jadi kita perlu memastikan orang
benar-benar dapat menggunakannya (atau mencela dan EOL fitur yang
tampaknya tidak mungkin).

Tantangan dengan inti kubernetes adalah menemukan cara untuk menangani situasi Anda secara umum atau untuk keluar dari jalan Anda
dan memberdayakan Anda untuk mengaturnya sendiri. Mungkin kita bisa melakukan sesuatu dengan mode encap ipvs, tapi saya tidak tahu performanya
implikasinya.

Apa yang telah kami lakukan adalah generik yang mungkin kami buat (berfungsi di sini, berfungsi di Amazon, dan saya yakin itu akan berhasil di
GCE ketika kita perlu memperluas), dengan satu-satunya batasan adalah bahwa aplikasi yang berjalan di pod/wadah harus > dijalankan pada port yang sama dengan layanan yang setelah banyak diskusi internal, tidak ada yang dapat menemukan skenario dimana
ini akan membatasi dari perspektif tumpukan aplikasi E2E.

Saya sangat ingin memahami caranya. Apakah Anda memiliki sesuatu yang lebih selangkah demi selangkah?

Juga di sisi UDP, terima kasih atas klarifikasinya; Saya tidak mengetahui bahwa UDP didukung sepenuhnya di kube-proxy sampai sekarang.
Ketika kami pertama kali mencoba kube-proxy dengan UDP, kami mendapatkan banyak sekali hang. Tidak yakin mengapa, tetapi kami meningkatkan batas waktu dan
masih memiliki masalah. Kami harus menemukan solusi dengan cepat sehingga kami akhirnya mengatasinya dengan IPVS daripada men-debug-nya. Pada
waktu itu hanya berfungsi untuk beban kerja paket per detik yang cukup rendah (di bawah 1k pps) tetapi kami belum menguji ulang baru-baru ini.

Masalah utama dengan iptables dan layanan UDP tingkat tinggi adalah pengisian tabel conntrack netfilter. Bahkan jika Anda meningkatkan
ukuran conntrack ke 1 juta, kemudian beberapa pengguna akhir yang terinfeksi malware DDoS Anda atau mencoba menggunakan Anda untuk amplifikasi DNS
menyerang dan kemudian tabel conntrack Anda terisi kembali. Secara umum, praktik terbaik untuk server DNS (atau tingkat tinggi apa pun
Layanan UDP) adalah untuk menonaktifkan conntrack (menggunakan -j NOTRACK di tabel mentah), dan jika Anda menonaktifkan conntrack, iptables NAT dan
hal-hal stateful (-m state) rusak.

Ya, NAT untuk UDP sangat disayangkan. Menemukan non-conntrack
solusi akan bagus, tetapi itu harus berlaku untuk semua
lingkungan atau diparameterisasi oleh platform (yang sulit sendiri
cara).

Terlepas dari repo GIT, di mana tempat terbaik untuk mencari sebelum mencoba membuat a
Modul/paket "k8s.io/kubernetes/pkg/proxy/ipvs"? atau apakah ini sebaiknya diserahkan kepada seseorang yang mengetahui basis kode dengan lebih baik?

Saya membuka masalah github tentang IPVS, tetapi saya menggunakan masquerade (NAT)
mode karena saya tidak bisa membuatnya bekerja di GCE tanpa (dan karena
fitur pemetaan ulang port). Jika pemetaan ulang port memicu yang kurang ideal
mode penyeimbangan, saya mungkin bisa hidup dengan itu dan hanya mendokumentasikannya
Dengan demikian.

Kita harus memindahkan obrolan ini ke sana - itu akan hilang di sini.

Pada 18/01/2016 12:34, Tim Hockin menulis:

Ya, NAT untuk UDP sangat disayangkan. Menemukan non-conntrack
solusi akan bagus, tetapi itu harus berlaku untuk semua
lingkungan atau diparameterisasi oleh platform (yang sulit sendiri
cara).

dapatkah NAT stateless bekerja untuk kasus di mana pasangan (pod, port) memiliki di
kebanyakan satu layanan (banyak pod ke satu layanan)?

Ini akan terlihat seperti ini:

{dari: clientIP:clientPort, ke: externalIP:externalPort} ---[proxy memilih pod acak]---> {from: clientIP:clientPort, ke: podIP:targetPort} ---> [dirutekan melalui host yang tepat ...]

Dalam perjalanan kembali, firewall akan memiliki aturan yang mengatakan sebuah paket {from:
podIP:targetPort , to: any} harus di-SNAT ke {from:
e xternalIP:externalPort , ke: tidak berubah}.

Untuk menyatakannya dalam dialek iptables:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53 --to-source 1.2.3.4

Saya tidak melihat di mana ini tidak berfungsi ketika paket datang dari luar
cluster.

Cara Layanan diekspresikan di Kubernetes memungkinkan satu pod menjadi
digawangi oleh sejumlah Layanan, jadi ini rusak - kami tidak tahu apa
untuk SNAT untuk.

Pada hari Minggu, 17 Januari 2016 pukul 18:13, Mikaël Cluseau [email protected]
menulis:

Pada 18/01/2016 12:34, Tim Hockin menulis:

Ya, NAT untuk UDP sangat disayangkan. Menemukan non-conntrack
solusi akan bagus, tetapi itu harus berlaku untuk semua
lingkungan atau diparameterisasi oleh platform (yang sulit sendiri
cara).

dapatkah NAT stateless bekerja untuk kasus di mana pasangan (pod, port) memiliki di
kebanyakan satu layanan (banyak pod ke satu layanan)?

Ini akan terlihat seperti ini:

{dari: clientIP:clientPort, ke: externalIP:externalPort} ---[proxy memilih
pod acak]---> {dari: clientIP:clientPort, ke: podIP:targetPort} --->
[diarahkan melalui host yang tepat...]

Dalam perjalanan kembali, firewall akan memiliki aturan yang mengatakan sebuah paket {from:
podIP:targetPort , to: any} harus di-SNAT ke {from:
e xternalIP:externalPort , ke: tidak berubah}.

Untuk menyatakannya dalam dialek iptables:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53
--to-source 1.2.3.4

Saya tidak melihat di mana ini tidak berfungsi ketika paket datang dari luar
cluster.

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

Pada 18/01/2016 15:31, Tim Hockin menulis:

Cara Layanan diekspresikan di Kubernetes memungkinkan satu pod
menjadi
digawangi oleh sejumlah Layanan, jadi ini rusak - kami tidak tahu
Apa
untuk SNAT untuk.

Itu sebabnya saya membatasi kasus ini menjadi banyak-ke-satu (kalimat pertama saya :-)).
Saya hanya mencoba menarik garis di sekitar apa yang bisa dilakukan atau tidak.

Tentu, saya hanya memiliki pekerjaan yang tidak menguntungkan untuk menunjukkan mengapa itu bukan
solusi yang cukup umum :(

Pada hari Minggu, 17 Jan 2016 jam 20:34, Mikaël Cluseau [email protected]
menulis:

Pada 18/01/2016 15:31, Tim Hockin menulis:

Cara Layanan diekspresikan di Kubernetes memungkinkan satu pod
menjadi
digawangi oleh sejumlah Layanan, jadi ini rusak - kami tidak tahu
Apa
untuk SNAT untuk.

Itu sebabnya saya membatasi kasus ini menjadi banyak-ke-satu (kalimat pertama saya :-)).
Saya hanya mencoba menarik garis di sekitar apa yang bisa dilakukan atau tidak.

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

Pada 18/01/2016 15:46, Tim Hockin menulis:

Tentu, saya hanya memiliki pekerjaan yang tidak menguntungkan untuk menunjukkan mengapa itu bukan
solusi yang cukup umum :(

Ya ... tapi itu FAQ. Kami juga dapat menempatkan, di suatu tempat, "jika len(layanan)
== 1 { implement stateless } else { implement stateful }". Tapi ini mungkin
terlihat seperti berantakan bagi para pemula. Saya juga bisa menjadi kontrib/elbs/sesuatu...

Itu bahkan bukan sesuatu yang saat ini kami lacak (jumlah Layanan yang
depan pod yang diberikan). Kita bisa, saya kira. Saya tidak menentangnya (bahkan jika itu
tampaknya ceruk). Kedengarannya seperti perubahan besar yang harus dilakukan untuk memilikinya
banyak peringatan. Saya masih ingin memikirkan jawaban yang lebih baik.

Pada hari Minggu, 17 Jan 2016 jam 20:51, Mikaël Cluseau [email protected]
menulis:

Pada 18/01/2016 15:46, Tim Hockin menulis:

Tentu, saya hanya memiliki pekerjaan yang tidak menguntungkan untuk menunjukkan mengapa itu bukan
solusi yang cukup umum :(

Ya ... tapi itu FAQ. Kami juga dapat menempatkan, di suatu tempat, "jika len(layanan)
== 1 { implement stateless } else { implement stateful }". Tapi ini mungkin
terlihat seperti berantakan bagi para pemula. Saya juga bisa menjadi
kontribusi/elb/sesuatu...

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

Pada 18/01/2016 16:07, Tim Hockin menulis:

Itu bahkan bukan sesuatu yang saat ini kami lacak (jumlah Layanan yang
depan pod yang diberikan). Kita bisa, saya kira. Saya tidak menentangnya (bahkan jika itu
tampaknya ceruk). Kedengarannya seperti perubahan besar yang harus dilakukan untuk memilikinya
banyak peringatan. Saya masih ingin memikirkan jawaban yang lebih baik.

Saya setuju, tetapi tidak memiliki ide yang lebih baik untuk saat ini :-(

Bahkan SDN yang dibuat khusus perlu melacak sesuatu yang saya kira. Mungkin
solusi berbasis label seperti MPLS..?

Pada 18/01/2016 16:18, Mikaël Cluseau menulis:

Bahkan SDN yang dibuat khusus perlu melacak sesuatu yang saya kira.
Mungkin solusi berbasis label seperti MPLS..?

Dalam gagasan pelabelan sesuatu... jika kita menetapkan satu IP per layanan + satu
IP per titik akhir (pasangan layanan+pod), dan tambahkan IP titik akhir ini ke
pod, itu harus bekerja sepenuhnya tanpa kewarganegaraan:

``````

• Eksternal ke host:{dari: clientIP:clientPort, ke: externalIP:servicePort} -----[ELB
  memilih satu titik akhir]--------> {dari: clientIP:clientPort, ke:
  endpointServiceIP:podPort} --> rute ke host

• Host ke pod:{from: clientIP:clientPort, ke: endpointServiceIP:podPort} --[standar
  perutean ke wadah]--> {dari: clientIP:clientPort , ke:
  ServiceIP titik akhir

• Pod ke Host:{dari: endpointServiceIP:podPort, ke: clientIP:clientPort}
  --------[perutean standar ke router]-----> {dari:
  endpointServiceIP:podPort, ke: clientIP:clientPort} - Host ke eksternal:{from: endpointServiceIP:podPort, ke: clientIP:clientPort} --------[ELB
  SNAT kembali]------------------> {dari: clientIP:clientPort , ke:
  e xternalIP:servicePort } ```

Sepertinya kita bisa membuat ini berfungsi untuk clusterIP juga.
``````

Saya tidak dapat membuat ini berfungsi di GCE, dan saya tidak yakin tentang AWS - ada
terbatasnya jumlah rute statis yang tersedia.

Saya ingin tahu apakah saya bisa melakukannya dengan membonceng 2 rentang IP secara bersamaan
rute. Banyak IP yang harus dibelanjakan, tapi saya rasa itu hanya penting untuk UDP.
Aku harus mencobanya.

Sunting: Saya mencobanya dan tidak berhasil, tetapi saya kehilangan sesuatu.
Kami harus menambah/menghapus IP dalam wadah sebagai tanggapan atas layanan yang akan datang
dan pergi, tetapi saya tidak dapat membuat IP "ekstra" dalam wadah berfungsi (bisa
ping tetapi bukan TCP atau UDP, tidak yakin mengapa).

Saya harus mencoba lagi kapan-kapan.

Pada hari Minggu, 17 Januari 2016 pukul 22.22, Mikaël Cluseau [email protected]
menulis:

Pada 18/01/2016 16:18, Mikaël Cluseau menulis:

Bahkan SDN yang dibuat khusus perlu melacak sesuatu yang saya kira.
Mungkin solusi berbasis label seperti MPLS..?

Dalam gagasan pelabelan sesuatu... jika kita menetapkan satu IP per layanan + satu
IP per titik akhir (pasangan layanan+pod), dan tambahkan IP titik akhir ini ke
pod, itu harus bekerja sepenuhnya tanpa kewarganegaraan:

``````

• Eksternal ke Host:{from: clientIP:clientPort, ke: externalIP:servicePort}
  -----[ELB
  memilih satu titik akhir]--------> {dari: clientIP:clientPort, ke:
  endpointServiceIP:podPort} --> rute ke host

• Host ke pod:{from: clientIP:clientPort, ke: endpointServiceIP:podPort}
  --[standar
  perutean ke wadah]--> {dari: clientIP:clientPort , ke:
  ServiceIP titik akhir

• Pod ke Host:{dari: endpointServiceIP:podPort, ke: clientIP:clientPort}
  --------[perutean standar ke router]-----> {dari:
  endpointServiceIP:podPort, ke: clientIP:clientPort} - Host ke
  eksternal:{dari: endpointServiceIP:podPort, ke: clientIP:clientPort}
  --------[ELB
  SNAT kembali]------------------> {dari: clientIP:clientPort , ke:
  e xternalIP:servicePort } ```

Sepertinya kita bisa membuat ini berfungsi untuk clusterIP juga.

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

``````

Saya mencoba di pihak saya untuk mendapatkan sesuatu (dengan jaring murni di Host lokal saya
untuk sekarang).

Saya mencoba pendekatan di mana saya memengaruhi rentang IP layanan ke host untuk
kurangi jumlah entri perutean:

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

Tidak ada ping ATM (paket tidak melalui rantai PREROUTING...), dan
perlu tidur. Lebih lanjut tentang ini besok;)

Pada 18/01/2016 18:28, Tim Hockin menulis:

Saya tidak dapat membuat ini berfungsi di GCE, dan saya tidak yakin tentang AWS - ada
terbatasnya jumlah rute statis yang tersedia.

Saya ingin tahu apakah saya bisa melakukannya dengan membonceng 2 rentang IP secara bersamaan
rute. Banyak IP yang harus dibelanjakan, tapi saya rasa itu hanya penting untuk UDP.
Aku harus mencobanya.

Sunting: Saya mencobanya dan tidak berhasil, tetapi saya kehilangan sesuatu.
Kami harus menambah/menghapus IP dalam wadah sebagai tanggapan atas layanan yang akan datang
dan pergi, tetapi saya tidak dapat membuat IP "ekstra" dalam wadah berfungsi (bisa
ping tetapi bukan TCP atau UDP, tidak yakin mengapa).

Saya harus mencoba lagi kapan-kapan.

Saya sedikit lebih jauh, tetapi sesuatu yang seharusnya saya prediksi terjadi.

Saya menyiapkan pod dengan 10.244.2.8/25 sebagai antarmuka utamanya dan 10.244.2.250/25
sebagai antarmuka "dalam layanan". Saya berharap saya bisa mengirim UDP ke
.250 dan mendeteksi tanggapan, untuk SNAT mereka. Tapi tentu saja, jika kliennya
tidak di /25 yang sama (yang tidak bisa) rute default dimulai, yang
berasal dari alamat .8. tcpdump mengonfirmasi bahwa tanggapan berasal dari .8
saat menggunakan UDP.

Saya lagi di tempat di mana saya tidak yakin bagaimana membuatnya bekerja. akan berpikir
lebih di atasnya.

Pada Senin, 18 Januari 2016 pukul 02:59, Mikaël Cluseau [email protected]
menulis:

Saya mencoba di pihak saya untuk mendapatkan sesuatu (dengan jaring murni di Host lokal saya
untuk sekarang).

Saya mencoba pendekatan di mana saya memengaruhi rentang IP layanan ke host untuk
kurangi jumlah entri perutean:

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

Tidak ada ping ATM (paket tidak melalui rantai PREROUTING...), dan
perlu tidur. Lebih lanjut tentang ini besok;)

Pada 18/01/2016 18:28, Tim Hockin menulis:

Saya tidak dapat membuat ini berfungsi di GCE, dan saya tidak yakin tentang AWS - ada
terbatasnya jumlah rute statis yang tersedia.

Saya ingin tahu apakah saya bisa melakukannya dengan membonceng 2 rentang IP bersama-sama dalam a
Lajang
rute. Banyak IP yang harus dibelanjakan, tapi saya rasa itu hanya penting untuk UDP.
Aku harus mencobanya.

Sunting: Saya mencobanya dan tidak bisa membuatnya bekerja, tetapi saya hilang
sesuatu.
Kami harus menambah/menghapus IP dalam wadah sebagai tanggapan atas layanan yang akan datang
dan pergi, tetapi saya tidak dapat membuat IP "ekstra" dalam wadah berfungsi (bisa
ping tetapi bukan TCP atau UDP, tidak yakin mengapa).

Saya harus mencoba lagi kapan-kapan.

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

Saya sadar (melalui Abhishek) bahwa meskipun ini berhasil, kita MASIH harus
trek mengalir di suatu tempat, jadi pada akhirnya tidak stateless.

Pada Senin, 18 Januari 2016 pukul 21:50, Tim Hockin [email protected] menulis:

Saya sedikit lebih jauh, tetapi sesuatu yang seharusnya saya prediksi terjadi.

Saya menyiapkan pod dengan 10.244.2.8/25 sebagai antarmuka utamanya dan
10.244.2.250/25 sebagai antarmuka "dalam layanan". Saya berharap bahwa saya
bisa mengirim UDP ke .250 dan mendeteksi tanggapan, untuk SNAT mereka. Tapi tentu saja,
jika klien tidak dalam /25 yang sama (yang tidak bisa) default
rute dimulai, yang berasal dari alamat .8. tcpdump menegaskan bahwa
tanggapan berasal dari .8 saat menggunakan UDP.

Saya lagi di tempat di mana saya tidak yakin bagaimana membuatnya bekerja. akan berpikir
lebih di atasnya.

Pada Senin, 18 Januari 2016 pukul 02:59, Mikaël Cluseau [email protected]
menulis:

Saya mencoba di pihak saya untuk mendapatkan sesuatu (dengan jaring murni di Host lokal saya
untuk sekarang).

Saya mencoba pendekatan di mana saya memengaruhi rentang IP layanan ke host untuk
kurangi jumlah entri perutean:

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

Tidak ada ping ATM (paket tidak melalui rantai PREROUTING...), dan
perlu tidur. Lebih lanjut tentang ini besok;)

Pada 18/01/2016 18:28, Tim Hockin menulis:

Saya tidak dapat membuat ini berfungsi di GCE, dan saya tidak yakin tentang AWS - ada
terbatasnya jumlah rute statis yang tersedia.

Saya ingin tahu apakah saya bisa melakukannya dengan membonceng 2 rentang IP bersama-sama dalam a
Lajang
rute. Banyak IP yang harus dibelanjakan, tapi saya rasa itu hanya penting untuk UDP.
Aku harus mencobanya.

Sunting: Saya mencobanya dan tidak bisa membuatnya bekerja, tetapi saya hilang
sesuatu.
Kami harus menambah/menghapus IP dalam wadah sebagai tanggapan terhadap layanan
yang akan datang
dan pergi, tetapi saya tidak dapat membuat IP "ekstra" dalam wadah berfungsi (itu
bisa
ping tetapi bukan TCP atau UDP, tidak yakin mengapa).

Saya harus mencoba lagi kapan-kapan.

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

Sangat disayangkan :-( Omong-omong, tidak yakin mengapa. Saya akan mencoba sesuatu dengan MPLS, saya tetap ingin mempelajarinya.

Jika Anda memiliki 2 backend untuk Layanan dan Anda ingin mengirim lebih dari satu
paket, Anda perlu melacak aliran dalam beberapa cara, bukan? Atau apakah kamu?
dengan asumsi aman untuk menyemprotkan paket di backend yang berbeda?

Pada Rabu, 20 Januari 2016 pukul 12:24, Mikaël Cluseau [email protected]
menulis:

Sangat disayangkan :-( tidak yakin mengapa. Saya akan mencoba sesuatu dengan
MPLS kalau begitu, saya tetap ingin mempelajarinya.

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

Saya agak berasumsi bahwa untuk beban kerja UDP, ya. Ini juga dapat menjadi opsional untuk tidak memiliki kewarganegaraan bahkan untuk UDP. @qoke ada komentar tentang ini?

Juga, kita dapat menggunakan hal-hal seperti hashing IP klien untuk membuat aliran lebih stabil sementara tetap seimbang (saya tidak tahu apakah kita dapat menyebutnya "semacam pelacakan" :-)).

@MikaelCluseau kami menggunakan perilaku IPVS default, yang melakukan "kelengketan" UDP yang sangat ringan...

Untuk menjadwalkan datagram UDP, penyeimbang beban IPVS mencatat penjadwalan datagram UDP dengan batas waktu yang dapat dikonfigurasi, dan batas waktu UDP default adalah 300 detik. Sebelum batas waktu koneksi UDP, semua datagram UDP dari soket yang sama (protokol, alamat ip, dan port) akan diarahkan ke server yang sama.

-- Dikutip dari http://kb.linuxvirtualserver.org/wiki/IPVS

Tentu saja, ini hanya berfungsi jika Anda memiliki banyak klien yang berbicara dengan satu layanan, atau satu klien dengan berbagai port sumber. Jika Anda memiliki satu klien volume tinggi, semua lalu lintas pengiriman dari port sumber yang sama, dan Anda ingin memuat keseimbangan ini melalui beberapa backend, maka Anda mungkin lebih suka menggunakan pendekatan stateless/spray-and-pray.

Kami memuat keseimbangan banyak lalu lintas DNS dan RADIUS - DNS biasanya termasuk dalam kategori pertama (banyak klien, atau klien dengan banyak port sumber), dan RADIUS biasanya termasuk dalam kategori selanjutnya (sedikit klien, banyak paket semua dari IP/port yang sama). Daripada menggunakan hash stateless untuk RADIUS, kami memutuskan untuk mengacak port sumber untuk mendapatkan penyebaran yang merata.

Setelah membaca seluruh utas, saya masih tidak tahu apakah mengaktifkan mode iptables untuk kube-proxy harus memperbaiki masalah IP eksternal yang disembunyikan (#10921) atau tidak. Kami memang mengaktifkan mode iptables dengan v1.1 seperti yang disarankan di sini, tetapi kami masih melihat IP dari cluster, bukan yang asli dari pengguna.

Cluster kami ada di GCE dan kami hanya membutuhkan penyeimbang beban dengan dukungan HTTPS sebelum kami ditayangkan. Karena GCE tidak mendukung v.1.2 alpha, kami tidak dapat menggunakan Ingress baru (yang AFAIK mendukung HTTPS Load Balancer), jadi Network Load Balancer adalah satu-satunya pilihan kami. Tapi jelas kita tidak bisa hidup tanpa kemampuan logging ips nyata dari pengguna kami.

Beberapa klarifikasi untuk pengguna baru tentang ini akan dihargai. Mendukung HTTPS adalah wajib bagi banyak dari kita. Terima kasih!

Saya telah menggunakan dan mematikan proxy iptables selama beberapa waktu dan dapat mengonfirmasi bahwa IP eksternal klien masih tersembunyi/tampilkan IP cluster.

Kami telah menyiasatinya sejauh ini dengan menjalankan proxy HTTP/HTTPS frontend kami yang berjalan dalam mode jaringan host sehingga ia melihat alamat IP sumber.

@maclof terima kasih atas umpan baliknya. Bisakah Anda berbagi info lebih lanjut tentang bagaimana solusi Anda? Apa yang Anda maksud dengan HTTP/HTTPS Anda yang berjalan di jaringan host?

@javiercr kami menggunakan spesifikasi pod seperti ini: http://pastie.org/private/zpdelblsob654zif7xus5g

Menggunakan jaringan host berarti bahwa pod berjalan di jaringan mesin host, alih-alih diberi IP cluster.

Itu berarti ketika server nginx kami mengikat ke port 80/443 itu akan mendengarkan pada IP host dan akan melihat alamat IP sumber.

Saya menggunakan kubernetes 1.1, /opt/bin/kube-proxy ... --proxy-mode=iptables --masquerade-all=false dan merutekan jaringan IP cluster melalui host yang memiliki kube-proxy. Dalam pengaturan ini, layanan saya melihat IP eksternal. Saya menggunakan namespace jaringan yang sangat tersedia yang memiliki IP eksternal dan rute ke host:

I0221 01:20:32.695440       1 main.go:224] <A6GSXEKN> Connection from 202.22.xxx.yyy:51954 closed.

Saya telah belajar banyak membaca utas ini!

Sebagai FYI, dokumen ini menyatakan bahwa AWS ELB menggunakan round-robin untuk koneksi TCP dan koneksi paling sedikit untuk http/https: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html# permintaan -perutean

Saya setuju bahwa fokus untuk mendapatkan permintaan hanya ke node yang menjalankan pod dan mencoba melayani pod lokal adalah cara terbaik untuk melakukannya. Manfaat sampingan yang bagus dari ini adalah akan ada lebih sedikit lalu lintas node-to-node di dalam cluster dan saya kira peningkatan latensi dengan selalu melayani permintaan lokal dari layanan ke pod (yang saya kira bahkan lebih bermanfaat jika Anda memiliki node di dalamnya. beberapa zona ketersediaan di cluster yang sama).

Dalam hal bekerja dengan penyeimbang beban yang tidak mendukung pembobotan maka Anda dapat menyelesaikan ini dengan pengontrol replikasi Anda dengan mencoba untuk selalu menjaga jumlah pod yang sama pada sebuah node (jika ada lebih dari 1 per node) dan kemudian mendistribusikan secara merata antara mereka, bahkan jika ini berarti harus memindahkan pod dari sebuah node dalam situasi tertentu dan hanya mengizinkan jumlah replika tertentu. misalnya untuk kluster 4 node dengan layanan yang terhubung ke penyeimbang beban, satu-satunya jumlah replika pod yang dapat diterima adalah 1,2,3,4,6,8,9,12,16,20, dll.

Kami juga mencari solusi untuk lalu lintas ke rute ke pod lokal saja. Saya akan baik-baik saja dengan nodeport pergi pada sebuah node pada saat tidak ada pod yang hadir secara lokal untuk sebuah layanan. Dengan cara ini, pemeriksaan kesehatan TCP penyeimbang beban sederhana akan mencegah permintaan masuk ke node tersebut. Saya pikir jika kita setidaknya dapat memecahkan bagian iptables\kube-proxy dari ini, maka kita akan mengetahui apa implikasi penyeimbangan beban ketika pod tidak seimbang di seluruh cluster. Saya pikir ada cara untuk menyelesaikannya pada penyeimbang beban tanpa harus menetapkan bobot untuk setiap node dengan panggilan API.

Penyeimbang beban sudah menangani ini dengan menggunakan metode dinamis lainnya. Juga, tergantung pada apa yang sebenarnya dilakukan oleh layanan yang Anda jalankan di dalam wadah itu untuk setiap panggilan api, itu mungkin tidak dapat mendukung 2x lalu lintas ketika ada 2 pod pada sebuah node vs satu. Jika Batas Kubernetes ditetapkan dan jika tingkat penggunaan maksimum sedang didekati pada podnode, hal ini juga dapat menambah lapisan kerumitan untuk mencoba menemukan pengaturan bobot yang tepat pada penyeimbang beban eksternal.

Menurut saya, jauhi tingkat kerumitan itu dan jangan mencoba mengatur bobot penyeimbang beban dari kubernetes.

@yoshiwaan Dapatkah saya menyarankan membuka masalah baru untuk saran lalu lintas antar-simpul, karena masalah ini sekarang sudah ditutup. Secara pribadi saya pikir langkah pertama yang baik adalah memastikan bahwa _if_ sebuah pod berjalan di node lokal, yang kami rutekan ke pod lokal. Saya menduga ini akan cukup, karena Anda kemudian dapat menskalakan RC Anda sehingga ada pod di setiap node.

@justinsb +1, kami juga mengalami masalah sekarang di mana kami perlu melihat IP klien dan pada dasarnya tidak mungkin dengan pengaturan saat ini.

Ini mungkin terlalu naif, namun saya bertanya-tanya apa perbedaan antara mode userspace dan iptables? Saya tidak bisa benar-benar tahu dari pengguna doc .

Mode Userland berarti kube-proxy menangani koneksi itu sendiri dengan menerima permintaan koneksi dari klien dan membuka soket ke server, yang (1) menghabiskan lebih banyak CPU dan memori dan (2) terbatas pada jumlah port yang dapat digunakan oleh satu port. buka (<65k). Mode iptables bekerja pada tingkat yang lebih rendah, di kernel, dan menggunakan pelacakan koneksi sebagai gantinya, jadi jauh lebih ringan dan menangani lebih banyak koneksi*.

(edit) (*) Selama Anda tidak melewati paket SNAT, yang pada gilirannya memerlukan pengaturan di mana Anda yakin paket akan melewati aturan pelacakan koneksi yang terkait dengannya. Misalnya, menggunakan desain akses yang dirutekan memungkinkan Anda menghindari SNAT, yang berarti titik akhir layanan akan melihat IP klien yang sebenarnya.

@MikaelCluseau
artinya kube-proxy hanya bertanggung jawab untuk mengatur dan memelihara aturan iptables dan kami tidak lagi mendapatkan port lokal acak untuk setiap layanan dalam mode iptables, bukan?

Pada 19/4/2016 22:51, Emma He menulis:

artinya kube-proxy hanya bertanggung jawab untuk menyiapkan dan memelihara
iptables dan kami tidak lagi mendapatkan port lokal acak untuk setiap layanan di
mode iptables, kan?

Ya.

Maaf tapi saya benar-benar melewatkan ini sebelumnya.

(edit) (*) Selama Anda tidak melewati paket SNAT, yang pada gilirannya memerlukan pengaturan di mana Anda yakin paket akan melewati aturan pelacakan koneksi yang terkait dengannya. Misalnya, menggunakan desain akses yang dirutekan memungkinkan Anda menghindari SNAT, yang berarti titik akhir layanan akan melihat IP klien yang sebenarnya.

@MikaelCluseau Saya berpikir iptables mengadopsi SNAT dan DNAT, yang menurut Anda tidak demikian. Bisakah Anda menjelaskan ini untuk saya?

Pada 20/04/2016 13:59, Emma He menulis:

@MikaelCluseau https://github.com/MikaelCluseau Saya berpikir
iptables mengadopsi SNAT dan DNAT, yang menurut Anda tidak demikian.
Bisakah Anda menjelaskan ini untuk saya?

Ini bagian yang sulit.

(1) Menggunakan IP layanan/eksternal memerlukan DNAT.
(2) Jika Anda yakin paket balasan akan melalui jalur yang sama
aturan (yaitu, tumpukan jaringan yang sama atau tabel conntrack yang direplikasi), Anda
dapat melewati bagian SNAT (yaitu, aturan MASQUERADE).

Kondisi (2) biasanya baik-baik saja dalam desain jaringan akses yang dirutekan
(yang merupakan desain paling sederhana yang dapat saya pikirkan).

Misalnya, diberikan

• klien 1.0.1.1,
• layanan 1.0.2.1,
• sebuah pod yang mengimplementasikan layanan 1.0.3.1.

Kemudian,

1. Router/firewall/loadbalancer/host/apa pun yang menerima paket
   untuk layanan sehingga ia melihat paket "1.0.1.1 -> 1.0.2.1";
2. Ini DNAT ke titik akhir (pod) sehingga paket akan menjadi "1.0.1.1 ->
   1.0.3.1" di jaringan cluster;
3. Pod membalas dengan paket "1.0.3.1 -> 1.0.1.1";
4. Paket melewati router/firewall/loadbalancer/host/apapun
   memiliki aturan conntrack, sistem conntrack menulis ulang paket
   ke "1.0.2.1 -> 1.0.1.1" sebelum mengirimnya kembali ke klien.

Jika kondisi (2) tidak dapat dipenuhi, Anda harus menggunakan SNAT/MASQUERADING
untuk memastikan bahwa paket akan kembali melalui
router/firewall/loadbalancer/host/conntrack.

@MikaelCluseau -
sesuatu untuk mu

Pada Selasa, 19 Apr 2016 jam 20:20, Mikaël Cluseau [email protected]
menulis:

Pada 20/04/2016 13:59, Emma He menulis:

@MikaelCluseau https://github.com/MikaelCluseau Saya berpikir
iptables mengadopsi SNAT dan DNAT, yang menurut Anda tidak demikian.
Bisakah Anda menjelaskan ini untuk saya?

Ini bagian yang sulit.

(1) Menggunakan IP layanan/eksternal memerlukan DNAT.
(2) Jika Anda yakin paket balasan akan melalui jalur yang sama
aturan (yaitu, tumpukan jaringan yang sama atau tabel conntrack yang direplikasi), Anda
dapat melewati bagian SNAT (yaitu, aturan MASQUERADE).

Kondisi (2) biasanya baik-baik saja dalam desain jaringan akses yang dirutekan
(yang merupakan desain paling sederhana yang dapat saya pikirkan).

Misalnya, diberikan

• klien 1.0.1.1,
• layanan 1.0.2.1,
• sebuah pod yang mengimplementasikan layanan 1.0.3.1.

Kemudian,

1. Router/firewall/loadbalancer/host/apa pun yang menerima paket
   untuk layanan sehingga ia melihat paket "1.0.1.1 -> 1.0.2.1";
2. Ini DNAT ke titik akhir (pod) sehingga paket akan menjadi "1.0.1.1 ->
   1.0.3.1" di jaringan cluster;
3. Pod membalas dengan paket "1.0.3.1 -> 1.0.1.1";
4. Paket melewati router/firewall/loadbalancer/host/apapun
   memiliki aturan conntrack, sistem conntrack menulis ulang paket
   ke "1.0.2.1 -> 1.0.1.1" sebelum mengirimnya kembali ke klien.

Jika kondisi (2) tidak dapat dipenuhi, Anda harus menggunakan SNAT/MASQUERADING
untuk memastikan bahwa paket akan kembali melalui
router/firewall/loadbalancer/host/conntrack.

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

@justinsb @yoshiwaan apakah ada yang pernah membuat masalah untuk ini? Fu pencarian saya mengecewakan saya, dan saya memiliki kebutuhan yang sama.

Bisakah saya menyarankan membuka edisi baru untuk saran lalu lintas antar-simpul, karena masalah ini sekarang sudah ditutup. Secara pribadi saya pikir langkah pertama yang baik adalah memastikan bahwa jika sebuah pod berjalan di node lokal, kami merutekan ke pod lokal. Saya menduga ini akan cukup, karena Anda kemudian dapat menskalakan RC Anda sehingga ada pod di setiap node.

Saya tidak membesarkannya sendiri

Ahhhhh, saya pikir saya menemukannya, ini tampaknya fitur/perbaikan: https://github.com/kubernetes/features/issues/27

Tampaknya beta pada 1.5.x.