121–130 of 144 posts
Earlier quoted context omitted.
Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.
Well I started with Swarm because Kubes had additional learning to do. Swarm worked from the same docker-compose.yml files I already knew. Looking at moving to k8s but that was my reason for swarm at the time. And it was the right one as it just worked with minimal effort.
Earlier quoted context omitted.
> You should expect a lot of bleeding edge features to ship in Swarm first The development of those bleeding edge features is well hidden. The contributions graphs seem to indicate that Swarm is at best a ghost town. Perhaps the action is happening somewhere else and/or Docker will start investing in Swarm once more. https://github.com/docker/swarm/graphs/contributors
You may be looking for swarmkit https://github.com/docker/swarmkit
Great news for everyone except for VMWare (this is a simple compelling operating system for data centers that spans both windows and mac) and Openshift (which was one of the few viable ways of actually purchasing Kubernetes support). A lot of egos on both sides had to be suppressed to make this happen. Docker Swarm was a key driver in making Kubernetes popular because everyone realized that they needed swarm, but the…
I've said before and I'll say again: Red Hat, Microsoft and Google (and Pivotal and VMWare) are going to wind up making more money from Docker than Docker Inc does. Kubernetes has swept the field at the container-orchestrator level, the rest is a fight for the upper part of the stack.
Disclosure: I work for Pivotal, though not on PKS.
Earlier quoted context omitted.
Absolutely. Running k8s on bare metal requires full-time dedicated staff. Running k8s with GKE, and possibly also Azure Container Service, though I have no direct experience, is a one-off half-day effort. What people usually don't realize is that once you're in the cloud, all your services talk TCP. A service in GKE and another one in AWS are just a network hop away. Two considerations are: * Network egress costs, wh…
Yeah, thanks for sharing your experiences on that. Unfortunately our egress costs would likely be significant. I am honestly anxious to get my employer started on the path to k8s, but until the tooling reduces the hours required to maintain it successfully, Swarm seems like the superior solution if you are locked in on a non-GKE/Azure Container Service provider. I have heard good things about Kops helping setup/enabl…
Disclosure: I work for Pivotal.
This will give IT organizations the option of getting an Enterprise supported distribution of Kubernetes from Docker. Historically, most IT orgs requiring supported k8s have either gone cloud with something like Google Container Engine or gone with OpenShift and get support from RedHat. OpenShift is a fork if kubernetes though and lags a year or so behind. It also adds opinionated features such as Image Streams. Dock…
I have skin in this game as well, as my other comments on this post demonstrate. We (Pivotal & Google) kinda skipped the hard bits of keeping up with k8s by packaging it as a BOSH release, so we'll always be up to date. That's actually one of the project goals: parity with vanilla k8s, because it is vanilla k8s, operated by a lower-level system.
This really helps with the dev-to-production story for containers. When people first started using Docker containers, we were promised things would run identically in dev and production - no more "but it worked on my laptop" issues. Then the rise of orchestrators meant that there again became a significant difference between running an app locally (in compose) and in production (on Kubernetes). Docker for Mac/Windows…
in order to test your app in prod-like env you need to run prod-like env locally. ie. a k8s-cluster that is close enough to prod. for that you will have to at least simulate multi-node-setup and run all cluster-addons like in production. i am excited about this move from docker but i don't think it will solve all the problems. i think once you have a bigger team it is worthwhile to run a second k8s-cluster besides pr…
Earlier quoted context omitted.
Yes. And I don't mean to knock minikube, but this is potentially simpler and easier to use.
I don't see how it could be much simpler and/or easier. In my experience, Minikube just works, out-of-the-box.
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 production-grade deployments (single binary, which means a rewrite of main function for etcd and all control plane components, as well as hard to debug basic performance issues in control plane, there is one large process and you don't know what is wrong, also there is no way to use your favourite network add-on).
Additionally, minikube is based on legacy Docker libmachine, it is not really maintained anymore.
This really helps with the dev-to-production story for containers. When people first started using Docker containers, we were promised things would run identically in dev and production - no more "but it worked on my laptop" issues. Then the rise of orchestrators meant that there again became a significant difference between running an app locally (in compose) and in production (on Kubernetes). Docker for Mac/Windows…
Docker for Windows is pretty much unusable at the moment.
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…
Note: resource intensive might be because of the hypervisor but generally shouldn't be that bad.
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…
That's for OpenShift Dedicated, in which you're literally buying dedicated engineer & support time along with IaaS, PaaS plus our AWS costs.
OpenShift in on-premise or cloud environments comes in a different pricing structure based on (v)Cores or CPU Sockets.