Cloud computing and containerization has been on the rise in recent years and have become important areas of research and development in the field of computer science. One of the challenges in distributed and cloud computing is to predict the resource utilization of the nodes that run the applications and services. This is especially relevant for container-based platforms such as Kubernetes. Predicting the resource utilization of a Kubernetes cluster can help optimize the performance, reliability, and cost-effectiveness of the platform. This thesis focuses on how well different resources in a cluster can be predicted using machine learning techniques. The approach consists of 3 main steps: data collection, data extraction and pre-processing, and data analysis. The data collection step involves stressing the system with a load-generator called Locust and collecting data from Locust and collecting data from Kubernetes with the use of Prometheus. The data pre-processing and extraction step involves extracting relevant data and transforming it into a suitable format for the machine learning models. The final step involves applying different machine learning models to the data and evaluating their accuracy. The results of this thesis illustrate that machine learning can work well for predicting resources in a cluster based on how stressed the system is and that the best performing machine learning model tested was Support Vector Machine with a polynomial kernel. / Cloud computing och containerisering har ökat de senaste åren och har blivit viktiga områden för forskning och utveckling inom datavetenskap. En av utmaningarna inom distribuerad och cloud computing är att förutsäga resursutnyttjandet av de noder som kör applikationerna och tjänsterna. Detta är särskilt relevant för containerbaserade plattformar som Kubernetes. Att förutsäga resursutnyttjandet av ett Kubernetes-kluster kan hjälpa med att optimera plattformens prestanda, tillförlitlighet och kostnadseffektivitet. Denna avhandling fokuserar på hur väl olika resurser i ett kluster kan förutsägas med hjälp av maskininlärningstekniker. Tillvägagångssättet består av 3 huvudsteg: datainsamling, dataextraktion och för-processering, samt dataanalys. Datainsamlingssteget innebär att stressa systemet med en load-generator som heter Locust och samla in data från Locust och även samla in data från Kubernetes med hjälp av Prometheus. Steget för för-processering och extrahering av data innefattar att extrahera relevant data och omvandla den till ett lämpligt format för maskininlärningsmodellerna. Det sista steget innefattar att tillämpa olika maskininlärningsmodeller på data och utvärdera deras noggrannhet. Resultaten av denna avhandling demonstrerar att maskininlärning kan fungera bra för att förutsäga resurser i ett kluster baserat på hur stressat systemet är och att den bäst presterande maskininlärningsmodellen som testades var Support Vector Machine med en polynom-kernel.

Setting up one's software environment and ensuring that all dependencies and settings are the same across the board when deploying an application, can nowadays be a time consuming and frustrating experience. To solve this, the industry has come up with an alternative deployment environment called software containers, or simply containers. These are supposed to help with eliminating the current troubles with virtual machines to create a more streamlined deployment experience.The aim of this study was to compare this deployment technique, containers, against the currently most popular method, virtual machines. This was done using a case study where an already developed application was migrated to a container and deployed online using a cloud provider’s services. Then the application could be deployed via the same cloud service but onto a virtual machine directly, enabling a comparison of the two techniques. During these processes, information was gathered concerning the usability of the two environments. To gain a broader perspective regarding the usability, an interview was conducted as well. Resulting in more well-founded conclusions. The conclusion is that containers are more efficient regarding the use of resources. This could improve the service provided to the customers by improving the quality of the service through more reliable uptimes and speed of service. However, containers also grant more freedom and transfers most of the responsibility over to the developers. This is not always a benefit in larger companies, where regulations must be followed, where a certain level of control over development processes is necessary and where quality control is very important. Further research could be done to see whether containers can be adapted to another company’s current environment. Moreover, how different cloud provider’s services differ. / Att sätta upp och konfigurera sin utvecklingsmiljö, samt att försäkra sig om att alla beroenden och inställningar är lika överallt när man distribuerar en applikation, kan numera vara en tidskrävande och frustrerande process. För att förbättra detta, har industrin utvecklat en alternativ distributionsmiljö som man kallar “software containers” eller helt enkelt “containers”. Dessa är ämnade att eliminera de nuvarande problemen med virtuella maskiner och skapa en mer strömlinjeformad distributionsupplevlese. Målet med denna studie var att jämföra denna nya distributionsteknik, containrar, med den mest använda tekniken i dagsläget, virtuella maskiner. Detta genomfördes med hjälp av en fallstudie, där en redan färdigutvecklad applikation migrerades till en container, och sedan distribuerades publikt genom en molnbaserad tjänst. Applikationen kunde sedan distribueras via samma molnbaserade tjänst men på en virtuell maskin istället, vilket möjliggjorde en jämförelse av de båda teknikerna. Under denna process, samlades även information in kring användbarheten av de båda teknikerna. För att få ett mer nyanserat perspektiv vad gäller användbarheten, så hölls även en intervju, vilket resulterade i något mer välgrundade slutsatser. Slutsatsen som nåddes var att containrar är mer effektiva resursmässigt. Detta kan förbättra den tjänst som erbjuds kunder genom att förbättra kvalitén på tjänsten genom pålitliga upp-tider och hastigheten av tjänsten. Däremot innebär en kontainerlösning att mer frihet, och därmed även mer ansvar, förflyttas till utvecklarna. Detta är inte alltid en fördel i större företag, där regler och begränsningar måste följas, en viss kontroll över utvecklingsprocesser är nödvändig och där det ofta är mycket viktigt med strikta kvalitetskontroller. Vidare forskning kan utföras för att undersöka huruvida containers kan anpassas till ett företags nuvarande utvecklingsmiljö. Olika molntjänster för distribuering av applikationer, samt skillnaderna mellan dessa, är också ett område där vidare undersökning kan bedrivas.

The future of networking lies within the development of low-latency and reliable networks. This development poses increased demand on the presence of edge-nodes. For a network operator to provide a low-latency edge-node resource, the physical distance from antenna-to-user needs to be small. This in turn, requires the network operator to have wide coverage of their physical antennas. An alternative solution is for network operators to share their edge-nodes within a so-called Operator Platform (OP) to reduce the cost of expanding their physical presence. In this project Design Science Research (DSR) was used to design an artifact named Master Thesis Orchestrator (MTO), to address the issue of finding and delivering shared edge-node resources between operators. An abstracted model of a realistic scenario was adopted. This model was used in evaluating the performance of the design against a baseline solution. The MTO is a decentralised algorithm using a shared memory cache. The artifact also has a randomised component which is used to control the frequency of shared memory accesses. These design choices were chosen to improve the performance in terms of scalability. A simulation of the artifact and baseline was conducted using a testbed implemented with Kubernetes/minikube. By assessing the performance on different input sizes (number of edge-nodes), the following performance metrics was gathered: success-rate (accuracy), run-time, and amount of data transmitted. The results showed that the MTO produced an average accuracy of 36% (baseline=96.8%) in terms of successful/failed user requests. The performance regarding run-time and transmitted data, varied depending on the outcome of the request. The MTO’s worst-case performance occurs for failed matches, leading to performance akin to that of the baseline’s average performance. The best-case performance of the MTO showed improvements of run-time compared to the baseline solution. The data was validated through an Analysis of variance (ANOVA)-test and the distributions are significantly (α = 5%) different from each other. The designed artifact is however not better than the baseline solution on all analysed metrics. The designed algorithm is volatile in-terms of time-needed and accuracy, but resource efficient. The poor accuracy is a significant factor into the probability that the worst-case performance would occur resulting in a slow and unreliable solution. Nevertheless, in terms of scalability, the designed artifact is showing less severe growth-rate than that of the baseline. / Framtiden för nätverk ligger i utvecklingen av tillförlitliga nätverk med låg latenstid. Denna utveckling ställer ökade krav på förekomsten av så kallade kantnoder. För att en nätoperatör ska kunna tillhandahålla en kantnodsresurs med låg latenstid måste det fysiska avståndet från antenn till användare vara litet. Detta kräver i sin tur att nätoperatören bör ha stor täckning av sina fysiska antenner. Ett alternativ till detta är att nätoperatörer delar sina resurser inom en så kallad Operatörsplatform för att minska kostnaderna för utökning av sin fysiska antennärvaro. I det här projektet användes Design Science Research för att utforma en produkt vid namn Master Thesis Orchestrator (MTO) för att lösa problemet med att hitta och leverera kantnodresurser mellan operatörer. En abstrakt modell av ett realistiskt scenario skapades. Denna modell användes för att utvärdera designens prestanda i förhållande till en baslinjelösning. MTO är en decentraliserad algoritm som använder sig av en delad minnescache. Designen har också en slumpmässig komponent som används för att styra åtkomstsfrekvensen till det delade minnet. Dessa designval gjordes för att förbättra skalbarhetsprestandan. En simulering av algoritmen och baslinjelösningen genomfördes med hjälp av en testbädd som implementerades med Kubernetes/minikube. Genom att testa prestandan på olika ingångsstorlekar (antal kantnoder) samlades följande mätetal in: framgångkvot (noggrannhet), körtid och mängden överförd data. Resultaten visade att MTO gav en genomsnittlig noggrannhet på 36% (baslinje=96,8%) gällande lyckade/felaktiga matchningar. Prestandan när det gäller körtid och överförda data varierade beroende på resultatet av matchningar. MTO:s sämsta prestanda uppstår vid misslyckade matchningar, vilket leder till ett resultat som liknar baslinjelösningens genomsnittliga prestanda. MTO:s bästa prestanda visade förbättringar av körtiden jämfört med baslinjelösningen. Testerna validerades genom ett ANOVA-test och algoritmerna skiljer sig signifikant (α = 5%) från varandra. Den utformade produkten är dock inte bättre än den baslinjelösningen för alla analyserade mätvärden. Den utformade algoritmen är volatil när det gäller tidsåtgång och noggrannhet, men resurseffektiv. Den dåliga noggrannheten är en betydande faktor för sannolikheten att den värsta möjliga prestandan skulle inträffa, vilket leder till en långsam och opålitlig lösning. När det gäller skalbarhet uppvisar den utformade produkten dock en mindre allvarlig tillväxttakt än baslinjelösningen.

With the development of cloud computing technologies, the concept of Function as a Service (FaaS) has become increasingly popular over the years. Developers can choose to create applications in the form of functions, and delegate the deployment and management of the infrastructure to the FaaS provider. Before a function can be executed at the infrastructure of the FaaS service provider, an environment to execute a function needs to be initiated; this environment initialization is known as cold start. Loading and maintaining a function is costly for FaaS providers, especially the cold start process which costs more system resources like Central Processing Unit (CPU) and memory than keeping functions alive. Therefore it is essential to prevent a cold start whenever possible because this would lead to an increase in both the response time and the cost. An instance management policy need to be implemented to reduce the probability of cold starts while minimizing costs. This project’s objective is to develop an instance management algorithm to minimize total costs while meeting response time requirements. By investigating three widely used instance management algorithms we found that none of them utilize the dependency existing between functions. We believe these dependencies can be useful to reduce response time and cold start probability by predicting next invocations. By leveraging this observation, we proposed a novel Dependency Based Algorithm (DBA). By using extensive simulations we showed that proposed algorithm can solve the problem and provide low response time with low costs compare to baselines. / I och med utvecklingen av molntjänster har konceptet FaaS (Function as a Service) blivit alltmer populärt under årens lopp. Utvecklare kan välja att skapa applikationer i form av funktioner och delegera utplaceringen och förvaltningen av infrastrukturen till FaaS-leverantören. Innan en funktion kan exekveras i FaaS-tjänsteleverantörens infrastruktur måste en miljö för att exekvera en funktion initieras; denna miljöinitialisering kallas kallstart. Att ladda och underhålla en funktion är kostsamt för FaaS-leverantörerna, särskilt kallstartsprocessen som kostar mer systemresurser som CPU och minne än att hålla funktionerna vid liv. Därför är det viktigt att förhindra en kallstart när det är möjligt eftersom detta skulle leda till en ökning av både svarstiden och kostnaden. En policy för hantering av instanser måste införas för att minska sannolikheten för kallstarter och samtidigt minimera kostnaderna. Projektets mål är att utveckla en algoritm för hantering av instanser för att minimera de totala kostnaderna samtidigt som kraven på svarstid uppfylls. Genom att undersöka tre allmänt använda algoritmer för hantering av instanser fann vi att ingen av dem utnyttjar det beroende som finns mellan funktioner. Vi tror att dessa beroenden kan vara användbara för att minska svarstiden och sannolikheten för kallstart genom att förutsäga nästa anrop. Genom att utnyttja denna observation föreslog vi en ny beroendebaserad algoritm. Med hjälp av omfattande simuleringar visade vi att den föreslagna algoritmen kan lösa problemet och ge en låg svarstid med låga kostnader jämfört med baslinjerna.

Microservice architecture is an emerging paradigm that has been unceasingly adopted by large organizations to develop flexible, agile, and distributed applications. This architecture involves breaking a large monolithic application into multiple services that can be deployed and scaled autonomously. Moreover, it helps to improve the resiliency and fault tolerance of a large-scale distributed application. However, this architecture is not without challenges. It increases the number of services communicating with each other, leading to an increased surface of attack. To overcome the security vulnerabilities, it is important that the communication between the services must be secured. Service Mesh is increasingly embraced to resolve the security challenges of microservices and facilitate secure and reliable communication. It is a dedicated infrastructure layer on top of microservices responsible for their networking logic. It uses sidecar proxies to ensure secure and encrypted communication between the services. This thesis studies different deployment models of service meshes, identifies the reasons for federating heterogeneous service meshes, investigates the existing problems faced during the federation process, and proposes a solution to achieve a secure federation between heterogeneous service meshes, i.e., Istio and Consul. The security of the proposed solution was evaluated against the basic security requirements, such as Authenticity, Confidentiality, and Integrity. The evaluation results proved the solution to be secure and feasible for implementation. / Microservice är ett framväxande paradigm som oavbrutet har anammats av stora organisationer för att utveckla flexibla, agila och distribuerade applikationer. denna arkitektur innebär att dela upp en stor monolitisk applikation i flera tjänster som kan distribueras och skalas autonomt. Dessutom hjälper det till att förbättra motståndskraften och feltolerans för en storskalig distribuerad applikation. Men denna arkitektur är inte utan utmaningar. Det ökar antalet tjänster som kommunicerar med varandra, vilket leder till en ökad attackyta. För att övervinna säkerhetsproblemet nerabiliteter är det viktigt att kommunikationen mellan tjänsterna måste säkra. Service Mesh anammas alltmer för att lösa säkerhetsutmaningarna med microservice och underlätta säker och pålitlig kommunikation. Det är en dedikerad infrastruktur lager ovanpå mikrotjänster som ansvarar för deras nätverkslogik. Den använder sidovagn fullmakter för att säkerställa säker och krypterad kommunikation mellan tjänsterna. Detta avhandlingen studerar olika utbyggnadsmodeller av servicenät, identifierar orsakerna för att förena heterogena servicenät, undersöker de befintliga problemen som står inför under förbundsprocessen, och föreslår en lösning för att uppnå en säker federation mellan heterogena tjänstemaskor, d. v. s. Istio och Consul. Säkerheten för prolösningen utvärderades mot de grundläggande säkerhetskraven, såsom Autentticitet, konfidentialitet och integritet. Utvärderingsresultaten visade att lösningen var säker och genomförbar för implementering.

Most of the medium and big size software companies around the world are now using some form of continuous automatic build systems, with smaller companies following through. This approach, towards a more continuous flow, has pushed for more innovation in the domain and the adoption of various orchestration tools for these builds. At the same time, most continuous integration build systems do not leverage the data for improving the total building time. This thesis intends to decrease the overall building time in a pull based build system, named Blazar. This is obtained by decreasing the average time a build waits before being allocated a resource by the orchestration tool, Kubernetes. The improvement of average queuing time is done by leveraging the past data regarding the queue load of the system with the scope of predicting the amount of resources and preemptively allocating them. In the thesis, various time series prediction models are explored in order to find the most relevant one with regards to the available data. The final choice of the model is Facebook’s Prophet due to its ability to leverage multiple seasonalities, handle outliers, accommodate holidays, and provide fast predictions. By tuning various model’s parameters, it was possible to achieve satisfactory results. Thus, for some of the tested periods, the average queuing time was decreased with up to 20%, while maintaining a reasonable resource usage, compared to the time without using any prediction models. Finally, this thesis represents a practical approach that can be applied to other applications and systems. This thesis also details its limitations while discussing other solutions and ideas to further improve the results. / De flesta medelstora och större mjukvaruföretag runt om i världen använder idag någon form av kontinuerliga automatiska byggsystem, något som mindre företag även har börjat efterfölja. Detta tillvägagångssätt mot ett mer kontinuerligt flöde har drivit för mer innovation inom domänen och adopteringen av olika orkestreringsverktyg för dessa byggda program. Samtidigt utnyttjar de flesta kontinuerliga integrationssystem inte den data de samlar in för att förbättra den totala byggtiden. Denna uppsats avser att minska den totala byggtiden i ett pull-baserat byggsystem som heter Blazar. Detta uppnås genom att minska den genomsnittliga tid som ett byggt program väntar innan den tilldelas en resurs av orkestreringsverktyget, Kubernetes. Förbättringen av den genomsnittliga kötiden fås genom att utnyttja tidigare data om systemets köbelastning med omfattningen att förutsäga mängden resurser och fördela dem förebyggande. I avhandlingen undersöks olika tidsserieprognosmodeller för att hitta den mest relevanta med avseende på tillgänglig data. Det slutliga valet av modellen är Facebooks Prophet på grund av dess förmåga att utnyttja flera säsongsbestämmelser, hantera avvikelser, helgdagar och ge snabba förutsägelser. Genom att ställa in olika modellparametrar var det möjligt att uppnå tillfredsställande resultat. Under några av de testade perioderna minskade således den genomsnittliga kötiden med upp till 20%, samtidigt som en rimlig resursanvändning bibehölls, jämfört med tiden som ficks utan att använda någon förutsägelsemodell. Slutligen avser denna avhandling inte att ge en toppmodern lösning. Således slutar det med att beskriva sina begränsningar samtidigt som de tillhandahåller andra lösningar och idéer som kan förbättra resultaten.

As more online services are migrated from monolithic systems into decoupled distributed micro services, the need for efficient internal load balancing solutions increases. Today, there exists two main approaches for load balancing internal traffic between micro services. One approach uses either a central or sidecar proxy to load balance queries over all available server endpoints. The other approach lets client themselves decide which of all available endpoints to send queries to. This study investigates a new approach called lookaside load balancing. This approach consists of a load balancer that uses the control plane to gather a list of service endpoints and their current load. The load balancer can then dynamically provide clients with a subset of suitable endpoints they connect to directly. The endpoint distribution is controlled by a lookaside load balancing algorithm. This study presents such an algorithm that works by changing the endpoint assignment in order to keep current load between an upper and lower bound. In order to compare each of these three load balancing approaches, a test environment in Kubernetes is constructed and modeled to be similar to a real service mesh. With this test environment, we perform four experiments. The first experiment aims at finding suitable settings for the lookaside load balancing algorithm as well as a baseline load configuration for clients and servers. The second experiments evaluates the underlying network infrastructure to test for possible bias in latency measurements. The final two experiments evaluate each load balancing approach in both high and low load scenarios. Results show that lookaside load balancing can achieve similar performance as client-side load balancing in terms of latency and load distribution, but with a smaller CPU and memory footprint. When load is high and uneven, or when compute resource usage should be minimized, the centralized proxy approach is better. With regards to traffic flow control and failure resilience, we can show that lookaside load balancing is better than client-side load balancing. We draw the conclusion that lookaside load balancing can be an alternative approach to client-side load balancing as well as proxy load balancing for some scenarios. / Då fler online tjänster flyttas från monolitsystem till uppdelade distribuerade mikrotjänster, ökas behovet av intern lastbalansering. Idag existerar det två huvudsakliga tillvägagångssätt för intern lastbalansering mellan interna mikrotjänster. Ett sätt använder sig antingen utav en central- eller sido-proxy for att lastbalansera trafik över alla tillgängliga serverinstanser. Det andra sättet låter klienter själva välja vilken utav alla serverinstanser att skicka trafik till. Denna studie undersöker ett nytt tillvägagångssätt kallat extern lastbalansering. Detta tillvägagångssätt består av en lastbalanserare som använder kontrollplanet för att hämta en lista av alla serverinstanser och deras aktuella last. Lastbalanseraren kan då dynamiskt tillsätta en delmängd av alla serverinstanser till klienter och låta dom skapa direktkopplingar. Tillsättningen av serverinstanser kontrolleras av en extern lastbalanseringsalgoritm. Denna studie presenterar en sådan algoritm som fungerar genom att ändra på tillsättningen av serverinstanser för att kunna hålla lasten mellan en övre och lägre gräns. För att kunna jämföra dessa tre tillvägagångssätt för lastbalansering konstrueras och modelleras en testmiljö i Kubernetes till att vara lik ett riktigt service mesh. Med denna testmiljö utför vi fyra experiment. Det första experimentet har som syfte att hitta passande inställningar till den externa lastbalanseringsalgoritmen, samt att hitta en baskonfiguration för last hos klienter or servrar. Det andra experimentet evaluerar den underliggande nätverksinfrastrukturen för att testa efter potentiell partiskhet i latensmätningar. De sista två experimenten evaluerar varje tillvägagångssätt av lastbalansering i både scenarier med hög och låg belastning. Resultaten visar att extern lastbalansering kan uppnå liknande prestanda som klientlastbalansering avseende latens och lastdistribution, men med lägre CPU- och minnesanvändning. När belastningen är hög och ojämn, eller när beräkningsresurserna borde minimeras, är den centraliserade proxy-metoden bättre. Med hänsyn till kontroll över trafikflöde och resistans till systemfel kan vi visa att extern lastbalansering är bättre än klientlastbalansering. Vi drar slutsatsen att extern lastbalansering kan vara ett alternativ till klientlastbalansering samt proxylastbalansering i vissa fall.

With the upcoming 5G deployment and the exponentially increasing data transmitted over cellular networks, off the shelf hardware won't provide enough performance to cope with the data being transferred over cellular networks. To tackle that problem, hardware accelerators will be of great support thanks to their better performances and lower energy consumption. However, hardware accelerators are not a silver bullet as their very nature prevents them to be as flexible as CPUs. Hardware accelerators integration into Kubernetes and Docker, respectively the most used tools for orchestration and containerization, is still not as flexible as it would need. In this thesis, we developed a framework that allows for a more flexible integration of these accelerators into a Kubernetes cluster using Docker containers making use of an abstraction layer instead of the classic virtualization process. Our results compare the performance of an execution with and without the framework that was developed during this thesis. We found that the framework's overhead depends on the size of the data being processed by the accelerator but does not go over a very low percentage of the total execution time. This framework provides an abstraction for hardware accelerators and thus provides an easy way to integrate hardware accelerated applications into a heterogeneous cluster or even across different clusters with different hardware accelerators types. This framework also moves the hardware specific parts of an accelerated program from the containers to the infrastructure and enables a new kind of service, OpenCL as a service.

Orchestrated container virtualization, such as Docker/Kubernetes, is an attractive option to transfer complex IT ecosystems into the cloud. However, this is associated with new challenges for IT security. Containers store sensitive data with the code. The orchestration decides at run-time which containers are executed on which host. Application code is obtained as images from external sources at run-time. Typically, the operator of the cloud is not the owner of the data. Therefore, the configuration of the orchestration is critical, and an attractive target for attackers. A prominent option to secure IT infrastructures is to use security guidelines from agencies, such as Germany’s Federal Office for Information Security. In this work, we analyze the module ”SYS.1.6 Container” from this agency. We want to find out how suitable this module is to secure a typical Kubernetes scenario. Our scenario is a classical 3-tier architecture with front end, business logic and databaseback end. We show that with orchestration, the protection needs for the entire Kubernetes cluster in terms of confidentiality, integrity and availability automatically become ”high” as soon as a sensitive data object is processed or stored in any container. Our analysis has shown that the SYS.1.6 module is generally suitable. However, we have identified three additional threats. Two of them could be exploited automatically, as soon as a respective vulnerability in Docker/Kubernetes appears.

Background:  Cloud computing technology has come a long way with various technological advancements in the past few years. It has been accelerated with the evolution of various virtualization technologies. Currently almost every social platform and small-scale applications look towards cloud to deploy their services successfully and provide maximum satisfaction to their end-user. Thus, virtualizing their services becomes utmost important to deploy and develop their applications. This alone emphasizes the importance of Docker containers in the development world. Docker containers right now are playing a very important role in the field of cloud computing. Since Multimedia plays a huge role in our day to day lives and most people crave for faster and efficient responses, it is essential to develop our applications with better Real time communication capabilities. Thus, we are determining which container orchestration tool serves best for Real time communication applications.  A multimedia application is developed and deployed using WebRTC based Kurento media server and the performance of the server is measured when the application is deployed. We have chosen Kubernetes and Docker Swarm as container platforms for this thesis. The Servers and Clients are virtualized and metrics such as CPU Utilization, Network Traffic, Container overhead, Memory Utilization are measured. These metrics provide the performance overhead in different scenarios for each orchestration technology. This will be helpful to analyze and understand the effect of Kurento server on these technologies. Thus, the results are expected to determine which orchestration technology serves best for RTC applications. Objectives: The objectives of this project are:  • To implement WebRTC based Kurento server in a container orchestrated environment.  • To extract performance metrics such as Network Traffic, CPU and Memory Utilization while server is running.  • To compare WebRTC based Kurento server in Kubernetes and Docker Swarm.   Method: Kubernetes and Docker Swarm environments are setup and then docker images with video conferencing application(One-to-One call and One-to-Many call) using Kurento media server is deployed in them. Once either of the applications is running, experiments are performed for analyzing performance metrics like CPU Utilization, Memory Utilization, Network Traffic and overhead using monitoring tool, Prometheus. Along with Kubernetes and Docker Swarm, Kurento server is also deployed on a stand-alone container to estimate the performance overhead. Later, statistical analysis(ANOVA and differences of Standard error) is done over these metrics and conclusions are drawn.  Results: Based on the performed experiments and the extracted metrics, for One-to-One call application, Kubernetes showed better resource utilization for CPU and Network Traffic while it consumed more memory over Docker Swarm. Similar behaviour is observed for One-to-Many application. When application is scaled, the percent of resource utilization increase in Kubernetes is higher when compared to Docker Swarm, but overall resource utilization of Kubernetes is much lower than that of Docker Swarm.  Conclusions: WebRTC based Kurento media server is investigated in  Kubernetes and Docker Swarm. From the detailed analysis there is significant overhead in Docker Swarm than in Kubernetes for CPU Utilization and Network Traffic. For Memory Utilization, this is opposite. Packet Loss resulted in 0 percent as network transfer is within the same network . By considering all the metrics and providing evidence that numbers obtained in this thesis are statistically significant and not by fluctuations(ANOVA and post-hoc analysis), we can better recommend Kubernetes over Docker Swarm for Web based Real Time Communication.   However, not all applications need the complex deployment, scheduling, and scaling services (or the overhead) that Kubernetes offers. But to meet the increasing demand for seamless Real time communications, and to suffice user requirements, the overheard offered by it is acceptable.