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

You might not need Kubernetes

blog.jessfraz.com

Post reply on HN
Print view View original

211–220 of 319 posts

Re: You might not need Kubernetes

#211

Post by Enginerd3 »

movedx wrote: post #192
Enginerd3 wrote: post #169

Earlier quoted context omitted.

"I figured some products would exist already to solve this problem, but I wanted to make my own." But why? You could've used so many different products. You could've even used Google Docs.

There's a bit more to the story than simply solving a problem. I have other plans for the software and we have ideas about how we want to move it forward. One of the key features is being able to "tag" an item on someone's wish list as "bought" or "buying". This allows others viewing the list to know that item has been taken. But there's also a requirement that the original author of the list/item cannot see that it…

Still, I highly doubt that there are not any apps that do this already. I mean, my family uses Amazon wish lists and set it so that you can't see when stuff is purchased.

Re: You might not need Kubernetes

#212

Post by movedx »

loftyal wrote: post #166
atleta wrote: post #16

Yeah, you probably don't. And not only that, but it probably makes your life harder. I've interviewed for a tech lead position at a company working with freelancers and I'm pretty sure the reason they ended up rejecting me was that I mentioned the technical interviewer that I think containers, container infrastructures (like Kubernetes) and even cloud infrastructure is being overused/used without giving too much thou…

Same with me, never had any interviewer actually give me an actual real rebuttal, other than "but it scales!!". I love software, but I really get tired of the blind cargo-cult culture of most of the industry.

I'm not an interviewer, but:

* Version controlled deployments of your application via K8s state files * Once an application is live, you can easily deploy a new version and have traffic drained over for you * Recovery of applications (Pods) that fall over * Automatic replacement of your application when a piece of hardware fails (K8s will see the Pod has died and bring it back up elsewhere) * You can use labels and other mechanisms to "slice up" your infrastructure for specific work loads * The underlaying hardware can be virtually anything: a high-end physical server, an EC2 instance or a RaspberryPi -- you just define the resources available and what your application needs, that it's placed on the right hardware for you * With a few Pods setup, you can have all the hosts and Pods on the cluster report their CPU, memory, disk, network, and other metrics, straight into a Prometheus instance and have Grafana dashboards up nearly instantly, for free (in virtually in senses of the word) * New Pods are automatically added to the above setup, too * Integration with Cloud providers (so for example creating a service endpoint and saying you want it to be public results in K8s provisioning a public facing load balancer and IP for you and managing that...) * Much more..

This is all instantly available straight out of the box within 15 minutes with Kops on AWS.

I'm not arguing that K8s is automatically the correct answer, but to assume it's not an answer at all based on the feedback from interviews is a poor reason to dismiss it.

It does have a place and it doesn't have to be hard.

Hopefully I've been constructive here.

Re: You might not need Kubernetes

#213

Post by radlad »

TheDong wrote: post #188
devhead wrote: post #181

Earlier quoted context omitted.

that's why you version pin and vet new updates before you let them in.

Okay, so walk me through how to do this in a dockerfile? My first line becomes: FROM debian@sha256:14e15b63bf3c26dac4f6e782dbb4c9877fb88d7d5978d202cb64065b1e01a88b Okay, that's easy. Now, what about older versions of packages in debian's apt repos that have been deleted? How do I get those? I run my own apt mirror I guess which I update in lock-step with my dockerfile and thus don't let the Dockerfile reach out to th…

A Dockerfile is an input which produces an image as an output. That image should not suffer from the bit rot examples you gave (e.g. "what about older versions of packages in debian's apt repos that have been deleted?")

However, when security patches are released, your image obviously will not contain them.

Re: You might not need Kubernetes

#214

Post by TheDong »

radlad wrote: post #213
TheDong wrote: post #188

Earlier quoted context omitted.

Okay, so walk me through how to do this in a dockerfile? My first line becomes: FROM debian@sha256:14e15b63bf3c26dac4f6e782dbb4c9877fb88d7d5978d202cb64065b1e01a88b Okay, that's easy. Now, what about older versions of packages in debian's apt repos that have been deleted? How do I get those? I run my own apt mirror I guess which I update in lock-step with my dockerfile and thus don't let the Dockerfile reach out to th…

A Dockerfile is an input which produces an image as an output. That image should not suffer from the bit rot examples you gave (e.g. "what about older versions of packages in debian's apt repos that have been deleted?") However, when security patches are released, your image obviously will not contain them.

I am not arguing that the docker image output is mutably changing. It is a good artifact that can be reproducibly run.

The comment I am originally replying to is 'docker image definitions are idempotent'. Note, 'image definitions', not 'images'.

My point has nothing to do with the image, but with the image definition itself.

Re: You might not need Kubernetes

#215

Post by wpietri »

taeric wrote: post #179
wpietri wrote: post #87

Earlier quoted context omitted.

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine. On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead…

I'm curious how docker will help with the "5 years on" problem. I'd be willing to place money saying your docker setup for this week will have trouble running "as is" next month. Especially true for the vast majority of one-offs out there.

For me it separates application environment issues from the machine issues. As an example, I have a daemon that runs my ambient home lighting: https://github.com/wpietri/sunrise

It has been running in a Docker container for a little over 4 years. Moving that from one machine to another was trivial. I didn't have to worry about language runtime or libraries or config files tucked away somewhere in /etc. I just told Kubernetes where to pull the image from and away it went.

That still leaves me with various problems building the app, as I needed to do when I made some configuration changes. But even there Docker was some help. The addition of multi-stage builds [1] means I can describe the build environment and the run environment in one file, giving me an easy way to have a repeatable build process.

Over time, my goal is set up all my home services similarly, so that when I decide to replace my current home server, there won't be a multi-day festival of "what the hell did I do in 2004 to get Plex working?" I'll bring up the new one, add it as a Kubernetes worker, and then kill the old server. I'm hoping it will also make me braver about upgrading server OS versions, as right now I'm pretty slack about that at home.

[1] https://docs.docker.com/v17.09/engine/userguide/eng-image/mu...

Re: You might not need Kubernetes

#216

Post by bitwize »

pathseeker wrote: post #153
bitwize wrote: post #65

Earlier quoted context omitted.

If you're buzzword compliant, you can fail forward. Your last product may not have worked out, but you've become an expert in Docker, Kubernetes, AWS, OpenShift, and Terraform which means that companies who are committed to the cloud (i.e., everybody) won't pass you over. Built an app that works before the cloud hype hit? Congratulations. You're a specialist in legacy technologies. We'll call you if we have a COBOL o…

No companies worth working for hire that way. What you are describing is a way to get jobs at startups or non-tech companies that don't have a good grasp on fundamentals.

When your only alternative is starving, you tend to adjust your expectations of a company "worth working for" downward. I've been faced with that alternative enough times in my life to think it wise not to rule out any options.

Re: You might not need Kubernetes

#217

Post by devhead »

TheDong wrote: post #188
devhead wrote: post #181

Earlier quoted context omitted.

that's why you version pin and vet new updates before you let them in.

Okay, so walk me through how to do this in a dockerfile? My first line becomes: FROM debian@sha256:14e15b63bf3c26dac4f6e782dbb4c9877fb88d7d5978d202cb64065b1e01a88b Okay, that's easy. Now, what about older versions of packages in debian's apt repos that have been deleted? How do I get those? I run my own apt mirror I guess which I update in lock-step with my dockerfile and thus don't let the Dockerfile reach out to th…

> Now, what about older versions of packages in debian's apt repos that have been deleted? How do I get those?

you can version pin your apt packages if you need to, i personally prefer the minor patches so i get my security updates. my build tool will catch if there's a bug affecting my software.

> Is this any different from what you do in a shell script on a server?

yes, because I can take that built image and deploy it to any host and all my developers get to all use the same one in their development. but hey, if you like building with shell, you could try out packer and run that shell script to create an image; which can safely be used on any host that supports docker or kub?

> I don't see how a docker image definition makes any of this easy. There's not even a flag to disallow network access during "docker build".

Easier depends on your goals and perspectives. For me, it's easier to write a docker file that installs what I need to run a service. Where bash doesn't have that, it's just a script that needs an environment to run. where do you run bash? is it locally on your OS with your packages with your settings and your needs? what happens when I run that bash script in a different OS? Who's going to debug that? Are you going to track your changes made in version control? how do you update the other servers/users who use your script? I got other fun things to do than worry about that.

Re: You might not need Kubernetes

#218

Post by wpietri »

jerf wrote: post #132
wpietri wrote: post #87

Earlier quoted context omitted.

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine. On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead…

"5 years on, I know that I did a bunch of things for a bunch of reasons, but I don't really remember what or why." For my home servers, I've settled on "a default install of distro $X and an idempotent shell script that sets everything up for me". You have to use discipline to do everything in the shell script rather than simply fix the problem, but if you can do that, you end up with documentation as to how your ser…

From my perspective, a Dockerfile already is an idempotent shell script that sets everything up for me. With the advantage that I can easily write and run tests for it that verify that the app comes up just fine.

The main struggle for me there is existing apps that weren't made with Docker in mind. There, using the OS install tools can me easier. But I think that's changing. The Docker Postgres images, for example, let you configure key things via simple environment variables: https://hub.docker.com/_/postgres/

So I expect that we'll continue to see more and more apps provide Dockerized versions, gradually chipping away at the advantage built up over the years by OS packaging.

Re: You might not need Kubernetes

#219

Post by spookthesunset »

mohaine wrote: post #44
frostyj wrote: post #13

Depends on the scale. If I only have 10 containers to manage I'd throw them on a m4 and let it be. Benefit of using k8s kicks in when your use case gets complicated.

This. At some point you get tried of trying to find an underutilized box to launch a new service. This is when you should start looking for something more complicated.

> This. At some point you get tried of trying to find an underutilized box to launch a new service. This is when you should start looking for something more complicated.

But that is the point of containers. To abstract away the need to worry about "finding underutilized boxes". The second you said "find an underutilized box" my mind went immediately to a pile of what I call "special snowflake" boxes. Each one is it's own unique thing. Symptoms usually include having cute names for each server instead of random, machine generated names. That shit is hard and expensive to maintain--especially in a fault tolerant way.

The best way to treat your infrastructure is to make it as ephemeral as possible. Absolutely any part of it should be able to go out of commission at any time and a new instance should go online to replace it.

If you are loading up multiple things onto a single m4 instance, I'm gonna say right now you are using AWS wrong....

Re: You might not need Kubernetes

#220

Post by ngrilly »

vidarh wrote: post #160
wpietri wrote: post #87

Earlier quoted context omitted.

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine. On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead…

You can put everything in containers and still not need much orchestration, though. My personal projects run in dozens of containers, and the "orchestration" consists of a Makefile include pulled into each project that creates a systemd service file based on some variables, and pushes it into the right place. The service files will pull down and set up a suitable Docker container. The full setup for a couple of dozen…

When you deploy a new version of a container, how do you avoid downtime? Do you start a new container running the new version, wait for the new container to be ready, switch traffic to the new container, stop traffic to the old container and drain connections, and then stop the old container?
Post reply on HN