Overview

Table of Contents

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

SysEleven maintains a curated catalog of Building Blocks. This catalog is being expanded constantly.

Development and / or DevOps organisations use managed service to lower operational costs and reduce maintaining efforts on tools e.g. like redis, elasticsearch as such.
Those are the benefits that all those building blocks provide.

The Addons have a full managed service character, whereas 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.

Furthermore, 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.

With MetaKube Accelerator, development teams get

  • A mature Release automation process. If you like to learn more about follow the description in Quality Assurance
  • Operational Incident Management. More infos in chapter Report-Incidents
  • Infos on Educational support right here, please follow the links where you would like to dive in more deeply.
  • Well tested mature Building blocks

Remember Our Catalogue of Building Blocks is growing continuously. Check our Section for Building Blocks or subscribe for the SysEleven newsletter !

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 critical 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.

Redundancy?! Building Block description
no need for Redundancy


Not a timebound critical tool.

Similar to velero building block.

Time bound task. Just a quick reuqest.

Time bound task. For the time of the backup. If this component just indicates unavailabilty a backup can be easy postponed. Not like a functional database to be available.



need for redundancy

A network infrastructure tool.

Elasticsearch general purpose nosql database.

Monitoring and alarming.

Your business critical data might reside here!

A Inmemory database and belongs to the NoSQL Database family. Can be used for caching, streaming etc.

Can be your monitoring tool.
need for redundancy but technical limitation

security

Application logging.

Your application cache.

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, in order 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 behaviour.
But in certain cases, a node failure e.g. 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.