Tutorial ini khusus untuk pembangun dengan latar belakang Java yang ingin belajar cara menulis operator kubernetes pertama dengan pantas. Mengapa pengendali? Terdapat beberapa kelebihan:
Saya akan cuba mengehadkan teori kepada minimum dan menunjukkan resipi kalis bodoh cara "membakar kek". Saya memilih Java kerana ia hampir dengan pengalaman bekerja saya dan sejujurnya ia lebih mudah daripada Go (tetapi ada yang mungkin tidak bersetuju).
Mari melompat terus ke sana.
Tiada siapa yang suka membaca dokumentasi yang panjang, tetapi mari kita dapatkan ini dengan cepat dari dada kita, boleh?
Apakah pod?
Pod ialah sekumpulan bekas dengan antara muka rangkaian kongsi (dan diberi alamat IP unik) serta storan.
Apakah set replika?
Set replika mengawal penciptaan dan pemadaman pod supaya pada setiap saat terdapat bilangan pod yang ditentukan dengan templat yang diberikan.
Apakah itu penempatan?
Deployment memiliki set replika dan secara tidak langsung memiliki pod. Apabila anda membuat pod penempatan dibuat, apabila anda memadamkannya pod akan hilang.
Apakah perkhidmatan itu?
Perkhidmatan ialah SATU titik akhir internet untuk sekumpulan pod (ia mengagihkan beban di antara mereka secara sama rata). Anda boleh mendedahkannya untuk kelihatan dari luar kelompok. Ia mengautomasikan penciptaan kepingan titik akhir.
Masalah dengan kubernetes ialah sejak dari awal ia direka bentuk tanpa kewarganegaraan. Set replika tidak menjejaki identiti pod, apabila pod tertentu hilang, pod baharu baru dibuat. Terdapat beberapa kes penggunaan yang memerlukan keadaan seperti pangkalan data dan kelompok cache. Set stateful hanya sebahagiannya mengurangkan masalah.
Inilah sebabnya orang mula menulis operator untuk mengurangkan beban penyelenggaraan. Saya tidak akan pergi ke kedalaman corak dan pelbagai sdk — anda boleh bermula dari sini.
Semua yang berfungsi dalam kubernetes, setiap gear kecil jentera adalah berdasarkan konsep mudah gelung kawalan. Jadi apa yang dilakukan oleh gelung kawalan ini untuk jenis sumber tertentu ialah ia menyemak apa yang ada dan apa yang sepatutnya (seperti yang ditakrifkan dalam manifes). Jika terdapat ketidakpadanan, ia cuba melakukan beberapa tindakan untuk membetulkannya. Ini dipanggil perdamaian.
Dan apakah pengendali sebenarnya adalah konsep yang sama tetapi untuk sumber tersuai. Sumber tersuai ialah cara untuk melanjutkan api kubernetes kepada beberapa jenis sumber yang ditakrifkan oleh anda. Jika anda menyediakan crd dalam kubernetes maka semua tindakan seperti dapatkan, senarai, kemas kini, padam dan sebagainya akan dapat dilakukan pada sumber ini. Dan apa yang akan melakukan kerja sebenar? Betul — pengendali kami.
Seperti biasa untuk menguji teknologi buat kali pertama anda memilih masalah yang paling asas untuk dilakukan. Oleh kerana konsepnya sangat kompleks maka hello world dalam kes ini akan menjadi sedikit panjang. Bagaimanapun, dalam kebanyakan sumber saya telah melihat bahawa kes penggunaan yang paling mudah ialah menyediakan siaran halaman statik.
Jadi projeknya adalah seperti ini : kami akan mentakrifkan sumber tersuai yang mewakili dua halaman yang ingin kami sediakan. Selepas menggunakan operator sumber itu secara automatik akan menyediakan aplikasi penyajian dalam Spring Boot, buat peta konfigurasi dengan kandungan halaman, lekapkan peta konfigurasi ke dalam volum dalam pod aplikasi dan sediakan perkhidmatan untuk pod itu. Apa yang menyeronokkan tentang ini ialah jika kita mengubah suai sumber, ia akan mengikat semula segala-galanya dengan cepat dan perubahan halaman baharu akan kelihatan serta-merta. Perkara kedua yang menyeronokkan ialah jika kami memadamkan sumber, ia akan memadamkan segala-galanya menjadikan kluster kami bersih.
Menyajikan apl java
Ini akan menjadi pelayan halaman statik yang sangat mudah dalam Spring Boot. Anda hanya memerlukan spring-boot-starter-web jadi teruskan ke spring initializer dan pilih:
Apl ini hanyalah:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Apa sahaja yang kami lalui sebagai pembolehubah laluan akan diambil daripada direktori /statik (dalam kes kami halaman1 dan halaman2). Jadi direktori statik akan dipasang daripada peta konfigurasi, tetapi mengenainya kemudian.
Jadi sekarang kita perlu membina imej asli dan menolaknya ke repositori jauh.
Petua nombor 1
1 2 3 4 5 6 7 8 9 |
|
Mengkonfigurasi GraalVM seperti itu supaya anda akan mempunyai binaan terpantas dengan penggunaan memori paling rendah (sekitar 2GB). Bagi saya ia adalah satu kemestian kerana saya hanya mempunyai 16GB memori dan banyak barangan yang dipasang.
Petua nombor 2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
So now you do:
mvn spring-boot:build-image
And that’s it.
Operator with Fabric8
Now the fun starts. First you will need this in your pom:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
crd-generator-apt is a plugin that scans a project, detects CRD pojos and generates the manifest.
Since I mentioned it, these resources are:
1 2 3 4 5 |
|
1 2 |
|
1 2 |
|
What is common in all resource manifests in Kubernetes is that most of them has spec and status. So you can see that the spec will consist of two pages pasted in heredoc format. Now, the proper way to handle things would be to manipulate status to reflect whatever operator is doing. If for example it is waiting on deployment to finish it would have status = “Processing”, on everything done it would patch the status to “Ready” and so on. But we will skip that because this is just simple demo.
Good news is that the logic of the operator is all in main class and really short. So step by step here it is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
So the heart of the program is of course Fabric8 Kuberenetes client built in first line. It is convenient to customize it with own executor. I used famous virtual threads, so when waiting on blocking io java will suspend the logic and move to main.
How here is a new part. The most basic version would be to run forever the loop and put Thread.sleep(1000) in it or so. But there is more clever way - kubernetes informers. Informer is websocket connection to kubernetes api server and it informs the client each time the subscribed resource changes. There is more to it you can read on the internet for example how to use various caches which fetch updates all at once in batch. But here it just subscribes directly per resource. The handler is a little bit bloated so I wrote a helper class GenericResourceEventHandler.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Since we only need to wake up the loop in all of the cases then we pass it a generic lambda. The idea for the loop is to wait on lock in the end and then the informer callback releases the lock each time the changes are detected.
Next:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
If there is no crd then there is nothing to be done. And if the crd changed then we have to reload everything.
1 2 3 4 5 6 7 8 9 |
|
This is for the case that ConfigMap is changed in between the iterations. Since it is mounted in pod then we have to reload the deployment.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
If any of the service or deployment differs from the defaults we will replace them with the defaults.
1 2 3 |
|
Then the aforementioned lock.
So now the only thing is to define the desired configmap, service and deployment.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 |
|
The magic of the OwnerReference is that you mark the resource which is it’s parent. Whenever you delete the parent k8s will delete automatically all the dependant resources.
But you can’t run it yet. You need a docker credentials in kubernetes:
1 2 3 4 5 6 |
|
Run this script once. Then we also need to set up the ingress:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
The workflow
So first you build the operator project. Then you take target/classes/META-INF/fabric8/webservingresources.com.github.webserving-v1.yml and apply it. From now on the kubernetes is ready to accept your crd. Here it is:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
You apply the crd kubectl apply -f src/main/resources/crd-instance.yaml. And then you run Main of the operator.
Then monitor the pod if it is up. Next just take the ip of the cluster:
minikube ip
And in your browser navigate to /page1 and /page2.
Then try to change the crd and apply it again. After a second you should see the changes.
The end.
A bright observer will notice that the code has some concurrency issues. A lot can happen in between the start and the end of the loop. But there are a lot of cases to consider and tried to keep it simple. You can do it as aftermath.
Like wise for the deployment. Instead of running it in IDE you can build the image the same way as for serving app and write deployment of it. That’s basically demystification of the operator — it is just a pod like every other.
I hope you found it useful.
Thanks for reading.
I almost forgot - here is the repo:
https://github.com/dgawlik/operator-hello-world
Atas ialah kandungan terperinci Menulis koperator di Jawa. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!