Infrastructure

Kubernetes Operating Model

Assistance-managed Kubernetes boundaries for customers and operators


Kubernetes is a platform for running containerized workloads with declarative deployment, service discovery, scaling, and recovery primitives. In Assistance engagements, Kubernetes is treated as an operated platform boundary: Assistance can design, build, improve, or run the cluster and platform services while your team owns the applications that run on it.

When to use Kubernetes#

SituationFit
Multiple services with repeatable deploymentsGood fit when GitOps, templates, and shared platform controls reduce delivery risk
Existing clusters need reliability workGood fit for Kubernetes Support or a managed platform plan
Moving from VMs or PaaS to more controlGood fit when workload readiness and team ownership are confirmed
Edge, lab, or constrained environmentsConsider Managed Kubernetes
One small app with simple hosting needsKubernetes may add unnecessary operational complexity

What Assistance operates#

Platform areaAssistance responsibility
Cluster foundationdistribution selection, control plane, node pools, upgrades, capacity review, and runbooks
NetworkingCNI, ingress, load balancers, DNS integration, TLS, and network policy baseline
DeliveryGitOps or CI/CD deployment path, Helm/Kustomize conventions, rollback workflow, and promotion controls
SecurityRBAC, namespace model, pod security baseline, secrets integration, image policy guidance, and audit evidence where scoped
ObservabilityPrometheus/Grafana or provider metrics, logging, alerts, dashboards, and escalation routing
Reliabilityetcd or cluster-state backup, restore notes, incident triage, maintenance windows, and post-incident notes

What the customer owns#

AreaCustomer responsibility
Application workloadscode, manifests or chart values, health checks, resource behavior, and release correctness
Business dataclassification, retention, migration acceptance, and application-level recovery validation
Access approvalsidentity source, user approvals, repository permissions, and internal access reviews
Product impactdeployment timing, customer communications, and business decisions during incidents
Provider relationshipcloud account, billing, quotas, and contractual obligations unless Assistance-managed tenancy is contracted

Engagement models#

ModelBest for
Readiness assessmentDecide whether Kubernetes is the right platform and what must change first
Platform buildCreate a new cluster with GitOps, ingress, TLS, observability, security baseline, and handoff docs
Managed platform planOngoing operations, upgrades, incident support, capacity review, and platform backlog management
Migration projectMove selected workloads into Kubernetes with staged rollout and rollback plans
Emergency responseStabilize an active cluster or workload incident before ongoing support is established

Onboarding path#

  1. Discovery — applications, dependencies, traffic, data, compliance, environments, deployment workflow, and team skills.
  2. Target design — topology, distribution, networking, namespaces, GitOps, observability, secrets, backup, and support tier.
  3. Build or takeover — provision a new cluster or baseline the existing one before Assistance accepts operational responsibility.
  4. Workload onboarding — pilot service, deployment path, rollback plan, resource profile, and owner mapping.
  5. Operate — upgrades, capacity reviews, incident support, maintenance windows, and platform improvements.

Normal change requests#

Use a planned request for new namespaces, ingress/DNS records, TLS changes, node pool changes, add-ons, policy changes, backup scope, or version upgrades. Emergency requests cover unavailable clusters, failed control plane operations, platform add-on outages, capacity exhaustion, and security events affecting covered services.

Getting started#