5 ms·
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 oth
by stonewhite 9y ago
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 you do that?
All I see is struggling for relevance, duplication of functionality and a very unnecessary vendor lock-in vector.
- raesene6 9y agoNot 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 this move is about Docker maintaining the trajectory in enterprise where people want the management GUIs and extra features but where Kubernetes and particularly Openshift is making progress at the expense of Docker EE.
- SEJeff 9y agoOpenshift is open source, Docker EE is not. Big difference. https://github.com/openshift/origin https://github.com/openshift/origin
- InTheArena 9y agoOpenshift 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.
- SEJeff 9y agoExcept 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-OpenShift-Origin-Online-and-Enterprise https://www.quora.com/What-is-the-difference-between-OpenShi...
- netwrk 9y agototally dodged the cost comparison concern.
- raesene6 9y agoAs InTheArena says, both Docker EE and Openshift have Open source cores and then supply commercial support and additions to suppplement them. It's a pretty common model amongst these companies, and hey they've got to make money somehow :)
- smarterclayton 9y agoEverything in openshift is open source at https://github.com/openshift/origin https://github.com/openshift/origin. The commercial version is long term support, security response and errata, and the stability around that. There's nothing that is withheld from the open source project. It is not open core. Edit: I forgot, the logo is not open source. So the logo is withheld :)
- SEJeff 9y agoIts surprising how many people don't realize this!
- jadbox 9y agoHuh, how does Openshift compare with Mesos DC/OS? Sounds similar
- raesene6 9y agoI've not look too much at Mesos and DC/OS, so could be wrong, but my understanding is that where Openshift is focused on managing containerized workloads using Kubernetes and Docker or CRI-O , Mesos and DC/OS are more widely focused on managing a variety of workloads which could include containers but also VMs etc. For me, the benefit of Openshift over vanilla Kubernetes is the additional management tooling and the strong default settings for production use. Openshift has a lot of focus on things like manageability and security which make it well suited to production workloads in enterprises and anecodotally it seems to be taking off quite well in enterprise customers.
- hatred 9y agoPretty similar. The main difference from the architecture standpoint is that Enterprise DC/OS uses Mesos+Marathon for container orchestration and OpenShift uses K8s. The other functionalities are mostly overlapping. There is also an OSS version of DC/OS minus some security features. Also, historically Mesos has had better support for running stateful workloads but K8s is catching up too. Recently, DC/OS announced support for K8s too which is similar to the K8s announcement from Docker. Disclosure: Apache Mesos committer.
- InTheArena 9y agoAnd it's a pain to setup, there is no key way to get a supportable license across all of them, breaks with each new K8s or Docker release, etc. Hopefully this is K8s, but with Swarm simplicity to get started.
- hosh 9y agoI 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 three technology I just mentioned reduces enough friction for contributing innovations that k8s will likely phase-shift. I just don't see Docker catching up. Sure, developers know them and think it has a good developer story. It doesn't. Docker for Mac and Window is practically useless when you have to struggle with file mounting for dev work. Docker Swarm is just not as robust as K8S, and the source of innovation going into Docker Swarm is coming from ideas from K8S. Someone said it. ... K8S, not Docker, is the Linux of the cloud native platform.
- yumyumyumyum 9y agoFrom 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 <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 <secret-name> <file/stdin>` 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-encryption/ 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.