Resources · Integration patterns
Kubernetes platform patterns
Team namespaces, admission policies, GitOps, autoscaling and standard observability.
Integration status: Documented pattern
A documented pattern. The product manages no clusters.
Description
The platform offers a paved road: service templates, security policies, network rules, secrets from an external store and standard telemetry.
Prerequisites
- A managed cluster.
- An image registry.
- A multi-tenancy model.
When to use it
- Many containerised services.
- Several teams on one platform.
- Common practices are needed.
When not to use it
- One or two services — a managed service is simpler.
- No platform team.
- Workloads unsuitable for containers.
Reference diagram
An illustration of the components and the flow — not a running system.
01Delivery
- GitOps
- Signed images
02Admission
- Policies
- Quotas
03Runtime
- Namespaces
- Network policies
- Autoscaling
04Monitoring
- Metrics
- Logs
- Traces
The diagram as a list
| Stage | Components |
|---|---|
| Delivery | GitOps, Signed images |
| Admission | Policies, Quotas |
| Runtime | Namespaces, Network policies, Autoscaling |
| Monitoring | Metrics, Logs, Traces |
Security controls
- RBAC per namespace.
- No privileged containers.
- Default-deny network policies.
Observability
- Cluster health.
- Usage per namespace.
- Failed deployments.
Failure modes
| Failure | Mitigation |
|---|---|
| Exhausted resources | Quotas and limits. |
| Failed upgrade | Staged upgrades and rollback. |
| Leaked secrets | An external store and rotation. |