Apa itu Kubernetes Server-Side Apply (SSA)?

  • Post author:
  • Post category:Tutorial

Server-Side Apply (SSA) telah tersedia secara umum di Kubernetes sejak rilis v1.22 pada bulan Agustus 2021. Ini adalah strategi untuk pengelolaan sumber daya deklaratif yang meningkatkan perhitungan diff dan memperingatkan tentang konflik penggabungan dengan memindahkan logika perintah kubectl apply ke server.

Artikel ini akan menjelaskan cara kerja SSA dan mengapa SSA lebih disukai daripada pendekatan client-side apply (CSA) sebelumnya. Anda juga akan mempelajari cara mengaktifkan SSA saat membuat perubahan pada objek di cluster Anda.

Memahami Pembaruan Deklaratif

Perintah kubectl apply melakukan pembaruan objek deklaratif. Alih-alih menginstruksikan Kubernetes untuk memodifikasi bidang tertentu, Anda memberikan representasi lengkap dari objek seperti yang Anda inginkan. Sistem secara otomatis menghitung perbedaan dibandingkan dengan status klaster Anda saat ini. Ini kemudian akan melakukan tindakan yang mengubah keadaan menjadi keadaan yang diinginkan yang diungkapkan oleh file manifes Anda.

Berikut adalah manifes Pod sederhana:

apiVersion: v1 kind: Metadata Pod: name: nginx spec: containers: – name: nginx image: nginx :latest

Running kubectl apply dengan manifes ini akan memulai Pod baru yang menjalankan nginx:latest image. Perbedaan antara status klaster yang ada dan yang diinginkan jelas: sebuah Pod telah dibuat, di mana sebelumnya tidak ada dengan nama nginx.

Anda kemudian dapat memodifikasi manifes dengan mengubah salah satu properti Pod:

apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: – name: nginx image: nginx:1.23

Kali ini perbedaan antara status yang ada dan yang diinginkan kurang substansial. Perintah kubectl apply akan mendeteksi bidang gambar yang telah direvisi dan memperbarui konfigurasi Pod Anda sesuai dengan itu. Masalah Dengan Penerapan Sisi Klien

Membedakan perubahan dan menyelesaikan setiap konflik adalah bagian terpenting dari pembaruan deklaratif. Proses ini berjalan di dalam Kubectl secara default. Klien bertanggung jawab untuk mengidentifikasi objek yang ada di server dan membandingkan perubahannya.

Perintah kubectl apply menulis anotasi last-applied-configuration ke objek untuk membantu proses ini. Ini memungkinkan identifikasi bidang yang ada pada objek langsung tetapi telah dihapus dari manifes yang masuk. Klien kemudian tahu untuk menghapusnya dari objek untuk mencapai status baru.

Pendekatan ini bermasalah ketika ada banyak agen yang memperbarui objek yang sama. Satu objek dapat dimodifikasi oleh Kubectl dan pengontrol khusus di klaster Anda, misalnya. Penerapan sisi klien tidak dapat melacak agen mana yang mengubah bidang, juga tidak dapat memahami saat terjadi konflik. Ini hanya membandingkan manifes lokal Anda dengan konfigurasi terapan terakhir dari objek yang ada dan menggabungkannya dalam setiap perubahan.

Penerapan sisi klien juga secara inheren terkait dengan Kubectl. Alat pihak ketiga yang ingin membuat pembaruan deklaratifnya sendiri harus memanggil Kubectl atau membuat ulang logika penerapan dari awal. Tak satu pun dari kedua opsi ini yang ideal.

Bagaimana Penerapan Sisi Server Bekerja

Masalah mendasar dengan CSA adalah bahwa manifes lokal yang usang tidak pernah terdeteksi. Jika applier lain mengubah objek sebelum Anda menjalankan kubectl apply, revisi lokal lama Anda mungkin menimpa yang baru yang benar. Dengan mengaktifkan SSA, konflik akan terdeteksi dan pembaruan akan diblokir. Ini adalah sistem terpusat yang memaksa agar negara bagian Anda selalu diperbarui.

SSA bekerja dengan menambahkan mekanisme bidang kontrol yang menyimpan informasi tentang setiap bidang di objek Anda. Ini menggantikan anotasi last-applied-configuration dengan bidang metadata.managedFields baru. Setiap bidang di objek Anda dilacak dalam bidang yang dikelola.

Bidang diberi “manajer bidang” yang mengidentifikasi klien yang memilikinya. Jika Anda menerapkan manifes dengan Kubectl, maka Kubectl akan menjadi pengelola yang ditunjuk. Manajer bidang juga bisa menjadi pengontrol atau integrasi eksternal yang memperbarui objek Anda.

Manager dilarang memperbarui bidang masing-masing. Anda akan diblokir dari mengubah kolom dengan kubectl apply jika saat ini dimiliki oleh pengontrol yang berbeda. Tiga strategi tersedia untuk menyelesaikan konflik penggabungan ini:

Force menimpa nilai – Dalam beberapa situasi, Anda mungkin ingin memaksakan pembaruan. Ini akan mengubah nilainya dan mentransfer kepemilikan ke pengelola lapangan yang baru. Ini terutama ditujukan untuk pengontrol yang perlu mempertahankan pengelolaan bidang yang telah mereka isi. Anda dapat memaksakan pembaruan secara manual dengan menyetel flag –force-conflicts di Kubectl. Jangan menimpa nilai – Applier dapat menghapus kolom dari konfigurasi lokalnya dan kemudian mengulangi permintaan tersebut. Bidang akan mempertahankan nilai yang ada. Menghapus bidang mengatasi konflik dengan menyerahkan kepemilikan kepada pengelola yang ada. Bagikan pengelolaan – Applier dapat memperbarui nilai lokalnya agar sesuai dengan nilai yang ada di server. Jika mengulangi permintaan sambil tetap mengklaim kepemilikan, SSA akan mengizinkannya berbagi manajemen dengan manajer yang ada. Hal ini karena applier menerima keadaan field saat ini tetapi telah mengindikasikan bahwa applier mungkin ingin mengelolanya di masa mendatang. Pendekatan ini jauh lebih kuat daripada penerapan kubectl tradisional. Ini mencegah penimpaan yang tidak disengaja, memungkinkan pengontrol dengan andal mengklaim kepemilikan bidang yang mereka kontrol, dan sepenuhnya bersifat deklaratif. SSA melacak bagaimana pengguna yang berbeda telah mengubah masing-masing bidang, alih-alih hanya merekam seluruh status terakhir objek. Ini juga berarti Anda sekarang dapat menggunakan apply di dalam alat apa pun, terlepas dari bahasa atau ketersediaan biner kubectl. Anda akan mendapatkan hasil konsisten yang sama, bagaimanapun Anda memulai operasi.

Menggunakan SSA Hari Ini

Anda dapat mengaktifkan SSA dengan menyetel flag –server-side setiap kali Anda menjalankan Kubectl apply:

$ kubectl apply -f nginx.yaml –server-side pod/nginx serverside-applied

Output perintah berubah untuk menyoroti bahwa SSA telah digunakan.

Memeriksa manifes YAML objek akan mengungkapkan bidang yang dikelola:

$ kubectl get pod nginx -o yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: “2022- 11-24T16:02:29Z” managedFields: – apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:spec: f:containers: k:{“name”:”nginx”}: .: {} f:image: {} f :name: {} manager: operasi kubectl: Terapkan waktu: “2022-11-24T16:02:29Z” – apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:status: f:conditions: k:{“type”:”ContainersReady “}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{“type”:”Initialized”}: .: {} f:lastProbeTime : {} f:lastTransitionTime: {} f:status: {} f:type: {} k: {“type”:”Ready”}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} f:containerStatuses: {} f:hostIP: {} f:fase: {} f:podIP: {} f:podIPs: .: {} k:{“ip”:”10.244.0.186″}: .: {} f:ip: {} f:startTime: {} manager: kubelet operation: Update subresource: status time: “2022-11-24T16:02:31Z” …

Field dikelompokkan bersama oleh manajer yang memilikinya. Dalam contoh ini, spek dikelola oleh Kubectl karena begitulah Pod dibuat. Akan tetapi, kolom status dikelola oleh Kubelet, karena Node yang menjalankan Pod mengubah nilai kolom tersebut selama siklus hidup Pod.

SSA juga siap digunakan di pengontrol. Ini memungkinkan semantik yang lebih kuat dan pengontrol jenis baru, termasuk pengontrol yang merekonstruksi objek. Model ini menangani perubahan dengan terlebih dahulu membangun kembali bidang objek dari awal hingga kepuasan pengontrol, lalu menerapkan hasilnya kembali ke server. Ini adalah metode yang lebih alami daripada membuat urutan operasi secara manual yang akan menghasilkan perubahan yang diinginkan.

Memeriksa Apakah Objek Dikelola Dengan SSA

Anda dapat memeriksa apakah suatu objek menggunakan CSA atau SSA dengan mengambil manifes YAML-nya di Kubectl:

$ kubectl get pod nginx -o yaml

Jika Anda melihat anotasi last-applied-configuration, objek Anda dikelola oleh CSA:

apiVersion: v1 kind: Pod metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {“apiVersion”:”v1″,”kind”:”Pod”,”metadata”:{“annotations”:{},”name”:”nginx”,”namespace”:”default”},”spec”: {“containers”:[{“image”:”nginx:latest”,”name”:”nginx”}]}} pembuatanTimestamp: “2022-11-24T14:20:07Z” name: nginx namespace: default … …

SSA telah digunakan untuk objek jika metadata.managedFields muncul sebagai gantinya:

apiVersion: v1 kind: Pod metadata: creationTimestamp: “2022-11-24T16:02:29Z” managedFields: – apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f :spec: f:containers: k:{“name”:”nginx”}: .: {} f:image: {} f:name: {} manager: kubectl operation: Apply time: “2022-11-24T16: 02:29Z”………

Anda dapat memindahkan objek antara CSA dan SSA hanya dengan menambahkan atau menghilangkan flag –server-side saat Anda menjalankan kubectl apply. Kubernetes menangani konversi last-applied-configuration menjadi managedFields dan sebaliknya.

Upgrade ke SSA dapat menimbulkan konflik jika manifes lokal Anda berbeda dari objek di server. Ini terjadi ketika kamu menjalankan perintah imperatif seperti kubectl scale atau kubectl label sejak operasi apply terakhir kamu terhadap objek. Anda harus memeriksa manifes lokal Anda secara akurat cocok dengan objek langsung sebelum mengonversi ke SSA.

Server-side apply adalah pendekatan untuk pengelolaan objek deklaratif di mana bidang dilacak oleh bidang kontrol Kubernetes. Ini memfasilitasi deteksi konflik yang kuat dan strategi penyelesaian yang fleksibel. SSA menangani batasan aplikasi sisi klien yang mengizinkan kolom untuk ditimpa secara tidak sengaja tanpa peringatan apa pun.

Meskipun SSA sekarang tersedia secara umum, Anda masih perlu menentukannya secara manual setiap kali Anda menjalankan kubectl apply. Perlu diingat bahwa SSA paling berguna dalam situasi di mana objek dikelola oleh beberapa proses berbeda, seperti operator manusia dengan Kubectl dan loop pengontrol. Anda tidak akan mendapat banyak manfaat dari SSA jika Anda secara eksklusif menggunakan kubectl apply untuk membuat dan memperbarui objek. Nbsp

A rilis Kubernetes mendatang diharapkan untuk menghapus CSA, menjadikan SSA sebagai opsi default dan satu-satunya. Bendera –server-side kemudian akan menjadi redundant.

Disadur dari HowToGeek.com.