Database Scaling on Kubernetes

Perera, Habarakadage; Silva, T. S. D. De; Wasala, W. M. D. C.; Rajapakshe, R. M. P. R. L.; Kodagoda, Nuwan; Samaratunge, Udara Srimath S.; Jayanandana, H. H. N. C.

doi:10.1109/icac54203.2021.9671185

Cited by 8 publications

(4 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As mentioned above, when containerising and managing an application that involves DBs, the common practice in production is to host and maintain the DBs independently outside of Kubernetes [13], [14]. Google engineers confirm that it is still far from running a DB in Kubernetes in a practical sense, and we have to wait for the further evolution of relevant technologies and tools [3].…”

Section: B Running Databases In Kubernetesmentioning

confidence: 99%

“…However, using external volumes for data persistence could encounter dangling volume issues [12] and will introduce disk I/O performance bottlenecks [16]. • To address the limits of StatefulSets, the second path employs third-party Operators to extend Kubernetes APIs, by creating custom resources and controllers [14]. However, the current Operators are immature and unsuitable for mission-critical workloads [13], not to mention that the extended tech stack may even worsen the complications of running DBs in Kubernetes.…”

Section: B Running Databases In Kubernetesmentioning

confidence: 99%

See 1 more Smart Citation

On Kubernetes-aided Federated Database Systems

Saldias-Vallejos²,

Rodriguez³

et al. 2022

2022 IEEE International Conference on Cloud Computing Technology and Science (CloudCom)

View full text Add to dashboard Cite

Cloud computing has made federated database systems (FDBS) significantly more practical to implement than in the past. As part of a recent Web-based Geographic Information System (WebGIS) project, we are employing cloudnative technologies (from the container ecosystem) to develop a federated database (DB) infrastructure, to help manage and utilise the distributed and various geospatial data. Unfortunately, there seem to be inherent challenges and complexity of applying the container and Kubernetes technologies to building and running DB systems. Considering that most of the geospatial and theme data are pre-obtained and fixed in our WebGIS project, we decided to focus on the read-only user queries and still resort to Kubernetes to implement an FDBS instance to use. Unlike the de facto practices (e.g., using the StatefulSets mechanism, extending Kuberentes APIs, or employing KubeFed), our solution for Kubernetes-aided FDBS simplifies the tech stack by investigating the fractal object of federated data management, inclusively containerising DB instances, and using the lightweight Deployment mechanism to handle stateless DB containers. Overall, this research not only reveals an easy-to-implement approach to constructing read-only components in a fully-fledged FDBS, but also proposes and demonstrates a novel methodology for FDBS investigations.

show abstract

Section: B Running Databases In Kubernetesmentioning

confidence: 99%

Section: B Running Databases In Kubernetesmentioning

confidence: 99%

On Kubernetes-aided Federated Database Systems

Saldias-Vallejos²,

Rodriguez³

et al. 2022

2022 IEEE International Conference on Cloud Computing Technology and Science (CloudCom)

View full text Add to dashboard Cite

show abstract

“…Cloud native Streams relies on the Kubernetes name resolution system to resolve inter-PE connections. There are similarities with the legacy system name resolution system, as it relies on etcd to store its Service configurations, and it also has some currently unresolved latency issues [42,43].…”

Section: Loose Couplingmentioning

confidence: 99%

“…Even with some caching (used to reestablish lost connections), the thundering herd aspect of this initialization process and the strain it applies to the ZooKeeper ensemble delays initial deployment times.Cloud native Streams relies on the Kubernetes name resolution system to resolve inter-PE connections. There are similarities with the legacy system name resolution system, as it relies on etcd to store its Service configurations, and it also has some currently unresolved latency issues[42,43].…”

mentioning

confidence: 99%

A Cloud Native Platform for Stateful Streaming

Schneider,

Guerin,

et al. 2020

Preprint

View full text Add to dashboard Cite

We present the architecture of a cloud native version of IBM Streams, with Kubernetes as our target platform. Streams is a general purpose streaming system with its own platform for managing applications and the compute clusters that execute those applications. Cloud native Streams replaces that platform with Kubernetes. By using Kubernetes as its platform, Streams is able to offload job management, life cycle tracking, address translation, fault tolerance and scheduling. This offloading is possible because we define custom resources that natively integrate into Kubernetes, allowing Streams to use Kubernetes' eventing system as its own. We use four design patterns to implement our system: controllers, conductors, coordinators and causal chains. Composing controllers, conductors and coordinators allows us to build deterministic state machines out of an asynchronous distributed system. The resulting implementation eliminates 75% of the original platform code. Our experimental results show that the performance of Kubernetes is an adequate replacement in most cases, but it has problems with oversubscription, networking latency, garbage collection and pod recovery.

show abstract

FogDEFTKube: Standards‐compliant dynamic deployment of fog service containers

Thalla,

Srirama

2024

Softw Pract Exp

View full text Add to dashboard Cite

The traditional cloud‐centric approach in IoT applications lack the speed and efficiency required for time‐critical tasks, resulting in network inefficiencies. To address this, the notions of Edge and Fog computing have emerged as alternatives. Fog computing facilitates the deployment of services and applications closer to the network's edge, lowering latency and allowing real‐time capabilities. It enhances reliability, fault tolerance, and connectivity in areas with spotty network coverage. Despite the fact that fog computing overcomes the limitations of cloud‐centric IoT processing, its adoption faces challenges like platform independence, interoperability, and portability. To tackle these challenges, the FogDEFT (Fog computing out of the box: Dynamic dEployment of Fog service containers with TOSCA) framework was developed. It complies to OASIS‐TOSCA standards and guarantees dynamic deployment of fog services on resource‐constrained devices while leveraging Docker containerization technology to ensure platform independence and interoperability. Due to its tight coupling with Docker Swarm, which is designed for medium‐sized deployments, the fogDEFT framework is constrained by Docker Swarm's limitations, hindering its ability to effectively manage large‐scale, automated, and resource‐efficient microservice deployments. To address these limitations, we propose FogDEFTKube, an extension of the FogDEFT architecture that incorporates Kubernetes for orchestration, Jenkins for continuous integration and deployment, and a comprehensive redefinition of the core capabilities of the FogDEFT architecture. This offers a promising solution that supports Kubernetes for handling scalable and highly available fog applications with ease while offering CI/CD. FogDEFTKube simplifies the modeling and deployment of fog services while abstracting the complexities of underlying fog networks.

show abstract

Database Scaling on Kubernetes

Cited by 8 publications

References 12 publications

On Kubernetes-aided Federated Database Systems

On Kubernetes-aided Federated Database Systems

A Cloud Native Platform for Stateful Streaming

FogDEFTKube: Standards‐compliant dynamic deployment of fog service containers

Contact Info

Product

Resources

About