Having set up Kubernetes to test, I'd say it's a bit less complicated than many people claim, though still obviously complex. I had a two-node cluster up and running in an hour using Flannel and Kismatic's prepackaged binaries for Debian/Ubuntu [1].
The biggest hurdle, ironically, is the official documentation, which seems to have been written by someone with no understanding of explaining things from first principles, or any talent for organizing ifnroamtion. You'd think the "setup from scratch" guide [2] would be the most detailed and useful for someone who wants to see how each piece fits into the next one, but it's actually terrible. It skips a lot of implicit information and makes some odd assumptions/suggestions. Almost every part of Kubernetes is multiple choice, which affects later steps. For example, if you use Flannel and you're not on GCloud, much of what Google's docs say about networking is moot.
Everything is also made harder by the fact that Kubernetes is changing awfully fast in non-backwards-compatible ways, and chances are that if you google some config problem, the answer is long out of date — the necessary kubectl option no longer exists or whatever. A lot of config recipes are useless now.
I set up Kubernetes on AWS, a staging and a production cluster. Staging had 1 master, 3 worker nodes, Production has 3 masters, 5 worker nodes, with two compute classes (fixed and burst, so pods could be scheduled to what was needed). All of this was on CoreOS, and included independent etcd clusters. So all total, we're talking 18 AWS EC2 instances. I put live users on it, with real traffic and tinkered with it as I learned things from a production workflow.
This was back in mid-2015, which meant figuring out things like how to get overlay networking with AWS's routing, fiddling with AWS's IAM settings, VPC settings, figuring out how to split the nodes across availability zones. This included integrating with AWS AutoScalingGroups to bring up new CoreOS/K8S nodes whenever something goes down. I never got EBS working as a Kubernetes volume type (at the time, you have to add hackish tools into CoreOS to detect unformatted EBS blocks and format them when they get mounted; forget it), but fortunately, used AWS RDS for persistent stores. Persistent storage is something I look forward to trying on GKE.
I could have tried creating CloudFormation scripts but I was making my way through documentation, blog posts, and Github issues to pull it all together. It was worth it when I was done.
I didn't say it was complicated. I said it was a pain in the ass, and it's something that Kubernetes developers have acknowledged and are working on it.
I'd be interested to see what you think of the CoreOS "step by step" guide that we've honed over the past few months, trying to strike a balance of explaining the background while keeping it as brief as possible:
The biggest hurdle, ironically, is the official documentation, which seems to have been written by someone with no understanding of explaining things from first principles, or any talent for organizing ifnroamtion. You'd think the "setup from scratch" guide [2] would be the most detailed and useful for someone who wants to see how each piece fits into the next one, but it's actually terrible. It skips a lot of implicit information and makes some odd assumptions/suggestions. Almost every part of Kubernetes is multiple choice, which affects later steps. For example, if you use Flannel and you're not on GCloud, much of what Google's docs say about networking is moot.
Everything is also made harder by the fact that Kubernetes is changing awfully fast in non-backwards-compatible ways, and chances are that if you google some config problem, the answer is long out of date — the necessary kubectl option no longer exists or whatever. A lot of config recipes are useless now.
[1] https://github.com/kismatic/repo_server/find/master
[2] http://kubernetes.io/docs/getting-started-guides/scratch/