11 ms·

This. Time and again. The number of people who adopt complicated stuff like Kubernetes for what is essentially a couple of web servers and a database is too hig

• codegladiator 8y ago
  I had an excellent time working with kubernetes and I am practically a one person company. Kubernetes frees my mind from so many things that now I hate to work without it. Couple of those things include: - automated ssl - centralized logging - super easy scaling up and down (going from 1 instance to 2 instance is a headache manually) - centralized auth (have a service which doesnt have built in auth?) - super easy recovery (containers recreated/volumes attached automatically/apps just work unless you have db type of application which shouldn't be just restarted, which is rare) - Smooth CI/CD (gogs/jenkins/private docker image repository) As for the "execute query" example, why is it such a headache ? I just "kubectl ssh <container>" and I am in. > I know a bio scientist who spent Super obscure example. Kubernetes is definitely not for non-tech people. And I didn't pick k8s overnight. Spent a year doing playful POCs before deploying in a production environment. If the only thing thats stopping you from using k8s is the learning curve, I suggest you to go ahead and learn it. Its a huge boon.
  • bthornbury 8y ago
    The learning curve is sharp. The amount of things happening you don't have awareness of is also worrisome (to me). Source: I am also using Kubernetes in production, migrating off it soon.
    • austinjp 8y ago
      It would be interesting if you could briefly say your reasons for moving away from K8s and what you're moving to.
      • bthornbury 8y ago
        Sure. The largest reason is cost. My small deployment (3 nodes) is running around $100 / mo on AWS (That's my app, nginx, redis, and postgres). It doesn't even need 3 nodes, I don't recall if 3 is the minimum, but realistically I only need one (for now). For larger projects this is probably a non-issue. Second largest reason, is that really I have no idea what is going on on these nodes, and I probably never will. Magically my services run when I have the correct configurations. Not to say that's always a bad thing, but I've found it difficult to determine the default level of security as a result of this. A third reason is the learning curve. This is less of an issue because I've invested the time to learn already. But like, the first time I tried to get traffic ingressed was painful. As to what I'm moving to, I migrated one of my websites to a simple rsync + docker-compose setup and am pretty happy with it. In the past, I ran ansible on a 50 node cluster and it worked really well.
        • rconti 8y ago
          I'm not really clear on how moving off Kubernetes saves you money in this scenario. Seems like the most likely source of the cost is the AWS, which is the non-free part. I'm just learning k8s, so I feel you on the learning curve.
          • bthornbury 8y ago
            Kubernetes has a minimum node count. Moving to one node, saves cost, by a factor of 3. Not to mention all of the other resources it creates (load balancers).
  • sklivvz1971 8y ago
    > As for the "execute query" example, why is it such a headache ? I just "kubectl ssh <container>" and I am in. It's slow as hell. > I had an excellent time working with kubernetes I'm happy for you, seriously, and I'm not claiming general validity of my experience. What I am disputing is the blog post (which does claim general validity).
  • reacharavindh 8y ago
    Thanks for sharing your experience. I question myself whether it is necessary to hide my operational needs behind a behemoth of complexity like Kubernetes. The list of conveniences you mentioned sounds like magic you get from Kubernetes. What if there is a problem with any of them? Missing logs? Inappropriate scaling? Auth failures? or worse, failure of Auth system? Easy recovery? what if there were failures to checkpoint/backup/snapshot containers? CI/CD is good regardless of whether you use Kubernetes or not. EDIT: The question is, if you have any of these problems, why is it better to get your head into how Kubernetes deals with those operations & tools rather than dealing with well-defined unix tools that specialise in doing these jobs. syslog instead of however Kubernetes gathers the logs, reading FreeIPA docs instead of Kubernetes auth system logs? My point is, that to deal with all of the conveniences you mentioned, you need to know their details anyway. Why rely on Kubernetes abstraction if there is no such need? (I'm not trying to being snarky. I'm genuinely curious why you think it is a good idea. If you convince me otherwise, perhaps I would start adopting Kubernetes as well.) I run my cluster(I'm a sysadmin) with a couple of OpenBSD server that runs redundant DNS and DHCP. a CentOS 7 box that runs FreeIPA as central Auth. an OpenBSD server that acts as public facing SSH server. about 20 nodes, all provisioned using kickstart files, and then configured using Ansible. They run databases, web servers, batch jobs, Git, etc. A single server that runs ELK stack for log analysis. A single server that runs Prometheus for quick aggregated monitoring. Do you think I should switch over to Kubernetes for any benefits?
    • merb 8y ago
      how often do you update your nodes?!
      • StudentStuff 8y ago
        It sounds like the prior commenter Ansiblized their environment, they likely update the 20+ machines often since its not much of an effort.
      • reacharavindh 8y ago
        All nodes are bare-metal servers that run CentOS 7, and are configured strictly via Ansible. If a node experiences a hardware failure, we just pick another spare server and run our Ansible playbook on it + a script for infrastructure changes like DNS & DHCP. Our workload is not strictly attached to physical resource. So, we have our updates scheduled for every week, with the condition that updates run when there are no user tasks scheduled on them. The other nodes that serve a specific purpose - like database servers, app servers etc, get updated regularly for security updates as & when they are available and necessary, and checked for version upgrades (with scheduled downtime) once every 4 months.
  • brightball 8y ago
    Honestly, this is why so many people just use Heroku.
  • marmaduke 8y ago
    > I am practically a one person company > Spent a year > go ahead and learn it. Its a huge boon. for green field deployment with a 1 year R&D budget for devops, sure K8s is great choice perhaps, but for the rest of us (even in tech)?
  • konradb 8y ago
    Would it be possible to elaborate on centralized auth with an example? I've done a small amount of playing around with k8s but I'd not heard of this specific use case.
  • base698 8y ago
    To play devils advocate, why not use AppEngine or Heroku, that does most of these things and you don't have to manually setup each of the apps with long YAML configs involving resource constraints and restart policies?
    • ownagefool 8y ago
      I gather it's simply less popular because they're proprietary, opaque and opinionated. I suspect we're going to continue to see layers built on top of kubernetes, such as gitlabs autodevops, where for the simple things, you don't need to write any of that, but you can still inspect what they create, and jump off the rails for things that are a bit more complex.
      • dgruesso 8y ago
        Hi, GitLab PM here, thanks for the mention. We're indeed trying to make use of kubernetes inside GitLab as simple as possible. And just to add to your comment, you can try out kubernetes integration (https://docs.gitlab.com/ee/user/project/clusters/ https://docs.gitlab.com/ee/user/project/clusters/) independent of auto devops and vice-versa (https://docs.gitlab.com/ee/topics/autodevops/ https://docs.gitlab.com/ee/topics/autodevops/). Both of these are available in our core offering.
• disiplus 8y ago
  same here, you really have to look at your own needs. i was thinking about using something like that, but at the end of the day i would waste time and energy and complicate my setup a lot for no benefits. We are simply not at that scale, and dont have those problems, and as much as i would like to play with new technology (and i do that privately) cost/benefit calculation for us is not working right now.
• snaky 8y ago
  > This find | xargs mawk | mawk pipeline gets us down to a runtime of about 12 seconds, or about 270MB/sec, which is around 235 times faster than the Hadoop implementation. https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://adamdrake.com/command-line-tools-can-be-235x-faster-...
  • tralarpa 8y ago
    Pipelines of gunzip, find, grep, xargs, awk etc. on RAID disks... good memories. Analyzed terabytes of data with that. Hard to beat because of the zero setup time.
    • kochthesecond 8y ago
      And now your customers expect to see new data immediately reflected in their account. What then?
      • tinco 8y ago
        All those tools are stream processors, why wouldn't the customers see the new data immediately reflected in their account?
      • snaky 8y ago
        It depends. If you have one customer who need it once a week, you add this find-grep-awk script to xinetd and set the PHP page with the couple of fields setting the arguments for the request. If you have a million of customers per hour, you setup a bunch of terabyte-RAM servers with realtime Scala pipeline, and hire a team to tweak it day and night. Because that's a two very different problems. And the worst thing to do is to try to solve the problem X with a tools for problem Y.
      • bufferoverflow 8y ago
        Spawn as many servers as you wish, spread your data between them, run your scripts, generate reports, show it to the customers.
      • 8y ago
• jpalomaki 8y ago
  IMHO the point for running Kubernetes for personal projects would be to share the same virtual/physical machines between multiple projects while still keeping things manageable. Over the years you easily end up with a pile of these projects, which want to keep running mostly for fun and therefore want to minimize the associated fixed costs. Using containers may help in keeping the herd manageable so that you can, for example, move everything to some other hosting provider.
  • TheGrumpyBrit 8y ago
    Precisely. I use Docker for my personal projects whenever possible, because it keeps the host tidy and avoids conflicts. If I want to play with something new, I can just throw it onto an existing server and start playing, rather than deploying a new VM specifically for it. When I get bored, it's a 2 minute job to trash the container.
• ratsimihah 8y ago
  > They're Google wannabies that thinks in Google's scale and the people who, when they show up at their Google interview, nail the part about scaling. Not that Google ever asked me how to scale a project, but it doesn't hurt learning things just for the sake of learning.
  • reacharavindh 8y ago
    Sorry you quoted me in partial context. I said, > They're Google wannabies that thinks in Google's scale but forget that it is utterly unnecessary in their case. Meaning they _unnecessarily_ think in Google's scale when there is no need for it.
    • ratsimihah 8y ago
      I see! My bad then :)
  • ex_amazon_sde 8y ago
    > the people who, when they show up at their Google interview, nail the part about scaling Having interviewed many tenths of engineers at Amazon - no, not really.
    • ratsimihah 8y ago
      Isn't someone who played with e.g. k8s more likely to understand scaling than someone who never cared about it though?
      • Gigablah 8y ago
        That's kinda like saying people who use postgres understand query performance more than people who use mysql.
        • TomMarius 8y ago
          I think it's more like postgres vs csv.
• ownagefool 8y ago
  I really think this kubernetes is complex meme needs to die. I mean, sure, kubernetes _is_ complex. But it's complex in the way that using Rails is more complex than pure Ruby. It's fine when you're playing, or you have a weird subset of problems where you don't care if someone runs or not, but as soon as you deal with the problems of HA, DR, live deployments, secret management, sharing servers, working in a team, etc then if you're solving these issues with ansible and terraform, you're probably just inventing something as complex, and worse, bespoke to your problem. At the end of the day, once you've learned to use kube, it's probably no worse than any other configuration as code based system, and the question is which of us should be learning it and when, and which of us should just be using higher levels of abstractions like gitlabs autodevops. Now, indeed, if you're just hacking and you have no need for a CI and CD pipeline, or reproducibility, etc, then sure, it's probably not the time to learn a hosting framework, but once you do know it, you're free to make an informed opinion on your problem. Personally, I sell kube a lot, but I tend to work for orgs that have several development teams and several apps, and bringing them to a platform seems like a good idea. The question is, should I also put a startup on GKE, or should I do something bespoke where they can't hire another contractor to take over as easily? Personally, I'd go GKE.
  • raesene9 8y ago
    Managed k8s (e.g. GKE) and unmanaged k8s (e.g. kops/kubeadm etc) aren't really the same thing in terms of complexity. GKE takes a lot of the load off by making it Google's problem. The possible downside (which may or may not matter depending on use case) is that you're tied to what Google's control plane provides. So if you want a shiney admission controller, you're out of luck unless they support it. But for basic workloads, it's likely to work well and their management solves a lot of vanilla k8s pain points.
    • peterwwillis 8y ago
      This. It's perfectly fine to use GKE or AWS. Trying to set up your own cloud provider for a small project? Crazy. The amount of hours you have to spend learning how k8s works just to set it up properly from scratch will far exceed the r&d and operational cost of a less sophisticated small project set up from scratch. Pay for managed services, or do it as simple as possible.
• weberc2 8y ago
  Not that the author is right, but he does address exactly these criticims. Besides, that someone used Docker inappropriately isn't evidence that Docker is the wrong tool for personal projects (again, it may be true that Docker is the wrong tool for personal projects, but that is not evidenced by your bio scientist friend scenario).
• groestl 8y ago
  > ... for what is essentially a couple of web servers and a database Interestingly, while the author compares k8s to an SQL database, they actually do not deploy a DB. It's all fun an giggles until you deploy a DB.
• rconti 8y ago
  As someone who's just starting to learn kubernetes (but has a strong background in virtualization and multi-thousand-node environments), I was inclined to agree at first but now see it as more of a modern "home lab" type person. I don't see it as doing it to be a fake-Googler, but more to learn the scalable way of doing things. Or, as worst, the shortcut to understanding the underlying tech. But, isn't that the point of abstraction?