9 ms·

The problem i have with cubernetes is the following: I as a small developer and small server owner don't have the ressources to even get started. The first thin

• Majestic121 7y ago
  You don't need a whole cluster to get started, you can use Minikube locally for example : https://minikube.sigs.k8s.io/docs/ https://minikube.sigs.k8s.io/docs/
  • katsura 7y ago
    Have they solved the high CPU usage problem while it is running (even when no containers are inside)? I don't like my laptop hot, so never could make a switch.
    • ngrilly 7y ago
      Yes, it's a real issue. Kubernetes burns too much RAM and CPU even with no workload.
      • Fnoord 7y ago
        Docker on macOS also suffers from that issue though.
        • mschuster91 7y ago
          Not for me, except for the RAM blocking - I wish that Hyperkit could dynamically allocate and release RAM for the guest machine instead of blocking 2GB (in my case) by default all the time.
        • ngrilly 7y ago
          I haven't noticed that.
        • GordonS 7y ago
          It will use more on MacOS and Windows than on Linux, as it needs to use a sidecar Linux "Moby" VM to run containers. In practice on Windows, this hasn't been an issue for me (64GB RAM in my dev laptop). This will actually finally change soon'ish with Windows at least, I think as part of WSL2. Not sure if anything is going to change on MacOS.
    • ypcx 7y ago
      They haven't. As an example of where this lack of efficiency comes from, recently I've fixed an issue during which I've discovered that the Etcd component of k8s uses periodic (10 sec) liveness checking, where for every check (launching of the etcdctl client), the `runc` binary (from container.d) is executed 3 (three) times. You can imagine this probably just scratches the surface.
      • ngrilly 7y ago
        Ugh! Was the fix committed upstream?
        • ypcx 7y ago
          Yes, this one was a systemd detection in runc, which was causing big log flooding and runtime overhead due to runc being executed so frequently. I initially cached the checks, but later the devs removed them altogether. Still, this is not solving the inefficiencies in k8s. https://github.com/kubernetes/kubernetes/issues/76531 https://github.com/kubernetes/kubernetes/issues/76531
    • bryanlarsen 7y ago
      --vm-driver=none helps a lot with the CPU and especially RAM usage, using k3s instead of minikube helps more.
  • jhanschoo 7y ago
    If uptime is not a concern and only one node is intended, docker-compose is a far more efficient solution to any k8s solution.
    • Majestic121 7y ago
      It might be more efficient but it's definitely not a solution to get up to speed with k8s
      • jhanschoo 7y ago
        I'm sorry, I somehow missed that the top-level commenter was interested in the one-node k8s to get started in it.
• de_watcher 7y ago
  Docker and Kubernetes are on completely different layers. You can't do those comparisons. Kubernetes is like an operating system, Docker is like a format for the executable files. There is no problem with servers. We're running Kubernetes in production on a single Linux machine, essentially using Kubernetes as an alternative OS.
  • smitty1e 7y ago
    Precisely. I'm reading the article and not grasping the technical point. Mainly because the point is non-technical; while I'm not sure that Google is exactly a saintly organization, things like the Summer of Code and giving K8s away have procured some goodwill for them. The whole article is over the head of Joe User (me) who is competent to use Docker but nowhere near deep enough to contribute code to it.
  • Dowwie 7y ago
    Kubernetes seems to be intended for large, complex environments but yours seems to not meet that category. What have you gained by using it?
    • notyourday 7y ago
      Like https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs but for devops.
    • kuschku 7y ago
      (Not OP) I'm running a single node kubernetes cluster because it provides much needed isolation between services as well as, and that's the biggest part, a aingle and simple way to have everything in one place. I can duplicate a service I'm running 1:1 with a new version for testing in 2 minutes, I can tear it down in 2 seconds. I can roll back changes in one command, I can wipe the server and reinstall everything from scratch in 25 minutes. The environment is completely reproducible, and I can with a single command see every config that applies to a service. All the usual deployment trouble is gone, no more weird setups and config situations. All the weirdness is nicely encapsulated.
• dguaraglia 7y ago
  You can run a single-node cluster. Not the best option and overkill if you don't have the need for redundancy, but it might save you some time deploying software. Honestly at that point you might be better running your software using docker-compose or something like that. For development, microk8s is actually very nice: https://microk8s.io https://microk8s.io
• sneystein 7y ago
  I feel until you have atleast a clusterful of services, you shouldn't add that much complexity to your applications. It's much easier to manage a single tower for as long as possible, and slowly migrate to a new one when it seems ripe
• thunderbong 7y ago
  >> I as a small developer and small server owner... You'll never ever need either Docker or Kubernetes or even the latest and greatest javascript frameworks. I started running a server before I knew anything and that server is still purring along happily. But if you're ever targeting an enterprise, either as a freelancer or as an employee, those words are invaluable in your resume. It of course helps if you actually know about those technologies! And when you do get to learn them you'll wonder why everyone is coming full circle!
  • mschuster91 7y ago
    > You'll never ever need either Docker or Kubernetes or even the latest and greatest javascript frameworks. I agree with "no need for k8s and the latest JS frameworks", but strongly disagree on not needing Docker. It is extremely useful for setting up separate development instances for your projects - no matter if you're doing PHP development with N different versions of PHP (as some sites may still be stuck at 5.6 while others are already requiring 7.2 due to Composer dependencies) or, worse, nodejs and Java where each project will have its own requirements for node, Tomcat and whatnot. I personally set up one mega-container for each project which runs all the services required - mysql/pgsql for the database, apache as frontend / mod-php, if needed Tomcat - and can simply shut them down when I'm done working on a project instead of having the databases and servers all consuming memory and resources all the time.
    • mr__y 7y ago
      >It is extremely useful for setting up separate development instances for your projects this. and not only the ability to have different software and versions for each project but also the ability to more or less match the production environment in your dev container for each project.
  • 1337shadow 7y ago
    The point is to deploy immutable images that were clean rebuilt from scratch and tested prior to deployment, rather than upgrading an environment which becomes risky after some time. Another added value is automatic actions based on container watchers, traefik for example will self-configure on the fly when you just spawn a container with the hostname in a label. If deployment becomes that easy then why not leverage gitlab dynamic environment feature and deploy on $branchname.ci.example.com so that you can have say a product owner to review the development prior to merging to master (which would deploy to staging if you have an aggressive CD strategy - which I do)
• pjmlp 7y ago
  Why bother with containers at all at that scale then? We keep on using plain old VMs, while watching everyone rush into containers fashion.
  • tofflos 7y ago
    I like the tooling better and suspect that many other developers feel the same. Docker is more like managing and configuring software libraries and dependencies. You just declare what type of environment you want and it's there. If you change the version number of a dependency the old image is discarded and a fresh one is created. The Dockerfile is managed with the source code. VirtualBox feels like installing a regular computer. It takes a long time and is a lot of manual work. If you want to change something you login on the existing VM until you reach a point where you no longer remember all the changes you've made over the years. The machine is unclean. I realize that there are solutions out there for automating VM deployments but Docker did a good job of catering, and perhaps marketing, to developers.
    • pjmlp 7y ago
      Might be, on large organisations we just make out an order and get our VM. I have more experience with VMware and Hyper-V, as type 1 hypervisors, VirtualBox always felt a bit underpowered.
    • sergiosgc 7y ago
      > VirtualBox feels like installing a regular computer. It takes a long time and is a lot of manual work. If you want to change something you login on the existing VM until you reach a point where you no longer remember all the changes you've made over the years. The machine is unclean. Unfair comparison. People running on VMs usually rely on configuration management to do the install+config part. Think of stuff like Ansible as a Dockerfile for VMs/bare-metal.
      • Spivak 7y ago
        Config management isn't a magic bullet. At the core every config management platform is manual work in a for loop. Lot's of layers in the case of Salt/Puppet to make it a bit more ergonomic but you're ultimately still on the hook for all the server maintenance. No config management is all-encompassing and so without extreme diligence you will lose the state of your servers over time. I use Ansible all day every day -- it's not comparable container tooling in the slightest.
• krzepah 7y ago
  Docker is more than enough for most of the setups TBH, prometheus and what will work just as well. I would never recommend K8 locally, if you can even avoid docker it's a win. It's just a matter of preferences, where you want to invest your time to learn etc... Kubernetes being the fully fledged "state-of-the-art" I would just recommend the work of Stefan Prodan who's repository and blog are full of open and well thought devops work, even if you are just interested in K8 or only Docker
• moksly 7y ago
  > as a small developer Do you need kubernetes? I know the hype cycle is mad for copying big tech, but if stackoverflow can operate on a couple of IIS instances I’d argue that you almost never need kubernetes.
  • raxxorrax 7y ago
    For me containerization was always about deterministic environments and ease of deployment instead of performance and clustering. But even with these advantages I am currently not using any solution for that. For cloud services this is probably a good idea, even for users to a degree if the provider doesn't already give you a fitting box. But otherwise it is not a must have in my opinion. Maybe that is a mistake and the apps I develop today are not going to work in 10 years. Well, worst case: I have to be paid again.
    • sergiosgc 7y ago
      > For me containerization was always about deterministic environments and ease of deployment instead of performance and clustering. But even with these advantages I am currently not using any solution for that. You can get 99% of the way using a stable distribution and a configuration management system (ansible, chef and the like). It's much much simpler than running an orchestration service. I feel most people don't need containers and orchestration, just config management running redundant system designs.
      • ptsneves 7y ago
        To be honest I only very recently got to know ansible and related techs so I maybe missing an opportunity to learn something. Even so I think you are forgetting the DEV part. With ansible and chef you can make a deployment to the real infra. With containers you can have infra locally in your DEV environment and have clean slates. The similitude of the DEV environment and the production are crucial for devops. There is nothing more annoying for developers than having something work locally and then needing some weird quirk for the production/ci. A lot of political infighting and hate for devops. I saw this being a tech lead for build system in a fortune 500 company. Ah they have redhat based distro. Ultra stable! Problem is nothing from outside the company works out of the box, leading to blessed machines. A disaster that lead to so much unofficial workarounds that it is not funny. Lol the kernel is so old it cannot run docker:) Ubuntu is better but ultra stable machines will tend to massive customizations that are very hard to keep when you finally want to upgrade. It was very common to reach End of Life of LTS distros, and then have the server upgrade being a nightmare due to the long evolution that happened in the mean time.
• cs02rm0 7y ago
  Just use Docker. Let others run to Kubernetes, it doesn't sound like the right tool for you. That's ok!
• bryanlarsen 7y ago
  > Why a cluster? For availability. If you have promised 99.9% or more availability to your customers you probably need some sort of redundancy or hot failover. Kubernetes is a good option to get that. If you don't need 99.9%, simpler is better. > Too cheap You can get a single node Kubernetes cluster from Digital Ocean for $10 per month. That's silly because a single node cluster doesn't have redundancy which is the main reason for Kubernetes, but it lets you get started. A minimum redundant cluster would have two nodes and a $15 load balancer, so $35 per month at DO.
• geggam 7y ago
  Dabble with LXC on Linux
• a-saleh 7y ago
  I was looking at https://k3s.io/ https://k3s.io/ as a better configuration management solution than just pure-docker. Because I like kubernetes, I used it, I know it.
• totomz 7y ago
  We've had the same problems - we didn't need all the overhead of kubernetes. Have you seen BeeKube? https://beekube.cloud https://beekube.cloud It is a managed container platform, similar to a paas but with containers