Repository navigation
Feature: Private/SNA SKE cluster support with two-stage runner model #37
Description
Context
Current end-to-end deployment is stable with network.mode = public for SKE. We intentionally defer private/SNA cluster enablement to a dedicated feature stream.
Problem Statement
Using the Kubernetes provider against private control-plane endpoints requires private network reachability from the execution environment. This adds architectural and operational complexity (runner placement, connectivity, auth, retries, diagnostics).
Goal
Introduce first-class support for private SKE clusters (accessScope = SNA) in stackit-landing-zone with a robust two-stage execution model.
Scope (proposed)
- Add/validate prerequisites for private SKE clusters:
- SNA membership
- Routing tables enabled
- Public DNS resolver requirements for SNA networking
- Define a two-stage pipeline model:
- Stage A: STACKIT infrastructure provider (public CI possible)
- Stage B: Kubernetes provider from private-reachable runner
- Add explicit readiness gates/preflight checks:
- API endpoint reachability
- auth/token validation
- Improve operational diagnostics:
- classify network EOF/timeout errors separately from config/drift errors
- expose actionable logs and trace IDs
- Optional break-glass mode:
- bastion/tunnel based temporary access with hardened security defaults
Out of Scope (for this issue)
- Immediate rollout of private clusters in current E2E lane
- Permanent bastion-based proxy as primary operating model
Acceptance Criteria
- Private/SNA cluster path can be deployed reproducibly in CI with documented runner requirements.
- Kubernetes resources are applied only from environments with verified private API reachability.
- Documentation includes decision tree: public vs private/SNA cluster operation model.
Activity
lweberru commentedon Oct 21, 2026
Confirmed scope for the next Application Owner acceptance: Public and Corporate Application Landing Zone projects are required now; Namespace services on a centrally managed Platform Kubernetes cluster inside an SNA are explicitly deferred to this private/SNA execution stream. Namespace services belong only to Platform Kubernetes, not arbitrary Application project templates or an implicit new cluster. Current Application planning rejects Namespace services instead of silently ignoring them.
Future support needs a reviewed Platform Kubernetes target binding and an execution environment with demonstrated private API reachability, followed by separate Plan/Apply acceptance. The successful Platform infrastructure Apply and the Public/Corporate project work in #131 do not qualify that Kubernetes path.
lweberru commentedon Oct 21, 2026
Scope clarification: Accelerator Namespace services have always targeted Platform Kubernetes exclusively. This issue concerns reaching and operating the central Platform Kubernetes API inside an SNA; it does not introduce Namespace Building Blocks for Application-owned clusters. In an Application-owned cluster, namespaces belong to the workload. Possible later Building Blocks layered on Application Landing Zones are a separate future product decision and are outside the current Public/Corporate project-order acceptance.
fix(ci): budget Runner package inspection and clarify Namespace scope (…