Why I'm leaving Kubernetes for Swarm

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..

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.

Kubernetes 'on prem' is hard and stuff

Have fun, see you when you come back :)