I built an on-premises Kubernetes environment on VMware for a customer that previously used Kubernetes elsewhere. The platform is intended to support highly available containerized microservices as they move away from monolithic containers and virtual machines. I've become the de facto system owner because the other administrators have little interest in learning Kubernetes, although the application development team is expected to use it.
I've encouraged the developers to learn about pod replicas for availability and load balancing, along with taints and tolerations so workloads can remain available during automated node patching. I'm also planning to implement a management platform, but a CI/CD solution has not been approved yet.
What would be the best way to make this environment approachable for developers and system administrators who do not want to learn kubectl or container tooling in depth? Should I focus on a graphical management layer, GitOps, training, or something else?
5 Answers
Look into GitOps rather than waiting for a traditional CI/CD platform. A tool such as Flux can reconcile manifests from version control, provide an audit trail, and make deployments repeatable. Pair that with reusable Helm charts or application templates so teams change a few documented values instead of writing every manifest from scratch.
Be careful not to make replicas, taints, and tolerations the developers’ first concern. Those are useful, but the platform team should provide safe defaults and enforce policies where possible. Teach application teams the parts they own—resource requests and limits, readiness and liveness probes, graceful shutdown, persistent storage, configuration, and failure testing—while keeping node maintenance and cluster operations centralized.
Start with the teams’ actual operational problems rather than presenting Kubernetes as the solution to everything. If high-availability container orchestration is genuinely required and the developers are committed to using it, define a small supported platform and make the common workflows easy. Give them documented deployment templates, examples, resource defaults, health checks, replica guidance, upgrade procedures, and clear ownership boundaries.
The customer specifically requested the platform and is moving from non-HA monolithic workloads and VMs to highly available microservices, so the main challenge is making the transition manageable for the teams.
A self-service graphical interface can reduce the amount of Kubernetes knowledge people need for routine work. Developers could use it for viewing applications, checking rollout status, reading logs, and restarting or scaling workloads, while administrators retain control over cluster-wide settings. Just make sure the interface complements good standards instead of hiding problems that users eventually need to understand.
A simpler application-focused view is especially useful for getting people comfortable with the platform before asking them to learn every kubectl command and Kubernetes concept.
The biggest risk is making one person permanently responsible for the whole platform. Establish an operating model early: who owns the cluster, who owns namespaces, who handles incidents, what support is provided, and what applications must meet before deployment. Hands-on workshops and a small pilot application will usually work better than expecting every administrator to become a Kubernetes expert immediately.
GitOps is a helpful direction, and I’ll evaluate Flux along with the management tooling.