I built an on-premises VMware-based Kubernetes platform at a customer's request. The customer previously used Kubernetes, and the new environment is intended to support a move from non-HA monolithic containers and virtual machines toward highly available microservices. I've become the de facto system owner because the other administrators have limited interest in learning Kubernetes, while the application team is willing to use it but still needs guidance.
I've encouraged the developers to research pod replicas for availability and load balancing, along with taints and tolerations so workloads can remain available during automated maintenance and patching. I'm also considering a centralized management tool, but there is currently no approved CI/CD platform.
What would be the best ways to make the platform approachable for developers and system administrators who don't want to become experts in kubectl, container tooling, and Kubernetes internals? Would GitOps, a developer-friendly dashboard, or another operating model be a good starting point?
4 Answers
Since the environment was specifically requested and the development team has bought in, focus on adoption instead of trying to train the whole organization at once. Run a small pilot with one application, turn the successful setup into a reusable reference architecture, and offer short hands-on sessions based on real tasks.
For the other administrators, provide runbooks for patching, upgrades, access management, backups, incident response, and common failures. A managed control plane or centralized management product may reduce the learning curve, but it won’t replace clear operational ownership and documentation.
Start with the problems the platform is meant to solve and define what each team actually needs to manage. Kubernetes can provide highly available container orchestration, but users still need clear ownership boundaries, documented workflows, standard templates, and sensible defaults.
For automation, look into GitOps rather than treating CI/CD as the only option. A tool such as Flux can continuously reconcile the cluster with configuration stored in version control. That gives administrators an auditable change process without requiring everyone to operate the cluster directly.
Don’t expect every developer or administrator to become a Kubernetes expert. Provide a supported application path with templates for deployments, services, probes, resource requests and limits, replica counts, disruption budgets, configuration, and secrets. Then document which settings users may change and which remain owned by the platform team.
A simple web interface can also help teams view applications, inspect deployments, and perform routine actions without memorizing kubectl commands. Just make sure it complements good access controls and does not hide important operational behavior.
Be careful not to equate replicas and taints with complete high availability. Replicas help only when workloads are spread across failure domains, and the applications need health checks, graceful shutdown, suitable storage, and enough capacity. Use scheduling rules, topology spread constraints, pod disruption budgets, and maintenance procedures so upgrades don’t remove every instance at once.
It’s also worth agreeing with the application team on service ownership, recovery objectives, monitoring, logging, and on-call responsibilities. The platform can provide the mechanisms, but the application team still needs to make its services resilient.
That makes sense. I’m planning to start with a pilot application and turn the deployment, maintenance, and troubleshooting steps into a standard workflow before expanding access.