Convergence to Kubernetes • Hacker News Board

Re: Convergence to Kubernetes

#121

Post by manigandham » Wed, Jun 27, 2018, 6:17 AM UTC

mmt wrote: post #117

manigandham wrote: post #116

Earlier quoted context omitted.

Kubernetes is a solution for 90% of the effort and services needed for distributed apps running and interacting with each other over a cluster of servers. Those accessory services aren't abstracted, I never used that word. They are instead provided out of the box by K8S, leading to fewer individual components to run, maintain and monitor yourself. You can switch out components at any level, from a single container ru…

> They are instead provided out of the box by K8S, leading to fewer individual components to run, maintain and monitor yourself. You can switch out components at any level, from a single container running your favorite webserver, to a full service mesh, to your own custom controllers. Fair enough, though I was misled by the word "replaces", which, to my mind, means something different than merely providing out of the…

"removes ops overhead" is about K8S, not containers. Less stuff in a container on a bare VM means less to manage and maintain, thus easier.

I don't get your point in "considering the future" - what are you saying exactly? Yes people should plan for it. You have to be competent enough to do that, and if you're not then that's a different discussion.

However, even if you have a poor team, then Kubernetes still helps because it's well designed, flexible, reliable, and can grow with your business. As stated, it's incredibly customizable. The entire system is designed around interfaces, like the CRI for container runtimes, CNI for networking, CSI for storage, and more. In fact the extensibility APIs like metacontrollers and CRDs are so powerful now that some of the main primitives (like StatefulSets) can even be recreated in just a few lines of code.

Given that, your question of "what if we succeed" (which must be tempered by the fact that very few need high scale, and fewer still will outgrow the capabilities of K8S) is answered by "you upgrade the things you need". It really is that simple. Kubernetes is well-designed, documented, battle-tested, and supported by a large community and major vendors, so it's a better choice for both early and late stage deployments.

Considering the major investments by every cloud vendor and the benefits detailed by hundreds of companies both large and small, I believe this has proven itself beyond just a hype cycle.

Re: Convergence to Kubernetes

#122

Post by erik_seaberg » Wed, Jun 27, 2018, 6:19 AM UTC

de_watcher wrote: post #102

jrs95 wrote: post #26

Earlier quoted context omitted.

You probably shouldn’t be using Ubuntu base images anyways. The closer you can get to “scratch” the better, and the fewer security related issues you’ll have. For most use cases I think Alpine is a much better base image.

That's more about trust and faith in the maintainers of the distribution (that they won't screw up).

This. If you start adding stuff to "FROM scratch", you are creating your own obscure Linux distro. When you screw up, there are no other customers to report bugs to you, much less other maintainers to help.

Re: Convergence to Kubernetes

#123

Post by jrs95 » Wed, Jun 27, 2018, 7:47 PM UTC

erik_seaberg wrote: post #122

de_watcher wrote: post #102

Earlier quoted context omitted.

That's more about trust and faith in the maintainers of the distribution (that they won't screw up).

This. If you start adding stuff to "FROM scratch", you are creating your own obscure Linux distro. When you screw up, there are no other customers to report bugs to you, much less other maintainers to help.

You really shouldn't be adding stuff to "FROM scratch" unless you have one statically linked binary and maybe some config files or something like that. If you actually need packages, you should use something like Alpine if possible.

Re: Convergence to Kubernetes

#124

Post by nh2 » Thu, Jun 28, 2018, 2:13 AM UTC

TheDong wrote: post #39

nh2 wrote: post #16

Earlier quoted context omitted.

> don't routine security updates mean you're constantly rebuilding and redeploying these images? It means you should be constantly rebuilding and redeploying these images. The fewest people I've seen use Docker actually do that. The answer I've heard most commonly so far is "uh hmm ... right, given that I see new CVEs fixed every day, scrolling by in the `apt-get dist-upgrade` I do daily on my desktop, we should prob…

> At the time of writing, every single image is labelled with "This image has vulnerabilities". The majority of those are not applicable in any way to your average container. I would highly encourage you to not attempt to make points off such bad data. See below for why I think it's bad data. I'd also like to point out that those CVEs are even more of a pointless thing to make such a point with since almost all of th…

You are are right with all you're saying here.

I was not suggesting that `docker build` executed at a given time point is less secure than `unattended-upgrades`. My point in referencing the vulnerabilities was to simply show that there is a constant stream of vulnerabilities that you need to keep patching, and that picking a new base image "every now and then" isn't enough. `unattended-upgrades` just makes it trivial to automate following this constant stream of updates, while with Docker you have to manage that yourself.

Yes, most CVEs don't affect your use case and operations, independent of via Docker or full OSs. But every now and then there is a severe CVE in that stream that affects you. You don't know when it's coming.

There are two ways to be safe: Automatic upgrades, or reading through / subscribing to the CVE stream and analysing everything that passes by (as you demonstrated here; that takes real effort and you need to be awake when it happens). Most people don't do the latter.