Dalam dunia k8, setiap sumber dicipta melalui pengawal. Seperti terdapat pengawal terbina untuk pod, penempatan, set replika dan lain-lain. Jadi pada asasnya, Pengawal hanyalah gelung kawalan yang sentiasa memantau keadaan kluster dan mengambil tindakan untuk membawa kluster ke keadaan yang dikehendaki. Sumber mempunyai spesifikasi yang menyediakan keadaan yang dikehendaki. Pengawal menyemak keadaan semasa. Jika ia tidak sepadan dengan keadaan yang diingini, ia akan membuat perubahan atau pengubahsuaian yang sesuai untuk membawanya lebih dekat kepada keadaan yang dikehendaki.
ReplicaSet Controller: Pengawal ini bertanggungjawab untuk mengekalkan set stabil replika Pod yang berjalan pada bila-bila masa. Ia sering digunakan bersama-sama dengan Deployments untuk memastikan bahawa bilangan replika pod tertentu dijalankan pada setiap masa, walaupun sekiranya berlaku kegagalan nod atau penamatan pod.
Pengawal Penerapan: Pengawal ini menyediakan kemas kini deklaratif untuk Pod dan ReplicaSets. Ia membolehkan penskalaan mudah, kemas kini rolling dan rollback aplikasi. Pengawal Deployment menguruskan penciptaan dan pemadaman ReplicaSets untuk memastikan bilangan pod yang diingini sentiasa berjalan.
StatefulSet Controller: Pengawal ini digunakan untuk mengurus aplikasi stateful, seperti pangkalan data. Ia memberikan identiti unik (nama hos yang stabil) kepada setiap pod dalam set dan mengekalkan susunan dan keunikan pod ini. Ia amat berguna apabila anda memerlukan pengecam rangkaian yang stabil, storan berterusan yang stabil dan penempatan dan penskalaan yang teratur dan anggun.
Pengawal Perkhidmatan: Pengawal ini bertanggungjawab untuk mengekalkan alamat IP dan nama DNS yang stabil untuk satu set pod. Ia bertindak sebagai pengimbang beban dan mengarahkan trafik ke pod yang sesuai berdasarkan pemilih perkhidmatan. Ini memastikan bahawa perkhidmatan mempunyai titik akhir yang stabil untuk mengakses pod yang sedang berjalan, walaupun ia dibuat, dimusnahkan atau dialihkan di sekitar gugusan.
Jadi Sebelum terjun ke dalam ujian, kita perlu memahami seni bina asas pengawal standard. Dalam seni bina pelayan pelanggan Kubernetes, pengawal memainkan peranan penting sebagai pelanggan yang membuat panggilan API, terutamanya HTTP, ke pelayan API Kubernetes. Objektif utama mereka adalah untuk menyelaraskan objek API Kubernetes dengan sumber sistem sebenar. Komponen penting dalam seni bina ini ialah penggunaan Pemberitahu. Pemberi maklumat bertanggungjawab untuk memantau sebarang perubahan dalam kelompok, yang penting kerana tinjauan berterusan untuk mendapatkan maklumat tentang sumber boleh merendahkan prestasi pelayan API dengan ketara.
Pemaklum bekerja dengan menanyakan data sumber dan menyimpannya dalam cache setempat. Setelah data disimpan, peristiwa dijana hanya apabila terdapat perubahan dalam keadaan objek (atau sumber). Pendekatan ini memastikan sistem tidak ditimpa peristiwa yang tidak perlu dan pengawal hanya dimaklumkan apabila perubahan yang berkaitan berlaku.
Satu lagi konsep penting dalam seni bina ini ialah versi sumber. Versi ini berubah dengan setiap operasi tulis dan digunakan untuk kawalan konkurensi yang optimistik. Ia memastikan kemas kini kepada sumber diuruskan dengan cara yang mengelakkan konflik dan mengekalkan konsistensi merentas sistem. Dengan memahami dan memanfaatkan mekanisme ini, pengawal Kubernetes boleh mengurus dan menyelaraskan keadaan sumber dalam kelompok dengan cekap.
Kubernetes membenarkan penciptaan Definisi Sumber Tersuai (CRD), yang merupakan sambungan API Kubernetes yang membolehkan pengguna mentakrifkan sumber tersuai. Sumber tersuai ini tidak tersedia dalam pemasangan Kubernetes lalai dan digunakan untuk menampung kes penggunaan khusus domain dan keperluan aplikasi yang kompleks.
Untuk mengurus sumber tersuai ini, pengawal tersuai diperlukan. Pengawal tersuai, CRD dan pelayan API Kubernetes membentuk hubungan yang padu di mana:
CRD mentakrifkan sumber tersuai.
Pelayan API menguruskan kitaran hayat sumber ini.
Pengawal tersuai memastikan bahawa keadaan sumber ini dikekalkan mengikut konfigurasi yang diingini.
Seni bina ini membolehkan kebolehlanjutan Kubernetes, membolehkan pengguna menyesuaikan platform dengan keperluan khusus mereka.
Memastikan pengawal Kubernetes bersedia untuk menyampaikan permintaan kepada pelayan API Kubernetes adalah penting sebelum menggunakannya untuk pengeluaran. Terdapat beberapa pendekatan untuk menguji pengawal Kubernetes. Antaranya yang saya nyatakan adalah daripada artikel :
Menggunakan client-go palsu atau abstraksi peringkat lebih tinggi: Pendekatan ini mengelakkan menjalankan sebarang API sokongan, menjadikannya sesuai untuk unit menguji komponen individu secara berasingan.
Menggunakan pakej envtest daripada controller-runtime: Pakej ini berfungsi dengan pelayan API yang dikupas untuk mengesahkan interaksi sebenar dengan API, termasuk penyegerakan masa dan cache, tanpa gangguan daripada pengawal lain . Ia menyokong kedua-dua ujian tempatan terhadap contoh yang dikupas dan ujian terhadap gugusan berfungsi sepenuhnya.
Menjalankan pelayan API sebenar: Pendekatan ini sesuai untuk persekitaran pementasan atau keadaan seperti jenis fana atau microk8 untuk menguji hasil sebenar. Ia membenarkan untuk menguji interaksi terhadap pelayan API sebenar.
Kelebihan menggunakan proses luaran, seperti envtest atau pelayan API sebenar, ialah ia mengambil kira kependaman yang wujud dalam sistem teragih. Perpustakaan seperti Gomega boleh digunakan untuk menunggu keadaan tertentu selepas tindakan berlaku. Pendekatan di atas lebih kerap terdengar terbaik untuk ujian unit dan ujian tahap penyepaduan, di mana kami menguji komponen tertentu secara berasingan. sama ada dengan memalsukan data dengan menulis ujian
Walaupun teknik di atas berkesan untuk ujian unit dan penyepaduan, ia mungkin tidak meliputi ujian hujung ke hujung (e2e), yang penting untuk memastikan kefungsian keseluruhan pengawal. Satu pendekatan untuk ujian e2e adalah untuk melaksanakan kemas kini sumber dan operasi lain untuk menguji keseluruhan aliran pengawal dalam persekitaran terkawal, mereplikasi proses apabila perlu. Ini membantu mengesahkan gelagat pengawal dalam senario dunia sebenar dan memastikan bahawa ia bersedia untuk penggunaan pengeluaran.
Ringkasnya, gabungan unit, penyepaduan dan ujian hujung ke hujung adalah penting untuk memastikan kebolehpercayaan dan keberkesanan pengawal Kubernetes sebelum mendorongnya ke dalam pengeluaran.
Membina dan menguji pengawal Kubernetes secara tempatan boleh menjadi mencabar, terutamanya apabila berurusan dengan panggilan API keluar. Walau bagaimanapun, Keploy, sebagai alat mencipta kes ujian dan data mengejek daripada panggilan API, pertanyaan DB, dsb., menawarkan penyelesaian. Keploy membolehkan anda merakam dan memainkan semula panggilan keluar yang dibuat oleh pengawal Kubernetes anda, yang boleh menjadi sangat berguna untuk menguji dan memastikan pengawal anda berkelakuan seperti yang diharapkan.
Anda mungkin tertanya-tanya bagaimana ini boleh dilakukan tanpa sebarang perubahan kod. Keploy menggunakan eBPF untuk menambah probe pada ruang kernel dan mengumpul data penimbal rangkaian. Data ini kemudiannya dihantar ke proksi Keploy, yang bertindak sebagai ruang pengguna di mana semua pemprosesan penimbal dilakukan oleh penghurai protokol yang berbeza. Keploy boleh menangkap trafik keluar pengawal dan menyimpan permintaan dan respons dalam fail YAML untuk acara tertentu itu. Semasa mod main semula, bukannya membuat panggilan API ke pelayan API sebenar, Keploy akan mengembalikan respons daripada fail YAML yang disimpan untuk permintaan tertentu itu. Ini menjadikan proses bebas daripada kluster atau persekitaran, menawarkan cara yang mudah dan cekap untuk menguji pengawal Kubernetes secara tempatan.
Jadi untuk menangkap ujian pengawal anda secara setempat atau dari mana-mana persekitaran langsung, anda perlu memulakan gugusan kubernetes dahulu dan membuat pengawal tersuai anda untuk membuat interaksi dengan pelayan.
Untuk merakam pengawal anda dengan Keploy, ikut langkah berikut:
Tetapkan objek Kubernetes *rest.Config anda menjadi tidak selamat dan tanpa fail CA:
cfg.Insecure = true cfg.CAFile = ""
Buat RoundTripper tersuai untuk menambah medan pengepala yang mengandungi versi sumber. Pengepala ini berfungsi sebagai id jejak untuk permintaan yang sepadan semasa keadaan yang sama dengan olok-olok yang direkodkan. Berikut ialah contoh pelaksanaan:
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
Pastikan untuk menetapkan nilai versi sumber dalam konteks.Konteks semasa proses penyegerakan. Ini penting untuk menghantar konteks yang diubah suai kepada kemas kini dan mencipta kaedah pengawal anda. Contohnya:
func (c *Controller) syncHandler(ctx context.Context, key string) error {
// set ResourceVersion in ctx
rv := foo.GetResourceVersion()
if rv != "" {
ctx = context.WithValue(ctx, "ResourceVersion", rv)
}
}
Bina perduaan Go bagi pengawal Kubernetes anda:
go build -o sample-controller .
Untuk merakam panggilan keluar melalui Keploy, bungkus arahan pengawal anda dengan arahan rekod Keploy. Nota - Ciri keploy ini dalam penggunaan beta dan belum dikeluarkan dalam utama. Ini dibuat khusus sebagai percubaan untuk peminat Kubernetes mencuba dan memberi ulasan. Oleh itu, anda perlu mendaftar keluar di cawangan khusus ini dan membina binari keploy menggunakan arahan go build. https://github.com/keploy/keploy/pull/1342.
Daftar keluar di cawangan yang dinyatakan.
1.
git checkout kube-controller
```
{% endraw %}
Membina binari keploy untuk cawangan itu.
{% mentah %}
go build -o keploy && sudo mv keploy /usr/local/bin
Tambahkan bendera yang diperlukan mengikut konfigurasi kube anda:
sudo -E env PATH=$PATH keploy record -c "./sample-controller -kubeconfig=$HOME/.kube/config" --mtls-cert-path "$HOME/.minikube/profiles/minikube/client.crt" --mtls-key-path "$HOME/.minikube/profiles/minikube/client.key" --mtls-host-name 192.168.49.2:8443
Anda boleh melihat keploy/test-set-0/mocks.yaml dibuat sebaik sahaja Keploy mula memintas panggilan keluar. Setiap versi sumber mempunyai fail olok-olok berasingan yang dilambangkan dengan mocks_ "
Nota - Satu perkara yang ingin saya jelaskan ialah, ciri di atas tidak membantu anda dalam TDD (Pembangunan dipacu ujian). Tetapi anda masih boleh keploy semasa menulis ujian unit dengan memanfaatkan keupayaan penjanaan rintisan keploy. Oleh itu, daripada membuat sebarang pelayan api olok-olok atau tulisan rintisan untuk ujian unit tertentu, anda boleh memainkan ujian itu dalam persekitaran sebenar anda. Keploy akan menyimpan semua interaksi dalam fail olok-olok dan akan menggunakan data tersebut apabila ujian dijalankan seterusnya.
Untuk menguji pengawal anda dengan olok-olok yang dirakam:
Jalankan Keploy dalam mod ujian dengan bendera mockAssert ditetapkan kepada benar dan berikan binari pengawal anda. Keploy akan membuat konfigurasi kube palsu secara automatik untuk anda:
cfg.Insecure = true cfg.CAFile = ""
Secara pilihan, anda boleh menetapkan masa ulang tayang anda sendiri, yang akan cuba memainkan semula sesi rakaman anda dalam masa yang disediakan: contoh aplikasi lengkap yang disepadukan dengan keploy diberikan di sini.
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
Perhatikan bahawa proses main semula memangkas jurang masa acara yang cukup besar kepada tempoh purata yang tepat antara dua peristiwa pemberi maklumat. Ini membolehkan acara dihantar lebih awal daripada yang berlaku dalam rekod, memudahkan main semula yang lebih pantas.
Ini boleh membantu anda memainkan semula keseluruhan sesi panggilan api yang dihasilkan oleh pengawal tetapi kali ini anda tidak memerlukan pelayan k8s sebenar atau mana-mana sumber luaran untuk mendapatkan respons. Semua jawapan akan dikembalikan oleh keploy sendiri bertindak seperti pelayan olok-olok atau orang tengah. Ini boleh memberi keyakinan untuk menjalankannya dalam saluran paip CI-CD anda.
Misalnya - Anda bekerja dalam organisasi pengkomputeran awan yang besar dan untuk mendapatkan semua perkara digunakan, ia memerlukan banyak virtualisasi dan operasi intensif sumber. Jadi hampir mustahil untuk mengujinya dalam persekitaran sebenar. Di sini alat seperti Keploy boleh menjadi sangat berguna kerana ia sudah mempunyai respons yang anda ingin dapatkan sekiranya pelancaran sumber itu berjaya. Jadi ia boleh menjadi operasi yang pantas, boleh dipercayai dan menjimatkan kos kerana anda baru sahaja menangkap aliran perkhidmatan pengawal anda yang betul sekali sahaja. Dan boleh menggunakan semula main semula keploy dalam keluaran anda yang berikutnya.
Menguji pengawal Kubernetes secara tempatan boleh dibuat lebih cekap dan boleh dipercayai dengan alatan seperti Keploy. Dengan merakam dan memainkan semula panggilan keluar, anda boleh memastikan pengawal anda berkelakuan betul dalam pelbagai senario, meningkatkan kualiti keseluruhan aplikasi Kubernetes anda. Memandangkan keploy mempunyai sokongan asli rangka kerja ujian seperti gotest , ia juga mungkin untuk mendapatkan liputan talian mana-mana aplikasi walaupun pengawal kube anda. Terokai Keploy dan tingkatkan aliran kerja ujian pengawal Kubernetes anda!
Merakam dan memainkan semula panggilan API keluar: Ini menghapuskan keperluan untuk persekitaran langsung semasa ujian.
Kecekapan yang dipertingkatkan: Dengan menggunakan olok-olok yang disimpan, ujian menjadi lebih pantas dan bebas daripada gugusan Kubernetes sebenar.
Kos dan penjimatan sumber: Ia mengurangkan pergantungan pada persekitaran intensif sumber untuk pengesahan, menjadikannya ideal untuk saluran paip CI/CD dalam operasi berskala besar.
Keploy menggunakan probe eBPF untuk memintas panggilan keluar dan menyimpan pasangan permintaan-tindak balas dalam fail tiruan. Semasa mod main semula:
Panggilan dipintas dan dipadankan dengan olok-olok yang dirakam sebelum ini.
Respons dikembalikan daripada olok-olok ini dan bukannya menghubungi pelayan API sebenar.
Mekanisme ini memastikan ujian boleh dijalankan tanpa memerlukan kluster Kubernetes secara langsung.
Walaupun ciri rakaman dan main semula Keploy tidak direka khusus untuk TDD, ia masih boleh digunakan dengan berkesan:
Penjanaan stub: Jalankan pengawal dalam persekitaran sebenar sekali untuk menangkap interaksi. Keploy akan mencipta olok-olok untuk kegunaan seterusnya.
Sokongan ujian unit: Dengan memanfaatkan olok-olok ini, anda boleh mengelak daripada menulis stub secara manual dan menumpukan pada pelaksanaan ujian.
Keploy melengkapkan aliran kerja TDD sedia ada dengan memperkemas penciptaan olok-olok dan mengurangkan overhed pembangunan.
Atas ialah kandungan terperinci Cara Menguji Trafik Menggunakan Pengawal Kubernetes Tersuai: Panduan Langkah demi Langkah. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Apakah kod ruang dalam html
Apakah yang perlu saya lakukan jika huruf Inggeris muncul apabila komputer dihidupkan dan komputer tidak boleh dihidupkan?
laman web rasmi aplikasi platform dagangan okex
Bagaimana untuk menyelesaikan tidak tersedia
setInterval
Apakah pembolehubah persekitaran
Bagaimana untuk menukar ape kepada wav
html editor dalam talian
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
