[HN Gopher] Kubernetes for Developers Who Know How to Develop
___________________________________________________________________
Kubernetes for Developers Who Know How to Develop
Author : EntICOnc
Score : 55 points
Date : 2022-07-24 19:21 UTC (3 hours ago)
(HTM) web link (blog.ali.dev)
(TXT) w3m dump (blog.ali.dev)
| daenz wrote:
| I'm going to post my unsolicited opinion about K8s here, as an
| SWE+SRE who used it heavily for about 1.5 years on GCP.
|
| It's a very cool system. I completely understand why people half-
| jokingly call it a "distributed operating system." It does a lot
| of things related to the lifecycles of various state (secrets,
| storage, config, deployments, etc).
|
| However, I believe it goes way too far into putting
| infrastructure into non-cloud-managed state machines. Things that
| exist in most modern clouds are being _reinvented_ in K8s. What
| 's more, is that K8s objects are being created as interfaces to
| the underlying cloud objects. So you now have 2 layers of
| abstractions, each with their own quirks. It's too much.
|
| Not to mention that IaC for K8s is extremely immature. This will
| improve, yes, for some definition of "improve." But if you've
| ever written Helm charts that integrate with Terraform, you'll
| know about all the spinning plates you have to keep balanced.
|
| It's not a system I see sustaining into the long term future.
| Google may continue to use and support it forever, but afaik,
| they are the most invested in its success. Other cloud platforms,
| like AWS, seem to be focusing on not re-inventing all of their
| cloud offerings in K8s.
| osigurdson wrote:
| >> Things that exist in most modern clouds are being reinvented
| in K8s
|
| The market wants cloud computing to be a commodity. I expect it
| will get what it wants via k8s or some other technology.
| moritonal wrote:
| In case you didn't know of it, for IaC, CDK8S has worked very
| well for me.
| cheriot wrote:
| > Things that exist in most modern clouds are being reinvented
| in K8s.
|
| My more optimistic view is that vendor specific APIs are being
| standardized. Initial implementations have their issues, but as
| more people use them the cloud vendors will improve their
| offering.
| doliveira wrote:
| You know the mountains of legacy code locked in to Oracle
| stuff? The way I see it, k8s is the way for us to avoid making
| the same mistake with AWS.
|
| At the very least we can actually simulate our stack locally.
| hujun wrote:
| the problem I have with k8s or whole concept of "cloud native" is
| it almost ONLY focus on web based application, if your
| application is not HTTP based or "stateless", it is very hard to
| run or design to be "cloud native" , specially in a managed k8s
| service(like eks/aks).
| slimsag wrote:
| If you want highly scalable at Google's scale, HTTP-based
| stateless services that can be scaled up/down in response to
| traffic are highly desirable properties.
|
| The real problem is k8s and "cloud native" are designed for
| Google's scale, not yours.
| CameronNemo wrote:
| Can you tell me what specific challenges you've had with
| deploying non-HTTP services using Kubernetes? Many features are
| http-centric, but others seem fairly agnostic to me. What kind
| of non-http services are we talking about anyway?
| JanMa wrote:
| Why does everyone keep thinking developers need to now about K8S?
| Just be glad if your infra/DevOps/platform teams abstract this
| away from you and you don't have to deal with this insanity.
| JacobHenner wrote:
| Not every org delegates these responsibilities to separate
| roles.
| deckard1 wrote:
| if you're at the size of needing K8S, you can afford a
| devops/cloud engineering team.
|
| To OP's point, this seems to be a trend among corporate
| blogs. Targeting devs with irrelevant content. A few weeks
| back I remember seeing a "SOC 2 for devs" blog article and
| was really scratching my head. That's not the level that devs
| work at, at all. If you're paying six figure salaries to devs
| to sit around all day worrying about overweight bureaucratic
| nonsense, or other tasks way beyond their expertise, then
| you're doing it wrong. I'm guessing these orgs think devs has
| some decision making influence or perhaps it looks good for
| recruiting? Or maybe they just want that HN juice. What next,
| I wonder? Neurosurgery for devs?
| dingleberry420 wrote:
| No. Kubernetes is extremely valuable to small orgs. Google
| Kubernetes Engine is pretty much fire & forget. You turn it
| on, set the maintenance window and it just works. It also
| saves you from having to reinvent health checks, ingresses,
| etc. It's actually less work than maintaining plain old
| servers when you factor in maintenance, and since state is
| immutable you don't run into issues where some developer
| fixed an issue 3 years ago and no one knows why it works.
| EddySchauHai wrote:
| What's SOC 2? Security Operations Center?
| dingleberry420 wrote:
| It's laughable to think every small company has
| infra/DevOps/platform teams.
|
| Also, in general, it's very useful to know the platform your
| software is going to be deployed to, so that you can design the
| software with those constraints in mind.
| ForHackernews wrote:
| Kubernetes was a clever ploy to trick cloud providers into
| abstracting themselves into irrelevance, but otherwise a dead
| end. Can we please hurry up and replace it with an open-source
| Nomad clone?
| vbezhenar wrote:
| IMO Kubernetes is not going anywhere. People are jumping to it
| in huge numbers. It's very hot. It has sane architecture in my
| opinion. I'd say it has awesome architecture and I have great
| respects to the ones responsible for it. They've got very
| quality foundations. Kubernetes is new Linux. You expected to
| know Linux and Git, now you'll be expected to know Kubernetes
| if you're developer.
| rschachte wrote:
| I've been working on a Kubernetes cluster for my home network. I
| know a lot of people hate on Kubernetes, but it's pretty cool and
| not too bad to even get started from scratch with Kubeadm.
|
| I think the constant thought in the back of my mind is... Docker
| containers and Nginx is definitely enough for my needs. At work,
| it's a different story, but more most things, it can be over
| kill.
| vbezhenar wrote:
| My biggest issue with Kubernetes is huge costs of running it.
| It's 3 servers with 4 GB RAM. It's almost $100/month just for
| Kubernetes alone. And you need one load balancer for control
| nodes which is another $25 for my hoster. And you need second
| load balancer for production workloads which is another $25. So
| you have to pay $150/month for the privilege of using
| Kubernetes. And they double your costs for your application,
| because you want it to be high-available, why bother with
| Kubernetes otherwise.
|
| So something that could be run with $5 droplet, suddenly
| requires $200.
|
| They you want to install grafana, ELK, service mesh and
| whatnot.
| tux3 wrote:
| k3s will run on a $5 droplet happily. If you want k8s for the
| yaml and not for the heavy-duty hyperscale redundancy, k3s
| works great
| 0x006A wrote:
| What part makes this for developers and what are developers that
| don't know how to develop?
| birdyrooster wrote:
| Probably a joke for all those software engineers that don't do
| anything.
| politelemon wrote:
| I've read through twice and I cannot see the relationship
| between the title and the contents.
| Izkata wrote:
| It's the part where it explains the "what" and "why" but
| skips the "how" under the assumption someone who knows how to
| develop just needs a hook to relate it to what they already
| know, and can then learn on their own.
| embik wrote:
| > Kubernetes x Docker: Best Friends Forever
|
| > Whenever you hear Kubernetes, you're probably going to hear
| Docker in the same sentence. Kubernetes and Docker are like
| peanut butter and jelly--they're a perfect pair.
|
| For what it's worth, this article was originally written in
| October 2021, but even at that point it was clear that Kubernetes
| would remove support for docker. In fact it has already with
| Kubernetes 1.24. Not exactly "Best Friends Forever". I wish
| people writing this kind of introductory blog posts would take
| the time and just quickly explain container runtimes instead of
| just mentioning docker and be done with it.
| altdataseller wrote:
| Does this apply to GKE? Are they going to remove support for
| Docker as well (or did they?)
| embik wrote:
| They have, with 1.24[1], following Kubernetes upstream. If
| you are an end user nothing is really going to change from
| this though, because docker produces container images that
| can be used in other container runtimes (and in fact,
| containerd is what powers docker underneath today anyway).
| But that's why it's so important to explain that containers
| != docker, otherwise "removing docker support" seems really
| scary.
|
| [1] https://cloud.google.com/kubernetes-
| engine/docs/deprecations...
| georgyo wrote:
| > They have
|
| The question was did they remove support for docker. They
| have not.
|
| They simply removed dockershim and no longer special case
| it.
|
| Your point is that we should stop using a brand name to
| describe OCI open standard containers. However, like
| aspirin, the names are interchangable for the vast majority
| of people.
|
| OCI container doesn't really roll off the toung, and
| container by itself could mean all sorts of things.
|
| Docker is really the best word to describe what people are
| thinking about it every day conversation. So much so that I
| think they are at risk of loose their trademark.
| embik wrote:
| > The question was did they remove support for docker.
| They have not.
|
| Have they not? Note that the GP asked for GKE
| specifically. The support page I linked to literally says
| so:
|
| > GKE will stop supporting node images that use Docker as
| the runtime in GKE version 1.24 and later
|
| Removing dockershim removed the existing support for
| docker, because docker does not support CRI (Container
| Runtime Interface), the API required by Kubernetes. You
| can go through a third-party solution that adds CRI
| support on top of docker, but most managed Kubernetes
| offerings simply removed docker support.
|
| I don't see any argument supporting the claim that docker
| is the "best word" to describe containers. I am also not
| aware of ambiguity for the term "(Linux) container" when
| it comes to operating/deploying software. What else does
| it mean in that context?
| boloust wrote:
| Saying "Kubernetes has removed support for Docker" is
| incredibly misleading at best, and less charitably, is
| just plainly wrong.
|
| While it's true that 1.24 does not support docker as the
| specific container runtime that's directly used by
| Kubernetes itself, this has approximately zero impact on
| how the vast majority of beginners would use Kubernetes,
| as out of the box you're still able to run docker
| containers.
|
| Probably not the kind of confusing detail that needs to
| be in an intro to Kubernetes article.
| georgyo wrote:
| The install instructions still explicitly lists docker
| engine as container runtime.
|
| https://kubernetes.io/docs/setup/production-
| environment/cont...
|
| The dockershim removal FAQ says how to continue to use
| docker engine.
|
| https://kubernetes.io/blog/2022/02/17/dockershim-faq/
|
| -- Linux container could be LXC, systemd-nspawn, snap,
| flatpak, nixos-container, and many many many other
| things.
|
| That's because Linux containers are built on Linux
| interfaces, but Linux itself does not have any
| prescriptive requirements on how to stich them together.
| gerwim wrote:
| While you are technically correct, kubernetes removed the
| Dockershim. Docker is often used as a synonym for containers.
| However, most of the things should still work [1].
|
| [1]: https://kubernetes.io/blog/2020/12/02/dont-panic-
| kubernetes-...
| embik wrote:
| I am very much aware of this, but that's exactly what I am
| arguing. Articles setting out to explain Kubernetes should
| not perpetuate the false equality of docker and containers.
| yonixw wrote:
| If you use `docker build/run` in your bash, it will
| actually be more confusing IMO saying k8s "dropped
| docker(shim) support". This fact should be a footnote for
| the curious reader, surely on an introduction article.
| stetrain wrote:
| > remove support for docker
|
| So I can't use Dockerfiles and `docker build` to build things
| for k8s?
| vbezhenar wrote:
| This is not correct.
|
| Kubernetes used docker engine under the hood in the past. Now
| they abstracted useful part of this engine into API. There's
| implementation from the docker (containerd), there's
| implementation from Redhat (CRI-O), may be others. Docker
| don't have to be installed for Kubernetes to work anymore.
|
| Building container images is a different topic. Kubernetes
| does not have anything to offer here. So you probably still
| need docker in your development machine and in your CI
| pipeline to build those images. There are plenty of
| alternatives rised in recent years, most prominent ones are
| kaniko, buildah/podman, but they're far from docker in their
| maturity.
|
| That actually makes a problem. It's hard to run docker and
| kubernetes side-by-side. Or docker inside kubernetes. So if
| you want to run your CI jobs inside Kubernetes, there's no
| good solutions right now.
|
| I think people will eventually migrate to Kaniko. It's from
| Google, it seems to be a sane approach. But right now it's a
| mess.
___________________________________________________________________
(page generated 2022-07-24 23:00 UTC)