Kubernetes: Dynamic Scaling

This page explains how Connexion runs as an elastic Kubernetes application. Instead of sizing a fixed application-server cluster for peak load, Kubernetes can add Connexion pods when processing demand rises and remove them when the environment becomes idle.

The result is the same economical model demonstrated in Cloud Dynamic Scaling & Integration: keep a small baseline running, scale out during heavy ingestion, and scale back in after the work completes.

The validation used Amazon EKS, but the Connexion deployment model uses standard Kubernetes resources and Helm packaging.

Deployment and Lifecycle Management

Kubernetes support is broader than autoscaling. Connexion can be installed as a versioned Helm release, configured with environment-specific values, and upgraded through a controlled rolling deployment.

This gives platform teams a familiar way to:

• install Connexion consistently across environments;

• keep configuration and credentials outside the container image;

• perform rolling upgrades while maintaining available capacity;

• integrate releases with CI/CD or GitOps workflows;

• use Kubernetes health, logging, and monitoring controls; and

• manage Connexion alongside software from other vendors.

See Deploying and Managing Connexion with Kubernetes and Helm for the detailed installation, upgrade, rollback, configuration, and day-two operations guide.

Executive Summary

Connexion on Kubernetes combines these platform and application capabilities:

• Connexion Linux app servers run as pods from a versioned container image.

• A Kubernetes Deployment maintains the desired pod count and performs rolling replacement.

• A HorizontalPodAutoscaler (HPA) increases or decreases pod capacity from measured load.

• Kubernetes Services and a load balancer provide stable UI, MCP, health, and inbound-channel endpoints.

• Connexion distributes tabs and channel groups across the active application-server pods.

• PostgreSQL services store Connexion configuration and message data.

• Kubernetes metrics and logs provide operational visibility.

• Helm provides repeatable installation and upgrade management.

Kubernetes owns pod scheduling and replica count. Connexion makes the resulting application-server capacity useful by reporting health, distributing work, and releasing assignments during graceful termination.

High-Level Architecture

What Each Kubernetes Component Does

Connexion and Kubernetes Responsibilities

Kubernetes understands infrastructure capacity; Connexion understands the integration workload.

Kubernetes is responsible for:

• deciding how many pods should run;

• scheduling those pods onto available workers;

• routing traffic only to Ready pods;

• restarting or replacing unhealthy capacity; and

• rolling out new pod versions.

Connexion is responsible for:

• reporting when an application server is ready;

• maintaining a multi-active view of the available application servers;

• placing tabs and channel groups across those servers;

• redistributing work as capacity changes; and

• exposing cluster and scaling state in the Connexion UI.

This separation allows Connexion to use standard Kubernetes behavior without treating application servers as fixed, manually managed hosts.

Dynamic Inbound Routing

Inbound devices can register the TCP, MLLP, HTTP, or HTTPS endpoints they expose. Connexion publishes only routes whose channels are Running and whose owning application-server pods are healthy.

For Kubernetes, the route publisher can generate Gateway API HTTPRoute or TCPRoute resources together with the Service and EndpointSlice that point to the pod currently running the channel. If placement moves to another pod during scaling, maintenance, or recovery, Connexion republishes the route with the new backend endpoint while clients continue using the same Gateway address and port.

See Dynamic Inbound Routing for route registration, Gateway API, AWS NLB, Traefik, HAProxy, movement, reconciliation, and operational guidance.

Horizontal Scaling: Application Servers

Connexion application-server pods are dynamic compute capacity. A new pod starts from the same image, joins the active cluster, passes its readiness checks, and becomes available for tab and channel-group placement.

When the HPA raises or lowers the Deployment replica count, Connexion adapts its placement across the Ready pods. Multiple healthy pods can run work at the same time, providing both horizontal throughput and redundancy.

The validation used six EKS workers across two availability zones. Each Connexion pod requested 3 CPU and 7 GiB of memory with an 8 GiB memory limit. The profile allowed one large Connexion pod per worker and kept the test comparable to the one-application-server-per-instance AWS test.

Horizontal Scaling: Data Layer

Application-server elasticity and database capacity are related but independent. Adding Connexion pods increases available processing capacity, while message repository sizing determines how much persisted message traffic the data layer can sustain.

The validation used:

• one PostgreSQL service for Connexion configuration data;

• two PostgreSQL message repositories; and

• two 120-channel workloads distributed across those repositories.

This architecture allows high-throughput groups to be distributed across multiple message repositories rather than concentrating all writes on a single database service.

Scale-Out: What Happens When Load Increases

The sequence is:

1. Running channels increase application-server CPU.

2. Kubernetes metrics report utilization to the HPA.

3. The HPA raises the Deployment replica count.

4. Kubernetes schedules and starts additional Connexion pods.

5. Startup and readiness checks pass.

6. Connexion recognizes the new Ready capacity and distributes tabs and channel groups across it.

The Kubernetes Service continues routing the Connexion UI and integration endpoints while the application-server membership changes.

During redistribution, channels within a moved tab or channel group may briefly stop and restart on their new application server. Placement occurs at the tab or channel-group level rather than splitting individual channel execution across pods.

Scale-In: What Happens When Load Drops

The validated policy used a 120-second stabilization window and limited scale-down to a maximum 50% reduction every 60 seconds. This avoids abrupt capacity changes and gives Connexion time to release assigned work cleanly.

The sequence is:

1. Processing demand and pod CPU fall.

2. The HPA waits through its stabilization period.

3. The Deployment replica count is reduced.

4. Kubernetes selects a pod for termination and sends SIGTERM.

5. Connexion releases work assigned to that pod.

6. The remaining Ready pods continue serving through the same Service.

After the workload completed, the deployment returned from six Ready pods to its configured one-pod baseline.

Performance Validation

The Kubernetes run used 240 generator channels across 12 tabs. The workload generated, transformed, and stored test messages while Kubernetes expanded the Connexion application tier.

The validated environment used:

• six EKS m7i.xlarge workers across two availability zones;

• Connexion pod request of 3 CPU and 7 GiB memory;

• Connexion pod memory limit of 8 GiB;

• HPA range of 1 to 6 pods with a 70% CPU target;

• two RDS PostgreSQL message repositories;

• a separate RDS PostgreSQL configuration database; and

• a Kubernetes LoadBalancer Service backed by an AWS Network Load Balancer.

Observed results:

• all 240 channels reached Running;

• channel errors remained at zero;

• the deployment scaled from 1 to 6 Ready pods;

• observed throughput exceeded 40k messages per second during the run; and

• the deployment returned from 6 pods to its 1-pod baseline when the workload stopped.

The AWS and Kubernetes runs used similar workload shapes but were not identical throughput benchmarks. The Kubernetes validation focused on the complete pod lifecycle, multi-active placement, stable frontend behavior, and successful scale-out and scale-in.

Operational rules of thumb:

• If Connexion pod CPU remains high, increase application-server capacity and confirm Kubernetes worker capacity is available.

• If new pods remain Pending, add or resize worker capacity.

• If pod CPU is moderate but throughput is capped, inspect PostgreSQL write throughput, storage performance, and repository distribution.

• If one message repository is saturated, distribute groups across additional repositories or tune that database service.

• Size the Kubernetes and PostgreSQL tiers together for the expected workload and availability target.

Helm and Infrastructure Automation

The Kubernetes deployment is packaged as a reusable Helm chart. The validated AWS environment was created with Terraform, while Helm managed the Connexion application release inside the cluster.

The reference assets include:

Download the sanitized Helm and Terraform reference deployment assets

Results and Observations

Final Result

The validated deployment ran all 240 channels with zero channel errors, scaled from 1 to 6 Ready pods under load, and returned to the 1-pod baseline after the workload completed.

What Scaling Looks Like in the Connexion UI

Connexion exposes application-server membership, status, workload placement, throughput, and Kubernetes scaling information in the management UI.

Idle Baseline

The deployment begins with one Ready pod and no active test throughput.

As load increases, additional pods become Ready and workload placement expands across the cluster.

All six application-server pods are Ready and participating in the multi-active deployment.

This screenshot shows one six-pod interval at approximately 20.6k messages per second. It is a placement and cluster-membership example rather than the performance peak; throughput exceeded 40k messages per second at other points in the run.

For the equivalent EC2 and Auto Scaling Group architecture, see Cloud Dynamic Scaling & Integration.