Hacker News Reader

Comment by cygned | Hacker News Reader

I am a developer and I find k8s frustrating. To me, its documentation is confusing and scattered among too many places (best example: overlay networks). I have read multiple books and gazillions of articles and yet I have the feeling that I am lacking the bigger picture.

I was able to set it up successfully a couple of times, with more or less time required. Last time, I gave up after four days because I realized that what I need was a "I just want to run a simple cluster" solution and while k8s might provide that, its flexibility makes it hard for me to use it.

View on HN

Have you used other google products? I find their documentation routinely incomprehensible and difficult.

Agreed! I am an engineer and have written documentation off and on throughout my career. I'm continuously dismayed at the incomprehensible documentation generated by most companies. Google's documentation is particularly bad though.

I have a theory that the type of people who make it past the google interview are smart people who are bad at teaching. Like they get all the concepts, algos etc.. but when it comes to distilling it into an Explain-Like-Im-5 tutorial, it just goes to hell very quickly.

What they need to do is hire some people who are great teachers, explainers etc.. Avoid people who rely on already attained technical knowledge, design patterns, algos etc.. to pattern match on new tech to instantly grok it. The 'noob' people who question the engineers who designed the tools and ask a ton of dumb questions about how it works so they can then translate it into everyday tutorial paragraphs.

Kubernetes has always had an identity crisis.

Who is aimed at, app developers or platform operators? Clear, obvious contracts between the two roles are valuable, even if you decide to combine them.

I'm moderately hopeful that Knative will help in that regard, as it is more conclusively oriented towards the developer. But I am wary that since it leaves the implementation details completely visible, it may not achieve that goal.

Disclosure: I work for Pivotal, we have products based on both of these.

Achieving that is a difficulty task, though. Personally, I’d not like to rely on an abstraction on top of a system with that level of complexity for production because I expect to run into situations that can only be solved with deep knowledge of k8s.

I feel like this separation is achievable, if only because it's been achieved several times already.

Google App Engine did it. Heroku did it. Cloud Foundry did it. In none of these situations does an app developer need to know or care how the bits are plumbed, they only need to enjoy hot and cold running code.

> app developers or platform operators

Definitely not the former. The YAML-based configuration is not a pleasant app deployment experience. Companies end up needing to do some sort of auto-generation for it to make it sane for app devs.

App developers want experiences similar to heroku. They want to git push and have applications safely roll out without downtime or configuration.

I’m a little behind on Cloud Native adoption so I gotta ask - what’s preventing a “git push to heroku” from being the norm here? Are we using the wrong abstractions? Or are the abstractions still too low?

...why is Heroku/buildpack not running away with it?

Personally, I stopped using Heroku because it is more expensive than manually deploying to something like Digital Ocean. I also found dealing with third-party services that were here today and gone tomorrow a little irritating. Maybe things have improved recently. I haven't used Heroku for a few years.

The main alternative was and still is Cloud Foundry (by way of disclosure, I've been in and around CF for years). But it's always been pitched to enterprise customers and approximately zero effort has ever been made to expand awareness outside that world. Kubernetes had Google's massively powerful halo blowing in its sails.

> ...why is Heroku/buildpack not running away with it?

I predict that buildpacks are going to make a big comeback, because they make everything about Day 2 much easier. Pivotal and Heroku have been cooperating on the Cloud Native Buildpacks[0] spec under the CNCF sandbox process. There is some seriously cool stuff coming down the pipe.

[0] https://buildpacks.io/

My team has configured gitlab with post-commit hooks so that pushes to dev branch get compiled/packaged/deployed to the dev environment with a simple git push.

Also, I don't find YAMLs bad for deployment.

There's no question that you can build higher-level deployment strategies on top of the system (or any other system). It's just not baked in.

Also, YAML in general is not a bad thing, but kubernetes presents you with a ton of boilerplate and a complicated DSL. There's a lot of rough edges (annotations don't get validated, for example).

Kelsey has the answer for you: "Kubernetes is a platform for building platforms. It's a better place to start; not the endgame." (https://twitter.com/kelseyhightower/status/93525292372179353...)

As an application developer, you probably also don't work with the Kernel and syscalls directly (anymore), so I guess you can expect higher abstractions and a smoother experience for Kubernetes in the future.

Kubernetes doesn't specify anything about overlay networks. That's up to the CNI provider. Are you referring to flannel's documentation?

Perhaps there is a good plural sight course? Sounds like a tech you have to invest many hours to learn.

Reply on news.ycombinator.com