Hasil Pencarian  ::  Simpan CSV :: Kembali

Abstrak :
Pada saat ini, pengadaan suatu event untuk menarik pengguna dilakukan oleh perusahaan. Namun, hal tersebut menyebabkan lonjakan HTTP Request pada pod yang ada pada kluster. Peristiwa tersebut menyebabkan thundering herd yang berdampak ke response time yang meningkat. Pada umumnya, terdapat Horizontal Pod Autoscaler (HPA) yang digunakan untuk mengatur jumlah pod berdasarkan kebutuhan namun waktu yang dibutuhkan cukup lama. Waktu yang lama disebabkan oleh adanya pengecekan yang dilakukan oleh Readiness dan Liveness Probe. Untuk dapat membuat kluster lebih siap menghadapi suatu event, pengembang melakukan kon gurasi ulang pada HPA sebelum event dimulai. Namun, selain diperlukan pengkon gurasian pada HPA diperlukan juga pengkon gurasian terhadap Cluster Autoscaler (CA) dikarenakan pod yang dibuat HPA memiliki kemungkinan tidak aktif jika tidak terdapat node yang tersedia untuk digunakan. Karena pengkon gurasian dilakukan dengan campur tangan manusia, maka peluang human error seperti lupa atau salah hitung dapat terjadi. Maka dari itu, dalam penelitian ini akan dikembangkan sebuah aplikasi KubeEP yang dapat melakukan penjadwalan kon gurasi HPA dan pengkalkulasian banyaknya node yang dibutuhkan oleh suatu kluster pada saat event terjadi. Dampak dari aplikasi KubeEP akan diuji dengan memberikan pengujian beban kepada kluster yang telah dijadwalkan kon gurasi HPA-nya dan telah dikalkulasikan banyak node yang dibutuhkan. Pengujian dilakukan dengan membuat lonjakan HTTP Request pada saat event mulai. Hasil pengujian didapati bahwa kluster yang dilakukan penjadwalan kon gurasi serta pengkalkulasian jumlah maksimum node memiliki performa yang lebih baik. Sementara itu, kluster yang dilakukan penjadwalan kon gurasi namun jumlah maksimum nodenya hanya 2 kali lipat dari sebelumnya memiliki performa yang lebih rendah namun masih bisa memproses HTTP Request. Pada kluster yang dilakukan penjadwalan namun jumlah maksimum node nya tidak disesuaikan lagi memiliki performa yang cukup buruk, banyak sekali HTTP Request yang gagal dan memiliki response time yang tinggi. Performa yang lebih buruk didapati pada saat kluster tidak dilakukan penjadwalan dan pengkalku- lasian jumlah maksimum node yang dibutuhkan. Berdasarkan pengujian tersebut dilakukan analisis dan didapati bahwa dampak dari penjadwalan dan pengkalkulasian yang dilakukan oleh aplikasi KubeEP memberikan efek yang signi kan pada performa dan ketersediaan kluster. ......Currently, a company creates an event to attract many users. However, it causes HTTP Request spikes to cluster pods. HTTP Request spikes cause thundering herd and the result is an increase in response time. In general, there is a Horizontal Pod Autoscaler (HPA) used for managing pod count according to the needs but it takes quite a long time. The long time is due to a check carried out by Readiness and Liveness Probe. To make kluster more ready to handle the event, developer recon gures the HPA before the event starts. However, besides that con guration on HPA is also required con guration of Cluster Autoscaler (CA) because the pod that HPA creates might had a chance to not active if there are no nodes available to be used. Because the con guration is done by human intervention, the possibility of human error such as forgetting or miscalculation can occur. Therefore, in this research, a KubeEP application will be developed that can perform HPA con guration scheduling and calculating the number of nodes required by a cluster when the event occurs. The impact of KubeEP application will be tested by providing load testing to a cluster that had scheduled HPA con guration and calculated the required number of nodes. Testing is done by making HTTP Request spikes when event starts. The test results found that the cluster which had scheduled con guration and calculated the required maximum number of nodes had better performance. Meanwhile, cluster which had scheduled con guration but the maximum number of nodes is doubled the amount from before had a lower performance but it still can process the HTTP Request. In cluster which had scheduled con guration but the maximum number of nodes is not changed had a bad performance, many HTTP Requests had failed and they had high response time. Worst performance found in kluster which had no scheduling and calculation of the required amount of maximum nodes. Based on the tests, an analysis was carried out and it was found that the impact of scheduling and calculations performed by the KubeEP application had a signi cant effect on the performance and availability of the cluster

Abstrak :
Salah satu fungsi CCTV yaitu untuk menjaga lalu-lintas pada persimpangan jalan, yang merupakan bagian dari ATCS. Ketika semakin banyak ATCS yang terpasang di jalan, secara konvensional, semakin banyak layar yang harus dipantau pada control room. Hal ini memerlukan sumber daya manusia tambahan, misalnya untuk dapat mengontrol keseluruhan lampu merah di persimpangan jalan. Sehingga, penggunaan algoritma YOLO dapat membantu melakukan pendeteksian kepadatan lalu lintas pada suatu persimpangan secara otomatis. Namun, menjalankan proses ini di sebuah server dapat mengakibatkan performa yang buruk bila jumlah aliran video dari CCTV yang harus diproses bertambah. Penelitian ini melakukan proof of concept untuk implementasi sistem di atas secara lebih scalable. Video yang berasal dari beberapa CCTV dikirimkan ke sebuah cluster kubernetes dengan memanfaatkan arsitektur multi-core pada GPU. Proses ini menghasilkan video deteksi yang telah diberikan bounding box dari kendaraan yang berada dalam lalulintas. Selain itu, terdapat hasil dari hitungan banyak kendaraan dari masing-masing lajur yang disimpan dalam sebuah databas. Data tersebut digunakan untuk web dashboard yang digunakan untuk memudahkan petugas dalam melakukan pemantauan dan pengambilan keputusan. Uji coba yang dilakukan membuktikan bahwa sistem dapat bekerja dengan stabil dengan auto-scaling mengikuti jumlah workload, dengan rerata penggunaan CPU yaitu 490 mCore, rerata penggunaan memory sebesar 1,7 GB untuk masing-masing pod, rata-rata penggunaan GPU 1,2 GB untuk satu koneksi client, dan 2 GB untuk dua koneksi client. ......One of the functions of CCTV is to maintain traffic at crossroads, which is part of ATCS. As more and more ATCS are installed on the road, conventionally, more screens will have to be monitored in the control room. This requires additional human resources, for example, to be able to control the total number of red lights at crossroads. Thus, the use of the YOLO algorithm can help detect traffic density at an intersection automatically. However, running this process on a server can result in poor performance if the number of video streams from CCTV has to increase. This research does a proof of concept to implement the system in a more scalable way. Video from multiple CCTVs is sent to a Kubernetes cluster by leveraging the GPU's multi-core architecture. This process produces a detection video that has been assigned a bounding box from that in traffic. In addition, there are results from the count of the number of vehicles from each lane that are stored in a database. The data is used for a web dashboard that is used to make it easier for officers to monitor and make decisions. The tests were carried out to prove that the system can work stably with automatic scaling according to the number of workloads, with an average CPU usage of 490 mCore, the average memory usage of 1.7 GB for each pod, an average GPU usage of 1.2 GB for one client connection, and 2 GB for two client connections.

Abstrak :
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.

Abstrak :
Dengan meningkatnya penerapan teknologi informasi dalam berbagai bidang di kehidupan sehari-hari membuat sistem komputer saat ini menjadi sebuah sistem yang vital. Untuk meningkatkan reliabilitas dari sistem komputer, salah satu metode yang dapat dilakukan adalah melakukan replikasi secara geografis. Namun pendekatan tersebut memiliki isu terkait masalah koneksi dan latensi yang tinggi. Termotivasi dari masalah tersebut, penelitian ini melakukan analisis lebih mendalam pada pengaruh penempatan lokasi server sebuah Kubernetes cluster terhadap aspek performa, reliabilitas dan fleksibilitas. Penelitian ini mendapatkan bahwa konfigurasi lokasi Kubernetes cluster tidak memberikan dampak yang signifikan pada aspek performa. Penerapan geo-distributed cluster terbukti dapat memberikan reliabilitas yang lebih baik ketimbang pendekatan single-zone maupun multi-zone. Sedangkan pemanfaatan Kubernetes dapat meningkatkan aspek fleksibilitas namun dengan adanya konsekuensi pada performa sistem. Pada penelitian ini, ditemukan juga bahwa Google Cloud Load Balancer mengalami kendala dalam melakukan load balancing pada geo-distributed cluster yang menyebabkan beberapa server tidak mendapatkan traffic sama sekali dan Google Cloud Load Balancer tidak memenuhi aspek geo-aware yang menyebabkan requests dari pengguna tidak selalu diarahkan pada server yang terdekat dari lokasi pengguna. ......With the application of information technology in various fields of daily life, today's computer system has become a vital system. To increase the reliability of the computer system, one method that can be done is to replicate the application in multiple geographical locations. However, this approach has problems with connection and high latency. Motivated by this problem, this study conducts a more in-depth analysis of the effect of server location placement in a Kubernetes cluster on aspects of performance, reliability, and flexibility. This study found that the use of multiple geographical locations for the Kubernetes cluster does not have a significant impact on the performance. The use of geo-distributed clusters is proven to provide better reliability compared to the single-zone and multi-zone approaches. While the use of Kubernetes can increase the flexibility of the system, it also impacts the system performance. In this study, it was also found that Google Cloud Load Balancer experienced problems when load balancing traffic on the geo-distributed cluster which caused some servers not getting any traffic and Google Cloud Load Balancer does not meet the geo-aware aspect which causes requests from users not directed to the server closest to the user's location.

Abstrak :
User Plane Function (UPF) adalah salah satu komponen utama dalam jaringan inti 5G. Komponen ini berfungsi untuk menangani data plane processing, seperti packet routing, forwarding, quality of service (QoS), dan mengirimkan data pengguna antara control plane dan user plane. UPF merupakan Network Function (NF) yang memiliki beban kerja paling berat dalam jaringan 5G karena harus menangani data pengguna dalam jumlah yang sangat banyak setiap detiknya. Oleh karena itu, improvisasi dari UPF sangatlah penting untuk meningkatkan jumlah data yang dapat ditangani oleh UPF. Salah satu cara untuk meningkatkannya adalah dengan Kubernetes. Kubernetes adalah open-source platform untuk mengelola aplikasi dan layanan dalam container. Dengan menggunakan kubernetes, jaringan 5G dapat menerapkan strategi Multi UPF, yaitu penggunaan lebih dari satu UPF dalam satu machine yang sama. Pada skripsi ini, strategi penerapan tersebut akan dibandingkan dengan penggunaan UPF secara konvensional untuk mengetahui seberapa besar peningkatkan jumlah data pengguna yang tertangani. Hasil percobaan menunjukkan bawha pada User Datagram Protocol (UDP) traffic, penggunaan Kubernetes untuk menerapkan Multi UPF dapat meningkatkan throughput hingga 7.37%, serta mencapai response time yang lebih rendah, meskipun menggunakan resource yang lebih besar, yaitu peningkatan CPU utilization hingga 44.91% dan peningkatan memory utilization hingga 14%. Sebaliknya, pada Transmission Control Protocol (TCP) traffic, hasil yang didapatkan adalah throughput dan response time yang hampir sama antara kedua metode, meskipun resouce utilization juga lebih besar. Hal ini disebabkan oleh adanya mekanisme reliability pada TCP yang membuat adanya bottleneck pada kernel saat pemrosesan paket. ......User Plane Function (UPF) is one of the key component in the 5G core network. This component responsible for data plane processing, such as packet routing, forwarding, quality of service (QoS), and transmitting user data between the control plane and user plane. UPF is a Network Function (NF) with the heaviest workload in the 5G network as it has to handle a significant amount of user data every second. Therefore, improving UPF performance is crucial to enhance the amount of data that can be handled by UPF. One way to improve UPF performance is by using Kubernetes. Kubernetes is an open-source platform for managing applications and services in containers. By utilizing Kubernetes, the 5G network can implement Multi UPF strategy, which involves using more than one UPF within the same machine. In this thesis, this implementation strategy will be compared with the conventional use of UPF to determine the extent of the increase in the amount of user data that can be handled. The experimental results show that for User Datagram Protocol (UDP) traffic, using Kubernetes to implement Multi-UPF can increase throughput by up to 7.37% and achieve lower response time, although it uses more resources, specifically an increase in CPU utilization by up to 44.91% and an increase in memory utilization by up to 14%. Conversely, for Transmission Control Protocol (TCP) traffic, the results show that the throughput and response time are almost the same between the two methods, even though resource utilization is also higher. This is due to the reliability mechanism in TCP that causes a bottleneck in the kernel during packet processing.

Abstrak :
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).

Abstrak :
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).

Abstrak :
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.

Abstrak :
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.

Abstrak :
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).