12 ms·

Adding Kubernetes support to the Docker platform

300 points by sz4kerto 9y ago

ealexhudson 9y ago
Have to say, I don't see the value in being able to have Swarm and k8s in the same cluster. "Docker: powered by Kubernetes" seems to be more of a marketing thing to move down the value chain, and not be seen as a basic piece of infrastructure.
- squeed 9y ago
  Agreed, just seems like marketing vaporspeak. Not exactly a trustworthy source, too. For example, containerd has been moved to the CNCF and made a broader project. Fine, but Docker runs a separate fork of containerd anyways. A neat marketing sleight-of-hand, but to what end?
- krallistic 9y ago
  Could be a nice bridge to move off docker :P
- shykes 9y ago
  You can disable Swarm or Kubernetes at will in each Docker EE cluster. Hybrid is very useful for enterprises who already have to manage both - it was a highly requested feature.
  - ealexhudson 9y ago
    I think I can understand "We have both and need to manage them more easily" as a request, because it's about pain right now. The thing I'm unsure about - and it would be really interesting to get your perspective on - is what this means for Swarm longer-term. Is there still going to be a reason why people will want hybrid? Is it a migration play? In a hybrid, over time I'd want to two to behave the same, and getting k8s up and running is a one-time cost and likely decreasing maintenance. It seems like a point solution.
    - grabcocque 9y ago
      K8S is looking for all the world like it's becoming the One True Container Orchestration Platform. Obviously Docker can't admit that because it has investors, and one thing you can't afford to do with investors is be honest. But reading the runes, it sure looks like Docker are providing a migration path from Swarm to K8s.
      - deleted 9y ago
        [deleted]
    - shykes 9y ago
      Swarm has a very special role, because it's custom-built to integrate in the Docker platform. Because it's so specific, it has a smaller standalone community than Kubernetes, but it makes up for it in focus and speed. You should expect a lot of bleeding edge features to ship in Swarm first, and a generalized version to land in kubernetes later. That's already been the case in the past: Windows support, secrets, node identity & promotion - those all shipped in Swarm first, then made their way to Kubernetes. Not because Swarm developers are smarter, but because they can focus on a narrower, more integrated problem set. Longer term, I think all orchestrators will converge to look more and more the same. Orchestration will become a commodity, and it will matter less and less which orchestrator you use, especially to developers. But this process will take a long time, and in the meantime enterprises (our primary customers) need to deal with the situation on the ground, which is a lot of Swarm and Kubernetes living side by side because of historical decisions made in 2015-17.
      - throwaway0071 9y ago
        "which is a lot of Swarm" I think that's an overstatement. I talk to a lot of professionals in this area and never seen Swarm deployed to production (from small to big corps). Anecdata warnings apply. Could you share some numbers?
        shykes 9y ago
        A good starting point is the archive of Dockercon talks, we've had quite a few enterprise customers come on stage to describe their production deployments. Or check out the customers section on docker.com.
grabcocque 9y ago
This seems a lot to me like Docker Inc. caving in to what has been painfully obvious for a while: K8s won and Swarm/Mesos lost the battle for hearts and minds in container orchestration. We can argue about why it happened, but I got the impression Docker Inc. were desperately trying to wish it away. Now reality has intruded and I am glad, though I predict they'll continue to maintain that Swarm is a first class platform for a while, then quietly let it wither on the vine until one day it's forgotten about. Also of note is Rancher 2.0's dropping support for Swarm and Mesos and focusing solely on K8S going forward.
- jadbox 9y ago
  Not sure why you would use Rancher if you have Mesos DC/OS? Mesos eclipses every significant feature, but I'd say Rancher is easier to set up initially.
  - HyperLinear 9y ago
    We run a DC/OS+Traefik stack here and can only praise it. Shame it doesn't get the same amount of love the other projects enjoy, but so far its rock-solid and we are more than happy with it. :)
sz4kerto 9y ago
Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)
- grabcocque 9y ago
  Why wouldn't you start with the one with the strongest mindshare and reputation? Even a cursory amount of googling shows there's a strong sentiment bias towards K8S over Swarm, it's not surprising that's what most people pick.
  - sz4kerto 9y ago
    But the thing is that as a developer, it doesn't matter what you start with - you have both and you're using compose files, etc. So Docker is trying to make the orchestrator less relevant now, and says that 'don't worry about the orchestrator'. You, as a developer, are using Docker and Compose. (Or at least that's what Docker is trying to do here, I think.)
    - grabcocque 9y ago
      I don't think having support for multiple orchestrators is valuable except as a transitional thing. In this case, presumably, transitioning from Swarm to K8S. Nobody is gonna want the hassle of supporting both outside a transition.
      - shykes 9y ago
        It's extremely valuable for large IT organizations. Most of them have at least one deployment of each orchestrator, because of the proliferation of container projects in their various teams. They are very eager to adopt a single platform to manage it all. Now Docker EE can be that platform. In general enterprises don't like to be told "throw away your existing system to adopt my platform".
- 9y ago
amouat 9y ago
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 will now bridge that gap, giving me a k8s node to run against in dev. Whilst Kubernetes has provided a great production orchestration solution, it never provided a great solution for development, meaning most users kept developing with Docker and Compose. It's great to see these worlds now coming together and hopefully leading to a first-class solution all the way from dev to prod.
- grabcocque 9y ago
  There's minikube. There's been minikube for a long while.
  - organsnyder 9y ago
    Minikube (and its derivative, MiniShift) have been very helpful for my team in bridging the gap between local development and production for Kubernetes and OpenShift.
    - gbraad 9y ago
      Thanks... Would love to know more about your experience. /me is one of the main contributors of Minishift
    - KurtMueller 9y ago
      As an ordinary developer, I'd love to hear your experience as well.
  - pmezard 9y ago
    Is there an easy way to build an image locally and start it in minikube without an external registry or running a local one?
familyit 9y ago
And Amazon making K8S a first class citizen
- malaporte 9y ago
  Any special insight here?
  - hijinks 9y ago
    Amazon did join the CNCF
    - oblio 9y ago
      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.
      - noway421 9y ago
        Don't they use Xen?
        oblio 9y ago
        For Elastic Compute Cloud (EC2) aka hosted VMs, yes. For ECS (EC2 Container Service), they use Docker on top of their VMs. So they have a Docker offering but not a Kubernetes one, at the moment.
      - freeman478 9y ago
        AWS Re:invent is in the end of november. I'd guess there will be some annoucements there ...
        islanderfun 9y ago
        That's what they said last year. We got Blox instead.
alexlarsson 9y ago
Is this a response to cri-o taking Docker out of Kubernetes?
- iamdeedubs 9y ago
  That was my initial thought as well. CRI-O hits 1.0, and then this. To me, it comes across as an attempt to stay in the news. Possibly to start changing the narrative from Docker vs Kubernetes to Docker <3's Kubernetes.
  - zenlikethat 9y ago
    Docker's conference (Dockercon) is happening right now so announcements coming from them are no surprise. A Kubernetes integration has probably been in the works for a while. It seems more likely to me that the CRI-O 1.0 announcement was a tactical move from Red Hat to hijack the conversation during Docker's own conference. CoreOS did the same thing 3 years ago when they announced rkt, trying to capitalize on Dockercon as a time to make a bunch of noise for themselves. Docker themselves have been no perfect angels in this regard, for instance with their infamous "accept no imitations" shirt at Red Hat's conference, I'm just calling it as I see it. Disclaimer: I worked for Docker, Inc. for 3 years.
sandGorgon 9y ago
How are they doing this? The big difference in swarm and kubernetes is the ingress. If this is seamless, then it has to be a batteries-included version of kubernetes with ingress, overlay network choice, etc already mapped out. What are the details here? Docker Swarm is beyond awesome and a great path for someone to scale up at the lower end of the scale spectrum (two containers). I really hope that this brings more people into Swarm. I'm also keen to see what it means for the Kompose project.
bonsai80 9y ago
I see them stating "...for developers using Windows and macOS" but not mentioning Linux. I feel like I'm missing something in how I'm reading that page. How can I make use of this on Linux?
- shykes 9y ago
  We're going to support Linux also. But we want to careful not to disrupt the users of the original container engine, as we transition it to Moby. In the future there will be a cleaner separation between "Docker CE, the developer tools" and "Moby engine, the open-source container engine". The last thing we want is someone to upgrade their production Linux engine to find an unexpected and unwanted kubernetes distribution wedged in. That separation is already in place for Windows and Mac, so we're starting there.
  - ntnn 9y ago
    That sounds like a shoehorned explanation. You're leaving developers on linux out to dry because people aren't paying attention to their production systems? Don't get me wrong, the work you guys do is cool and all, but that isn't a valid explanation from my point of view. Any company should have some sort of staging to test updated before rolling them out - it isn't up to the developers of the software to take care of this. And not only that - the switch will come at some point or another either way, so it doesn't make sense to hold that back from CE on linux so that someone doesn't 'find an unexpected and unwanted kubernetes distribution wedged in'. Those who would find that now would also be surprised by that later on. To add to that - containers are tested using CI/CD tools anyhow, which are predominantly powered by linux machines, which again makes this decision less convincing. The build may be fine on the developers machine and in production, but the CI/CD environment wouldn't reflect both of these environments. This looks more like a facade for selling more Docker EE licenses rather than wanting to protect users. Which is fine, of course - but then please say that.
    - InTheArena 9y ago
      Yes, but think about the whipping we would (and have) given them in the past for bundling these things directly into the engine without sufficient time for testing, or good sep of concerns.
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 ago
  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 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 ago
    Openshift is open source, Docker EE is not. Big difference. https://github.com/openshift/origin https://github.com/openshift/origin
    - InTheArena 9y ago
      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.
      - SEJeff 9y ago
        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-OpenShift-Origin-Online-and-Enterprise https://www.quora.com/What-is-the-difference-between-OpenShi...
InTheArena 9y ago
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 implementation was so poor, no one could use it. That kicked K8s up into hyperdrive. Parts of the K8s community have been particularly partisan in doing everything they can to minimize docker. Hopefully both sides _now_ come together and sing kumbaya, and we don't see a continuing KDE versus Gnome war a embrace and extend attitude by Docker or a continuing push to marginalize docker by the Kubernetes folks.
- erikb 9y ago
  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 99% of my effort on k8s because of that). And given enterprise support Openshift is still ongoing as the best solution. They are afaik the only ones that offer a complete set of answers to most questions you can have in the PaaS space. Everybody else is like "here's an API, choose one of 3 billion plugins" (just thinking CNI here). In the end for the customer it doesn't matter though. Customers just want things to run smoothly and if possible reduce their maintenance work force. They don't want choices, they want solutions.
  - InTheArena 9y ago
    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 plugins and displace Openshift. Plus, Openshift is _12k_ a application node on AWS: https://www.openshift.com/dedicated/index.html#pricing https://www.openshift.com/dedicated/index.html#pricing
caleblloyd 9y ago
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. Docker's announcement said they were using "real" kubernetes, not a fork or a wrapper. I've setup kubernetes by hand before and it is no easy feat. I'm looking forward to evaluating Docker's solution and maintenance upgrade process. UPDATE: My goal with this post is not to sell people one way or another, but moreso to explain where some of Docker's reasoning for this integration is coming from. Disclosure: I work for a Docker partner
- tachion 9y ago
  There is (and was for a while already) Kubernetes distribution called Tectonic, with enterprise support from CoreOS.
  - caleblloyd 9y ago
    Yes there are other supported distribution out there, I believe Cannonical also has one. IT orgs are very comfortable with RedHat though so that has been the majority of what we've seen IT orgs go to for Kubernetes. Disclosure: I work for a Docker Partner
- tnolet 9y ago
  Don't take this the wrong way, but I love how we are already talking about "historically" in the context of Kubernetes enterprise support when the first release of Kubernetes was in 2014 and AFAICS pro-support is something from the last 1.5 years. Crazy world!
- InTheArena 9y ago
  This. It's hard not to see Redhat (and to a lesser degree VMware) as the big looser of today's news. I absolutely want to see how this is implemented. Openshift's pricing is highway robbery. Disclosure: my company is (was?) a big Openshift consumer...
InTheArena 9y ago
So 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.
- HatchedLake721 9y ago
  AWS re:Invent is few weeks away, so hope they announce something Kubernetes related
  - InTheArena 9y ago
    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 ;-)
- erikb 9y ago
  It's already the smoothest environment to run vanilla K8S on anyways.
andy_ppp 9y ago
What does this mean for Docker Swarm, are they saying Kubenetes is "better"?
- why-el 9y ago
  Not necessarily. It's like when Apple supports PowerPoint when it has Keynote.
  - InTheArena 9y ago
    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.
    - why-el 9y ago
      Yep, I agree with you.
- erikb 9y ago
  Kubernetes currently has a lot of traction in Enterprise world. Even the CEOs of the big corps currently know what Kubernetes is. That's why you need to support it in some way if you want to continue to compete. At least for the time being. I think technically and in some regards also politically the Docker people are smarter though. In the most pro-docker comment I answered with "don't start to ignore k8s yet" and here I feel like saying "don't start to ignore docker(-swarm) yet". The battle is ongoing and these two are both possible leaders.
wyc 9y ago
From The Information's article "When Docker Said No to Google": > In 2014, Google approached a startup called Docker proposing the two collaborate on software each was developing to help companies manage lots of complex applications, according to people with knowledge of the proposal. But Solomon Hykes, Docker’s founder and CTO, said no. He wanted to go it alone. > Three years later, the cost of Mr. Hykes’ previously unreported decision is becoming apparent. The software that Google was developing was Kubernetes, an open-source product that now dominates its segment of the cloud software market. Docker’s rival software, Swarm, is also open-source but isn’t anywhere near as popular, two former Docker employees say. https://www.theinformation.com/when-docker-said-no-to-google https://www.theinformation.com/when-docker-said-no-to-google (Sorry...it's paywalled :/)
- InTheArena 9y ago
  Yep, Kudos for Docker for learning from their mistakes... But it's also a reminder of how powerful being low on the stack is.
InTheArena 9y ago
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/files https://github.com/docker/libnetwork/pull/1978/files
- zenlikethat 9y ago
  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.
  - erikb 9y ago
    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.
    - zenlikethat 9y ago
      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.
kozikow 9y ago
I use minikube for dev and it's pretty good. My description of my minikube+pycharm setup: https://kozikow.com/2016/09/16/using-pycharm-docker-integration-with-minikube/ https://kozikow.com/2016/09/16/using-pycharm-docker-integrat... . The only problem I didn't solve yet is debugging python code running in kubernetes using pycharm. If I run a container in pycharm using "Debug..." dialog it launches inside "docker context" rather than "kubernetes context". For example, I can't connect to kubernetes services via their ClusterIP - the container launched via pycharm does not see it. The only solution I found is using docker compose to set up an environment similar to kubernetes and using docker compose from pycharm. Hopefully, this announcement from docker will simplify this story.
joevandyk 9y ago
Anyone have any recommendations for getting k8s on a 3 machine system, like Digital Ocean or OVH?
- chmielewski 9y ago
  https://ronanquillevere.github.io/2017/05/16/kubernetes-ovh.html https://ronanquillevere.github.io/2017/05/16/kubernetes-ovh.... https://github.com/antoineco/kOVHernetes 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.

300 points by sz4kerto 9y ago

Have to say, I don't see the value in being able to have Swarm and k8s in the same cluster. "Docker: powered by Kubernetes" seems to be more of a marketing thing to move down the value chain, and not be seen as a basic piece of infrastructure.

squeed 9y ago
Agreed, just seems like marketing vaporspeak. Not exactly a trustworthy source, too. For example, containerd has been moved to the CNCF and made a broader project. Fine, but Docker runs a separate fork of containerd anyways. A neat marketing sleight-of-hand, but to what end?
krallistic 9y ago
Could be a nice bridge to move off docker :P
shykes 9y ago
You can disable Swarm or Kubernetes at will in each Docker EE cluster. Hybrid is very useful for enterprises who already have to manage both - it was a highly requested feature.
- ealexhudson 9y ago
  I think I can understand "We have both and need to manage them more easily" as a request, because it's about pain right now. The thing I'm unsure about - and it would be really interesting to get your perspective on - is what this means for Swarm longer-term. Is there still going to be a reason why people will want hybrid? Is it a migration play? In a hybrid, over time I'd want to two to behave the same, and getting k8s up and running is a one-time cost and likely decreasing maintenance. It seems like a point solution.
  - grabcocque 9y ago
    K8S is looking for all the world like it's becoming the One True Container Orchestration Platform. Obviously Docker can't admit that because it has investors, and one thing you can't afford to do with investors is be honest. But reading the runes, it sure looks like Docker are providing a migration path from Swarm to K8s.
    - deleted 9y ago
      [deleted]
  - shykes 9y ago
    Swarm has a very special role, because it's custom-built to integrate in the Docker platform. Because it's so specific, it has a smaller standalone community than Kubernetes, but it makes up for it in focus and speed. You should expect a lot of bleeding edge features to ship in Swarm first, and a generalized version to land in kubernetes later. That's already been the case in the past: Windows support, secrets, node identity & promotion - those all shipped in Swarm first, then made their way to Kubernetes. Not because Swarm developers are smarter, but because they can focus on a narrower, more integrated problem set. Longer term, I think all orchestrators will converge to look more and more the same. Orchestration will become a commodity, and it will matter less and less which orchestrator you use, especially to developers. But this process will take a long time, and in the meantime enterprises (our primary customers) need to deal with the situation on the ground, which is a lot of Swarm and Kubernetes living side by side because of historical decisions made in 2015-17.
    - throwaway0071 9y ago
      "which is a lot of Swarm" I think that's an overstatement. I talk to a lot of professionals in this area and never seen Swarm deployed to production (from small to big corps). Anecdata warnings apply. Could you share some numbers?
      - shykes 9y ago
        A good starting point is the archive of Dockercon talks, we've had quite a few enterprise customers come on stage to describe their production deployments. Or check out the customers section on docker.com.

grabcocque 9y ago

This seems a lot to me like Docker Inc. caving in to what has been painfully obvious for a while: K8s won and Swarm/Mesos lost the battle for hearts and minds in container orchestration. We can argue about why it happened, but I got the impression Docker Inc. were desperately trying to wish it away. Now reality has intruded and I am glad, though I predict they'll continue to maintain that Swarm is a first class platform for a while, then quietly let it wither on the vine until one day it's forgotten about. Also of note is Rancher 2.0's dropping support for Swarm and Mesos and focusing solely on K8S going forward.

jadbox 9y ago
Not sure why you would use Rancher if you have Mesos DC/OS? Mesos eclipses every significant feature, but I'd say Rancher is easier to set up initially.
- HyperLinear 9y ago
  We run a DC/OS+Traefik stack here and can only praise it. Shame it doesn't get the same amount of love the other projects enjoy, but so far its rock-solid and we are more than happy with it. :)

sz4kerto 9y ago

Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)

grabcocque 9y ago
Why wouldn't you start with the one with the strongest mindshare and reputation? Even a cursory amount of googling shows there's a strong sentiment bias towards K8S over Swarm, it's not surprising that's what most people pick.
- sz4kerto 9y ago
  But the thing is that as a developer, it doesn't matter what you start with - you have both and you're using compose files, etc. So Docker is trying to make the orchestrator less relevant now, and says that 'don't worry about the orchestrator'. You, as a developer, are using Docker and Compose. (Or at least that's what Docker is trying to do here, I think.)
  - grabcocque 9y ago
    I don't think having support for multiple orchestrators is valuable except as a transitional thing. In this case, presumably, transitioning from Swarm to K8S. Nobody is gonna want the hassle of supporting both outside a transition.
    - shykes 9y ago
      It's extremely valuable for large IT organizations. Most of them have at least one deployment of each orchestrator, because of the proliferation of container projects in their various teams. They are very eager to adopt a single platform to manage it all. Now Docker EE can be that platform. In general enterprises don't like to be told "throw away your existing system to adopt my platform".
9y ago

amouat 9y ago

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 will now bridge that gap, giving me a k8s node to run against in dev. Whilst Kubernetes has provided a great production orchestration solution, it never provided a great solution for development, meaning most users kept developing with Docker and Compose. It's great to see these worlds now coming together and hopefully leading to a first-class solution all the way from dev to prod.

grabcocque 9y ago
There's minikube. There's been minikube for a long while.
- organsnyder 9y ago
  Minikube (and its derivative, MiniShift) have been very helpful for my team in bridging the gap between local development and production for Kubernetes and OpenShift.
  - gbraad 9y ago
    Thanks... Would love to know more about your experience. /me is one of the main contributors of Minishift
  - KurtMueller 9y ago
    As an ordinary developer, I'd love to hear your experience as well.
- pmezard 9y ago
  Is there an easy way to build an image locally and start it in minikube without an external registry or running a local one?

familyit 9y ago

And Amazon making K8S a first class citizen

malaporte 9y ago
Any special insight here?
- hijinks 9y ago
  Amazon did join the CNCF
  - oblio 9y ago
    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.
    - noway421 9y ago
      Don't they use Xen?
      - oblio 9y ago
        For Elastic Compute Cloud (EC2) aka hosted VMs, yes. For ECS (EC2 Container Service), they use Docker on top of their VMs. So they have a Docker offering but not a Kubernetes one, at the moment.
    - freeman478 9y ago
      AWS Re:invent is in the end of november. I'd guess there will be some annoucements there ...
      - islanderfun 9y ago
        That's what they said last year. We got Blox instead.

alexlarsson 9y ago

Is this a response to cri-o taking Docker out of Kubernetes?

iamdeedubs 9y ago
That was my initial thought as well. CRI-O hits 1.0, and then this. To me, it comes across as an attempt to stay in the news. Possibly to start changing the narrative from Docker vs Kubernetes to Docker <3's Kubernetes.
- zenlikethat 9y ago
  Docker's conference (Dockercon) is happening right now so announcements coming from them are no surprise. A Kubernetes integration has probably been in the works for a while. It seems more likely to me that the CRI-O 1.0 announcement was a tactical move from Red Hat to hijack the conversation during Docker's own conference. CoreOS did the same thing 3 years ago when they announced rkt, trying to capitalize on Dockercon as a time to make a bunch of noise for themselves. Docker themselves have been no perfect angels in this regard, for instance with their infamous "accept no imitations" shirt at Red Hat's conference, I'm just calling it as I see it. Disclaimer: I worked for Docker, Inc. for 3 years.

sandGorgon 9y ago

How are they doing this? The big difference in swarm and kubernetes is the ingress. If this is seamless, then it has to be a batteries-included version of kubernetes with ingress, overlay network choice, etc already mapped out. What are the details here? Docker Swarm is beyond awesome and a great path for someone to scale up at the lower end of the scale spectrum (two containers). I really hope that this brings more people into Swarm. I'm also keen to see what it means for the Kompose project.

bonsai80 9y ago

I see them stating "...for developers using Windows and macOS" but not mentioning Linux. I feel like I'm missing something in how I'm reading that page. How can I make use of this on Linux?

shykes 9y ago
We're going to support Linux also. But we want to careful not to disrupt the users of the original container engine, as we transition it to Moby. In the future there will be a cleaner separation between "Docker CE, the developer tools" and "Moby engine, the open-source container engine". The last thing we want is someone to upgrade their production Linux engine to find an unexpected and unwanted kubernetes distribution wedged in. That separation is already in place for Windows and Mac, so we're starting there.
- ntnn 9y ago
  That sounds like a shoehorned explanation. You're leaving developers on linux out to dry because people aren't paying attention to their production systems? Don't get me wrong, the work you guys do is cool and all, but that isn't a valid explanation from my point of view. Any company should have some sort of staging to test updated before rolling them out - it isn't up to the developers of the software to take care of this. And not only that - the switch will come at some point or another either way, so it doesn't make sense to hold that back from CE on linux so that someone doesn't 'find an unexpected and unwanted kubernetes distribution wedged in'. Those who would find that now would also be surprised by that later on. To add to that - containers are tested using CI/CD tools anyhow, which are predominantly powered by linux machines, which again makes this decision less convincing. The build may be fine on the developers machine and in production, but the CI/CD environment wouldn't reflect both of these environments. This looks more like a facade for selling more Docker EE licenses rather than wanting to protect users. Which is fine, of course - but then please say that.
  - InTheArena 9y ago
    Yes, but think about the whipping we would (and have) given them in the past for bundling these things directly into the engine without sufficient time for testing, or good sep of concerns.

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 ago
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 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 ago
  Openshift is open source, Docker EE is not. Big difference. https://github.com/openshift/origin https://github.com/openshift/origin
  - InTheArena 9y ago
    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.
    - SEJeff 9y ago
      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-OpenShift-Origin-Online-and-Enterprise https://www.quora.com/What-is-the-difference-between-OpenShi...

InTheArena 9y ago

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 implementation was so poor, no one could use it. That kicked K8s up into hyperdrive. Parts of the K8s community have been particularly partisan in doing everything they can to minimize docker. Hopefully both sides _now_ come together and sing kumbaya, and we don't see a continuing KDE versus Gnome war a embrace and extend attitude by Docker or a continuing push to marginalize docker by the Kubernetes folks.

erikb 9y ago
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 99% of my effort on k8s because of that). And given enterprise support Openshift is still ongoing as the best solution. They are afaik the only ones that offer a complete set of answers to most questions you can have in the PaaS space. Everybody else is like "here's an API, choose one of 3 billion plugins" (just thinking CNI here). In the end for the customer it doesn't matter though. Customers just want things to run smoothly and if possible reduce their maintenance work force. They don't want choices, they want solutions.
- InTheArena 9y ago
  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 plugins and displace Openshift. Plus, Openshift is _12k_ a application node on AWS: https://www.openshift.com/dedicated/index.html#pricing https://www.openshift.com/dedicated/index.html#pricing

caleblloyd 9y ago

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. Docker's announcement said they were using "real" kubernetes, not a fork or a wrapper. I've setup kubernetes by hand before and it is no easy feat. I'm looking forward to evaluating Docker's solution and maintenance upgrade process. UPDATE: My goal with this post is not to sell people one way or another, but moreso to explain where some of Docker's reasoning for this integration is coming from. Disclosure: I work for a Docker partner

tachion 9y ago
There is (and was for a while already) Kubernetes distribution called Tectonic, with enterprise support from CoreOS.
- caleblloyd 9y ago
  Yes there are other supported distribution out there, I believe Cannonical also has one. IT orgs are very comfortable with RedHat though so that has been the majority of what we've seen IT orgs go to for Kubernetes. Disclosure: I work for a Docker Partner
tnolet 9y ago
Don't take this the wrong way, but I love how we are already talking about "historically" in the context of Kubernetes enterprise support when the first release of Kubernetes was in 2014 and AFAICS pro-support is something from the last 1.5 years. Crazy world!
InTheArena 9y ago
This. It's hard not to see Redhat (and to a lesser degree VMware) as the big looser of today's news. I absolutely want to see how this is implemented. Openshift's pricing is highway robbery. Disclosure: my company is (was?) a big Openshift consumer...

InTheArena 9y ago

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

HatchedLake721 9y ago
AWS re:Invent is few weeks away, so hope they announce something Kubernetes related
- InTheArena 9y ago
  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 ;-)
erikb 9y ago
It's already the smoothest environment to run vanilla K8S on anyways.

andy_ppp 9y ago

What does this mean for Docker Swarm, are they saying Kubenetes is "better"?

why-el 9y ago
Not necessarily. It's like when Apple supports PowerPoint when it has Keynote.
- InTheArena 9y ago
  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.
  - why-el 9y ago
    Yep, I agree with you.
erikb 9y ago
Kubernetes currently has a lot of traction in Enterprise world. Even the CEOs of the big corps currently know what Kubernetes is. That's why you need to support it in some way if you want to continue to compete. At least for the time being. I think technically and in some regards also politically the Docker people are smarter though. In the most pro-docker comment I answered with "don't start to ignore k8s yet" and here I feel like saying "don't start to ignore docker(-swarm) yet". The battle is ongoing and these two are both possible leaders.

wyc 9y ago

From The Information's article "When Docker Said No to Google": > In 2014, Google approached a startup called Docker proposing the two collaborate on software each was developing to help companies manage lots of complex applications, according to people with knowledge of the proposal. But Solomon Hykes, Docker’s founder and CTO, said no. He wanted to go it alone. > Three years later, the cost of Mr. Hykes’ previously unreported decision is becoming apparent. The software that Google was developing was Kubernetes, an open-source product that now dominates its segment of the cloud software market. Docker’s rival software, Swarm, is also open-source but isn’t anywhere near as popular, two former Docker employees say. https://www.theinformation.com/when-docker-said-no-to-google https://www.theinformation.com/when-docker-said-no-to-google (Sorry...it's paywalled :/)

InTheArena 9y ago
Yep, Kudos for Docker for learning from their mistakes... But it's also a reminder of how powerful being low on the stack is.

InTheArena 9y ago

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/files https://github.com/docker/libnetwork/pull/1978/files

zenlikethat 9y ago
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.
- erikb 9y ago
  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.
  - zenlikethat 9y ago
    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.

kozikow 9y ago

I use minikube for dev and it's pretty good. My description of my minikube+pycharm setup: https://kozikow.com/2016/09/16/using-pycharm-docker-integration-with-minikube/ https://kozikow.com/2016/09/16/using-pycharm-docker-integrat... . The only problem I didn't solve yet is debugging python code running in kubernetes using pycharm. If I run a container in pycharm using "Debug..." dialog it launches inside "docker context" rather than "kubernetes context". For example, I can't connect to kubernetes services via their ClusterIP - the container launched via pycharm does not see it. The only solution I found is using docker compose to set up an environment similar to kubernetes and using docker compose from pycharm. Hopefully, this announcement from docker will simplify this story.

joevandyk 9y ago

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

chmielewski 9y ago
https://ronanquillevere.github.io/2017/05/16/kubernetes-ovh.html https://ronanquillevere.github.io/2017/05/16/kubernetes-ovh.... https://github.com/antoineco/kOVHernetes 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.