5 ms·

As a Kubernetes outsider, I get confused why so much new jargon had to be introduced. As well as so many little new projects coupled to Kubernetes with varying

As a Kubernetes outsider, I get confused why so much new jargon had to be introduced. As well as so many little new projects coupled to Kubernetes with varying degrees of interoperability. It makes it hard to get a grip on what Kube really is for newcomers. It also has all the hallmarks of a high-churn product where you need to piece together your solution from a variety of lower-quality information sources (tutorials, QA sites) rather than a single source of foolproof documentation.

sidlls 5y ago
> I get confused why so much new jargon had to be introduced. Consider the source of the project for your answer (mainly, but not entirely, bored engineers who are too arrogant to think anybody has solved their problem before). > It also has all the hallmarks of a high-churn product where you need to piece together your solution from a variety of lower-quality information sources (tutorials, QA sites) rather than a single source of foolproof documentation. This describes 99% of open source libraries used.The documentation looks good because auto doc tools produce a prolific amount of boilerplate documentation. In reality the result is documentation that's very shallow, and often just a re-statement of the APIs. The actual usage documentation of these projects is generally terrible, with few exceptions.
- nhooyr 5y ago
  I find it's low quality libraries that tend to have poor documentation. Perhaps that's 99% of open source libraries.
- joshuamorton 5y ago
  > Consider the source of the project for your answer (mainly, but not entirely, bored engineers who are too arrogant to think anybody has solved their problem before). This seems both wrong and contrary to the article (which mentions that k8s is a descendant of Borg, and in fact if memory serves many of the k8s authors were borg maintainers). So they clearly were aware that people had solved their problem before, because they maintained the tool that had solved the problem for close to a decade.
- parasubvert 5y ago
  Kubernetes docs are pretty good, detailed, and kept up to date - a lot more than just API auto-documentation.
a_square_peg 5y ago
I think one part of this the lack of accepted nomenclature in CS - naming convention is typically not enforced, unlike if you'd have to produce an engineering drawing for it and have it conform to a standard. For engineering, the common way is to use a couple of descriptive words + basic noun so things do get boring quite quickly but very easy to understand, say something like Google 'Cloud Container Orchestrator' instead of Kubernetes.
- oalae5niMiel7qu 5y ago
  If only branding wasn't involved.
diminish 5y ago
I second this. I like "silent" new tech, which doesn't need to introduce dozens of new "concepts". - containers focus on what you can do, easy to understand and you can start in 5 minutes - kubernetes is the opposite, where verbose tutorials lose time explaining me how it works, rather than what i do with it.
parasubvert 5y ago
The Kubernetes documentation site is the source of truth, and pretty well written, though obviously no set of docs is perfect. The concepts and constructs do not usually change in breaking ways once they reach beta status. If you learned Kubernetes in 2016 as an end user, there are certainly more features but the core isn’t that different.
sevagh 5y ago
I always find it surprising that I have yet to see or touch Kubernetes (and I work as an SRE with container workloads for several years now), and yet HN threads about it are full of people who apparently think it's the only possible solution and are flabbergasted that people don't pray to it nightly. https://news.ycombinator.com/item?id=27910185 https://news.ycombinator.com/item?id=27910185 https://news.ycombinator.com/item?id=27910481 https://news.ycombinator.com/item?id=27910481 - weird comparison to systemd https://news.ycombinator.com/item?id=27910553 https://news.ycombinator.com/item?id=27910553 - another systemd comparison https://news.ycombinator.com/item?id=27913239 https://news.ycombinator.com/item?id=27913239 - comparing it to git

sidlls 5y ago

> I get confused why so much new jargon had to be introduced. Consider the source of the project for your answer (mainly, but not entirely, bored engineers who are too arrogant to think anybody has solved their problem before). > It also has all the hallmarks of a high-churn product where you need to piece together your solution from a variety of lower-quality information sources (tutorials, QA sites) rather than a single source of foolproof documentation. This describes 99% of open source libraries used.The documentation looks good because auto doc tools produce a prolific amount of boilerplate documentation. In reality the result is documentation that's very shallow, and often just a re-statement of the APIs. The actual usage documentation of these projects is generally terrible, with few exceptions.

nhooyr 5y ago
I find it's low quality libraries that tend to have poor documentation. Perhaps that's 99% of open source libraries.
joshuamorton 5y ago
> Consider the source of the project for your answer (mainly, but not entirely, bored engineers who are too arrogant to think anybody has solved their problem before). This seems both wrong and contrary to the article (which mentions that k8s is a descendant of Borg, and in fact if memory serves many of the k8s authors were borg maintainers). So they clearly were aware that people had solved their problem before, because they maintained the tool that had solved the problem for close to a decade.
parasubvert 5y ago
Kubernetes docs are pretty good, detailed, and kept up to date - a lot more than just API auto-documentation.

a_square_peg 5y ago

I think one part of this the lack of accepted nomenclature in CS - naming convention is typically not enforced, unlike if you'd have to produce an engineering drawing for it and have it conform to a standard. For engineering, the common way is to use a couple of descriptive words + basic noun so things do get boring quite quickly but very easy to understand, say something like Google 'Cloud Container Orchestrator' instead of Kubernetes.

oalae5niMiel7qu 5y ago
If only branding wasn't involved.

diminish 5y ago

I second this. I like "silent" new tech, which doesn't need to introduce dozens of new "concepts". - containers focus on what you can do, easy to understand and you can start in 5 minutes - kubernetes is the opposite, where verbose tutorials lose time explaining me how it works, rather than what i do with it.

parasubvert 5y ago

The Kubernetes documentation site is the source of truth, and pretty well written, though obviously no set of docs is perfect. The concepts and constructs do not usually change in breaking ways once they reach beta status. If you learned Kubernetes in 2016 as an end user, there are certainly more features but the core isn’t that different.

sevagh 5y ago

I always find it surprising that I have yet to see or touch Kubernetes (and I work as an SRE with container workloads for several years now), and yet HN threads about it are full of people who apparently think it's the only possible solution and are flabbergasted that people don't pray to it nightly. https://news.ycombinator.com/item?id=27910185 https://news.ycombinator.com/item?id=27910185 https://news.ycombinator.com/item?id=27910481 https://news.ycombinator.com/item?id=27910481 - weird comparison to systemd https://news.ycombinator.com/item?id=27910553 https://news.ycombinator.com/item?id=27910553 - another systemd comparison https://news.ycombinator.com/item?id=27913239 https://news.ycombinator.com/item?id=27913239 - comparing it to git