Kubeadm: node dengan beberapa antarmuka jaringan dapat gagal untuk berbicara dengan layanan

Pengguna lain melaporkan perilaku yang sama pada # kubernetes-users.

@damaspi Saya telah membuka masalah ini dan memberikan perbaikan. Menunggu umpan balik!

Juga, pindah ke mode userspace membawa cukup banyak hukuman kinerja.

Maaf, saya berkomentar di masalah yang salah.
Terima kasih atas perbaikannya. Saya tidak akan dapat segera mengujinya (saya mengerjakan ini selama liburan, dan saya kembali bekerja), dan saya hanya menggunakan versi stabil resmi (jadi saya tidak memiliki lingkungan untuk membuatnya).

Saya menyalinnya di sini sekarang, dan menghapusnya di ...

Saya bekerja untuk sementara dengan mengkonfigurasi mode proxy ke ruang pengguna tetapi saran apa pun diterima ...

(terinspirasi oleh masalah ini )

kubectl -n kube-system get ds -l "component=kube-proxy" -o json | jq ".items[0].spec.template.spec.containers[0].command |= .+ [\"--proxy-mode=userspace\"]" | kubectl apply -f - && kubectl -n kube-system delete pods -l "component=kube-proxy"

Sekali lagi, @damaspi

Juga, pindah ke mode ruang pengguna membawa cukup banyak hukuman kinerja.

Saya memiliki masalah yang sama.
Kube-Proxy saya tidak akan menginstal aturan terkait Layanan, membuat layanan apa pun tidak tersedia dari pod.

Perbaikan saya adalah memodifikasi Kubeadm DaemonSet untuk kube-proxy dan menambahkan secara eksplisit opsi --cluster-cidr =.

/ cc @luxas

@spxtr Anda menutup banyak masalah di repo ini

@mikedanese PR digabungkan dan ada PR digabungkan yang memperbaiki kekurangan --cluster-cidr flag di controller-manager.

@pires , penggabungan PR di repo utama bukan yang menutup PR ini. Itu adalah penggabungan di cabang @spxtr . Itulah yang menjadi perhatian saya.

Ah, aku memang pernah melihatnya sebelumnya.

Saya telah melihat ini di 1.5.2. Saya secara manual membangun cluster (untuk belajar.). Saya tidak jelas apa perbaikannya, karena ada penyebutan controller-manager dan set daemon. Itu menyiratkan kepada saya bahwa orang-orang meluncurkan kube-proxy melalui set-daemon. Hanya untuk memperjelas, perbaikan sebenarnya adalah menambahkan bendera (--cluster-cidr) ke kube-proxy, benar? Hanya mencoba memastikan saya tidak melewatkan sesuatu. Juga, hanya untuk menghapus ingatan saya, bukankah kube-proxy menggunakan untuk mendapatkan ini dari kube-apiserver? Apakah itu selalu dibutuhkan, saya tidak ingat. Jika tidak, dapatkah seseorang menjelaskan perbedaan antara --service-cluster-ip-range = 10.0.0.0 / 16 (api) dan --cluster-cidr (proxy)? Terima kasih. (maaf untuk menambahkan di sini, tidak yakin ke mana lagi untuk menanyakan masalah ini.)

Di mana server API mengekspos pod cluster CIDR? Ini adalah kesalahpahaman di pihak saya juga.

Hai @pires , pikirku. --service-cluster-ip-range = 10.0.0.0 / 16 di api-server mengatur semuanya karena proxy akan berbicara dengan server k8s untuk mendapatkan informasi itu. --cluster-cidr mungkin melakukan subset dari --service-cluster-ip-range, kalau tidak sepertinya berlebihan atau ada kasus penggunaan yang saya tidak jelas (atau saya tidak tahu apa yang saya bicarakan , yang mungkin benar!)

Layanan CIDR adalah subnet yang digunakan untuk IP virtual (digunakan oleh kube-proxy). Masalahnya adalah kube-proxy tidak mengetahui tentang CIDR jaringan pod, yang berbeda dengan CIDR layanan.

Ah, jadi apakah itu overlaynya?

Apakah masalah ini menyebabkan komunikasi antara pod dan api-server? Misalnya jika saya menjalankan perintah curl dari pod kube ke apiserver "curl https://10.96.0.1:443/api" hasilnya:> curl: (7) Gagal menyambung ke 10.96.0.1 port 443: Waktu koneksi di luar...

@ bamb00 , ya gejala itu disebabkan oleh bug ini.

Bagi mereka yang tertarik, yang terjadi adalah tanpa pengetahuan tentang subnet cluster, kube-proxy tidak dapat menghasilkan kondisi iptables agar sesuai dengan lalu lintas eksternal. Tanpa kondisi tersebut, lalu lintas tidak akan ditandai untuk SNAT dan disambungkan dengan alamat tujuan yang benar tetapi sumber salah.

Demonstrasi aturan yang hilang:

--- /root/ipt.old   2017-02-22 09:26:48.666151853 +0000
+++ /root/ipt.new   2017-02-22 09:25:52.010151853 +0000
@@ -27,8 +27,11 @@
 -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
 -A KUBE-SEP-EHDRCCD3XO3VA5ZU -s 192.168.1.4/32 -m comment --comment "default/kubernetes:https" -j KUBE-MARK-MASQ
 -A KUBE-SEP-EHDRCCD3XO3VA5ZU -p tcp -m comment --comment "default/kubernetes:https" -m recent --set --name KUBE-SEP-EHDRCCD3XO3VA5ZU --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 192.168.1.4:6443
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4
 -A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS
 -A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-EHDRCCD3XO3VA5ZU --mask 255.255.255.255 --rsource -j KUBE-SEP-EHDRCCD3XO3VA5ZU
@@ -72,4 +75,6 @@
 -A WEAVE-NPC -d 224.0.0.0/4 -j ACCEPT
 -A WEAVE-NPC -m state --state NEW -j WEAVE-NPC-DEFAULT
 -A WEAVE-NPC -m state --state NEW -j WEAVE-NPC-INGRESS
+-A WEAVE-NPC-DEFAULT -m set --match-set weave-k?Z;25^M}|1s7P3|H9i;*;MhG dst -j ACCEPT
+-A WEAVE-NPC-DEFAULT -m set --match-set weave-iuZcey(5DeXbzgRFs8Szo]<<strong i="9">@p</strong> dst -j ACCEPT
 COMMIT

Ini dapat diperbaiki saat runtime dengan memodifikasi perintah @damaspi dari atas, mengganti --proxy-mode = userspace dengan --cluster-cidr = your_cidr

Saat ini membangun kubeadm dengan tambalan gabungan, akan melakukan bootstrap ulang dengan itu dan melaporkan kembali keberhasilannya.

@predakanga , Terima kasih atas tanggapan dan penjelasannya. Saya berjuang untuk memahami koneksi yang waktunya habis ke apiserver dari pod. Yang membingungkan bagi saya adalah kesalahan waktu habis terjadi pada pod yang berjalan di node di non-master (AWS) dan pod yang berjalan di node master tidak memiliki error waktu habis. Saya ingin menerapkan solusi yang disarankan tetapi memiliki pertanyaan tentang bagaimana cara mendapatkan nilai your_cidr untuk --cluster-cidr?

Solusi:
kubectl -n kube-system dapatkan ds -l "component = kube-proxy" -o json | jq '.items [0] .spec.template.spec.containers [0] .command | =. + [\ " --cluster-cidr = your_cidr \"]' | kubectl apply -f - && kubectl -n kube-system hapus pods -l "component = kube-proxy"

Berikut adalah waktu log habis:
2017-02-22T16: 23: 44.200770003Z 2017-02-22 16:23:44 +0000 [info]: mulai fluentd-0.12.31
2017-02-22T16: 23: 44.281836006Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-elasticsearch' versi '1.9.2'
2017-02-22T16: 23: 44.281862309Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-journal-parser' version '0.1.0'
2017-02-22T16: 23: 44.281867643Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-kubernetes_metadata_filter' versi '0.26.2'
2017-02-22T16: 23: 44.281873256Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-record-reformer' versi '0.8.3'
2017-02-22T16: 23: 44.281876742Z 2017-02-22 16:23:44 +0000 [info]: permata 'fluentd' versi '0.12.31'
2017-02-22T16: 23: 44.281976520Z 2017-02-22 16:23:44 +0000 [info]: menambahkan pola filter = "kubernetes. " Type = "kubernetes_metadata"2017-02-22T16: 24: 44.639919409Z 2017-02-22 16:24:44 +0000 ** [error]: config error file = "/ fluentd / etc / fluent.conf" error = "Endpoint Kubernetes API v1 tidak valid https://10.96.0.1 : 443 / api: Waktu habis saat menyambung ke server "
2017-02-22T16: 24: 44.641926923Z 2017-02-22 16:24:44 +0000 [info]: proses selesai kode = 256
2017-02-22T16: 24: 44.641936546Z 2017-02-22 16:24:44 +0000 [error]: proses utama fluentd tiba-tiba mati. memulai ulang.

Seperti yang Anda lihat, batas waktu menunjukkan https://10.96.0.1 : 443 / api, tetapi dari layanan kubernetes titik akhir apiserver adalah 10.43.0.20:6443. Dari apa yang saya pahami dari penjelasan Anda, kesalahan waktu habis adalah kube-proxy tidak dapat menghasilkan kondisi iptables agar sesuai dengan lalu lintas eksternal.

Mengapa koneksi melewati 10.96.0.1:443 dan bukan titik akhir 10.43.0.20:6443?

Nama: kubernetes
Namespace: default
Label: komponen = apiserver
provider = kubernetes
Pemilih:
Jenis: ClusterIP
IP: 10.96.0.1
Porta: https 443 / TCP
Titik akhir: 10.43.0.20:6443
Afinitas Sesi: ClientIP
Tidak ada acara.

Pembaruan: Menerapkan solusi solusi "clusterCIDR tidak ditentukan, tidak dapat membedakan antara lalu lintas internal dan eksternal".

Terima kasih.

Maaf untuk pertanyaan pemula, tapi bagaimana cara mendapatkan perbaikan untuk menerapkannya secara permanen?

Kami menggunakan kube-proxy v1.5.3 (gcr.io/google_containers/kube-proxy-amd64:v1.5.3) tetapi masih melihat kesalahan "clusterCIDR tidak ditentukan, tidak dapat membedakan antara lalu lintas internal dan eksternal".

Menurut URL di bawah ini perbaikan untuk kube-proxy v1.5,
https://github.com/dchen1107/kubernetes-1/commit/9dedf92d42028e1bbb4d6aae66b353697afaa55b

Apakah ini benar?

@ bamb00 ini bukan perbaikan kube-proxy tetapi perubahan kubeadm yang menyetel tanda dalam manifes pod kube-proxy. kubeadm tidak mengikuti (belum!) proses rilis kubernetes, jadi tidak ada kubeadm 1.5.3. Akan ada 1.6.

Saya menyebarkan 1.5.2. Beberapa petunjuk peringatan. proxy: clusterCIDR tidak ditentukan, tidak dapat membedakan antara lalu lintas internal dan eksternal

@timchenxiaoyu Dengan v1.6 Anda dapat menyetel flag --pod-network-cidr untuk menyetelnya

Hai, saya bekerja di Weave Net, dan saya tidak mengerti mengapa perubahan diperlukan seperti yang dijelaskan di https://github.com/kubernetes/kubeadm/issues/102#issuecomment -281617189

Weave Net menginstal aturan penyamarannya sendiri saat keluar dari jaringan pod, jadi seharusnya tidak perlu kube-proxy untuk melakukannya juga.

@bboreham Saya tidak dapat menjelaskan alasannya, tetapi dari ingatan masalahnya adalah bahwa pod daemonset weave-net tidak dapat berbicara satu sama lain.

Saya akan mengatur ulang lingkungan saya sehingga saya dapat memberi Anda lebih banyak detail, tetapi itu mungkin memakan waktu cukup lama (internet Australia)

Tidak dapat melihat mengapa masalah ini harus ditutup - dapatkah pengelola membukanya kembali?

/ cc @luxas

Saya baru saja memeriksa cluster Kubernetes + WeaveNet yang berfungsi, dan memiliki pesan yang sama di log kube-proxy

W0404 12:24:17.175005       1 proxier.go:309] clusterCIDR not specified, unable to distinguish between internal and external traffic

Jadi saya akan menyimpulkan bahwa peringatan itu tidak perlu menakut-nakuti orang.

masalahnya adalah pod daemonset weave-net tidak dapat saling berkomunikasi.

@predakanga implementasi Weave Net berjalan di namespace jaringan host; itu pasti tidak akan terpengaruh oleh (atau mendekati) aturan kube-proxy ketika pod berbicara satu sama lain.

@boreham Ah, saya salah mengingat, permintaan maaf saya.

Saya rasa saya tahu apa masalah sebenarnya, tetapi saya akan menunda sampai dua node ini menyelesaikan bootstrap sehingga saya dapat mengonfirmasi

@bboreham Masalahnya adalah pod weave mencoba menjangkau server API melalui VIP-nya

Saya baru saja mem-bootstrap cluster dua node tanpa opsi khusus dan https://git.io/weave-kube-1.6 diterapkan, dan mencapai kondisi kesalahan.

Keluaran syslog:

Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.775425   17891 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/a96a9cfb-193b-11e7-b8e0-02fc636bbb90-weave-net-token-p3qrx" (spec.Name: "weave-net-token-p3qrx") pod "a96a9cfb-193b-11e7-b8e0-02fc636bbb90" (UID: "a96a9cfb-193b-11e7-b8e0-02fc636bbb90").
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.984975   17891 kuberuntime_manager.go:458] Container {Name:weave Image:weaveworks/weave-kube:1.9.4 Command:[/home/weave/launch.sh] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[cpu:{i:{value:10 scale:-3} d:{Dec:<nil>} s:10m Format:DecimalSI}]} VolumeMounts:[{Name:weavedb ReadOnly:false MountPath:/weavedb SubPath:} {Name:cni-bin ReadOnly:false MountPath:/host/opt SubPath:} {Name:cni-bin2 ReadOnly:false MountPath:/host/home SubPath:} {Name:cni-conf ReadOnly:false MountPath:/host/etc SubPath:} {Name:dbus ReadOnly:false MountPath:/host/var/lib/dbus SubPath:} {Name:lib-modules ReadOnly:false MountPath:/lib/modules SubPath:} {Name:weave-net-token-p3qrx ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/status,Port:6784,Host:127.0.0.1,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:30,TimeoutSeconds:1,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:3,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:nil,Privileged:*true,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.986470   17891 kuberuntime_manager.go:742] checking backoff for container "weave" in pod "weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.987392   17891 kuberuntime_manager.go:752] Back-off 5m0s restarting failed container=weave pod=weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)
Apr  4 13:48:45 frontend kubelet[17891]: E0404 13:48:45.987440   17891 pod_workers.go:182] Error syncing pod a96a9cfb-193b-11e7-b8e0-02fc636bbb90 ("weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"), skipping: failed to "StartContainer" for "weave" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=weave pod=weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"
Apr  4 13:48:50 frontend kubelet[17891]: W0404 13:48:50.545383   17891 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr  4 13:48:50 frontend kubelet[17891]: E0404 13:48:50.546074   17891 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Menenun log kontainer:

2017/04/04 13:45:24 error contacting APIServer: Get https://10.96.0.1:443/api/v1/nodes: dial tcp 10.96.0.1:443: i/o timeout; trying with fallback: http://localhost:8080
2017/04/04 13:45:24 Could not get peers: Get http://localhost:8080/api/v1/nodes: dial tcp 127.0.0.1:8080: getsockopt: connection refused
Failed to get peers

Dan node tidak pernah mencapai status "Ready"

Masalahnya adalah pod weave mencoba menjangkau server API melalui VIP-nya

apa buktinya?

Dapatkan http: // localhost : 8080 / api / v1 / node

Ini adalah pod weave yang mencoba menjangkau api-server di alamat lokal yang tidak aman. Ini bukanlah konfigurasi yang Anda dapatkan dari kubeadm saat ini tanpa opsi.

Saya buruk lagi - format saya memotong baris pertama dari setiap log. Saya telah mengubah keduanya.

ok, saya juga baru saja menyiapkan cluster tanpa opsi khusus dan tidak kesulitan menghubungi tcp: //10.96.0.1 : 443

Namun komentar saya tentang Weave Net menyiapkan aturan penyamaran tidak relevan. Biarkan saya melihat apakah saya bisa mengetahuinya.

Sebagai perbandingan, saya baru saja menjalankan kembali bootstrap kubeadm dengan tambahan --pod-network-cidr 10.32.0.0/12 , dan pod tenun dimulai dengan benar, transisi node ke Ready.

Saya curiga Anda tidak mengalaminya karena ini hanya berlaku untuk konfigurasi jaringan tertentu - dalam kasus saya, saya menggunakan mesin Vagrant dengan cluster kube yang dibuat melalui antarmuka khusus pribadi sekunder.

Dalam percakapan terpisah, saya telah melihat ini terjadi:

Ada dua antarmuka jaringan, eth0 dan eth1 : eth0 memiliki rute default, tetapi kami ingin semua lalu lintas ke kubernetes melalui eth1 .

• Sebuah proses, seperti Weave Net, membuka koneksi ke alamat layanan 10.96.0.1
• Alamat tujuan dipetakan ulang ke alamat eth1 master 192.168.10.90 (pemetaan ulang dilakukan dengan aturan iptables yang dibuat oleh kube-proxy.)
• Paket dikirim pada antarmuka eth1 node.
• Namun Linux telah memilih alamat sumber eth0 untuk paket ini, berdasarkan tujuan asli yang cocok dengan rute default.
• Di tempat tujuan itu dijatuhkan karena datang dari tempat yang salah

Menambahkan --pod-network-cidr menyebabkan aturan iptables tambahan untuk menulis ulang alamat sumber. Jadi sekarang akan membahas antarmuka eth1. [EDIT: Saya tidak merekomendasikan ini, karena pada dasarnya ini adalah kecelakaan yang membuatnya bekerja]

Cara lain untuk membuatnya berfungsi adalah dengan menambahkan rute yang memberi tahu Linux bahwa semua alamat layanan kubernetes harus melalui eth1, seperti ini:

ip route add 10.96.0.0/16 dev eth1 src 192.168.10.100

Secara pribadi saya menemukan rute yang lebih menarik karena membuat keputusan yang tepat lebih awal. Tapi mencari suara lain untuk berkomentar apakah ini valid.

@bboreham terima kasih telah

Akan menguji perbaikan di lingkungan saya.

Menarik - Saya dapat mengonfirmasi bahwa pendekatan rute ini berfungsi pada satu
segmen jaringan, tetapi apakah itu akan menyebabkan masalah di seluruh domain siaran?

Lachlan

Pada Rabu, 5 Apr 2017 jam 1:16, Bryan Boreham [email protected]
menulis:

Dalam percakapan terpisah, saya telah melihat ini terjadi:

Ada dua antarmuka jaringan, eth0 dan eth1: eth0 memiliki default
rute, tapi kami ingin semua lalu lintas ke kubernetes melalui eth1.

• Sebuah proses, seperti Weave Net, membuka koneksi ke layanan
  alamat 10.96.0.1
• Alamat tujuan dipetakan ulang ke alamat eth1 master
  192.168.10.90 (pemetaan ulang dilakukan dengan aturan iptables yang dibuat oleh kube-proxy.)
• Paket dikirim pada antarmuka eth1 node.
• Namun Linux telah memilih alamat sumber eth0 untuk ini
  paket, berdasarkan tujuan awal yang cocok dengan rute default.
• Di tempat tujuan itu dijatuhkan karena datang dari tempat yang salah

Menambahkan --pod-network-cidr menyebabkan aturan iptables tambahan untuk ditulis ulang
alamat sumber. Jadi sekarang akan membahas antarmuka eth1.

Cara lain untuk membuatnya berfungsi adalah dengan menambahkan rute yang memberi tahu Linux itu semua
alamat layanan kubernetes harus melalui eth1, seperti ini:

rute ip tambahkan 10.96.0.0/16 dev eth1 src 192.168.10.100

Secara pribadi saya merasa rutenya lebih menarik karena berbelok ke kanan
keputusan sebelumnya. Tapi mencari suara lain untuk mengomentari apakah ini
adalah benar.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/102#issuecomment-291532883 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAystQH0juIo6cXPh5QQeB-1rHlUKUgvks5rsl7WgaJpZM4La21F
.

@bboreham Saya dapat mengonfirmasi bahwa saya sekarang memiliki penyiapan yang dapat berfungsi dengan menambahkan rute ... :-)

@predakanga semua yang saya coba lakukan dengan rute adalah membuat Linux memilih alamat sumber yang lebih baik; karena kami mengharapkan semua IP layanan mendapatkan DNAT, kami tidak berharap untuk benar-benar menggunakan rute itu. Namun saya dapat melihat bahwa jika alamat yang mendasarinya keluar pada dua adapter jaringan yang berbeda maka saran saya tidak akan baik.

@thockin Saya akan menghargai masukan Anda pada analisis saya di https://github.com/kubernetes/kubeadm/issues/102#issuecomment -291532883 dan dua saran untuk mengkonfigurasi SNAT (untuk koneksi yang berasal dari namespace jaringan host) atau menambahkan rute untuk rentang IP layanan.

@bboreham dapatkah Anda mendokumentasikan temuan ini entah bagaimana dan di suatu tempat?
Jadi lebih banyak pengguna yang akan mengetahuinya?

Saya baru selesai men- debug sistem
Saya mendokumentasikannya di sini sehingga seseorang dapat berkata "tidak! Tidak! Anda benar-benar salah paham".
Jika itu tidak terjadi, saya akan dengan senang hati meningkatkannya ke dokumentasi yang benar: little_smiling_face:

Dalam kasus multi-jalur multi-NIC, ya, saya pikir Anda memerlukan rute seperti yang Anda sarankan. Tidak yakin bagaimana cara mengetahui itu secara otomatis ...

Satu pemikiran lagi muncul di benak: ini tidak ada hubungannya dengan jaringan pod (Weave Net atau sebaliknya), karena hal yang gagal adalah proses di namespace host node yang mencoba berbicara dengan api-server di master. Jadi temuan bahwa menyetel clusterCIDR membuatnya bekerja pasti tidak disengaja.

@bboreham @thockin Ada yang bisa kami lakukan di sini atau bisakah saya melanjutkan dan menutup ini?
Anda dapat menyetel --cluster-cidr pada kube-proxy dengan mengirimkan --pod-network-cidr ke kubeadm init

Seperti yang telah saya jelaskan, pengaturan --cluster-cidr bukanlah tanggapan yang valid untuk masalah yang awalnya dilaporkan dalam komentar di # 74 . (Meskipun kebetulan membuat masalah hilang).

Judul di sini tidak membantu; ini berkaitan dengan pesan peringatan yang sama sekali tidak ada hubungannya dengan masalah yang mendasarinya.

Saya tidak benar-benar tahu apa yang bisa dilakukan kubeadm, karena solusinya tampaknya terkait dengan jaringan yang mendasarinya. Mungkin menambahkan opsi untuk menginformasikan "antarmuka publik" dan "antarmuka pribadi" yang Anda inginkan dan meminta kubeadm merekomendasikan perubahan konfigurasi jaringan?

Saya baru saja melihat logika clusterCIDR di kube-proxy, dan saya setuju itu adalah kasus sudut yang aneh.

Saya setuju rute statis sesuai untuk antarmuka ke-2, tetapi sangat disayangkan. Sepertinya kernel harus lebih pintar dari itu.

Saya menjalankan v1.6.1 dan mengira kesalahan "clusterCIDR tidak ditentukan, tidak dapat membedakan antara lalu lintas internal dan eksternal" akan menjadi alamat.

2017-06-06T17: 49: 17.113224501Z I0606 17: 49: 17.112870 1 server.go: 225] Menggunakan iptables Proxier.
2017-06-06T17: 49: 17.139584294Z W0606 17: 49: 17.139190 1 proxier.go: 309] clusterCIDR tidak ditentukan, tidak dapat membedakan antara lalu lintas internal dan eksternal
2017-06-06T17: 49: 17.139607413Z I0606 17: 49: 17.139223 1 server.go: 249] Menghancurkan aturan userspace.
2017-06-06T17: 49: 17.251412491Z I0606 17:49: 17.251115 1 conntrack.go: 81] Set sysctl 'net / netfilter / nf_conntrack_max' ke 524288
2017-06-06T17: 49: 17.252499164Z I0606 17: 49: 17.252359 1 conntrack.go: 66] Setting conntrack hashsize ke 131072
2017-06-06T17: 49: 17.253220249Z I0606 17: 49: 17.253057 1 conntrack.go: 81] Set sysctl 'net / netfilter / nf_conntrack_tcp_timeout_established' ke 86400
2017-06-06T17: 49: 17.253246216Z I0606 17:49: 17.253124 1 conntrack.go: 81] Set sysctl 'net / netfilter / nf_conntrack_tcp_timeout_close_wait' ke 3600

bagaimana mendefinisikan lalu lintas internal dan eksternal?

Kesalahan ini secara khusus merujuk pada apa pun di luar kluster IP Pod.

Pada Kamis, 8 Juni 2017 pukul 22.29 timchenxiaoyu [email protected]
menulis:

bagaimana mendefinisikan lalu lintas internal dan eksternal?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/102#issuecomment-307298979 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AFVgVPwm-x4smcIx1cFAOLOO6FFIn9T6ks5sCNgkgaJpZM4La21F
.

Saya telah melihat masalah ini juga. rute ke jaringan pod ke nic kedua menyelesaikan masalah untuk saya. Meski terasa sedikit rapuh .....

Hai,

Saya menjalankan Kubernetes v1.6.6 & v1.7.0 kube-proxy. Mendapatkan kesalahan yang sama,

kube-proxy:

   W0914 00:15:41.627710       1 proxier.go:298] clusterCIDR not specified, unable to distinguish between internal and external traffic

Versi Kubernetes:

   Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:34:20Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
   Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}

Coba solusi dari @damaspi tetapi gagal di v1.6.6 dan v1.7.0 gunakan untuk bekerja di v1.5.4.

  # kubectl -n kube-system get ds -l "component=kube-proxy" -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--cluster-cidr=10.96.0.0/12"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l "component=kube-proxy"

    error: error validating "STDIN": error validating data: items[0].apiVersion not set; if you choose to ignore these errors, turn validation off with --validate=false

Perlu panduan untuk menyelesaikannya di v1.6.6 & v1.7.0. Terima kasih.

@boreham

Saya tidak benar-benar tahu apa yang bisa dilakukan kubeadm, karena solusinya tampaknya terkait dengan jaringan yang mendasarinya. Mungkin menambahkan opsi untuk menginformasikan "antarmuka publik" dan "antarmuka pribadi" yang Anda inginkan dan meminta kubeadm merekomendasikan perubahan konfigurasi jaringan?

Saya tidak berpikir kubeadm harus mengeluarkan instruksi konfigurasi khusus OS atau distro untuk jaringan host. Saya pikir itu adalah tanggung jawab operator untuk mengonfigurasi host mereka dengan tepat karena jika tidak maka akan menjadi lubang kelinci. Kami pasti bisa menjadikannya sebagai persyaratan.

Apa yang harus diharapkan kubeadm agar semuanya berfungsi? Bahwa jika pengguna ingin menggunakan NIC non-default, mereka perlu menambahkan rute statis di Linux? Apakah ini kasus penggunaan yang cukup umum bagi kami untuk menambahkannya sebagai persyaratan sistem?

@bboreham Ada ide tentang bagaimana kami dapat meningkatkan dokumentasi kami di sini? Kalau tidak, saya mendukung untuk menutup ini karena:

1. tampaknya berhubungan dengan lingkungan jaringan pengguna, bukan kubeadm
2. tidak ada cara tunggal untuk mengklarifikasi ekspektasi tersebut

[Selain: itu mengganggu saya, saya harus membaca ke atas dan ke bawah dan melalui masalah lain untuk melihat konteksnya kembali. Masalah yang orang ingin selesaikan sama sekali tidak ada hubungannya dengan judul masalah ini]

Dalam dokumen penyiapan, Anda dapat mengatakan "jika Anda memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes Anda tidak dapat dijangkau pada rute default, kami menyarankan Anda untuk menambahkan rute IP sehingga alamat cluster Kubernetes melalui adaptor yang sesuai".

[Selain: itu mengganggu saya, saya harus membaca ke atas dan ke bawah dan melalui masalah lain untuk melihat konteksnya kembali. Masalah yang orang ingin selesaikan sama sekali tidak ada hubungannya dengan judul masalah ini]

Kamu bukan satu-satunya! 😅

Dalam dokumen penyiapan, Anda dapat mengatakan "jika Anda memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes Anda tidak dapat dijangkau pada rute default, kami menyarankan Anda untuk menambahkan rute IP sehingga alamat cluster Kubernetes melalui adaptor yang sesuai".

Keren, saya akan mencoba mengirimkan dokumen PR untuk ini besok dan menutupnya.

Ini sekarang didokumentasikan di https://github.com/kubernetes/website/pull/6265 , jadi saya akan menutupnya.

Masalah ini tampaknya melacak beberapa masalah yang berbeda sekaligus, jadi jika Anda masih mengalami potensi bug, buka masalah baru agar dapat menargetkan akar masalah dengan lebih baik.

FWIW, jika Anda menggunakan kubeadm untuk memulai cluster, jika Anda menentukan "pod-network-cidr", itu akan diteruskan ke kube-proxy saat dimulai sebagai "cluster-cidr". Misalnya, menenun default menggunakan "10.32.0.0/12"..jadi saya menggunakan kubeadm init --kubernetes-version=v.1.8.4 --pod-network-cidr=10.32.0.0/12 yang memulai kube-proxy dengan cluster-cidr=10.32.0.0/12

@bboreham Saya baru dalam hal ini ... Apakah akan ada contoh tentang cara mengimplementasikan saran Anda "tambahkan rute IP sehingga alamat klaster Kubernetes melalui adaptor yang sesuai"?

@ bamb00 gulir ke atas; ada contohnya di https://github.com/kubernetes/kubeadm/issues/102#issuecomment -291532883

Perhatian : jika Anda melakukan langkah yang salah, ini dapat mengakibatkan mesin Anda tidak dapat diakses. Biasanya ini akan muncul kembali setelah reboot, kecuali Anda mengkonfigurasi rute yang buruk untuk berada di sana saat startup.

Saya tidak tahu cara mudah untuk mempelajari konfigurasi jaringan Linux.

@mindscratch perhatikan masalah ini tidak ada hubungannya dengan "cluster-cidr"; itu adalah ikan haring merah yang dimusnahkan sekitar tujuh bulan lalu. Silakan buka masalah baru jika Anda mengalami masalah baru.

Saran semi-serius untuk memperbaiki kasus khusus ini tanpa memerlukan kube-proxy untuk menggunakan ! -s $podCIDR untuk membedakan alamat sumber host:

$ sudo ip ro add local 10.96.0.0/12 table local dev lo
$ sudo iptables -t nat -I KUBE-SERVICES -s 10.96.0.0/12 -d 10.96.0.0/12 -j KUBE-MARK-MASQ

(atau mungkin beberapa variasi dengan ... src 10.96.0.0 eksplisit pada rute lokal ... table local mungkin juga tidak diperlukan dan ide yang buruk)

$ ip ro get 10.96.0.1
local 10.96.0.1 dev lo  src 10.96.0.1 
    cache <local> 
$ curl -vk https://10.96.0.1
...
* Connected to 10.96.0.1 (10.96.0.1) port 443 (#0)

11:32:20.671085 0c:c4:7a:54:0a:e6 > 44:aa:50:04:3d:00, ethertype IPv4 (0x0800), length 74: 10.80.4.149.59334 > 10.80.4.147.6443: Flags [S], seq 2286812584, win 43690, options [mss 65495,sackOK,TS val 209450 ecr 0,nop,wscale 8], length 0
11:32:20.671239 44:aa:50:04:3d:00 > 0c:c4:7a:54:0a:e6, ethertype IPv4 (0x0800), length 74: 10.80.4.147.6443 > 10.80.4.149.59334: Flags [S.], seq 1684666695, ack 2286812585, win 28960, options [mss 1460,sackOK,TS val 208877 ecr 209450,nop,wscale 8], length 0
11:32:20.671315 0c:c4:7a:54:0a:e6 > 44:aa:50:04:3d:00, ethertype IPv4 (0x0800), length 66: 10.80.4.149.59334 > 10.80.4.147.6443: Flags [.], ack 1, win 171, options [nop,nop,TS val 209450 ecr 208877], length 0

Namun, saya tidak tahu apakah itu mencakup semua perilaku yang diharapkan dari aturan MASQ kube-proxy sumber-spesifik itu ...

EDIT: ini juga memiliki semua jenis efek samping untuk koneksi ke layanan VIP yang tidak dikonfigurasi ... mereka akhirnya akan terhubung ke layanan namespace jaringan host yang cocok.

EDIT2: Namun, bahkan itu mungkin lebih baik daripada perilaku koneksi bocor saat ini ke 10.96.XY layanan VIP yang tidak dikonfigurasi melalui rute default ... yang samar-samar mengganggu