Auto stacktrace adalah fitur yang memungkinkan Anda menangkap dan menganalisis stack trace dari aplikasi Anda secara otomatis. Stack trace adalah urutan panggilan fungsi atau metode rekaman yang terjadi dalam aplikasi saat terjadi kesalahan atau menyenangkan. Dengan mengetahui stack trace, Anda dapat melacak akar penyebab masalah kinerja atau kesalahan dengan lebih mudah dan cepat. Auto stacktrace bekerja dengan cara menyisipkan agen ke dalam aplikasi Anda yang akan mengumpulkan dan mengirimkan stack trace ke server APM. Server APM kemudian akan menganalisis stack trace dan menampilkan informasi yang relevan di dashboard APM. Anda dapat melihat stack trace dari berbagai sudut pandang, seperti waktu, lokasi, pengguna, atau perangkat.Anda juga dapat memfilter, mencari, atau membandingkan stack trace untuk mendapatkan wawasan yang lebih mendalam.
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
Apakah Anda pernah mengalami masalah kinerja aplikasi yang sulit disembuhkan? Apakah Anda ingin mengetahui apa yang menyebabkan aplikasi Anda berjalan lambat, macet, atau mengalami kesalahan? Jika iya, maka Anda membutuhkan application performance monitoring (APM). APM adalah proses mengelola kinerja seluruh perangkat lunak untuk memantau ketersediaan, waktu transaksi, dan masalah kinerja yang berpotensi memengaruhi pengalaman pengguna. Salah satu fitur canggih dari APM adalah auto stacktrace, yang dapat membantu Anda menangkap dan menganalisis stack trace dari aplikasi Anda secara otomatis. Dalam artikel ini, kami akan menjelaskan apa itu auto stacktrace, bagaimana cara kerjanya, dan apa gunanya bagi Anda.
Tools APM (Application Performance Monitoring) memberikan informasi tentang kinerja dari sisi server situs web atau aplikasi Anda. Dengan meningkatkan waktu kerja dan pengalaman pengguna, serta mengurangi risiko dan penurunan, APM Tools memberikan manfaat yang lebih besar bagi bisnis Anda untuk bersaing lebih cepat dan memberikan nilai lebih kepada pengguna.
Tidak heran bahwa, menurut analisis oleh Emergen Research, pasar global untuk Aplikasi Performance Monitoring APM Tools diperkirakan akan mencapai $15 miliar pada tahun 2028, meningkat dari $6,54 miliar pada tahun 2020.
Dengan begitu banyak APM Tools yang tersedia di pasaran, memilih solusi yang tepat bisa menjadi sulit. Setiap perusahaan berbeda, sehingga perangkat lunak APM yang berfungsi untuk sebuah perusahaan mungkin tidak memenuhi kebutuhan orang lain. Karena kinerja aplikasi dipantau di server, Anda juga harus memilih platform yang mendukung bahasa pemrograman yang digunakan.
Namun, dengan mencari Tools APM yang tepat dan bermanfaat, Anda dapat meningkatkan efektivitas perusahaan Anda sambil memastikan bahwa aplikasi dan layanan yang Anda berikan memenuhi harapan pelanggan.
Dengan mempertimbangkan hal tersebut, mari kita lihat keunggulan dari APM Jennifer.
Application Performance Monitoring (APM) dari Jennifer.soft menawarkan solusi komprehensif yang memungkinkan Anda mengintegrasikan kinerja server aplikasi Anda dari satu lokasi pusat.
Baca Juga : Apa Itu APM
Baca juga : Memantau Kinerja Aplikasi Anda Dengan APM Jennifer
APM Jennifer adalah solusi komprehensif yang menggabungkan Crash Reporting, Real User Monitoring, dan perangkat lunak APM dalam satu dasbor terintegrasi. Hal ini memungkinkan Anda untuk memperoleh data waktu nyata tentang pengalaman pengguna dan kinerja aplikasi Anda. Dengan menggunakan APM Jennifer, Anda dapat dengan cepat mengidentifikasi masalah dan menentukan apa yang perlu dilakukan untuk mempercepat kinerja aplikasi Anda.
Salah satu keunggulan APM Jennifer adalah kemampuannya dalam memberikan konteks dan visibilitas yang lebih besar kepada tim IT dalam menyelesaikan permasalahan aplikasi mereka. Dengan fitur Flamechart, Anda dapat melacak jejak masalah pada backend, fungsi, database, atau panggilan API Anda. Selain itu, mesin pembuat masalah memungkinkan pengembang untuk memperbaiki masalah yang paling memengaruhi pengguna.
Satu hal lagi yang membedakan APM Jennifer dari solusi APM lainnya adalah harga yang lebih terjangkau. Dibandingkan dengan beberapa APM Tools lain di pasar, APM Jennifer tersedia dengan harga yang lebih ramah. APM Jennifer juga dapat digunakan untuk lingkungan server .NET, PHP, Java, dan Python.
Dalam keseluruhan, APM Jennifer adalah solusi APM yang tepat bagi perusahaan Anda jika Anda ingin meningkatkan efektivitas aplikasi Anda dan memastikan bahwa layanan yang Anda berikan melebihi harapan pelanggan Anda.
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, menurut saya, 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 dapat 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:
- Menyediakan antarmuka pengguna (UI) yang mudah digunakan.
- Mudah diintegrasikan dengan alat lain.
- 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:
- Instalasi ArgoCD
- Mendeploy Helm Chart NGINX menggunakan ArgoCD
- 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.
- 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. - 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.
Sebagai praktisi DevOps yang berpengalaman dengan Kubernetes Native dan Managed (EKS), saya akan menjelaskan tiga ciri utama Kubernetes dan perbedaan antara Kubernetes Native dan Managed dari sudut pandang operasional.
1. Manajemen Keadaan yang Diinginkan (Desired State Management
Salah satu ciri utama Kubernetes adalah kemampuannya untuk mengelola klaster menggunakan konsep inti yang disebut "keadaan yang diinginkan" (desired state). Sesuai dengan istilahnya, keadaan yang diinginkan mengacu pada proses mendefinisikan secara eksplisit bagaimana aplikasi dan sumber daya dalam klaster harus beroperasi. Kubernetes kemudian memastikan bahwa keadaan saat ini selalu sesuai dengan keadaan yang telah ditentukan.
Konsep ini merupakan salah satu prinsip inti Kubernetes dalam mengelola dan memelihara aplikasi serta infrastruktur secara otomatis. Sebagai contoh, jika salah satu proses yang sedang berjalan tiba-tiba berhenti, Kubernetes akan secara otomatis memulai ulang proses tersebut tanpa memerlukan intervensi pengguna. Dengan demikian, Kubernetes mampu menjaga keadaan yang diinginkan tetap konsisten, memberikan kemampuan yang sangat baik dalam menangani gangguan atau kegagalan.
Saya pernah menjadi administrator Solaris pada sistem Unix. Saat terjadi gangguan, saya sering menerima telepon dari tim pemantauan, bahkan di tengah malam, untuk masuk ke konsol dan secara manual menjalankan ulang proses yang bermasalah. Namun, kini Kubernetes mengambil alih tugas tersebut. Waktu tidur saya di malam hari menjadi jauh lebih nyenyak.
Manajemen keadaan yang diinginkan adalah konsep yang sering digunakan dalam budaya DevOps dan lingkungan cloud-native. Dengan pendekatan ini, efisiensi dan keandalan dalam pengelolaan sistem dapat meningkat secara drastis, karena proses-proses yang sebelumnya membutuhkan intervensi manual kini dapat ditangani secara otomatis oleh Kubernetes.
Mari kita cari tahu dengan sebuah contoh. Jalankan 'Deployment' NGINX seperti yang ditunjukkan di bawah ini. Deployment adalah sumber daya Kubernetes untuk mengelola dan men-deploy instance aplikasi. Perintah kubectl digunakan di bawah ini. Kami akan membahas penggunaan secara detail, termasuk cara menggunakan perintah kubectl, di seri mendatang. Untuk saat ini, ada baiknya jika kita fokus pada konsep inti saja.
Perintah tersebut akan menjalankan pod NGINX. Anda dapat memeriksa status terkini pod dengan menggunakan perintah kubectl get pod
. Pod adalah unit terkecil yang digunakan dalam Kubernetes untuk proses deployment, yang dapat berisi satu atau lebih container. Pod berfungsi sebagai host logis untuk container, di mana container dalam pod yang sama akan berbagi namespace jaringan, alamat IP, rentang port, serta penyimpanan yang sama
Kita akan membuat situasi gangguan secara sengaja. Untuk memantau perubahan status secara real-time, bagi jendela terminal menjadi dua. Pada jendela atas, hapus pod, dan pada jendela bawah, pantau perubahan status pod secara real-time menggunakan opsi -w
(watch). Perintah untuk menghapus pod adalah kubectl delete pod
.
Pada jendela bawah, Anda dapat melihat bahwa pod yang dihapus secara otomatis dibuat kembali.
Pod dengan nama ‘nginx-748c667d99-d6bb5’ sedang dalam proses terminasi dan pod baru dengan nama ‘nginx-748c667d99-jmb7z’ sedang berjalan (Running). Kubernetes telah mengonfirmasi bahwa pod sebelumnya telah dihentikan dan secara otomatis menjalankan pod baru. Dengan kata lain, Kubernetes mendeteksi bahwa proses telah berhenti dan secara otomatis mengembalikan ke ‘status yang diinginkan’ semula. Sebagai catatan, nama ‘nginx-748c667d99-d6bb5’ dihasilkan oleh Kubernetes Deployment Resource yang secara otomatis menambahkan nilai hash acak ke nama deployment nginx.
BACA JUGA : Catatan Teknis Jennifer: Panduan Praktis Menguasai Kubernetes
Kita telah menjalankan pod dengan perintah kubectl create deployment
pada awalnya. Dengan demikian, Kubernetes Deployment mendefinisikan ‘status yang diinginkan’ sebagai keadaan di mana pod sedang berjalan. Oleh karena itu, meskipun kita menghapus pod secara sengaja (atau karena gangguan sistem yang tidak terduga), Kubernetes akan secara otomatis menjaga agar status yang diinginkan, yaitu satu pod yang sedang berjalan, tetap terjaga dengan memulai kembali pod. Di dalamnya, Deployment Resource menggunakan pengontrol bernama ReplicaSet Controller untuk selalu menjaga agar tetap dalam status yang diinginkan. Jika jumlah pod dideklarasikan sebanyak 3, maka akan selalu ada 3 pod yang dijaga melalui ReplicaSet Controller. Dengan cara yang serupa, Kubernetes menggunakan berbagai pengontrol untuk selalu mempertahankan status yang diinginkan. Penanggung jawab mendefinisikan terlebih dahulu ‘status yang diinginkan’, dan Kubernetes secara otomatis menjaga status tersebut dengan menggunakan berbagai sumber daya ‘pengontrol’. Ini memungkinkan pemulihan otomatis (self-healing) dan memfasilitasi komunikasi yang lancar antara pengembang dan operator.
2. Pengelolaan Sumber Daya Menggunakan Kode
Semua sumber daya Kubernetes dikelola dengan kode. Misalnya, ketika menginstal aplikasi, pada lingkungan VM sebelumnya, kita menggunakan perintah yum
seperti di bawah ini.
Kami berusaha untuk mencapai hasil yang diinginkan dengan menjalankan langkah-langkah secara bertahap menggunakan perintah. Khususnya, perintah tertentu harus dijalankan secara berurutan agar berfungsi dengan baik. Namun, seiring berjalannya waktu, status sistem berubah, membuatnya sangat sulit untuk melacak dan mengelola perubahan. Seringkali, pengelolaan dilakukan secara manual, tetapi tidak ada jaminan bahwa status sistem saat ini sesuai dengan dokumen manual yang ada (up-to-date).
Lingkungan Kubernetes juga dapat menggunakan perintah kubectl create deployment
seperti pada contoh sebelumnya, tetapi hampir semua sumber daya dibuat dengan menggunakan file kode seperti di bawah ini.
Mengelola sumber daya Kubernetes dengan menggunakan kode, bukan perintah, berarti menggunakan pendekatan manajemen yang deklaratif. Kubernetes adalah platform yang secara kuat mengadopsi pendekatan deklaratif, di mana ‘bentuk deklaratif’ mengacu pada metode yang secara eksplisit mendefinisikan status akhir dan mengarahkan sistem untuk mencapai status tersebut. Dalam pendekatan deklaratif, kita tidak secara langsung menyebutkan proses atau langkah-langkah untuk melakukan tugas, melainkan mendefinisikan status akhir yang diinginkan, sehingga sistem diarahkan untuk mencapai hasil tersebut.
Dengan mendefinisikan sumber daya menggunakan kode, kita dapat secara jelas menentukan sumber daya apa yang diperlukan dan pengaturan apa yang harus ada. Ini memastikan bahwa sumber daya di dalam kluster dibuat dan dikonfigurasi secara konsisten, serta mencegah kesalahan konfigurasi yang tidak terduga atau konflik, sehingga meningkatkan stabilitas sistem. Sebelum menerapkan sumber daya secara nyata, kita dapat mengimplementasikannya dalam kode dan melakukan tinjauan bersama rekan (PR Review) untuk mencegah gangguan yang mungkin terjadi selama proses kerja. Selain itu, penggunaan kode yang sama sangat berguna untuk mereproduksi infrastruktur. Dengan menjalankan kode yang sama di lingkungan mana pun, sumber daya yang sama akan dikerahkan, sehingga menjaga konsistensi lingkungan di berbagai tahap seperti pengembangan, pengujian, dan produksi. Selain itu, melalui sistem kontrol versi (misalnya, Git), kita dapat melacak dan mengelola perubahan. Ini memudahkan untuk melacak riwayat perubahan dan berkolaborasi dengan rekan kerja, serta mengoordinasikan perubahan yang dilakukan.
Berbeda dengan pengembang, operator mungkin merasa keberatan untuk menggunakan kode. Namun, kode yang digunakan dalam Kubernetes tidak rumit seperti bahasa pemrograman umum, sehingga tidak terlalu membebani untuk dipelajari. Jika Anda hanya memahami sintaks dasar file YAML, Anda tidak akan mengalami kesulitan dalam penggunaannya. Selain itu, dengan menggunakan alat seperti VSCode, Anda dapat memanfaatkan fitur auto-complete dan pemeriksaan sintaks otomatis, yang membuatnya lebih nyaman.
3. Konfigurasi Ketersediaan Tinggi (Pet vs Cattle)
Pertama, mari kita memahami konsep Hewan Peliharaan dan Sapi (Pet vs Cattle). Hewan peliharaan dan sapi adalah metafora untuk dua pendekatan dalam pengelolaan infrastruktur.
Hewan peliharaan memerlukan perhatian dan pengelolaan yang individual dan khusus. Setiap hewan peliharaan diberikan nama dan mendapatkan perhatian khusus. Di sisi lain, sapi tidak memiliki nama yang unik; mereka digunakan dengan label atau nomor umum. Dalam contoh sebelumnya, nama pod (nginx-748c667d99-d6bb5) menggunakan nilai hash acak. Pendekatan ini membutuhkan kemampuan untuk dikelola secara besar-besaran dan memberikan kemampuan untuk diubah dan fleksibilitas.
Kubernetes, yang merupakan alat orkestra berbasis kontainer, mengadopsi pendekatan pengelolaan Sapi (Cattle). Kubernetes mengelola aplikasi yang terkontainerisasi dengan cara yang terstandarisasi, mengotomatisasi infrastruktur, dan membangunnya agar dapat diskalakan. Dengan demikian, Kubernetes dapat secara efisien melakukan tugas seperti penyebaran aplikasi, penskalaan, pembaruan bergulir, dan pemulihan otomatis.
Sebagai contoh, ketika Kubernetes menghubungkan aplikasi (web server) dengan aplikasi (database server), ia menggunakan sumber daya layanan (Service) dengan metode nama domain, bukan metode IP yang digunakan dalam lingkungan VM sebelumnya. Metode IP yang sebelumnya digunakan mengandalkan nilai tetap (Static); jika server database berubah, alamat IP-nya juga berubah, sehingga alamat IP yang ditetapkan dalam variabel lingkungan web server juga harus diubah. Namun, Kubernetes menggunakan metode nama domain yang dinamis (Dynamic), sehingga jika alamat IP berubah, koneksi akan otomatis diarahkan ke alamat IP yang baru.
Dengan cara yang serupa, Kubernetes mengasumsikan bahwa gangguan dapat terjadi kapan saja dan menyediakan berbagai fitur seperti load balancer, penjadwalan lanjutan, dan Readiness/Liveness Probe untuk memastikan pemulihan otomatis dan kelangsungan layanan bahkan jika terjadi gangguan.
Berikut adalah contoh sumber daya layanan (Service) Kubernetes.
Ketika menghubungkan antar pod, digunakan layanan yang bernama nginx. Layanan ini secara otomatis menghasilkan 'endpoints' dan akan memperbarui IP yang terpetakan ke layanan tersebut jika alamat IP pod berubah. Oleh karena itu, meskipun alamat IP berubah, nama layanan tetap tidak berubah, sehingga layanan nginx yang ada dapat terus digunakan untuk koneksi antar pod dengan nama yang sama.
4. Perbandingan Solusi Kubernetes Native vs Managed
Di lingkungan on-premise, penggunaan Kubernetes dapat dilakukan dengan menggunakan Kubernetes native versi resmi atau solusi dari vendor seperti OpenShift dan Tanzu. Untuk lingkungan cloud, biasanya digunakan Kubernetes terkelola yang disediakan oleh masing-masing CSP (Cloud Service Provider), seperti EKS (Amazon Elastic Kubernetes Service), AKS (Azure Kubernetes Service), dan GKE (Google Kubernetes Engine).
Native Kubernetes juga sering disebut sebagai Vanilla Kubernetes. Istilah "Vanilla Kubernetes" merujuk pada versi resmi Kubernetes yang dirilis secara resmi. "Vanilla" berarti sesuatu yang umum atau dalam keadaan aslinya, dan dalam konteks ini, istilah tersebut digunakan untuk membedakan versi resmi Kubernetes. Kubernetes sendiri adalah proyek open-source yang dikelola oleh CNCF (Cloud Native Computing Foundation). CNCF bertanggung jawab atas pengembangan dan pemeliharaan Kubernetes, serta menyediakan versi resmi dari Kubernetes. Menyebut versi resmi ini sebagai Vanilla Kubernetes mengindikasikan bahwa versi ini mencakup komponen inti dan fitur dasar Kubernetes, serta mencerminkan keadaan asli seperti yang disediakan oleh CNCF.
Perbedaan utama antara Native Kubernetes dan Managed Kubernetes terletak pada aspek pengelolaan. Native Kubernetes mengharuskan pengguna untuk melakukan instalasi, upgrade, dan pengelolaan control plane secara mandiri. Sebaliknya, Managed Kubernetes menyediakan panduan instalasi dan secara langsung mengelola control plane untuk pengguna. Selain itu, Managed Kubernetes biasanya terintegrasi dengan sumber daya lain milik penyedia layanan, sehingga konfigurasi penyimpanan (storage) dan jaringan (network) dalam lingkungan Kubernetes menjadi lebih mudah dibandingkan dengan lingkungan Native Kubernetes. Integrasi ini memberikan efisiensi dan kemudahan dalam mengelola infrastruktur Kubernetes.
Namun, dari sudut pandang deployment aplikasi dan pengoperasian layanan secara stabil, kedua layanan ini—Native Kubernetes dan Managed Kubernetes—tidak memiliki perbedaan yang signifikan. Keduanya berbasis sistem Kubernetes, sehingga pemahaman mendalam tentang Kubernetes tetap diperlukan. Selain itu, kemampuan untuk mengintegrasikan berbagai perangkat lunak open-source lainnya, seperti Helm, ArgoCD, dan Ingress, sangat penting untuk memastikan sistem berjalan dengan optimal. Menurut pendapat pribadi, sekitar 80% hingga 90% tugas harian yang dilakukan dalam kedua layanan ini adalah serupa. Menggunakan layanan Managed Kubernetes tidak secara otomatis mengurangi beban kerja atau secara drastis menurunkan tingkat kesulitan. Pemahaman dan keterampilan teknis tetap menjadi kunci keberhasilan dalam mengelola lingkungan Kubernetes, terlepas dari jenis layanan yang digunakan.
Sebagai contoh sederhana, dalam Native Kubernetes, Anda dapat melihat berbagai pod yang berjalan di dalam namespace kube-system
. Namespace ini digunakan untuk komponen internal Kubernetes, seperti kube-apiserver
, kube-scheduler
, kube-controller-manager
, dan lainnya yang diperlukan untuk menjalankan cluster Kubernetes.
Misalnya, dalam Native Kubernetes, Anda dapat menemukan berbagai pod yang membentuk control plane, seperti etcd, controller manager, scheduler, dan api-server, di dalam namespace kube-system
. Pod-pod ini merupakan komponen inti yang bertanggung jawab untuk mengelola dan mengoordinasikan operasi cluster Kubernetes.
Namun, dalam EKS (Amazon Elastic Kubernetes Service), control plane dikelola langsung oleh AWS, sehingga Anda tidak dapat melihat pod seperti etcd, controller manager, scheduler, atau api-server. Saat memeriksa daftar pod yang berjalan di cluster, daftar tersebut cenderung lebih sederhana, karena hanya mencakup pod aplikasi pengguna dan beberapa komponen tambahan yang dikelola di tingkat node worker.
Namun, selain pengelolaan control plane, tugas lainnya—seperti mengelola berbagai open-source tools—tetap sama, baik dalam Native Kubernetes maupun Managed Kubernetes. Untuk operasional Kubernetes, penggunaan berbagai proyek open-source sangat penting. Daftar lengkap proyek-proyek open-source yang mendukung ekosistem Kubernetes dapat ditemukan di situs CNCF (Cloud Native Computing Foundation). CNCF menyediakan panduan dan sumber daya untuk membantu mengintegrasikan alat-alat ini ke dalam lingkungan Kubernetes Anda.