Kubernetes Platform Architecture

The cluster, add-ons, and ownership model Assistance documents before operating Kubernetes

Kubernetes architecture is more than control-plane diagrams. For an Assistance-managed platform, the architecture defines who owns the cluster, how workloads enter it, which add-ons are operated, how data is protected, and how incidents are handled.

Architecture areas to decide#

Area	Decisions to document
Cluster topology	distribution, region/site, control plane, worker pools, HA expectations, and upgrade path
Networking	CNI, ingress, load balancing, DNS, certificates, private access, and network policies
Delivery	GitOps repository, CI/CD integration, Helm/Kustomize standards, promotion and rollback flow
Security	RBAC, namespaces, service accounts, pod security, image policy, secrets, and audit logging
Observability	metrics, logs, dashboards, alerts, SLO views, and escalation routing
State and recovery	storage classes, persistent volumes, etcd or cluster-state backups, restore process, and application data owner
Operations	maintenance windows, change approvals, runbooks, capacity review, and incident severity model

What Assistance operates#

Layer	Assistance responsibility
Platform control	cluster configuration, add-on lifecycle, upgrades, operational runbooks, and platform incident triage
Shared services	ingress, DNS integration, TLS automation, monitoring, logging, policy controllers, and secrets integration where scoped
Reliability	capacity review, backup/restore evidence for platform state, failure-mode review, and maintenance planning
Documentation	architecture diagram, ownership matrix, access model, support contacts, and handoff notes

What the customer owns#

Layer	Customer responsibility
Workloads	application manifests, charts, resource needs, health behavior, and release safety
Data	database ownership, persistent data classification, retention requirements, and restore acceptance
Governance	team ownership, access approvals, repository permissions, and business-impact decisions
Provider controls	cloud account, quotas, billing, regions, procurement, and vendor obligations unless contracted otherwise

Deployment models#

Model	Best for
K3s on VMs or bare metal	lean clusters, edge sites, labs, internal platforms, and cost-sensitive steady workloads
Managed cloud Kubernetes	teams standardizing on EKS, AKS, GKE, or equivalent provider controls
Existing cluster takeover	organizations with a cluster that needs baseline, hardening, upgrade, or support work
Hybrid platform	development or edge clusters on Assistance-operated infrastructure with production in the customer cloud

Architecture onboarding checklist#

Confirm workloads, environments, traffic, dependencies, and data sensitivity.
Select deployment model and define provider/account ownership.
Define namespace, RBAC, secret, and repository ownership.
Choose ingress, DNS, certificate, observability, and storage patterns.
Document backup, restore, upgrade, and incident paths.
Identify non-goals and work that remains outside the managed platform boundary.

Change and maintenance expectations#

Cluster version upgrades, add-on upgrades, CNI changes, ingress changes, node pool changes, storage changes, and policy changes are planned platform changes. Assistance provides impact notes and rollback approach for the managed layer. Application teams validate workload behavior before and after the change.

Getting started#

Bring your current cluster diagram, cloud account model, deployment workflow, and known pain points. Assistance will turn them into a platform architecture with clear operating boundaries.

Request platform architecture review →