Docker For Mac Kubernetes Ingress

So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments. I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud providers and very needy posters on Github, myself included.

Kubernetes on the other hand is trivial with GKE. It’s great for single node deployments. I run a single node on GKE and it’s awesome, easy, and very cheap. You can even run preemptible instances. The myth that kubernetes is complicated is largely perpetuated by the same kind of people who say React is complicated: the people who’ve not tried it. And like React, once you try kubernetes you never go back. Kubernetes is actually the orchestration equivalent of React.

You declare what should be true, and Kubernetes takes care of the rest. And the features it provides are useful for any-sized application! If you try kubernetes you quickly discover persistent volumes and statefulsets, which take away most of the complexities out of stateful applications (ie most applications). You also discover ingress resources and controllers, which make trivial so many things that are difficult with Swarm, like TLS termination.

Swam doesn’t have such features, which any non-trivial app (say, Django, wordpress, etc) benefits from tremendously. > Kubernetes on the other hand is trivial with GKE How do I install GKE on my servers?;) > By hand it’s not trivial to get a secure install. The default install (basically, adding a repo and apt-get install docker-ce on Debian and derivatives - trivial to automate with Ansible) is reasonably secure if you view Docker as a tool for packaging and task scheduling with some nice extras and don't buy the marketed isolation properties. It only listens for commands on a local socket, and permissions are sane.

I haven't looked into Swarm mode protocol traffic, though but I don't think it's tweakable anyway. > The myth that kubernetes is complicated is largely perpetuated by the same kind of people who say React is complicated: the people who’ve not tried it.

I've tried K8s. I've set up a test cluster, it worked, I wrote some YAML, it worked, all good.

So I've worsened the conditions (explicitly going into 'I want things to break' territory) and made it fail. I've researched how hard it is to diagnose the problem and fix it - it happened to be complicated.

To configure a Treafik Kubernetes ingress controller within UCP 3.0 follow the steps below: Authorization. First, create a Kubernetes namespace for the Traefik ingress controller and a permissions grant for the default Service Account within this namespace. Docker for Mac; Docker for Windows(PC) Docker for AWS. Unless something seriously magical has happened with 'Docker for Mac,' then the type: LoadBalancer is only designed for a cloud environment, where the Ingress controller can provision a cloud load balancer (i.e. AWS's ELB, GKE's. Whatever they use). That said, one can see from your output that kubernetes has behaved as if it was type: NodePort (with your specific example showing that port.

At least, for me. Just felt that 'if something goes wrong here, I'll have bad time trying to fix it'. Surely, this is not the case on GKE where you don't run and don't manage the cluster. I had somewhat similar experience with Docker and Docker Swarm mode, and it was significantly easier to dive into the code, find out the relevant parts and see what's going on.

> difficult with Swarm, like TLS termination YMMV, but I just add some labels to the service and Traefik does the rest.;) (But, yeah, Traefik with Swarm requires some reasonable but not exactly obvious networking logic. May take one deployment of 'why I'm getting 504s?!' To figure it out. And Traefik needs access to manager nodes to work with built-in Swarm service discovery.).

Hardware rental is one way to tackle provisioning. You're still left with all the other tasks required to bootstrap your own datacenter. As you build up the roll-your-own solution, you end up in the same place: hire IT headcount. If you are a small startup looking to validate market fit, your best bet is Cloud + Kubernetes. If you are an established business with millions of daily customers and serious IT headcount budget, you may look into roll-your-own.

The best orchestrator at that scale is, again, Kubernetes. Thanks for the reply. I agree with what you say. I'm not tying to say people should all jump to k8s.

Having options on the market is great. But I was trying to refute the notion that Kubernetes has no advantages unless you're running a huge cluster. My main points where: * It works great with 1 node. * It comes with many features that Swarm does not have that are useful even at 1 node (PersistentVolumes, StatefulSets are biggest for me, though there are _many_ more I wouldn't want to go without anymore).