/
Kubernetes and Helm: Deployment & Management

Kubernetes and Helm: Deployment & Management

Deploying and Managing Connexion with Kubernetes and Helm

Kubernetes support is not only a scaling feature. It allows organizations that already operate a shared Kubernetes platform to install, upgrade, configure, observe, and remove Connexion using the same Helm-based processes they use for software from other vendors.

This is especially useful in large organizations where a central platform team owns clusters, networking, security policy, registries, secrets, monitoring, and deployment automation. Connexion can fit into that operating model without requiring the platform team to treat each application server as a manually maintained machine.

This page describes the deployment and lifecycle-management contract. Dynamic pod scaling and the production-like EKS test are covered separately in Cloud Integration: Kubernetes Dynamic Scaling.

Why Helm Matters

Helm packages the Kubernetes resources required by Connexion as a versioned release. The same command can perform an initial installation or upgrade an existing release:

helm upgrade --install connexion oci://<registry>/connexion \ --version <chart-version> \ --namespace connexion \ --create-namespace \ -f connexion-production-values.yaml \ --atomic \ --wait \ --timeout 30m

After the customer supplies the cluster, databases, images, values, and referenced Secrets, Helm coordinates the Connexion-specific Kubernetes resources and release ordering.

This gives platform teams familiar operational properties:

  • A declarative, reviewable values file instead of manual server-by-server setup.

  • A versioned chart and immutable container images.

  • Repeatable installation across development, test, and production clusters.

  • Standard release history through helm history.

  • Controlled rolling replacement of application-server pods.

  • Integration with GitOps and CI/CD systems that already understand Helm.

  • Kubernetes-native health, service discovery, policy, placement, and observability.

Helm does not replace the Connexion installer or database upgrade logic. Helm coordinates Kubernetes resources; Connexion-owned bootstrap commands create or upgrade the databases, accounts, runtime catalog, and seeded product configuration.

Responsibility Model

Area

Typical Owner

Responsibility

Area

Typical Owner

Responsibility

Kubernetes cluster and nodes

Customer platform team

Cluster lifecycle, capacity, supported Kubernetes versions, node security, and availability zones.

Container and chart registry

Customer platform team or Conevity

Store immutable, versioned Connexion images and Helm charts.

Helm chart

Conevity

Define supported Kubernetes resources, hooks, probes, rollout behavior, and configuration inputs.

Databases

Customer database/platform team

Provide supported PostgreSQL or SQL Server targets, backups, high availability, capacity, and credentials.

Secrets

Customer security/platform team

Supply database credentials, bootstrap inputs, registry access, certificates, and integrations using Kubernetes Secrets or an external secret controller.

Connexion configuration

Connexion administrator

Define product behavior such as repositories, listeners, routing, and management settings.

Release execution

Customer platform or application team

Promote chart/image versions and values through the organization's deployment pipeline.

Application validation

Connexion administrator and platform team

Confirm health, channel placement, frontends, metrics, logs, and database state after a release.

This separation lets Connexion run on a shared Kubernetes platform without requiring the chart to own the customer's database service, secret manager, ingress standard, or observability stack.

What the Connexion Chart Manages

The chart can manage these Kubernetes resources:

  • Connexion app-server Deployment.

  • Stable Service resources for UI/management, health, MCP, metrics, APIs, and configured listeners.

  • Startup, readiness, and liveness probes.

  • Service account and limited RBAC used for Kubernetes scaling status and optional route publication.

  • HorizontalPodAutoscaler when Kubernetes-managed scaling is enabled.

  • PodDisruptionBudget for voluntary disruption.

  • Bootstrap and runtime-catalog Jobs.

  • References to customer-owned Secrets.

  • Resource requests and limits, topology spread, node selection, affinity, and tolerations.

  • Optional Kubernetes Gateway API route publication.

The chart does not need to create the Kubernetes cluster, database service, enterprise secret manager, monitoring platform, or organization-wide ingress controller. Those remain platform prerequisites and can differ between customers.

Required Inputs

A production release normally supplies:

  • A versioned Connexion application-server image.

  • A matching versioned container-bootstrap image.

  • A Helm chart version that declares compatible application images.

  • A bootstrap request describing the database provider and target databases.

  • Connexion product configuration to seed or update.

  • Database administrator, runtime, and initial Connexion administrator credentials through Secrets.

  • A runtime bootstrap Secret containing the configuration database provider and connection string.

  • Customer-specific resource sizing, Service type, annotations, topology, and scaling values.

  • A license sized for the maximum useful application-server replica count.

Passwords and bearer tokens should not be placed in values files, command-line arguments, or committed JSONC configuration. The chart references Kubernetes Secrets; an organization may populate those Secrets directly or through its existing external-secret controller.

Initial Installation

Connexion supports repeatable first-time installation as a Helm release. The customer supplies the Kubernetes environment, database services, images, configuration values, and referenced Secrets; the chart coordinates the Connexion-specific preparation and application resources.

Required database and runtime preparation completes before application pods are made available. Kubernetes health checks keep traffic away from a pod until Connexion is ready, and an unsuccessful preparation step fails the release rather than presenting a partially initialized deployment as healthy.

Rolling Upgrades

Connexion supports controlled rolling upgrades through a versioned Helm release. A matching chart and set of immutable images are promoted together, required preparation completes first, and Kubernetes then replaces application-server pods progressively.

New pods must become Ready before they serve traffic. Pods being replaced are given time to release assigned work and shut down cleanly. The standard strategy replaces capacity sequentially so the release can remain within its licensed application-server count; customers with spare license and cluster capacity may choose a surge strategy.

Availability During a Roll

With two or more healthy replicas and a rolling-compatible release, Connexion can remain available while pods are upgraded sequentially. Startup and readiness checks, controlled pod replacement, graceful termination, disruption protection, and a stable Service work together to keep usable capacity online.

Work assigned to a replaced pod is moved to another active application server. Individual channel groups may briefly stop and restart during that move, while the Connexion frontend remains stable throughout the rollout.

Database Compatibility Is the Upgrade Boundary

Database compatibility determines the upgrade method. Releases whose application and database versions are mutually compatible can use a rolling upgrade. If a release does not support mixed application versions against the upgraded database, stop all application servers, perform the database and application upgrade together, and then restart the deployment. This requires a short maintenance window. Downgrades follow the release-specific downgrade procedure.

Upgrade and Rollback Operations

Upgrades use the organization's normal Helm or GitOps release process, including release review, rollout monitoring, health validation, and recorded release history.

Downgrades follow release-specific downgrade procedures. Helm rollback is appropriate only where the target application and current database remain compatible.

Configuration Changes

There are three common types of change:

Helm values change

Resource limits, Service annotations, topology, scaling, and other pod-template values are changed through Helm values. A pod-template change produces a controlled Deployment rollout.

Secret rotation

The platform team updates the referenced Secret and performs a controlled rollout so new pods receive the new value. Secret rotation should be tested for database reconnect behavior and should never require storing the cleartext password in product configuration.

Connexion product-configuration reseed

The operator updates the customer-owned product-configuration Secret, then runs a normal Helm upgrade so the pre-upgrade bootstrap hook imports the new configuration. If the running process has cached the old configuration, explicitly restart the Deployment after the successful reseed:

kubectl -n connexion rollout restart deployment/connexion kubectl -n connexion rollout status deployment/connexion --timeout=30m

The separation is intentional: Helm values describe deployment behavior, while Connexion configuration describes product behavior.

Day-Two Management

Common platform operations use standard Kubernetes and Helm interfaces:

# Release and rollout state helm -n connexion status connexion helm -n connexion history connexion kubectl -n connexion get deployment,pods,svc,hpa,pdb # Health and logs kubectl -n connexion describe deployment connexion kubectl -n connexion logs deployment/connexion --all-pods --tail=200 kubectl -n connexion get events --sort-by=.metadata.creationTimestamp # Scale or restart when HPA is disabled kubectl -n connexion scale deployment/connexion --replicas=<count> kubectl -n connexion rollout restart deployment/connexion # Remove Kubernetes resources while retaining external databases helm -n connexion uninstall connexion

Uninstalling a Helm release removes chart-managed Kubernetes resources. It should not automatically destroy customer databases or other external durable services. Reinstalling against retained, compatible databases should recreate the Kubernetes workload without losing product configuration or message data.

Related Documentation