Cloud and platform
Internal Kubernetes platform
A managed cluster with team namespaces, GitOps, policies and observability as a paved road for services.
Fictional scenario. An example situation that illustrates the approach. It is not a client project and describes no measured results.
Business problem
A fictional company runs about ten services on virtual machines with different delivery processes. New teams start slowly.
Assumptions
- A managed service is used (AKS, EKS or GKE).
- Services are already containers or can be.
- There is a platform team.
Constraints
- No direct changes in the cluster.
- Each team sees only its namespaces.
- Secrets are not in Git.
Reference architecture
Components by stage — an illustration, not a running system and not a certified design.
01Input
- Git repositories
- Image registry
02Delivery
- GitOps controller
- Admission policies
03Platform
- Team namespaces
- Ingress
- Autoscaling
04Monitoring
- Metrics
- Logs
- Traces
The diagram as a list
| Stage | Components |
|---|---|
| Input | Git repositories, Image registry |
| Delivery | GitOps controller, Admission policies |
| Platform | Team namespaces, Ingress, Autoscaling |
| Monitoring | Metrics, Logs, Traces |
Interfaces
| From | To | Via |
|---|---|---|
| CI | Registry | Signed images |
| GitOps | Cluster | Pull model |
| Services | Secrets | External secrets |
Data flow
- Code is built and the image is signed.
- A Git change describes the desired state.
- GitOps applies the change.
- Policies reject unsuitable manifests.
- Monitoring shows health.
Security boundaries
- RBAC per namespace.
- Policies: no root, no privileged containers.
- Secrets from an external store.
Where a person approves
- Production manifest changes through review.
- Policy exceptions.
Delivery phases
01 · Design
Clusters, network, multi-tenancy.
02 · Foundation
Cluster, GitOps, policies.
03 · Migration
The first services.
04 · Operation
Upgrades and capacity.
Limitations
- Not every service needs Kubernetes.
- It needs a platform team.
Trade-offs
- Shared vs separate clusters — cost vs isolation.
- Strict policies — slower team onboarding.
Related services
Related assessments
Integration patterns used
Workshops and assessments
Facing something similar?
We start with an assessment of where you are and propose a realistic first phase.