1. Introduction

To guarantee high software quality and to ensure that CaaS Platform runs in all supported configurations, regular tests are carried out within the scope of quality assurance. Reference configurations are used to perform these quality tests. In a real scenario, however, usually certain deviations from the reference configurations will exist.

In order to provide planning security for a company introducing new software for this case as well, a more extensive number of system configurations are defined as actively supported. But, unlike the reference configurations, not all actively supported system configurations are tested regularly for functionality. However, Crownpeak Technology GmbH assures that if problems occur with a configuration defined as being actively supported, measures will be taken to solve them.

In addition, there is a range of passively supported system configurations. These are not actively tested by Crownpeak Technology GmbH, but are successfully in use by our customers or partners or were supported in previous versions.

In a few cases, incompatibilities with certain system configurations have been noticed. These system configurations are defined as not supported.

This Technical Data Sheet is valid for CaaS Platform Version 2.0 and above.

2. Terminology

As mentioned in the introduction, real life systems will often not match the reference configurations, which is why a distinction between active/passive supported and unsupported configurations is necessary. Therefore the following terminology is used in this document.

Reference

To ensure that incompatibilities are detected prior to delivery, CaaS is regularly tested with this configuration, for which no restrictions are imposed. Furthermore, if necessary, mechanisms which avoid occurring errors in third party products and, thus, prevent problems during interaction with CaaS will be integrated into CaaS for reference system configurations.

Actively supported

This (or a very similar) system configuration has been tested by Crownpeak Technology GmbH and assessed as being functional. However, due to the time required, the relevant tests are carried out regularly but cannot be performed completely with each release (unlike Reference). We maintain the necessary infrastructure in-house, so that we can quickly carry out our own tests and if necessary debugging.

Prerequisites for the elimination of errors are:

  • Reproducibility of the problem

  • Current maintenance contract

    If error elimination is not possible (e.g. for technical reasons), the system configuration will be defined as Not supported in the next version of the Technical Data Sheet.
Passively supported

This (or a similar) system configuration is or has been successfully operated by a customer/partner and reported as being functional; however, this statement has not been checked by Crownpeak Technology GmbH. In general, a corresponding system configuration does not exist at Crownpeak Technology GmbH, so internal tests are not possible. Crownpeak Technology GmbH can take debugging steps on the basis of error messages (if a current software maintenance agreement exists); however, only within a limited time frame – but the customer has no claim to this.

Especially within the scope of the further development of CaaS, new product functions can result in system configurations that were previously passively supported being declared explicitly not supported, although an adjustment of CaaS to the passively supported system configuration would be technically feasible.

Not supported

The system configurations listed are known to lead to problems or are highly likely to cause problems. Crownpeak Technology GmbH will not take measures to eliminate possibly occurring problems. If a system configuration is not listed here, it does not mean that it is supported, but only that there is no specific information at present.

3. System requirements

The following subchapters resume the system requirements for CaaS Platform. While the first subchapter just provides a brief overview, detailed information about references, recommendations, and restrictions etc. can be found in the second subchapter.

3.1. Brief overview

This chapter resumes the most important system requirements for CaaS Platform in a brief overview. Detailed information about references, recommendations, and restrictions etc. are contained in the following subchapter.

  • Kubernetes 1.11.0

  • Helm 3

3.2. Detailed overview

This chapter describes in detail the system configurations CaaS Platform is able to run with.

Kubernetes as well supports various platforms, although the manufacturer does not get explicit about them. Besides many as-a-service offerings and hosted environments, Kubernetes can be installed from scratch as well.

Kubernetes supports various operating systems and is supported by many service providers.

Detailed information can be found in the official Kubernetes Documentation.
Reference

  • k8s/kubectl version 1.19

  • Helm 3

  • RBAC

  • Calico v1.11.2

Actively supported

  • Reference configuration

Passively supported

  • Helm 2

  • RBAC configuration for Helm 2

For the installation of our Helm distribution using Helm 2 you have to ensure that your tiller pod has the necessary access rights. In the following configuration the system uses a service account named tiller. The role tiller-manager is associated with said service account using role binding.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-manager
  namespace: \$NAMESPACE
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-binding
  namespace: \$NAMESPACE
subjects:
- kind: ServiceAccount
  name: tiller
  namespace: \$NAMESPACE
roleRef:
  kind: Role
  name: tiller-manager
  apiGroup: rbac.authorization.k8s.io

The configuration above is related to a specific namespace. If you want to give tiller access to the whole cluster, you may need to define the access controls using a ClusterRole and a ClusterRoleBinding. Furthermore, the configuration might be too open for your own cluster.

Since the need of further restrictions is highly dependent on the user’s needs, we cannot give any further advice here.

4. Recommended hardware configurations

The following configurations are determined by extensive load and stress test scenarios we ran. Since we simulated test runs with virtually up to 100.000 users doing different operations, the following configurations are very likely to be sufficient for any production scenario. The Kubernetes stack is well prepared for scaling in different ways.

According to the default configuration a Kubernetes setup must be configured with at least three mongodb instances. Each of these pods requires storage amounting to at least 5 times the deployed size of the Project. On top of that the mongodb also keeps a journal of transactions in storage. This can take up varying amounts of space depending on the number of concurrent write requests. Note that this is independent of project size but instead depends on the current workload. In a project of 500MB, journal sizes varying between 300MB and 1500MB have been observed. If a mongodb instance runs out of storage space it will crash. This can result in severe instabilities in the Kubernetes cluster.

Write requests pass through the single primary node of a mongodb cluster. For this reason, it is necessary to react to high load requirements due to writing scenarios with vertical scaling of the nodes used.

Scenarios of many read operations are expected to be most likely. With a single REST API instance, configured with 250 millicores and 350MB memory limit, an Amazon EC2 t2.medium instance is capable of processing 350 requests of mixed nature per second with a response time of less than 200 ms for 99% of all requests.

The mean time for a request is only 21ms. The amount of requests the stack can handle is linear to the number of REST API instances running until the database cluster becomes your limiting factor.

5. Help

The Technical Support of the Crownpeak Technology GmbH provides expert technical support covering any topic related to the FirstSpirit™ product. You can get and find more help concerning relevant topics in our community.

6. Disclaimer

This document is provided for information purposes only. Crownpeak Technology GmbH may change the contents hereof without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Crownpeak Technology GmbH specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionality, services, and processes described herein are subject to change without notice.