This document describes the ITIL-compliant architecture of a Kubernetes-based business process management (BPM) platform running Imixs-Office-Workflow. This cluster architecture follows an Infrastructure as Code (GitOps) approach. It defines the structure, components, and processes to ensure stable and scalable operations.
1.2 Scope
The architecture includes:
- Separation of application server, network and storage
- GitOps-based deployment (IaC)
- Kubernetes cluster management
- Security and compliance requirements
1.3 Target group
- IT Service Management (ITSM)
- IT operations
- Cloud architects
- DevOps teams
References:
1. Service Overview
Service Name: Imixs-Cloud Platform
Purpose: To provide a scalable, resilient, and secure Kubernetes-based infrastructure tailored for business process management applications, leveraging GitOps principles and Infrastructure as Code (IaC).
Key Features:
- Separation of concerns: decoupling application servers, networking, and storage.
- GitOps-driven deployment and management using Git and Argo CD.
- Integration with Ceph for distributed storage solutions.
- Enhanced security through firewall configurations and NGINX authentication.
- Monitoring components
2. Service Architecture
2.1 Kubernetes Cluster Components
A Cluster consists of a minimum of 4 nodes – the master node providing the kubernetes api scheduler and controller server and a minimum of 3 worker nodesserving the applications (pods).

All nodes are defined by unique fixed IP-addresses and DNS names. Only the manager-node need to be accessible through the Internet.
Master Node
The master node may run on a virtual machine, and hosts the Kubernetes API server and controls the cluster.
Worker Nodes
Worker nodes should run on bare metal and are responsible to run the business process management platform as containerized applications and services.
Private Docker Registry:
At least one private docker registry stores private custom Docker images for internal use.
Storage Solution
Persistence Volumes used by database containers connects to an independent Ceph cluster for persistent storage. See section ‘Storage Layer’
2.2 Networking
Internal Communication
Internal communication is controlled by the API server utilizes Calico for networking between pods and services.
External Access
External access is managed by a Reverse Proxy based on NGINX Ingress Controller, which supports SSL termination integrated with Let’s Encrypt for certificate management.
- Firewall Configuration: Employs iptables to restrict unauthorized access and protect the cluster.imixs.github.io+1imixs.github.io+1
2.3 Storage Layer
Ceph Integration: Provides scalable and resilient storage, decoupled from the Kubernetes cluster. This separation enhances flexibility and fault tolerance.
Key Features:
• Scalability: Dynamically expand storage resources without downtime.
• Redundancy: Replication across multiple nodes (CRUSH algorithm).
• Multi-Protocol Support:
◦ RBD (RADOS Block Device): For Kubernetes PVs (RWX/RWO).
◦ S3 API: Object storage for backups/artifacts.

Persistent Volumes: Managed through Kubernetes PersistentVolumeClaims (PVCs), backed by Ceph’s RBD or CephFS.

- Storage Classes for dynamic provisioning of PVC
- CSI-Driver for native integration into the CEPH cluster
3. GitOps and CI/CD Pipeline
- Infrastructure as Code: All configurations, including deployments and services, are defined declaratively in YAML files stored in Git repositories.
- Argo CD: Automates the deployment and synchronization of applications from Git repositories to the Kubernetes cluster, providing a visual interface for monitoring and management.
- CI/CD Integration: Supports integration with CI tools like GitHub Actions to automate testing and deployment processes.
4. Security Management
The goal of the Firewall setup rule is to avoid unauthorized access to your cluster but allowing internal communication.

- Firewall (iptables): Configured to allow only necessary traffic, blocking unauthorized access to the cluster.
- NGINX Authentication: Supports basic authentication mechanisms to secure services exposed via the Ingress Controller.
- Role-Based Access Control (RBAC): Enforces fine-grained access policies within the Kubernetes cluster.
References:
https://github.com/imixs/imixs-cloud/blob/master/doc/FIREWALL.md
https://imixs.github.io/imixs-cloud/doc/SECURITY.html
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
5. Monitoring and Logging
- Prometheus: Collects metrics from Kubernetes components and applications for real-time monitoring.
- Grafana: Provides dashboards for visualizing metrics collected by Prometheus.
- Alerting: Configured to notify administrators of anomalies or threshold breaches in system performance.
6. High Availability and Scalability
- Cluster Scaling: Supports horizontal scaling by adding more worker nodes to handle increased workloads.
- Redundancy: Critical components like the API server and etcd can be configured for high availability to prevent single points of failure.
- Load Balancing: Distributes traffic across multiple instances to ensure optimal resource utilization and response times.
7. Service Management Practices
7.1 Service Design
- Capacity Planning: Regular assessments to ensure the infrastructure meets current and future demands.
- Availability Management: Implementing redundancy and failover mechanisms to maintain service uptime.
- Security Management: Continuous evaluation and enhancement of security measures to protect data and services.
7.2 Service Transition
- Change Management: All changes are tracked and reviewed through Git commits and pull requests, ensuring traceability and accountability.
- Release Management: Automated deployments via Argo CD ensure consistent and reliable release processes.
7.3 Service Operation
- Incident Management: Monitoring tools detect and alert on issues, enabling swift response and resolution.
- Problem Management: Analysis of incidents to identify root causes and implement preventive measures.
- Access Management: RBAC policies control user access to resources, ensuring only authorized interactions.
8. Continual Service Improvement
- Feedback Loops: Regular reviews of performance metrics and user feedback to identify areas for enhancement.
- Automation: Ongoing efforts to automate repetitive tasks, reducing manual intervention and potential errors.
- Training: Continuous learning opportunities for staff to stay updated with best practices and emerging technologies.
9. Appendices
- A. Configuration Directory Structure:
- apps/ – Contains individual application configurations.
- management/ – Houses configurations for management tools like monitoring and registry.
- scripts/ – Includes setup and deployment scripts.
- tools/ – Contains auxiliary tools for cluster management.
- B. Setup Guide:
- Kubernetes Installation: Scripts provided for setting up Kubernetes on Debian 12 systems.
- Cluster Initialization: Guidelines for initializing the master node and joining worker nodes.
- Network Configuration: Instructions for setting up Calico and configuring hostnames and IP addresses
References:
https://imixs.github.io/imixs-cloud/doc/SETUP.html
- C. Security Best Practices:
- Firewall Rules: Recommendations for configuring iptables to secure the cluster.
- Ingress Authentication: Steps to implement basic authentication using NGINX.
- User Management: Guidelines for creating and managing cluster users with appropriate permissions