Skip to content

Overview

MKA

What Is The Basic MetaKube Accelerator

MetaKube Accelerator is build on top of our mature MetaKube product and offers a variety of production ready tools like redis, prometheus, OpenVPN and more.

The Landscape of MetaKube Accelerator consists of 3 main basic services which is the foundation of a highly customizable environment but still has its flavor of "as a service".

  1. Git-repository Management - powered by GitLab
  2. CI/CD infrastructure - powered by GitLab Runner
  3. curated Catalogue of Building Blocks

Curated Building Blocks

We maintain a curated catalog of Building Blocks. This catalog is being expanded constantly.

Development and DevOps organizations use managed service to lower operational costs and reduce maintaining efforts on tools such as Redis and Elasticsearch. Those are the benefits that all those building blocks provide.

The Addons have a full managed service character, while with the MetaKube Accelerator you have the full control and freedom to configure in a way it suits best for your use case.

In this way, our Building Blocks relieve the development teams of a large part of their work.

What's more, each Building Blocks comes with a promise of reliability and safety for production operation. Comprehensive documentation ensures that developers can use the full potential at any point in time and increase significantly their development speed.

High Availability And Redundancy

Between High Availability and Redundancy, two different aspects need to be mentioned. High Availability means a continuous operation. Redundancy on the other hand means that a component has at least an identical 2nd component to remain in operation. Redundancy is a prerequisite to HA. The value for your business is to achieve no downtimes.

Certain components bring up the notion of quorum. There are various approaches to implement a quorum in distributed systems. In our curated building blocks the default settings cover this aspect for you as our best practice approach.

The details are further described in the repositories of our building blocks. In the following table you can find a concise overview of Building Blocks and their need for redundancy.

Strategy Redundancy And Availability

To achieve redundancy, multiple replicas catches pod failures. Anti affinity rules to guide the scheduler into scheduling the pods on different nodes and catches node failures. Additionally hard anti affinity, to make our node selection rules a hard requirement so that the failure can be caught as soon as possible. Make sure the update deployment strategy is set to rolling update, to minimize downtime during an upgrade.

Software-defined Storage remains available, even if a node or pod dies. This is the self-healing feature which comes with the default K8S behavior... But in certain cases, a node failure for example the local-path-provisioner, causes data loss as the local-storage is bound to the node. We strongly recommend provisioning the velero for backup purposes.