- 3 minutes to read

Run Nodinite on Kubernetes (Experimental POC)

Nodinite can be evaluated in a Kubernetes-based Proof of Concept (POC) for teams that want container orchestration, repeatable deployments, and environment parity from development to test. The current scope is focused on Nodinite Core Services and should be treated as an experimental track.

This page explains the runtime architecture, identity model, platform options such as OpenShift and AKS, and practical troubleshooting checks for Kubernetes deployments.

Current Scope and Intended Usage

The Kubernetes track is currently intended for short-lived or pre-production POC use.

  • Core Services are available in the container runtime track.
  • OAuth 2.0 and OpenID Connect are required for sign-in.
  • Keycloak is a common local identity provider option for early testing.
  • Monitoring agents and logging agents are not yet bundled in this track.

Important

Kubernetes support is currently an experimental POC path and is not yet a full replacement for a standard Windows Server production installation.

Understanding the Kubernetes Runtime Architecture

Kubernetes adds orchestration primitives such as Deployments, Services, Ingress, and ConfigMaps/Secrets around the containerized Nodinite Core Services runtime. Identity is delegated to an OAuth 2.0/OpenID Connect provider. Most teams package these resources with Helm charts to keep deployment changes controlled and repeatable.

flowchart LR USER["far:fa-user Platform User"] subgraph CLUSTER["Kubernetes Cluster"] INGRESS["far:fa-globe Ingress"] CORE["far:fa-box Nodinite Core Services"] SQL["far:fa-database SQL Server"] IDP["far:fa-id-card OAuth 2.0 IDP"] CONFIG["far:fa-file-lines ConfigMap and Secret"] end USER --> INGRESS INGRESS --> CORE CORE --> SQL CORE --> IDP CONFIG --> CORE style INGRESS fill:#87CEEB,stroke:#1e5f86 style CORE fill:#90EE90,stroke:#2e7d32 style IDP fill:#FFD700,stroke:#8a6d00

Diagram: Kubernetes POC architecture where Nodinite Core Services run behind an Ingress and use externalized configuration with OAuth 2.0/OpenID Connect authentication.

Component Responsibilities

Component Purpose Typical Kubernetes Resource
Core Services Hosts the Nodinite runtime APIs and web workloads Deployment + Service
SQL Server Stores configuration and runtime data External SQL instance or Stateful deployment
Identity provider Handles OAuth 2.0/OpenID Connect tokens External service (for example Keycloak)
Runtime configuration Supplies environment-specific settings ConfigMap + Secret
Ingress Publishes HTTPS endpoints into the cluster Ingress Controller + TLS Secret

OpenShift Example Topology

The following topology illustrates Nodinite Core Services running in OpenShift. This is a useful visual reference when planning namespace design, routes, and identity integration.

OpenShift Nodinite Core Services (7.0)
Example of an OpenShift deployment topology for Nodinite Core Services in an experimental Kubernetes container runtime setup.

Identity and Access Requirements

Kubernetes deployments for Nodinite currently depend on OAuth 2.0/OpenID Connect-based authentication.

  • Use an OAuth 2.0 compliant identity provider.
  • Configure OpenID Connect client settings for Nodinite endpoints.
  • Store client secrets and signing material in Kubernetes Secret resources.
  • Define role and claim mappings before exposing the environment to test users.

Tip

If your first milestone requires Active Directory integrated sign-in from day one, use the Windows Server path and revisit Kubernetes after validating identity requirements.

Kubernetes, OpenShift, and AKS Positioning

Platform Best fit in this stage Notes
Kubernetes (generic) Lab, POC, and repeatable deployment testing Most flexible, requires cluster operations skills
OpenShift Enterprise clusters with security/governance guardrails Good for regulated environments with strict policies
AKS Azure-native teams Simplifies managed control plane and cluster lifecycle

Troubleshooting Checklist

Use this checklist before escalating issues.

  • Verify Ingress hostnames, TLS certificates, and DNS resolution.
  • Verify pod readiness/liveness probes and rollout status.
  • Verify OAuth 2.0 issuer URL, client ID, redirect URI, and OpenID Connect metadata.
  • Verify SQL connectivity from pods to your SQL Server endpoint.
  • Verify ConfigMap and Secret values are mounted and mapped correctly.

Roadmap Direction

The target direction is to provide a configuration-driven deployment model for container platforms, including Kubernetes and OpenShift, with clearer production hardening patterns over time.

Note

Roadmap items are directional and can change between releases.

Next Step