Memecahkan masalah jaringan Google Distributed Cloud

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

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Pemecahan masalah konektivitas jaringan

Jaringan GKE Enterprise mengandalkan infrastruktur jaringan fisik Anda. Misalnya, MetalLB bergantung pada switch yang mematuhi ARP gratis, load balancing yang dipaketkan 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 di komponen GKE Enterprise atau di infrastruktur Anda sendiri.

Pertama, tentukan cakupan masalah, lalu coba identifikasi komponen yang terpengaruh. Cakupan masalah dapat berupa salah satu dari tiga kategori: subjek (dari mana), target (ke mana), 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 sekumpulan 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).
  • Entitas dari luar cluster.
  • Entitas di internet.

Lapisan jaringan dapat berupa satu atau beberapa hal berikut:

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

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

Masalah ingress

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

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

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

Memecahkan masalah ingress jaringan dengan meninjau setiap langkah yang dilakukan paket saat bergerak melalui lingkungan Anda. Periksa apakah tindakan dan koneksi yang sesuai ada di sepanjang jalan.

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

  • Apakah paket meninggalkan klien? Jika tidak, Anda mungkin mengalami masalah infrastruktur jaringan.
  • Apakah Anda menggunakan MetalLB? Jika ya, 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 ya, apakah Anda telah memeriksa masalah F5?
  • Apakah penafsiran alamat jaringan (NAT) dilakukan dengan benar? Jika tidak, Anda mungkin 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 mengalir 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.

  1. Gunakan tcpdump untuk memeriksa paket saat keluar dari klien untuk layanan tujuan:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Jika Anda tidak melihat traffic keluar, ini adalah sumber masalahnya.

Apakah paket tiba di node LoadBalancer?

Jika Anda menggunakan MetalLB sebagai load balancer:

  1. 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

  2. Hubungkan ke node menggunakan SSH.

  3. Untuk node MetalLB, gunakan tcpdump untuk meninjau traffic:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Untuk ManualLB, traffic dapat diarahkan 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 antara 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 masalah.

Apakah ada masalah F5 BIG-IP?

Untuk memecahkan masalah F5 BIG-IP, lihat salah satu bagian berikut di 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, hal ini merupakan sinyal adanya masalah pada infrastruktur jaringan fisik Anda. Penyebab umum masalah ini adalah beberapa fitur pembelajaran dataplane lanjutan mengabaikan respons ARP dalam solusi jaringan yang ditentukan oleh software (SDN).

  1. Gunakan tcpdump untuk mendeteksi respons ARP:

    tcpdump -ni any arp

    Coba temukan pesan yang mengiklankan VIP yang bermasalah.

  2. Untuk MetalLB, MetalLB tidak mengirim ARP yang tidak perlu. Frekuensi Anda melihat respons bergantung pada waktu perangkat lain seperti tombol top of rack (ToR) mengirim permintaan ARP.

Apakah NAT dilakukan?

Dataplane v2 / kube-proxy melakukan penafsiran 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 tersebut menggunakan SSH.

  1. Gunakan tcpdump untuk memeriksa apakah VIP Layanan diterjemahkan dengan benar:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. Untuk Dataplane v2, Anda juga dapat terhubung ke pod anetd dan menggunakan alat debug Cilium tersemat:

    cilium monitor --type=drop

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

Apakah paket tiba di node pekerja?

Di node pekerja, paket tiba di antarmuka eksternal, lalu dikirim ke Pod.

  1. 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, paket dienkapsulasi dalam tunnel. Saat di-dekapsulasi, paket akan keluar dari antarmuka jaringan bernama cilium_geneve.

Karena backend Layanan normal berisi beberapa Pod di berbagai node, mungkin sulit memecahkan masalah node mana yang salah. Solusi umum adalah dengan menangkap masalah cukup lama sehingga beberapa paket akhirnya tiba, atau membatasi jumlah backend menjadi satu.

Jika paket tidak pernah sampai di node kerja, hal ini merupakan indikasi masalah infrastruktur jaringan. Hubungi tim infrastruktur jaringan untuk mengetahui alasan paket dihapus di antara node LoadBalancer dan node pekerja. Beberapa masalah umum mencakup hal berikut:

  • Periksa log jaringan yang ditentukan software (SDN). Terkadang, SDN dapat menurunkan paket karena berbagai alasan, seperti segmentasi, checksum salah, atau anti-spoofing.
  • Aturan firewall yang memfilter paket geneve port UDP 6081.

Jika paket tiba di antarmuka eksternal atau antarmuka tunnel node, paket tersebut 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 salah 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. CNI yang berbeda memiliki skema yang berbeda. Untuk Dataplane v2, antarmuka biasanya diberi nama lxcxxxx. Nama tersebut memiliki nomor antarmuka berturut-turut, 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 tiba di Pod, periksa tabel perutean sebagai berikut:

ip route

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

Masalah egress

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

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

  1. Untuk memverifikasi bahwa paket keluar menyamar 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 sumber atau SNAT). Di Dataplane v2, proses ini dicapai dengan ebpf yang dimuat di 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.

  2. 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 tentukan cakupan masalah ke node. Sering kali, grup node tidak dapat berkomunikasi dengan grup node lain.

  1. Di Dataplane v2, periksa konektivitas node dari node saat ini ke semua node lainnya dalam 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, "Masalah konektivitas dari sumber ke tujuan" tidak cukup informatif untuk membantu menyelesaikan masalah, yang dapat berupa error aplikasi, masalah pemilihan rute, atau masalah DNS. Memahami lapisan mana yang mengalami masalah akan membantu memperbaiki komponen yang tepat.

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

  • Error HTTP menunjukkan bahwa masalahnya berada di Lapisan 7.
    • Kode HTTP 40x, 50x, atau error handshake TLS berarti semuanya berfungsi secara normal di Lapisan 4.
  • Error "Connection reset by peer" menunjukkan bahwa ini adalah masalah Lapisan 4.
    • Sering kali, soket jarak jauh tidak dapat menyetujui status koneksi saat ini sehingga mengirim paket RESET. Perilaku ini mungkin merupakan kesalahan dalam pelacakan koneksi, atau NAT.
  • Error "Tidak ada rute ke host" dan "Waktu tunggu koneksi habis" biasanya merupakan masalah Lapisan 3 atau Lapisan 2.
    • Error ini menunjukkan bahwa paket tidak dapat dirutekan dengan benar ke tujuan.

Alat pemecahan masalah yang berguna

DaemonSet terkait jaringan berjalan di node Anda dan dapat menjadi penyebab masalah konektivitas. Namun, kesalahan konfigurasi node, tombol top of rack (ToR), router spine, atau firewall juga dapat menyebabkan masalah. Anda dapat menggunakan alat berikut untuk membantu menentukan cakupan atau lapisan masalah dan menentukan apakah masalahnya ada pada 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 menjangkau tujuan, biasanya masalahnya ada di lapisan 3.

Namun, tidak semua alamat IP dapat di-ping. Misalnya, beberapa VIP 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 semuanya berfungsi di lapisan 3. Anda dapat menggunakan ping untuk memeriksa konektivitas. Meskipun berbeda, F5 juga mendukung ICMP. Anda dapat menggunakan ping untuk memeriksa konektivitas ke VIP F5.

Arping

Arping mirip dengan ping, tetapi berfungsi di lapisan 2. Masalah lapisan 2 dan lapisan 3 sering kali memiliki pesan error yang serupa dari aplikasi. Arping dan ping dapat membantu membedakan masalah. Misalnya, jika sumber dan tujuan berada di subnet yang sama, tetapi Anda tidak dapat melakukan arping pada tujuan, berarti ada masalah Lapisan 2.

arping <ip> yang berhasil akan menampilkan alamat MAC tujuan. Di lapisan 2, alamat ini sering kali menunjukkan masalah infrastruktur fisik. Masalah ini sering kali berupa tombol fisik di antara node.

Arping juga dapat mendeteksi konflik alamat IP. Konflik alamat IP terjadi saat dua komputer dikonfigurasi untuk menggunakan alamat IP yang sama di subnet yang sama, atau VIP digunakan oleh komputer fisik lain. Konflik alamat IP dapat menyebabkan masalah yang bersifat sementara dan sulit dipecahkan. Jika arping <ip> menampilkan lebih dari satu entri alamat MAC, ini merupakan indikasi bahwa ada konflik alamat IP.

Setelah mendapatkan alamat MAC dari arping, Anda dapat menggunakan https://maclookup.app/ untuk mencari produsen alamat MAC. Setiap produsen memiliki awalan MAC, sehingga 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 pemetaan alamat IP ke alamat MAC
  • ip a: mencetak semua antarmuka di komputer

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 dalam 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
    • Cetak semua paket yang melewati stack ebpf anetd.
  • cilium status --all-health
    • Cetak status Cilium, termasuk status konektivitas node ke node. Setiap Pod anetd memeriksa kondisi semua node lain dalam cluster dan dapat membantu menentukan masalah konektivitas node ke node.

Iptables

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

  1. Untuk memecahkan masalah jaringan di tingkat iptables, gunakan perintah berikut:

    iptables -L -v | grep DROP

    Tinjau aturan penghapusan, dan periksa jumlah paket dan jumlah byte untuk melihat apakah jumlahnya meningkat dari waktu ke waktu.

Tcpdump

Tcpdump adalah alat pengambilan paket yang canggih yang menghasilkan banyak data traffic jaringan. Praktik yang umum adalah menjalankan tcpdump dari sumber dan tujuan. Jika paket diambil saat keluar dari node sumber, tetapi tidak pernah diambil di node tujuan, artinya ada sesuatu di antaranya yang menghapus paket. Perilaku ini biasanya menunjukkan bahwa ada sesuatu di infrastruktur fisik Anda yang keliru menghapus paket.

Pemecahan masalah DNS

Masalah resolusi DNS dibagi menjadi 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 memberikan beberapa informasi tentang arsitektur DNS cluster dan tips bermanfaat sebelum Anda mulai memecahkan masalah salah satu kategori ini.

Arsitektur DNS cluster

Layanan DNS Cluster me-resolve permintaan DNS untuk Pod di cluster. CoreDNS menyediakan layanan ini untuk semua versi Google Distributed Cloud.

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

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

  • Jika permintaan ditujukan untuk domain cluster.local, permintaan tersebut adalah nama DNS dalam cluster yang mereferensikan Layanan 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 permintaan bukan untuk domain cluster.local, permintaan tersebut ditujukan untuk domain eksternal.
    • CoreDNS meneruskan permintaan ke server nama upstream. Secara default, CoreDNS menggunakan server nama upstream yang dikonfigurasi di node tempat server tersebut berjalan.

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 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 output perintah dig atau nslookup. 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 tersebut gagal menyelesaikan nama domain:

  • Error NXDOMAIN menunjukkan bahwa server DNS melaporkan bahwa domain tidak ada. Pastikan 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 domain 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 yang lainnya tidak, periksa apakah ada pola yang dapat dikenali, seperti resolusi DNS berfungsi untuk Pod di node yang sama dengan Pod coredns, tetapi tidak di seluruh node. Perilaku ini dapat menunjukkan 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 di 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 mereka tidak dapat me-resolve nama domain cluster.local.

Jika Anda mengalami masalah dengan resolusi nama jaringan host, gunakan langkah-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 dikonfigurasi. Jika telah mengonfigurasi server nama yang berbeda, Anda mungkin melihat inkonsistensi dalam resolusi DNS di node yang berbeda. Pastikan setiap server nama berfungsi satu per satu dengan mengirim permintaan ke setiap server 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 jaringan umum

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 tambahan, hubungi Cloud Customer Care.

Dataplane v2 / Cilium

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

Error ini berarti peristiwa pembuatan Pod telah ditolak oleh agen Cilium karena batas kapasitas. Untuk setiap node, Cilium memiliki batas empat permintaan serentak ke endpoint PUT. Jika ada lonjakan permintaan ke satu node, perilaku ini normal. Agen Cilium harus mengejar permintaan yang tertunda.

Di GKE Enterprise 1.14 dan yang lebih baru, batas kapasitas otomatis disesuaikan dengan kapasitas node. Pembatas kapasitas dapat berkonvergensi 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 aturan Layanan, pelacakan koneksi, identitas Pod, dan Kebijakan Jaringan. Jika peta penuh, agen tidak dapat menyisipkan entri, yang menyebabkan perbedaan antara bidang kontrol dan bidang data. Misalnya, peta Layanan memiliki batas entri 64k.

  1. 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

  2. Jika peta mendekati batas 64 ribu, hapus peta. Contoh berikut akan 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

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

Node tidak siap karena error NetworkPluginNotReady

Jika Pod CNI tidak berjalan di node, Anda mungkin melihat error yang mirip dengan berikut:

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

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

  "Network plugin not installed"

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

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

  1. Periksa status Pod anetd. Tinjau langkah-langkah pemecahan masalah berikut untuk membantu menentukan penyebab masalah:

    • Jika Pod berada dalam status Crashlooping, periksa log untuk mengetahui alasan Pod tidak dapat berjalan dengan benar.
    • Jika Pod berada 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-nya.

Node TIDAK SIAP karena entri ARP yang sudah tidak berlaku

Terkadang, entri ARP yang sudah tidak berlaku di node panel kontrol cluster admin dapat menyebabkan ketidakcocokan pada alamat MAC. Ketidakcocokan alamat ini pada akhirnya dapat menyebabkan waktu tunggu koneksi ke VIP bidang kontrol cluster pengguna terkelola habis. Waktu tunggu koneksi dapat menyebabkan node dengan entri ARP yang sudah tidak berlaku ditandai sebagai NOT READY. Node yang ditandai sebagai NOT READY dapat menunda penginstalan dan upgrade cluster.

Dalam situasi ini, log kubelet di node dengan entri ARP yang sudah tidak berlaku berisi error waktu tunggu TLS handshake seperti berikut:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Gunakan langkah-langkah berikut untuk memverifikasi dan menyelesaikan masalah:

  1. Gunakan SSH untuk terhubung ke node bidang kontrol cluster pengguna.

  2. Verifikasi alamat MAC antarmuka tempat alamat VIP terikat:

    ip a | grep DEVICE_NAME: -A 6

    Ganti DEVICE_NAME dengan nama perangkat jaringan untuk node platform kontrol.

  3. Gunakan SSH untuk terhubung ke node bidang kontrol cluster admin.

  4. Periksa cache ARP di bidang kontrol cluster admin untuk alamat VIP bidang kontrol cluster pengguna:

    ip n | grep VIP_ADDRESS

    Ganti VIP_ADDRESS dengan alamat IP VIP bidang kontrol cluster pengguna (controlPlaneVIP).

    Jika dua perintah ip menampilkan alamat MAC yang berbeda, Anda terpengaruh oleh masalah ini.

  5. Untuk mengatasi masalah ini, hapus cache ARP di node control plane cluster admin:

    ip n flush all

Layanan F5 tidak menerima traffic

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

  1. Pastikan setiap partisi di F5 BIG-IP dikonfigurasi dalam satu cluster, baik cluster admin maupun 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 alih kontrol atas partisi yang sama, dan menghapus Layanan dari cluster lain.

  2. Pastikan bahwa dua Pod berikut sedang berjalan. Setiap Pod yang tidak berjalan menunjukkan error:

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    Load-balancer-f5 dimiliki oleh GKE Enterprise, dan membuat ConfigMap untuk setiap Service jenis LoadBalancer. ConfigMap pada akhirnya akan digunakan oleh pengontrol bigip.

  3. Pastikan ConfigMap ada untuk setiap port dari 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 dalam 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

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

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) merutekan paket ke alamat IP node sebelum diteruskan ke Pod backend.

Rentang port untuk NAT yang digunakan oleh Google Distributed Cloud adalah 32768-65535. Rentang ini membatasi jumlah koneksi paralel menjadi 32.767 per protokol di node tersebut. Setiap koneksi memerlukan entri dalam tabel conntrack. Jika Anda memiliki terlalu banyak koneksi berumur pendek, tabel conntrack akan kehabisan port untuk NAT. Pengumpul sampah akan membersihkan entri yang sudah tidak berlaku, tetapi pembersihan tidak dilakukan secara langsung.

Saat jumlah koneksi di node mendekati 32.767, Anda akan mulai melihat paket yang hilang untuk koneksi yang memerlukan NAT.

Untuk menentukan apakah Anda terpengaruh oleh masalah ini:

  1. 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 bentuk 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 tambahan, hubungi Cloud Customer Care.