Summary
Our CI/CD pipeline (Jenkins) and artifact-mirroring process are Helm-centric. Today, Instana Enterprise/Backend requires copying individual images and using kubectl instana to render/apply manifests. We request official minimal Helm charts for the Instana Enterprise Operator and Instana Backend to streamline mirroring and installation across environments, including air-gapped clusters.
Problem / Why this matters
• Our corporate process mirrors Helm charts (not raw YAML) into internal registries.
• Current Instana docs require copying images one by one and applying templated YAML via kubectl instana, which doesn’t fit our pipeline guardrails.
• This creates friction, bespoke workarounds, and additional validation overhead for each release.
Who is impacted
• Platform/Ops teams managing air-gapped or restricted clusters
• CI engineers maintaining Jenkins pipelines for cluster bootstrapping
• Security/compliance teams auditing provenance of deployable artifacts
Proposed solution (minimal scope)
Publish two official, minimal Helm charts:
1. instana-enterprise-operator
2. instana-backend
Design goals:
• Wrapper-style charts that primarily package/render the same resources produced by kubectl instana … template.
• Stable values schema aligned with existing values.yaml options (registry overrides, imagePullSecrets, namespace, resource requests/limits, version pinning).
• Air-gap friendly: first-class support for global.imageRegistry/image.registry overrides and secret references.
• CRDs lifecycle handled in chart (install/upgrade hooks or split CRDs subchart), documented clearly.
• Idempotent upgrades: conservative defaults; no breaking in-place upgrades by default.
• Versioning: chart version tracks the supported Instana release; changelog documents any values changes.
• Distribution: publish to an official IBM/Instana Helm repo (and OCI registry) with signed charts.
Non-goals (for initial delivery)
• Full parameterization of every backend component. Minimal viable knobs are sufficient: registry/refs, namespaces, pull secrets, resource/classic tolerations/affinities, labels/annotations, and explicit version pinning.
Acceptance criteria
• We can helm install the operator and backend into a clean namespace with only:
o --set global.imageRegistry=<our-internal-registry> (or equivalent)
o --set imagePullSecrets[0].name=<secret>
o --set namespace=<ns> (or via --namespace)
o --set version=<instana-version> / chart appVersion alignment
• CRDs are installed exactly once and handled safely on helm upgrade.
• All images used by the release are discoverable (e.g., via chart notes or helm show values) to enable pre-mirror.
• Works on vanilla Kubernetes and OpenShift in online and air-gapped modes.
• Clear, tested rollback path via helm rollback.
Alternatives considered
• Maintaining private “wrapper charts” that embed rendered YAML from kubectl instana.
o Drawback: not vendor-supported, brittle across releases, extra internal maintenance.
Benefits / Business impact
• Compliance: aligns with our auditable Helm-only mirroring process.
• Velocity: reduces bespoke scripting and manual image lists per release.
• Reliability: standardized install/upgrade/rollback via Helm lifecycles.
• Adoption: lowers effort to scale Instana across many clusters.
