Memecahkan masalah GKE pada jaringan Bare Metal

Halaman ini menunjukkan cara menyelesaikan masalah jaringan dengan Google Distributed Cloud Virtual untuk Bare Metal. Informasi dan panduan pemecahan masalah umum disediakan, beserta alat yang disarankan. Informasi pemecahan masalah DNS dan beberapa masalah umum untuk MetalLB juga disertakan.

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.

Pemecahan masalah konektivitas jaringan

Jaringan GKE Enterprise mengandalkan infrastruktur jaringan fisik Anda. Misalnya, MetalLB bergantung pada tombol yang memenuhi ARP yang serampangan, paket load balancing dengan Border Gateway Protocol (BGP) bergantung pada router Anda, dan semua node harus dapat berkomunikasi satu sama lain. Jika mengalami masalah jaringan di cluster GKE, Anda harus mengidentifikasi apakah masalahnya ada pada komponen GKE Enterprise atau pada infrastruktur Anda sendiri.

Pertama-tama, tentukan cakupan masalah, lalu coba identifikasi komponen yang terpengaruh. Cakupan masalah dapat berupa salah satu dari tiga kategori: subjek (dari tempat), target (yang menjadi target), dan lapisan jaringan.

Cakupan subjek dapat berupa salah satu dari berikut:

Semua node (atau Pod hostNetwork) di seluruh cluster.
Semua Pod di seluruh cluster.
Semua Pod di satu node atau kumpulan node.
Semua Pod dari Deployment atau DaemonSet yang sama.
Klien dari luar cluster.

Cakupan target dapat berupa satu atau beberapa hal berikut:

Semua alamat IP Pod lainnya dari cluster yang sama.
Semua alamat IP Pod lainnya dari node yang sama.
VIP Layanan ClusterIP dari cluster yang sama.
VIP Layanan LoadBalancer dari cluster yang sama.
LoadBalancer Lapisan 7 Ingress (Istio).
Node lain dari cluster yang sama.
Nama DNS internal (seperti *.svc.cluster.local).
Nama DNS eksternal (seperti google.com).
Entity dari luar cluster.
Entitas di internet.

Lapisan jaringan dapat berupa satu atau beberapa hal berikut:

Masalah lapisan tautan 2 seperti sistem tetangga, ARP, atau NDP.
Masalah pemilihan rute alamat IP Lapisan 3.
Masalah titik akhir TCP atau UDP Lapisan 4.
Masalah HTTP atau HTTPS Lapisan 7.
Masalah resolusi DNS.

Memahami cakupan masalah membantu mengidentifikasi komponen yang terlibat dalam masalah, dan di lapisan mana masalah tersebut terjadi. Mengumpulkan informasi saat masalah terjadi adalah hal penting karena beberapa masalah bersifat sementara, sehingga snapshot setelah sistem dipulihkan tidak akan menyertakan informasi yang cukup untuk analisis akar masalah.

Masalah masuk

Jika subjeknya adalah klien dari luar cluster dan gagal terhubung ke Layanan LoadBalancer, masalahnya adalah masalah konektivitas Utara-Selatan. Diagram berikut menunjukkan bahwa dalam contoh yang berfungsi, traffic masuk melewati stack dari kiri ke kanan, dan menampilkan traffic kembali melalui stack dari kanan ke kiri.

Traffic masuk akan diteruskan dari pengguna ke infrastruktur fisik, melalui load balancer ke anetd / kube-proxy, lalu ke backend.

Saat ada masalah dengan alur traffic ini, gunakan diagram alir pemecahan masalah berikut untuk membantu mengidentifikasi letak masalahnya:

Pemecahan masalah masuk jaringan dengan meninjau setiap langkah yang diambil paket saat bergerak melalui lingkungan Anda. Periksa apakah ada tindakan dan konektivitas yang sesuai selama prosesnya.

Dalam diagram alir ini, panduan pemecahan masalah berikut membantu menentukan lokasi masalahnya:

Apakah paket meninggalkan klien? Jika tidak, Anda mungkin memiliki masalah infrastruktur jaringan.
Apakah Anda menggunakan MetalLB? Jika demikian, apakah paket tiba di node LB, dan apakah ARP kemudian dikirim dengan benar? Jika tidak, Anda mungkin memiliki masalah infrastruktur jaringan.
Apakah Anda menggunakan F5 BIG-IP, dan jika demikian, apakah Anda sudah memeriksa masalah F5?
Apakah penafsiran alamat jaringan (NAT) dilakukan dengan benar? Jika tidak, kemungkinan Anda memiliki masalah kube-proxy / Dataplane V2.
Apakah paket tiba di node pekerja? Jika tidak, Anda mungkin memiliki masalah Pod-to-Pod Dataplane v2.
Apakah paket tiba di Pod? Jika tidak, Anda mungkin memiliki masalah penerusan lokal Dataplane v2.

Bagian berikut memberikan langkah-langkah untuk memecahkan masalah setiap tahap guna menentukan apakah traffic berjalan dengan benar atau tidak.

Apakah paket meninggalkan klien?

Periksa apakah paket keluar dari klien dengan benar dan melewati router yang dikonfigurasi di infrastruktur jaringan fisik Anda.

Gunakan tcpdump untuk memeriksa paket saat meninggalkan klien menuju layanan tujuan:
```
tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
```
Jika Anda tidak melihat lalu lintas padam, ini adalah sumber masalahnya.

Apakah paket tiba di node LoadBalancer?

Jika Anda menggunakan MetalLB sebagai load balancer:

Lihat log metallb-controller untuk menentukan node load balancer mana yang menayangkan VIP layanan:
```
kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP
```
Hubungkan ke node menggunakan SSH.
Untuk node MetalLB, gunakan tcpdump untuk meninjau traffic:
```
tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
```
Untuk ManualLB, traffic dapat sampai ke node mana pun. Bergantung pada konfigurasi load balancer, Anda dapat memilih satu atau beberapa node. Gunakan tcpdump untuk meninjau traffic:
```
tcpdump -ni any host NODE_IP and port NODE_PORT
```
Perintah ini berbeda untuk setiap jenis load balancer, karena MetalLB tidak melakukan NAT sebelum meneruskan paket ke node.

Jika Anda tidak melihat traffic yang masuk ke node mana pun, ini adalah sumber masalahnya.

Apakah ada masalah F5 BIG-IP?

Untuk memecahkan masalah F5 BIG-IP, lihat salah satu bagian berikut tentang Layanan F5 tidak menerima traffic.

Apakah ARP dikirim dengan benar?

Node load balancer untuk MetalLB mengandalkan ARP untuk mengiklankan VIP layanan. Jika respons ARP dikirim dengan benar, tetapi traffic tidak masuk, itu menandakan adanya masalah dalam infrastruktur jaringan fisik Anda. Penyebab umum dari masalah ini adalah beberapa fitur pembelajaran dataplane lanjutan mengabaikan respons ARP dalam solusi software-defined networking (SDN).

Gunakan tcpdump untuk mendeteksi respons ARP:
```
tcpdump -ni any arp
```
Coba cari pesan yang mengiklankan VIP yang mengalami masalah dengan Anda.
Untuk MetalLB, tindakan tersebut tidak mengirimkan ARP serampangan. Frekuensi respons yang Anda lihat bergantung pada kapan perangkat lain, seperti tombol top of rack (ToR) mengirim permintaan ARP.

Apakah NAT dilakukan?

Dataplane v2 / kube-proxy melakukan terjemahan alamat jaringan tujuan (NAT atau DNAT tujuan) untuk menerjemahkan VIP tujuan ke alamat IP Pod backend. Jika Anda mengetahui node mana yang merupakan backend untuk load balancer, hubungkan ke node menggunakan SSH.

Gunakan tcpdump untuk memeriksa apakah VIP Layanan diterjemahkan dengan benar:
```
tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
```
Untuk Dataplane v2, Anda juga dapat terhubung ke pod anetd dan menggunakan alat debug Cilium yang disematkan:
```
cilium monitor --type=drop
```

Untuk mengetahui informasi selengkapnya, lihat salah satu bagian berikut tentang Masalah Dataplane v2 / Celium.

Apakah paket tiba di node pekerja?

Pada node pekerja, paket tiba di antarmuka eksternal, lalu dikirimkan ke Pod.

Periksa apakah paket tiba di antarmuka eksternal, biasanya bernama eth0 atau ens192, menggunakan tcpdump:
```
tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
```

Untuk Google Distributed Cloud Virtual untuk Bare Metal, paket dienkapsulasi dalam tunnel. Saat didekapsulasi, paket keluar dari antarmuka jaringan bernama cilium_geneve.

Karena backend Service normal berisi beberapa Pod di berbagai node, mungkin sulit untuk memecahkan masalah node mana yang salah. Solusi umumnya adalah menangkap masalah cukup lama sehingga beberapa paket akhirnya tiba, atau membatasi jumlah backend hingga satu.

Jika paket tidak pernah tiba di node pekerjaan, hal tersebut merupakan indikasi adanya masalah infrastruktur jaringan. Periksa dengan tim infrastruktur jaringan untuk mengetahui alasan paket dihapus antara node LoadBalancer dan node pekerja. Beberapa masalah umumnya adalah sebagai berikut:

Periksa log software-defined network (SDN) Anda. Terkadang, SDN dapat menghapus paket karena berbagai alasan, seperti segmentasi, checksum yang salah, atau anti-spoofing.
Aturan firewall yang memfilter paket geneve UDP port 6081.

Jika paket tiba di antarmuka eksternal atau antarmuka tunnel node, paket harus diteruskan ke Pod tujuan. Jika Pod adalah Pod jaringan host, langkah ini tidak diperlukan karena Pod berbagi namespace jaringan dengan node. Jika tidak, penerusan paket tambahan diperlukan.

Setiap Pod memiliki pasangan antarmuka ethernet virtual, yang berfungsi seperti pipa. Paket yang dikirim ke satu ujung antarmuka diterima dari ujung antarmuka yang lain. Salah satu antarmuka dipindahkan ke namespace jaringan Pod, dan diganti namanya menjadi eth0. Antarmuka lainnya disimpan di namespace host. CSI yang berbeda memiliki skema yang berbeda. Untuk Dataplane v2, antarmuka biasanya diberi nama lxcxxxx. Nama-nama tersebut memiliki nomor antarmuka yang berurutan, seperti lxc17 dan lxc18. Anda dapat memeriksa apakah paket tiba di Pod menggunakan tcpdump, atau Anda juga dapat menentukan antarmuka:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Jika paket tiba di node tetapi gagal sampai di Pod, periksa tabel perutean sebagai berikut:

  ip route

Biasanya, setiap Pod harus memiliki entri pemilihan rute yang mengarahkan alamat IP Pod ke antarmuka lxc. Jika entri tidak ada, biasanya berarti datapath CNI mengalami error. Untuk menentukan akar masalahnya, periksa log CNI DaemonSet.

Masalah keluar

Jika traffic dapat masuk ke Pod, Anda mungkin mengalami masalah dengan traffic saat traffic tersebut keluar dari Pod. Diagram berikut menunjukkan bahwa dalam contoh yang berfungsi, traffic yang masuk melewati stack dari kiri ke kanan:

Traffic keluar diteruskan dari Pod melalui antarmuka eksternal host ke infrastruktur fisik, lalu ke layanan eksternal.

Untuk memverifikasi bahwa paket keluar disamarkan dengan benar sebagai alamat IP node, periksa layanan eksternal (Lapisan 4).

Alamat IP sumber paket harus dipetakan dari alamat IP Pod ke alamat IP node dengan penafsiran alamat jaringan sumber (NAT atau SNAT sumber). Di Dataplane v2, proses ini dicapai oleh ebpf yang dimuat pada antarmuka eksternal.

Gunakan tcpdump untuk memeriksa apakah alamat IP sumber diterjemahkan dengan benar dari alamat IP Pod ke alamat IP node:
```
tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT
```
Jika tcpdump menunjukkan bahwa paket disamarkan dengan benar tetapi layanan jarak jauh tidak merespons, periksa koneksi ke layanan eksternal di infrastruktur Anda.
Jika paket keluar disamarkan dengan benar sebagai alamat IP node, periksa konektivitas host eksternal (Lapisan 3) menggunakan tcpdump:
```
tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
```
Pada saat yang sama dengan menjalankan tcpdump, lakukan ping dari salah satu Pod:
```
kubectl exec POD_NAME ping EXTERNAL_IP
```
Jika Anda tidak melihat respons ping, periksa koneksi ke layanan eksternal di infrastruktur Anda.

Masalah dalam cluster

Untuk masalah konektivitas Pod-to-Pod, coba cakupan masalah ini ke node. Sering kali, sekelompok node tidak dapat berkomunikasi dengan grup node lainnya.

Di Dataplane v2, periksa konektivitas node dari node saat ini ke semua node lain di cluster yang sama. Dari dalam Pod anetd, periksa status respons:
```
cilium status --all-health
```

Masalah lapisan jaringan

Mengidentifikasi lapisan jaringan tempat masalah konektivitas terjadi adalah langkah penting. Pesan error seperti, "A konektivitas from a source to a destination" tidak cukup informatif untuk membantu menyelesaikan masalah, yang dapat berupa error aplikasi, masalah perutean, atau masalah DNS. Memahami di lapisan mana masalah terjadi akan membantu memperbaiki komponen yang tepat.

Sering kali, pesan error secara langsung menunjukkan lapisan mana yang menyebabkan masalah. Contoh berikut dapat membantu Anda memecahkan masalah lapisan jaringan:

Kesalahan HTTP menunjukkan bahwa ini adalah masalah Lapisan 7.
- Error handshake TLS akan kode HTTP 40x, 50x, atau TLS berarti semuanya berfungsi biasanya di Lapisan 4.
Error "Koneksi direset oleh peer" menunjukkan bahwa masalah tersebut ada di Lapisan 4.
- Sering kali, soket jarak jauh tidak setuju dengan status koneksi saat ini, sehingga mengirim paket RESET. Perilaku ini bisa menjadi kesalahan dalam pelacakan koneksi, atau NAT.
Error "Tidak ada rute ke host" dan "Waktu tunggu koneksi" biasanya merupakan masalah Lapisan 3 atau Lapisan 2.
- Error ini menunjukkan bahwa paket tidak dapat diarahkan dengan benar ke tujuan.

Alat pemecahan masalah yang berguna

DaemonSet terkait jaringan berjalan pada node Anda dan dapat menjadi penyebab masalah konektivitas. Namun, kesalahan konfigurasi node, tombol top of rack (ToR), router tambahan, atau firewall juga dapat menyebabkan masalah. Anda dapat menggunakan alat berikut untuk membantu menentukan cakupan atau lapisan masalah dan menentukan apakah masalah tersebut berkaitan dengan node GKE Enterprise atau infrastruktur fisik Anda.

Ping

Ping berfungsi di Lapisan 3 (lapisan IP) dan memeriksa rute antara sumber dan tujuan. Jika ping gagal mencapai tujuan, hal itu sering kali berarti masalah berada di lapisan 3.

Namun, tidak semua alamat IP dapat di-ping. Misalnya, beberapa load balancer tidak dapat di-ping jika merupakan load balancer Lapisan 4 murni. Layanan ClusterIP adalah contoh saat VIP mungkin tidak menampilkan respons ping. Di lapisan 4, Layanan ini hanya menampilkan respons ping saat Anda menentukan nomor port, seperti VIP:port.

Load balancer BGPLB dan MetalLB di Google Distributed Cloud Virtual untuk Bare Metal berfungsi di lapisan 3. Anda dapat menggunakan {i>ping<i} untuk memeriksa konektivitas. Meskipun F5 berbeda, ia juga mendukung ICMP. Anda dapat menggunakan ping untuk memeriksa konektivitas ke F5 VIP.

Arping

Arping mirip dengan {i>ping<i}, hanya saja ia berfungsi di lapisan 2. Masalah Lapisan 2 dan lapisan 3 sering kali memiliki pesan error yang serupa dari aplikasi. Arping dan {i>ping<i} dapat membantu membedakan masalah. Misalnya, jika sumber dan tujuan berada di subnet yang sama, tetapi Anda tidak dapat mem-arping tujuan, ini masalah Lapisan 2.

arping <ip> yang berhasil akan menampilkan alamat MAC tujuan. Pada lapisan 2, alamat ini sering menunjukkan masalah infrastruktur fisik. Masalah ini sering kali merupakan peralihan fisik antar-node.

Arping juga dapat mendeteksi konflik alamat IP. Konflik alamat IP terjadi ketika dua mesin dikonfigurasi untuk menggunakan alamat IP yang sama di subnet yang sama, atau VIP digunakan oleh mesin fisik lainnya. Konflik alamat IP dapat menimbulkan masalah sesekali yang sulit untuk dipecahkan. Jika arping <ip> menampilkan lebih dari satu entri alamat MAC, hal ini merupakan indikasi bahwa ada konflik alamat IP.

Setelah mendapatkan alamat MAC dari arping, Anda dapat menggunakan https://maclookup.app/ untuk mencari tahu produsen alamat MAC. Setiap produsen memiliki awalan MAC, jadi Anda dapat menggunakan informasi ini untuk membantu menentukan perangkat mana yang mencoba menggunakan alamat IP yang sama. Misalnya, VMware memiliki blok 00:50:56, sehingga alamat MAC 00:50:56:xx:yy:zz adalah VM di lingkungan vSphere Anda.

`iproute2`

CLI ip untuk iproute2 memiliki banyak subperintah yang berguna, seperti berikut:

ip r: mencetak tabel rute
ip n: mencetak tabel tetangga untuk alamat IP ke pemetaan alamat MAC
ip a: mencetak semua antarmuka pada mesin

Rute yang hilang atau entri yang hilang di tabel tetangga dapat menyebabkan masalah konektivitas dari node. Anetd mengelola tabel rute dan tabel tetangga. Kesalahan konfigurasi pada tabel tersebut dapat menyebabkan masalah konektivitas.

Cilium / Hubble CLI untuk Dataplane v2

Setiap Pod anetd memiliki beberapa alat proses debug yang berguna untuk masalah konektivitas:

cilium monitor --type=drop
- Mencetak log untuk setiap paket yang dihapus oleh anetd / Cilium.
hubble observe
- Mencetak semua paket yang melalui tumpukan ebpf anetd.
cilium status --all-health
- Mencetak status Cilium, termasuk status konektivitas node-ke-node. Setiap Pod yang di-anetd akan memeriksa kondisi semua node lain di cluster dan dapat membantu menentukan masalah konektivitas node-ke-node.

Iptable

Iptable digunakan di banyak komponen dan subsistem Kubernetes. kube-proxy menggunakan iptable untuk menerapkan resolusi layanan.

Untuk memecahkan masalah jaringan di tingkat iptables, gunakan perintah berikut:
```
iptables -L -v | grep DROP
```
Tinjau aturan operasi lepas, lalu periksa jumlah paket dan jumlah byte untuk melihat apakah meningkat dari waktu ke waktu.

{i>Tcpdump<i}

{i>Tcpdump<i} adalah alat penangkapan paket yang canggih yang menghasilkan banyak data lalu lintas jaringan. Praktik yang umum adalah menjalankan tcpdump dari sumber dan tujuan. Jika sebuah paket diambil saat meninggalkan node sumber tetapi tidak pernah ditangkap di node tujuan, artinya sesuatu di antaranya akan menurunkan paket. Perilaku ini biasanya menunjukkan bahwa ada sesuatu di infrastruktur fisik Anda yang keliru menempatkan paket.

Pemecahan masalah DNS

Masalah resolusi DNS terbagi dalam dua kategori utama:

Pod Reguler, yang menggunakan server DNS dalam cluster.
Pod atau node jaringan host, yang tidak menggunakan server DNS dalam cluster

Bagian berikut ini memberikan beberapa informasi tentang arsitektur DNS cluster dan tips berguna sebelum Anda mulai memecahkan masalah salah satu kategori ini.

Arsitektur cluster DNS

Layanan DNS Cluster menyelesaikan permintaan DNS untuk Pod di cluster. CoreDNS menyediakan layanan ini untuk semua versi Google Distributed Cloud Virtual untuk Bare Metal.

Setiap cluster memiliki dua Pod coredns atau lebih, dan penskala otomatis yang bertanggung jawab untuk menskalakan jumlah Pod DNS relatif terhadap ukuran cluster. Ada juga layanan bernama kube-dns yang melakukan load balancing terhadap permintaan di antara semua Pod coredns backend.

Sebagian besar Pod memiliki DNS upstream yang dikonfigurasi ke alamat IP Layanan kube-dns, dan Pod mengirim permintaan DNS ke salah satu Pod coredns. Permintaan DNS dapat dikelompokkan ke dalam salah satu tujuan berikut:

Jika permintaan tersebut ditujukan untuk domain cluster.local, nama tersebut adalah nama DNS dalam cluster yang mereferensikan Service atau Pod dalam cluster.
- CoreDNS memantau api-server untuk semua Layanan dan Pod di cluster, dan merespons permintaan untuk domain cluster.local yang valid.
Jika bukan untuk domain cluster.local, permintaan dibuat untuk domain eksternal.
- CoreDNS meneruskan permintaan ke server nama upstream. Secara default, CoreDNS menggunakan server nama upstream yang dikonfigurasi pada node tempat CoreDNS dijalankan.

Untuk mengetahui informasi selengkapnya, lihat ringkasan cara kerja dan konfigurasi DNS di Kubernetes.

Tips pemecahan masalah DNS

Untuk memecahkan masalah DNS, Anda dapat menggunakan alat dig dan nslookup. Alat ini memungkinkan Anda mengirim permintaan DNS untuk menguji apakah resolusi DNS berfungsi dengan benar. Contoh berikut menunjukkan cara menggunakan dig dan nslookup untuk memeriksa masalah resolusi DNS.

Gunakan dig atau nslookup untuk mengirim permintaan sebesar google.com:
```
dig google.com
nslookup google.com
```
Gunakan dig untuk mengirim permintaan kubernetes.default.svc.cluster.local ke server 192.168.0.10:
```
dig @192.168.0.10 kubernetes.default.svc.cluster.local
```
Anda juga dapat menggunakan nslookup untuk melakukan pencarian DNS yang sama seperti perintah dig sebelumnya:
```
nslookup kubernetes.default.svc.cluster.local 192.168.0.10
```
Tinjau {i>output<i} dari perintah {i>dig<i} atau {i>nslookup<i}. Jika Anda menerima respons yang salah, atau tidak ada respons, hal ini menunjukkan masalah resolusi DNS.

Pod Reguler

Langkah pertama untuk men-debug masalah DNS adalah menentukan apakah permintaan berhasil masuk ke Pod coredns atau tidak. Sering kali masalah konektivitas cluster umum muncul sebagai masalah DNS karena permintaan DNS adalah jenis traffic pertama yang dikirim beban kerja.

Tinjau pesan error dari aplikasi Anda. Error seperti io timeout atau yang serupa menunjukkan tidak ada respons dan masalah konektivitas jaringan umum.

Pesan error yang menyertakan kode error DNS seperti NXDOMAIN atau SERVFAIL menunjukkan bahwa ada konektivitas ke server DNS dalam cluster, tetapi server gagal me-resolve nama domain:

Error NXDOMAIN menunjukkan bahwa server DNS melaporkan bahwa domain tersebut tidak ada. Verifikasi bahwa nama domain yang diminta aplikasi Anda valid.
Error SERVFAIL atau REFUSED menunjukkan bahwa server DNS mengirim kembali respons, tetapi tidak dapat me-resolve domain atau memvalidasi bahwa server tersebut tidak ada. Untuk informasi selengkapnya, periksa log Pod coredns.

Anda dapat menemukan alamat IP layanan kube-dns menggunakan perintah berikut:

kubectl -n kube-system get svc kube-dns

Dari Pod tempat DNS tidak berfungsi, coba kirim permintaan DNS ke alamat IP ini menggunakan dig atau nslookup seperti yang dijelaskan di bagian sebelumnya:

Jika permintaan ini tidak berhasil, coba kirim permintaan ke alamat IP setiap Pod coredns.
Jika beberapa Pod berfungsi tetapi tidak yang lain, periksa apakah ada pola yang jelas, seperti resolusi DNS berfungsi untuk Pod pada node yang sama dengan Pod coredns, tetapi tidak di seluruh node. Perilaku ini dapat menunjukkan adanya beberapa masalah konektivitas dalam cluster.

Jika CoreDNS tidak dapat me-resolve nama domain eksternal, lihat bagian berikut untuk memecahkan masalah Pod jaringan host. CoreDNS berperilaku seperti Pod jaringan host dan menggunakan server DNS upstream node untuk resolusi nama.

Pod atau node jaringan host

Pod jaringan host dan node menggunakan server nama yang dikonfigurasi pada node untuk resolusi DNS, bukan layanan DNS dalam cluster. Bergantung pada OS, server nama ini dikonfigurasi di /etc/resolv.conf atau /run/systemd/resolve/resolv.conf. Konfigurasi ini berarti bahwa domain tersebut tidak dapat me-resolve nama domain cluster.local.

Jika mengalami masalah dengan resolusi nama jaringan host, gunakan langkah pemecahan masalah di bagian sebelumnya untuk menguji apakah DNS berfungsi dengan benar untuk server nama upstream Anda.

Pastikan semua node memiliki kumpulan server yang sama yang telah dikonfigurasi. Jika memiliki konfigurasi server nama yang berbeda, Anda mungkin melihat inkonsistensi dalam resolusi DNS pada node yang berbeda. Pastikan setiap server nama berfungsi secara individual dengan mengirim permintaan ke setiap server nama menggunakan dig atau nslookup. Jika beberapa server nama berfungsi, tetapi yang lainnya tidak, Anda akan melihat jenis kegagalan resolusi DNS yang tidak konsisten ini.

Masalah umum jaringan

Bagian berikut menjelaskan beberapa masalah jaringan umum yang mungkin Anda temui. Untuk membantu menyelesaikan masalah Anda, ikuti panduan pemecahan masalah yang sesuai. Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.

Dataplane v2 / Cilium

Error umum: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Error ini berarti bahwa peristiwa pembuatan Pod telah ditolak oleh agen Cilium karena adanya pembatasan kapasitas. Untuk setiap node, Cilium memiliki batas empat permintaan serentak ke endpoint PUT. Jika ada burst permintaan ke satu node, perilaku ini adalah hal yang wajar. Agen Cilium harus mengejar permintaan yang tertunda.

Di GKE Enterprise 1.14 dan yang lebih baru, batas kapasitas secara otomatis disesuaikan dengan kapasitas node. Pembatas kapasitas dapat digabungkan ke jumlah yang lebih wajar, dengan batas kapasitas yang lebih tinggi untuk node yang lebih canggih.

Error umum: Ebpf map size is full

Dataplane v2 menyimpan status dalam peta eBFP. Status mencakup Service, pelacakan koneksi, identitas Pod, dan aturan Kebijakan Jaringan. Jika peta penuh, agen tidak dapat menyisipkan entri, sehingga menimbulkan perbedaan antara bidang kontrol dan bidang data. Misalnya, peta Layanan memiliki batas entri 64 ribu.

Untuk memeriksa entri peta eBFP dan ukurannya saat ini, gunakan bpftool. Contoh berikut memeriksa peta load balancer:

bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

Jika peta mendekati batas 64k, bersihkan peta tersebut. Contoh berikut membersihkan peta load balancer:

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

Untuk mengisi ulang status ke peta eBFP, mulai ulang anetd.

Node belum dibaca karena error NetworkPluginNotReady

Jika Pod CNI tidak berjalan pada node, Anda mungkin melihat error yang serupa dengan berikut:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Node mungkin juga berada dalam status belum dibaca, dengan error yang mirip dengan contoh berikut:

  "Network plugin not installed"

Saat node diinisialisasi, kubelet akan menunggu hingga beberapa peristiwa terjadi sebelum menandai node tersebut sebagai Ready. Salah satu peristiwa yang diperiksa kubelet adalah plugin Container Network Interface (CNI) diinstal. Plugin CNI harus diinstal oleh anetd menggunakan container init untuk menginstal biner CNI dan konfigurasi CNI ke direktori host yang diperlukan.

Untuk memecahkan masalah ini, periksa alasan Pod tersebut tidak berjalan pada node. Biasanya, error bukan disebabkan oleh masalah jaringan. Pod tersebut berjalan di jaringan host, sehingga tidak ada dependensi jaringan.

Periksa status Pod anetd. Tinjau langkah-langkah pemecahan masalah berikut untuk membantu menentukan penyebab masalah tersebut:
- Jika Pod berada dalam status Crashlooping, periksa log untuk mengetahui alasan Pod tidak dapat berjalan dengan benar.
- Jika Pod dalam status Pending, gunakan kubectl describe dan tinjau peristiwa Pod. Misalnya, Pod mungkin tidak memiliki resource seperti Volume.
- Jika Pod dalam status Running, periksa log dan konfigurasi. Beberapa implementasi CNI menyediakan opsi untuk menonaktifkan penginstalan CNI, seperti di Cilium.
- Ada opsi konfigurasi di anetd yang disebut custom-cni-conf. Jika setelan ini dikonfigurasi sebagai true, anetd tidak akan menginstal biner CNI.

Layanan F5 tidak menerima traffic

Jika tidak ada traffic yang diteruskan ke Layanan F5, tinjau langkah-langkah pemecahan masalah berikut:

Pastikan setiap partisi di F5 BIG-IP dikonfigurasi dalam satu cluster, baik admin maupun cluster pengguna. Jika satu partisi digunakan bersama oleh beberapa cluster yang berbeda, Anda akan mengalami gangguan koneksi yang terputus-putus. Perilaku ini terjadi karena dua cluster mencoba mengambil kontrol atas partisi yang sama, dan menghapus Layanan dari cluster lain.
Pastikan dua Pod berikut berjalan. Setiap Pod yang tidak berjalan menunjukkan error:
```
Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj
```
Load-balancer-f5 yang dimiliki oleh GKE Enterprise, dan membuat ConfigMaps untuk setiap Service jenis LoadBalancer. ConfigMap pada akhirnya digunakan oleh pengontrol bigip.

Pastikan ConfigMap ada untuk setiap port setiap Layanan. Misalnya, dengan port berikut:

Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

Layanan kube-server akan terlihat seperti contoh berikut:

Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

Bagian data di ConfigMap harus memiliki VIP dan port frontend, seperti yang ditunjukkan pada contoh berikut:

data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

Periksa log dan metrik instance BIG-IP Anda. Jika ConfigMap dikonfigurasi dengan benar, tetapi instance BIG-IP gagal menerima konfigurasi, hal ini dapat menjadi masalah F5. Untuk masalah yang terjadi di dalam instance BIG-IP, hubungi dukungan F5 untuk mendiagnosis dan memecahkan masalah tersebut.

Kegagalan NAT dengan terlalu banyak koneksi paralel

Untuk node tertentu dalam cluster Anda, alamat IP node menyediakan terjemahan alamat jaringan (NAT) untuk paket yang dirutekan ke alamat di luar cluster. Demikian pula, saat paket masuk memasuki node load balancing yang dikonfigurasi untuk menggunakan load balancing paket (spec.loadBalancer.mode: bundled), penafsiran alamat jaringan sumber (SNAT) akan merutekan paket tersebut ke alamat IP node sebelum diteruskan ke Pod backend.

Rentang port untuk NAT yang digunakan oleh GDCV untuk Bare Metal adalah 32768-65535. Rentang ini membatasi jumlah koneksi paralel hingga 32.767 per protokol pada node tersebut. Setiap koneksi memerlukan entri dalam tabel koneksi. Jika Anda memiliki terlalu banyak koneksi berumur pendek, tabel conntrack kehabisan port untuk NAT. Pembersih sampah memori membersihkan entri yang sudah tidak berlaku, tetapi pembersihan tidak langsung dilakukan.

Jika jumlah koneksi pada node Anda mendekati 32.767, Anda akan mulai melihat penurunan paket untuk koneksi yang memerlukan NAT.

Untuk mengetahui apakah Anda terkena dampak masalah ini:

Jalankan perintah berikut di Pod anetd pada node yang bermasalah:

kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

Anda akan melihat error dalam formulir berikut:

No mapping for NAT masquerade DROPPED

Sebagai solusi untuk masalah ini, distribusikan ulang traffic Anda ke node lain.

Langkah selanjutnya

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.