Earlier quoted context omitted.
I think the original article made a good point, and one that seems to be overlooked by pretty much every critical response: if you don't already know standard sysadmin tooling and procedures, then the value proposition for k8s for small projects alone is probably comparable to standard sysadmin tooling. At least with k8s, you can take that knowledge with you when you want to scale. I don't know if I'm totally convinc…
Do you really thing you can set up and run a Kubernetes cluster, even a small one, without significant understanding of standard sysadmin tooling? I know a fair bit, and I didn't find it easy.
Kubernetes for personal projects? No thanks
251–260 of 278 posts
Re: Kubernetes for personal projects? No thanks
#252Earlier quoted context omitted.
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).
Pick the one that works best for you and your projects goals (within reason...).
Re: Kubernetes for personal projects? No thanks
#253Earlier quoted context omitted.
If we're here to avoid pre-existing agendas, then Docker and Kubernetes promotional articles tick every box on the "tedious" agenda. The best part is, the article is about "no thanks" to Kubernetes, which I wholeheartedly agree with and have stuck to commenting relevantly to the topic, backed up by plenty of citations.
I mentioned our talk to my coworker, his immediate response was "does he work for Oracle?" I'm only half seriously asking but, do you? (Given the certifications you mentioned, I think that even if you don't, there is a vague subjective case that you do...)
Re: Kubernetes for personal projects? No thanks
#254Earlier quoted context omitted.
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…
If you think someone is abusing HN, the thing to do is email us at hn@ycombinator.com so we can look into it.
Re: Kubernetes for personal projects? No thanks
#255Earlier quoted context omitted.
The personal attack wasn't ok, but please don't "pop up" on every thread to say predictable things. Pre-existing agendas are tedious, and tedium is what we all come here to avoid.
If we're here to avoid pre-existing agendas, then Docker and Kubernetes promotional articles tick every box on the "tedious" agenda. The best part is, the article is about "no thanks" to Kubernetes, which I wholeheartedly agree with and have stuck to commenting relevantly to the topic, backed up by plenty of citations.
Re: Kubernetes for personal projects? No thanks
#256Earlier quoted context omitted.
Do you really thing you can set up and run a Kubernetes cluster, even a small one, without significant understanding of standard sysadmin tooling? I know a fair bit, and I didn't find it easy.
Absolutely. I set one up from scratch on a cluster of Raspberry Pis and I don't know shit about Packer, Ansible, SystemD, and probably a bunch of things I'm only nominally familiar with. And that was a bare metal cluster, and it was hard; however, I don't think it was hard for lack of sysadmin knowledge, it was hard because I was learning K8s, I had to learn about ingres and MetalLB, K8s requires you to modify cgroup…
Re: Kubernetes for personal projects? No thanks
#257Earlier quoted context omitted.
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).
Fair, but I think it's arguable there isn't really a "standard" way for container orchestration, and Docker Swarm to me is starting to feel like a dead horse, despite protestations to the contrary from Docker. The requirements of different software always make each project's needs for zero downtime upgrades different enough, especially if you are dealing with legacy software. Pick the one that works best for you and…
Agreed by Docker swarm mode feeling a bit abandoned.
Do you have any recommendation for a solution that I would have missed?
Re: Kubernetes for personal projects? No thanks
#258Earlier quoted context omitted.
I mentioned our talk to my coworker, his immediate response was "does he work for Oracle?" I'm only half seriously asking but, do you? (Given the certifications you mentioned, I think that even if you don't, there is a vague subjective case that you do...)
This comment breaks the site guidelines. Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here.
The missing context from another comment was:
> ... amount of institutional inertia I've come up against while trying to get any part of our Development or Production stack shifted over to Kubernetes, which I consider myself fairly expert in, I think you'd understand that "containers on Solaris" is not going to go over any better for me than containers on GNU/Linux,
Both SmartOS and GNU/Linux are open platforms, so it really wasn't fair of me to accuse a person of shilling for Oracle. I think I understand.
(That wasn't my intention, but if you read it that way, that's my mistake.)
Re: Kubernetes for personal projects? No thanks
#259Oh man, the original article went way over the author's head. The point of the original article was that even though Kubernetes is primarily useful for tackling the challenges involved with running many workloads at enterprise scale, it can also be used to run small hobbyist workloads at a price point acceptable for hobbyist projects. Does that mean that Kubernetes should now be used for all hobbyist projects? No. If…
> But maybe I envision my side project turning into full-time startup some day. The state of the art for cluster management will probably something completely different by then. Better to build a good product now and if you really want to turn it into a startup, productionize it then. > Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. If learning Kubernetes _is_ your s…
Well, you gotta deploy with something. Why not k8s?
Obviously if you're developing locally, k8s would not help in the least.
Re: Kubernetes for personal projects? No thanks
#260Earlier quoted context omitted.
> The state of the art for cluster management will probably something completely different by then Has it not only changed twice in the prior two decades between first VMs and now containers? Don't think this is something you have to worry about long term.
Uh I don't think vms or containers are cluster management in itself. They are just technologies. What you use to orchestrate them is entirely different, and yes that has changed over the years many times.
I'd describe cluster management as four things - provisioning + configuration, resource management (CPU+RAM+Disk), scheduling (when & where to put things based on availability/resources), and deployment (running things). At least, these are the things I'm concerned about when managing a product that requires a cluster (besides monitoring).
Early cluster management tools were often just doing provisioning and configuration (CFEngine). We see Puppet, Chef, and eventually Ansible further refine the solution as we enter the "Bronze Era" where standing up new servers take a fraction of the time. Now we didn't even bother to name each server by hand when we were going through the installation process after booting up the OS - servers had become cattle, and they were tagged appropriately.
Around the same time (2003-2006) we see virtual machines begin to catch on, culminating in the 2006 debut of Amazon Elastic Compute Cloud (EC2) and the birth of modern cloud computing. We now had a general purpose mechanism (VMs) to spin up isolated compute units that could be provisioned, configured, and managed using tools like CFEngine & Puppet. IT departments begin spending less on the SANs that dominated the early aughts and shift budgets to AWS or VMWare ESXi.
Then in 2006 we see Hadoop spin off from Nutch, and the MapReduce paradigm popularized by Google leads to an optimization of the resource and scheduling problems thanks to YARN and Mesos and related tools. Non-trivial programs and workloads can now be scheduled across a cluster with vastly improved confidence. Distributed programs are now in reach of a much larger audience.
Suddenly new Hadoop clusters are springing up everywhere and the "Silver Era" begins. Tools enabling greater efficiency hit the scene like RPC serialization frameworks (Thrift, Protobuf), improved on-disk storage (O/RCFile, Parquet), distributed queues (RabbitMQ, SQS), clustered databases (Cassandra, HBase), and event streaming and processing (Storm, Kafka).
Coordination becomes more complicated and essential, so we get ZooKeeper and etcd and consul. Managing passwords and other secure data leads to tools like Vault. Logstash and Graylog make log management less of a nightmare. Solr leads to Elasticsearch leads Kibana and we now have logging and visualization for both server and application monitoring.
Developers also begin to take advantage of VMs and it's not long before tools like Vagrant help bridge the gap between development, staging, and production. Our profession takes a collective sigh of relief as getting our distributed programs started on a new developers machine went from three days of trial-and-error to minutes thanks to well-maintained Vagrantfiles.
Still, deployment is a big pain point. A single cluster could be home to Hadoop (which benefits from YARN) and thirty other things being run by teams across the organization. One day you discover that your mission critical web app is sharing resources with your BI team after your CEO calls you in a panic to tell you the website is down. Turns out a DBA transferred a 20TB backup across the same switch shared with your customer-facing website because somebody forgot to isolate a VLAN to prevent backups from interfering with other traffic.
This doesn't even take into the consideration the abominations we call deployment scripts that developers and DevOps wrangle together to get our programs deployed.
Then Docker and containers become a thing. Developers are now able to setup incredibly complex distributed programs with little more than text files. No more coordinating with DevOps to make sure your servers have the latest version of libpng, or spending months fighting to get Java upgraded to the latest version. I shout in glee as I delete Chef from my machine because progress. Then the beer goggles dissipate and the love affair ends and we realize things are shitty in a different way.
Docker Swarm and Kubernetes emerge, and that brings us to today which I'll call the "Golden Era". We now have incredible tooling that deals with provisioning and configuration, resource management, scheduling, and deployment. But like any new era there are rough spots, but I'm positive incredible new tech will popup.
Throughout all of this, virtual machines and containers were the fundamental building blocks that enabled improved clustering and cluster management. They're inextricably tied together. But all-in-all, things have changed VERY little (couhg LXC cough) in 20 years compared to the rest of the landscape. We're solid for another 10 years before anything like this is going to happen again.