Hasil Pencarian  ::  Simpan CSV :: Kembali

"Kebutuhan untuk menyediakan layanan kepada pengguna di seluruh dunia menyebabkan layanan aplikasi web untuk beradaptasi menggunakan teknologi baru dan memadai. Untuk mencapai hal tersebut, layanan cloud servis digunakan untuk memperluas jangkauan geografis dari layanan web di seluruh dunia. Peningkatan kualitas pengembangan deployment aplikasi web terlihat pada Kubernetes, alat yang diadopsi secara luas yang didukung di sebagian besar platform cloud, yang memungkinkan penerapan geo-distributed clusters untuk aplikasi yang memiliki pengguna multinasional. Dikarenakan kelangkaan studi mengenai geo-distributed clusters dan kinerjanya, penelitian ini bermaksud untuk menjembatani kesenjangan pengetahuan tersebut dengan mengimplementasikan solusi menggunakan Istio (Anthos Service Mesh), mesh layanan yang paling banyak digunakan untuk aplikasi Kubernetes, serta solusi cloud native di Google Cloud Platform menggunakan MultiClusterService. Studi ini menemukan bahwa kedua pendekatan tersebut dapat diandalkan, namun, Istio/ASM memiliki latensi yang sedikit lebih rendah untuk sebagian besar request. Kedua pendekatan tersebut merupakan pilihan baik untuk aplikasi global, karena keduanya menggunakan geo-aware load balancing, yang merutekan permintaan pengguna ke klaster terdekat yang tersedia. Basis kode studi dan hasil pengujian ini tersedia secara open-sourced untuk studi lebih lanjut tentang aplikasi berbasis geo-distributed Kubernetes clusters.

---

With the need of providing services to ever-growing worldwide users, web application services must adapt new technologies in order to fulfill these needs. As setting up physical servers across the globe is a daunting task, cloud service providers are an essential tool to reach geographical coverage for worldwide web services. Further advancements on the developer experience of deploying web applications can be seen in tools such as Kubernetes, a widely adopted tool that’s supported in most cloud platforms that enables the implementation of geo-distributed clusters for applications with a multi-national user base. However, there is a scarcity of studies regarding geo-distributed clusters methods and its performance. Therefore, this study intends to bridge that knowledge gap by implementing a solution using Istio (Anthos Service Mesh), the most used service mesh for kubernetes applications as well as a cloud native solution on Google Cloud Platform using MultiClusterService. This study found that both approaches are reliable, however, Istio / ASM has a slightly lower latency for the vast majority of requests. In addition, both approaches are a viable choice for worldwide applications, as they both use geo- aware load balancing, which routes user requests to the nearest available cluster. This study’s scripts and test results are open-sourced for further studies about geo-distributed Kubernetes- based applications. "

"Penggunaan container pada arsitektur microservice merupakan sebuah pendekatan yang dapat digunakan untuk mempermudah proses delivery sistem. Container dalam sistem pun lebih mudah diatur dengan Kubernetes sehingga sistem dapat berjalan secaraseamless. Hal tersebut memungkinkan deployment sistem yang cepat dan portable. Salah satu strategi deployment yang dapat digunakan untuk men-deploy sistem yang menggunakan container pada arsitektur microservice adalah canary deployment, dimana sebagian traffic diarahkan ke sekelompok kecil pengguna terlebih dahulu untuk menguji aplikasi di production. Pada dasarnya, canary deployment dapat dilakukan secara native dengan Kubernetes, namun cara ini masih memiliki masalah, yaitu traffic distribution dan replica deployment yang tidak independen. Salah satu solusi yang dapat dilakukanuntuk memecahkan masalah tersebut adalah dengan menggunakan service mesh. Hal ini dikarenakan service mesh memiliki fitur traffic management yang dapat melakukan intelligent routing untuk melakukan canary deployment. Isu independensi ini memengaruhi proses deployment dan kebutuhan bisnis, dimana dengan menggunakan service mesh, jumlah replika pods yang digunakan untuk men-deploy aplikasi tidakberubah bagaimanapun aturan traffic routing-nya. Hal ini berbeda dengan sistem yang tidak menggunakan service mesh, dimana jumlah replika pods-nya berubah-ubah menyesuaikan aturan traffic routing yang telah ditentukan. Tanpa service mesh, rasio replika pods perlu diatur secara manual dengan konfigurasi yang redundan. Di sisi lain, konfigurasi sistem dengan service mesh mudah diatur dengan memanfaatkan fitur-fitur yang disediakan oleh service mesh itu sendiri, khususnya fitur traffic management. Selain itu, penggunaan service mesh dalam proses canary deployment pada aplikasiberbasis Kubernetes juga dapat membuat proses deployment menjadi lebih efisien dalam jumlah resource (pods).

---

The use of containers in the microservice architecture is an approach that can be used to

simplify the system delivery process. Containers in the system are also easier to manage with Kubernetes so that the system can run seamlessly. This allows for fast and portable system deployment. One deployment strategy that can be used to deploy systems that use containers on a microservices architecture is canary deployment, where some traffic is directed to a small group of users first to test the application in production. Basically, canary deployment can be done with Kubernetes natively, but this method still has

problems, namely traffic distribution and replica deployment which are not independent. One solution that can be done to solve this problem is to use a service mesh. This is because the service mesh has a traffic management feature that can perform intelligent routing to perform canary deployments. This independence issue affects the deployment

process and business needs, where by using a service mesh, the number of replica pods used to deploy applications does not change regardless of the traffic routing rules. This is different from a system that does not use a service mesh, where the number of replica pods varies according to predetermined traffic routing rules. Without a service mesh, the ratio of pod replicas needs to be set manually with redundant configurations. On the

other hand, system configuration with service mesh is easy to manage by utilizing the features provided by the service mesh itself, especially the traffic management feature. In addition, the use of service mesh in the canary deployment process for

Kubernetes-based applications can also make the deployment process more efficient in terms of the number of resources (pods)."

"Penggunaan container pada arsitektur microservice merupakan sebuah pendekatan yang dapat digunakan untuk mempermudah proses delivery sistem. Container dalam sistem pun lebih mudah diatur dengan Kubernetes sehingga sistem dapat berjalan secara seamless. Hal tersebut memungkinkan deployment sistem yang cepat dan portable. Salah satu strategi deployment yang dapat digunakan untuk men-deploy sistem yang menggunakan container pada arsitektur microservice adalah canary deployment, dimana sebagian traffic diarahkan ke sekelompok kecil pengguna terlebih dahulu untuk menguji aplikasi di production. Pada dasarnya, canary deployment dapat dilakukan secara native dengan Kubernetes, namun cara ini masih memiliki masalah, yaitu traffic distribution dan replica deployment yang tidak independen. Salah satu solusi yang dapat dilakukan untuk memecahkan masalah tersebut adalah dengan menggunakan service mesh. Hal ini dikarenakan service mesh memiliki fitur traffic management yang dapat melakukan intelligent routing untuk melakukan canary deployment. Isu independensi ini memengaruhi proses deployment dan kebutuhan bisnis, dimana dengan menggunakan service mesh, jumlah replika pods yang digunakan untuk men-deploy aplikasi tidak berubah bagaimanapun aturan traffic routing-nya. Hal ini berbeda dengan sistem yang tidak menggunakan service mesh, dimana jumlah replika pods-nya berubah-ubah menyesuaikan aturan traffic routing yang telah ditentukan. Tanpa service mesh, rasio replika pods perlu diatur secara manual dengan konfigurasi yang redundan. Di sisi lain, konfigurasi sistem dengan service mesh mudah diatur dengan memanfaatkan fitur-fitur yang disediakan oleh service mesh itu sendiri, khususnya fitur traffic management. Selain itu, penggunaan service mesh dalam proses canary deployment pada aplikasi berbasis Kubernetes juga dapat membuat proses deployment menjadi lebih efisien dalam jumlah resource (pods).

---

The use of containers in the microservice architecture is an approach that can be used to simplify the system delivery process. Containers in the system are also easier to manage with Kubernetes so that the system can run seamlessly. This allows for fast and portable system deployment. One deployment strategy that can be used to deploy systems that use containers on a microservices architecture is canary deployment, where some traffic is directed to a small group of users first to test the application in production. Basically, canary deployment can be done with Kubernetes natively, but this method still has problems, namely traffic distribution and replica deployment which are not independent. One solution that can be done to solve this problem is to use a service mesh. This is because the service mesh has a traffic management feature that can perform intelligent routing to perform canary deployments. This independence issue affects the deployment process and business needs, where by using a service mesh, the number of replica pods used to deploy applications does not change regardless of the traffic routing rules. This is different from a system that does not use a service mesh, where the number of replica pods varies according to predetermined traffic routing rules. Without a service mesh, the ratio of pod replicas needs to be set manually with redundant configurations. On the other hand, system configuration with service mesh is easy to manage by utilizing the features provided by the service mesh itself, especially the traffic management feature. In addition, the use of service mesh in the canary deployment process for Kubernetes-based applications can also make the deployment process more efficient in terms of the number of resources (pods)."

"Pengadopsian Kubernetes sebagai bagian dari sistem terdistribusi meningkatkan kompleksitas pengelolaan sistem sehingga dapat membuka peluang ancaman keamanan. Model keamanan Zero Trust pun dikembangkan untuk menangani masalah keamanan akibat peningkatan kompleksitas tersebut. Berfokus pada perlindungan resources, model keamanan ini membatasi kerusakan yang dapat ditimbulkan penyerang dengan memberikan akses terbatas ke setiap pengguna. Pada Kubernetes, penerapan Zero Trust Architecture dapat dibantu dengan memanfaatkan fitur-fitur keamanan milik service mesh. Namun, penerapan Zero Trust Architecture pada Kubernetes dengan menggunakan service mesh masih belum dapat menangani ancaman internal yang disebabkan oleh penyerang yang menyalahgunakan privileges-nya sebagai Cluster Administrator. Ancaman internal tersebut diidentifikasi dan kemudian direproduksi pada sistem acuan penelitian ini. Hasil reproduksi menunjukkan bahwa sistem acuan belum terlindungi dari ancaman internal. Oleh karena itu, penanganan terhadap ancaman internal tersebut dilakukan dengan mereproduksi sistem solusi berupa validasi signature terhadap konfigurasi manifest atas pembuatan dan modifikasi resources pada Kubernetes melalui admission controller. Sistem solusi kemudian diuji dengan dilakukannya reproduksi ancaman internal tersebut. Berdasarkan hasil pengujian, ancaman internal telah berhasil ditangani oleh sistem solusi.

---

The adoption of Kubernetes as part of a distributed system increases the complexity of managing the system, which can lead to security threats. The Zero Trust security model was developed to address the security concerns resulting from this increased complexity. Focusing on resource protection, this security model limits the damage an attacker can cause by granting limited access to each user. In Kubernetes, implementing Zero Trust Architecture can be aided by utilizing the security features of service mesh. However, the implementation of Zero Trust Architecture on Kubernetes using service mesh is still unable to handle internal threats caused by attackers who abuse their privileges as Cluster Administrators. These internal threats are identified and then reproduced on the baseline system of this research. The reproduction results show that the baseline system is not yet protected from the internal threats. Therefore, the internal threats are addressed by reproducing the solution system in the form of signature validation of the manifest configuration for the creation and modification of resources on Kubernetes through the admission controller. The solution system is then tested by reproducing the internal threats. Based on the test results, the internal threats have been successfully handled by the solution system."

"Pengadopsian Kubernetes sebagai bagian dari sistem terdistribusi meningkatkan kompleksitas pengelolaan sistem sehingga dapat membuka peluang ancaman keamanan. Model keamanan Zero Trust pun dikembangkan untuk menangani masalah keamanan akibat peningkatan kompleksitas tersebut. Berfokus pada perlindungan resources, model keamanan ini membatasi kerusakan yang dapat ditimbulkan penyerang dengan memberikan akses terbatas ke setiap pengguna. Pada Kubernetes, penerapan Zero Trust Architecture dapat dibantu dengan memanfaatkan fitur-fitur keamanan milik service mesh. Namun, penerapan Zero Trust Architecture pada Kubernetes dengan menggunakan service mesh masih belum dapat menangani ancaman internal yang disebabkan oleh penyerang yang menyalahgunakan privileges-nya sebagai Cluster Administrator. Ancaman internal tersebut diidentifikasi dan kemudian direproduksi pada sistem acuan penelitian ini. Hasil reproduksi menunjukkan bahwa sistem acuan belum terlindungi dari ancaman internal. Oleh karena itu, penanganan terhadap ancaman internal tersebut dilakukan dengan mereproduksi sistem solusi berupa validasi signature terhadap konfigurasi manifest atas pembuatan dan modifikasi resources pada Kubernetes melalui admission controller. Sistem solusi kemudian diuji dengan dilakukannya reproduksi ancaman internal tersebut. Berdasarkan hasil pengujian, ancaman internal telah berhasil ditangani oleh sistem solusi.

---

The adoption of Kubernetes as part of a distributed system increases the complexity of managing the system, which can lead to security threats. The Zero Trust security model was developed to address the security concerns resulting from this increased complexity. Focusing on resource protection, this security model limits the damage an attacker can cause by granting limited access to each user. In Kubernetes, implementing Zero Trust Architecture can be aided by utilizing the security features of service mesh. However, the implementation of Zero Trust Architecture on Kubernetes using service mesh is still unable to handle internal threats caused by attackers who abuse their privileges as Cluster Administrators. These internal threats are identified and then reproduced on the baseline system of this research. The reproduction results show that the baseline system is not yet protected from the internal threats. Therefore, the internal threats are addressed by reproducing the solution system in the form of signature validation of the manifest configuration for the creation and modification of resources on Kubernetes through the admission controller. The solution system is then tested by reproducing the internal threats. Based on the test results, the internal threats have been successfully handled by the solution system."

"Penggunaan container pada arsitektur microservice merupakan sebuah pendekatan yang dapat digunakan untuk mempermudah proses delivery sistem. Container dalam sistem pun lebih mudah diatur dengan Kubernetes sehingga sistem dapat berjalan secara seamless. Hal tersebut memungkinkan deployment sistem yang cepat dan portable. Salah satu strategi deployment yang dapat digunakan untuk men-deploy sistem yang menggunakan container pada arsitektur microservice adalah canary deployment, dimana sebagian traffic diarahkan ke sekelompok kecil pengguna terlebih dahulu untuk menguji aplikasi di production. Pada dasarnya, canary deployment dapat dilakukan secara native dengan Kubernetes, namun cara ini masih memiliki masalah, yaitu traffic distribution dan replica deployment yang tidak independen. Salah satu solusi yang dapat dilakukan untuk memecahkan masalah tersebut adalah dengan menggunakan service mesh. Hal ini dikarenakan service mesh memiliki fitur traffic management yang dapat melakukan intelligent routing untuk melakukan canary deployment. Isu independensi ini memengaruhi proses deployment dan kebutuhan bisnis, dimana dengan menggunakan service mesh, jumlah replika pods yang digunakan untuk men-deploy aplikasi tidak berubah bagaimanapun aturan traffic routing-nya. Hal ini berbeda dengan sistem yang tidak menggunakan service mesh, dimana jumlah replika pods-nya berubah-ubah menyesuaikan aturan traffic routing yang telah ditentukan. Tanpa service mesh, rasio replika pods perlu diatur secara manual dengan konfigurasi yang redundan. Di sisi lain, konfigurasi sistem dengan service mesh mudah diatur dengan memanfaatkan fitur-fitur yang disediakan oleh service mesh itu sendiri, khususnya fitur traffic management. Selain itu, penggunaan service mesh dalam proses canary deployment pada aplikasi berbasis Kubernetes juga dapat membuat proses deployment menjadi lebih efisien dalam jumlah resource (pods).

---

The use of containers in the microservice architecture is an approach that can be used to simplify the system delivery process. Containers in the system are also easier to manage with Kubernetes so that the system can run seamlessly. This allows for fast and portable system deployment. One deployment strategy that can be used to deploy systems that use containers on a microservices architecture is canary deployment, where some traffic is directed to a small group of users first to test the application in production. Basically, canary deployment can be done with Kubernetes natively, but this method still has problems, namely traffic distribution and replica deployment which are not independent. One solution that can be done to solve this problem is to use a service mesh. This is because the service mesh has a traffic management feature that can perform intelligent routing to perform canary deployments. This independence issue affects the deployment process and business needs, where by using a service mesh, the number of replica pods used to deploy applications does not change regardless of the traffic routing rules. This is different from a system that does not use a service mesh, where the number of replica pods varies according to predetermined traffic routing rules. Without a service mesh, the ratio of pod replicas needs to be set manually with redundant configurations. On the other hand, system configuration with service mesh is easy to manage by utilizing the features provided by the service mesh itself, especially the traffic management feature. In addition, the use of service mesh in the canary deployment process for Kubernetes-based applications can also make the deployment process more efficient in terms of the number of resources (pods)."