Kubernetes Deployment

Initial k8s deployment steps are used to install Rierino core platform, which then facilitates easy installation of any new modules through its UI

Kubernetes deployment is the “full platform” way to run Rierino. It is the best fit when you need higher scale, workload isolation, and high availability patterns. You start by provisioning the prerequisite systems, then bootstrap the core platform once. After that, most day-to-day deployments can be triggered through the admin UI.

What you get after the initial install

At the end of the initial Kubernetes deployment, you typically have:

• A running admin UI (front-end).

• A running admin gateway (public API endpoint for the UI and clients).

• A baseline set of core runners (admin CRUD + RPC + auth runner).

• A deployer component that standardizes later upgrades and installs.

From that point, you can deploy additional runners and modules without redoing bootstrap steps.

Before you begin

Complete the environment prerequisites first:

• Provision enabling systems like MongoDB, Kafka, and optionally Keycloak.

• Provision a Kubernetes cluster and node pools.

• Set up network connectivity, DNS, and TLS for public endpoints.

• Install your deployment tooling (kubectl, Helm, and optionally Ansible/Terraform).

Start here: Prerequisites

Most failed installs come from missing connectivity between the cluster and enabling systems (MongoDB/Kafka/Keycloak). Confirm firewall rules and DNS early.

How the Kubernetes deployment is structured

Central deployer coordination

Deployments are coordinated by a central deployer component. This keeps deployment credentials and assets in one place. It also makes deployments observable and repeatable.

Namespace separation

The core platform is split into namespaces to reduce blast radius and simplify operations. The step-by-step flow typically creates namespaces like:

• deployment for deployer jobs/services

• admin-backend for core runners

• admin-gateway for gateway/auth/session services

• admin-ui for the UI

Secrets and infrastructure details live outside the database

Infrastructure-specific values (IPs, endpoints, credentials) are kept in Kubernetes ConfigMaps and Secrets. This avoids mixing operational data with application data.

Bootstrap once, then iterate

The initial deployment is mainly about installing the baseline services and wiring connectivity. After that, you can deploy new runners through the platform itself. You typically only return to bootstrap steps when you rebuild the cluster.

Everything is customizable

You can override values at install time. You can also fork deployment repositories and edit Helm charts, Ansible roles, and deployment assets when you need deeper customization.

Choose your installation method

All methods produce the same end state. The difference is how much you want automated versus how much you want to control each step.

Option

Recommended: Helm (umbrella chart). Fastest path.

Runbook

Recommended: Helm - Fully Automated

Option

Ansible (single playbook). Automated but easier to extend.

Runbook

Alternative 1: Ansible - Fully Automated

Option

Step-by-step (kubectl + Helm). Maximum transparency and control.

Runbook

Alternative 2: Ansible - Step-by-Step

If you are optimizing for speed and a standard footprint, use the Helm umbrella chart. If you expect to add custom steps (extra imports, extra systems, more checks), the Ansible playbook is usually easier to extend. If you need full visibility for audit or tuning, use step-by-step.

Typical deployment flow (high level)

The exact commands differ by method, but the flow is consistent.

1

Set up the deployer

Install the deployer components into the deployment namespace. Configure credentials for artifact access (Git/Maven/Docker) as Kubernetes secrets.

2

Populate prerequisite systems

Run initialization tasks such as MongoDB imports, Kafka topic creation, and Keycloak realm/client setup (if used).

3

Deploy core runners (admin backend)

Deploy the baseline runner set that powers admin CRUD/RPC and initial auth flows.

4

Deploy gateway services

Deploy the admin gateway (and auth/session services as needed). Validate the gateway load balancer endpoint.

5

Deploy the admin UI

Deploy the UI and validate it can reach the gateway endpoint.

Timing and expected effort

After prerequisites are done, typical initial deployment time is:

• Fully automated: ~30–60 minutes

• Step-by-step: ~2–3 hours

Your first run is usually slower due to DNS/TLS, firewall rules, and credential setup.

Recommended background knowledge

You do not need to be a Kubernetes expert, but these skills help a lot:

• Cloud networking basics (VPC/VNet, firewall rules, DNS, TLS certificates).

• Kubernetes basics (namespaces, services, deployments, load balancers).

• Helm chart basics (values overrides, releases).

• Terraform and Ansible familiarity (optional, but useful for automation paths).