6 ms·

So let’s take step by step: 1. Learn shell scripts. 2. Learn Docker conf. 4. Learn yaml. (May be helm and plethora of acronyms specially designed for k8s).

So let’s take step by step: 1. Learn shell scripts. 2. Learn Docker conf. 4. Learn yaml. (May be helm and plethora of acronyms specially designed for k8s). 5. Combine spaghetti of 1,2,3 to build container image scripts. 6. Tie it into CI/CD process for adventurous. 7. Learn to install and manage k8s cluster or learn proprietary non open source api of google or amazon or azure. 8. Constantly patch and manage plethora of infrastructure software besides application code. Now with all this use a tool designed for million user application on an application which will be used by 100’s to 1000’s of users. I think k8s is designed for google kind of problem and is an overkill for over 80-90% of deployments and applications. May be just use simple deployment with Ansible, puppet,chef, nix, gnu guix etc. to deploy and manage software based on necessity on a single vm and extend it to a large cluster if necessary of bare metal or vm or container in a cloud agnostic manner. Not sure when the technology fashion overtook the infrastructure area like complex web app tooling in JavaScript world. K8s has its own place at scale required by handful of Organization with google level traffic and load for most traditional companies Simple cluster management and configuration management tool will work wonders with less moving parts and cognitive load.

curryst 7y ago
Then you still have to learn Ansible, so you're still learning a tool. And you probably want to use Docker anyways, unless you're shipping statically linked binaries. Also, you said VM which implies that instead of Kubernetes you're going to use a VM platform, which comes with every bit of the complexity Kubernetes has. I agree with you that it's a simpler deployment method when you don't need HA. As soon as you need HA, then all of a sudden you need to be able to fail over to new nodes and manage a load balancer and the backends for that load balancer. Kubernetes makes that easy. Kubernetes makes easy things harder than they should be, and hard things easier than they should be. The number of things I've managed that don't need HA is vanishingly low.
- ar_lan 7y ago
  I think you're starting to get at what has annoyed me about a lot of the anti-k8s folks. I really just don't think they understand the tool, because any production environment should have many of the features Kubernetes helps provide. So the argument becomes "I know how to do it this other way, so learning a new tool is too complex." Kubernetes helps standardize a lot of these things - I can very easily hop between different clusters running completely different apps/topologies and have a good sense of what's going on. A mish-mash of custom solutions re-inventing these wheels is, in my opinion, far more confusing. > Kubernetes makes easy things harder than they should be, and hard things easier than they should be. This is really the crux, I think. I think a lot of people look at Kubernetes, try to learn it by running their blog on a K8s platform, and decide it's overly complex to run something that Docker probably solves (alone) for them. When you need HA for many services, don't want to have to handle the hassle of your networking management, design your applications with clear abstractions, etc., and really need to start worrying about scale, Kubernetes starts to really shine. /rant
  - hello_moto 7y ago
    > I can very easily hop between different clusters running completely different apps/topologies and have a good sense of what's going on. A mish-mash of custom solutions re-inventing these wheels is, in my opinion, far more confusing Kinda like jumping between Rails projects (assuming those rails projects don't diverge heavily from the "convention") vs jumping around between custom PHP scripts ;) Or for Java Dev... kinda like jumping between Maven (again, assuming mostly follow the Maven convention) vs random Ant scripts to build your Java-based systems. There will always be naysayers no matter what because they're used to the previous tech.
    - burpsnard 7y ago
      I am that old curmudgeon. There's a cycle in tool ecology: - simple useful tool - adds formats, integrations, config, etc - codebase is large and change is slow - the skijump has become an overhang on the learning curve - a frustrated person writes a simple useful tool - goto 10 I haven't used k8 but it looks useful for uncommon workloads. I expect some nu shinyee thing will replace it eventually.
      - hello_moto 7y ago
        I'm the kind of guy who just got lucky enough to land in workplace that moved away from previously ducktaped/custom build script to something not-necessary new but have since become accepted to be a better standardized tools.
- dragonsh 7y ago
  I don’t have to go docker or kubernetes path for anything complex. I can still use more secure lxd containers with the same system configuration tool and scripts used for VM, bare metal to manage container. Indeed due to problem with docker and CRI all kubernetes were vulnerable recently and needed security patch, as docker containers do not run in user namespace like lxd. So for HA also traditional methods are better and functional programming approach like guix and nix to generate lxd container images, vm images or deploy to bare metal to run application is far superior and secure instead of spaghetti and non understandable black box images popular in docker world.
  - fapjacks 7y ago
    You have either deliberately misrepresented "Docker" in your post, or don't know enough about the vulnerability (and the affected software, runc) to make the claims you are making. The vulnerability was in runc, and Docker et al have had the capability to utilize user namespaces for a number of years.
    - dragonsh 7y ago
      No I did not mis-represent docker, used it since version 0.96 and after 1.0. Also commented, when under the new investment it tried to re-invent the wheels by moving away from lxc base to re-write its own libcontainer and lost on the development of unprivileged containers which landed in lxc 1.0. Since than it’s always been a security nightmare. Docker although inferior and less secure than LXC/LXD became popular due to marketing driven by VC money, not on technical merits. Check the old thread discussing the security issue with docker not supporting unprivileged container. [1] [1] https://news.ycombinator.com/item?id=20487625 https://news.ycombinator.com/item?id=20487625

curryst 7y ago

Then you still have to learn Ansible, so you're still learning a tool. And you probably want to use Docker anyways, unless you're shipping statically linked binaries. Also, you said VM which implies that instead of Kubernetes you're going to use a VM platform, which comes with every bit of the complexity Kubernetes has. I agree with you that it's a simpler deployment method when you don't need HA. As soon as you need HA, then all of a sudden you need to be able to fail over to new nodes and manage a load balancer and the backends for that load balancer. Kubernetes makes that easy. Kubernetes makes easy things harder than they should be, and hard things easier than they should be. The number of things I've managed that don't need HA is vanishingly low.

ar_lan 7y ago
I think you're starting to get at what has annoyed me about a lot of the anti-k8s folks. I really just don't think they understand the tool, because any production environment should have many of the features Kubernetes helps provide. So the argument becomes "I know how to do it this other way, so learning a new tool is too complex." Kubernetes helps standardize a lot of these things - I can very easily hop between different clusters running completely different apps/topologies and have a good sense of what's going on. A mish-mash of custom solutions re-inventing these wheels is, in my opinion, far more confusing. > Kubernetes makes easy things harder than they should be, and hard things easier than they should be. This is really the crux, I think. I think a lot of people look at Kubernetes, try to learn it by running their blog on a K8s platform, and decide it's overly complex to run something that Docker probably solves (alone) for them. When you need HA for many services, don't want to have to handle the hassle of your networking management, design your applications with clear abstractions, etc., and really need to start worrying about scale, Kubernetes starts to really shine. /rant
- hello_moto 7y ago
  > I can very easily hop between different clusters running completely different apps/topologies and have a good sense of what's going on. A mish-mash of custom solutions re-inventing these wheels is, in my opinion, far more confusing Kinda like jumping between Rails projects (assuming those rails projects don't diverge heavily from the "convention") vs jumping around between custom PHP scripts ;) Or for Java Dev... kinda like jumping between Maven (again, assuming mostly follow the Maven convention) vs random Ant scripts to build your Java-based systems. There will always be naysayers no matter what because they're used to the previous tech.
  - burpsnard 7y ago
    I am that old curmudgeon. There's a cycle in tool ecology: - simple useful tool - adds formats, integrations, config, etc - codebase is large and change is slow - the skijump has become an overhang on the learning curve - a frustrated person writes a simple useful tool - goto 10 I haven't used k8 but it looks useful for uncommon workloads. I expect some nu shinyee thing will replace it eventually.
    - hello_moto 7y ago
      I'm the kind of guy who just got lucky enough to land in workplace that moved away from previously ducktaped/custom build script to something not-necessary new but have since become accepted to be a better standardized tools.
dragonsh 7y ago
I don’t have to go docker or kubernetes path for anything complex. I can still use more secure lxd containers with the same system configuration tool and scripts used for VM, bare metal to manage container. Indeed due to problem with docker and CRI all kubernetes were vulnerable recently and needed security patch, as docker containers do not run in user namespace like lxd. So for HA also traditional methods are better and functional programming approach like guix and nix to generate lxd container images, vm images or deploy to bare metal to run application is far superior and secure instead of spaghetti and non understandable black box images popular in docker world.
- fapjacks 7y ago
  You have either deliberately misrepresented "Docker" in your post, or don't know enough about the vulnerability (and the affected software, runc) to make the claims you are making. The vulnerability was in runc, and Docker et al have had the capability to utilize user namespaces for a number of years.
  - dragonsh 7y ago
    No I did not mis-represent docker, used it since version 0.96 and after 1.0. Also commented, when under the new investment it tried to re-invent the wheels by moving away from lxc base to re-write its own libcontainer and lost on the development of unprivileged containers which landed in lxc 1.0. Since than it’s always been a security nightmare. Docker although inferior and less secure than LXC/LXD became popular due to marketing driven by VC money, not on technical merits. Check the old thread discussing the security issue with docker not supporting unprivileged container. [1] [1] https://news.ycombinator.com/item?id=20487625 https://news.ycombinator.com/item?id=20487625