Memperkenalkan perpustakaan kubedog untuk pelacakan sumber daya Kubernetes

Kami dengan senang hati mengumumkan pengembangan Open Source baru dari perusahaan Flant untuk para spesialis DevOps dan tidak hanya kubedog . Ini adalah perpustakaan yang ditulis Go dan CLI berdasarkan itu untuk melacak peristiwa sumber daya Kubernetes dan mengumpulkan log mereka.


Perpustakaan saat ini mendukung pelacakan sumber daya berikut: Pod (dan Wadah), Pekerjaan, Penempatan, StatefulSet, dan DaemonSet. Acara dan log dikirimkan melalui panggilan balik.

Kubedog CLI memiliki dua mode operasi:

• rollout track - melacak sumber daya hingga status Ready tercapai dan keluar jika ada kesalahan untuk kenyamanan penggunaan di CI / CD;
• ikuti - cetak acara dan log ke layar tanpa keluar, mirip dengan tail -f .

Masalah

Mengapa kami mulai menulis perpustakaan baru jika proyek serupa sudah ada (lihat “Bekerja dengan log” dalam ulasan ini ) ? Kubedog digunakan dalam utilitas dapp DevOps kami untuk melacak peluncuran grafik Helm. Helm sendiri tidak tahu bagaimana memonitor keadaan sumber daya yang ditambahkannya, dan transfer log tidak disediakan pada tingkat interaksi GRPC antara Helm dan anakan. Pada kesempatan ini, ada masalah kami 3481 , dalam kerangka di mana kami menerapkan pelacakan sumber daya tambahan ... Namun, proyek Helm sekarang enggan untuk menambahkan fitur baru ke Helm 2, karena semua upaya terkonsentrasi pada versi baru Helm 3 . Untuk alasan ini, kami memutuskan untuk memisahkan kubedog menjadi proyek yang terpisah.

Apa yang dibutuhkan perpustakaan pelacakan sumber daya?

• Dapatkan log Pods milik sumber daya - misalnya, Penempatan.
• Tanggapi perubahan dalam komposisi Pods yang termasuk dalam sumber daya: tambahkan log penerima dari Pods baru, nonaktifkan log dari Pods ReplicaSets lama.
• Pelacakan Peristiwa di mana dekripsi berbagai kesalahan datang. Misalnya, Pod tidak dapat dibuat karena gambar yang tidak dikenal atau Pod dibuat, tetapi perintah yang ditentukan dalam template tidak ada di dalam gambar.
• Dan satu persyaratan lagi adalah melacak transisi sumber daya dari rollout ke mode ready . Dan setiap sumber daya memiliki ketentuannya sendiri untuk ini.

Seperti yang Anda duga, di kubedog kami mencoba untuk memperhitungkan semua hal di atas .

Dalam cara yang baik, pada awal mengerjakan sesuatu yang baru, mereka menganalisis solusi yang ada. Tetapi ternyata meskipun ada banyak solusi dalam bentuk CLI, tidak ada perpustakaan Go. Oleh karena itu, kami hanya dapat memberikan sedikit perbandingan fitur utama dari utilitas CLI yang ada untuk melacak sumber daya Kubernetes.

Solusi yang ada

kubespy

→ GitHub

• Dapat memantau hanya Penyebaran dan Layanan, bereaksi terhadap Pods baru.
• Ada mode pelacakan untuk deskripsi sumber daya dan statusnya dan output dari perubahan dalam bentuk json diff.
• Ada representasi tabel warna dari perubahan yang menunjukkan status ReplicaSets dan ketentuan.
• Tidak menampilkan log Pod.
• Itu ditulis dalam Go, tetapi tidak dapat digunakan sebagai perpustakaan.

kubetail

→ GitHub

• Skrip bash yang memanggil kubectl.
• Mampu menunjukkan log dari Pod yang ada.
• Itu tidak mendeteksi Pods baru, jika rollback terjadi, kubetail perlu di-restart.

buritan

→ GitHub

• Memperlihatkan log dari Pods yang difilter menurut kueri-pod.
• Temukan pod baru.
• Garis log diwarnai untuk persepsi yang lebih baik.
• Memperlihatkan peristiwa menambah dan menghapus Pod dengan nama wadah di dalamnya.
• Itu tidak mengikuti Acara, oleh karena itu tidak menunjukkan penyebab kesalahan Pod.
• Itu ditulis dalam Go, tetapi tidak dapat digunakan sebagai perpustakaan.

kail

→ GitHub

• Mampu menunjukkan log secara bersamaan dari ruang nama yang berbeda untuk sumber daya yang berbeda.
• Tidak memantau Acara, tidak menunjukkan penyebab kesalahan, misalnya, untuk Penempatan.
• Tidak mengecat log Pods.
• Itu ditulis dalam Go, tetapi tidak dapat digunakan sebagai perpustakaan.

k8stail

→ GitHub

• Pilihan Pods menurut namespace dan label.
• Melacak yang baru, penghapusan.
• Tidak mengikuti Acara, tidak akan menampilkan kesalahan.
• On Go, tapi bukan perpustakaan.

kubedog

→ GitHub

• CLI beroperasi dalam dua mode: pelacakan tanpa akhir dan pelacakan sampai sumber daya berubah menjadi status SIAP.
• Melacak satu sumber daya.
• Bereaksi terhadap perubahan sumber daya, berlangganan log dari Pods baru.
• Dapat memonitor Deployment, StatefulSet, DaemonSet, Job atau Pod terpisah.
• Ditulis dalam Go, Anda dapat menggunakannya sebagai perpustakaan untuk menambahkan sumber daya ke program Anda untuk memantau status sumber daya dan menerima log dari wadah.

Jika Anda melihat lebih dekat, Anda dapat mengatakan bahwa setiap utilitas dalam beberapa cara mengungguli para pesaingnya dan tidak ada pemenang tunggal yang dapat melakukan semua yang dilakukan orang lain.

Jadi kubedog!

Inti dari kerja kubedog adalah sebagai berikut: untuk sumber daya yang ditentukan, jalankan Watchers on Events dan di Pods milik sumber daya, dan ketika Pod muncul, jalankan logger-nya. Segala sesuatu yang terjadi dengan sumber daya disiarkan ke klien dengan menelepon panggilan balik.

Mari kita lihat contoh DaemonSet, yang tersedia untuk kode yang menggunakan pustaka. Antarmuka panggilan balik untuk Penempatan, StatefulSet, dan DaemonSet adalah sama * - ini adalah ControllerFeed :

 type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error } 

* Pengecualiannya adalah AddedReplicaSet , yang hanya masuk akal untuk Penerapan (Anda tidak dapat menentukan metode ini untuk melacak DaemonsSet).

Penjelasan untuk metode antarmuka lainnya:

• Added sesuai dengan watch.Added Acara tambahan pengamat untuk sumber daya yang dipilih;
• Ready disebut ketika sumber daya telah memasuki status Ready (misalnya, untuk DaemonSet ini adalah saat ketika jumlah Pods yang diperbarui dan tersedia bertepatan dengan jumlah Pod yang "diinginkan");
• Failed - metode ini dipanggil saat sumber daya dihapus atau jika suatu Acara diterima dengan sebab dan deskripsi kesalahan (misalnya, FailedCreate );
• EventMsg dipanggil untuk setiap Acara yang diterima dari sumber daya atau Podnya: ini adalah acara tentang pembuatan sumber daya, tentang unggahan gambar, dll. Termasuk pesan kesalahan;
• AddedPod - metode di mana Anda dapat menangkap momen membuat Pods baru;
• PodLogChunk dipanggil ketika sepotong log lainnya berasal dari API Kubernetes;
• PodError akan PodError jika Pod gagal.

Setiap panggilan balik dapat mengembalikan StopTrack jenis StopTrack dan pelacakan akan selesai. Jadi, misalnya, dilakukan dalam peluncuran peluncur - Ready StopTrack dan CLI menyelesaikan pekerjaannya.

Untuk memfasilitasi definisi panggilan balik, ada struktur ControllerFeedProto , saat membuat objek yang Anda dapat menentukan metode panggilan balik yang diinginkan.

Ini adalah bagaimana, misalnya, output tanpa henti dari log DaemonSet terlihat seperti tanpa informasi tambahan tentang peristiwa dan status:

 // kubedog     Kubernetes',    // . https://github.com/flant/kubedog/blob/master/pkg/kube/kube.go kubeClient, err := kubernetes.NewForConfig(config) if err != nil { return err } feed := &tracker.ControllerFeedProto{ PodLogChunkFunc: func(chunk *tracker.ReplicaSetPodLogChunk) error { for _, line := range chunk.LogLines { fmt.Printf(">> po/%s %s: %s\n", chunk.PodName, chunk.ContainerName, line) } return nil }, } //    timeout   API   ,     .   ,     ,    Pod'. opts := tracker.Options{ Timeout: time.Second * time.Duration(300), LogsFromTime: time.Now(), } tracker.TrackDaemonSet(dsName, dsNamespace, kubeClient, feed, opts) 

Panggilan terakhir adalah pemblokiran : ia memulai putaran tanpa akhir untuk menerima peristiwa dari Kubernetes dan memanggil panggilan balik yang sesuai. Anda dapat secara terprogram menghentikan siklus ini dengan mengembalikan StopTrack dari callback.

Contoh aplikasi

Penggunaan kubedog sebagai perpustakaan dapat dilihat di utilitas dapp. Di sinilah Peluncur peluncuran siap pakai dijalankan untuk memeriksa sumber daya yang dibuat atau diperbarui Helm.

Kubedog CLI dapat membantu dengan peluncuran di sistem CI / CD , dan terlepas dari apakah itu digunakan: kubectl, Helm atau yang lainnya. Setelah semua, Anda dapat menjalankan kubectl apply , dan kemudian kubedog rollout track , dan Anda akan melihat kesalahan dalam kubedog rollout track log jika ada sesuatu yang salah dengan sumber daya. Penggunaan kubedog ini akan membantu mengurangi waktu untuk mendiagnosis masalah peluncuran.

Apa selanjutnya

Kami berencana untuk mengembangkan perpustakaan dengan tujuan mendukung lebih banyak sumber daya - misalnya, saya benar-benar ingin mengikuti Layanan dan Ingress. Selain itu, seharusnya melakukan pengerjaan klasifikasi reason dalam Event'ah, untuk lebih akurat menentukan saat ketika kita dapat mengasumsikan bahwa peluncuran sumber daya gagal. Vektor lain dari pengembangan pustaka adalah melacak beberapa sumber sekaligus, misalnya, dengan labelSelector atau dengan namespace nama. Saya juga ingin mendukung berbagai anotasi yang dapat mengubah sifat pelacakan, misalnya, untuk kait Helm, tetapi ini masih lebih relevan untuk dapp.

Dalam waktu dekat, fokus akan berada di perpustakaan, tetapi perbaikan juga direncanakan untuk CLI: perintah dan bendera yang lebih nyaman, pewarnaan log, pesan tentang menghapus Pod, seperti di buritan. Kami juga mempertimbangkan kemungkinan untuk membuat mode interaktif dengan tabel status Penempatan dan acara di satu jendela dan dengan log di jendela lain.

Bagaimana cara mencoba?

Kubedog CLI build untuk Linux dan macOS tersedia di bintray .

Sangat menantikan tanggapan dan masalah Anda di GitHub !

PS

Baca juga di blog kami:

• " Kubebox dan cangkang konsol lainnya untuk Kubernetes ";
• " Memperkenalkan loghouse - sistem open source untuk bekerja dengan log di Kubernetes ";
• “Kami secara resmi mewakili dapp - utilitas DevOps untuk mendukung CI / CD ”;
• " Infrastruktur dengan Kubernet sebagai layanan yang terjangkau ."