32 ms·

Kubernetes for personal projects? No thanks

481 points by carlosrdrz 8y ago

jeremychone 8y ago
yes, there is a learning curve, but once you have your system in place (for local Kuberenetes Development as well as deployment), then, even of a web-sites, it is a breeze. But yes, still need to be organized.
reilly3000 8y ago
Warning to those who think Fargate is green pastures: it has its own learning curve. Also, it costs about ~1.8-2.5X the price of standard EC2 for the convenience. Don't waste your money on it for long-running containers that will rarely need to scale.
- carlosrdrz 8y ago
  Thanks for sharing your thoughts! I wrote about Fargate because I like the idea of having a service that manages both masters AND workers and where you only need to care about the API, but didn't really try it yet. That was my impression as well, though. Even the use cases mentioned in the pricing site are just containers running for a few hours a day, and not long-running services like servers.
  - tilolebo 8y ago
    The smallest fargate container in us-east-1 will cost you USD 13 per month if you never shut it down. Avoid using a load balancer as they are quite pricey (although it will allow you to create and use auto-managed SSL certificates for free.) Of course you will also pay for egress traffic. The nicest part of Fargate is that: * you can define your whole cluster using a docker-compose like format. * you can manage your cluster using the ECS CLI. No extra tool needed.
jitl 8y ago
I’m itching to replace my home server’s FreeBSD with Linux and Kubernetes. I use it (& build dev tools for others) at work plenty so for me, the learning curve is in the past. I’m not sure if I would recommend this journey for others, but I also wouldn’t recommend FreeBSD to anyone, either. In both cases, you know what you’re getting in to - something complex, opinionated, powerful, and industrial strength.
- barrystaes 8y ago
  Try Unraid on your home server: boots from USB and runs in memory, no raid risks but have network share span several HDDs, parity HDDs, use SSD for cache. No kubernetes involved - just a webinterface to run containers, install dockers as "apps" on your server. And Unraid is linux, you can but dont need to tinker. Unraid is how i started using Dockers and became happy friends with my home server again. (tm)
  - jitl 8y ago
    I think you misunderstand me: my objective is to tinker. Before, I was tinkering with FreeBSD, now I will be tinkering with Kubernetes. Thanks for the recommendation though.
- tannhaeuser 8y ago
  You'll know this already but I'd say when you're coming from FreeBSD you'll be disappointed with Docker in particular, because it serves no purpose in the (usually) well-organized BSD world where the good stuff is built from source, and developed to POSIX guidelines most of the time anyway. Docker is just a workaround for the perceived mess of shared libraries in the Linux world of multiple O/S vendors (by not using shared libs in the first place which could be solved by statically linking everything), and FreeBSD's jails is IMHO superior as sandbox technology anyway.
  - jitl 8y ago
    I found the jails ecosystem as old and creaky as FreeBSD itself; the technology is good, and everything makes sense, but after using Docker on Mac and Linux for a while, I've started to prefer the lighter-weight and more user-friendly abstractions. If there was a Jailfile equivalent for FreeBSD and a command-line tool with the same interfaces as docker, namely `docker run --rm -it ...`, I might be staying on FreeBSD.
jypepin 8y ago
I totally agree with this article. I'm giving a point of a view of a pure developer who knows nothing about DevOps things and managing servers. I kind of know what NGINX is and barely know how to configure something like systemd. I recently setup a digital ocean droplet and setup my blog there to actually understand how it works. It was great because I learned a ton and feel in control. Pretty simple setup - single droplet, rails with postgres, capistrano to automate deploys and a very simply NGINX config. It took me multiple days to setup everything, compared to the 5 minutes Heroku would have required - and it's not as nice as what Heroku offers. Still, I'd wait as long as I can to get out of something so simple as Heroku for _anything_. I understand it gets expensive quickly, but I really want to see the cost difference of Heroku vs the time spent for the engineering team to manage all the complexities of devops, automated deploys, scaling, and I'm not even mentioning all the data/logging/monitoring things that Heroku allows to add with 1 click.
- rehemiau 8y ago
  Did you try preconfigured Dokku images on Digital Ocean?
  - acjohnson55 8y ago
    I've heard of Dokku as a "run your own Heroku" solution. Is there a good guide for this combo?
    - josegonzalez 8y ago
      The "quick-start" installation process on our homepage is `curl | bash` on a plain Ubuntu/Debian/Centos server (you can also run the commands manually, which are also outlined on that page). If you go through the web installer - which allows you to add your ssh key and setup a global domain - you'll be redirected to our deployment tutorial here: http://dokku.viewdocs.io/dokku/deployment/application-deployment/ http://dokku.viewdocs.io/dokku/deployment/application-deploy... - Dokku homepage: http://dokku.viewdocs.io/dokku/ http://dokku.viewdocs.io/dokku/
- de_watcher 8y ago
wheresvic1 8y ago
Totally agree with the author, for my side projects in Node.js, I use the following: - pm2 for uptime (pm2 itself is setup as a systemd serivce, it's really simple to do and pm2 can install itself as a systemd service) - I create and tag a release using git - on the production server, I have a little script that fetches the latest tag, wipes and does a fresh npm install and pm2 restart. - nginx virtual host with ssl from letsencrypt (setting this stuff was a breeze given the amount of integration and documentation available online) Ridiculously simple and I only pay for a single micro instance which I can use for multiple things including running my own email server and a git repo! The only semi-problem that I have is that a release is not automagically deployed, I would have to write a git hook to run my deployment script but in a way I'm happy to do manual deployments as well to keep an eye on how it went :)
- striking 8y ago
  Drone CI could make this whole process automated and preserve your ability to inspect the logs.
- Draiken 8y ago
  Honestly, you could do that in almost the same time on Kubernetes. I understand why people might not want to invest the time onto learning a new technology, but that's not a reason to say it's a bad fit. If you know how to use Kubernetes, doing these bash scripts and doing a few YAML files will take basically the same time and the end result will be vastly superior on Kubernetes.
  - Aeolun 8y ago
    Good luck setting up an email server on kube. Or a git repository for that matter
    - denvrede 8y ago
      Why exactly do you think someone needs luck with that? I'm honestly curious.
    - 8y ago
majewsky 8y ago
I looked into using Kubernetes for my personal servers, but I abandoned the idea when I saw that the minimal Kubernetes setup uses more compute resources than all the services [1] it's supposed to manage combined (e.g. 0.5 GiB RAM vs. 0.25 GiB, which is substantial on a 1/1 VM). And that's before you consider that a single-server setup is not The Right Way (TM) in k8s land. [1] Gitea (Github clone), Murmur (voice-chat server), Matrix Synapse (instant messaging), Prosody (XMPP), nginx (for those services and for various static websites)
- zeeZ 8y ago
  IMHO Kubernetes only makes sense if you can, or want to, run multiples of things that are either stateless or clustered in some way, or another copy for a different purpose. Run two instances of something if you want to survive a single crash or a node update. Run another copy of your application stack if you want to try out a different version or config. Without looking at the docs, most of the things in your list are single-instance stateful applications, so unless you plan to run another copy of them for a different purpose, K8S is overkill.
vbsteven 8y ago
I've been thinking about setting up a small Kubernetes cluster for hosting some smaller client projects (read websites, shopping carts, API's, admin panels). My current setup uses a couple of Hetzner dedicated machines and services are deployed with ansible playbooks. The playbooks install and configure nginx, install the right version of ruby/java/php/postgres, configure and start systemd services. These playbooks end up copied and slightly modified for each project, and sometimes they interfere with one another in sublte ways (different ruby versions, conflicting ports, etc) With my future Kubernetes setup I would just package each project into its own self-contained container image, write a kubernetes deployment/pod spec, update the ingress and I'm done.
- grillorafael 8y ago
  I recommend having a look at DCOS
  - p_l 8y ago
    I recently started working with DCOS, and so far it seems that while it might have been more mature and ready platform 2-3 years ago, today I have to deal with issues I don't have to care about on K8s
    - grillorafael 8y ago
      Curious to know what. We run a DCOS cluster with 40+ machines and we have to deal with pretty much nothing
- hardwaresofton 8y ago
  If you can find the time to get up to speed on Kubernetes, I would say do it. I actually have a weirdly similar setup to you (I run on Hetzner and used and still use ansible), and I've written about it, most recently when I switched my single node cluster to Ubuntu 18.04 [0]. In the past I've also run a single node kubernetes clusters on CoreOS Container Linux, Arch, and back to CoreOS Container Linux in that order, from versions 1.7~1.11. [0]: https://vadosware.io/post/hetzner-fresh-ubuntu-install-to-single-node-kubernetes-cluster-with-ansible/ https://vadosware.io/post/hetzner-fresh-ubuntu-install-to-si...
cs02rm0 8y ago
I don't even want to use it for commercial projects. It needs a certain scale before the overheads are worth it.
- cs02rm0 8y ago
  Didn't expect this comment to come back from being voted down so much! Guess it splits opinion.
  - vesak 8y ago
    People are crazy (literally) about Kubernetes.
hardwaresofton 8y ago
If you can devote some time and learn the underpinnings, Kubernetes is great for personal projects. I personally use it for 1 business website, 1 blog, 2 3 tier applications (backs are SQLite though) and 1 3-tier client project. Where kubernetes shines is that that it handles most things in a principled, and self-consistent manner -- once you've made your way up the learning curve, you can think in terms of kubernetes without having many hiccups. I'd argue that a lot of the complexity people find in Kubernetes is essential when you consider what it takes to run an application in any kind of robust manner. Take the simplest example -- reverse proxying to an instance of an application, a process (containerized or not) that's bound to a local port on the machine. If you want to edit your nginx config manually to add new upstreams when you deploy another process, then reload nginx be my guest. If you find and setup tooling that helps you do this by integrating with nginx directly or your app runtime that's even better. Kubernetes solves this problem once and for all consistently for a large amount of cases, regardless of whether you use haproxy, nginx, traefik, or whatever else for your "Ingress Controller". In Kubernetes, you push the state you want your world to be in to the control plane, and it makes it so or tells you why not. Of course, the cases where Kubernetes might not make sense are many: - Still learning/into doing very manual server management (i.e. systemd, process management, user management) -- ansible is the better pick here - Not using containerization (you really kinda should be at this point, if you read past the hype train there's valuable tech/concepts below) - Not interested in packaged solutions for the issues that kubernetes solves in a principled way that you could solve relatively quickly/well adhoc. - Launching/planning on launching a relatively small amount of services - Are running on a relatively small machine (I have a slightly beefy dedicated server, so I'm interested in efficiently running lots of things). A lower-risk/simpler solution for personal projects might be something like Dokku[0], or Flynn[1]. In the containerized route, there's Docker Swarm[2] +/- Compose[3]. Here's an example -- I lightly/lazily run https://techjobs.tokyo https://techjobs.tokyo (which is deployed on my single-node k8s cluster), and this past weekend I put up https://techjobs.osaka https://techjobs.osaka. The application itself was generically written so all I had to do for the most part was swap out files (for the front page) and environment variables -- this meant that deploying a completely separate 3-tier application (to be fair the backend is SQLite), only consisted of messing with YAML files. This is possible in other setups, but the number of files and things with inconsistent/different/incoherent APIs you need to navigate is large -- systemd, nginx, certbot, docker (instances of the backend/frontend). Kubernetes simplified deploying this additional almost identical application in a robust manner massively for me. After making the resources, bits of kubernetes got around to making sure things could run right, scale if necessary, retrieve TLS certificates, etc -- all of this is possible to set up manually on a server but I'm also in a weird spot where it's something I probably won't do very often (making a whole new region for an existing webapp), so maybe it wouldn't be a good idea to write a super generic ansible script (assuming I was automating the deployment but not with kubernetes). Of course, Kubernetes is not without it's warts -- I have more than once found myself in a corner off the beaten path thoroughly confused about what was happening and sometimes it took days to fix, but that's mostly because of my penchant to use relatively new/young/burgeoning technology (for example kube-router recently instead of canal for routing), and lack of business-value to my projects (if my blog goes down for a day, I don't really mind). [0]: http://dokku.viewdocs.io/dokku http://dokku.viewdocs.io/dokku [1]: https://github.com/flynn/flynn/ https://github.com/flynn/flynn/ [2]: https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ [3]: https://docs.docker.com/compose/ https://docs.docker.com/compose/
dropmann 8y ago
For me also the overhead played a big role, to just get a bare kubernetes cluster you already need 3 nodes + 1-2 load balancers. In case you are using GKE, you actually need two ingresses to support IPv6 + IPv4 This adds up to like 10 times the cost of an single droplet. For personal projects this seems kind of wasteful to me.
z3 8y ago
kubernetes has more advantages than pure horizontal scaling capacity. there are services, secrets, networking etc, which are useful for small size projects at the same way as big ones. I agree that it can be over kill, but I would not throw away whole kubernetes only for assumptions base on the size of the projects.
comboy 8y ago
In my opinion, the best technology for personal projects is the one that you don't know yet. They are a great opportunity to play around stuff which really is the only way of learning something new. Unless the personal project is something that you really care about, potential startup or something like that, then obviously you choose something that you are already proficient in because then it's about getting stuff done and moving forward. So while it may make sense to discuss what technology is good or bad for some kind of companies, I think we won't arrive at any ultimate conclusion like "X is good/bad for personal projects".
solatic 8y ago
Oh 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 I'm thinking of playing around with a Raspberry Pi or other SBC, do I need to install Kubernetes on the SBC first? If I'm thinking of playing around with IoT or serverless, should I dump AWS- or GCE-proprietary tools because nobody will ever run anything that that can't run on Kubernetes ever again? If I'm going to play around with React or React Native, should I write up a backend just so I can have something that I can run in a Kubernetes cluster, because all hobbyist projects must run Kubernetes now, because it's cheap enough for hobbyist projects? If I'm going to play around with machine learning at home, buy a machine with a heavy GPU, figure out how to get Kubernetes to schedule my machine learning workload correctly instead of just running it directly on that machine, because uhhh maybe someday I'll have three such machines with powerful GPUs plus other home servers for all my other hobbyist projects? No, no, no, no, no. Clearly. But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Different people will use different solutions for different project requirements.
- carlosrdrz 8y ago
  I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably wrong. I don't think that is wrong. I do think it is probably overkill, and IMO it does introduce operational burden and complexity. That doesn't mean you shouldn't do it, though, if you're interested in exploring the technology, for example.
  - Draiken 8y ago
Annatar 8y ago
"I think the point I'm trying to make is: do you actually need all of this?" Yep! For any thing which goes beyond the initial viability test, I make an OS package. SmartOS has SMF, so integrating automatic startup/shutdown is as easy as delivering a single SMF manifest, and running svccfg import in the package postinstall. For the configuration, I just make another package which delivers it, edits it dynamically and automatically in postinstall if required, and calls svcadm refresh svc://... it's easy. It's fast. The OS knows about all my files. I can easily remove it or upgrade it. It's clean. When I'm done, I make another ZFS image for imgadm(1M) to consume and Bob's my uncle.
fcgravalos 8y ago
I can't agree more with the author ;). I work in my day to day 100% and fully dedicated automating Kubernetes cluster lifecycle, maintaining them, monitoring them and creating tools around it. Kubernetes it's a production-grade container orchestrator, it solves really difficult problems but it brings some challenges though. All of their components work distributed across the cluster, including network plugins, firewall policies, the control plane, etc. So be prepared to understand all of it. Don't get me wrong, I love Kubernetes and if you want to have some fun go for it, but don't use the HA features as an excuse to do it. But overall saying "NO" to rsync or ansible to deploy your small project just because it's not fancy enough it sounds to me like "Are you really going to the supermarket by car, when there are helicopters out there?" Great article!
Annatar 8y ago
"Oh man, the original article went way over the author's head." No, the author of the Kubernetes article completely, so utterly missed the point that it's not even funny: none of those Kubernetes complications are necessary if one runs SmartOS and optionally, as a bonus, Triton. Since doing something the harder and more complicated way for the same effect is irrational, which presumably the author of the Kubernetes article isn't, I'm compelled to presume that he just didn't know about SmartOS and Triton, or that the person is just interested in boosting their resume rather than researching what the most robust and simplest technology is. If resume boosting with Kubernetes is their goal then their course of action makes sense, but the company where they work won't get the highest reliability and lowest complexity that they could get. So good for them, suboptimal for their (potential) employer. And that's also a concern, moreover, it's a highly professional one. I'm looking through the employer's eyes on this, but then again, I really like sleeping through entire nights without an incident. A simple and robust architecture is a big part of that. Resume boosting isn't.
- yebyen 8y ago
  While that's great, and I thought about plugging my own containers project here too, to get it some exposure and possibly help someone (we're trying to help people get on the train, and that's commendable, I didn't downvote you) now you've gone from something bespoke to something basically singular, where Kubernetes is a leading industry standard with the weight of at least[1] 77 vendors who have sought and achieved conformance[2] with their own distributions of Kubernetes. I haven't heard of Joyent or SmartOS in years! I am super surprised to hear of anyone recommending it today as a competitor to Kubernetes, and I have no facts or deep understanding of that platform so I won't belabor you with an argument about how Kubernetes is better. (I can't say if it is or isn't.) It's just not in the same ballpark. I'm glad it works for you. I'm especially glad to hear about another option (that we could potentially replace our bespoke deployments with), because the more of these things I know about, the louder I can clamor to upper management about the fact that we're not using any of these technologies yet, and we should be (to sleep through the night!) I learned about Kubernetes through Deis Workflow. It took years to understand Kubernetes from end-to-end, and I was already a container veteran when Deis moved to k8s. I resisted! I caved. I came over, now I have years of experience with Kubernetes, and I can't say I'd recommend anything else. "Those complications" are all very hard to get over, but then ... you get over them! And largely don't have to do that again. If you are on Kubernetes, then you are not locked in to any cloud provider (unless you have opted into another technology that made you locked in.) I can't say the same for Triton. For the purposes of disclosure, I am a member of Team Hephy, the open source Deis Workflow fork. (Deis Workflow is EOL and Hephy is the continuation.) Workflow is how I learned Kubernetes, and I would still recommend it highly to anyone else that wants to learn Kubernetes. But I will not kid anyone into thinking it's going to happen overnight. (With Workflow though, you can absolutely start using it productively in about an hour.)[3] [1]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb... [2]: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ [3]: https://web.teamhephy.com https://web.teamhephy.com or https://blog.teamhephy.info/#install https://blog.teamhephy.info/#install
codegladiator 8y ago
Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me". You don't need to run a new cluster for every project. You can deploy multiple projects in a single cluster. I was running close to 5 different projects in a single cluster, backed by about 3-6 machines (machines added/removed on demand). Kubernetes is basically like your own heroku. You can create namespaces for your projects. No scripts. You can deduce everything (how is a service deployed, whats the config, whats the arch) from the config files (yml) > Is a single Nginx virtual host more complex or expensive than deploying a Nginx daemon set and virtual host in Kubernetes? I don't think so. Yes it is. I wonder if the author has actually tried setting this themselves. I do realise i had similar opinions before I had worked with kubernetes, but after working with it, I cannot recommend it enough. > When you do a change in your Kubernetes cluster in 6 months, will you remember all the information you have today? Yes, why does the author think otherwise ? Or if this is a real argument why does the author think their "ansible" setup would be at the top of the head. I had one instance where I had to bring a project back up on prod (it was a collection of 4 services + 2 databases not including the LB) after 6-8 months of keeping it "down". Guess what, I just scaled the instances from 0 to 3, ssl is back, all services are back, everything is up and running. This is not to say you wont have issues, I had plenty during the time i started trying it out. There is a learning curve and please do try out the ecosystem multiple times before thinking of using it in production.
- carlosrdrz 8y ago
  > Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me". It is just my opinion after all. I'm just trying to share my thoughts :) > Yes it is. I wonder if the author has actually tried setting this themselves. I've used K8s for months in production, maintaining a few clusters at my previous job.
pstadler 8y ago
> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. Once your cluster is running you just write a couple of manifests to deploy a project, versus: ssh into machine; useradd; mkdir; git clone; add virtual host to nginx; remember how certbot works; apt install whatever; systemctl enable whatever; pm2 start whatever.yml; auto-start project on reboot; configure logrotate; etc. Can this be automated? Sure, but I'd rather automate my cluster provisioning.
- vorpalhex 8y ago
  > Complexity is a weak argument I see you've never tried to upgrade a running kubernetes cluster or been in an on call schedule for one. It's a new technology that is still maturing but it has a lot of moving parts all of which require a fair bit of understanding and which change on a regular basis. Hell, just a few months ago the ACM agent totally got rewritten and now you have a choice between alpha software or a deprecated project!
  - pstadler 8y ago
    I treat my cluster as immutable. My setup is open source: https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide
- carlosrdrz 8y ago
  I will also invite everyone to try it and I also believe K8S is here to stay. I think K8S makes a lot of sense for lots of workloads, but I don't think it makes sense to maintain a k8s cluster to run personal projects. About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workloads you can run there.
  - 8y ago
stuaxo 8y ago
The point about complexity is exactly right. Every new thing that you add, adds complexity. If that thing interfaces with another, then there is complexity at the interfaces of both. Modern tools that atomise everything reduce density (and thus complexity), but people aren't paying attention to the amount of abstractions they are adding and their cost.
ataturk 8y ago
I can't think of any reason why I would need container orchestration at home. Seems like swatting flies with a bazooka to me.
isugimpy 8y ago
For random toy projects, spinning up a whole Kubernetes cluster is absolutely overkill (unless part of the project is learning Kubernetes). The thing is as you get further along, for some applications, it becomes harder and harder to move to a container-based design as you have to unwind all the weird dependency mappings. I've got an app I've been involved with containerizing for a client at work, and they're dead set on sticking with an Ubuntu 14.04 base container, because they legitimately don't know if it'll even function on a more modern base, and don't feel they can spare the development cycles to figure it out. Thing is, it started as a toy application, deployed to a server by manually SSHing in and doing a git pull from the repo (not even rsync!) and restarting all the services, and that's still how it's deployed in production today. Containers (and thus Kubernetes) aren't the magical solution to every problem in the world. But they help, and the earlier you can get to an automated, consistent build/deploy process with anything that'll actually serve real customers, the better off you are. Personally, I'd rather design with containers in mind from day one, because it's what I'm comfortable with. There's nothing wrong with deploying code as a serverless-style payload, or even running on a standalone VM, but you need to start planning for how something should work in the real world as early as you can reasonably.
- yebyen 8y ago
  FWIW, cedar-14 stack is Ubuntu 14.04 and that's been the base of Deis Workflow (now Hephy Workflow) for years. We've been meaning to upgrade to Heroku-16 stack (and eventually Heroku-18) but our resources are limited too, and we've had to fight other dragons like getting a website together, and figuring out the build system. (Deis Workflow was EOL'ed last year, and Team Hephy is the fork/continuation of development, which we can do because Deis developers were all gracious enough to keep everything OSS.) So, back to the point, I'm sure you couldn't deploy your app on Heroku if that's your requirement (because cedar-14 is deprecated, and not available for new deployments anymore) but if you seriously wanted to try containerizing it onto Kubernetes, and if you don't have other obstacles to 12-factor design that you're also not prepared to tackle, then Hephy Workflow v2.19.4 might actually work for you. https://teamhephy.com https://teamhephy.com and https://docs.teamhephy.com https://docs.teamhephy.com I'm sure this probably won't work for you, for reasons you may not have explained, but ... maybe you'd like to look? I'm not doing a great job selling it, the one redeeming quality I've mentioned is that it runs an outdated stack that you need ;)
nimbius 8y ago
I work as an engine mechanic full time, and im learning programming as a hobby. Kubernetes to me is like the shade-tree mechanic vs the professional. Professional mechanics use high grade tools that can cost thousands of dollars each. We have laser alignment rigs, plasma cutters, computer controlled balancing and timing hardware, and high performance benchmarking hardware that can cost as much as the car you're working on. We have a "Kubernetes" like setup because we service hundreds of cars a month. The shade-tree mechanic wrenching on her fox body mustang on the other hand? her hand-me-down tool box and a good set of sockets will get her by with about 90% of what she wants to do on that car. she doesnt need to perform a manifold remap, so she doesnt need a gas fluid analyzer any better than her own two ears. I should also clarify that these two models are NOT mutually exclusive. If i take home an old Chevy from work, I can absolutely work on it with my own set of tools. And if the shade-tree wants to turn her mustang into a professional race car, she can send it to a professional "kubernetes" type shop that will scale that car up proper.
- ayyyyy 8y ago
  This might actually be the stupidest fucking thing I have ever read.
- xtrapolate 8y ago
  I don't quite resonate with the analogy here. It's about using the right tool for the job. Most small-scale personal projects, by their very definition, don't require an orchestration framework.
- shaklee3 8y ago
  This doesn't make sense, and it's really the opposite of what you're saying. K8s is hard, but for large scale you need something robust that's tested at that scale. A collection of shell scripts is more like a beginner tool set. Yes, it's easy to learn, but it will break when you get serious.
  - falcolas 8y ago
    For large scale you have to first make your application capable of scaling. That's a bit that's missing from most of these conversations. Only the simplest programs can "scale up" by just adding more programs - most have to be re-architected to move all the state in the program to some other service. That is to say, if scaling is your primary concern, you have a dozen other things more important to fix than your choice to use shell scripts vs. Kubernetes. And, fwiw, Linux has run professional services somewhere around 10x longer on those "beginner tools" than containers have even existed.
doppel 8y ago
I feel that Kubernetes has a lot of "upfront" cost that needs to be tackled - containerization, manifests for all the pods you want to set up, potentially setting up the right persistent storage if needed, user access, logging, etc. And this is still if you use a "hosted" solution with Amazon/Google/Microsoft, if you set it up yourself there is a ton more complexity. Using something you are familiar with, even if it's just a 10-line bash script, a simple virtual private server and the adding an nginx config there, is usually faster than having to orchestrate everything. If you want to invest the time in setting up Kubernetes for all your personal projects, it would probably make sense. Basically, is it worth it? https://xkcd.com/1205/ https://xkcd.com/1205/
kujaomega 8y ago
I read the article. I'm sorry, but my impression about it is the following: Why use Kubernetes in your personal projects when you have got no idea about it?. One think I have experimented after working with Docker for two years, is that once you know it, you will put every service inside a docker. It only takes 5 minutes to do it and the benefits are huge. Kubernetes might be an overkill, but containerize the apps is another thing.
billylindeman 8y ago
This seems like a grumpy and lame rationalization of not wanting to learn something new
pawurb 8y ago
Dokku works quite well for personal projects and is easy to get started with even without much dev ops exp https://pawelurbanek.com/rails-heroku-dokku-migration https://pawelurbanek.com/rails-heroku-dokku-migration
mcs_ 8y ago
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 interface and auto devops is enabled in 3 projects. in office we do not work with docker, containers, cloud etc, we run legacy asp.net 2.0 on-premise without any kind of automation (just a couple of us coordinating the releases and copying and pasting into the customer Windows Server 2008). Kubernetes for personal projects? In my case, after 10 years of on-premise deployments, VM Ware, SQL Clusters, web.config, IIS, ARR and the rest of the things related, YES! I absolutely want 3 hosts for less then 100$, a gitlab account for 4$, a free account in cloudflare, code and deploy.
- dsumenkovic 8y ago
  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#installing-applications https://docs.gitlab.com/ee/user/project/clusters/index.html#...
JAdamMoore 8y ago
Yes. Exactly. Kubernetes is adding complexity needlessly. People are so dumb, they can't understand that more isn't always better.
wwarner 8y ago
I absolutely love docker for development. It saves so much set up time, and of course is handy later.
caymanjim 8y ago
Kubernetes is just one of many development ecosystem tools that solve real problems and, once you know them, make your life easier. The arguments in this article can apply to any development tool or practice. Why separate your code into multiple files? Why write tests? Why use a code linter? Why use virtual environments? Why write a Makefile? If you're working on a small personal project, or you're a newer developer learning the ropes, or the project is temporary, not important, doesn't need to scale, etc. then it's simply a matter of personal choice. It doesn't make sense to get bogged down learning a lot of tools and processes if there's no compelling business need and you're just trying to get the job done. If you already know how to use these tools, though, they usually make your life a whole lot easier. I learn how to use complex systems in my career, where they're necessary and helpful. I apply these same tools and practices on my personal projects now, because once you know how to use something like Kubernetes, there's little cost to it and many of the benefits still apply.
- whydoineedthis 8y ago
  > tools that solve real problems and, once you know them, make your life easier. yep, i think you nailed here.
markbnj 8y ago
This whole line of debate is really getting tiresome. Kubernetes has proven its value in production use cases across a wide variety of application domains. That doesn't mean everybody should be using it, any more than the proven value of containers means that everyone should be deploying in them. I've been working with k8s for three years and run multiple production clusters, but if I had some little thing I might very well toss it up on a paas like app engine, or just install it on a free micro instance as the OP suggests. Or... maybe I would create a cluster and run it there. Point is kubernetes is an alternative that I can take advantage of where it makes sense because I've gotten some experience with it. It might make sense for you, it might not, but it's not essential that all developers immediately come to agreement on whether or not all software projects should migrate to k8s by tomorrow.
- bauerd 8y ago
  I wholeheartedly agree with this. It's one of many HN debates that boil down to whether X is the right tool. Thing is, you can't judge about the usefulness of a tool without factoring in its users. If you and your team have experience with Kubernetes and its ecosystem, you'll have no problems reaping its advantages even for small deployments. If that's not the case, then by all means, pick something else.
chilicuil 8y ago
I agree with the idea the post is trying to do but not with the justifications, I think it's wrong to compare Kubernetes vs rsync or ansible, it resolves a different problem, container cluster management, a more appropriate comparison would had been to compare with simpler solutions in the same domain, such as docker swarm or nomad.
- Docker_Docker 8y ago
  Or with smth even simpler, like condo (https://github.com/prepor/condo https://github.com/prepor/condo)
- sklivvz1971 8y ago
  I think the whole point of the article is that k8s solves a different problem: orchestrating large sets of images if your application uses a significant portion of a datacenter. The problems one _actually_ has on a personal projects are indeed solved with simple tools like rsync.
marenkay 8y ago
You could also have told that it is a very complex system where one still just runs Bash scripts to solve exactly the same problems as on bare metal, VMs, etc.
- icebraining 8y ago
  That's why I never use computers, everything can be done with pencil and paper, it just takes a bit longer.
  - marenkay 8y ago
    Can't hear you, still waiting for your reply letter! :-D
AYBABTME 8y ago
Kubernetes is an operating system. Using it to run your software is as overkill today as running your own Linux server was overkill before that. Maybe you just need to run on Heroku and don't need the complexity of writing systemd service files? In the end, the steps you take to deploy with rsync and run your systemd service are the same (conceptually) you'd take to run on K8S, but translated to some YAML and a docker push. In one case you need to learn a new paradigm, in the other case you deal with something you already know. Not having to learn something new is an argument, but it doesn't mean your bare-Linux approach is simpler than the K8S approach. You just know it more.
tomc1985 8y ago
Why is there always this foregone conclusion that everyone is going to do their hobby projects on AWS or GCP or paid cloud platforms? You can get fast baremetal servers off the gray market super cheap, pay once and you're set.
- swebs 8y ago
  Also something like Linode, Digital Ocean or even NearlyFreeSpeech are all happy compromises. That way you can have a static IP and not have to worry about power, cooling, or networking.
barbecue_sauce 8y ago
What about using Kubernetes to manage several personal projects simultaneously? Different namespaces, but with a single point of administration.
tracker1 8y ago
I would say to the author that for most small/personal projects that dokku is probably about as extreme as you want/need. Use Docker for (Windows|Mac|Linux) locally as needed, and use dokku for your deploy target. A $40 DO/Linode vm will go a long way for small scale. I've even setup round-robin load balanced deployments, where the app just deploys to two hosts with the exact same config. Works great on smaller things. Of course, if you're in a workplace on a project likely to see more than a few hundred simultaneous users in a given application, definitely look at what K8s offers. Edit: as to deploys, get CI/CD working from your source code repository. GitLab, Azure DevOps (formerly VSTS), CircleCI, Travis and so many others are free to very affordable for this. Take the couple hours to get this working, and when you want to update, just update your source repo in the correct branch.
amthna 8y ago
kubernetes for some, miniature american flags for others.
djhworld 8y ago
What are people classing as personal projects here? I have a bunch of raspberry pi's running docker that I throw some things on to run, and have some custom scripts to pull a new image and restart the container when I want to do an update. But they're tiny, tiny things that are very personal (i.e. they have 1 user - me) If you're getitng to the point where you need to scale things using a kubernetes cluster or whatever it seems to me like that thing has graduated from "personal project" to an actual product that needs the features of kubernetes like reslience and so on. I mean, I'd love the idea of having a kubernetes cluster to throw some things onto but I really don't have the patience to set it all up right now, it seems way too much cost and effort
michaelmior 8y ago
> Of course, they won't work for any project. I assume "any" should be "every"?
- emodendroket 8y ago
  Any as in just any.
  - michaelmior 8y ago
    Sure. It seems much more ambiguous written as it is though.
whydoineedthis 8y ago
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 elixer's perspective. Dealing with big data takes extra consideration. etc. etc. All said, if you have an interest in DevOps/Ops/SysAdmin type technologies, learning Kubernetes is a fine way to spend your time. Once you have a few patterns under your belt, you are going to run way faster at moving your stack to production for real users to start using, and that has value. I think the initial author (not this article, the other one) was just pointing out that you can indeed run kubernetes pretty cheap, and that is useful information and good introduction. This article is clickbait designed to mooch off of the others success.
- emodendroket 8y ago
  > 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.
  - whydoineedthis 8y ago
    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.
hosh 8y ago
I have deployed by hand, with Capistrano, with Chef, with Heroku, with systemd, with Docker, with AWS EC2, and with Kubernetes. Like everything, there are tradeoffs. If there were a fairly easy way to do a one-node Kubernetes setup (say, Minikube), I would probably just go that route. One doesn't have to use the full feature set of Kubernetes to get one or two things that are advantageous. As it is, I setup Minikube for the dev machines for the team I am on. I might consider Kubernetes for my personal side project if I knew Minikube would do well for machines under 1 GB of memory (it doesn't really). The pre-emptible VMs that cost less than $5 is interesting, and I might do something like that.
adamc 8y ago
Minor word nit: "alright" is not a word. Or shouldn't be. It's not "all right".
giobox 8y ago
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 author mentioned he was happy with using Ansible, Systemd etc instead (which are all reasonable tools for what they are) he lost me - this is collectively much more work for me as the sole developer than a simple Docker container setup for virtually all web app projects in my experience. If you understand these relatively complex tools, you can likely learn Docker well enough in about an hour or two, the payoff in time savings in the future will make this time well spent. In my experience "Dockerising" a web app is much, much less time consuming than trying to script it in Ansible (or Chef, Puppet, <name your automation tool>) and of course much less error prone too. I've yet to meet an Ansible setup that didn't become brittle or require maintenance eventually. If you are using straight forward technologies (Ruby, Java, Node, Whatever) your Dockerfile is often just a handful of lines at most. You can even configure it as a "service" without having to bother with Systemd service definitions and the like at all.
- imhoguy 8y ago
  Ansible + Docker play well together and are both a weekend effort to learn and use on side-project. Both work fine for me on cheap dedicated machine. Ansible is a good documentation of how the bare metal host is configured including Docker setup and compose like config[0]. Docker handles apps setup, isolation and local networking nicely. Then playing with Kubernetes on private project would have only Résumé-value for me. [0] https://docs.ansible.com/ansible/latest/modules/docker_container_module.html https://docs.ansible.com/ansible/latest/modules/docker_conta... (check other docker modules too)
- ngrilly 8y ago
  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)?
beat 8y ago
Back when I was trying to do a startup full-time, I avoided Kubernetes because of the steep learning curve. Now that I'm back to being a regular employee, I've learned Kubernetes out of necessity, and it's great. So if I go back to working on the startup, I'll do it on Kubernetes, because it will save me time and ops grief. But it will save time and grief because I already know it now.
gant 8y ago
I am sort of a kubernetes person at work, and I just wasted 3 hours trying to get a cluster up with Rancher. Everything worked fine, except somehow the network started isolating namespaces and the nginx ingress couldn't reach my service. So I'm calling it quits for now. Just running the cluster requires a small ops team.
thrower123 8y ago
Having to worry about redundancy and scaling out on a one-man personal project is a very enviable problem to have. Personally, I'm just going to stick with some kind of paas that gives me a managed IIS or Apache type webserver that I don't have to frig with, and focus my energies on actually building the project.
mychael 8y ago
Thank you for writing this. We've reached peak Kubernetes fanboyism.
lazyant 8y ago
He makes some valid points but I think if you want to write a blog entry about why "B" is not good for a case and you rather use "A" (that you already know), then you should at least try "B" technology; it doesn't seem the author has even tried k8s.
strzibny 8y ago
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/ https://vpsformakers.com/.
throw2016 8y ago
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.
tiangolo 8y ago
I don't get why Docker Swarm mode is so underrated. Docker Compose is excellent for local development, and Docker Swarm mode uses the same file and is almost the same thing. Some minor additions in extra docker-compose files and it's ready for production in a cluster. For the same $5 bucks in a full Linux VPS with Linode or DigitalOcean (or even the free tier in Google Cloud) you can get a full cluster, starting with a single node, including automatic HTTPS certificates, etc. Here's my quick guide, with a Linux from scratch to a prod server in about 20 min. Including full-stack app: https://github.com/tiangolo/full-stack/blob/master/docker-swarm-cluster-deploy.md https://github.com/tiangolo/full-stack/blob/master/docker-sw...

481 points by carlosrdrz 8y ago

yes, there is a learning curve, but once you have your system in place (for local Kuberenetes Development as well as deployment), then, even of a web-sites, it is a breeze. But yes, still need to be organized.

reilly3000 8y ago

Warning to those who think Fargate is green pastures: it has its own learning curve. Also, it costs about ~1.8-2.5X the price of standard EC2 for the convenience. Don't waste your money on it for long-running containers that will rarely need to scale.

carlosrdrz 8y ago
Thanks for sharing your thoughts! I wrote about Fargate because I like the idea of having a service that manages both masters AND workers and where you only need to care about the API, but didn't really try it yet. That was my impression as well, though. Even the use cases mentioned in the pricing site are just containers running for a few hours a day, and not long-running services like servers.
- tilolebo 8y ago
  The smallest fargate container in us-east-1 will cost you USD 13 per month if you never shut it down. Avoid using a load balancer as they are quite pricey (although it will allow you to create and use auto-managed SSL certificates for free.) Of course you will also pay for egress traffic. The nicest part of Fargate is that: * you can define your whole cluster using a docker-compose like format. * you can manage your cluster using the ECS CLI. No extra tool needed.

jitl 8y ago

I’m itching to replace my home server’s FreeBSD with Linux and Kubernetes. I use it (& build dev tools for others) at work plenty so for me, the learning curve is in the past. I’m not sure if I would recommend this journey for others, but I also wouldn’t recommend FreeBSD to anyone, either. In both cases, you know what you’re getting in to - something complex, opinionated, powerful, and industrial strength.

barrystaes 8y ago
Try Unraid on your home server: boots from USB and runs in memory, no raid risks but have network share span several HDDs, parity HDDs, use SSD for cache. No kubernetes involved - just a webinterface to run containers, install dockers as "apps" on your server. And Unraid is linux, you can but dont need to tinker. Unraid is how i started using Dockers and became happy friends with my home server again. (tm)
- jitl 8y ago
  I think you misunderstand me: my objective is to tinker. Before, I was tinkering with FreeBSD, now I will be tinkering with Kubernetes. Thanks for the recommendation though.
tannhaeuser 8y ago
You'll know this already but I'd say when you're coming from FreeBSD you'll be disappointed with Docker in particular, because it serves no purpose in the (usually) well-organized BSD world where the good stuff is built from source, and developed to POSIX guidelines most of the time anyway. Docker is just a workaround for the perceived mess of shared libraries in the Linux world of multiple O/S vendors (by not using shared libs in the first place which could be solved by statically linking everything), and FreeBSD's jails is IMHO superior as sandbox technology anyway.
- jitl 8y ago
  I found the jails ecosystem as old and creaky as FreeBSD itself; the technology is good, and everything makes sense, but after using Docker on Mac and Linux for a while, I've started to prefer the lighter-weight and more user-friendly abstractions. If there was a Jailfile equivalent for FreeBSD and a command-line tool with the same interfaces as docker, namely `docker run --rm -it ...`, I might be staying on FreeBSD.

jypepin 8y ago

I totally agree with this article. I'm giving a point of a view of a pure developer who knows nothing about DevOps things and managing servers. I kind of know what NGINX is and barely know how to configure something like systemd. I recently setup a digital ocean droplet and setup my blog there to actually understand how it works. It was great because I learned a ton and feel in control. Pretty simple setup - single droplet, rails with postgres, capistrano to automate deploys and a very simply NGINX config. It took me multiple days to setup everything, compared to the 5 minutes Heroku would have required - and it's not as nice as what Heroku offers. Still, I'd wait as long as I can to get out of something so simple as Heroku for _anything_. I understand it gets expensive quickly, but I really want to see the cost difference of Heroku vs the time spent for the engineering team to manage all the complexities of devops, automated deploys, scaling, and I'm not even mentioning all the data/logging/monitoring things that Heroku allows to add with 1 click.

rehemiau 8y ago
Did you try preconfigured Dokku images on Digital Ocean?
- acjohnson55 8y ago
  I've heard of Dokku as a "run your own Heroku" solution. Is there a good guide for this combo?
  - josegonzalez 8y ago
    The "quick-start" installation process on our homepage is `curl | bash` on a plain Ubuntu/Debian/Centos server (you can also run the commands manually, which are also outlined on that page). If you go through the web installer - which allows you to add your ssh key and setup a global domain - you'll be redirected to our deployment tutorial here: http://dokku.viewdocs.io/dokku/deployment/application-deployment/ http://dokku.viewdocs.io/dokku/deployment/application-deploy... - Dokku homepage: http://dokku.viewdocs.io/dokku/ http://dokku.viewdocs.io/dokku/
de_watcher 8y ago

wheresvic1 8y ago

Totally agree with the author, for my side projects in Node.js, I use the following: - pm2 for uptime (pm2 itself is setup as a systemd serivce, it's really simple to do and pm2 can install itself as a systemd service) - I create and tag a release using git - on the production server, I have a little script that fetches the latest tag, wipes and does a fresh npm install and pm2 restart. - nginx virtual host with ssl from letsencrypt (setting this stuff was a breeze given the amount of integration and documentation available online) Ridiculously simple and I only pay for a single micro instance which I can use for multiple things including running my own email server and a git repo! The only semi-problem that I have is that a release is not automagically deployed, I would have to write a git hook to run my deployment script but in a way I'm happy to do manual deployments as well to keep an eye on how it went :)

striking 8y ago
Drone CI could make this whole process automated and preserve your ability to inspect the logs.
Draiken 8y ago
Honestly, you could do that in almost the same time on Kubernetes. I understand why people might not want to invest the time onto learning a new technology, but that's not a reason to say it's a bad fit. If you know how to use Kubernetes, doing these bash scripts and doing a few YAML files will take basically the same time and the end result will be vastly superior on Kubernetes.
- Aeolun 8y ago
  Good luck setting up an email server on kube. Or a git repository for that matter
  - denvrede 8y ago
    Why exactly do you think someone needs luck with that? I'm honestly curious.
  - 8y ago

majewsky 8y ago

I looked into using Kubernetes for my personal servers, but I abandoned the idea when I saw that the minimal Kubernetes setup uses more compute resources than all the services [1] it's supposed to manage combined (e.g. 0.5 GiB RAM vs. 0.25 GiB, which is substantial on a 1/1 VM). And that's before you consider that a single-server setup is not The Right Way (TM) in k8s land. [1] Gitea (Github clone), Murmur (voice-chat server), Matrix Synapse (instant messaging), Prosody (XMPP), nginx (for those services and for various static websites)

zeeZ 8y ago
IMHO Kubernetes only makes sense if you can, or want to, run multiples of things that are either stateless or clustered in some way, or another copy for a different purpose. Run two instances of something if you want to survive a single crash or a node update. Run another copy of your application stack if you want to try out a different version or config. Without looking at the docs, most of the things in your list are single-instance stateful applications, so unless you plan to run another copy of them for a different purpose, K8S is overkill.

vbsteven 8y ago

I've been thinking about setting up a small Kubernetes cluster for hosting some smaller client projects (read websites, shopping carts, API's, admin panels). My current setup uses a couple of Hetzner dedicated machines and services are deployed with ansible playbooks. The playbooks install and configure nginx, install the right version of ruby/java/php/postgres, configure and start systemd services. These playbooks end up copied and slightly modified for each project, and sometimes they interfere with one another in sublte ways (different ruby versions, conflicting ports, etc) With my future Kubernetes setup I would just package each project into its own self-contained container image, write a kubernetes deployment/pod spec, update the ingress and I'm done.

grillorafael 8y ago
I recommend having a look at DCOS
- p_l 8y ago
  I recently started working with DCOS, and so far it seems that while it might have been more mature and ready platform 2-3 years ago, today I have to deal with issues I don't have to care about on K8s
  - grillorafael 8y ago
    Curious to know what. We run a DCOS cluster with 40+ machines and we have to deal with pretty much nothing
hardwaresofton 8y ago
If you can find the time to get up to speed on Kubernetes, I would say do it. I actually have a weirdly similar setup to you (I run on Hetzner and used and still use ansible), and I've written about it, most recently when I switched my single node cluster to Ubuntu 18.04 [0]. In the past I've also run a single node kubernetes clusters on CoreOS Container Linux, Arch, and back to CoreOS Container Linux in that order, from versions 1.7~1.11. [0]: https://vadosware.io/post/hetzner-fresh-ubuntu-install-to-single-node-kubernetes-cluster-with-ansible/ https://vadosware.io/post/hetzner-fresh-ubuntu-install-to-si...

cs02rm0 8y ago

I don't even want to use it for commercial projects. It needs a certain scale before the overheads are worth it.

cs02rm0 8y ago
Didn't expect this comment to come back from being voted down so much! Guess it splits opinion.
- vesak 8y ago
  People are crazy (literally) about Kubernetes.

hardwaresofton 8y ago

If you can devote some time and learn the underpinnings, Kubernetes is great for personal projects. I personally use it for 1 business website, 1 blog, 2 3 tier applications (backs are SQLite though) and 1 3-tier client project. Where kubernetes shines is that that it handles most things in a principled, and self-consistent manner -- once you've made your way up the learning curve, you can think in terms of kubernetes without having many hiccups. I'd argue that a lot of the complexity people find in Kubernetes is essential when you consider what it takes to run an application in any kind of robust manner. Take the simplest example -- reverse proxying to an instance of an application, a process (containerized or not) that's bound to a local port on the machine. If you want to edit your nginx config manually to add new upstreams when you deploy another process, then reload nginx be my guest. If you find and setup tooling that helps you do this by integrating with nginx directly or your app runtime that's even better. Kubernetes solves this problem once and for all consistently for a large amount of cases, regardless of whether you use haproxy, nginx, traefik, or whatever else for your "Ingress Controller". In Kubernetes, you push the state you want your world to be in to the control plane, and it makes it so or tells you why not. Of course, the cases where Kubernetes might not make sense are many: - Still learning/into doing very manual server management (i.e. systemd, process management, user management) -- ansible is the better pick here - Not using containerization (you really kinda should be at this point, if you read past the hype train there's valuable tech/concepts below) - Not interested in packaged solutions for the issues that kubernetes solves in a principled way that you could solve relatively quickly/well adhoc. - Launching/planning on launching a relatively small amount of services - Are running on a relatively small machine (I have a slightly beefy dedicated server, so I'm interested in efficiently running lots of things). A lower-risk/simpler solution for personal projects might be something like Dokku[0], or Flynn[1]. In the containerized route, there's Docker Swarm[2] +/- Compose[3]. Here's an example -- I lightly/lazily run https://techjobs.tokyo https://techjobs.tokyo (which is deployed on my single-node k8s cluster), and this past weekend I put up https://techjobs.osaka https://techjobs.osaka. The application itself was generically written so all I had to do for the most part was swap out files (for the front page) and environment variables -- this meant that deploying a completely separate 3-tier application (to be fair the backend is SQLite), only consisted of messing with YAML files. This is possible in other setups, but the number of files and things with inconsistent/different/incoherent APIs you need to navigate is large -- systemd, nginx, certbot, docker (instances of the backend/frontend). Kubernetes simplified deploying this additional almost identical application in a robust manner massively for me. After making the resources, bits of kubernetes got around to making sure things could run right, scale if necessary, retrieve TLS certificates, etc -- all of this is possible to set up manually on a server but I'm also in a weird spot where it's something I probably won't do very often (making a whole new region for an existing webapp), so maybe it wouldn't be a good idea to write a super generic ansible script (assuming I was automating the deployment but not with kubernetes). Of course, Kubernetes is not without it's warts -- I have more than once found myself in a corner off the beaten path thoroughly confused about what was happening and sometimes it took days to fix, but that's mostly because of my penchant to use relatively new/young/burgeoning technology (for example kube-router recently instead of canal for routing), and lack of business-value to my projects (if my blog goes down for a day, I don't really mind). [0]: http://dokku.viewdocs.io/dokku http://dokku.viewdocs.io/dokku [1]: https://github.com/flynn/flynn/ https://github.com/flynn/flynn/ [2]: https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ [3]: https://docs.docker.com/compose/ https://docs.docker.com/compose/

dropmann 8y ago

For me also the overhead played a big role, to just get a bare kubernetes cluster you already need 3 nodes + 1-2 load balancers. In case you are using GKE, you actually need two ingresses to support IPv6 + IPv4 This adds up to like 10 times the cost of an single droplet. For personal projects this seems kind of wasteful to me.

z3 8y ago

kubernetes has more advantages than pure horizontal scaling capacity. there are services, secrets, networking etc, which are useful for small size projects at the same way as big ones. I agree that it can be over kill, but I would not throw away whole kubernetes only for assumptions base on the size of the projects.

comboy 8y ago

In my opinion, the best technology for personal projects is the one that you don't know yet. They are a great opportunity to play around stuff which really is the only way of learning something new. Unless the personal project is something that you really care about, potential startup or something like that, then obviously you choose something that you are already proficient in because then it's about getting stuff done and moving forward. So while it may make sense to discuss what technology is good or bad for some kind of companies, I think we won't arrive at any ultimate conclusion like "X is good/bad for personal projects".

solatic 8y ago

Oh 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 I'm thinking of playing around with a Raspberry Pi or other SBC, do I need to install Kubernetes on the SBC first? If I'm thinking of playing around with IoT or serverless, should I dump AWS- or GCE-proprietary tools because nobody will ever run anything that that can't run on Kubernetes ever again? If I'm going to play around with React or React Native, should I write up a backend just so I can have something that I can run in a Kubernetes cluster, because all hobbyist projects must run Kubernetes now, because it's cheap enough for hobbyist projects? If I'm going to play around with machine learning at home, buy a machine with a heavy GPU, figure out how to get Kubernetes to schedule my machine learning workload correctly instead of just running it directly on that machine, because uhhh maybe someday I'll have three such machines with powerful GPUs plus other home servers for all my other hobbyist projects? No, no, no, no, no. Clearly. But maybe I envision my side project turning into full-time startup some day. Maybe I see all the news about Kubernetes and think it would be cool to be more familiar with it. Nah, probably too expensive. Oh wait, I can get something running for $5? Hey, that's pretty neat! Different people will use different solutions for different project requirements.

carlosrdrz 8y ago
I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably wrong. I don't think that is wrong. I do think it is probably overkill, and IMO it does introduce operational burden and complexity. That doesn't mean you shouldn't do it, though, if you're interested in exploring the technology, for example.
- Draiken 8y ago

Annatar 8y ago

"I think the point I'm trying to make is: do you actually need all of this?" Yep! For any thing which goes beyond the initial viability test, I make an OS package. SmartOS has SMF, so integrating automatic startup/shutdown is as easy as delivering a single SMF manifest, and running svccfg import in the package postinstall. For the configuration, I just make another package which delivers it, edits it dynamically and automatically in postinstall if required, and calls svcadm refresh svc://... it's easy. It's fast. The OS knows about all my files. I can easily remove it or upgrade it. It's clean. When I'm done, I make another ZFS image for imgadm(1M) to consume and Bob's my uncle.

fcgravalos 8y ago

I can't agree more with the author ;). I work in my day to day 100% and fully dedicated automating Kubernetes cluster lifecycle, maintaining them, monitoring them and creating tools around it. Kubernetes it's a production-grade container orchestrator, it solves really difficult problems but it brings some challenges though. All of their components work distributed across the cluster, including network plugins, firewall policies, the control plane, etc. So be prepared to understand all of it. Don't get me wrong, I love Kubernetes and if you want to have some fun go for it, but don't use the HA features as an excuse to do it. But overall saying "NO" to rsync or ansible to deploy your small project just because it's not fancy enough it sounds to me like "Are you really going to the supermarket by car, when there are helicopters out there?" Great article!

Annatar 8y ago

"Oh man, the original article went way over the author's head." No, the author of the Kubernetes article completely, so utterly missed the point that it's not even funny: none of those Kubernetes complications are necessary if one runs SmartOS and optionally, as a bonus, Triton. Since doing something the harder and more complicated way for the same effect is irrational, which presumably the author of the Kubernetes article isn't, I'm compelled to presume that he just didn't know about SmartOS and Triton, or that the person is just interested in boosting their resume rather than researching what the most robust and simplest technology is. If resume boosting with Kubernetes is their goal then their course of action makes sense, but the company where they work won't get the highest reliability and lowest complexity that they could get. So good for them, suboptimal for their (potential) employer. And that's also a concern, moreover, it's a highly professional one. I'm looking through the employer's eyes on this, but then again, I really like sleeping through entire nights without an incident. A simple and robust architecture is a big part of that. Resume boosting isn't.

yebyen 8y ago
While that's great, and I thought about plugging my own containers project here too, to get it some exposure and possibly help someone (we're trying to help people get on the train, and that's commendable, I didn't downvote you) now you've gone from something bespoke to something basically singular, where Kubernetes is a leading industry standard with the weight of at least[1] 77 vendors who have sought and achieved conformance[2] with their own distributions of Kubernetes. I haven't heard of Joyent or SmartOS in years! I am super surprised to hear of anyone recommending it today as a competitor to Kubernetes, and I have no facts or deep understanding of that platform so I won't belabor you with an argument about how Kubernetes is better. (I can't say if it is or isn't.) It's just not in the same ballpark. I'm glad it works for you. I'm especially glad to hear about another option (that we could potentially replace our bespoke deployments with), because the more of these things I know about, the louder I can clamor to upper management about the fact that we're not using any of these technologies yet, and we should be (to sleep through the night!) I learned about Kubernetes through Deis Workflow. It took years to understand Kubernetes from end-to-end, and I was already a container veteran when Deis moved to k8s. I resisted! I caved. I came over, now I have years of experience with Kubernetes, and I can't say I'd recommend anything else. "Those complications" are all very hard to get over, but then ... you get over them! And largely don't have to do that again. If you are on Kubernetes, then you are not locked in to any cloud provider (unless you have opted into another technology that made you locked in.) I can't say the same for Triton. For the purposes of disclosure, I am a member of Team Hephy, the open source Deis Workflow fork. (Deis Workflow is EOL and Hephy is the continuation.) Workflow is how I learned Kubernetes, and I would still recommend it highly to anyone else that wants to learn Kubernetes. But I will not kid anyone into thinking it's going to happen overnight. (With Workflow though, you can absolutely start using it productively in about an hour.)[3] [1]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb... [2]: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ [3]: https://web.teamhephy.com https://web.teamhephy.com or https://blog.teamhephy.info/#install https://blog.teamhephy.info/#install

codegladiator 8y ago

Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me". You don't need to run a new cluster for every project. You can deploy multiple projects in a single cluster. I was running close to 5 different projects in a single cluster, backed by about 3-6 machines (machines added/removed on demand). Kubernetes is basically like your own heroku. You can create namespaces for your projects. No scripts. You can deduce everything (how is a service deployed, whats the config, whats the arch) from the config files (yml) > Is a single Nginx virtual host more complex or expensive than deploying a Nginx daemon set and virtual host in Kubernetes? I don't think so. Yes it is. I wonder if the author has actually tried setting this themselves. I do realise i had similar opinions before I had worked with kubernetes, but after working with it, I cannot recommend it enough. > When you do a change in your Kubernetes cluster in 6 months, will you remember all the information you have today? Yes, why does the author think otherwise ? Or if this is a real argument why does the author think their "ansible" setup would be at the top of the head. I had one instance where I had to bring a project back up on prod (it was a collection of 4 services + 2 databases not including the LB) after 6-8 months of keeping it "down". Guess what, I just scaled the instances from 0 to 3, ssl is back, all services are back, everything is up and running. This is not to say you wont have issues, I had plenty during the time i started trying it out. There is a learning curve and please do try out the ecosystem multiple times before thinking of using it in production.

carlosrdrz 8y ago
> Frankly the article is filled with FUD and the author justifies everything with "i think/what if/my way is fine for me". It is just my opinion after all. I'm just trying to share my thoughts :) > Yes it is. I wonder if the author has actually tried setting this themselves. I've used K8s for months in production, maintaining a few clusters at my previous job.

pstadler 8y ago

> Do you want to do all of this because you think is fun? Or because you want to learn the technology? or just because? Please, be my guest! [...] Kubernetes is likely here to stay. If you're interested in running a cluster to undestand what the hype is all about and to learn something new, you should do it. Also, ignore everybody telling you that this platform wasn't meant for that. Complexity is a weak argument. Once your cluster is running you just write a couple of manifests to deploy a project, versus: ssh into machine; useradd; mkdir; git clone; add virtual host to nginx; remember how certbot works; apt install whatever; systemctl enable whatever; pm2 start whatever.yml; auto-start project on reboot; configure logrotate; etc. Can this be automated? Sure, but I'd rather automate my cluster provisioning.

vorpalhex 8y ago
> Complexity is a weak argument I see you've never tried to upgrade a running kubernetes cluster or been in an on call schedule for one. It's a new technology that is still maturing but it has a lot of moving parts all of which require a fair bit of understanding and which change on a regular basis. Hell, just a few months ago the ACM agent totally got rewritten and now you have a choice between alpha software or a deprecated project!
- pstadler 8y ago
  I treat my cluster as immutable. My setup is open source: https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide
carlosrdrz 8y ago
I will also invite everyone to try it and I also believe K8S is here to stay. I think K8S makes a lot of sense for lots of workloads, but I don't think it makes sense to maintain a k8s cluster to run personal projects. About complexity, what you're saying is true, but I think "once your cluster is running" is making a lot of assumptions about what is actually running in the cluster in terms of infra and what workloads you can run there.
- 8y ago

stuaxo 8y ago

The point about complexity is exactly right. Every new thing that you add, adds complexity. If that thing interfaces with another, then there is complexity at the interfaces of both. Modern tools that atomise everything reduce density (and thus complexity), but people aren't paying attention to the amount of abstractions they are adding and their cost.

ataturk 8y ago

I can't think of any reason why I would need container orchestration at home. Seems like swatting flies with a bazooka to me.

isugimpy 8y ago

For random toy projects, spinning up a whole Kubernetes cluster is absolutely overkill (unless part of the project is learning Kubernetes). The thing is as you get further along, for some applications, it becomes harder and harder to move to a container-based design as you have to unwind all the weird dependency mappings. I've got an app I've been involved with containerizing for a client at work, and they're dead set on sticking with an Ubuntu 14.04 base container, because they legitimately don't know if it'll even function on a more modern base, and don't feel they can spare the development cycles to figure it out. Thing is, it started as a toy application, deployed to a server by manually SSHing in and doing a git pull from the repo (not even rsync!) and restarting all the services, and that's still how it's deployed in production today. Containers (and thus Kubernetes) aren't the magical solution to every problem in the world. But they help, and the earlier you can get to an automated, consistent build/deploy process with anything that'll actually serve real customers, the better off you are. Personally, I'd rather design with containers in mind from day one, because it's what I'm comfortable with. There's nothing wrong with deploying code as a serverless-style payload, or even running on a standalone VM, but you need to start planning for how something should work in the real world as early as you can reasonably.

yebyen 8y ago
FWIW, cedar-14 stack is Ubuntu 14.04 and that's been the base of Deis Workflow (now Hephy Workflow) for years. We've been meaning to upgrade to Heroku-16 stack (and eventually Heroku-18) but our resources are limited too, and we've had to fight other dragons like getting a website together, and figuring out the build system. (Deis Workflow was EOL'ed last year, and Team Hephy is the fork/continuation of development, which we can do because Deis developers were all gracious enough to keep everything OSS.) So, back to the point, I'm sure you couldn't deploy your app on Heroku if that's your requirement (because cedar-14 is deprecated, and not available for new deployments anymore) but if you seriously wanted to try containerizing it onto Kubernetes, and if you don't have other obstacles to 12-factor design that you're also not prepared to tackle, then Hephy Workflow v2.19.4 might actually work for you. https://teamhephy.com https://teamhephy.com and https://docs.teamhephy.com https://docs.teamhephy.com I'm sure this probably won't work for you, for reasons you may not have explained, but ... maybe you'd like to look? I'm not doing a great job selling it, the one redeeming quality I've mentioned is that it runs an outdated stack that you need ;)

nimbius 8y ago

I work as an engine mechanic full time, and im learning programming as a hobby. Kubernetes to me is like the shade-tree mechanic vs the professional. Professional mechanics use high grade tools that can cost thousands of dollars each. We have laser alignment rigs, plasma cutters, computer controlled balancing and timing hardware, and high performance benchmarking hardware that can cost as much as the car you're working on. We have a "Kubernetes" like setup because we service hundreds of cars a month. The shade-tree mechanic wrenching on her fox body mustang on the other hand? her hand-me-down tool box and a good set of sockets will get her by with about 90% of what she wants to do on that car. she doesnt need to perform a manifold remap, so she doesnt need a gas fluid analyzer any better than her own two ears. I should also clarify that these two models are NOT mutually exclusive. If i take home an old Chevy from work, I can absolutely work on it with my own set of tools. And if the shade-tree wants to turn her mustang into a professional race car, she can send it to a professional "kubernetes" type shop that will scale that car up proper.

ayyyyy 8y ago
This might actually be the stupidest fucking thing I have ever read.
xtrapolate 8y ago
I don't quite resonate with the analogy here. It's about using the right tool for the job. Most small-scale personal projects, by their very definition, don't require an orchestration framework.
shaklee3 8y ago
This doesn't make sense, and it's really the opposite of what you're saying. K8s is hard, but for large scale you need something robust that's tested at that scale. A collection of shell scripts is more like a beginner tool set. Yes, it's easy to learn, but it will break when you get serious.
- falcolas 8y ago
  For large scale you have to first make your application capable of scaling. That's a bit that's missing from most of these conversations. Only the simplest programs can "scale up" by just adding more programs - most have to be re-architected to move all the state in the program to some other service. That is to say, if scaling is your primary concern, you have a dozen other things more important to fix than your choice to use shell scripts vs. Kubernetes. And, fwiw, Linux has run professional services somewhere around 10x longer on those "beginner tools" than containers have even existed.

doppel 8y ago

I feel that Kubernetes has a lot of "upfront" cost that needs to be tackled - containerization, manifests for all the pods you want to set up, potentially setting up the right persistent storage if needed, user access, logging, etc. And this is still if you use a "hosted" solution with Amazon/Google/Microsoft, if you set it up yourself there is a ton more complexity. Using something you are familiar with, even if it's just a 10-line bash script, a simple virtual private server and the adding an nginx config there, is usually faster than having to orchestrate everything. If you want to invest the time in setting up Kubernetes for all your personal projects, it would probably make sense. Basically, is it worth it? https://xkcd.com/1205/ https://xkcd.com/1205/

kujaomega 8y ago

I read the article. I'm sorry, but my impression about it is the following: Why use Kubernetes in your personal projects when you have got no idea about it?. One think I have experimented after working with Docker for two years, is that once you know it, you will put every service inside a docker. It only takes 5 minutes to do it and the benefits are huge. Kubernetes might be an overkill, but containerize the apps is another thing.

billylindeman 8y ago

This seems like a grumpy and lame rationalization of not wanting to learn something new

pawurb 8y ago

Dokku works quite well for personal projects and is easy to get started with even without much dev ops exp https://pawelurbanek.com/rails-heroku-dokku-migration https://pawelurbanek.com/rails-heroku-dokku-migration

mcs_ 8y ago

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 interface and auto devops is enabled in 3 projects. in office we do not work with docker, containers, cloud etc, we run legacy asp.net 2.0 on-premise without any kind of automation (just a couple of us coordinating the releases and copying and pasting into the customer Windows Server 2008). Kubernetes for personal projects? In my case, after 10 years of on-premise deployments, VM Ware, SQL Clusters, web.config, IIS, ARR and the rest of the things related, YES! I absolutely want 3 hosts for less then 100$, a gitlab account for 4$, a free account in cloudflare, code and deploy.

dsumenkovic 8y ago
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#installing-applications https://docs.gitlab.com/ee/user/project/clusters/index.html#...

JAdamMoore 8y ago

Yes. Exactly. Kubernetes is adding complexity needlessly. People are so dumb, they can't understand that more isn't always better.

wwarner 8y ago

I absolutely love docker for development. It saves so much set up time, and of course is handy later.

caymanjim 8y ago

Kubernetes is just one of many development ecosystem tools that solve real problems and, once you know them, make your life easier. The arguments in this article can apply to any development tool or practice. Why separate your code into multiple files? Why write tests? Why use a code linter? Why use virtual environments? Why write a Makefile? If you're working on a small personal project, or you're a newer developer learning the ropes, or the project is temporary, not important, doesn't need to scale, etc. then it's simply a matter of personal choice. It doesn't make sense to get bogged down learning a lot of tools and processes if there's no compelling business need and you're just trying to get the job done. If you already know how to use these tools, though, they usually make your life a whole lot easier. I learn how to use complex systems in my career, where they're necessary and helpful. I apply these same tools and practices on my personal projects now, because once you know how to use something like Kubernetes, there's little cost to it and many of the benefits still apply.

whydoineedthis 8y ago
> tools that solve real problems and, once you know them, make your life easier. yep, i think you nailed here.

markbnj 8y ago

This whole line of debate is really getting tiresome. Kubernetes has proven its value in production use cases across a wide variety of application domains. That doesn't mean everybody should be using it, any more than the proven value of containers means that everyone should be deploying in them. I've been working with k8s for three years and run multiple production clusters, but if I had some little thing I might very well toss it up on a paas like app engine, or just install it on a free micro instance as the OP suggests. Or... maybe I would create a cluster and run it there. Point is kubernetes is an alternative that I can take advantage of where it makes sense because I've gotten some experience with it. It might make sense for you, it might not, but it's not essential that all developers immediately come to agreement on whether or not all software projects should migrate to k8s by tomorrow.

bauerd 8y ago
I wholeheartedly agree with this. It's one of many HN debates that boil down to whether X is the right tool. Thing is, you can't judge about the usefulness of a tool without factoring in its users. If you and your team have experience with Kubernetes and its ecosystem, you'll have no problems reaping its advantages even for small deployments. If that's not the case, then by all means, pick something else.

chilicuil 8y ago

I agree with the idea the post is trying to do but not with the justifications, I think it's wrong to compare Kubernetes vs rsync or ansible, it resolves a different problem, container cluster management, a more appropriate comparison would had been to compare with simpler solutions in the same domain, such as docker swarm or nomad.

Docker_Docker 8y ago
Or with smth even simpler, like condo (https://github.com/prepor/condo https://github.com/prepor/condo)
sklivvz1971 8y ago
I think the whole point of the article is that k8s solves a different problem: orchestrating large sets of images if your application uses a significant portion of a datacenter. The problems one _actually_ has on a personal projects are indeed solved with simple tools like rsync.

marenkay 8y ago

You could also have told that it is a very complex system where one still just runs Bash scripts to solve exactly the same problems as on bare metal, VMs, etc.

icebraining 8y ago
That's why I never use computers, everything can be done with pencil and paper, it just takes a bit longer.
- marenkay 8y ago
  Can't hear you, still waiting for your reply letter! :-D

AYBABTME 8y ago

Kubernetes is an operating system. Using it to run your software is as overkill today as running your own Linux server was overkill before that. Maybe you just need to run on Heroku and don't need the complexity of writing systemd service files? In the end, the steps you take to deploy with rsync and run your systemd service are the same (conceptually) you'd take to run on K8S, but translated to some YAML and a docker push. In one case you need to learn a new paradigm, in the other case you deal with something you already know. Not having to learn something new is an argument, but it doesn't mean your bare-Linux approach is simpler than the K8S approach. You just know it more.

tomc1985 8y ago

Why is there always this foregone conclusion that everyone is going to do their hobby projects on AWS or GCP or paid cloud platforms? You can get fast baremetal servers off the gray market super cheap, pay once and you're set.

swebs 8y ago
Also something like Linode, Digital Ocean or even NearlyFreeSpeech are all happy compromises. That way you can have a static IP and not have to worry about power, cooling, or networking.

barbecue_sauce 8y ago

What about using Kubernetes to manage several personal projects simultaneously? Different namespaces, but with a single point of administration.

tracker1 8y ago

I would say to the author that for most small/personal projects that dokku is probably about as extreme as you want/need. Use Docker for (Windows|Mac|Linux) locally as needed, and use dokku for your deploy target. A $40 DO/Linode vm will go a long way for small scale. I've even setup round-robin load balanced deployments, where the app just deploys to two hosts with the exact same config. Works great on smaller things. Of course, if you're in a workplace on a project likely to see more than a few hundred simultaneous users in a given application, definitely look at what K8s offers. Edit: as to deploys, get CI/CD working from your source code repository. GitLab, Azure DevOps (formerly VSTS), CircleCI, Travis and so many others are free to very affordable for this. Take the couple hours to get this working, and when you want to update, just update your source repo in the correct branch.

amthna 8y ago

kubernetes for some, miniature american flags for others.

djhworld 8y ago

What are people classing as personal projects here? I have a bunch of raspberry pi's running docker that I throw some things on to run, and have some custom scripts to pull a new image and restart the container when I want to do an update. But they're tiny, tiny things that are very personal (i.e. they have 1 user - me) If you're getitng to the point where you need to scale things using a kubernetes cluster or whatever it seems to me like that thing has graduated from "personal project" to an actual product that needs the features of kubernetes like reslience and so on. I mean, I'd love the idea of having a kubernetes cluster to throw some things onto but I really don't have the patience to set it all up right now, it seems way too much cost and effort

michaelmior 8y ago

> Of course, they won't work for any project. I assume "any" should be "every"?

emodendroket 8y ago
Any as in just any.
- michaelmior 8y ago
  Sure. It seems much more ambiguous written as it is though.

whydoineedthis 8y ago

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 elixer's perspective. Dealing with big data takes extra consideration. etc. etc. All said, if you have an interest in DevOps/Ops/SysAdmin type technologies, learning Kubernetes is a fine way to spend your time. Once you have a few patterns under your belt, you are going to run way faster at moving your stack to production for real users to start using, and that has value. I think the initial author (not this article, the other one) was just pointing out that you can indeed run kubernetes pretty cheap, and that is useful information and good introduction. This article is clickbait designed to mooch off of the others success.

emodendroket 8y ago
> 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.
- whydoineedthis 8y ago
  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.

hosh 8y ago

I have deployed by hand, with Capistrano, with Chef, with Heroku, with systemd, with Docker, with AWS EC2, and with Kubernetes. Like everything, there are tradeoffs. If there were a fairly easy way to do a one-node Kubernetes setup (say, Minikube), I would probably just go that route. One doesn't have to use the full feature set of Kubernetes to get one or two things that are advantageous. As it is, I setup Minikube for the dev machines for the team I am on. I might consider Kubernetes for my personal side project if I knew Minikube would do well for machines under 1 GB of memory (it doesn't really). The pre-emptible VMs that cost less than $5 is interesting, and I might do something like that.

adamc 8y ago

Minor word nit: "alright" is not a word. Or shouldn't be. It's not "all right".

giobox 8y ago

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 author mentioned he was happy with using Ansible, Systemd etc instead (which are all reasonable tools for what they are) he lost me - this is collectively much more work for me as the sole developer than a simple Docker container setup for virtually all web app projects in my experience. If you understand these relatively complex tools, you can likely learn Docker well enough in about an hour or two, the payoff in time savings in the future will make this time well spent. In my experience "Dockerising" a web app is much, much less time consuming than trying to script it in Ansible (or Chef, Puppet, <name your automation tool>) and of course much less error prone too. I've yet to meet an Ansible setup that didn't become brittle or require maintenance eventually. If you are using straight forward technologies (Ruby, Java, Node, Whatever) your Dockerfile is often just a handful of lines at most. You can even configure it as a "service" without having to bother with Systemd service definitions and the like at all.

imhoguy 8y ago
Ansible + Docker play well together and are both a weekend effort to learn and use on side-project. Both work fine for me on cheap dedicated machine. Ansible is a good documentation of how the bare metal host is configured including Docker setup and compose like config[0]. Docker handles apps setup, isolation and local networking nicely. Then playing with Kubernetes on private project would have only Résumé-value for me. [0] https://docs.ansible.com/ansible/latest/modules/docker_container_module.html https://docs.ansible.com/ansible/latest/modules/docker_conta... (check other docker modules too)
ngrilly 8y ago
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)?

beat 8y ago

Back when I was trying to do a startup full-time, I avoided Kubernetes because of the steep learning curve. Now that I'm back to being a regular employee, I've learned Kubernetes out of necessity, and it's great. So if I go back to working on the startup, I'll do it on Kubernetes, because it will save me time and ops grief. But it will save time and grief because I already know it now.

gant 8y ago

I am sort of a kubernetes person at work, and I just wasted 3 hours trying to get a cluster up with Rancher. Everything worked fine, except somehow the network started isolating namespaces and the nginx ingress couldn't reach my service. So I'm calling it quits for now. Just running the cluster requires a small ops team.

thrower123 8y ago

Having to worry about redundancy and scaling out on a one-man personal project is a very enviable problem to have. Personally, I'm just going to stick with some kind of paas that gives me a managed IIS or Apache type webserver that I don't have to frig with, and focus my energies on actually building the project.

mychael 8y ago

Thank you for writing this. We've reached peak Kubernetes fanboyism.

lazyant 8y ago

He makes some valid points but I think if you want to write a blog entry about why "B" is not good for a case and you rather use "A" (that you already know), then you should at least try "B" technology; it doesn't seem the author has even tried k8s.

strzibny 8y ago

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/ https://vpsformakers.com/.

throw2016 8y ago

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.

tiangolo 8y ago

I don't get why Docker Swarm mode is so underrated. Docker Compose is excellent for local development, and Docker Swarm mode uses the same file and is almost the same thing. Some minor additions in extra docker-compose files and it's ready for production in a cluster. For the same $5 bucks in a full Linux VPS with Linode or DigitalOcean (or even the free tier in Google Cloud) you can get a full cluster, starting with a single node, including automatic HTTPS certificates, etc. Here's my quick guide, with a Linux from scratch to a prod server in about 20 min. Including full-stack app: https://github.com/tiangolo/full-stack/blob/master/docker-swarm-cluster-deploy.md https://github.com/tiangolo/full-stack/blob/master/docker-sw...