Memecahkan masalah jaringan Google Distributed Cloud

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

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Pemecahan masalah konektivitas jaringan

Jaringan GKE Enterprise mengandalkan infrastruktur jaringan fisik Anda. Sebagai contoh, MetalLB bergantung di {i>switch<i} Anda yang menerapkan ARP yang serampangan, paket {i>load balancing<i} dengan Border {i>Gateway Protocol<i} (BGP) bergantung pada {i> router<i} Anda, dan semua {i>node<i} harus dapat berkomunikasi satu sama lain. Saat Anda mengalami masalah jaringan GKE cluster, Anda harus mengidentifikasi apakah masalahnya ada di GKE Enterprise atau di infrastruktur Anda sendiri.

Pertama, tentukan ruang lingkup masalah, lalu coba identifikasi dampak komponen. 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 hal berikut:

  • Semua node (atau hostNetwork Pod) di seluruh cluster.
  • Semua Pod di seluruh cluster.
  • Semua Pod pada 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.
  • ClusterIP Service VIP 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.
  • Entity 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 titik akhir TCP atau UDP lapisan 4.
  • Masalah HTTP atau HTTPS lapisan 7.
  • Masalah resolusi DNS.

Memahami ruang lingkup masalah membantu mengidentifikasi komponen yang terlibat sumbernya, dan di lapisan mana masalah itu terjadi. Mengumpulkan informasi saat masalah yang terjadi bersifat penting karena beberapa masalah bersifat sementara, jadi snapshot setelah sistem pulih tidak akan menyertakan informasi yang cukup untuk akar masalahnya. analisis data.

Masalah traffic masuk

Jika subjek adalah klien dari luar cluster dan gagal terhubung ke Layanan LoadBalancer, ini adalah masalah konektivitas Utara-Selatan. Hal berikut diagram menunjukkan bahwa dalam contoh yang berfungsi, lalu lintas masuk melalui menumpuk dari kiri ke kanan, dan mengembalikan lalu lintas kembali melalui tumpukan dari kanan ke kiri.

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

Saat terjadi masalah dengan arus lalu lintas ini, gunakan diagram alir pemecahan masalah untuk membantu mengidentifikasi letak masalahnya:

Memecahkan masalah masuknya jaringan dengan meninjau setiap langkah yang diambil paket saat bergerak melalui lingkungan Anda. Periksa apakah tindakan dan konektivitas ada di sepanjang jalan.

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

  • Apakah paket meninggalkan klien? Jika tidak, kemungkinan Anda memiliki jaringan masalah infrastruktur.
  • Apakah Anda menggunakan MetalLB? Jika ya, apakah paket itu sampai di {i>node<i} LB, dan ARP kemudian dikirim dengan benar? Jika tidak, Anda mungkin memiliki infrastruktur jaringan masalah performa.
  • Apakah Anda menggunakan F5 BIG-IP, dan jika ya, sudahkah Anda memeriksa masalah F5?
  • Apakah penafsiran alamat jaringan (NAT) dilakukan dengan benar? Jika tidak, Anda mungkin memiliki masalah kube-proxy / Dataplane V2.
  • Apakah paket sudah sampai di node pekerja? Jika tidak, Anda mungkin memiliki Pod-ke-Pod Dataplane v2 masalah performa.
  • Apakah paket sudah sampai di Pod? Jika tidak, Anda mungkin memiliki Lokal Dataplane v2 penerusan panggilan.

Bagian berikut memberikan langkah-langkah untuk memecahkan masalah setiap tahap untuk menentukan apakah lalu lintas data mengalir dengan benar atau tidak.

Apakah paket meninggalkan klien?

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

  1. Gunakan tcpdump untuk memeriksa paket karena paket tersebut akan dikirim dari klien layanan tujuan:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

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

Apakah paket tiba di node LoadBalancer?

Jika Anda menggunakan MetalLB sebagai load balancer:

  1. Lihat log metallb-controller untuk menentukan node load balancer melayani 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 mendarat di node mana pun. Tergantung beban 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 di antara jenis load balancer karena MetalLB tidak lakukan NAT sebelum meneruskan paket ke {i>node<i}.

    Jika Anda tidak melihat lalu lintas yang menuju ke {i>node<i} 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 keluar, tapi lalu lintas tidak masuk, itu adalah pertanda adanya masalah pada fisik infrastruktur jaringan. Penyebab umum dari masalah ini adalah beberapa fitur pembelajaran {i>dataplane<i} mengabaikan respons ARP dalam jaringan yang ditentukan perangkat lunak (SDN).

  1. Gunakan tcpdump untuk mendeteksi respons ARP:

    tcpdump -ni any arp

    Coba temukan pesan yang mengiklankan VIP yang bermasalah dengan Anda.

  2. Untuk MetalLB, proses ini tidak mengirim ARP yang serampangan. Frekuensi Anda melihat respons bergantung pada saat perangkat lain seperti tombol rak atas (ToR) mengirimkan ARP permintaan.

Apakah NAT dilakukan?

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

  1. Gunakan tcpdump untuk memeriksa apakah Service VIP 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 yang disematkan:

    cilium monitor --type=drop

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

Apakah paket tiba di node pekerja?

Pada node pekerja, paket tiba di antarmuka eksternal dan kemudian yang dikirimkan 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. Ketika paket itu didekapsulasi, kode ini berasal dari antarmuka jaringan bernama cilium_geneve.

Karena backend Service normal berisi beberapa Pod di node yang berbeda, mungkin sulit untuk memecahkan masalah {i>node<i} mana yang bermasalah. Solusi yang umum adalah dengan menangkap masalah cukup lama sehingga beberapa paket akhirnya tiba, atau membatasi jumlah backend menjadi satu.

Jika paket tidak pernah sampai di {i>node<i} kerja, itu adalah indikasi jaringan masalah infrastruktur. Hubungi tim infrastruktur jaringan untuk mengetahui alasannya paket ditempatkan di antara node LoadBalancer dan worker node. Beberapa hal yang umum permasalahan tersebut meliputi:

  • Periksa log software-defined (SDN) Anda. Terkadang, SDN bisa menghapus paket karena berbagai alasan, seperti segmentasi, {i>checksum<i} yang salah, atau anti-spoofing.
  • Aturan firewall yang memfilter paket geneve UDP port 6081.

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

Setiap Pod memiliki pasangan antarmuka ethernet virtual, yang bekerja seperti pipa. Sebuah paket dikirim ke salah satu ujung antarmuka diterima dari ujung lain dari dalam antarmuka berbasis web yang sederhana. Salah satu antarmuka dipindahkan ke namespace jaringan Pod, dan diganti namanya menjadi eth0. Antarmuka yang lain disimpan di namespace host. Berbeda CNI memiliki skema yang berbeda. Untuk Dataplane v2, antarmuka biasanya dinamai sebagai lxcxxxx. Nama tersebut memiliki nomor antarmuka yang berurutan, seperti lxc17 dan lxc18. Anda dapat memeriksa apakah paket tersebut 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 {i>routing table <i}sebagai berikut:

ip route

Biasanya, setiap Pod harus memiliki rute entri perutean alamat IP Pod ke Antarmuka lxc. Jika entri tidak ada, biasanya berarti jalur data CNI telah mengalami {i>error.<i} Untuk menentukan akar masalah, periksa log CNI DaemonSet.

Masalah traffic keluar

Jika traffic dapat masuk ke Pod, Anda mungkin akan mengalami masalah dengan traffic yang akan keluar dari Pod. Diagram berikut menunjukkan bahwa dalam contoh kerja lalu lintas masuk berjalan melalui tumpukan dari kiri ke kanan:

Traffic keluar yang diteruskan dari Pod melalui antarmuka eksternal host ke infrastruktur fisik dan kemudian ke layanan eksternal.

  1. Untuk memverifikasi bahwa paket keluar dengan benar menyamar sebagai IP {i>node<i} alamat IP eksternal, periksa layanan eksternal (Lapisan 4).

    Alamat IP sumber paket harus dipetakan dari alamat IP Pod ke alamat IP {i>node<i} dengan penafsiran alamat jaringan sumber ({i>source NAT<i} atau JAM). Pada Dataplane v2, proses ini dilakukan 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 remote control layanan tidak merespons, periksa koneksi ke layanan eksternal infrastruktur Anda.

  2. Jika paket keluar disamarkan dengan benar sebagai alamat IP {i>node<i}, memeriksa konektivitas host eksternal (Lapisan 3) menggunakan tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Secara bersamaan 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 eksternal di infrastruktur Anda.

Masalah dalam cluster

Untuk masalah konektivitas Pod-ke-Pod, cobalah untuk mencakup masalah ke node. Sering kali, kelompok {i>node<i} tidak dapat berkomunikasi dengan kelompok {i>node<i} lainnya.

  1. Di Dataplane v2, periksa konektivitas {i>node<i} dari {i>node<i} saat ini ke semua {i>node<i} node di cluster yang sama. Dari dalam Pod anetd, periksa health status:

    cilium status --all-health

Masalah lapisan jaringan

Mengidentifikasi pada lapisan jaringan mana 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 {i>error<i} aplikasi, masalah {i>routing<i}, 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 terjadi. Tujuan contoh berikut dapat membantu Anda memecahkan masalah terkait lapisan jaringan:

  • Error HTTP menunjukkan bahwa masalah ini berkaitan dengan Lapisan 7.
    • Error kode HTTP 40x, 50x, atau handshake TLS berarti semuanya berfungsi biasanya di Lapisan 4.
  • Error "Connection reset by peer" menunjukkan bahwa masalah ini terjadi pada Lapisan 4.
    • Sering kali, soket jarak jauh tidak sesuai dengan keadaan saat ini dari yang terhubung, lalu mengirim paket RESET. Perilaku ini bisa menjadi kesalahan pelacakan koneksi, atau NAT.
  • Error "No route to host" dan "Connection timeout" biasanya adalah Lapisan 3 atau Masalah Lapisan 2.
    • Pesan ini menunjukkan bahwa paket tidak dapat diarahkan dengan benar ke tujuan.

Alat pemecahan masalah yang berguna

DaemonSets terkait jaringan berjalan pada {i>node<i} Anda dan dapat menjadi penyebab masalah konektivitas. Namun, kesalahan konfigurasi node Anda, yaitu top of rack (ToR) {i>switch<i}, {i>router<i} tulang belakang, atau {i>firewall<i} juga dapat menyebabkan masalah. Anda dapat menggunakan alat berikut untuk membantu menentukan ruang lingkup atau lapisan isu dan menentukan apakah ada masalah dengan node GKE Enterprise atau infrastruktur IT.

Ping

{i>Ping<i} bekerja di Lapisan 3 (lapisan IP) dan memeriksa rute antara sumber dan tujuan. Jika {i>ping<i} gagal mencapai tujuan, itu sering kali berarti masalahnya di lapisan 3.

Namun, tidak semua alamat IP dapat di-ping. Misalnya, beberapa load balancer VIP tidak dapat di-ping jika merupakan load balancer Lapisan 4 murni. Layanan ClusterIP contoh di mana VIP mungkin tidak menampilkan respons {i>ping<i}. Pada lapisan 4, ini Layanan hanya menampilkan respons ping jika Anda menentukan nomor port, seperti VIP:port.

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

Arping

Arping mirip dengan {i>ping<i}, hanya saja berfungsi di lapisan 2. Lapisan 2 dan lapisan 3 sering kali memiliki pesan {i>error<i} yang serupa dari aplikasi. {i>Arping<i} dan {i>ping<i} dapat membantu membedakan masalah. Misalnya, jika sumber dan tujuannya di subnet yang sama tetapi Anda tidak dapat melakukan {i> arping<i} tujuannya, ini adalah 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 berupa peralihan fisik antara node.

Arping juga dapat mendeteksi konflik alamat IP. Konflik alamat IP adalah ketika dua komputer dikonfigurasikan untuk menggunakan alamat IP yang sama di subnet yang sama, atau alamat VIP digunakan oleh komputer fisik lainnya. Konflik alamat IP dapat menimbulkan masalah yang terputus-putus yang sulit untuk dipecahkan. Jika arping <ip> menampilkan nilai lainnya dari satu entri alamat MAC, itu adalah indikasi bahwa ada alamat IP konflik.

Setelah mendapatkan alamat MAC dari {i>arping<i}, Anda dapat menggunakan https://maclookup.app/ untuk mencari produsen alamat MAC. Setiap produsen memiliki MAC sehingga Anda dapat menggunakan informasi ini untuk membantu menentukan perangkat mana yang sedang 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 mesin

Rute yang hilang atau entri yang hilang di tabel tetangga dapat menyebabkan konektivitas masalah 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
    • Cetak log untuk setiap paket yang dihapus oleh anetd / Cilium.
  • hubble observe
    • Mencetak semua paket yang melewati tumpukan ebpf anetd.
  • cilium status --all-health
    • Mencetak status Cilium, termasuk status konektivitas node-ke-node. Masing-masing Pod anetd memeriksa health semua node lain dalam cluster dan dapat membantu menentukan apakah ada masalah konektivitas {i>node-to-node<i}.

Iptable

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

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

    iptables -L -v | grep DROP

    Tinjau aturan pelepasan, lalu periksa jumlah paket dan jumlah byte untuk melihat apakah mereka meningkat seiring waktu.

{i>Tcpdump<i}

{i>Tcpdump<i} adalah alat penangkapan paket yang ampuh yang menghasilkan banyak jaringan data lalu lintas data. Praktik yang umum adalah menjalankan {i>tcpdump<i} dari sumber tujuan. Jika sebuah paket ditangkap saat meninggalkan {i>node<i} sumber tetapi tidak pernah ditangkap di {i>node<i} tujuan, itu berarti bahwa sesuatu yang berada di tengah penurunan paket. Perilaku ini biasanya menunjukkan bahwa sesuatu di fisik Anda infrastruktur membuang paket secara tidak sengaja.

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 menyediakan beberapa informasi tentang arsitektur DNS cluster dan kiat berguna sebelum Anda mulai memecahkan masalah salah satu kategori tersebut.

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 relatif terhadap ukuran cluster. Ada juga layanan bernama kube-dns yang melakukan load balancing permintaan antara semua Pod coredns backend.

Sebagian besar Pod memiliki DNS upstream yang dikonfigurasi ke IP Layanan kube-dns dan Pod akan 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 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 permintaan bukan untuk domain cluster.local, maka permintaan ini untuk domain eksternal {i>Directory<i}
    • CoreDNS meneruskan permintaan ke server nama upstream. Secara {i>default<i}, CoreDNS menggunakan server nama upstream yang dikonfigurasi pada simpul yang berjalan di.

Untuk 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. Ini memungkinkan Anda mengirim permintaan DNS untuk menguji apakah resolusi DNS bekerja dengan benar. Tujuan contoh berikut menunjukkan cara menggunakan dig dan nslookup untuk memeriksa DNS penyelesaian masalah.

  • Gunakan dig atau nslookup untuk mengirim permintaan terkait google.com:

    dig google.com
nslookup google.com

  • Gunakan dig untuk mengirim permintaan bagi kubernetes.default.svc.cluster.local untuk 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 sebelumnya Perintah dig:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    Tinjau output perintah dig atau nslookup. Jika Anda menerima informasi respons, atau tidak ada respons, ini menunjukkan adanya masalah resolusi DNS.

Pod Reguler

Langkah pertama untuk men-debug masalah DNS adalah menentukan apakah permintaan sampai Pod coredns atau tidak. Sering kali masalah konektivitas cluster umum muncul sebagai Masalah DNS karena permintaan DNS adalah jenis lalu lintas pertama yang harus ditangani dikirimkan.

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

Pesan error yang menyertakan kode error DNS seperti NXDOMAIN atau SERVFAIL menunjukkan adanya konektivitas ke server DNS dalam cluster, tetapi server gagal me-resolve 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 balik tetapi tidak dapat me-resolve domain atau memvalidasi bahwa memang tidak ada. Untuk mengetahui informasi selengkapnya, periksa log Pod coredns.

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

kubectl -n kube-system get svc kube-dns

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

  • Jika permintaan ini tidak berhasil, coba kirim permintaan ke alamat IP masing-masing Pod coredns.
  • Jika beberapa Pod berfungsi, tetapi tidak, periksa apakah ada pola yang jelas, misalnya resolusi DNS berfungsi untuk Pod di node yang sama dengan Pod coredns, tetapi tidak pada seluruh {i>node<i}. Perilaku ini dapat mengindikasikan beberapa cluster dalam cluster masalah konektivitas.

Jika CoreDNS tidak dapat me-resolve nama domain eksternal, lihat bagian berikut untuk memecahkan masalah Pod jaringan host. CoreDNS berperilaku seperti Pod jaringan {i>host<i} 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. Tergantung pada OS, server nama dikonfigurasi di /etc/resolv.conf atau /run/systemd/resolve/resolv.conf. Konfigurasi ini berarti mereka tidak dapat menyelesaikan Nama domain cluster.local.

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

Pastikan semua node memiliki kumpulan server yang sama yang telah dikonfigurasi. Jika Anda memiliki server nama yang berbeda dikonfigurasi, Anda mungkin melihat inkonsistensi dalam DNS resolusi pada {i>node<i} yang berbeda. Verifikasi bahwa setiap server nama berfungsi secara terpisah dengan mengirim permintaan ke setiap alamat menggunakan dig atau nslookup. Jika beberapa server nama tetapi yang lainnya tidak, Anda melihat jenis resolusi DNS yang tidak konsisten ini gagal.

Masalah umum jaringan

Bagian berikut merinci beberapa masalah jaringan umum yang mungkin hadapi. Untuk membantu menyelesaikan masalah Anda, ikuti pemecahan masalah yang sesuai panduan. 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 Cilium ke agen karena adanya pembatasan kapasitas. Untuk setiap {i>node<i}, Cilium memiliki batas empat permintaan serentak ke endpoint PUT. Jika terjadi burst permintaan ke satu node, perilaku ini sudah diperkirakan. Tujuan Agen Cilium harus mengejar permintaan yang tertunda.

Di GKE Enterprise 1.14 dan yang lebih baru, batas kapasitas otomatis disesuaikan dengan node kapasitas. Pembatas kapasitas dapat dikonvergensi ke angka yang lebih wajar, dengan untuk node yang lebih canggih.

Error umum: Ebpf map size is full

Dataplane v2 menyimpan status dalam peta eBFP. Status mencakup Layanan, hubungkan pelacakan, identitas Pod, dan aturan Kebijakan Jaringan. Jika peta penuh, agen tidak dapat menyisipkan entri, yang menimbulkan 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. Tujuan 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 64k, bersihkan peta. Hal berikut contoh ini 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 belum siap karena error NetworkPluginNotReady

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

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

{i>Node<i} mungkin juga dalam status belum dibaca, dengan pesan {i>error<i} yang mirip dengan contoh berikut:

  "Network plugin not installed"

Saat node diinisialisasi, kubelet akan menunggu beberapa peristiwa terjadi sebelum proses ini menandai node sebagai Ready. Salah satu peristiwa yang diperiksa kubelet adalah plugin Container Network Interface (CNI) yang sudah diinstal. Plugin CNI seharusnya diinstal oleh anetd menggunakan container init untuk menginstal biner CNI dan konfigurasi CNI ke direktori {i>host<i} yang diperlukan.

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

  1. Periksa status Pod anetd. Tinjau 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 dalam status Pending, gunakan kubectl describe dan tinjau Peristiwa pod. Misalnya, Pod mungkin tidak memiliki resource seperti Volume.
    • Jika Pod berada dalam status Running, periksa log dan konfigurasi. Beberapa implementasi CNI menyediakan opsi untuk menonaktifkan penginstalan CNI, seperti inci Cilium.
    • Ada opsi konfigurasi di anetd yang disebut custom-cni-conf. Jika 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 basi di {i>node<i} bidang kontrol klaster admin dapat menyebabkan ketidakcocokan dalam alamat MAC. Ketidakcocokan alamat ini pada akhirnya dapat menyebabkan koneksi dan waktu tunggu habis ke VIP bidang kontrol dari cluster pengguna terkelola. Koneksi waktu tunggu dapat menyebabkan node dengan entri ARP yang sudah tidak berlaku ditandai sebagai NOT READY. Node yang ditandai sebagai NOT READY dapat menghambat penginstalan cluster dan upgrade.

Dalam situasi ini, {i>kubelet log<i} pada {i>node<i} dengan entri ARP yang basi berisi kesalahan 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 yang terhubung ke alamat VIP:

    ip a | grep DEVICE_NAME: -A 6

    Ganti DEVICE_NAME dengan nama perangkat jaringan untuk {i>node<i} bidang kontrol.

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

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

    ip n | grep VIP_ADDRESS

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

    Jika kedua perintah ip mengembalikan alamat mac yang berbeda, Anda terpengaruh oleh menyelesaikan masalah ini.

  5. Untuk mengatasi masalah ini, bersihkan cache ARP di bidang kontrol cluster admin {i>node<i}:

    ip n flush all

Layanan F5 tidak menerima traffic

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

  1. Pastikan bahwa setiap partisi di F5 BIG-IP telah dikonfigurasi dalam satu cluster, baik pada kelompok admin maupun pengguna. Jika satu partisi digunakan bersama oleh beberapa cluster yang berbeda, Anda akan mengalami gangguan koneksi yang terputus-putus. Ini perilaku ini karena dua klaster mencoba merebut kontrol atas partisi yang sama, dan menghapus Service dari cluster lain.

  2. Pastikan dua Pod berikut berjalan. Setiap Pod yang tidak berjalan menunjukkan pesan {i>error<i}:

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

    Load-balancer-f5 yang dimiliki oleh GKE Enterprise, dan membuat ConfigMaps untuk setiap Layanan jenis LoadBalancer. ConfigMap akhirnya digunakan oleh Pengontrol bigip.

  3. Pastikan ConfigMap ada untuk setiap port dari setiap Layanan. Sebagai 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 sudah benar dikonfigurasi, tetapi instance BIG-IP gagal mengikuti konfigurasi, bisa jadi 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 memberikan alamat jaringan (NAT) untuk paket yang dirutekan ke alamat di luar cluster. Demikian pula, ketika paket masuk memasuki {i> load balancing node<i} yang dikonfigurasi untuk load balancing yang dipaketkan (spec.loadBalancer.mode: bundled), jaringan sumber penafsiran alamat (SNAT) mengarahkan paket ke alamat IP node sebelum diteruskan ke Pod backend.

Rentang port untuk NAT yang digunakan oleh Google Distributed Cloud adalah 32768-65535. Ini membatasi jumlah koneksi paralel hingga 32.767 per protokol pada {i>node<i}. Setiap koneksi memerlukan entri di tabel conntrack. Jika Anda memiliki banyak koneksi jangka pendek, tabel {i>conntrack<i} kehabisan porta untuk NAT. J pembersih sampah memori membersihkan entri yang basi, tetapi pembersihan tidak langsung dilakukan.

Ketika jumlah koneksi pada node Anda mendekati 32.767, Anda mulai melihat paket drop untuk koneksi yang membutuhkan NAT.

Untuk mengetahui apakah Anda terpengaruh oleh masalah ini:

  1. Jalankan perintah berikut pada 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.