Live data from Hacker News

Kubernetes for personal projects? No thanks

carlosrdrz.es

241–250 of 278 posts

Re: Kubernetes for personal projects? No thanks

#241
post #87

I start using Kubernetes with gitlab months ago with the free account. Today i'm using it for a side project. I never used kubectl since then. the project is very simple but still it is split into 3 different repos (all connected to the same cluster). Even if the documentation is not clear about how to connect different repos to the same cluster, after a couple of hours i had to click some buttons in the gitlab inter…

Hello, Community Advocate from GitLab here.

We are glad to hear that you like using GitLab!

Regarding the documentation, have you checked out the following doc? https://docs.gitlab.com/ee/user/project/clusters/index.html#...

Re: Kubernetes for personal projects? No thanks

#242
Good response. I agree with the intent of the article. For one I have a project where I just use Bash to set everything up (no containers what so ever). It's simple and convenient. I have it set up with Let's Encrypt, SELinux and git push deploy. The whole script is maybe like 100 lines of Bash + 2 configs (nginx and SELinux policy module).

For anybody who is interested in understanding this basic building blocks I decided to write https://vpsformakers.com/.

Re: Kubernetes for personal projects? No thanks

#243
post #197

I agree that Kubernetes for personal projects is likely going to be totally overkill for many, but I disagree that containers themselves are overkill, which this author also suggests. These are arguably two separate issues entirely, and lumping them together is extremely misleading. I happily run all my (very small) side projects in containers without Kubernetes and it's really pretty simple to do so. As soon as this…

Out of curiosity, how do you deploy new versions of your without downtime (start new containers, wait for new containers to be ready, switch traffic to new containers, shutdown old containers)?

Re: Kubernetes for personal projects? No thanks

#244
Containers can be easy to use, once you drop devops. Containers are simple, a much more flexible alternative to VMs.

Unfortunately the devops community always wanted to promote themselves as the only option for containers and even though they were based on the LXC project they did not explain the technical decisions and tradeoffs made as they did not want users to think there are valid alternatives. And this is the source of fundamental confusion among users about containers.

Why are you using single process containers? This is a huge technical decision that is barely discussed, a non standard OS environment adds significant technical debt at the lowest point of your stack. Why are you using layers to build containers? Why not just use them as runtime? What are the tradeoffs of not using layers? What about storage? Can all users just wish away state and storage? Why are these important technical issues about devops and alternative approaches not discussed? Unless you can answer these questions you cannot make an informed choice.

There is a culture of obfuscation in devops. You are not merely using an Nginx reverse proxy or Haproxy but a 'controller', using networking or mounting a filesystem is now a 'driver'. So most users end up trying Kubernetes or Docker and get stuck in the layers of complexity when they could benefit from something straightforward like LXC.

Re: Kubernetes for personal projects? No thanks

#245
post #197

I agree that Kubernetes for personal projects is likely going to be totally overkill for many, but I disagree that containers themselves are overkill, which this author also suggests. These are arguably two separate issues entirely, and lumping them together is extremely misleading. I happily run all my (very small) side projects in containers without Kubernetes and it's really pretty simple to do so. As soon as this…

Out of curiosity, how do you deploy new versions of your without downtime (start new containers, wait for new containers to be ready, switch traffic to new containers, shutdown old containers)?

For me personally zero downtime upgrades are a little beyond the scope of "personal project" and veering into something more production quality.

If I really had to for one of these, I'd probably just do something at the loadbalancer to start routing users to the new container stack then shutdown the old ones, much as you might have in the pre-container days. I can just wait the old fashioned way (by sitting in my chair for a minute) for them to start.

Re: Kubernetes for personal projects? No thanks

#246
post #181

Earlier quoted context omitted.

> Infrastructure is a core component of whatever it is you're building That's true in some sense -- but you can get surprisingly far using a PaaS like Heroku to abstract that infrastructure away. I'm a big fan of Kubernetes, and use it in production at my company, but I would not recommend using k8s in a prototype/early-stage startup unless you're already very familiar with the tool. The complexity overhead of k8s is…

I am a big fan of K8S too, not only use it in production, but I was also the one that set it up for my team. I agree that, unless you are already familiar with it, it is not always useful for protyping stage. There is something to be said about having the infrastructure in mind though. That's why I'm inclined to use something like Elixir/Phoenix for web-based projects. Some (not all) of the ideas that K8S brings to t…

> K8S is really a toolset for building your own PAAS.

I don't agree with this; that's one of the things you can do with it for sure, but multi-tenant isolation is actually one of k8s' weak points -- for example by default you can access services in any namespace, and you need something quite specialized like Calico and/or Istio to actually isolate your workloads. Plus you're still running workloads in containers on the same node, so inter-workload protection is nowhere near as good as if you're using VMs.

I see the big value add of k8s as making infrastructure programmable in a clear declarative way, instead of the imperative scripting that Chef/Puppet use. This makes it much easier to do true devops, where the developers have more control over the infrastructure layer, and also helps to commoditize the infrastructure layer to make the ops team's job easier, if you ever have a need to run your own on-prem large-scale cluster.

Re: Kubernetes for personal projects? No thanks

#247
post #245

Earlier quoted context omitted.

Out of curiosity, how do you deploy new versions of your without downtime (start new containers, wait for new containers to be ready, switch traffic to new containers, shutdown old containers)?

For me personally zero downtime upgrades are a little beyond the scope of "personal project" and veering into something more production quality. If I really had to for one of these, I'd probably just do something at the loadbalancer to start routing users to the new container stack then shutdown the old ones, much as you might have in the pre-container days. I can just wait the old fashioned way (by sitting in my cha…

Ok, this is basically what I do with an Ansible script, but I see it as a bit messy and non-standard, which is why I'm attracted to Docker swarm mode and Kubernetes (and maybe Nomad).

Re: Kubernetes for personal projects? No thanks

#248
post #177

Earlier quoted context omitted.

unless you already know how to do it. i can setup a production ready cluster in under a day and as long as things are containerized, run them likety split. Hardly insane once you know how it works.

An on-prem "production ready" k8s cluster in under a day? What kind of businesses are you setting this up for? Are these all greenfield projects? I'm sorry, but I find it hard to believe that. We run on-prem k8s, on bare metal and VMs. Integration with existing storage (we use NetApp Solidfire and NFS), load balancers, firewalls, backup strategy, DR, etc. takes weeks, if not months of work. But we may disagree on wha…

Whom said anything about on-prem? on-prem anything takes weeks and has nothing to do with kubernetes. AWS, production ready. I could probably do google too, but it would take a couple weeks to write the automation first. Also, if your on-prem system is already well organized, the kubernetes portion can also be done 1-2 days. If it takes you weeks to attach storage, load balancers, and configure your firewalls, none of that has anything to do with a production ready kubernetes cluster.

Re: Kubernetes for personal projects? No thanks

#249

So basically, ignore 1/2 of the reasonable problems that are solved in the first article and then look, no need to learn anything!!! As someone whom can setup and run a kubernetes cluster in my sleep, I can tell you that it is a superb production ready platform that solves many real world problems. That in mind, kubernetes has constraints also, like running networked elixer containers is possible, but not ideal from…

> So basically, ignore 1/2 of the reasonable problems that are solved in the first article and then look, no need to learn anything!!! I think the point is... do you actually have those problems? A lot of people jump immediately to worrying about having thousands of requests per second when it doesn't make any sense.

Sharing code and getting run on other collaborators workstations? Yes, that's a very real developer problem.

Deploying without downtime? Yep, it's nice to have because your favorite customer will have been testing that site in the exact 2 minutes of downtime which you deploy it ....believe me, murphy's law rules here.

Staging and Production environments that are the same, so I don't have surprises from local development to production release? Yep, another real problem that will slow momentum of development.

I suppose if you are developing a personal project of garbage that no one will ever see, than these problems don't exist. But if you are actually developing a product, these problems exist.

Re: Kubernetes for personal projects? No thanks

#250
post #224

Earlier quoted context omitted.

Don't waste your time, he's a troll that pops up on every thread that has anything to do with things like docker or k8s. It doesn't matter what the problem is, smartos is the solution. SmartOS is solid technology, but he doesn't have the slightest clue what k8s does, but is completely certain that smartos somehow does "the same thing" better. They aren't even mutually exclusive, there's no reason you couldn't write a…

Personal attacks will get you banned here. Please make your points without stooping to that in the future. https://news.ycombinator.com/newsguidelines.html

I suppose my comment appears harsh if you haven't seen month after month of his "smartos solves every problem and linux users are too stupid to know how to computer properly" type comments. read the guys bio:

> There exist no words in any of the languages I speak which can express my hate of GNU and GNU/Linux.

> I was raised on IRIX, HP-UX and Solaris. Huge illumos / SmartOS fan and FreeBSD sympathizer.

It's hard not to attack someone personally when their entire persona is tied to promoting a particular technology every chance they get.

The funny thing is all of his comments do absolutely nothing to convince anyone that smartos is worth looking at, which is a shame because it's actually quite nice.

Post reply on HN