Elasticsearch has evolved from an experimental, open-source, NoSQL database for full-text documents to an easily scalable search engine that canhandle a large amount of documents. This evolution has enabled companies todeploy Elasticsearch as an internal search engine for information retrieval (logs,documents, etc.). Later on, it was transformed as a cloud service and the latestdevelopment allows a containerized, serverless deployment of the application,using Docker and Kubernetes.This research examines the behaviour of the system by comparing the length and appearance of single-term and multiple-terms queries, the scaling behaviour and the security of the service. The application is deployed on Google Cloud Platform as a Kubernetes cluster hosting containerized Elasticsearch images that work as databasenodes of a bigger database cluster. As input data, a collection of JSON formatted documents containing the title and abstract of published papersin the field of computer science was used inside a single index. All the plots were extracted using Kibana visualization software. The results showed that multiple-term queries put a bigger stress on thesystem than single-term queries. Also the number of simultaneous users querying in the system is a big factor affecting the behaviour of the system. By scaling up the number of Elasticsearch nodes inside the cluster, indicated that more simultaneous requests could be served by the system.

In the digital age that we live in today, we are dependent on numerous web applications or services, from dealing with banking, booking air flights, and handling our taxes. We expect these applications and services to support high availability, data loss prevention, and fast response time. Microservices is a design pattern to support faster software change, and it also supports other non-functional attributes such as scalability and high availability. One way to deploy your software as microservices is to use containers and deploy them on a container cluster such as Kubernetes. The public opinion about writing Kubernetes deployment files is that it is complex and repetitive writing. This project aims to see how model-driven development can assist with the creation of the Kubernetes deployment files. To see how model-driven development can assist in the creation of Kubernetes files. The project will implement a domain-specific modeling language for Kubernetes, and the language should be able to model the application's desired states. And by using model transformation, the tool can generate Kubernetes deployable files.

Infrastructure is a common word used to express the basic equipment and structures that are needed e.g.  for a country or organisation to function properly. The same concept applies in the field of computer science, without infrastructure one would have problems operating software at scale. Provisioning and maintaining infrastructure through manual labour is a common occurrence in the "iron age" of IT. As the world is progressing towards the "cloud age" of IT, systems are decoupled from physical hardware enabling anyone who is software savvy to automate provisioning and maintenance of infrastructure. This study aims to determine how a generic environment can be created for applications that can run on Unix platforms and how that underlying infrastructure can be provisioned effectively. The results show that by utilising OS-level virtualisation, also known as "containers", one can deploy and serve any application that can use the Linux kernel in the sense that is needed. To further support realising the generic environment, hardware virtualisation was applied to provide the infrastructure needed to be able to use containers. This was done by provisioning a set of virtual machines on different cloud providers with a lightweight operating system that could support the container runtime needed. To manage these containers at scale a container orchestration tool was installed onto the cluster of virtual machines. To provision the said environment in an effective manner, the principles of infrastructure as code (IaC) were used to create a “blueprint" of the infrastructure that was desired. By using the metric mean time to environment (MTTE) it was noted that a cluster of virtual machines with a container orchestration tool installed onto it could be provisioned under 10 minutes for four different cloud providers.

abstract: Traumatic injuries are the leading cause of death in children under 18, with head trauma being the leading cause of death in children below 5. A large but unknown number of traumatic injuries are non-accidental, i.e. inflicted. The lack of sensitivity and specificity required to diagnose Abusive Head Trauma (AHT) from radiological studies results in putting the children at risk of re-injury and death. Modern Deep Learning techniques can be utilized to detect Abusive Head Trauma using Computer Tomography (CT) scans. Training models using these techniques are only a part of building AI-driven Computer-Aided Diagnostic systems. There are challenges in deploying the models to make them highly available and scalable. The thesis models the domain of Abusive Head Trauma using Deep Learning techniques and builds an AI-driven System at scale using best Software Engineering Practices. It has been done in collaboration with Phoenix Children Hospital (PCH). The thesis breaks down AHT into sub-domains of Medical Knowledge, Data Collection, Data Pre-processing, Image Generation, Image Classification, Building APIs, Containers and Kubernetes. Data Collection and Pre-processing were done at PCH with the help of trauma researchers and radiologists. Experiments are run using Deep Learning models such as DCGAN (for Image Generation), Pretrained 2D and custom 3D CNN classifiers for the classification tasks. The trained models are exposed as APIs using the Flask web framework, contained using Docker and deployed on a Kubernetes cluster. The results are analyzed based on the accuracy of the models, the feasibility of their implementation as APIs and load testing the Kubernetes cluster. They suggest the need for Data Annotation at the Slice level for CT scans and an increase in the Data Collection process. Load Testing reveals the auto-scalability feature of the cluster to serve a high number of requests. / Dissertation/Thesis / Masters Thesis Software Engineering 2020

Background: Nowadays lot of companies are enjoying the benefits of kubernetes by maintaining their containerized applications over it. AWS is one of the leading cloud computing service providers and many well-known companies are their clients. Many researches have been conducted on kubernetes, docker containers, cloud computing platforms but a confusion exists on how to deploy the applications in Kubernetes. A research gap about the impact created by CPU limits and requests while deploying the Kubernetes application can be found. So, through this thesis I want to analyze the performance of the CPU intensive containerized application. It will help many companies avoid the confusion while deploying their applications over kubernetes. Objectives: We measure the scalability of kubernetes under CPU intensive containerized application running over AWS and we can study the impact created by changing CPU limits and requests while deploying the application in Kubernetes. Methods: we choose a blend of literature study and experimentation as methods to conduct the research. Results and Conclusion: From the experiments it is evident that the application performs better when we allocate more CPU limits and less CPU requests when compared to equal CPU requests and CPU limits in the deployment file. CPU metrics collected from SAR and Kubernetes metrics server are similar. It is better to allocate pods with more CPU limits and CPU requests than with equal CPU requests and CPU limits for better performance. Keywords: Kubernetes, CPU intensive containerized application, AWS, Stress-ng.

Containerization has gained popularity for deploying applications in a lightweight environment. Kubernetes and Docker have gained a lot of dominance for scalable deployments of applications in containers. Usually, kubernetes clusters are deployed within a single shared network. For high availability of the application, multiple kubernetes clusters are deployed in multiple regions, due to which the number of kubernetes clusters keeps on increasing over time. Maintaining and managing mul-tiple kubernetes clusters is a challenging and time-consuming process for system administrators or DevOps engineers. These issues can be addressed by deploying a kubernetes cluster in a multi-region environment. A multi-region kubernetes de-ployment reduces the hassle of handling multiple kubernetes masters by having onlyone master with worker nodes spread across multiple regions. In this thesis, we investigated a multi-region kubernetes cluster’s network performance by deploying a multi-region kubernetes cluster with worker nodes across multiple openstack regions and tunneled using wireguard(a VPN protocol). A literature review on the common factors that influence the network performance in a multi-region deployment is conducted for the network performance metrics. Then, we compared the request-response time of this multi-region kubernetes cluster with the regular kubernetes cluster to evaluate the performance of the deployed multi-region kubernetescluster. The results obtained show that a kubernetes cluster with worker nodes ina single shared network has an average request-response time of 2ms. In contrast, the kubernetes cluster with worker nodes in different openstack projects and regions has an average request-response time of 14.804 ms. This thesis aims to provide a performance comparison of the kubernetes cluster with and without wireguard, fac-tors affecting the performance, and an in-depth understanding of concepts related to kubernetes and wireguard.

When dealing with latency-critical applications in Kubernetes, a common strategy is to over-allocate resources to ensure the application can meet its latency guarantees during traffic surges. However, this practice often leads to resource underutilizationas the application will not fully utilize its reserved resources. The Kubernetes scheduler cannot initiate new workloads on the node because of perceived full resource utilization. This study explored the utility of two existing methods, Container Runtime Interface (CRI-RM), which we configured to use the 'balloon policy' and the vertical Pod Autoscaler (VPA) in addressing resource underutilization problems on single node Kubernetes clusters while maintaining latency-grantees of certain pods. Utilizing tc-sim, a network traffic simulator, we deployed four latency-critical and two non-latency-critical pods, all subjected to overallocation. Our finding reveals that VPA was ineffectivein detecting and addressing the underutilization of resources because of its slow response in adjusting requests inside the pods. Moreover, it worsened the underutilization issues of the node. Our configuration of the 'balloon policy' failed to detect theover-allocation issues and further led to performance degradation in the simulator, potentially due to the overhead introduced by CRI-RM. These results underscore the intricacy of over-allocation challenges in latency-critical applications, emphasizing the need for proposed-designed solutions that enable quick and dynamic exchange of resources between pods.

Kubernetes is a free, open-source container orchestration system for deploying and managing Docker containers that host microservices. Its cluster logs are extremely helpful in determining the root cause of a failure. However, as systems become more complex, locating failures becomes more difficult and time-consuming. This study aims to identify the classification algorithms that accurately classify the given log data and, at the same time, require fewer computational resources. Because the data is quite large, we begin with expert-based feature selection to reduce the data size. Following that, TF-IDF feature extraction is performed, and finally, we compare five classification algorithms, SVM, KNN, random forest, gradient boosting and MLP using several metrics. The results show that Random forest produces good accuracy while requiring fewer computational resources compared to other algorithms.

In telecommunications, there is currently a lot of work being done to migrate to the cloud, and a lot of specialized hardware is being exchanged for virtualized solutions. One important part of telecommunication networks that is yet to be moved to the cloud is known as the base-band unit, which sits between the antennas and the core network. The base-band unit has very strict latency requirements, making it unsuitable for out-of-the-box cloud solutions. Ericsson is therefore investigating if cloud solutions can be customized in such a way that base-band unit functionality can be virtualized as well. One such customization is to describe the functionality of a base-band unit using a directed acyclic graph (DAG), and deploy it to a cloud environment using Kubernetes. This thesis sets out to take applications represented using a DAG and deploy it using Kubernetes in such a way that the network latency is reduced when compared to the deployment generated by the default Kubernetes scheduler. The problem of placing the applications onto the available hardware resources was formulated as an integer linear programming problem. The problem was then implemented using Pyomo and solved with the open-source solver GLPK to obtain an optimized placement. This placement was then used to generate a configuration file that could be used to deploy the applications using Kubernetes. A mock application was developed in order to evaluate the optimized placement. The evaluation carried out in this thesis shows that the optimized placement obtained from the solution could improve the average round-trip latency of applications represented using a DAG by up to 30% when compared to the default Kubernetes scheduler.

Cloud computing and containerisation have experienced significant growth in recent years. With cloud providers requiring users to specify resource limits and requests, the need for performance and resource optimisation has emerged in the cloud computing domain. This thesis focuses on examining three autoscaling approaches in the Kubernetes container orchestrator: Hybrid Pod Autoscaler, Vertical Pod Autoscaler (VPA), and Horizontal Pod Autoscaler (HPA). To conduct the analysis, a production-grade microservice was deployed on a GKE cluster, replicating the workload of the host company Nordnet Bank AB, a pan-Nordic platform for savings investments. The main objective was to investigate the impact of the different autoscalers on the 50th and 99th percentile response times. The study also aimed to investigate whether a hybrid pod autoscaler, combining VPA and HPA, could outperform HPA and VPA in terms of response time and CPU usage. Additionally, the study aimed to identify the service metrics that an orchestrator can use to achieve response times similar to those obtained when resources are over-provisioned. The research findings indicate that response times varied significantly depending on the autoscaling strategy. While the 50th percentile response times remained consistent, the 99th percentile exhibited greater variation. Among the strategies, HPA demonstrated consistent performance, albeit with greater variability in the 99th percentile response times. The VPA strategy, in contrast, resulted in higher response times for both the 50th and 99th percentile compared to the baseline. The hybrid approach generally outperformed VPA in terms of response times while showing comparable performance to HPA, although with slightly greater variability. CPU usage patterns of the hybrid approach were more closely aligned with HPA than VPA. CPU usage and request rate were effectively used as service metrics for orchestrators in achieving acceptable 99th percentile response times, as demonstrated by both HPA and the hybrid approach. Nevertheless, these findings are contingent on the specific autoscaler configuration, microservice, and workload model used in this study and may not be universally applicable. / Cloud computing och containerisering har under de senaste åren haft en betydande tillväxt. I och med att molnleverantörer ger användare möjlighet att själva specificera resursgränser, har behovet för prestanda- och resursoptimering inom molntjänster blivit alltmer framträdande. Denna forskning fokuserar på att undersöka och utvärdera tre olika autoskalningsmetoder i Kubernetes containerorkestrator: Hybrid Pod Autoscaler, Vertical Pod Autoscaler (VPA) och Horizontal Pod Autoscaler (HPA).För att genomföra utvärderingen implementerades tre mikrotjänster i en GKE-klustermiljö. Arbetsbelastningen hos den svenska banken och handelsplattformen Nordnet Bank AB replikerades. Det primära syftet med studien var att undersöka hur de olika autoskalningsmetoderna påverkade svarstiden i den 50:e och 99:e percentilen. Utöver detta, syftade också till att undersöka om en hybrid pod autoscaler, som kombinerar både VPA och HPA, kunde överträffa de enskilda metoderna i svarstid och CPU-användning. Dessutom identifiera vilka mätvärden en orchestrator kan använda för att uppnå svarstider som liknar dem som uppnås när resurserna överdimensionerade. Resultaten från forskningen visar att svarstiderna varierade avsevärt beroende på vilken autoskalningsstrategi som användes. Medan svarstiderna för 50:e percentilen var relativt konsekventa, uppvisade 99:e percentilen större variation. HPA visade generellt sett jämn prestanda, men med en något större variation i 99:e percentilen av svarstider. Å andra sidan resulterade VPA i högre svarstider både för 50:e och 99:e percentilen. Hybridmetoden presterade generellt sett bättre än VPA när det gäller svarstider och visade liknande resultat som HPA, även om det fanns en något större variabilitet. Mönstret för CPU-användning för hybridmetoden låg närmare HPA än VPA. CPU-användning och förfrågningshastighet visade sig vara effektiva mätvärden för att uppnå acceptabla svarstider i 99:e percentilen, vilket bekräftades av både HPA och hybridmetoden. Det är dock viktigt att notera att dessa resultat är specifika för den autoskalningskonfiguration, mikrotjänst och arbetsbelastningsmodell som användes i studien och kanske inte är universellt tillämpliga.