Pada akhir tahun lalu, Reddit
memperkenalkan sebuah plugin untuk kubectl, yang membantu untuk debug di pod dari cluster
Kubernetes -
kubectl-debug . Gagasan ini segera tampak menarik dan bermanfaat bagi para insinyur kami, jadi kami memutuskan untuk melihat implementasinya dan dengan senang hati membagikan hasil kami dengan para pembaca hubr.
Mengapa ini perlu?
Saat ini, ada ketidaknyamanan yang serius dalam proses men-debug sesuatu dalam kerangka pod. Tujuan utama saat merakit gambar kontainer adalah untuk
menguranginya , mis. membuatnya sekecil mungkin dalam ukuran dan mengandung sesedikit mungkin "kelebihan" di dalamnya. Namun, ketika datang ke masalah dalam pengoperasian perangkat lunak akhir dalam wadah atau debugging komunikasinya dengan layanan lain di cluster / di luar ... minimalis memainkan trik pada kita - setelah semua,
tidak ada dalam wadah untuk proses aktual menemukan masalah. Sebagai aturan, utilitas seperti netstat / ip / ping / curl / wget, dll. Tidak tersedia.
Dan seringkali itu semua berakhir dengan fakta bahwa insinyur menyiapkan perangkat lunak yang diperlukan tepat dalam wadah yang sedang berjalan untuk "melihat" dan melihat masalahnya. Untuk kasus seperti itu plugin Kubectl-debug tampaknya menjadi alat yang sangat berguna - karena menyelamatkan dari rasa sakit yang mendesak.
Dengan bantuannya, Anda dapat
meluncurkan wadah dengan semua alat yang diperlukan di papan dalam konteks
pod masalah
dengan satu perintah dan mempelajari semua proses "dari luar", berada di dalam. Jika Anda pernah mengalami pemecahan masalah Kubernetes, itu terdengar menarik, bukan?
Apa itu plugin ini?
Secara umum, arsitektur solusi ini terlihat seperti bundel dari
plugin untuk kubectl dan
agen yang mulai menggunakan pengontrol DaemonSet. Plugin ini melayani perintah yang dimulai dengan
kubectl debug … dan berinteraksi dengan agen pada node cluster. Agen, pada gilirannya, berjalan di jaringan host, dan buruh pelabuhan host. Kaus kaki dipasang di pod agen untuk akses penuh ke wadah di server ini.
Karena itu, ketika meminta untuk meluncurkan wadah debug di pod yang ditentukan:
ada proses untuk mengidentifikasi
hostIP , dan permintaan dikirim ke agen (bekerja pada host yang sesuai) untuk meluncurkan wadah debug di ruang nama yang sesuai dengan pod target.
Pandangan yang lebih rinci tentang langkah-langkah ini tersedia dalam
dokumentasi proyek .
Apa yang dibutuhkan untuk bekerja?
Penulis kubectl-debug mengklaim kompatibel dengan versi klien
Kubernetes / cluster
1.12.0+ , namun, saya memiliki K8 1.10.8 di tangan, di mana semuanya bekerja tanpa masalah yang terlihat ... dengan satu catatan: agar tim
kubectl debug berfungsi dalam bentuk ini, versi
kubectl tepat
1,12+ . Jika tidak, semua perintah serupa, tetapi hanya dipanggil melalui
kubectl-debug …Saat Anda memulai template DaemonSet yang dijelaskan dalam
README Anda tidak boleh lupa tentang noda yang Anda gunakan pada node: tanpa toleransi yang sesuai, pod agen tidak akan menetap di sana dan, akibatnya, Anda tidak akan dapat menggunakan pod yang hidup di node tersebut dapat terhubung dengan debugger.
Bantuan debugger sangat komprehensif dan tampaknya menjelaskan semua kemungkinan saat ini untuk meluncurkan / mengkonfigurasi plugin. Secara umum, utilitas senang dengan sejumlah besar arahan untuk dijalankan: Anda dapat melampirkan sertifikat, tentukan konteks kubectl, tentukan konfigurasi kubectl terpisah atau alamat server API cluster, dan banyak lagi.
Bekerja dengan debugger
Instalasi hingga saat "semuanya berfungsi" direduksi menjadi dua tahap:
- jalankan
kubectl apply -f agent_daemonset.yml ; - langsung instal plugin itu sendiri - secara umum, semuanya seperti yang dijelaskan di sini .
Bagaimana cara menggunakannya? Misalkan kita memiliki masalah berikut: metrik salah satu layanan di cluster tidak dikumpulkan - dan kami ingin memeriksa apakah ada masalah jaringan antara Prometheus dan layanan target. Seperti yang Anda duga, gambar Prometheus tidak memiliki alat yang diperlukan.
Mari kita coba sambungkan ke wadah dengan Prometheus (jika ada beberapa wadah di pod, Anda harus menentukan yang mana yang akan dihubungkan, jika tidak, debugger akan memilih yang pertama secara default):
kubectl-debug --namespace kube-prometheus prometheus-main-0 Defaulting container name to prometheus. pulling image nicolaka/netshoot:latest... latest: Pulling from nicolaka/netshoot 4fe2ade4980c: Already exists ad6ddc9cd13b: Pull complete cc720038bf2b: Pull complete ff17a2bb9965: Pull complete 6fe9f5dade08: Pull complete d11fc7653a2e: Pull complete 4bd8b4917a85: Pull complete 2bd767dcee18: Pull complete Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3 Status: Downloaded newer image for nicolaka/netshoot:latest starting debug container... container created, open tty... [1] → root @ /
Sebelumnya, kami menemukan bahwa layanan bermasalah tinggal di alamat 10.244.1.214 dan mendengarkan pada port 8080. Tentu saja, kami dapat memeriksa ketersediaan dari host juga, namun, untuk proses debugging yang andal, operasi ini harus direproduksi dalam kondisi yang identik (atau sedekat mungkin). Oleh karena itu, memeriksa dari pod / wadah dengan Prometheus adalah pilihan terbaik. Mari kita mulai dengan yang sederhana:
[1] → ping 10.244.1.214 PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data. 64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms 64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms 64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms ^C --- 10.244.1.214 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 61ms rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms
Semuanya baik-baik saja. Mungkin port tidak tersedia?
[1] → curl -I 10.244.1.214:8080 HTTP/1.1 200 OK Date: Sat, 12 Jan 2019 14:01:29 GMT Content-Length: 143 Content-Type: text/html; charset=utf-8
Dan tidak ada masalah. Kemudian kami akan memeriksa apakah komunikasi aktual antara Prometheus dan titik akhir dengan metrik terjadi:
[2] → tcpdump host 10.244.1.214 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1 14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0 14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK 14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel
Permintaan jawaban datang. Berdasarkan hasil operasi ini, kita dapat menyimpulkan bahwa tidak ada masalah di tingkat interaksi jaringan, yang berarti (kemungkinan besar) Anda perlu melihat dari sisi yang diterapkan. Kami terhubung ke wadah dengan eksportir (juga, tentu saja, menggunakan debugger yang bersangkutan, karena eksportir selalu memiliki gambar yang sangat minimalis) dan ... kami terkejut menemukan bahwa ada masalah dalam konfigurasi layanan - misalnya, kami lupa mengarahkan eksportir ke yang benar Alamat Aplikasi Tujuan
Kasus ini terpecahkan!Tentu saja, cara debugging lain dimungkinkan dalam situasi yang dijelaskan di sini, tetapi kami akan membiarkannya di luar ruang lingkup artikel. Hasilnya adalah debug kubectl memiliki banyak peluang untuk digunakan: Anda dapat menjalankan gambar apa pun ke dalam pekerjaan, dan jika Anda mau, Anda bahkan dapat merakit beberapa gambar tertentu (dengan seperangkat alat yang diperlukan).
Aplikasi apa lagi yang langsung muncul di benak Anda?
- Aplikasi "sunyi", yang pengembangnya
berbahaya tidak menerapkan pencatatan normal. Tetapi ia memiliki kemampuan untuk terhubung ke port layanan dan men-debug dengan alat tertentu, yang, tentu saja, tidak boleh dimasukkan dalam gambar akhir. - Luncurkan di sebelah aplikasi tempur yang identik dalam mode "manual", tetapi dengan debug diaktifkan - untuk memeriksa interaksi dengan layanan tetangga.
Secara umum, jelas bahwa ada lebih banyak situasi di mana alat semacam itu dapat bermanfaat. Insinyur yang menemukan mereka di tempat kerja setiap hari akan dapat menilai potensi utilitas dalam hal debugging “langsung”.
Kesimpulan
Kubectl-debug adalah alat yang berguna dan menjanjikan. Tentu saja, ada cluster Kubernetes dan aplikasi yang tidak masuk akal, tetapi masih ada banyak kasus ketika itu akan memberikan bantuan yang tak ternilai dalam debugging - terutama jika menyangkut lingkungan tempur dan kebutuhan untuk cepat, di sini dan sekarang, temukan alasannya masalah yang Anda temui.
Pengalaman penggunaan pertama mengungkapkan kebutuhan mendesak akan kemampuan untuk terhubung ke pod / wadah, yang tidak memulai sampai akhir (misalnya, hang di
CrashLoopbackOff ), hanya untuk memeriksa dengan cepat alasan aplikasi tidak memulai. Pada kesempatan ini, saya membuat
masalah yang sesuai dalam repositori proyek, di mana pengembang merespons secara positif dan menjanjikan implementasi dalam waktu dekat. Sangat senang dengan umpan balik yang cepat dan memadai. Jadi kami akan menantikan fitur-fitur baru dari utilitas dan pengembangan lebih lanjut!
PS
Baca juga di blog kami: