The use of cloud-native technologies has grown in popularity in recent years. With its ability to take advantage of the full benefits of cloud computing, cloud-native architecture has become a hot topic among developers and IT professionals. It refers to building and running applications using cloud services and architectures, including containerization, microservices, and automation tools such as Kubernetes to enable fast and continuous delivery of software applications. In Kubernetes, the desired state of a resource is described declaratively and then handles the details of how to get there. Databases are notoriously hard to deploy in such environments, and the Kubernetes operator pattern extends the resources it manages and how to get to the desired state, called reconcile function. Operators exist to manage PostgreSQL databases with backup and restore functionality, and some require a license to be used. Kubegres is a free-to-use open-source operator, but it lacks restore functionality. This thesis aims to extend the Kubegres operator to support database restoration using dump files. It includes how to create the restore process in Kubernetes, what modifications must be done to the current architecture, and how to make the reconcile function robust and self-healing yet customizable to fit many different needs. Research has been done to explore the design of other operators that already support database restoration. It inspired the design of the resource definition and the restoration process. A new resource definition was added to define the desired state of the database restoration and a new reconcile function to define how to act on it. The state is repeatedly created each time the reconcile function is triggered. During the restoration, a new database is always the target, and once completed, the resources to restore it are deleted, and only the PostgreSQL database is left. The performance of the modified operator impact compared to the original operator was measured to evaluate the operator. The tests consisted of operations both versions of the operator supported, including PostgreSQL database creation, cluster scaling, and changing resource limits. The two collected metrics, CPU- and memory usage, increased by 0.058-0.4 mvCPU (12-33%) and 8.2 MB (29%), respectively. A qualitative evaluation of the operator using qualities such as robustness, self-healing, customizability, and correctness showed that the design fulfils most of the qualities.

Ensuring high system availability is a crucial goal for many organizations, such as Ericsson. In this context, databases play a significant role as they represent a fundamental element that affects system availability within today’s complex technological environments. Mitigating downtime and maintaining high availability during database version changes are essential to ensure seamless continuity of business and system operations, such as data transactions, queries, and administrative tasks. In this project, we developed a prototype system to facilitate near-zero downtime during database version changes, thus preserving service availability and ensuring the process remains transparent to end users. Contrary to traditional database versioning approaches in the telecommunication industry, which require extensive downtime for data backup, validation, and migration, our system applies the established Blue-Green release strategy in a novel way. It benefits from the Logical Replication feature of PostgreSQL for data synchronization and further automates it for cloud-native deployments using the Kubernetes Operator Pattern. The entire database version change operation is automated by applying a Kubernetes Operator Pattern, ensuring uninterrupted external access to the system during the version change process. This innovative approach holds significant potential to augment database management practices, leading to enhanced system availability and reliability for applications deployed on cloud-native infrastructure. / Att säkerställa hög systemtillgänglighet är ett avgörande mål för många organisationer, som Ericsson. I detta sammanhang spelar databaser en betydande roll då de representerar ett grundläggande element som påverkar systemtillgängligheten inom dagens komplexa tekniska miljöer. Att minska driftstopp och bibehålla hög tillgänglighet under databasversionsändringar är avgörande för att säkerställa sömlös kontinuitet i affärs- och systemdrift, såsom datatransaktioner, frågor och administrativa uppgifter. I det här projektet utvecklade vi ett prototypsystem för att underlätta nästan noll driftstopp under databasversionsändringar, vilket bevarar tjänstens tillgänglighet och säkerställer att processen förblir transparent för slutanvändarna. I motsats till traditionella databasversionsmetoder, som kräver omfattande driftstopp för säkerhetskopiering, validering och migrering av data, tillämpar vårt system den etablerade Blue-Green releasestrategin på ett nytt sätt. Den drar nytta av den logiska replikeringsfunktionen i PostgreSQL för datasynkronisering och automatiserar den ytterligare för molnbaserade distributioner med hjälp av Kubernetes Operator Pattern. Hela databasversionsändringsoperationen automatiseras genom att tillämpa ett Kubernetes Operator Pattern, vilket säkerställer oavbruten extern åtkomst till systemet under versionsändringsprocessen. Detta innovativa tillvägagångssätt har betydande potential för att utöka databashanteringsmetoderna, vilket leder till förbättrad systemtillgänglighet och tillförlitlighet för applikationer som distribueras på en molnbaserad infrastruktur.

Edge computing has emerged as a paradigm to support the growing demand for real-time processing of data generated at the edge of the network. As the devices at the edge are constrained, one of the challenges in the area is how to schedule workloads. The scheduling problem is difficult to tackle due to the multitude of sources from which variables originate, diverse algorithms and execution methods, and tasks involving information dissemination and action execution. This project aims to explore the problem and implement a system that simplifies the construction of a scheduler for the edge computing to reduce the cognitive load on developers that work on the area and focus their attention on their expertise area. To construct the solution, a literature review is conducted, a set of functional and non functional requirements are proposed, an implementation using a Kubernetes operator and Python application is performed, and an evaluation and validation of the solution against the requirements and an use case and test case are performed. The results demonstrate that the system generates customized instances capable of receiving any number of inputs, outsources the execution of the logic and interacts with different outputs. This allows developers to rapidly deploy instances for their own needs, focusing on their domain of expertise. / Edge computing har framträtt som ett paradigm för att stödja den växande efterfrågan på realtidsbehandling av data som genereras vid nätverkets kant. Eftersom enheterna vid kanten är begränsade utgör en av utmaningarna inom området hur arbetsbelastningar ska schemaläggas. Schemaläggningsproblemet är svårt att hantera på grund av den mångfald av källor varifrån variabler härstammar, varierande algoritmer och utförandemetoder samt uppgifter som involverar informationsförmedling och utförande av åtgärder. Detta projekt syftar till att utforska problemet och implementera ett system som förenklar konstruktionen av en schemaläggare för kantberäkning för att minska den kognitiva belastningen på utvecklare som arbetar inom området och fokusera deras uppmärksamhet på deras expertområde. För att konstruera lösningen genomförs en litteraturgenomgång, en uppsättning funktionella och ickefunktionella krav föreslås, en implementation med hjälp av en Kubernetesoperatör och en Python-applikation utförs, och en utvärdering och validering av lösningen gentemot kraven, inklusive både användnings- och testfall, genomförs. Resultaten visar att systemet genererar anpassade instanser som kan ta emot vilket antal inmatningar som helst, outsourcar utförandet av logiken och interagerar med olika utgångar. Detta gör det möjligt för utvecklare att snabbt distribuera instanser för sina egna behov och fokusera på sitt expertområde.

CERN Scalable Analytics Section currently offers shared YARN clusters to its users as monitoring, security and experiment operations. YARN clusters with data in HDFS are difficult to provision, complex to manage and resize. This imposes new data and operational challenges to satisfy future physics data processing requirements. As of 2018, there were over 250 PB of physics data stored in CERN’s mass storage called EOS. Hadoop-XRootD Connector allows to read over network data stored in CERN EOS. CERN’s on-premise private cloud based on OpenStack allows to provision on-demand compute resources. Emergence of technologies as Containers-as-a-Service in Openstack Magnum and support for Kubernetes as native resource scheduler for Apache Spark, give opportunity to increase workflow reproducability on different compute infrastructures with use of containers, reduce operational effort of maintaining computing cluster and increase resource utilization via cloud elastic resource provisioning. This trades-off the operational features with datalocality known from traditional systems as Spark/YARN with data in HDFS.In the proposed architecture of cloud-managed Spark/Kubernetes with data stored in external storage systems as EOS, Ceph S3 or Kafka, physicists and other CERN communities can on-demand spawn and resize Spark/Kubernetes cluster, having fine-grained control of Spark Applications. This work focuses on Kubernetes CRD Operator for idiomatically defining and running Apache Spark applications on Kubernetes, with automated scheduling and on-failure resubmission of long-running applications. Spark Operator was introduced with design principle to allow Spark on Kubernetes to be easy to deploy, scale and maintain with similar usability of Spark/YARN.The analysis of concerns related to non-cluster local persistent storage and memory handling has been performed. The architecture scalability has been evaluated on the use case of sustained workload as physics data reduction, with files in ROOT format being stored in CERN mass-storage called EOS. The series of microbenchmarks has been performed to evaluate the architecture properties compared to state-of-the-art Spark/YARN cluster at CERN. Finally, Spark on Kubernetes workload use-cases have been classified, and possible bottlenecks and requirements identified. / CERN Scalable Analytics Section erbjuder för närvarande delade YARN-kluster till sina användare och för övervakning, säkerhet, experimentoperationer, samt till andra grupper som är intresserade av att bearbeta data med hjälp av Big Data-tekniker. Dock är YARNkluster med data i HDFS svåra att tillhandahålla, samt komplexa att hantera och ändra storlek på. Detta innebär nya data och operativa utmaningar för att uppfylla krav på dataprocessering för petabyte-skalning av fysikdata.Från och med 2018 fanns över 250 PB fysikdata lagrade i CERNs masslagring, kallad EOS. CERNs privata moln, baserat på OpenStack, gör det möjligt att tillhandahålla beräkningsresurser på begäran. Uppkomsten av teknik som Containers-as-a-Service i Openstack Magnum och stöd för Kubernetes som inbyggd resursschemaläggare för Apache Spark, ger möjlighet att öka arbetsflödesreproducerbarheten på olika databaser med användning av containers, minska operativa ansträngningar för att upprätthålla datakluster, öka resursutnyttjande via elasiska resurser, samt tillhandahålla delning av resurser mellan olika typer av arbetsbelastningar med kvoter och namnrymder.I den föreslagna arkitekturen av molnstyrda Spark / Kubernetes med data lagrade i externa lagringssystem som EOS, Ceph S3 eller Kafka, kan fysiker och andra CERN-samhällen på begäran skapa och ändra storlek på Spark / Kubernetes-klustrer med finkorrigerad kontroll över Spark Applikationer. Detta arbete fokuserar på Kubernetes CRD Operator för idiomatiskt definierande och körning av Apache Spark-applikationer på Kubernetes, med automatiserad schemaläggning och felåterkoppling av långvariga applikationer. Spark Operator introducerades med designprincipen att tillåta Spark över Kubernetes att vara enkel att distribuera, skala och underhålla. Analys av problem relaterade till icke-lokal kluster persistent lagring och minneshantering har utförts. Arkitekturen har utvärderats med användning av fysikdatareduktion, med filer i ROOT-format som lagras i CERNs masslagringsystem som kallas EOS. En serie av mikrobenchmarks har utförts för att utvärdera arkitekturegenskaperna såsom prestanda jämfört med toppmoderna Spark / YARN-kluster vid CERN, och skalbarhet för långvariga dataprocesseringsjobb.