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 Calico, Seesaw, dan MetalLB juga disertakan.

Pemecahan masalah konektivitas jaringan

Jaringan GKE Enterprise mengandalkan infrastruktur jaringan fisik Anda. Misalnya, Seesaw atau MetalLB mengandalkan switch Anda yang mendukung ARP gratis, load balancing yang dipaketkan dengan Border Gateway Protocol (BGP) mengandalkan 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 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.
  • 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.

Network layer dapat berupa salah satu atau beberapa hal berikut:

  • Masalah lapisan link Layer 2 seperti sistem tetangga, ARP, atau NDP.
  • Masalah perutean alamat IP Layer 3.
  • Masalah endpoint 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 terjadi. Mengumpulkan informasi saat masalah terjadi penting karena beberapa masalah bersifat sementara, sehingga snapshot setelah sistem pulih tidak akan menyertakan informasi yang cukup untuk analisis penyebab utama.

Masalah ingress

Jika subjek adalah klien dari luar cluster dan gagal terhubung ke Layanan LoadBalancer, berarti ada masalah konektivitas Utara-Selatan. Diagram berikut menunjukkan bahwa dalam contoh yang berfungsi, traffic masuk melewati stack dari kiri ke kanan, dan traffic kembali melewati stack dari kanan ke kiri. Seesaw berbeda karena traffic kembali melewati load balancer dan langsung kembali ke klien:

Traffic Ingress melewati dari pengguna ke infrastruktur fisik, melalui load balancer ke anetd / kube-proxy, lalu ke backend. Dengan Seesaw, traffic keluar melewati load balancer.

Jika ada masalah dengan alur traffic ini, gunakan diagram alur 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 konektivitas yang sesuai ada di sepanjang proses.

Dalam diagram alur ini, panduan pemecahan masalah berikut membantu menentukan penyebab masalah:

  • Apakah paket keluar dari klien? Jika tidak, kemungkinan Anda mengalami masalah infrastruktur jaringan.
  • Apakah Anda menggunakan load balancer Seesaw? Jika ya, apakah paket tiba di node Seesaw, dan apakah ARP kemudian dikirim dengan benar? Jika tidak, kemungkinan Anda 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 mengalami masalah infrastruktur jaringan.
  • Apakah Anda menggunakan F5 BIG-IP, dan jika ya, apakah Anda telah memeriksa masalah F5?
  • Apakah terjemahan alamat jaringan (NAT) dilakukan dengan benar? Jika tidak, Anda mungkin mengalami masalah kube-proxy / Dataplane V2.
  • Apakah paket tiba di node pekerja? Jika tidak, kemungkinan Anda mengalami masalah Pod-ke-Pod Calico / Dataplane v2.
  • Apakah paket tiba di Pod? Jika tidak, Anda mungkin mengalami masalah penerusan lokal Calico / Dataplane v2.

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

Apakah paket keluar dari 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 meninggalkan klien menuju layanan tujuan:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Jika Anda tidak melihat traffic keluar, inilah sumber masalahnya.

Apakah paket tiba di node Seesaw?

Jika Anda menggunakan Seesaw, lihat dokumentasi versi 1.16, temukan node master, lalu hubungkan ke node menggunakan SSH.

  1. Gunakan tcpdump untuk memeriksa apakah paket yang diharapkan tiba di node Seesaw:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Jika Anda tidak melihat traffic masuk, inilah 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 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. 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

    Perintahnya berbeda di antara jenis load balancer karena MetalLB dan Seesaw tidak melakukan NAT sebelum meneruskan paket ke node.

    Jika Anda tidak melihat traffic masuk ke node mana pun, berarti inilah sumber masalahnya.

Apakah ada masalah F5 BIG-IP?

Untuk memecahkan masalah F5 BIG-IP, lihat salah satu bagian berikut di F5 Service doesn't receive traffic.

Apakah ARP dikirim dengan benar?

Node load balancer untuk MetalLB atau Seesaw mengandalkan ARP untuk mengiklankan VIP layanan. Jika respons ARP dikirim dengan benar, tetapi traffic tidak masuk, hal ini menandakan 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 Anda alami masalahnya.

    • Untuk Seesaw, ARP yang serampangan dikirim untuk semua VIP. Anda akan melihat pesan ARP untuk setiap VIP setiap 10 detik.

    • Untuk MetalLB, ARP serampangan tidak dikirim. Frekuensi Anda melihat respons bergantung pada waktu perangkat lain seperti switch top of rack (ToR) atau switch virtual mengirim permintaan ARP.

Apakah NAT dilakukan?

Dataplane v2 / kube-proxy melakukan penafsiran alamat jaringan tujuan (NAT tujuan atau DNAT) untuk menerjemahkan VIP tujuan ke alamat IP Pod backend. Jika Anda mengetahui node mana yang menjadi backend untuk load balancer, hubungkan ke node 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 yang disematkan:

    cilium monitor --type=drop

Untuk mengetahui informasi selengkapnya, lihat salah satu bagian berikut di halaman Masalah Dataplane v2 / Cilium.

Apakah paket tiba di node pekerja?

Di node pekerja, paket tiba di antarmuka eksternal, lalu 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

Karena backend Service normal berisi beberapa Pod di berbagai node, mungkin sulit untuk memecahkan masalah node mana yang bermasalah. Solusi umum adalah mengambil masalah cukup lama sehingga beberapa paket akhirnya tiba, atau membatasi jumlah backend menjadi satu.

Jika paket tidak pernah tiba di node pekerja, hal ini menunjukkan adanya masalah infrastruktur jaringan. Tanyakan kepada tim infrastruktur jaringan untuk mengetahui alasan paket dihapus di antara node LoadBalancer dan node pekerja. Beberapa masalah umum meliputi:

  • Periksa log software-defined network (SDN) Anda. Terkadang, SDN dapat menjatuhkan paket karena berbagai alasan, seperti segmentasi, checksum yang salah, atau anti-spoofing.
  • Aturan firewall yang memfilter paket yang tujuannya adalah alamat IP dan port Pod backend.

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 lainnya. 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, antarmukanya biasanya diberi nama lxcxxxx. Nama memiliki nomor antarmuka 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 tiba di Pod, periksa tabel perutean sebagai berikut:

ip route

Biasanya, setiap Pod harus memiliki entri perutean yang merutekan alamat IP Pod ke antarmuka lxc. Jika entri tidak ada, biasanya berarti jalur data CNI mengalami error. Untuk menentukan penyebab utama, periksa log CNI DaemonSet.

Masalah keluar

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 melewati stack dari kiri ke kanan:

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

  1. Untuk memverifikasi bahwa paket keluar dengan benar menyamar 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. Calico menggunakan aturan iptables.

    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 di-masquerade dengan benar, tetapi layanan jarak jauh tidak merespons, periksa koneksi ke layanan eksternal di infrastruktur Anda.

  2. Jika paket keluar dengan benar di-masquerade sebagai alamat IP node, periksa konektivitas host eksternal (Layer 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 batasi cakupan masalah ke node. Sering kali, sekelompok node tidak dapat berkomunikasi dengan sekelompok node lainnya.

  1. Di Dataplane v2, periksa konektivitas node dari node saat ini ke semua node lain dalam cluster yang sama. Dari dalam Pod anetd, periksa status kesehatan:

    cilium status --all-health

    Google Distributed Cloud menggunakan mode perutean langsung. Anda akan melihat satu entri rute per node dalam cluster, seperti yang ditunjukkan dalam contoh berikut:

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    Jika rute yang diharapkan tidak ada untuk suatu node, koneksi ke node tersebut akan terputus.

Masalah lapisan jaringan

Mengidentifikasi lapisan jaringan tempat terjadinya masalah konektivitas adalah langkah penting. Pesan error seperti, "Masalah konektivitas dari sumber ke tujuan" tidak cukup informatif untuk membantu menyelesaikan masalah, yang bisa 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 di lapisan mana masalah terjadi. Contoh berikut dapat membantu Anda memecahkan masalah pertanyaan lapisan jaringan:

  • Error HTTP menunjukkan bahwa ini adalah masalah Layer 7.
    • Kode HTTP 40x, 50x, atau error handshake TLS berarti semuanya berfungsi normal di Layer 4.
  • Error "Connection reset by peer" menunjukkan bahwa ini adalah masalah Layer 4.
    • Sering kali, soket jarak jauh tidak dapat menyetujui status koneksi saat ini dan mengirim paket RESET. Perilaku ini bisa menjadi kesalahan dalam pelacakan koneksi, atau NAT.
  • Error "No route to host" dan "Connection timeout" biasanya merupakan masalah Layer 3 atau Layer 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, switch top of rack (ToR), router tulang belakang, atau firewall juga dapat menyebabkan masalah. Anda dapat menggunakan alat berikut untuk membantu menentukan cakupan atau lapisan masalah dan menentukan apakah masalah tersebut terkait 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 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 Layer 4 murni. ClusterIP Service adalah contoh ketika VIP mungkin tidak menampilkan respons ping. Di lapisan 4, Service ini hanya menampilkan respons ping saat Anda menentukan nomor port, seperti VIP:port.

Load balancer BGPLB , MetalLB, dan Seesaw 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, kecuali karena berfungsi di layer 2. Masalah layer 2 dan layer 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 ke tujuan, berarti ada masalah Layer 2.

arping <ip> yang berhasil akan menampilkan alamat MAC tujuan. Di layer 2, alamat ini sering kali menunjukkan masalah infrastruktur fisik. Masalah ini adalah kesalahan konfigurasi switch virtual.

Arping juga dapat mendeteksi konflik alamat IP. Konflik alamat IP terjadi saat dua mesin dikonfigurasi untuk menggunakan alamat IP yang sama pada subnet yang sama, atau VIP digunakan oleh mesin fisik lain. Konflik alamat IP dapat menyebabkan masalah sesekali yang sulit dipecahkan. Jika arping <ip> menampilkan lebih dari satu entri alamat MAC, hal ini menunjukkan 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 tidak ada atau entri yang tidak ada dalam tabel tetangga dapat menyebabkan masalah konektivitas dari node. Anetd dan Calico 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 dihentikan oleh anetd / Cilium.
  • hubble observe
    • Mencetak semua paket yang melewati stack ebpf anetd.
  • cilium status --all-health
    • Mencetak status Cilium, termasuk status konektivitas antar-node. Setiap Pod anetd memeriksa kondisi semua node lain dalam cluster dan dapat membantu menentukan masalah konektivitas antar-node.

Iptables

Iptables digunakan di banyak komponen dan subsistem Kubernetes. kube-proxy menggunakan iptables untuk menerapkan penyelesaian layanan. Calico menggunakan iptables untuk menerapkan kebijakan jaringan

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

    iptables -L -v | grep DROP

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

Tcpdump

Tcpdump adalah alat pengambilan paket yang canggih yang menghasilkan banyak data traffic jaringan. Praktik umum adalah menjalankan tcpdump dari sumber dan tujuan. Jika paket diambil saat meninggalkan node sumber, tetapi tidak pernah diambil di node tujuan, berarti ada sesuatu di antara keduanya yang menghentikan paket. Perilaku ini biasanya menunjukkan bahwa ada sesuatu di infrastruktur fisik Anda yang secara keliru membuang paket.

Metrik

Google Distributed Cloud berisi beberapa metrik untuk membantu Anda melacak perilaku jaringan Anda. Metrik berikut memberikan titik awal yang baik:

Kategori Metrik Deskripsi
Paket yang dihentikan cilium_drop_bytes_total Total byte yang dihentikan, diberi tag berdasarkan alasan penghentian dan arah masuk/keluar. Metrik ini adalah titik awal yang baik untuk menyelidiki penurunan tingkat byte.
cilium_drop_count_total Total paket yang dihapus, diberi tag berdasarkan alasan penghapusan dan arah masuk/keluar.
container_network_receive_packets_dropped_total Jumlah kumulatif paket yang dihapus saat menerima. Sampelnya dibuat setiap 60 detik.
container_network_transmit_packets_dropped_total Jumlah kumulatif paket yang dihapus saat mengirim. Sampelnya dibuat setiap 60 detik.
Paket yang diteruskan cilium_forward_bytes_total Total byte yang diteruskan, diberi tag menurut arah masuk/keluar. Sampelnya dibuat setiap 60 detik. Metrik ini memberikan informasi penerusan tingkat byte.
cilium_forward_count_total Total paket yang diteruskan, diberi tag berdasarkan arah masuk/keluar. Sampelnya dibuat setiap 60 detik. Metrik ini memberi Anda jumlah paket untuk traffic yang diteruskan.
cilium_policy_l7_forwarded_total Total permintaan yang diteruskan L7.
Received packets cilium_policy_l7_received_total Jumlah total permintaan/respons yang diterima L7. Sampelnya dibuat setiap 60 detik.
container_network_receive_bytes_total Jumlah kumulatif byte yang diterima. Dibuat sampelnya setiap 60 detik.
container_network_receive_packets_total Jumlah kumulatif paket yang diterima. Dibuat sampelnya setiap 60 detik.
container_network_receive_errors_total Jumlah kumulatif error yang terjadi saat menerima. Sampelnya dibuat setiap 60 detik.
cilium_kubernetes_events_received_total Jumlah peristiwa Kubernetes yang diterima dan diberi label berdasarkan cakupan, tindakan, data yang valid, dan kesamaan. Dibuat sampelnya setiap 60 detik.
BPF cilium_bpf_maps_virtual_memory_max_bytes BPF memetakan ukuran penggunaan memori maksimum kernel dalam byte.
cilium_bpf_progs_virtual_memory_max_bytes Ukuran penggunaan memori maksimum kernel program BPF dalam byte.
Conntrack node_nf_conntrack_entries Jumlah entri alur yang dialokasikan saat ini untuk pelacakan koneksi. Dibuat sampelnya setiap 60 detik.
node_nf_conntrack_entries_limit Ukuran maksimum tabel pelacakan koneksi. Dibuat sampelnya setiap 60 detik.
Konektivitas cilium_node_connectivity_latency_seconds Latensi terakhir yang diamati antara agen Cilium saat ini dan node Cilium lainnya dalam detik. Dibuat sampelnya setiap 60 detik.
cilium_node_connectivity_status Status terakhir yang diamati dari konektivitas ICMP dan HTTP antara agen Cilium saat ini dan node Cilium lainnya. Dibuat sampelnya setiap 60 detik.
Operator Cilium cilium_operator_process_cpu_seconds_total Total waktu CPU pengguna dan sistem yang dihabiskan dalam hitungan detik. Sampelnya dibuat setiap 60 detik.
cilium_operator_process_max_fds Jumlah maksimum deskriptor file terbuka. Dibuat sampelnya setiap 60 detik.
cilium_operator_process_open_fds Jumlah deskriptor file terbuka. Dibuat sampelnya setiap 60 detik.
cilium_operator_process_resident_memory_bytes Ukuran memori residen dalam byte. Dibuat sampelnya setiap 60 detik.
cilium_operator_process_start_time_seconds Waktu mulai proses sejak epoch unix dalam detik. Sampelnya dibuat setiap 60 detik.
cilium_operator_process_virtual_memory_bytes Ukuran memori virtual dalam byte. Dibuat sampelnya setiap 60 detik.
cilium_operator_process_virtual_memory_max_bytes Jumlah memori virtual maksimum yang tersedia dalam byte. Sampelnya dibuat setiap 60 detik.
cilium_operator_identity_gc_entries Jumlah identitas yang aktif dan dihapus di akhir proses garbage collector. Dibuat sampelnya setiap 60 detik.
cilium_operator_identity_gc_runs Jumlah berapa kali pengumpul sampah identitas telah berjalan. Sampelnya dibuat setiap 60 detik.

Untuk menerima notifikasi saat salah satu metrik ini melampaui atau berada di bawah nilai minimum tertentu, buat kebijakan pemberitahuan. Untuk mempelajari lebih lanjut, lihat artikel Membuat kebijakan pemberitahuan batas metrik di dokumentasi Cloud Monitoring.

Untuk mempelajari lebih lanjut metrik ini dan melihat daftar lengkap metrik, lihat Metrik Google Distributed Cloud.

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 menyelesaikan permintaan DNS untuk Pod di cluster. CoreDNS menyediakan layanan ini untuk Google Distributed Cloud versi 1.9.0 dan yang lebih baru.

Setiap cluster memiliki dua atau lebih Pod coredns, dan autoscaler yang bertanggung jawab untuk menskalakan jumlah Pod DNS relatif terhadap ukuran cluster. Ada juga layanan bernama kube-dns yang menyeimbangkan beban 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 Service atau Pod di 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 tersebut adalah untuk domain eksternal.
    • CoreDNS meneruskan permintaan ke server nama upstream. Secara default, CoreDNS menggunakan server nama upstream yang dikonfigurasi di node tempat CoreDNS 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 mencapai Pod coredns atau tidak. Masalah konektivitas cluster umum sering kali muncul sebagai masalah DNS karena permintaan DNS adalah jenis traffic pertama yang dikirimkan 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 menyelesaikan nama domain:

  • Error NXDOMAIN menunjukkan bahwa server DNS melaporkan bahwa domain 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 menyelesaikan domain atau memvalidasi bahwa domain tersebut tidak ada. Untuk mengetahui 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 lain tidak, periksa apakah ada pola yang dapat dibedakan, seperti resolusi DNS berfungsi untuk Pod di node yang sama dengan Pod coredns, tetapi tidak di seluruh node. Perilaku ini dapat menunjukkan adanya masalah konektivitas dalam cluster.

Jika CoreDNS tidak dapat menyelesaikan nama domain eksternal, lihat bagian berikut untuk memecahkan masalah Pod host-network. 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 menyelesaikan nama domain cluster.local.

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

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.

Calico

Error umum: calico/node is not ready: BIRD is not ready: BGP not established

Error status "tidak siap" di Kubernetes ini biasanya berarti bahwa peer tertentu tidak dapat dijangkau di cluster. Pastikan konektivitas BGP antara dua peer diizinkan di lingkungan Anda.

Error ini juga dapat terjadi jika resource node yang tidak aktif dikonfigurasi untuk mesh node-ke-node. Untuk memperbaiki masalah ini, nonaktifkan node yang tidak aktif.

Dataplane v2 / Cilium

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

Error ini berarti peristiwa pembuatan Pod telah ditolak oleh agen Cilium karena batas laju. Untuk setiap node, Cilium memiliki batas empat permintaan serentak ke endpoint PUT. Perilaku ini wajar jika ada lonjakan permintaan ke satu node. Agen Cilium akan memproses permintaan yang tertunda.

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

Error umum: Ebpf map size is full

Dataplane v2 menyimpan status di peta eBFP. Status mencakup Layanan, pelacakan koneksi, identitas Pod, dan aturan 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 hampir mencapai batas 64k, bersihkan peta. 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

  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 akan 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 juga mungkin dalam status tidak 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 apakah plugin Container Network Interface (CNI) telah diinstal. Plugin CNI harus diinstal oleh anetd atau Calico 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 di node. Biasanya, error ini bukan disebabkan oleh masalah jaringan. Pod tersebut berjalan di jaringan host, sehingga tidak ada dependensi jaringan.

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

    • Jika Pod 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 penerapan 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 tidak aktif

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

Dalam situasi ini, log kubelet di node dengan entri ARP yang tidak aktif 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 yang terikat dengan alamat VIP:

    ip a | grep DEVICE_NAME: -A 6

    Ganti DEVICE_NAME dengan nama perangkat jaringan untuk node control plane.

  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, bersihkan cache ARP di node bidang kontrol cluster admin:

    ip n flush all

Layanan F5 tidak menerima traffic

Jika tidak ada traffic yang melewati 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 merebut kontrol atas partisi yang sama, dan menghapus Layanan dari cluster lain.

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

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

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

  3. Pastikan ConfigMap ada untuk setiap port dari setiap Service. 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 menerapkan konfigurasi, hal ini mungkin merupakan masalah F5. Untuk masalah yang terjadi di dalam instance BIG-IP, hubungi dukungan F5 untuk mendiagnosis dan memecahkan masalah tersebut.

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:

  • Persyaratan untuk membuka kasus dukungan.
  • Alat untuk membantu Anda memecahkan masalah, seperti log dan metrik.
  • Komponen yang didukung, versi, dan fitur Google Distributed Cloud untuk VMware (khusus software).