Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes for Developers Who Know How to Develop

blog.ali.dev

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Kubernetes for Developers Who Know How to Develop

#71

Post by Tostino »

deckard1 wrote: post #31
JacobHenner wrote: post #19

Earlier quoted context omitted.

Not every org delegates these responsibilities to separate roles.

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…

Both of these articles were actually interesting to me as a dev who built a b2b SaaS company.

Re: Kubernetes for Developers Who Know How to Develop

#72

Post by moondev »

urthor wrote: post #56
vbezhenar wrote: post #21

Earlier quoted context omitted.

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 pr…

This is correct. K8s abstracted out containerization in preparation for the anticipated long term migration of the ecosystem to Podman et al (lots and lots of people are invested in moving "containers" away from "Docker").

I don't think podman is designed or supported as a CRI. It's for local development. You can create local "pods" without an API server, but not running containers on a real Kubernetes node. That would be containerd, crio, or cri-dockerd.

With that said I still prefer docker for local development by creating real ephemeral clusters with kind

Re: Kubernetes for Developers Who Know How to Develop

#74

Post by joshuak »

monkpit wrote: post #70
joshuak wrote: post #57

Earlier quoted context omitted.

The problem is that few people seem to understand the infrastructure as code concept, and essentially break the core k8s declarative architecture with imperative workflows that look just like the bash script install insanity we left behind. Workflows that are encouraged by tools like Helm and examples that create k8s objects on the fly without even creating much less retaining the "code" part of IaC. It turns a tool…

> IoC IaC?

Yes, fixed. Thank you

Re: Kubernetes for Developers Who Know How to Develop

#75

Post by moondev »

slimsag wrote: post #29
hujun wrote: post #28

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).

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.

The benefit of Kubernetes for most these days is the standardized api, not the ability to "webscale" although it certainly can. Google itself doesn't use k8s internally anyway - it uses borg. The CNCF oversees the Kubernetes project, not Google.

Re: Kubernetes for Developers Who Know How to Develop

#76

Post by cmehdy »

shepherdjerred wrote: post #38
rschachte wrote: post #15

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.

Do you think running k8s at home is worthwhile, past the learning experience and cool factor? I have a nice server that I used for 10-20 applications like Time Machine backup, media streaming, file syncing, home automation, etc. I was looking into k8s, but it seemed way too complicated when I only have one physical server, so I went with Docker + Docker Compose instead.

All the maintenance you put towards getting things running right now will be maintenance you put towards making sure your cluster is doing what you need and want.

If you start having more servers, a k8s cluster can do something like automatically transfer workloads when one machine has an issue for example, or dynamically allocating storage (even cloud) when needed, or allowing you to issue a single command to spin up more instance of whatever task you'd want to run more in parallel, or updating a version in a config file and letting the cluster do the job of stopping/updating/restarting things.

But what you also have to do is ensure the underlying networking between machines works, all versions of the binaries on all the machines of the cluster are in close agreement with each others, encryption of data via certificates and CAs is satisfactory, and your master(s) might require different maintenance from the workers - but you'll end up reading the docs to know how to roll updates step by step.

In your use case I would stick with a smart use of docker-composes, perhaps just centralized in a private repo, with cron jobs on top. If you buy/rent a couple machines of any kind (from raspberry pis to cloud instances) to put on your network and run things for you, then a cluster becomes increasingly interesting as the amount of tasks needed/wanted and amount of computing available grows.

My context: I have some limited experience with work (including some scary "abstractions" on top of K8s & Helm) and a recent CKA (certified kubernetes administrator hands-on certification) from LinuxFoundation.

Re: Kubernetes for Developers Who Know How to Develop

#77

Post by boloust »

yjftsjthsd-h wrote: post #43
boloust wrote: post #20

Earlier quoted context omitted.

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. Probabl…

> as out of the box you're still able to run docker containers. No, you're able to run containers from images produced by docker provided it exports them in OCI format. At no point does k8s see anything to do with docker. Saying docker when you mean container or container image is incredibly misleading at best, and less charitably, is just plainly wrong. Edit: Actually, it looks like if you want to add docker it's ea…

It seems like your view is informed from a cursory reading of the docs, rather than any first-hand experience.

Docker produces OCI images, there's no need to "export them" in that format.

So since Kubernetes can run any OCI image, and Docker images are OCI, Kubernetes supports running Docker images out of the box.

The documentation you linked to is if you wanted to swap out the container runtime Kubernetes is using, not if you just want to run a Docker image.

Re: Kubernetes for Developers Who Know How to Develop

#78

Post by joshuak »

ctroein89 wrote: post #69
joshuak wrote: post #57

Earlier quoted context omitted.

The problem is that few people seem to understand the infrastructure as code concept, and essentially break the core k8s declarative architecture with imperative workflows that look just like the bash script install insanity we left behind. Workflows that are encouraged by tools like Helm and examples that create k8s objects on the fly without even creating much less retaining the "code" part of IaC. It turns a tool…

Mind expanding a little on your complaints about Helm? I’ve only used Helm as a templating solution (and even then only to differentiate between local, staging and production), so I’m curious what problems I have to guard against.

Think of Kubernetes like a single application. The config files are the source for that application, the running cluster is the compiled application running on the users computer. By default Helm injects more "compiled" code unrelated to your applications source into the running application. Allowing any tool to alter active cluster state diffuses your single source of truth, your source code, to multiple sources of truth which will not remain in sync with your source unless great care is taken. Moving in sync matters, because that is how you roll back to a known good state when things break.

If you are using Helm to generate source code for your application you still have the added complexity of additional build step, but at least you can choose to add the generated code to your app in a way that tracks with the rest of your code.

Also most Helm chart authors are of varying skill level, and even skilled ones necessarily make incorrect assumptions about your deployment environment. It takes a lot of addition code in helm charts to support more flexibility, so it often get ignored, and you are left with a black box that doesn't quite do what you'd want it to do.

Post reply on HN