What does this mean for Docker Swarm, are they saying Kubenetes is "better"?
Not necessarily. It's like when Apple supports PowerPoint when it has Keynote.
Adding Kubernetes support to the Docker platform
71–80 of 144 posts
Re: Adding Kubernetes support to the Docker platform
#72So now the last question is how long does it take for AWS to finally abandon ECS and formally support K8S as a service? I think this makes it kind of slam dunk, but it is forcing aWS to give up a lot of proprietary lock in.
AWS re:Invent is few weeks away, so hope they announce something Kubernetes related
I'm going to be there front and center. I know that they had something they chose not to announce last year... hopefully they make up for it full tilt this year ;-)
Re: Adding Kubernetes support to the Docker platform
#73Earlier quoted context omitted.
Could you elaborate what alternatives to docker are worth checking out? I'm unfamiliar with containers and out of my head I can't name anything besides docker.
There's CRI-O. v1.0 was announced yesterday - https://medium.com/cri-o/cri-o-1-0-is-here-d06b97b92a98
The lesson of Linux is that fragmentation is bad. This is a chance to fight fragmentation.
Re: Adding Kubernetes support to the Docker platform
#74Earlier quoted context omitted.
Yes, but it will be a while, I think, before they actually offer something based on it. I don't see any service based on it at this point. AWS ECS is based on Docker.
AWS Re:invent is in the end of november. I'd guess there will be some annoucements there ...
That's what they said last year. We got Blox instead.
Re: Adding Kubernetes support to the Docker platform
#75What does this mean for Docker Swarm, are they saying Kubenetes is "better"?
Not necessarily. It's like when Apple supports PowerPoint when it has Keynote.
Ehh. I think the writing is more then on the wall with Swarm. K8s is a better solution, and at this point. Docker + K8s should be the standard. Fragmentation is bad.
Re: Adding Kubernetes support to the Docker platform
#76This 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…
There's minikube. There's been minikube for a long while.
which is actually just docker-machine. This could be a infiniately simpler, better and scalable minikube ;-)
Re: Adding Kubernetes support to the Docker platform
#77Re: Adding Kubernetes support to the Docker platform
#78This 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…
I believe when you say "simulating multi-node setup and addons" - you're seeing it from an operations perspective. Thing is, those concerns don't need to be repeated for every single application. When a consumer says "test", they mean testing functionality. Not testing operations like network I/O bandwidth, sysctl parameters, rebalancing, etc. The expectation is that, operational folks (kubernetes integration tests, ops integration tests, GKE tests, etc) already have tested and verified all of that.
This is not like ops vs dev. When you use a library or framework (say, spring) - you don't test whether HTTP MIME Types are working correctly in spring. You assume the library already has all that tested and covered, and as a consumer, you write tests for what you code. The library's code (and tests) are abstracted from you. This is similar, except for operational stuff. In fact, there is no major difference between them. Its just layering and separation of concerns.
There is no such thing as 100% prod except prod. Even for rocket launches. 90+% is good enough for majority of cases, and is already on the higher side.
Re: Adding Kubernetes support to the Docker platform
#79Earlier quoted context omitted.
Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.
I think several others have commented on this, but the learning curve of Swarm seems insignificant to the setup and implementation of a k8s cluster. I work with a team of four total developers and realistically two of us handle the vast majority of "operations." As a result, what was important for us in orchestration was ease of setup, speed of initial implementation, and the lowest immediate and ongoing difficulty a…
I've been running solo a GKE cluster for almost 2 years. Maaaybe I spent 1 week on eng effort on it.
Re: Adding Kubernetes support to the Docker platform
#80Disregarding 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…
Not really sure I see the vendor lock-in here. If you use Docker EE sure you're going to be locked in to their solutions to an extent but then that's true of adopting any commercial supported solution that provides layers on top of the base k8s clustering tech (e.g. Openshift). The API is still k8s and the YAML files are identical, so migration at a technical level off that platform should be easy enough. I think thi…
Huh, how does Openshift compare with Mesos DC/OS? Sounds similar