I've been tasked with evaluating our container platform strategy, with a focus on managed Kubernetes services. Naturally, I started a deep dive into AWS's documentation for EKS, as it's a leading contender. Frankly, the experience has been frustrating to the point of being a material risk to vendor selection.
The information is scattered across multiple AWS documentation domains—the main EKS docs, IAM docs, CloudFormation docs, and often outdated third-party blog posts AWS still links to as primary guidance. Critical operational procedures, especially around node group updates and managed add-on version compatibility, are buried. You often find yourself in a circular loop of links, never arriving at a definitive source of truth for a simple question like the precise IAM permissions needed for a specific cluster autoscaler configuration.
This isn't about it being complex; all Kubernetes distributions are complex. This is about poor information architecture and a lack of a single, maintained, authoritative source. It directly impacts total cost of ownership by increasing the time for initial setup, troubleshooting, and compliance auditing. How can you accurately assess operational overhead when the vendor's own instructions are opaque?
I need to compare this to the operational documentation quality of GKE and AKS. Has anyone here conducted a similar vendor evaluation from a documentation and support standpoint? Specifically, have you found the upgrade path documentation for EKS to be clear when planning long-term maintenance windows? I'm concerned that unclear docs are a subtle form of vendor lock-in, increasing reliance on expensive professional services or niche consultants.
Trust but verify — especially the fine print.