Dalam dunia sistem digital modern, kecepatan dan efisiensi bukan lagi sekadar nilai tambah keduanya sudah menjadi kebutuhan utama. Setiap kali kita membuka aplikasi, melakukan transaksi online, atau sekadar mengakses data dari server, ada ribuan proses kecil yang berjalan di balik layar. Semua proses itu terjadi dalam hitungan detik, bahkan milidetik. Untuk mengukur seberapa cepat sistem dapat menangani semua aktivitas tersebut, digunakanlah sebuah metrik penting yang bernama TPS (Transaction Per Second). Metrik ini menjadi salah satu indikator utama dalam pemantauan performa aplikasi, terutama bagi sitem berskala besar yang menangani ribuan hingga jutaan transaksi setiap harinya.

 

Apa itu TPS?

Secara sederhana, TPS atau Transactions per Second adalah ukuran yang menunjukan berapa banyak transaksi yang dapat diselesaikan oleh sistem dalam 1 detik. Setiap transaksi bisa memiliki arti berbeda tergantung aplikasinya bisa berupa satu permintaan dari pengguna ke server, eksekusi query ke database, pemanggilan API, hingga proses bisnis internal di dalam aplikasi. Istilah “Service Rate” kadang juga digunakan sebagai padanan dari TPS, karena keduanya sama-sama menggambarkan seberapa cepat layanan mampu merespons permintaan. Makin tinggi nilai TPS, semakin besar kemampuan sistem dalam memproses transaksi dalam waktu bersamaan. Namun penting untuk diingat bahwa perhitungan TPS didasarkan pada waktu saat transaksi benar-benar selesai diproses, bukan saat permintaaan dikirim. Artinya, TPS mencerminkan kecepatan nyata sistem dalam menyelesaikan pekerjaan, bukan sekedar banyaknya request yang masuk. 

 

Mengapa TPS Itu Penting? 

TPS dapat dianggap sebagai detak jantung performa sistem. Dengan memantau TPS, kita bisa mengetahui apakah sistem berjalan dengan kondisi optimal, mulai menurun performanya, atau bahkan menghadapi bottleneck tertentu. 

Beberapa alasan kenapa TPS penting untuk diperhatikan: 

1. Menilai kapasitas sistem: TPS membantu mengetahui seberapa besar beban transaksi yang bisa ditangani sistem tanpa mengalami penurunan performa.
2. Mengidentifikasi hambatan: Penurunan nilai TPS bisa menandakan adanya masalah pada CPU, memori, jaringan, atau desain aplikasi.
3. Mendukung perencanaan kapasitas: Dengan data TPS, tim dapat menentukan kapan sistem perlu di-scale up atau dioptimalkan.
4. Meningkatkan pengalaman pengguna: Sistem dengan TPS tinggi berarti permintaan pengguna diproses dengan cepat, menghasilkan pengalaman yang lebih responsif dan stabil

 

Mengenal Max TPS

Selain nilai TPS saat ini, ada juga metrik penting bernama Max TPS, yaitu jumlah transaksi per detik tertinggi yang pernah dicapai oleh sistem dalam periode tertentu. Max TPS sering digunakan untuk melihat performa maksimal sistem seberapa cepat sistem bisa “berlari” dalam kondisi terbaiknya. Dengan membandingkan TPS saat ini dengan Max TPS, tim teknis bisa menilai apakah performa sistem masih stabil mulai menurun dari kapasitas idealnya.

 

TPS dalam APM JENNIFER

 

 

Dalam konteks pemantauan performa aplikasi, seluruh data tersebut dapat diakses secara langsung melalui APM JENNIFER, sebuah platform Application Performance Monitoring (APM) yang berfungsi untuk memantau kondisi sistem secara real-time. Melalui chart TPS di APM JENNIFER, pengguna dapat melihat bagaimana jumlah transaksi per detik berubah dari waktu ke waktu. Setiap lonjakan pada grafik menandakan peningkatan aktivitas pengguna atau sistem, sedangkan penurunan drastis dapat menjadi indikasi bahwa sistem sedang mengalami beban berat atau penurunan performa.

Yang menarik, APM JENNIFER tidak hanya menampilkan angka TPS secara mentah, tetapi juga menyajikannya dalam bentuk visual yang informatif dan mudah dipahami, bahkan oleh pengguna non-teknis.
Bagi tim teknis, data ini dapat dimanfaatkan untuk analisis lebih mendalam seperti mengidentifikasi waktu puncak transaksi, pola peningkatan beban sistem, serta menentukan langkah optimasi yang diperlukan untuk menjaga performa tetap stabil.

 

Penutup

TPS adalah salah satu metrik paling fundamental untuk memahami bagaimana sebuah sistem menangani beban kerja di dunia nyata. Ia bukan sekadar angka, tetapi representasi langsung dari kecepatan, efisiensi, dan stabilitas aplikasi. Melalui APM JENNIFER, pemantauan TPS menjadi jauh lebih mudah dan informatif. Pengguna bisa melihat performa sistem secara visual, cepat, dan akurat membantu tim untuk mengambil keputusan berbasis data, bukan asumsi.

Pada artikel berikutnya, kita akan membahas lebih dalam tentang grafik TPS di APM JENNIFER, termasuk cara membaca polanya dan bagaimana metrik ini berhubungan dengan performa aplikasi secara keseluruhan.

 

Dalam dunia pengembangan aplikasi modern, kecepatan dan stabilitas menjadi dua faktor utama keberhasilan. Tim DevOps kini dituntut tidak hanya untuk mempercepat proses delivery, tetapi juga memastikan sistem tetap optimal dalam kondisi dinamis — mulai dari lingkungan pengujian hingga produksi.

Untuk mencapai hal tersebut, Application Performance Monitoring (APM) berperan sebagai jembatan antara tim pengembang dan operasi. Salah satu solusi APM yang terbukti efektif dalam mendukung prinsip DevOps adalah JENNIFER APM.

DevOps dan Pentingnya Observability

DevOps bukan hanya tentang otomasi pipeline CI/CD, tetapi juga tentang kolaborasi dan visibilitas. Tanpa visibilitas yang baik terhadap kinerja aplikasi dan infrastruktur, tim DevOps akan kesulitan mendeteksi anomali, memahami penyebab masalah, dan mengambil tindakan cepat.

Di sinilah konsep Observability masuk. Observability adalah sifat bawaan sistem yang memungkinkan Anda untuk memahami kondisi internalnya dari data eksternal yang dikumpulkan: metrics, traces, dan logs (tiga pilar).

• Monitoring berfokus pada pertanyaan yang sudah Anda ketahui tentang kesehatan sistem (apa yang salah?), seperti "Apakah CPU di atas 80%?". Monitoring adalah tindakan mengawasi metrik yang sudah didefinisikan.

• Observability berfokus pada kemampuan untuk menjawab pertanyaan baru yang belum pernah Anda antisipasi (mengapa hal itu salah?), memungkinkan diagnostik mendalam untuk menemukan akar penyebab masalah.

Dengan kata lain, Observability adalah prasyarat dan evolusi dari Monitoring. Observability memberikan data mentah yang kaya, sementara Monitoring memanfaatkan data tersebut untuk membuat alert dan dashboard. JENNIFER APM membantu tim menjembatani keduanya, menyediakan data observabilitas yang dibutuhkan untuk monitoring yang efektif.

JENNIFER APM dalam Ekosistem DevOps

JENNIFER APM tidak hanya berfungsi sebagai alat pemantauan performa aplikasi, tetapi juga sebagai bagian dari toolchain observability di pipeline DevOps.

Beberapa kemampuan yang mendukung integrasi ini antara lain:

1. Real-Time Metrics dan Alerting – Memberikan data performa secara langsung kepada tim operasi untuk mendeteksi masalah seketika.

2. Profiling Dinamis Tanpa Restart – Developer dapat menambahkan profil metode tanpa mengganggu layanan yang sedang berjalan.

3. Integrasi dengan Infrastruktur Modern (Container & Cloud) – Melalui JENNIFER for Kubernetes, sistem dapat memantau performa setiap pod, namespace, dan microservice secara detail.

4. REST API & Data Export – Memungkinkan integrasi dengan sistem analitik lain seperti Prometheus, Grafana, atau ELK Stack.

JENNIFER for Kubernetes: Langkah Menuju Observability

Dengan adopsi Kubernetes yang semakin luas, arsitektur aplikasi kini tersebar ke berbagai container dan microservice. Pemantauan di level host saja sudah tidak cukup.

JENNIFER for Kubernetes hadir sebagai solusi untuk menjawab tantangan ini.
Fitur utamanya mencakup:

• Auto-Discovery Container & Pod
  JENNIFER otomatis mendeteksi layanan di dalam cluster tanpa konfigurasi manual.

• Visualisasi Cluster Topology
  Menampilkan hubungan antar layanan, node, dan namespace secara grafis.

• Resource Monitoring (CPU, Memory, Network, Disk)
  Memonitor pemakaian sumber daya per container secara real-time.

• Integrasi APM & Infrastruktur View
  Menyatukan performa aplikasi dan metrik infrastruktur dalam satu dashboard terpadu.

Dengan kemampuan ini, tim DevOps dapat:

• Mendeteksi bottleneck antar layanan.

• Melihat dampak performa satu container terhadap keseluruhan sistem.

• Melakukan optimasi otomatis berdasarkan beban nyata.

 

Pipeline DevOps + JENNIFER: Kolaborasi Nyata

Dalam pipeline DevOps, JENNIFER dapat diintegrasikan di beberapa tahap:

1. Build Stage: Developer dapat menggunakan JENNIFER untuk menguji performa modul sebelum deployment.

2. Deploy Stage: Setelah aplikasi dirilis ke Kubernetes, JENNIFER secara otomatis mulai memantau setiap instance.

3. Operate Stage: Tim operasi menggunakan alert & dashboard untuk mendeteksi penurunan performa dan menginformasikan kembali ke pengembang.

4. Feedback Stage: Data performa dari JENNIFER digunakan untuk memperbaiki pipeline CI/CD dan memperkuat reliabilitas sistem.

Integrasi dua arah ini menciptakan loop observability — di mana setiap perubahan kode dapat diukur dampaknya terhadap performa sistem secara langsung.

Manfaat Nyata Integrasi JENNIFER di Lingkungan DevOps

• Transparansi menyeluruh dari kode hingga infrastruktur.

• Deteksi dan respon cepat terhadap masalah performa di lingkungan produksi.

• Kolaborasi lebih baik antara tim pengembang, QA, dan operasi.

• Data-driven optimization untuk meningkatkan keandalan sistem dari waktu ke waktu.

• Kesiapan cloud-native dengan dukungan penuh untuk Kubernetes dan container.

Kesimpulan

Transformasi dari monitoring tradisional menuju observability modern adalah langkah alami bagi organisasi yang menerapkan DevOps.

Dengan JENNIFER APM dan JENNIFER for Kubernetes, tim IT dapat memiliki pemahaman mendalam dan terintegrasi tentang performa aplikasi, infrastruktur, dan perilaku pengguna — semua dalam satu sistem.

Integrasi ini bukan hanya tentang teknologi, tetapi tentang membangun budaya DevOps yang kolaboratif dan berbasis data.
Dan di tengah dunia cloud-native yang semakin kompleks, JENNIFER hadir sebagai mitra yang andal untuk memastikan sistem tetap stabil, efisien, dan transparan.

Apakah Anda pernah merasa frustrasi ketika aplikasi yang Anda gunakan berjalan lambat, macet, atau tidak tersedia? Apakah Anda pernah kehilangan pelanggan atau pendapatan karena masalah kinerja aplikasi? Jika jawabannya ya, maka Anda membutuhkan APM. APM adalah singkatan dari Application Performance Monitoring, yaitu proses mengukur dan mengoptimalkan kinerja dan ketersediaan aplikasi perangkat lunak. Dalam artikel ini, kami akan menjelaskan apa itu APM, bagaimana cara kerjanya, dan mengapa penting bagi bisnis Anda.

Untuk memahami apa itu APM ( Application Performance Monitoring), mari kita mulai dengan definisi sederhana. Menurut Gartner, APM adalah “kumpulan teknologi yang memungkinkan pemantauan dan pengelolaan kesehatan dan kinerja aplikasi perangkat lunak”. Dengan kata lain, APM adalah cara untuk mengukur seberapa baik aplikasi Anda berfungsi dan seberapa puas pengguna Anda dengan aplikasi Anda.

APM bukanlah teknologi baru, tetapi telah berkembang seiring dengan perkembangan aplikasi perangkat lunak. Pada awalnya, APM hanya berfokus pada pemantauan ketersediaan dan waktu respons aplikasi. Namun, kini APM mencakup aspek-aspek lain seperti pemantauan kode, metrik server, lalu lintas jaringan, perilaku pengguna, dan transaksi bisnis. APM juga harus dapat menangani aplikasi yang kompleks, dinamis, dan terdistribusi di berbagai lingkungan cloud, wadah, dan layanan mikro.

Baca juga : Auto Stacktrace Fitur Canggih dari APM Jennifer Dari Korea

Pemantauan Kinerja Aplikasi (APM) adalah proses mengukur dan mengoptimalkan kinerja dan ketersediaan aplikasi perangkat lunak. APM membantu pengembang, pengoperasian TI, dan pemangku kepentingan bisnis untuk mengidentifikasi dan menyelesaikan masalah yang memengaruhi pengalaman pengguna dan hasil bisnis.

APM biasanya melibatkan pengumpulan dan analisis data dari berbagai sumber, seperti kode instrumen, metrik server, lalu lintas jaringan, perilaku pengguna, dan transaksi bisnis. Alat APM menggunakan data ini untuk memberikan wawasan tentang kesehatan dan kinerja aplikasi, seperti waktu respons, tingkat kesalahan, throughput, ketersediaan, pemanfaatan sumber daya, dan kepuasan pengguna.

APM dapat membantu Anda untuk:

• Meningkatkan kualitas dan pembelaan aplikasi Anda dengan mendeteksi dan mendiagnosis masalah sebelum berdampak pada pengguna.
• Mengoptimalkan kinerja dan efisiensi aplikasi Anda dengan mengidentifikasi dan menghilangkan hambatan dan pemborosan sumber daya.
• Tingkatkan pengalaman dan pertahankan pengguna dengan memastikan pengiriman aplikasi Anda yang cepat dan konsisten di berbagai perangkat dan lokasi.
• Menyelaraskan operasi TI dan tujuan bisnis Anda dengan memantau dan melaporkan indikator kinerja utama (KPI) dan perjanjian tingkat layanan (SLA).

Kesimpulan:

Application Performance Monitoring adalah proses mengukur dan mengoptimalkan kinerja dan ketersediaan aplikasi perangkat lunak. APM ( Application Performance Monitoring) membantu pengembang, pengoperasian TI, dan pemangku kepentingan bisnis untuk mengidentifikasi dan menyelesaikan masalah yang mempengaruhi pengalaman pengguna dan hasil bisnis. APM juga dapat meningkatkan kualitas, efisiensi, dan keselarasan aplikasi dengan tujuan bisnis. Dengan menggunakan alat APM yang tepat, Anda dapat memastikan bahwa aplikasi Anda selalu berfungsi dengan baik dan memberikan nilai kepada pengguna Anda.

Mau mencoba APM Jennifer klik disini 

1. Definisi GitOps dan Single Source of Truth (SSOT)

Pertama, mari kita pahami definisi Sistem GitOps. Seperti yang telah dijelaskan sebelumnya mengenai karakteristik Kubernetes yang berbasis deklaratif dan proses instalasinya, semua sumber daya dalam Kubernetes dapat dikonfigurasi menggunakan kode. Sistem GitOps adalah konsep di mana konfigurasi tersebut disimpan dalam repositori Git, dan sistem memastikan bahwa kondisi operasional saat ini (Ops) selalu selaras dengan kode yang tersimpan di Git.

Dalam lingkungan kerja, Sistem GitOps sering digunakan untuk mencegah perubahan langsung pada sistem produksi tanpa melalui proses commit dan push ke Git. Tanpa GitOps, seseorang bisa saja mengubah konfigurasi langsung dari sumber lokalnya atau melalui perintah manual, yang dapat menyulitkan pelacakan riwayat perubahan. Salah satu skenario umum yang sering terjadi adalah ketika hanya sebagian cluster mengalami masalah, dan setelah diperiksa, ternyata ada perubahan yang dilakukan secara manual tanpa terdokumentasi dengan baik. Selain itu, dalam proses membangun sistem baru, tanpa pendekatan GitOps, sering kali diperlukan upaya tambahan untuk mencari dan menerapkan konfigurasi yang benar.Sistem GitOps

Sistem GitOps mengadopsi konsep Single Source of Truth (SSOT), yang juga perlu dipahami dengan baik. SSOT adalah prinsip dalam manajemen data yang menyatakan bahwa hanya ada satu versi data yang akurat dan terpercaya yang digunakan di seluruh sistem. Konsep ini berperan penting dalam meningkatkan konsistensi, akurasi, dan efisiensi dalam pengelolaan sistem.

• Konsistensi: Semua komponen sistem mengacu pada sumber data yang sama, sehingga memastikan bahwa tidak ada perbedaan dalam informasi yang digunakan.
• Akurasi: Mengurangi kemungkinan duplikasi atau inkonsistensi, sehingga meningkatkan keakuratan data.
• Efisiensi: Dengan adanya satu lokasi utama untuk penyimpanan dan pemeliharaan data, proses pembaruan dan manajemen menjadi lebih efisien.

Dengan menerapkan Sistem GitOps dan konsep SSOT, organisasi dapat menjaga stabilitas sistem, meningkatkan keandalan operasional, dan mempermudah manajemen infrastruktur berbasis Kubernetes.

Dalam Sistem GitOps, repositori Git berperan sebagai Single Source of Truth (SSOT) untuk konfigurasi dan status sistem. Dengan menyimpan serta membuat versi dari seluruh kondisi kode dan infrastruktur di dalam repositori Git, sistem dapat dikelola dan diotomatisasi menggunakan pendekatan deklaratif. Ini berarti bahwa perubahan terhadap kondisi operasional tidak dilakukan secara manual oleh individu melalui perintah langsung atau sumber lokal yang belum dikomit, melainkan hanya melalui repositori Git yang terpusat.

Salah satu keuntungan terbesar dari Sistem GitOps adalah kemampuannya untuk menjaga konsistensi sistem, yang pada akhirnya meningkatkan produktivitas kolaborasi tim. Karena semua sistem dan pengguna mengacu pada satu sumber data yang sama, kemungkinan terjadinya inkonsistensi informasi berkurang, dan upaya serta biaya yang diperlukan untuk mengelola serta menyinkronkan data yang duplikat juga menurun. Selain itu, fitur pencarian untuk melihat kembali status sistem pada titik waktu tertentu juga sering dimanfaatkan.

Namun, menerapkan prinsip ini sering kali tidak mudah. Dalam kesibukan pekerjaan sehari-hari, ada banyak godaan untuk mengabaikan prinsip GitOps dan melakukan perubahan langsung tanpa melalui repositori Git. Oleh karena itu, penting untuk menggunakan alat GitOps yang mampu menegakkan kebijakan serta memastikan adanya arsitektur data, proses, dan alat manajemen yang tepat.

Untuk mengimplementasikan Sistem GitOps, terdapat berbagai alat yang dapat digunakan. Dalam hal Continuous Deployment (CD), ArgoCD adalah salah satu alat yang paling banyak digunakan karena beberapa alasan:

1. Menyediakan antarmuka pengguna (UI) yang mudah digunakan.
2. Mudah diintegrasikan dengan alat lain.
3. Memiliki banyak pengguna, sehingga dokumentasi dan contoh kasusnya melimpah.

Dengan menggunakan ArgoCD, organisasi dapat menerapkan GitOps secara lebih efektif, menjaga konsistensi sistem, dan meningkatkan efisiensi operasional.

ArgoCD: Pemantauan dan Sinkronisasi Otomatis

ArgoCD secara terus-menerus memantau repositori Git yang ditentukan dan klaster Kubernetes. Jika terdeteksi perubahan dalam repositori, ArgoCD secara otomatis menyinkronkan status klaster agar sesuai dengan status di repositori. Selain mode otomatis, ArgoCD juga menyediakan opsi sinkronisasi manual, yang berguna dalam situasi tertentu. Jika terjadi masalah, sistem dapat dengan mudah dikembalikan ke keadaan sebelumnya (rollback). Berkat fitur manajemen versi Git, semua riwayat perubahan dapat dilacak, sehingga pemulihan ke kondisi yang stabil menjadi lebih mudah.

BACA JUGA : Cara Instalasi EKS di AWS Menggunakan Terraform

ArgoCD juga menyediakan dasbor visual yang memungkinkan pengguna untuk memantau status aplikasi secara real-time, melihat sinkronisasi, serta mengevaluasi kesehatan (Health) aplikasi. Saat aplikasi dikelola menggunakan Helm, sering kali sulit untuk memahami keseluruhan sumber daya yang digunakan. Namun, dengan dasbor ArgoCD, pengguna dapat dengan mudah melihat struktur aplikasi mereka, menjadikannya fitur yang sangat disukai. Selain itu, ArgoCD memungkinkan pengaturan kontrol akses berbasis proyek dan pengguna, sehingga anggota tim hanya mendapatkan akses sesuai dengan peran mereka.

ArgoCD menggunakan repositori Git sebagai Single Source of Truth (SSOT) untuk memastikan bahwa status klaster Kubernetes selalu tersinkronisasi dan termonitor secara berkelanjutan. Dengan pendekatan ini, kolaborasi antara tim pengembang dan operasi (DevOps) menjadi lebih efektif, serta proses deployment menjadi lebih stabil dan cepat.

Praktik Langsung ArgoCD

Berikut adalah langkah-langkah praktikum yang akan kita lakukan:

1. Instalasi ArgoCD
2. Mendeploy Helm Chart NGINX menggunakan ArgoCD
3. Eksperimen GitOps – Validasi Perubahan Manual di Lingkungan Lokal

Mari kita mulai dengan langkah pertama!

2. Instalasi Argo-CD

Instalasi Aplikasi di Kubernetes dengan Helm Dalam lingkungan Kubernetes, aplikasi biasanya diinstal menggunakan Helm. Helm adalah manajer paket untuk Kubernetes, mirip dengan APT atau YUM pada sistem operasi berbasis Linux. Dengan Helm, berbagai sumber daya Kubernetes dapat dikemas menjadi satu unit yang disebut chart, sehingga proses instalasi, pembaruan, dan penghapusan aplikasi menjadi lebih sederhana. Pembahasan lebih detail mengenai Helm akan dijelaskan pada Bab 11.

Sekarang, mari kita instal ArgoCD menggunakan Helm.

• Pengguna Windows WSL dengan Homebrew dan pengguna macOS dapat menginstal Helm di PC lokal mereka menggunakan brew.

Sistem GitOps

Selanjutnya, unduh Helm Chart ArgoCD dari situs resmi ArgoCD.

Daftarkan repositori Helm ArgoCD yang ada di remote menggunakan perintah helm repo add, lalu unduh Helm Chart ke lokal dengan perintah helm pull.

Setelah itu, untuk menyesuaikan file konfigurasi Helm (Values.yaml) sesuai dengan lingkungan yang digunakan, salin file Values.yaml bawaan dan ubah namanya menjadi jerry-test-values.yaml.

Penjelasan lebih lanjut mengenai perintah Helm dapat ditemukan pada Bab 11.

Berikut adalah modifikasi dari Helm Values resmi (lihat referensi di GitHub penulis).

.configs.credentialTemplates.ssh-creds

Daftarkan informasi repositori GitHub yang akan digunakan dalam ArgoCD. Masukkan informasi kunci SSH yang telah terdaftar di GitHub Anda (biasanya terletak di ~/.ssh/id_rsa). Karena ini adalah informasi kunci pribadi, untuk alasan keamanan, informasi ini telah dimasking (xxxxx).

Informasi repositori dapat didaftarkan setelah instalasi ArgoCD selesai, dan juga bisa dilakukan melalui antarmuka grafis (GUI). Namun, disarankan untuk mengikuti filosofi GitOps dengan memasukkan informasi repositori Git ke dalam kode sumber. Meskipun mungkin terasa merepotkan di awal, menghindari penggunaan GUI akan lebih baik dalam hal keberlanjutan dan kemampuan untuk digunakan kembali di masa depan.

.repositories.k8s-class.name/url

Daftarkan nama dan URL repositori Git Anda.

Saat ini, pengaturan terkait Ingress belum dilakukan, sehingga pengaturan Helm Values yang berkaitan dengan Ingress masih belum ada. Setelah pengaturan Ingress di Bab 5 selesai, Anda dapat menambahkan konfigurasi Ingress untuk memudahkan akses menggunakan alamat Ingress.

Gunakan file Helm Values tersebut (jerry-test-values.yaml) untuk menginstal ArgoCD.

Setelah instalasi selesai, Anda dapat memeriksa pod yang terkait dengan ArgoCD.

3. Akses Pod Argo-CD Menggunakan Port-Forward

Mari kita akses pod ArgoCD yang telah diinstal menggunakan Port-forward. Untuk mengakses pod yang berjalan di dalam kluster dari luar kluster, kita umumnya menggunakan sumber daya Ingress Kubernetes. Penjelasan lebih lanjut mengenai hal ini akan disampaikan di Bab 5. Saat ini, kita akan menggunakan Port-forward agar administrator dapat dengan mudah mengakses pod tanpa melakukan pengaturan Ingress tambahan. Dalam praktiknya, pod yang tidak dikonfigurasi dengan Ingress karena alasan keamanan juga diakses menggunakan Port-forward.

Port-forward menggunakan perintah kubectl port-forward. Meskipun perintah port-forward agak panjang, perintah ini mendukung penyelesaian otomatis, sehingga tidak terlalu sulit untuk digunakan. Perintah port-forward memberikan kemampuan untuk meneruskan (port-forward) lalu lintas dari pod tertentu dalam kluster ke port tertentu di sistem lokal Anda. Dengan cara ini, Anda dapat mengakses sumber daya internal kluster secara langsung dari lingkungan pengembangan lokal. Karena port API server telah terhubung untuk menjalankan perintah kubectl, Anda hanya perlu melakukan pengaturan sederhana untuk terhubung ke port internal kluster.

Lalu lintas yang masuk ke port tertentu di sistem lokal akan diteruskan melalui API server ke port tertentu dari pod yang dipilih.

API server Kubernetes bertindak sebagai perantara dalam proses ini, sementara kubelet bertanggung jawab atas pengiriman lalu lintas yang sebenarnya. Sekarang, mari kita gunakan perintah di bawah ini untuk mengakses pod ArgoCD.

 

Kubernetes mengontrol lalu lintas pod melalui objek service. Menggunakan port-forward dengan service juga lebih nyaman. Penjelasan lebih rinci tentang service akan dibahas di bab berikutnya.

Port 8080 di depan perintah 8080:80 mengacu pada port di localhost, sedangkan port 80 di belakangnya mengacu pada port yang digunakan oleh service di kluster. Dengan kata lain, perintah ini berarti menghubungkan port 8080 di localhost saya ke port 80 di service kluster. Sekarang, jika Anda memasukkan localhost:8080 di browser seperti di bawah ini, Anda akan dapat melihat tampilan ArgoCD.

Kata sandi pengguna 'admin' awal dapat dilihat melalui Secret. Secret adalah objek Kubernetes yang digunakan untuk menyimpan informasi sensitif, seperti kata sandi. Penjelasan lebih lanjut akan dibahas di bagian berikutnya, tetapi saat ini, kita akan mendekode Secret di bawah ini untuk melihat kata sandi dalam bentuk teks biasa.

Masukkan Username sebagai admin dan masukkan hasil output dari perintah di atas ke dalam Password di jendela login. Setelah login, pilih menu ‘Settings’ di sebelah kiri layar, lalu pilih ‘Repositories’, dan Anda akan melihat bahwa repositori GitHub yang telah Anda daftarkan di file Helm Values terdaftar dengan normal.

ArgoCD telah berhasil diinstal dengan normal.

4. Mendeploy NGINX dengan Argo-CD

Sekarang, kita akan mendeploy aplikasi menggunakan ArgoCD yang telah diinstal. Aplikasi yang akan kita deploy adalah Nginx, yang sering digunakan sebagai server web.

Nginx juga akan dideploy menggunakan Helm Chart.

Proses instalasi Helm ini sama seperti sebelumnya. Anda dapat menggunakan versi terbaru dari Nginx web server, tetapi jika Anda ingin konfigurasi yang sama seperti penulis, silakan tentukan versi (15.1.0).

Berikut adalah modifikasi sederhana dari file Helm Values.yaml. File tersebut dapat Anda temukan di GitHub penulis.

Ini adalah perubahan sederhana, seperti mengubah jumlah pod Nginx web server dari pengaturan default menjadi 2. Berdasarkan file Helm Values tersebut, kita akan mendeploy web server Nginx. ArgoCD memungkinkan Anda untuk melakukan pekerjaan ini melalui GUI web untuk mendeploy aplikasi ke lingkungan Kubernetes. Namun, untuk memudahkan penggunaan kembali dan agar sesuai dengan filosofi GitOps, disarankan untuk juga melakukan pengaturan mendeploy aplikasi dalam bentuk kode.

ArgoCD menggunakan Custom Resource Definition (CRD) yang disebut ‘Application’ agar dapat mendeploy melalui kode. CRD adalah fitur yang memungkinkan pengguna untuk mendefinisikan sumber daya khusus di Kubernetes. Secara default, Kubernetes menyediakan sumber daya inti seperti pod, service, dan deployment, tetapi pengguna juga dapat mendefinisikan dan menggunakan jenis sumber daya mereka sendiri.

Dengan menggunakan CRD, pengguna dapat mendefinisikan jenis sumber daya mereka sendiri dan menggunakannya di kluster seolah-olah itu adalah sumber daya bawaan. ArgoCD juga menyediakan sumber daya khusus yang disebut ‘Application’ untuk memudahkan mendeploy aplikasi.

Mari kita buat ArgoCD Application untuk mendeploy Nginx web server. (Lihat di GitHub penulis)

.metadata.finalizers

Opsi ini memungkinkan penghapusan sumber daya ‘Application’ untuk secara bersamaan menghapus sumber daya Kubernetes terkait (seperti pod, dll).

.spec.destination.server

Di sini, Anda menentukan tujuan tempat ArgoCD akan mendeploy aplikasi. Anda dapat menentukan kluster Kubernetes jarak jauh atau Kubernetes tempat ArgoCD diinstal. Jika Anda menetapkan alamat sebagai ‘https://kubernetes.default.svc’, maka itu akan merujuk pada Kubernetes tempat ArgoCD diinstal.

.spec.source.helm

ArgoCD mendukung berbagai bentuk instalasi aplikasi, seperti Helm dan manifest. Dalam praktik ini, karena kita akan menginstal Nginx menggunakan Helm, kita menetapkannya sebagai ‘helm’.

.spec.source.path, repoURL

Menentukan URL repositori GitHub tempat Helm Chart berada dan jalur Helm Chart tersebut.

.spec.syncPolicy.automated.prune/selfHeal

Opsi ini menentukan apakah ArgoCD akan secara otomatis mendeploy aplikasi. Jika Anda ingin Kubernetes secara otomatis mendeploy Helm saat kode sumber diunggah ke Git, Anda dapat menetapkan opsi ‘automated’.

Di lingkungan nyata, di lingkungan Dev dan Stage, opsi ‘automated’ sering digunakan, tetapi di lingkungan produksi, banyak yang tidak menggunakan opsi ‘automated’ untuk memeriksa riwayat perubahan (‘Diff’) secara manual sebelum mendeploy.

Prune adalah opsi yang menghapus sumber daya yang sudah tidak ada di Git, sedangkan opsi selfHeal secara otomatis memulihkan tugas yang gagal.

.spec.syncOptions.CreateNamespace

Opsi ini digunakan untuk secara otomatis membuat namespace.

Karena Application CRD juga merupakan sumber daya Kubernetes, Anda dapat membuat sumber daya tersebut menggunakan perintah ‘kubectl apply’.

Sebuah objek Kubernetes terpisah yang disebut ‘Application’ telah dibuat di ArgoCD. Application di ArgoCD bukanlah aplikasi program pada umumnya, melainkan salah satu jenis objek Kubernetes yang dibuat oleh ArgoCD itu sendiri.

Jika Anda memeriksa menu di sebelah kiri layar di web ArgoCD, Anda akan melihat bahwa argocd/nginx yang baru telah dibuat.

Dengan mengklik menu tersebut, Anda dapat memeriksa sumber daya Kubernetes yang diinstal menggunakan Helm Chart NGINX. Service dan Deployment telah diinstal.

Anda dapat memeriksa pod web server Nginx yang telah diinstal menggunakan perintah.

Dengan demikian, Anda dapat mendistribusikan pod aplikasi menggunakan ArgoCD.

Pada saat pertama kali melakukan distribusi ArgoCD, aplikasi diinstal menggunakan perintah ‘helm install’ di PC lokal. Setelah itu, NGINX tidak diinstal menggunakan perintah ‘helm install’, melainkan didistribusikan menggunakan ArgoCD.

Aplikasi yang diinstal menggunakan perintah di PC lokal tidak dapat disimpan di Git, sehingga sulit untuk dikelola di masa mendatang. Namun, dengan menggunakan ArgoCD, Anda dapat memaksa penyimpanan dan distribusi sumber kode di Git, sehingga lebih mudah untuk menerapkan kebijakan GitOps. Disarankan agar semua aplikasi yang diinstal di Kubernetes didistribusikan menggunakan ArgoCD.

ArgoCD mendukung antarmuka pengguna (UI) yang memudahkan Anda untuk memeriksa sumber daya apa yang telah diinstal menggunakan Helm.

5. Praktik GitOps

Mari kita lihat bagaimana ArgoCD mengimplementasikan GitOps dengan membuat status yang sedang berjalan (Ops) berbeda dari status di Git.

Alih-alih menggunakan kode sumber, kita akan mengubah jumlah pod NGINX dari 2 menjadi 5 menggunakan perintah. Bagi konsol lokal menjadi dua jendela; di bagian atas, kita akan mengubah jumlah pod, dan di bagian bawah, kita akan memantau perubahan secara real-time.

Jendela di bawah akan memantau perubahan pod secara real-time menggunakan perintah ‘k get pod -w (watch)’.

Di jendela atas, kita akan mengubah jumlah pod. Perubahan jumlah pod dilakukan dengan menggunakan perintah scale.

Meskipun kita telah menetapkan jumlah pod menjadi 5 dengan perintah, pod tersebut tidak bertambah. Statusnya menunjukkan 'ContainerCreating' dan pada saat yang sama juga 'Terminating'.

Jumlah pod masih tetap 2. Mengapa hal ini bisa terjadi?

Karena jumlah pod tidak diubah di sumber Git, ArgoCD secara otomatis mempertahankan jumlah pod tetap 2 untuk mencocokkan keadaan kluster saat ini dengan keadaan sumber yang disinkronkan di Git.

Sekarang, untuk memeriksa perbedaan, saya akan menghapus opsi 'automated' di ArgoCD. Opsi 'automated' adalah opsi yang secara otomatis mencocokkan keadaan saat ini dengan keadaan di Git. Dengan menghapus opsi tersebut, ArgoCD tidak akan secara otomatis memperbaiki keadaan saat ini.

Setelah itu, jalankan kembali perintah 'k scale deployment nginx --replicas 5' dan periksa di web ArgoCD; statusnya akan menunjukkan 'OutOfSync'. Seperti yang terlihat dari pesan tersebut, dapat dipastikan bahwa keadaan sumber yang disimpan di Git tidak sinkron dengan keadaan kluster yang sedang berjalan saat ini.

Dengan memeriksa menu 'APP DIFF', Anda dapat melihat pesan yang lebih rinci.

Anda dapat melihat bahwa angka replika pod, yaitu 5 dan 2, saling berbeda.

Dalam lingkungan operasi praktis, sering kali opsi 'automated' dinonaktifkan seperti di atas. Pengguna selalu memeriksa 'Diff' secara manual untuk memastikan adanya masalah dan mengikuti proses penerapan ke cluster yang sebenarnya.

Dengan demikian, jika pengguna mengubah jumlah pod secara manual menggunakan perintah, tetapi opsi 'Automated' diaktifkan, ArgoCD akan secara otomatis menyinkronkan status saat ini dengan sumber Git, sehingga jumlah pod tetap 2.

Sekarang, mari kita ubah jumlah pod dari 2 menjadi 1 di sumber Git. Kita akan mengubah opsi 'replicaCount' dalam file nilai Helm NGINX.

Setelah melakukan commit Git, lakukan push untuk menggabungkan ke main Git. Berikut adalah contoh tampilan layar Git Commit di VSCode yang saya gunakan.

Dengan mengklik ‘REFRESH’ di menu ArgoCD, jumlah pod otomatis berkurang menjadi 1.

Dengan perintah kubectl, jumlah pod juga berkurang menjadi 1.

Dengan cara ini, ArgoCD menyinkronkan status yang tercermin dalam sumber Git dengan status Kubernetes yang sebenarnya. Semua perubahan dilakukan tidak melalui perintah atau sumber lokal secara sembarangan, tetapi hanya dilakukan di repositori Git terpusat.

Demikian pula, pekerjaan infrastruktur yang menggunakan Terraform juga diterapkan ke status aktual setelah melalui tinjauan PR Git.

Screenshot di atas adalah pesan tinjauan PR yang saya gunakan saat melakukan upgrade EKS. Ini adalah contoh di mana saya telah meminta rekan untuk memverifikasi pekerjaan kode Terraform untuk upgrade EKS melalui tinjauan. Dengan memverifikasi kode yang terkait dengan pekerjaan sebelumnya, saya dapat mengurangi kemungkinan terjadinya masalah selama proses. Kode yang sudah diverifikasi kemudian digabungkan ke dalam branch utama untuk diterapkan ke status yang sebenarnya.

Selain kode Terraform, kode Python untuk pekerjaan lainnya juga disimpan di Git dan diperiksa melalui proses tinjauan.

Contoh di atas adalah kode Python yang mencetak daftar seluruh AWS MSK Cluster berdasarkan setiap region.

Tentu saja, dalam operasional nyata, sulit untuk mendapatkan tinjauan kode untuk setiap pekerjaan karena keterbatasan waktu. Namun, sangat efektif untuk mengadopsi proses di mana semua pekerjaan dilakukan dengan menulis kode terlebih dahulu dan membuat dokumentasi berdasarkan kode tersebut untuk mendapatkan tinjauan dari rekan kerja. Selain itu, setidaknya semua catatan pekerjaan harus disimpan dalam bentuk kode, karena ini akan sangat membantu saat melakukan pekerjaan yang sama di masa mendatang.

Sampai saat ini, saya telah berbagi contoh GitOps dengan ArgoCD. GitOps adalah kebijakan, jadi niat untuk mematuhi kebijakan tersebut sangat penting. Penting untuk melakukan tinjauan kode dengan cermat dan menjaga prosedur kerja, meskipun terasa merepotkan, setiap usaha sehari-hari diperlukan untuk menjaga stabilitas sistem.

1. Keuntungan Menggunakan Kode untuk Instalasi Kubernetes

Bayangkan pembaca artikel ini menjadi penanggung jawab Kubernetes dan diberi tugas untuk melakukan cara instalasi EKS dengan Terraform. Bagaimana cara terbaik untuk melakukannya? Mari kita pikirkan bagaimana proses instalasi telah dilakukan hingga saat ini dan apa pendekatan terbaik yang bisa diterapkan ke depannya.

EKS dapat diinstal melalui konsol Amazon menggunakan antarmuka GUI (Graphical User Interface) atau dengan perintah eksctl. Pendekatan ini cukup nyaman karena memungkinkan instalasi dilakukan dengan relatif mudah. Namun, metode ini memiliki kelemahan dari sisi penggunaan ulang (reusability). Setiap kali instalasi dilakukan, Anda harus melalui proses yang sama, yang berisiko menimbulkan kesalahan. Selain itu, jika Anda perlu membuat EKS untuk berbagai lingkungan, seperti lingkungan pengembangan, produksi, atau tujuan layanan lainnya, Anda harus mengulangi serangkaian langkah GUI dan perintah tersebut setiap kali. Jika instalasi awal memakan waktu 10 menit, proses berikutnya juga akan memakan waktu yang sama. Lebih jauh lagi, sulit untuk melakukan tinjauan bersama dengan rekan kerja karena semua perintah yang diperlukan untuk pekerjaan tersebut tidak dapat disiapkan sebelumnya.

Seperti yang telah dijelaskan sebelumnya, mengelola Kubernetes dengan kode memiliki banyak keuntungan. Hal yang sama berlaku untuk EKS; jika infrastruktur dikelola dengan kode, terdapat sejumlah manfaat signifikan.

Banyak dari Anda mungkin sudah tahu bahwa saat ini praktik Infrastructure as Code (IaC), seperti menggunakan Terraform, sudah umum digunakan untuk mengelola infrastruktur melalui kode. Terraform sering digunakan di lingkungan public cloud. Sebagai alat otomatisasi infrastruktur, Terraform memungkinkan Anda untuk menyediakan dan mengelola infrastruktur di lingkungan cloud maupun on-premises menggunakan kode. Dengan Terraform, Anda dapat mendefinisikan infrastruktur dalam bentuk kode, yang memudahkan untuk mengotomatisasi tugas berulang, melacak perubahan, dan menjaga konsistensi dalam lingkungan infrastruktur. Terraform menggunakan bahasa deklaratif untuk mendefinisikan sumber daya, memungkinkan Anda mengonfigurasi infrastruktur sesuai dengan kondisi yang diinginkan.

EKS juga dapat diinstal menggunakan Terraform, dan pendekatan ini memiliki beberapa kelebihan sebagai berikut.

1. Pengelolaan Infrastruktur Menggunakan Kode
   Dengan menggunakan kode, Anda dapat meninjau kode sebelumnya untuk menemukan masalah, sehingga sangat mendukung kolaborasi. Selain itu, perubahan dapat dengan mudah dilacak dengan pengelolaan versi menggunakan platform seperti GitHub.
   
2. Kemudahan Penggunaan Kembali dan Pemeliharaan
   Di dunia kerja, kami menggunakan beberapa kluster untuk pengembangan, staging, dan produksi. Ketika membuat kluster yang sama, kami dapat menggunakan kode yang ada tanpa perubahan, sehingga meningkatkan produktivitas.
   

Ada berbagai Cara Instalasi EKS dengan Terraform. Terraform mendukung modul EKS, yang memungkinkan Anda menginstal berbagai sumber daya terkait seperti VPC, Security Group, dan Subnet dengan nyaman sekaligus tanpa menduplikasi kode. Modul Terraform mengabstraksi dan mengenkapsulasi fungsi atau sumber daya tertentu, sehingga menyederhanakan dan memodulasi konfigurasi infrastruktur yang kompleks. Ini membantu meningkatkan kemampuan penggunaan kembali dan pemeliharaan kode.

Dengan menggunakan modul Terraform, Anda dapat mengenkapsulasi skenario atau pola umum, sehingga mudah untuk mengulang konfigurasi yang sama di berbagai proyek atau lingkungan. Saya juga menggunakan modul Terraform untuk menginstal EKS dengan mudah.

2. Instalasi EKS dengan Terraform

Mari kita lihat Cara Instalasi EKS dengan Terraform yang digunakan di lingkungan kerja nyata. Kode tersebut dapat ditemukan di GitHub saya. Jika Anda melihat kode Terraform EKS tanpa pemahaman yang cukup tentang EKS, banyak hal mungkin terasa asing dan sulit dipahami. Pada awalnya, tidak masalah jika Anda hanya mengenali istilah-istilahnya. Seiring waktu dan penggunaan, Anda akan mulai memahami berbagai konsep yang sebelumnya sulit. Saya ingin menekankan bahwa mencoba untuk belajar secara sempurna di awal akan memakan waktu yang terlalu lama. Saya percaya bahwa lebih efektif untuk menyelesaikan praktik secara keseluruhan terlebih dahulu, dan kemudian mengulang bagian-bagian yang sulit atau diperlukan masing-masing. Cara Instalasi EKS dengan Terraform

BACA JUGA : Catatan Teknis Jennifer Panduan Praktis Menguasai Kubernetes

Unduh kode saya ke lokal menggunakan 'git clone'.

Jika Anda memeriksa direktori 'terraform-eks' di bawah ini, Anda akan menemukan kode Terraform yang terkait dengan instalasi EKS.


Pertama, ini adalah pengaturan terkait variabel locals. Variabel locals didefinisikan dalam Terraform menggunakan blok locals untuk membuat variabel lokal. Dengan mendefinisikan variabel menggunakan blok locals, variabel ini hanya dapat digunakan di dalam modul atau file pengaturan tersebut dan tidak dapat diakses dari luar. Variabel ini umumnya digunakan untuk menyimpan nilai yang berulang atau ekspresi yang kompleks, sehingga membuat kode lebih mudah dikelola. Cara Instalasi EKS dengan Terraform

Anda dapat menyimpan file variabel locals secara sembarangan, tetapi saya telah mendaftarkan blok locals di file main.tf.

. name

Ini adalah nama EKS. Setelah dibuat, nama kluster tidak dapat diubah, sehingga penting untuk memutuskan nama kluster dengan hati-hati sejak awal. Jika perusahaan sudah memiliki Konvensi Penamaan yang ditentukan, ikutilah. Jika tidak ada, buatlah aturan yang dapat diterapkan secara konsisten dengan mempertimbangkan penyampaian makna yang jelas dan kemungkinan perluasan di masa mendatang. Menetapkan nama seperti test-01 tanpa aturan akan sangat merepotkan. Tentukan nama yang dapat menjelaskan dirinya sendiri (Self Explaining). Perusahaan saya biasanya menggunakan format {Nama Produk} – {Wilayah} – {Lingkungan (test/stage/prod)}. Ini mudah untuk ditentukan, jadi saya sangat menyarankan untuk menetapkannya sebelumnya. Cara Instalasi EKS dengan Terraform

. region

Secara umum, saya menggunakan ap-northeast-2, yaitu Seoul, tetapi karena ada EKS lain yang sudah diinstal di wilayah tersebut, saya memilih wilayah ap-southeast-1, yaitu Singapura, untuk membedakannya. Tentu saja, Anda juga bisa membedakan dengan menggunakan VPC di wilayah yang sama, tetapi demi kenyamanan, saya memisahkan hingga ke tingkat wilayah. Jika tidak ada alasan khusus seperti yang saya miliki, disarankan untuk memilih ap-northeast-2.

. vpc_cidr

Ini adalah pengaturan yang penting. CIDR (Classless Inter-Domain Routing) adalah sistem alamat jaringan yang digunakan untuk mengelola dan membagi ruang alamat IP secara efisien. Ini adalah konsep yang melengkapi dan mengembangkan sistem alamat berbasis kelas (Classful Network), yang memungkinkan penugasan alamat IP yang lebih fleksibel. Pilihlah rentang IP yang unik dan tidak tumpang tindih dengan rentang IP dari VPC lain yang sudah digunakan. Jika Anda menggunakan infrastruktur lokal (on-premises) bersama dengan AWS Cloud, sebaiknya gunakan rentang IP yang berbeda dari rentang IP lokal untuk memudahkan pengaturan Peering di masa depan.

Rentang IP juga sebaiknya memiliki aturan yang jelas. Misalnya, untuk lingkungan produksi, Anda dapat membaginya menjadi 10.1.0.0/16, 10.2.0.0/16, dan untuk staging menjadi 10.11.0.0/16, 10.12.0.0/16, serta membagi berdasarkan wilayah: Seoul dengan rentang 10.0.0.0/16 hingga 10.50.0.0/16 dan Tokyo dengan rentang 10.51.0.0/16 hingga 10.100.0.0/16. (Atau bisa juga menggunakan 172.16.0.0/16, 192.168.0.0/16, dll.) Banyak kasus di mana rentang yang sama digunakan di VPC yang berbeda karena tidak ada aturan yang ditetapkan di awal.Cara Instalasi EKS dengan Terraform

. azs

Pertimbangkan ketersediaan dengan membagi dan mengalokasikan ke dalam 3 AZ (Availability Zone). Atau, untuk kluster pengujian, Anda dapat menggunakan satu AZ untuk mengurangi biaya. Dalam lingkungan operasional yang sebenarnya, sering terjadi lalu lintas antar node dalam kluster, yang dapat menyebabkan biaya Transfer Data lebih tinggi dari yang diperkirakan.

Selanjutnya adalah pengaturan modul EKS.

. cluster_endpoint_public_access

Karena ini adalah lingkungan kluster pengujian, akses publik ke layanan API EKS diizinkan. Namun, dalam lingkungan operasional yang sebenarnya, disarankan untuk membatasi akses dari luar demi keamanan.

Dengan pengaturan di atas, akses hanya dapat dilakukan dari dalam VPC yang sama dengan EKS. Melalui server API EKS, semua operasi Kubernetes dapat dilakukan, seperti menghapus pod dan node atau bahkan menghapus seluruh kluster, sehingga perlu dilakukan dengan hati-hati. Saya menggunakan VPN untuk mengakses menggunakan rentang IP internal. Jika tidak menggunakan VPN, Anda juga bisa membatasi rentang IP publik yang dapat mengakses API.

. cluster_addons

EKS Addon adalah fitur yang menyediakan kemampuan untuk dengan mudah mengaktifkan dan mengelola fungsi atau layanan tertentu dalam kluster Amazon EKS. Fitur ini memudahkan pengelolaan elemen-elemen penting dalam konfigurasi EKS, seperti jaringan dan DNS. Dengan mengelola Coredns, Kube-proxy, Vpc-cni sebagai add-on sebelumnya, Anda dapat dengan nyaman melakukan upgrade EKS di masa mendatang hanya dengan menyebutkan informasi versi baru.

. vpc_id

Disarankan untuk menggunakan VPC terpisah untuk tujuan EKS agar dapat dibedakan dari VPC yang ada. EKS secara default menggunakan VPC_CNI (Container Network Interface) untuk mengelola jaringan Kubernetes. VPC_CNI menggunakan rentang IP yang sama untuk pod dan node, sehingga membutuhkan banyak alamat IP. Adalah hal yang umum jika jumlah pod melebihi 1.000, yang dapat menyebabkan kekurangan IP. Oleh karena itu, disarankan untuk menggunakan VPC terpisah.

. subnet_ids

Tentukan rentang Subnet di mana pod EKS akan dialokasikan. Kecuali dalam lingkungan khusus di mana pod harus berkomunikasi dengan alamat IP publik, sebaiknya untuk alasan keamanan, rentang Subnet ditetapkan sebagai rentang IP privat.

. control_plane_subnet_ids

Ini adalah rentang subnet di mana pod Control Plane dialokasikan. Control Plane adalah komponen inti dari kluster Kubernetes, yang berfungsi untuk mengelola dan mengontrol semua operasi di dalam kluster. Penjelasan lebih detail akan disertakan dalam praktik yang akan datang, dan saat ini cukup jika Anda hanya mengenal istilah tersebut. Rentang jaringan untuk Control Plane ditetapkan sebagai rentang Intra yang lebih aman, bukan publik atau privat. Control Plane tidak memiliki akses eksternal melalui internet gateway atau NAT gateway, dan merupakan sumber daya yang digunakan hanya di dalam VPC.

Selanjutnya adalah pengaturan nodegroup. Kubernetes memerlukan instansi VM untuk menjalankan aplikasi kontainer secara nyata. EKS dapat mengelola dan memperluas ini secara efisien menggunakan nodegroup. Belakangan ini, banyak yang mengelola node EC2 EKS menggunakan Karpenter daripada menggunakan node group yang ada. Karpenter mengelola ukuran sumber daya antara node dan pod untuk mengoptimalkan efisiensi sumber daya dalam kluster. Ini sangat membantu dalam meningkatkan kinerja dan ketersediaan kluster dengan mengotomatiskan penyesuaian ukuran sumber daya. Penjelasan lebih lanjut akan dibahas di ‘Bab 8. Autoscaling Node – Karpenter’.

Node yang dijalankan oleh Karpenter tidak dapat ditentukan oleh Karpenter itu sendiri, sehingga node group yang dijalankan oleh Karpenter didefinisikan seperti di bawah ini.(eks-cluster.tf)

. eks_managed_node_group_defaults

Tentukan pengaturan dasar untuk node group. Pengaturan grup keamanan (security group) dan peran IAM (iam_role) mengikuti pengaturan dasar Terraform. Sementara itu, pengaturan kapasitas disk diubah menjadi 100Gi berbasis gp3 dengan lebih banyak ruang untuk mengantisipasi kemungkinan kegagalan, berbeda dari pengaturan dasar.

. eks_managed_node_groups.capacity_type, instance_types

Dalam kasus saya, lingkungan operasional ditetapkan menggunakan tipe instansi On-demand, sementara lingkungan Dev/Stage menggunakan Spot Instance untuk mengurangi biaya secara signifikan (sekitar 30% lebih murah dibandingkan On-demand). Untuk EKS pengujian, saya menetapkannya sebagai Spot Instance.

Sebagai catatan, jika Anda menentukan beberapa 'instance_types' di lingkungan Spot, Anda dapat mempersiapkan kemungkinan kekurangan sumber daya yang ditetapkan sebagai Spot. Bergantung pada situasinya, Anda dapat menentukan beberapa tipe, seperti [“t3.small”, “t3.large”, “m6i.large”].

Terakhir adalah pengaturan VPC. (vpc.tf)

. module “vpc”.source

Terraform, seperti EKS, juga menyediakan modul VPC terpisah.

. private_subnets, [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]

Tambahkan 4 ke CIDR sebelumnya vpc_cidr = “10.110.0.0/16” untuk mendapatkan CIDR /20, yang akan dialokasikan ke 3 AZ (Availability Zone), yaitu jika di Seoul, maka ap-northeast-2a, ap-northeast-2b, dan ap-northeast-2c.

. public_subnets  = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]
  intra_subnets   = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 52)]

Dengan menambahkan /16 + 8, kita akan mengalokasikan CIDR /24 ke 3 AZ. IP yang dialokasikan berada setelah rentang jaringan privat sebelumnya.

Jika Anda memeriksa rentang IP yang diterapkan di konsol AWS, akan terlihat seperti di bawah ini.

Tiga CIDR /20 bit dan enam CIDR /24 bit akan dialokasikan.

Setelah pengaturan selesai, Anda dapat menginstal EKS menggunakan Terraform. Pindah ke direktori tempat kode Terraform yang telah diunduh sebelumnya dengan 'git clone' disimpan.

Instal EKS menggunakan perintah Terraform.

Setelah sekitar 20 menit, instalasi akan selesai dengan normal. Setelah selesai, Anda dapat memeriksa di konsol AWS EKS seperti di bawah ini. Cari menu EKS di menu layanan AWS dengan mengetik 'eks'.

 

Tampilan konsol AWS EKS.

Jika Anda dapat memeriksa informasi EKS di layar konsol seperti di atas, itu berarti EKS telah terinstal dengan normal.

3. Pengaturan lingkungan operasi Kubectl lokal – Konfigurasi file lingkungan Kubernetes (~/.kube/config) dan pemanfaatan plugin Krew.

Untuk mengelola Kubernetes, diperlukan alat perintah 'kubectl'. Kubectl adalah antarmuka baris perintah (CLI) yang digunakan untuk berinteraksi dengan kluster Kubernetes. Ini adalah alat penting bagi pengguna untuk mengelola dan memantau sumber daya kluster. Di lingkungan Mac, Anda dapat menginstalnya dengan mudah menggunakan Homebrew.

Sebagai catatan, Homebrew juga dapat digunakan di lingkungan Ubuntu. Saya menggunakan WSL Ubuntu dan telah menginstal Homebrew untuk digunakan.(Rujuk ke metode instalasi) Anda dapat menginstal 'kubectl' dengan perintah yang sama seperti di atas.

Tentu saja, Anda juga dapat menggunakan manajer paket apt. Anda dapat menemukan metode instalasi yang lebih rinci di situs resmi Kubernetes.

Setelah instalasi, selesaikan pengaturan penyelesaian otomatis dan alias sesuai panduan di situs resmi Kubernetes.

Selain itu, jika Anda mendaftarkan alias di bawah ini, Anda dapat menjalankan perintah kubectl dengan lebih cepat.

Instalasi alat kubectl telah selesai. Selanjutnya, untuk mengelola kluster EKS jarak jauh dari lokal, perlu memodifikasi file konfigurasi Kubernetes di PC pribadi (/.kube/config). File ‘/.kube/config’ di Kubernetes berisi informasi alamat kluster Kubernetes jarak jauh, kredensial pengguna, dan lain-lain. Format file konfigurasi adalah YAML, dan Anda dapat mengeditnya secara langsung atau menggunakan perintah ‘kubectl config’.

Berikut adalah file konfigurasi Kubernetes yang terdaftar di PC saya. Jika Anda mengatur dengan cara yang sama, informasi yang diperlukan untuk mengakses Kubernetes jarak jauh akan terdaftar.

 Struktur Kubernetes Config terdiri dari tiga bagian utama seperti di bawah ini.

• Cluster (Klaster): Berisi alamat server klaster dan informasi autentikasi TLS dasar. Informasi ini sangat penting untuk menghubungkan ke klaster.
• Contexts (Konteks): Memuat informasi tentang klaster, pengguna, dan namespace. Konteks memungkinkan perpindahan cepat antara beberapa klaster dan pengguna.
• Users (Pengguna): Berisi informasi autentikasi klien untuk berkomunikasi dengan klaster. Ini mencakup token autentikasi, sertifikat klien, nama pengguna, dan kata sandi. Perlu dicatat bahwa EKS dan Kubernetes on-premise menggunakan metode autentikasi yang berbeda.

Selanjutnya, file ~/.kube/config pada bagian 'Clusters' dan 'Users' akan disesuaikan untuk memungkinkan pengelolaan klaster Kubernetes jarak jauh dari PC pribadi Anda. Informasi tambahan tentang file konfigurasi Kubernetes untuk EKS dapat ditemukan di dokumentasi resmi AWS.

Langkah pertama adalah memeriksa informasi alamat server dan sertifikat autentikasi pada bagian 'clusters'. Informasi ini dapat dilihat di menu 'Overview' (Ikhtisar) pada konsol manajemen AWS EKS.

Salin informasi tersebut, dan berdasarkan tangkapan layar yang diberikan, daftarkan ke dalam file konfigurasi lokal ~/.kube/config. Masukkan 'API Server Endpoint' ke dalam bagian 'server' dan masukkan informasi sertifikat otoritas, yaitu 'Certificate Authority', ke dalam 'certificate-authority-data'.

Tentukan nama untuk cluster, context, dan user. Nama-nama ini dapat ditentukan secara bebas, jadi pilih nama yang sesuai untuk Anda. Dalam kasus ini, saya menggunakan nama yang sama untuk ketiganya, yaitu switch-singapore-test.

Langkah terakhir adalah mengisi bagian 'user'. Pada bagian '--cluster-name', masukkan nama klaster yang digunakan saat instalasi (contoh: singapore-test). Kemudian, untuk env:name dan env:value, masukkan informasi kredensial AWS Anda. Informasi kredensial AWS dapat ditemukan dalam file ~/.aws/credentials. Gunakan informasi kredensial yang sama dengan yang digunakan saat menginstal EKS.

• Pada env:name, masukkan AWS_PROFILE.
• Pada env:value, masukkan nama profil dari file kredensial AWS Anda.

Setelah semua konfigurasi selesai, Anda kini dapat menjalankan perintah kubectl dari lingkungan lokal Anda untuk mengelola klaster Kubernetes.

Jika perintah di atas berhasil dijalankan, maka semua persiapan untuk mengelola kluster jarak jauh dari lingkungan lokal Anda telah selesai. Anda dapat mencoba membuat pod uji, dan pod tersebut akan berjalan dengan normal.

Selain itu, jika Anda memeriksa di AWS Console, Anda akan melihat bahwa VPC, Subnet, NAT Gateway, dan lainnya telah secara otomatis disertakan. Terraform dengan praktis menginstal semua sumber daya yang diperlukan untuk pengaturan EKS dalam satu modul.

Demikianlah cara memasang EKS menggunakan Terraform.

Dengan menggunakan Terraform, Anda tidak hanya dapat menginstal EKS, tetapi juga berbagai sumber daya yang diperlukan untuk menjalankan EKS dengan mudah. Terraform dirancang dengan abstraksi yang baik sehingga Anda tidak perlu memahami secara mendalam semua pengaturan detail dari berbagai sumber daya untuk dapat melakukan instalasi dan pengoperasian dengan lancar. Anda cukup menyesuaikan dan mengoptimalkan konfigurasi sesuai dengan kebutuhan masing-masing perusahaan.