Kubernetes 101: Deployment

Deployment menjalankan beberapa replika aplikasi dan secara otomatis menggantikan instans apa pun yang gagal atau menjadi tidak responsif.

Perkenalan Kubernetes 101: Deployment

Kubernetes telah mengukir ceruk untuk dirinya sendiri dalam bidang cloud computing yang luas, dengan pendekatan revolusionernya untuk mengelola aplikasi dalam container.

Platform orkestrasi sumber terbuka ini, awalnya dikembangkan oleh Google, telah menjadi standar nyata untuk mengatur dan mengelola kontainer dalam skala besar.

Inti dari Kubernetes adalah konsep Deployment. Melalui mekanisme Deployment-lah Kubernetes memastikan kontinuitas dan ketersediaan aplikasi, bahkan dalam menghadapi kegagalan hardware atau pemeliharaan rutin.

Kubernetes juga bertanggung jawab dalam mempertahankan status sistem yang diinginkan, menjaga replika aplikasi yang diperlukan tetap berjalan, dan mengelola peluncuran pembaruan.

Apa itu Deployment (di Kubernetes)?

Dalam leksikon Kubernetes, Deployment menandakan satu set dari beberapa Pod identik tanpa identitas unik. Deployment menjalankan beberapa replika aplikasi dan secara otomatis menggantikan setiap instans yang gagal atau tidak responsif.

Mendefinisikan Deployment artinya kamu menginstruksikan sistem Kubernetes tentang cara membuat dan memperbarui instans aplikasimu. Begitu Deployment dibuat, master Kubernetes menjadwalkan instance aplikasi yang disertakan dalam Deployment untuk berjalan di setiap Node dalam cluster.

Deployment dijelaskan dalam file YAML, di mana kamu menetapkan kondisi sistem yang diinginkan, termasuk berapa banyak replika aplikasi yang harus dipertahankan (ditentukan di bidang replicas), gambar container mana yang akan digunakan (ditentukan di bidang template), dan banyak lagi.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
        ports:
        - containerPort: 8080

Deployment dan Pods

Deployment Kubernetes bekerja sama dengan Pod, objek terkecil dan paling dasar yang dapat diterapkan di Kubernetes. Sebuah Pod mewakili satu proses yang berjalan dalam sebuah cluster dan dapat berisi satu atau beberapa kontainer.

Kontainer dalam Pod berbagi alamat IP, namespace IPC, dan sumber daya lainnya, yang memungkinkan mereka untuk bekerja sama dengan erat.

Deployment mengelola lifecycle dari Pod. Ketika sebuah Deployment dibuat, ia juga membuat ReplicaSet untuk memunculkan Pod.

Jika sebuah Pod mati selama masa pakainya (karena crash atau kegagalan node), Deployment memastikan bahwa Pod lain diputar sebagai pengganti, sehingga mempertahankan kondisi yang diinginkan sistem.

ReplicaSet: Kekuatan Pendorong di Balik Replikasi Pod di Kubernetes

ReplicaSet adalah sumber daya penting di Kubernetes yang memastikan jumlah “replica” Pod yang ditentukan berjalan pada waktu tertentu. ReplicaSet adalah pengontrol replikasi generasi berikutnya dalam sistem Kubernetes. Tujuan utama ReplicaSet yaitu untuk menjaga ketersediaan dan redundansi aplikasi dengan menangani lifecycle dari Pod.

Memahami Mekanisme ReplicaSet

Tujuan ReplicaSet adalah untuk mempertahankan set Pod replika yang stabil saat berjalan pada waktu tertentu. Ia menggunakan selector, yang berbasis set atau berbasis kesetaraan, untuk mengidentifikasi Pod yang harus dikelola.

Selector ini dibandingkan dengan label dalam metadata Pod untuk menentukan apakah Pod adalah bagian dari ReplicaSet.

Bidang replicas dalam spesifikasi ReplicaSet menentukan jumlah Pod yang diinginkan. Jika ada terlalu banyak Pod, ReplicaSet akan menghentikan Pod tambahan; jika jumlahnya terlalu sedikit, ReplicaSet akan memulai lebih banyak Pod.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-replicaset
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
        ports:
        - containerPort: 8080

Tak seperti Pod yang dibuat secara manual, Pod yang dikelola oleh ReplicaSet secara otomatis diganti, dihapus, atau dihentikan jika terjadi kegagalan. Hal ini sangat berguna jika kamu ingin memastikan sejumlah Pod selalu tersedia untuk menyediakan layanan, bahkan jika masing-masing Pod gagal.

ReplicaSet dan Deployment

Meskipun ReplicaSet memastikan ketersediaan sejumlah Pod identik yang ditentukan, ia tidak menawarkan mekanisme yang elegan untuk memperbarui Pod. Di situlah Deployment masuk.

Deployment adalah konsep tingkat tinggi yang mengelola ReplicaSet dan menyediakan pembaruan deklaratif untuk Pod bersama dengan banyak fitur berguna lainnya. Ketika kamu membuat Deployment, ia akan membuat ReplicaSet, yang kemudian memunculkan Pod.

Saat Deployment memperbarui Pod, ia membuat ReplicaSet baru dan secara bertahap mengalihkan traffic ke Pod baru, sambil mengalihkan ReplicaSet lama. Meskipun secara teknis dimungkinkan untuk membuat ReplicaSet tanpa Deployment, umumnya tidak disarankan.

Deployment menyediakan serangkaian fitur yang kuat di luar apa yang ditawarkan oleh ReplicaSets, termasuk kemampuan untuk mengembalikan ke versi sebelumnya dan dukungan untuk berbagai strategi pembaruan seperti penyebaran Blue-Green dan Canary.

Interaksi dengan ReplicaSets

Biasanya, kamu tidak perlu memanipulasi objek ReplicaSet secara langsung, karena mereka secara otomatis dikelola oleh Deployment. Namun, jika kamu ingin memeriksa status ReplicaSet, kamu dapat menggunakan perintah kubectl

Misalnya, untuk mendapatkan daftar ReplicaSet saat ini, kamu dapat menggunakan perintah kubectl get replicaset. Untuk mendeskripsikan ReplicaSet, kamu dapat menggunakan perintah kubectl describe replicaset <replicaset-name>, yang akan memberikan informasi rinci tentang ReplicaSet dan Pod yang dikelolanya.

Kesimpulannya, ReplicaSet di Kubernetes memastikan bahwa sejumlah Pod identik tertentu selalu aktif dan berjalan. Meskipun dapat digunakan sendiri, mereka biasanya dikelola sebagai bagian dari Deployment untuk fleksibilitas yang lebih baik dan kemudahan mengelola pembaruan.

Terlepas dari peran di belakang layar mereka, memahami ReplicaSets sangat penting untuk memahami mekanisme self-healing dan scaling di Kubernetes.

Deployment pada Self-Healing di Kubernetes

Self-healing adalah salah satu fitur Kubernetes yang paling kuat, dan yang pasti difasilitasi melalui Deployment. Fitur tersebut memastikan ketersediaan dan reabilitas aplikasi yang tinggi dengan secara otomatis mengganti atau menjadwalkan ulang Pods yang gagal, dihapus, atau dihentikan.

Meskipun Pod merupakan unit terkecil yang bisa diterapkan di Kubernetes, pada dasarnya ia tak tangguh. Jika Pod yang berjalan pada sebuah node gagal, Pod tidak akan memulai ulang secara otomatis. Itulah kemampuan self-healing Kubernetes, yang disediakan oleh konstruksi tingkat tinggi seperti Deployment, berperan.

Saat kamu membuat Deployment di Kubernetes, kamu bisa menentukan status yang diinginkan, termasuk informasi seperti gambar container yang akan digunakan, jumlah replika Pod yang akan dijalankan, dan lainnya.

Kubernetes terus mengamati kondisi sebenarnya dari sistem, dan jika keadaan tersebut menyimpang dari kondisi yang telah kamu tentukan (misalnya jika Pod crash atau node mati), Kubernetes akan mengambil Tindakan yang diperlukan untuk memperbaikinya – inilah yang disebut dengan istilah self-healing.

Mari ambil contoh konkret. Anggaplah kamu telah menentukan bahwa tiga replika dari Pod tertentu yang harus berjalan. Jika salah satu replika Pod ini gagal, Deployment akan menyadari perbedaan ini antara status yang diinginkan (tiga replika Pod yang berjalan) dan status aktual (dua replika Pod yang berjalan).

Untuk memperbaiki ini, Deployment menginstruksikan Kubernetes untuk memulai Pod baru, mengembalikan sistem ke kondisi yang diinginkan. Hal ini terjadi secara otomatis tanpa intervensi manual.

Ingatlah bahwa proses self-healing ini bukan hanya mengatasi Pod yang gagal. Jika sebuah node tersebut mati, Pods yang berjalan pada node tersebut juga akan hilang. Namun, Deployment mendeteksi hal tersebut dan memulai Pod baru di node lain yang tersedia, sehingga aplikasimu tetap tersedia.

Deployment Skalabilitas di Kubernetes

Skalabilitas adalah fitur penting lainnya dari Kubernetes, yang juga disediakan oleh Deployment. Dalam konteks Kubernetes, skalabilitas mengacu pada kemampuan untuk menangani peningkatan beban dengan menyesuaikan jumlah replika Pod.

Seperti halnya self-healing, kamu menentukan jumlah replika Pod dalam konfigurasi Deployment. Jika aplikasimu mengalami peningkatan beban, kamu bisa menyesuaikan jumlah replika Pod yang sesuai.

Saat kamu meningkatkan jumlah replica Pod, Deployment membuat Pod baru dan menjadwalkannya ke node dengan sumber daya yang tersedia. Begitu pula saat kamu mengurangi jumlahnya, Deployment akan menghapus kelebihan Pod.

Skalabilitas Deployment Kubernetes tidak hanya bersifat manual tetapi juga bisa diotomatisasi menggunakan Horizontal Pod Autoscaler. Berdasarkan pemanfaatan CPU atau metrik khusus (seperti permintaan HTTP per detik), Kubernetes bisa secara otomatis menskalakan jumlah replika Pod ke atas atau ke bawah untuk memenuhi permintaan beban aplikasimu.

Peran dari ReplicaSets

Saat membahas self-healing dan skalabilitas, kamu harus mengetahui peran ReplicaSets. ReplicaSet adalah objek Kubernetes lain yang memastikan sejumlah replika Pod berjalan pada waktu tertentu.

ReplicaSet inilah yang bertanggung jawab untuk membuat dan menghapus Pod yang diperlukan untuk memenuhi persyaratan skala yang ditentukan dalam Deployment-mu.

Meskipun kamu dapat membuat ReplicaSet secara langsung, umumnya disarankan menggunakan Deployment. Ia mengelola ReplicaSet dan menyediakan pembaruan deklaratif ke Pods bersama dengan banyak fitur berguna lainnya. Jadi, meskipun self-healing dan skalabilitas di Kubernetes disediakan oleh ReplicaSets, mereka biasanya dikelola dan dikontrol melalui Deployment.

Kesimpulannya, Deployment Kubernetes menambah kemampuan Pods dengan menyediakan self-healing dan skalabilitas. Dengan terus memantau kondisi sistem-mu dan membandingkannya dengan kondisi yang kamu tetapkan,

Kubernetes secara otomatis bangkit dari kegagalan dan beradaptasi dengan perubahan beban, sehingga memastikan ketahanan dan daya respon aplikasimu.

Rolling Update dalam Kubernetes Deployment

Rolling update yaitu metode penerapan perubahan secara progresif pada aplikasimu dengan cara yang aman, sehingga bisa mengurangi risiko gangguan layanan akibat pembaruan yang bermasalah. Kubernetes memiliki dukungan bawaan untuk rolling update, yang diterapkan ke Pod dan dikelola oleh Deployment.

Ketika kamu memperbarui spesifikasi Pod dalam manifes Deployment (biasanya berupa Docker dari container), Kubernetes memulai pembaruan bergulir. Ia membuat Pod baru dengan spesifikasi yang diperbarui, dan menggantikan Pod lama secara bertahap sambil memastikan aplikasi tetap tersedia.

maxUnavailable & maxSurge

maxUnavailable dan maxSurge adalah parameter yang digunakan dalam proses pembaruan Kubernetes Deployment. Keduanya merupakan bagian dari strategi pembaruan yang menentukan bagaimana Pod diganti saat diperbarui.

maxUnavailable mendefinisikan jumlah maksimum Pod yang tidak tersedia selama proses pembaruan. Nilainya bisa berupa angka absolut (misalnya, 1) atau persentase dari jumlah Pod yang diinginkan (misalnya, 10%).

Contohnya, kalau kamu memiliki 10 replika yang berjalan dan maxUnavailable diatur ke 2, maka Deployment akan memastikan setidaknya 8 replika tersedia setiap saat selama proses pembaruan. Jika maxUnavailable diatur ke “20%”, artinya, setidaknya (80% dari 10 replika) harus tetap tersedia selama pembaruan.

Pada maxSurge, bidang ini mendefinisikan jumlah maksimum Pod ekstra yang dapat dibuat melebihi jumlah Pod yang diinginkan. Nilainya bisa berupa angka absolut (misalnya, 1) atau persentase dari jumlah Pod yang diinginkan (misalnya, 10%).

Misalnya, kamu memiliki 10 replika dan maxSurge diatur ke 2, Deployment dapat membuat sampai 12 Pod (10 yang diinginkan ditambah 2 lonjakan) selama pembaruan. Jika maxSurge diatur ke “10%”, artinya hingga 11 Pod (10 yang diinginkan + 1 lonjakan) dapat dibuat selama pembaruan.

Kolom-kolom ini memberimu kendali atas proses peluncuran untuk memastikan ketersediaan dan penggunaan sumber daya aplikasi. Jika aplikasimu bisa menangani beberapa tingkat downtime, kamu mungkin mengizinkan lebih banyak Pod yang tidak tersedia untuk mempercepat pembaruan.

Di sisi lain, jika aplikasimu harus selalu tersedia, tapi kamu memiliki banyak sumber daya, kamu bisa mengizinkan lebih banyak Pod yang melonjak.

Rolling Back di Kubernetes Deployment

Salah satu kemampuan penting dari Deployment Kubernetes adalah kemampuannya untuk mengembalikan ke versi sebelumnya dari aplikasimu jika terjadi kegagalan atau pengenalan bug.

Ketika pembaruan Deployment tidak berjalan seperti yang diinginkan, Kubernetes menyediakan cara untuk kembali ke kondisi stabil sebelumnya.

Setiap kali pembaruan dipicu melalui Deployment, Revision baru pun dibuat, dan Kubernetes melacak Revisions tersebut. Setiap Revision berhubungan dengan ReplicaSet tertentu yang menyimpan templat Pod untuk versi tersebut.

Jika kamu perlu melakukan rollback, Kubernetes menggunakan ReplicaSet dari Revisi yang dipilih untuk mengembalikan versi aplikasi sebelumnya. Prosesnya otomatis, terkendali, dan umumnya cepat, jadi ia memastikan dampak minimal pada ketersediaan aplikasi dan pengalaman pengguna.

Memahami Revisions di Kubernetes Deployments

Revisions di Deployment Kubernetes mirip dengan kontrol versi untuk penerapan aplikasimu. Setiap kali kamu memperbarui Deployment di Kubernetes, Revision baru akan dibuat.

Hal ini memungkinkan untuk melacak perubahan pada Deployment-mu dari waktu ke waktu dan mengaktifkan fitur canggih seperti mengembalikan ke versi aplikasi sebelumnya, memastikan keandalan dan stabilitas layanan yang diterapkan.

Cara Kerja Revisions

Ketika kamu membuat Deployment di Kubernetes, Revision awal (Revision 1) akan dibuat. Revision ini sesuai dengan status awal Deployment-mu, termasuk templat Pod (yang berisi citra kontainer, nomor porta, dan sebagainya).

Tiap kali kamu memperbarui Deployment, misalnya dengan mengubah citra container atau memperbarui variable lingkungan, Revision baru pun dibuat. Ia berisi ReplicaSet baru dengan templat Pod yang diperbarui, yang mencerminkan perubahan yang dibuat dalam pembaruan tersebut.

Kubernetes secara otomatis melacak Revisions ini, dengan menambah nomor Revision setiap kali Deployment diperbarui. Dengan ini, kamu mungkin bisa melihat riwayat pembaruan Deployment dan perubahan yang dibuat dalam setiap pembaruan. Kamu bisa melihat Revision ini dan detailnya menggunakan perintah kubectl rollout history.

Rollbacks Menggunakan Revisions

Kemampuan untuk melacak Revisions menyediakan mekanisme yang kuat untuk mengelola pembaruan Deployment, khususnya melalui penggunaan rollback.

Jika pembaruan Deployment menimbulkan masalah, Kubernetes memungkinkan kamu untuk mengembalikan ke Revision sebelumnya. Ketika kamu melakukan rollback, Kubernetes menggunakan ReplicaSet yang terkait dengan Revision yang dipilih untuk memulihkan aplikasimu ke kondisi sebelumnya.

Maka dari itulah Kubernetes memastikan tidak ada downtime karena menggantikan Pod secara otomatis dari versi saat ini (yang bermasalah) dengan Pod dari versi sebelumnya (yang stabil). Ini semua terjadi tanpa intervensi manual, sehingga memungkinkan pemulihan cepat dari pembaruan yang gagal atau bug yang dimasukkan ke dalam produksi.

Untuk mengembalikan Deployment, kamu bisa menggunakan perintah kubectl rollout undo diikuti dengan nama Deployment, dan nomor revisi jika kamu ingin mengembalikan ke revision tertentu.

Mengelola Revisions

Secara default, Kubernetes menyimpan semua ReplicaSet lama dan Revision terkait untuk memungkinkan rollback. Tetapi, mungkin kamu tidak selalu ingin menyimpan semua Revision, terutama jika kamu sering memperbarui Deployment dan mempertimbangkan penyimpanan.

Untuk mengelola hal ini, Anda dapat menentukan revisionHistoryLimit dalam spesifikasi Deployment. Ia menentukan jumlah ReplicaSet lama (dan Revision terkait) yang ingin kamu simpan. ReplicaSet lama yang melebihi batas ini akan dihapus oleh garbage collector Kubernetes.

Contoh Deployment Manifest

Contoh sederhana dari Deployment Manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
        ports:
        - containerPort: 8080

Mari kita uraikan:

1. apiVersion: apps/v1: Versi API ini adalah yang digunakan Deployment. Deployment termasuk bagian dari grup API apps/v1.
2. kind: Deployment: Menentukan jenis objek Kubernetes yang sedang dibuat adalah Deployment.
3. metadata: Mencakup metadata tentang Deployment. Pada kolom name, menentukan nama Deployment (my-app-deployment), dan labels: menyediakan cara untuk mengatur objek Kubernetes yang berbeda. Di sini, kita melabeli Deployment dengan app: my-app.
4. spec: Tempat spesifikasi Deployment didefinisikan.

replicas: 3: Memberi tahu Kubernetes kalua kita ingin memiliki tiga replika dari Pod yang sedang berjalan.

selector: Cara Deployment menemukan Pod mana yang akan dikelola. Kita memerintahkan Deployment bahwa ia harus mengelola Pod dengan label app: my-app.

template: Templat untuk membuat Pod baru. Inilah yang dimaksud dengan bidang replicas: Bidang yang ketika dikatakan bahwa ia menginginkan tiga replica.

metadata: Blok ini berada di dalam template:, memberikan metadata ke Pod yang akan dibuat. Pada kasus ini, kita melabeli Pod dengan app:my-app.

spec: Terletak di dalam template:, menentukan spesifikasi Pod.

containers: Berisi spesifikasi untuk container yang akan dibuat dalam setiap Pod.

name: my-app-container: Nama yang diberikan pada container.

image: my-app:1.0: Memberi tahu Kubernetes citra Docker apa yang akan digunakan untuk container.

ports: Mendefinisikan port jaringan yang akan diungkapkan oleh container.

containerPort: 8080: Port yang akan digunakan oleh aplikasi di dalam container.

5. strategy: Bidang ini pada spec: dari file Deployment YAML menjelaskan strategi yang digunakan untuk menggantikan Pod lama dengan yang baru.

type: RollingUpdate: Mengatur tipe strategi ke RollingUpdate, yang artinya – Kubernetes memperbarui Pods secara berkala.

rollingUpdate: Menentukan parameter untuk strategi RollingUpdate.

maxUnavailable: 1: Bidang opsional yang menentukan jumlah maksimum Pod yang tak tersedia selama proses pembaruan. Nilainya bisa berupa angka absolut (misalnya, 1) atau persentase Pod yang diinginkan (misalnya, 10%). Nilai defaultnya adalah 25%.

maxSurge: 1: Bidang opsional yang menentukan jumlah maksimum Pod yang dapat dijadwalkan lebih dari jumlah Pod yang diinginkan. Nilainya juga bisa berupa angka absolut atau persentase. Nilai standarnya adalah 25%.