Artikel KOTA189
Node 01 / Platform Overview
KOTA189 # Container Orchestration Atur Banyak Layanan Gaming Biar Tetap Jalan dalam Satu Ekosistem
Menjalankan satu container masih gampang dibayangkan. Developer menyiapkan aplikasi memasukkannya bersama dependency yang diperlukan lalu menjalankannya pada resource yang tersedia. Ceritanya mulai berbeda ketika jumlahnya bukan lagi satu atau dua. Ada puluhan layanan dengan banyak instance yang bisa muncul berhenti diperbarui atau membutuhkan kapasitas berbeda. KOTA189 kali ini masuk ke container orchestration untuk melihat bagaimana kumpulan tersebut diatur supaya nggak berubah menjadi pekerjaan manual yang berantakan.
Orchestration pada dasarnya membawa lapisan pengelolaan di atas kumpulan container. Sistem nggak cuma diperintah untuk menjalankan sebuah container tetapi diberikan gambaran mengenai kondisi yang diinginkan. Dari sana orchestrator membantu menentukan tempat menjalankannya memantau kondisi workload dan mengambil tindakan ketika keadaan aktual mulai berbeda dari konfigurasi yang sudah ditetapkan.
Satu Container Masih Gampang Diurus Sendiri
Container membantu mengemas aplikasi bersama berbagai kebutuhan runtime sehingga lingkungan eksekusinya lebih konsisten. Untuk satu layanan sederhana proses pengelolaannya belum terasa rumit.
Masalah mulai muncul ketika sebuah sistem mempunyai banyak layanan. Satu service mungkin membutuhkan tiga instance sementara service lain membutuhkan sepuluh. Ada container yang harus diperbarui dan ada pula yang tiba-tiba berhenti bekerja.
Kalau semua perubahan tersebut harus ditangani satu per satu pekerjaan operasional bakal cepat membesar.
KOTA189 Mulai Membentuk Sebuah Cluster
Dalam container orchestration beberapa resource komputasi dapat dikumpulkan menjadi sebuah cluster. Dari sudut pandang pengelolaan resource tersebut nggak lagi diperlakukan sebagai mesin yang sepenuhnya berdiri sendiri.
Cluster menyediakan kumpulan kapasitas tempat workload dapat dijalankan. Orchestrator kemudian membantu menentukan bagaimana workload tersebut ditempatkan.
Buat teknologi KOTA189 cluster bisa dibayangkan sebagai satu ekosistem besar yang mempunyai banyak tempat untuk menjalankan layanan.
Node Menyediakan Tempat Buat Workload Berjalan
Di dalam cluster terdapat node yang menyediakan resource komputasi seperti CPU dan memory untuk workload.
Setiap node mempunyai kapasitas terbatas. Karena itu orchestrator nggak bisa terus menempatkan pekerjaan pada satu node sementara node lainnya kosong.
Kondisi kapasitas dan aturan penempatan menjadi bagian dari pertimbangan ketika workload baru perlu dijalankan.
Scheduler Jadi Pengatur Penempatan
Ketika sistem membutuhkan instance baru pertanyaan berikutnya sederhana tetapi penting yaitu container tersebut harus berjalan di mana?
Scheduler membantu menentukan node yang sesuai berdasarkan resource yang tersedia serta berbagai aturan penempatan yang sudah ditentukan.
Jadi developer nggak harus terus memilih server secara manual setiap kali instance baru muncul.
Resource Request Bikin Kebutuhan Workload Lebih Jelas
Nggak semua layanan membutuhkan kapasitas yang sama. Ada workload ringan dan ada pula proses yang memerlukan resource lebih besar.
Sistem orchestration dapat menggunakan informasi kebutuhan CPU atau memory sebagai salah satu dasar penempatan. Dengan begitu scheduler mempunyai gambaran mengenai resource minimum yang diperlukan sebuah workload.
Tanpa informasi yang masuk akal cluster bisa mengalami penempatan yang kurang efisien atau terlalu padat pada titik tertentu.
Desired State Jadi Target yang Terus Dijaga
Salah satu konsep menarik dalam orchestration adalah desired state. Operator menjelaskan kondisi yang diinginkan lalu sistem berusaha menjaga keadaan aktual mendekati kondisi tersebut.
Misalnya sebuah layanan ditentukan harus mempunyai beberapa instance aktif. Kalau salah satunya hilang kondisi aktual nggak lagi sesuai target.
Orchestrator kemudian dapat mengambil tindakan untuk mengembalikan jumlah instance sesuai konfigurasi.
Self Healing Bekerja Saat Container Bermasalah
Container bukan sesuatu yang pasti hidup selamanya. Proses bisa crash node bisa bermasalah atau aplikasi bisa masuk ke kondisi yang nggak sehat.
Container orchestration dapat memantau kondisi workload lalu mencoba menjalankan pengganti ketika instance yang dibutuhkan hilang.
Inilah yang sering disebut self-healing. Bukan berarti sistem mampu memperbaiki semua bug sendiri tetapi orchestrator dapat membantu mengembalikan workload ke kondisi operasional yang sudah ditentukan.
Health Check Nggak Cuma Bertanya Apakah Proses Masih Hidup
Sebuah proses bisa saja masih berjalan tetapi sebenarnya sudah nggak mampu melayani pekerjaan dengan benar. Karena itu status hidup saja belum selalu cukup.
Health check dapat digunakan untuk membantu menentukan kondisi aplikasi. Pemeriksaan bisa dibedakan berdasarkan kebutuhan seperti apakah aplikasi masih hidup dan apakah sudah siap menerima trafik.
Informasi tersebut membantu orchestration mengambil keputusan yang lebih tepat daripada hanya melihat keberadaan proses.
Traffic Sebaiknya Nggak Masuk Sebelum Layanan Siap
Container baru belum tentu langsung siap pada detik pertama. Aplikasi mungkin membutuhkan waktu untuk memuat konfigurasi membuka koneksi atau menyelesaikan proses inisialisasi.
Readiness check membantu memberi tahu sistem kapan sebuah instance sudah siap menerima trafik.
Dengan pendekatan ini request nggak langsung diarahkan ke container yang sebenarnya masih sibuk mempersiapkan diri.
Scaling Bikin Jumlah Instance Bisa Berubah
Kebutuhan kapasitas sebuah layanan nggak selalu sama sepanjang waktu. Pada kondisi tertentu beberapa instance mungkin cukup sementara pada periode lain dibutuhkan lebih banyak.
Orchestration mempermudah perubahan jumlah instance tanpa harus menjalankan container satu per satu secara manual.
Scaling dapat dilakukan berdasarkan keputusan operator atau menggunakan mekanisme otomatis berdasarkan metrik tertentu sesuai desain infrastrukturnya.
Autoscaling Tetap Butuh Sinyal yang Masuk Akal
Menambah instance otomatis terdengar sederhana tetapi sistem tetap membutuhkan dasar untuk mengambil keputusan.
CPU memory atau metrik aplikasi tertentu dapat menjadi sinyal tergantung karakter workload. Pemilihan metrik yang salah bisa membuat scaling terlalu agresif atau justru terlambat.
Karena itu autoscaling bukan sekadar mengaktifkan tombol otomatis. Perilaku workload tetap harus dipahami.
Service Membuat Container yang Berubah Tetap Bisa Ditemukan
Container dalam lingkungan orchestration bersifat dinamis. Instance lama dapat hilang lalu digantikan instance baru yang berjalan di lokasi berbeda.
Aplikasi lain tentu nggak praktis kalau harus terus mengikuti alamat setiap container secara manual. Dibutuhkan lapisan layanan yang menyediakan titik akses lebih stabil.
Dengan begitu komunikasi dapat diarahkan ke kelompok workload tanpa konsumen harus mengetahui setiap instance di belakangnya.
Load Balancing Membagi Request ke Beberapa Instance
Ketika sebuah layanan mempunyai beberapa instance trafik perlu dibagi supaya pekerjaan nggak hanya menumpuk pada satu container.
Load balancing membantu mendistribusikan request ke instance yang tersedia sesuai mekanisme sistem.
Kalau satu instance sudah tidak siap menerima trafik health dan readiness information dapat membantu mencegah request terus diarahkan ke sana.
Rolling Update Bikin Versi Baru Masuk Bertahap
Pembaruan aplikasi nggak selalu harus dilakukan dengan menghentikan seluruh instance lalu menggantinya sekaligus.
Rolling update memungkinkan versi baru diperkenalkan secara bertahap. Sebagian instance lama diganti sementara instance lain masih melayani pekerjaan.
Setelah instance baru dinyatakan siap proses dapat dilanjutkan sampai versi lama tergantikan sesuai strategi deployment.
Update Gagal Harus Punya Jalan Keluar
Versi terbaru nggak otomatis berarti versi terbaik. Bug konfigurasi salah atau dependency yang bermasalah bisa membuat deployment baru gagal.
Karena itu proses deployment membutuhkan monitoring serta strategi pemulihan. Kalau kondisi baru nggak memenuhi standar yang diharapkan perubahan bisa dihentikan atau dikembalikan sesuai mekanisme yang tersedia.
Orchestration membantu prosesnya tetapi keputusan mengenai versi yang aman tetap membutuhkan pengujian dan observability.
Configuration Nggak Harus Ditanam di Dalam Image
Aplikasi sering mempunyai konfigurasi yang berbeda antarlingkungan. Kalau setiap perubahan konfigurasi mengharuskan image baru proses pengelolaan bisa menjadi kurang fleksibel.
Lingkungan orchestration biasanya menyediakan mekanisme untuk memisahkan konfigurasi dari image aplikasi.
Dengan begitu image yang sama dapat digunakan dengan konfigurasi berbeda sesuai lingkungan tanpa harus mengubah kode aplikasinya.
Data Rahasia Perlu Jalur Pengelolaan Sendiri
Password token atau credential layanan nggak seharusnya ditempel sembarangan ke image maupun konfigurasi terbuka.
Sistem orchestration dapat mempunyai mekanisme pengelolaan secret tetapi cara penyimpanan akses dan distribusinya tetap perlu dirancang dengan benar.
Pemisahan secret dari source code menjadi bagian penting dari praktik operasional yang lebih aman.
Container Bisa Hilang tetapi Data Nggak Selalu Boleh Ikut Hilang
Banyak workload container dirancang supaya instance bisa dibuat dan dihentikan dengan mudah. Tetapi beberapa aplikasi tetap membutuhkan penyimpanan data yang bertahan lebih lama daripada umur sebuah container.
Karena itu storage persisten perlu diperlakukan berbeda dari filesystem sementara milik container.
Arsitektur harus menentukan data mana yang memang sementara dan mana yang membutuhkan penyimpanan persisten.
Cluster Juga Punya Batas Kapasitas
Orchestration bukan pencipta resource tanpa batas. Kalau seluruh node sudah penuh scheduler nggak bisa begitu saja menemukan kapasitas baru yang sebenarnya nggak tersedia.
Tim tetap perlu memantau penggunaan resource dan merencanakan kapasitas cluster. Pada infrastruktur yang mendukungnya jumlah node juga dapat disesuaikan menggunakan mekanisme scaling tersendiri.
Jadi scaling container dan scaling infrastruktur dasarnya merupakan dua lapisan yang saling berhubungan.
Observability Membantu Melihat Isi Ekosistem KOTA189
Semakin banyak workload semakin penting kemampuan melihat kondisi cluster. Operator perlu mengetahui container mana yang restart node mana yang kekurangan resource serta deployment mana yang mulai menghasilkan error.
Metrics logs dan event operasional dapat digunakan untuk membangun gambaran kondisi sistem.
Tanpa observability orchestration memang tetap menjalankan otomatisasi tetapi manusia bakal kesulitan memahami kenapa sistem mengambil tindakan tertentu.
Orchestration Nggak Menghapus Semua Kerumitan
Container orchestration menyelesaikan banyak pekerjaan operasional tetapi sebagai gantinya muncul lapisan teknologi baru yang juga perlu dipahami.
Scheduling networking storage security deployment sampai observability semuanya mempunyai aturan sendiri. Untuk sistem kecil kompleksitas tersebut belum tentu diperlukan.
Karena itu penggunaan orchestration sebaiknya mengikuti kebutuhan nyata bukan sekadar karena teknologinya populer.
KOTA189 Mengubah Banyak Container Menjadi Satu Ekosistem
Tema KOTA189 kali ini bukan tentang membuat satu container menjadi lebih hebat. Fokusnya adalah bagaimana banyak container dengan pekerjaan berbeda dapat hidup dalam infrastruktur yang sama tanpa semuanya harus diatur secara manual.
Cluster menyediakan lingkungannya node membawa resource scheduler menentukan penempatan dan health check membantu melihat kondisi workload. Ketika kebutuhan berubah scaling dapat menyesuaikan jumlah instance sementara rolling update membantu versi baru masuk secara bertahap.
Dari luar pengguna mungkin cuma melihat satu layanan gaming. Di baliknya bisa ada banyak komponen yang terus muncul berpindah diperbarui dan digantikan. Buat sistem KOTA189 container orchestration berperan sebagai pengatur yang menjaga kumpulan tersebut tetap bekerja sebagai satu ekosistem meskipun bagian di dalamnya terus berubah.
