
Why I'm leaving Kubernetes for Swarm - jonathan-kosgei
https://gist.github.com/jonathan-kosgei/dac620fed9d9aeec35050bcc0a146647
======
vgy7ujm
I agree that Swarm is easier. But will it work in production? And will they
break the API again? Just from 1.12 to 1.13 there are pretty big changes..

~~~
jonathan-kosgei
On my part I'll be able to give you a detailed answer after a few weeks of
running a couple of my apps with decent traffic on swarm :)

------
lobster_johnson
There's a lot of misleading information here. Pretty much all of his examples
use a more difficult solution than needed, making Kubernetes seem like it's a
lot more fiddly to use.

> "one docker-compose.yml file ... as opposed to the countless files covering
> everything"

The author seems to think that a Kubernetes manifest can only contain a single
declaration. You can actually stuff as many declarations as you want into a
single YAML file, like so (and you should!):

    
    
       apiVersion: extensions/v1beta1
       kind: Deployment
       [...]
       ---
       apiVersion: v1
       kind: ConfigMap
       [...]
       ---
       apiVersion: v1
       kind: Service
       [...]
    

Put it in myapp.yaml and do "kubectl apply -f myapp.yaml". Exactly the same as
Docker Compose.

Also, don't use "kubectl create" — use "kubectl apply". It will create or
update as needed. It even supports recursing through directories.

> How to use volumes in Kubernetes :(

It's only sad if you use persistent volume claims, which is the "advanced"
option which I don't think Swarm even has. I'm not sure why the author felt
they needed to use them.

Kubernetes supports ordinary volumes that don't require that you predeclare
anything else. For example, on Google Cloud Platform:

    
    
            containers:
              [...]
              volumeMounts:
              - name: pgdata
                mountPath: /var/lib/postgresql/data
                subPath: pgdata
                name: pgdata
            volumes:
            - name: pgdata
              gcePersistentDisk:
                pdName: some-disk-i-created
                fsType: ext4
    

This will mount the persistent disk "some-disk-i-created", and automatically
format it as ext4 if necessary.

Persistent volume _claims_ are for managing pools of storage: You create one
volume, then let pods carve out pieces of it. So you create big, generic
volumes and let Kubernetes handle allocation, as opposed to setting up
dedicated, named volumes for each container.

There are pros and cons to both approaches, of course. PV/PVCs obviously
require that they're defined first. That said, once you've created a PV, it's
actually less work to _use_ it across multiple pods, because Kubernetes will
handle the gritty details of allocation.

> the fickle beast that is Kubernetes Ingresses ...

In my opinion the ingress system is the weakest part of Kubernetes right now.
That said, once you create a controller (nginx-ingress-controller is great,
and covers most needs), setting up new ingresses is dead easy, and certainly
easier than managing your own load balancer using something like HAProxy or
Nginx.

(For simplicity's sake I recommend keeping a single ingress file for your
entire system, as opposed to spreading them out among different YAML files.
Easier to manage.)

But you don't _have_ to use an ingress or a managed load balancer. It's just a
convenience. The way to do it is to use a NodePort, then run your own load
balancer that points to it. I don't think this is any different from Docker
Swarm. To spread the load across a cluster of containers, you need, per
definition, a _load balancer_. You can also run a Kubernetes-aware load
balancer such as Traefik.

> Realising that to use paths i.e. example.com/path ...

The Nginx controller doesn't use physical paths for the ingress endpoints that
it proxies. I don't know what he means by this. I have not had this issue.

~~~
jonathan-kosgei
Hi :), I did give mention to putting it all in one file in Kubernetes

> You can define everything in one file in Kubernetes but it won't do much for
> readability.

My emphasis was on how much less config I have to go through to grasp the
details of my setup in entirety given a single dense kubernetes config file vs
a single compose file.

You mention using kubectl apply to deploy >Also, don't use "kubectl create" —
use "kubectl apply". It will create or update as needed. It even supports
recursing through directories.

It is indeed better than kubectl create, however I would point out that if you
use it with the intention of running it recursively within a directory, you
will have little control over the order of creation of resources, and you will
run into errors if one of your resources depends on another resource which has
not been created yet.

Before I continue :) you believe that I am using Kubernetes in the most
complicated way possible and thus making it seem harder to use than it
actually is, however I'd point out that I was porting a "production" cluster
to Swarm, and for deployment on dedicated machines and not a generic cloud
provider. I therefore had been using whatever advanced options I had at my
disposal to make my setup as robust as possible.

------
koltaggar
Kubernetes 'on prem' is hard and stuff

------
_jezell_
Have fun, see you when you come back :)

