5 ms·

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

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

linkmotif 9y ago
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). * Docker is not trivial to set up, either. > How do I install GKE on my servers? ;) Yes, of course. I was just saying there's a solid option to start exploring quickly. > It only listens for commands on a local socket. This is kind of a non-starter, isn't it? Of course it's easy to apt-get install docker, but then you want to control it remotely, right? Once you realize how nice it is to control Docker remotely, it's hard to imagine life before.
- perfmode 9y ago
  I appreciate where you’re coming from, but you can’t bring GKE into a conversation about the challenges of Kubernetes ops. GKE does everything for you.
  - linkmotif 9y ago
    I guess you are correct. What about Docker Machine vs Kops, then?
- sandGorgon 9y ago
  Actually if you are using StatefulSets and PV, then kubernetes is a better fit for you. However, Swarm is undeniably simpler to work with unless you have very specific requirements that only K8S provides. The yml file is incredibly simpler. Docker Swarm is the Kotlin to Kubernetes' Java. It's a much pleasanter and much less intimidating way to build production systems that scale pretty well. Kubernetes needs you to have load balancers setup which can talk K8S ingress. Bare metal setup for k8s is a huge effort (and I have stuck long enough on #sig-metal to know) as compared to Swarm. You should try out Swarm - you might choose not to use it, but you will enjoy the experience.
  - raarts 9y ago
    Completely agree. Tried them both and found Docker Swarm to be much simpler to setup and maintain.
- drdaeman 9y ago
  > Kubernetes has no advantages unless you're running a huge cluster. You're absolutely correct. Kubernetes has its advantages, even in a single-node setup. What many others are pointing out is that it also has significant disadvantages, too. > but then you want to control it remotely, right? By the way, I do talk to Docker (Swarm mode or standalone) deployments remotely, forwarding the socket via SSH. ssh -nNT -L /tmp/example.docker.sock:/run/docker.sock example.org docker -H unix:///tmp/example.docker.sock info (Needs user to have access to the socket, of course. If sudo with password-requirements is desirable, `ssh + sudo socat` is a viable alternative.) But, really, there is Ansible for this. Declare `docker_service` and get it deployed (or updated) as a part of the playbook. And ELK (with logging.driver=gelf for the containers or application-level) for logging. (BTW, what's nice about K8s is that IIRC it allows to exec into pods with just `kubectl exec`. With Swarm you need some script to discover the the right node and container ID, SSH into it and run `docker exec` there - no remote access.)
pacala 9y ago
> How do I install GKE on my servers? ;) Great question! All major Cloud providers offer managed Kubernetes services: https://cloud.google.com/kubernetes-engine https://cloud.google.com/kubernetes-engine https://azure.microsoft.com/en-us/services/container-service https://azure.microsoft.com/en-us/services/container-service https://aws.amazon.com/eks https://aws.amazon.com/eks https://www.ibm.com/cloud/container-service https://www.ibm.com/cloud/container-service The choice is Cloud + Kubernetes vs. roll everything on your own hardware. Running your own hardware is a major IT effort. Kubernetes is just a part of that effort. Then you have take care about planning, provisioning, logging, monitoring, alerting, auditing, networking, storage, oncall. You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount.
- bonesss 9y ago
  > Running your own hardware is a major IT effort. Kubernetes is just a part of that effort. For Enterprise nerds VMWare has also just launched a Kubernetes service, so the #1 Enterprise VM supplier just added k8s on-prem for everyone who is in a hybrid cloud situation.
- bboreham 9y ago
  EKS isn't generally available
- kuschku 9y ago
  > You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount. You can always rent dedicated hardware – much cheaper than renting similar amounts of virtual servers, and the same administration and operations costs. It’s often even significantly cheaper than what GCE offers – but of course, setting up Kubernetes is more complicated.
  - pacala 9y ago
    Exactly. 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.

linkmotif 9y ago

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). * Docker is not trivial to set up, either. > How do I install GKE on my servers? ;) Yes, of course. I was just saying there's a solid option to start exploring quickly. > It only listens for commands on a local socket. This is kind of a non-starter, isn't it? Of course it's easy to apt-get install docker, but then you want to control it remotely, right? Once you realize how nice it is to control Docker remotely, it's hard to imagine life before.

perfmode 9y ago
I appreciate where you’re coming from, but you can’t bring GKE into a conversation about the challenges of Kubernetes ops. GKE does everything for you.
- linkmotif 9y ago
  I guess you are correct. What about Docker Machine vs Kops, then?
sandGorgon 9y ago
Actually if you are using StatefulSets and PV, then kubernetes is a better fit for you. However, Swarm is undeniably simpler to work with unless you have very specific requirements that only K8S provides. The yml file is incredibly simpler. Docker Swarm is the Kotlin to Kubernetes' Java. It's a much pleasanter and much less intimidating way to build production systems that scale pretty well. Kubernetes needs you to have load balancers setup which can talk K8S ingress. Bare metal setup for k8s is a huge effort (and I have stuck long enough on #sig-metal to know) as compared to Swarm. You should try out Swarm - you might choose not to use it, but you will enjoy the experience.
- raarts 9y ago
  Completely agree. Tried them both and found Docker Swarm to be much simpler to setup and maintain.
drdaeman 9y ago
> Kubernetes has no advantages unless you're running a huge cluster. You're absolutely correct. Kubernetes has its advantages, even in a single-node setup. What many others are pointing out is that it also has significant disadvantages, too. > but then you want to control it remotely, right? By the way, I do talk to Docker (Swarm mode or standalone) deployments remotely, forwarding the socket via SSH. ssh -nNT -L /tmp/example.docker.sock:/run/docker.sock example.org docker -H unix:///tmp/example.docker.sock info (Needs user to have access to the socket, of course. If sudo with password-requirements is desirable, `ssh + sudo socat` is a viable alternative.) But, really, there is Ansible for this. Declare `docker_service` and get it deployed (or updated) as a part of the playbook. And ELK (with logging.driver=gelf for the containers or application-level) for logging. (BTW, what's nice about K8s is that IIRC it allows to exec into pods with just `kubectl exec`. With Swarm you need some script to discover the the right node and container ID, SSH into it and run `docker exec` there - no remote access.)

pacala 9y ago

> How do I install GKE on my servers? ;) Great question! All major Cloud providers offer managed Kubernetes services: https://cloud.google.com/kubernetes-engine https://cloud.google.com/kubernetes-engine https://azure.microsoft.com/en-us/services/container-service https://azure.microsoft.com/en-us/services/container-service https://aws.amazon.com/eks https://aws.amazon.com/eks https://www.ibm.com/cloud/container-service https://www.ibm.com/cloud/container-service The choice is Cloud + Kubernetes vs. roll everything on your own hardware. Running your own hardware is a major IT effort. Kubernetes is just a part of that effort. Then you have take care about planning, provisioning, logging, monitoring, alerting, auditing, networking, storage, oncall. You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount.

bonesss 9y ago
> Running your own hardware is a major IT effort. Kubernetes is just a part of that effort. For Enterprise nerds VMWare has also just launched a Kubernetes service, so the #1 Enterprise VM supplier just added k8s on-prem for everyone who is in a hybrid cloud situation.
bboreham 9y ago
EKS isn't generally available
kuschku 9y ago
> You either run Cloud + Kubernetes and get rolling in 15 minutes, or you hire IT headcount. You can always rent dedicated hardware – much cheaper than renting similar amounts of virtual servers, and the same administration and operations costs. It’s often even significantly cheaper than what GCE offers – but of course, setting up Kubernetes is more complicated.
- pacala 9y ago
  Exactly. 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.