1. 14
  1.  

  2. 5

    Why do you say Nomad is not free?

    1. 4

      That paragraph seems like the author is justifying to themselves why they want to play with k8s. I think they’re super weak reasons, could delete the entire paragraph and improve the post.

      eg, not sure I’d claim Mesos hasn’t gained critical mass given it underpins Netflix’s entire stack (Titus depends on Mesos & Zookeeper.) Nomad has equivalent large deployments, Cloudflare, Roblox and as you point out, is free (with paid-for extra features.)

      1. 4

        Author here, thanks for the feedback. I meant Nomad is not free because some features are behind an “Enterprise” paywall.

        1. 1

          Isn’t that also technically true of k8s? In the sense that cloud providers (google, amazon) have a special sauce that they don’t share with mere mortals?

          1. 3

            You don’t bump into “Error - Enterprise only feature” messages when working with K8s. I’m sure Amazon and Google have their own tools for working with it, but their use case is very specific.

            1. 1

              Thankfully no, that is not the case.

          2. 2

            Mesos was a contender for a hot minute but it’s definitely donezo at this point, isn’t it?

            1. 2
              1. 2

                Goodnight, sweet prince.

                edit: I actually had no idea it had gone to Apache, hah.

                1. 2

                  Apparently it was originally an Apache jam? Wow. I know nothing.

        2. 5

          I have a feeling (untested, unproven) many of the pain points that led the author to k8s/k3s could be solved by a combination of declarative OS config (NixOS) + systemd.

          EDIT: TFA mentions NixOS at the end.

          1. 2

            There’s also Harbormaster https://gitlab.com/stavros/harbormaster. But I wanted to get more knowledge of k8s too as it’s an increasing force in the DevOps world, and I like to be up to date on that side of things.

          2. 5

            My understanding is that the author just wanted to try out k8s at home, to be up to date with devops stuff. I’m interested to hear the experiences of people who also started trying it at home, and deploying it in their companies. How different it was? Did toying at home prepared you for all the pain points you experienced at much larger deployments?

            1. 7

              I also do this sort of thing, I explicitly try to use similar tech to what we use at work.

              I think there’s been three clear benefits for me:

              1. Seeing how we got to where we are. If you use k8s at work, but you weren’t the one that decided on it, or set it up; then it’s great to kind of go through the motions of how you got to where you are. Start with just docker on your home server, run that for a while, run nginx-ingress or such as an ingress, figure out the pitfalls, then move up from there.

              2. Run services that you think might be useful at work. Twice now I’ve been able to just take something I had running on my home server and get it up and running at work in less than 20 minutes. It almost feels like a magic trick when someone goes “I think we might need something that does X” and you can go “One minute, let me try something”.

              3. It’s practice. The failure modes are usually quite different, but the motion of debugging them is roughly the same, once you get into the same realm as your work, you start getting more and more familiar with things like the k8s command line interface kubectl for example. Having to learn how to use your tools while things are on fire (even if the fire is non-prod) is not fun, so it’s always good to be prepared.