[falcolas]

Let's talk about complexity for a moment, for one aspect of a simple service: ingress.

Kubernetes:

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: test-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /testpath
            backend:
              serviceName: test
              servicePort: 80

Nginx:

    location /testpath {
        proxy_path http://127.0.0.1:8080
    }

Which is less complex? Which is beta, and thus could be changed over time (it happens a lot). Which one requires major (and breaking) infrastructure updates every 3 months?

> I'd argue you have less YAMLs with k8s than with Ansible for a small project.

Since you typically need one yaml document per K8s resource, and can describe multiple independent and idempotant actions in one Ansible document, I think this is easily demonstrable as false for small projects (and likely big projects as well).

[justinsaccount]

The first one is a complete configuration you could kubectl apply into a cluster that sends traffic to a backend service that may be running across multiple instances on multiple machines.

The second is a configuration fragment that is useless by itself that would send all traffic to a single instance running on localhost.

[falcolas]

You can just drop it in a conf.d folder created by the package install and it would work just fine.

Also we're talking simple projects, and simple projects are typically not distributed; typically don't need to be distributed.

That said, supporting multiple backends with different load balancing algorithms is also pretty simple to write as well.

[justinsaccount]

Ok, great... I have a bunch of simple projects like that, one web instance running on a single host.

How do I safely upgrade it without downtime? Ensuring that the new version starts up properly and can receive traffic before sending it requests and stopping the old one?

With k8s: kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1 (or just use kubectl apply -f)

With your nginx config: ????

[falcolas]

That moves the goalposts a bit. We've gone from a simple service to a fleet of highly available services on multiple hosts with zero downtime requirements.

At which point, sure, use Kubernetes.

[justinsaccount]

No.. I didn't move the goalposts at all.

Still A single service on a single machine, how do I safely upgrade it?

A rolling deployment in k8s does work the same way on a single host with minikube as it does on a 1000 node cluster, but I'm still just asking about the single host case.

[wgjordan]

> Still A single service on a single machine, how do I safely upgrade it?

Depending on your OS-package's provided init script (here Ubuntu), it's as simple as `service nginx reload`, (`service nginx upgrade` if upgrading nginx itself).

Or skip the init script entirely with `/usr/sbin/nginx -s reload`.

[Draiken]

I think this is proving my point. They're basically the same, but one is completely dynamic and the other will have to be changed as soon as anything changes.

We've been using Kubernetes in production for almost two years now and I have yet to face a big API change that breaks everything. The core APIs are stable. There's a lot of new stuff added, but nothing that breaks backwards compatibility.

As you just said, if it's a simple project, you can upgrade the infrastructure by clicking "upgrade" on GKE. We've only ever hit problems when upgrading when using the bleeding edge stuff and the occasional bug (once since Kubernetes 1.1 to 1.10 for a large Rails app).

Regarding the yaml document per resource, I mean... that's spaghetti Ansible. If you want to have a proper Ansible setup you will have separate tasks and roles. If we're going down the route of just have "less files" you can have all the Kubernetes resources in a single YAML file. I would definitely not recommend that tho.

While Kubernetes is a lot more verbose, it is light years better than the Ansible jinja2 weird syntax. Even someone that never heard of Kubernetes can read that Ingress resource and guess what it does. If we're being really picky actually, the proxy_path should be pointing to some "test" thing that would have to be an upstream that would already make the NGINX config more obscure.

I feel like people just hate Kubernetes to avoid change. These arguments are never about Kubernetes' strengths or faults but about why "I think my way is better". You can always do things in millions of ways and they all have tradeoffs. The fact is: ROI on Kubernetes is a lot bigger than any other kind of manual setup.

I'll repeat what I said on another comment: the only reason to do anything by hand today is if it's a play thing

[dsnuh]

Are you using GKE for your production environment? Kubernetes has lots of great features, and definitely imposes some good operational patterns, but it's no panacea, and for those of us who can't put their applications in the cloud (or don't want to) Kubernetes can be a complex beast to integrate.

Are you running databases in Kubernetes? Do you have any existing on-prem infrastructure that you want to utilize (or are required to, because sunk costs) to integrate with Kubernetes?

Is you company a startup with no existing legacy application that you need to figure out how to containerize before you can even think about getting it into Kubernetes? We've seen benefits from running it, for sure, but I'm honestly not sure if the amount of work it took (and still takes) to make it work for us was worth the ROI.

Sometimes I feel like Kubernetes is a play by Google to get everyone using their methodology, but only they can provide the seamless experience of GKE.

[dsnuh]

I think the key element here is that you are using GKE. Managed cloud Kubernetes, and self-hosted on-prem Kubernetes are two different beasts. Yes, it's easy when you don't actually have to run the cluster yourself.

Ansible has its warts, but it is great for managing and configuring individual servers.

[Draiken]

Yes I agree. But in the context of this article, we're talking about small projects. So I wouldn't expect the need for an on-prem setup.

In fact I've used Kubespray[1] to setup a cluster with Ansible before with mild success. Nothing production ready, but it's actually a good tool for that job. At the end of the day you can't run Kubernetes on Kubernetes :D

[1]: https://github.com/kubernetes-incubator/kubespray

[dsnuh]

I really think that all Kubernetes related posts and articles need a footnote -

"Kubernetes allows you to scale simply!"*

"Kubernetes takes minutes to set up!"*

*When using GKE or another managed service.

[Draiken]

Honestly I cannot refute that!

Haven't had the experience myself outside of GKE so I can only imagine the complexity of it.

It is a young project still. My guess is that with some more time this will improve.

[dsnuh]

I guess it depends on your definition of "small projects". I agree with the article that if you are interested in getting something out there for people to use and see what kind of interest you get, then adding Kubernetes to the mix doesn't really get you there faster. If anything, I think it would slow you down, unless we are talking about a very trivial app.

I was responding more to the comments I had been reading, not the premise of the article.

[tomjen3]

How do you configure it with a master postgress db that is persistent over reboots, hooked up to two hot slaves? With ability to do of site backup?

All deployments I have seen so far have been immutable infi scale webapps. That is easy.

[Draiken]

That's true. Stateless apps are a lot easier. I have myself had to put a stateful service in K8s even before they had StatefulSets and it wasn't a walk in the park.

However doing what you described is hard... anywhere.

Even if you do it all by hand it's going to be hard and most likely brittle. It might take a bit more time/effort to do that on Kubernetes but I would say you would end up being a better solution that can actually sustain change.

As stated before by many, Kubernetes is not a magic wand. But it does force you to build things in a way that can sustain change without a big overhead.

We all know that different tools have different purposes and I'm not advocating it's perfect by any means. All I'm trying to say is that this idea - that a lot of people have - that Kubernetes is 10x more complex than doing X by hand is an illusion.