Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adding Kubernetes support to the Docker platform

docker.com

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Adding Kubernetes support to the Docker platform

#131

Post by erikb »

InTheArena wrote: post #120
erikb wrote: post #105

Earlier quoted context omitted.

Surpressing egos usually means one has found a joker to beat the other in the fight for leadership. I don't think that battle is over yet, though. It's a very strong move Docker does here, but at the same time k8s is considering choosing another container engine as their main component. Currently at least in Enterprise k8s has a lot more traction than docker (I personally love docker more, but every day need to focus…

Yes, but guess what, Docker CNI is now going to be supported, so CNI is no longer a issue. Ingress will still be a issue, but Openshift is still doing their own random route thing there anyways. Being low on the stack is a power move. It's like a NFL lineman, the lower player has considerably higher leverage then the higher player. Docker can go in, run Kubeadm legitimately, but use Docker based CNI and volume plugin…

Interesting idea, but reality looks different. Everything underneath the PaaS layer becomes less and less important. With container engines it may be hard to see for most people yet, I have to admit that. But with OS and hardware you can see it. E.g. think about what OS you run your PaaS on. It doesn't matter. The only limit here is integration with Docker/Kubernetes. If these are available on the OS then it doesn't matter which one you choose. That's also why many people now start to use complete unmodified OS images that don't update individual packages anymore but the whole OS layer together or nothing. Then hardware. Would you say anybody running k8s has an advantage when running on a super computer compared to a cluster of hundreds of desktop computers? Probably not.

Re: Adding Kubernetes support to the Docker platform

#132

Post by gbraad »

errordeveloper wrote: post #127
organsnyder wrote: post #46

Earlier quoted context omitted.

I don't see how it could be much simpler and/or easier. In my experience, Minikube just works, out-of-the-box.

Not everyone had the same experience. There a few minor UX flaws that make it frustrating to use, e.g. having to set Docker host, shared filesystem performance is poor, networking in enterprise desktop environment is broken (just to name a few top most issues). Also, a lot of folks end up running Docker for Mac and minikube VMs, why should they have to run two VMs? Additionally, minikube is completely different from…

Certain things are not possible. However, we try to match functionality as much as possible with localkube (and soon kubeadm).

Shared folders, especially using 9p and/or cross-platform have been an issue, and I personally also experience this in the fork Minishift, and this likely the performance issue you meant.

But back to an earlier question I posted, have you filed the issues you had in the issue tracker? https://github.com/kubernetes/minikube/issues

Yes, the docker/machine code is an issue. For this, the libmachine is mostly moved inrepo and we are working on abstracting and even replacing this.

Re: Adding Kubernetes support to the Docker platform

#133

Post by erikb »

zenlikethat wrote: post #113
InTheArena wrote: post #82

There is some real meat here, and things that should have been done long ago. A key thing is that the Docker network drivers (libnetwork) are becoming CNI compatable. This will vastly simplify one of the worst aspects of setting up Kubernetes, and ensure a consistent network space across containers, even if a given container is not in kube. That's nothing but awesome. https://github.com/docker/libnetwork/pull/1978/fi…

Yeah setting up networking has been one of the worst parts of using Kubernetes in my limited experience -- just using default Docker networking would be sweet.

Networking is a topic where you really need debugging functionality. That's why it hits you the hardest there. Same experience here. It's terrible. But the underlying problem is that there's basically no debugging functionality in cluster environments until you are skilled enough to set up your own (ELK stack etc). But you can't even get there in a reasonable amount of time.

The same incomplete debugging is also in kubeadm. It often hangs in the "waiting for control plane" level without any additional info. Helm also has such problems, reporting networking erros when there's no networking problem (if it checks ipv6 first but hten switches to ipv4 for instance). It's also possible that a helm deployment fails, gives no real reason why, then you can't uninstall it at all without restarting the k8s master.

It's maybe even more general, and a problem in the whole Go programming language world. Everytime I see a tool written in Go I immediately cringe and already know that there will be debugging problems. No ideas why nobody inside this community realises it or how they debug. I suspect they don't really debug and live in the illusion that actually others know something better, but actually the others also don't know it.

Re: Adding Kubernetes support to the Docker platform

#134

Post by netwrk »

SEJeff wrote: post #89
InTheArena wrote: post #81

Earlier quoted context omitted.

Openshift is just like Docker here. both will support Kubernetes in the openshift edition, both charge commercial support.. I'd like to see a price comparison between Docker EE and openshift, because Openshift aint cheap.

Except it isn't, because things in Docker EE aren't open source (case in point, docker datacenter), where as all of openshift is opensource. Your fallacy is comparing a product that is open core, with a product that is commercial open source. https://www.quora.com/What-is-the-difference-between-OpenShi...

totally dodged the cost comparison concern.

Re: Adding Kubernetes support to the Docker platform

#135

Post by amouat »

rdli wrote: post #99
grabcocque wrote: post #16

Earlier quoted context omitted.

There's minikube. There's been minikube for a long while.

So in reading this link where information is scarce, this seems like an alternative to minikube (e.g., bundling Kubernetes as part of Docker CE/EE). Is that the right interpretation? FWIW, we've found minikube a bit wonky. It's resource intensive, so if you want to run more than a couple services, your laptop starts to melt. One of our open source projects is Telepresence which relies heavily on Kubernetes networking…

Docker for Mac and Windows will include a single node k8s cluster, so yes, effectively a replacement for minikube. Docker EE will include full support for k8s as an orchestrator as well as Swarm mode.

Re: Adding Kubernetes support to the Docker platform

#136

Post by zenlikethat »

erikb wrote: post #133
zenlikethat wrote: post #113

Earlier quoted context omitted.

Yeah setting up networking has been one of the worst parts of using Kubernetes in my limited experience -- just using default Docker networking would be sweet.

Networking is a topic where you really need debugging functionality. That's why it hits you the hardest there. Same experience here. It's terrible. But the underlying problem is that there's basically no debugging functionality in cluster environments until you are skilled enough to set up your own (ELK stack etc). But you can't even get there in a reasonable amount of time. The same incomplete debugging is also in k…

Yeah, I've run into that same issue with kubeadm. It was hanging because of the network not being set up.

I'm not really sure where your original comment is going, but I don't really feel the problem is endemic to Go. Using/debugging most software is an exercise in frustration. Just look at Linux on the desktop (which I use btw, I'm not criticizing). Fixing things is usually reduced to tribal knowledge, IRC, and Googling.

Re: Adding Kubernetes support to the Docker platform

#137

Post by erikb »

zenlikethat wrote: post #136
erikb wrote: post #133

Earlier quoted context omitted.

Networking is a topic where you really need debugging functionality. That's why it hits you the hardest there. Same experience here. It's terrible. But the underlying problem is that there's basically no debugging functionality in cluster environments until you are skilled enough to set up your own (ELK stack etc). But you can't even get there in a reasonable amount of time. The same incomplete debugging is also in k…

Yeah, I've run into that same issue with kubeadm. It was hanging because of the network not being set up. I'm not really sure where your original comment is going, but I don't really feel the problem is endemic to Go. Using/debugging most software is an exercise in frustration. Just look at Linux on the desktop (which I use btw, I'm not criticizing). Fixing things is usually reduced to tribal knowledge, IRC, and Goog…

I agree, a lot of software NOT written in Go also has this problem. I don't know how it is in C world, but in many programming languages wriitng good activity reporting (i.e. logging) is considered a core skill of each program.

It is sometimes hard to read the logging messages and understand how they came to be. But just having a different status report for a different problem is already so helpful. For instance if kubeadm fails with "I need cheeseburgers" when you actually forgot to configure your proxy correctly, and with "I need more minerals" when you forgot something else, then the first time debuggin is quite frustrating. But after that you know "cheeseburger means proxy" and you can continue. But if you hit "waiting for control plane" for ALL the problems, then your brain can't even remember for what to check right now. I'm the best example, I already forgot the other five things that can go wrong and I would need to check my work internal wiki for that.

I think that's the main reason why logging exist, to increase the speed of hitting a symptom to discovering what's actually going wrong. And Go in general, k8s specifically, simply goes in the other direction the whole time. They don't report any errors, and sometimes even report errors when there is no error. This is systematic in some way but I would need to study the community to tell you more specifically what's wrong.

Re: Adding Kubernetes support to the Docker platform

#138

Post by chmielewski »

joevandyk wrote: post #116

Anyone have any recommendations for getting k8s on a 3 machine system, like Digital Ocean or OVH?

https://ronanquillevere.github.io/2017/05/16/kubernetes-ovh....

https://github.com/antoineco/kOVHernetes

Go with OVH, unlimited resource usage (including traffic) and they allow you to create/own your own private network (vRack) of dark fiber. Look into using multiple points of presence that they offer. If you don't need it nownow, wait for OVH to offer local US machines rather than just geolocated IPs.

You can do this well with bare metal servers or with a number of whatever dedicated and/or shared cloud stuff they offer.

Re: Adding Kubernetes support to the Docker platform

#139

Post by avgkol »

hosh wrote: post #96
m3adow wrote: post #45

Earlier quoted context omitted.

Because K8s has quite some overhead, a steeper learning curve and is more difficult to set up and to maintain. I don't see this as a problem in bigger companies, but in companies with less than 10 IT people and no prior knowledge I'd take Swarm over K8s every day.

We have less than 10 people, 5 of them engineers. We are overbooked getting features out. We are using K8S in both dev and production, not Swarm. A big part of that is because I have had experience running Docker (not Swarm), ECS, K8S, and building developer tooling (Vagrant), in addition to being a regular developer. The flip side: I had to opportunity to try out these different tech in production and saw where the…

Hosh , could you share your learning from setting up a prod K8 HA cluster? Could be useful for me.

Re: Adding Kubernetes support to the Docker platform

#140

Post by yumyumyumyum »

hosh wrote: post #95
stonewhite wrote: post #38

Disregarding the swarm compatibility bit (which is irrelevant because swarm is kind of irrelevant), I don't really like what this "support" really means. As others mentioned minikube and k8s-cluster is already providing dev-to-prod compatibility. Kubectl was already providing docker cli commands like "exec" "logs" etc. So you can execute some of these commands on a k8 cluster with the docker binary too? And why would…

I see the same thing too: a struggle for relevance. The center of gravity has already moved onto k8s, even if it will takw a while for the rest of the developer community to catch up. There are a lot more exciting work around Helm (packaging for K8S), third party extensions (plugins for K8S), and Operators (embedded managed services). The K8S community already has more contributios going towards the stack, and the th…

From a production Swarm operator without much experience with k8s:

When you create a new Swarm cluster with `docker swarm init`, Swarmkit creates PKI that is used for everything onward: gRPC cluster state communication, encrypted overlay networks, secrets, and so on. Keys are automatically rolled every 12 hours by default. This is done automatically and transparently to the operator, without any effort on their part. Adding workers or managers after that is as done with `docker swarm join --token ` on the new node, that's all.

I believe operation ease for starting a cluster and maintaining it for k8s is something that's going to get a lot easier soon from Moby and k8s joining forces.

Secrets. Swarm got encrypted secrets in January, and you create one with `docker secret create ` or the API. It looks like k8s got it as an alpha feature at the end of June and it doesn't look easy: https://www.twistlock.com/2017/08/02/kubernetes-secrets-encr... They are making secrets functionality plug-able, to match the flexibiliy in networks, volumes, and logging.

As far as development power goes, 9k contributors and 9k pull requests in the last year is nothing to scoff at. That's also a misrepresentation because of the effort put forth for CNI and container standards that make a lot of the work interchangeable.

k8s has a lot of nice stuff and a great, evolving ecosystem, but I think you are being a bit harsh on Swarm. I think Moby (and derivatives) and k8s will benefit mutually from this, as they have over the past year already.

Post reply on HN