11 ms·

I don't see how a freemium model solves the fundamental problem of Kubernetes eating their lunch. If anything surely this exacerbates it?

shykes 10y ago
Hi, I'm the founder of Docker. > [...] a freemium model Docker had already adopted an enterprise subscription + freemium model, but the offering was less clear (case in point: you weren't aware of it). This clarifies and simplifies our offering, and upgrades the enterprise offering along the way. > [...] solves the fundamental problem of Kubernetes eating their lunch Kubernetes is a component (like containerd or swarmkit), while Docker is a platform which integrates many components (like Cloud Foundry or Openshift). So Docker and Kubernetes are not directly competitive - Docker just happens not use Kubernetes as an orchestration component. It uses SwarmKit, an open-source component developed in-house (https://github.com/docker/swarmkit https://github.com/docker/swarmkit) A better comparison would be Docker and Openshift (which is Kubernetes-based). Is Openshift eating Docker's lunch? It certainly doesn't feel that way to me, but of course I am biased. Docker has three major advantages over Openshift: it's modular, it has better security, and it's not locked to RHEL. The main advantage of Openshift of course is that it is highly integrated into the Red Hat platform, which is appealing if you are already heavily invested in it. Openshift also benefits from the demand for a commercially supported product based on kubernetes. But either way the market is so early, and the demand so strong, I believe there is room for more than one major container platform. In a few years when the market starts maturing, we'll see!
- saycheese 10y ago
  My understanding is Red Hat is generating more revenue than Docker selling to the enterprise market. Is this true, and if so, how does Docker plan to beat them?
  - seeekr 10y ago
    Why does Docker Inc have to beat Red Hat? It's a big, growing market, enough cake for everyone?
    - bradmwalker 10y ago
      Aren't unicorn valuations based on the likelihood of winning a winner-take-all race?
      - shykes 10y ago
        No, they're based on the likelihood of achieving massive growth in revenue. In consumer markets that often requires a winner-takes-all race. In the enterprise market, which is Docker's market, winner-take-all is not as central because enterprise buyers care more about interoperability and integrations of many products made by many vendors. This is why, for example, Microsoft is seeing much more success with less tight coupling of Windows, Azure and Office.
        tmzt 10y ago
        Yet Docker is embracing "tight coupling" if not in the architecture ('batteries not included') then certainly in the marketing of their platform. If you use Docker it's expected (by Docker) that you will use Swarm. And now it's expected that your organization will use EE (is that Java EE? no it's Docker EE.) Docker followed the Apple II model into the enterprise, it was a fancy typewriter.
        shykes 10y ago
        Our motto is "batteries included but removable". We make sure the platform works great out of the box, and offers a smooth integrated experience. That is a big differentiator for Docker. At the same time, we also make sure you can pop the hood, mess with the components directly, and swap them out in various ways. You can do this within the Docker ecosyste with Docker plugins (for things like networking, storage, logging, authorization); or you can do it outside the ecosystem by hitting the low-level open-source components directly: containerd/runc, swarmkit, notary, libnetwork, infrakit.. All these components are usable standalone, and Docker preserves the loose coupling. You're right that currently Docker does not offer swappable orchestration - not because we don't want to, but because it's hard to do that without affecting the quality of the platform. Sometimes excessive abstraction leads to bad engineering. In early versions of Docker Swarm we experimented with pluggable support for Mesos, Kubernetes etc. It worked in demos but we didn't find it fit for production. I hope this helps understand our approach better.
  - shykes 10y ago
    In a growth market you don't have to beat anyone. You just have to deliver enough value to enough customers to capture part of that growth in the form of revenue. Which is the purpose of Docker EE :)
    - user5994461 10y ago
      More importantly than any of that, to capture any revenue you need to have a business model where you actually bill something! RedHat has OpenShift and support contracts. Google/AWS bill the usage directly, and get returns on other products you use. Docker didn't have much to sell.
- tyingq 10y ago
  "Kubernetes is a component (like containerd or swarmkit)...Docker is a platform...(like Cloud Foundry or Openshift)" I think that's pushing k8s farther to the left of what it really is, and pushing Docker farther to the right of what it really is. k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing. There are certainly potential customers debating, directly, k8s vs your full Docker platform, even if there are some gaps they have to fill with other software.
  - shykes 10y ago
    > k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing. Swarmkit does in fact implement service discovery, networking, and ingress load-balancing. It also implements out-of-the-box node security and mutual TLS, secure secrets management, a built-in raft store, infrastructure-agnostic overlay networking, and various goodies which we needed to make Docker work great out of the box. containerd is a different type of component entirely - in fact it is very complementary to kubernetes. > There are certainly potential customers debating, directly, k8s vs your full Docker platform They typically debate Docker vs kubernetes-based platforms (among other possible alternatives). If they're a Red Hat shop, they typically evaluate Openshift. Sometimes there's a team building an in-house platform. Nobody ever deploys kub alone in production. There is always some form of platform on top.
    - tyingq 10y ago
      >containerd is a different type of component entirely - in fact it is very complementary to kubernetes You made the initial comparison. > Nobody ever deploys kub alone in production. There is always some form of platform on top. Which is another way of saying "even if there are some gaps they have to fill with other software". Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.
- 013a 10y ago
  > Kubernetes is a component (like containerd or swarmkit), while Docker is a platform That's a really interesting angle to take on it. I think most users of Kubernetes would view it as the opposite; that K8s is the platform and Docker is just one component of that platform. It probably depends on which camp you've really bought into.
  - shykes 10y ago
    Yes, that is a common misunderstanding with the kubernetes community. We are correcting that misunderstanding with a few simple steps: - What kubernetes needs from Docker is a simple and robust container runtime. We are spinning out containerd (the core container runtime that powers the Docker platform) to provide exactly that. We are actively working with the Kubernetes community to make sure containerd is a perfect fit for kubernetes to integrate - a better fit than Docker itself, in fact, since it will be much smaller and change only very slowly. See https://containerd.tools https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ https://blog.docker.com/2017/02/containerd-summit-recap-slid... - This in turn will free Docker to focus on serving its userbase of developers and enterprises, which do want an integrated platform. Take a look at Docker for Mac/Windows or Docker for AWS/Azure for a sense of where we are taking the platform. - If you ask the core kubernetes maintainers, they will tell you that kube is intended to be the "kernel" of your distributed system, and it's up to you to build a platform on top. So in that way, I think we agree that kubernetes is ultimately a component - nothing derogatory about that! - You mention "camps". I think this evolution is very exciting because it allows us to move beyond the concept of camps. With containerd, a lot of bridges are already being built - engineers are collaborating peacefully and focusing on solving technical problems, which is a huge relief to everyone. Nobody likes drama. - Lastly, we are making sure Docker is a very modular and loosely coupled platform. So, who knows? If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component ;) The point is, we have an opportunity to refocus the conversation on technical tradeoffs rather than silly pissing contests. For all these reasons I think 2017 will be a good year for the entire container community.
    - thockingoog 10y ago
- curun1r 10y ago
  > Kubernetes is a component...while Docker is a platform which integrates many components...So Docker and Kubernetes are not directly competitive I wonder whether this is a distinction that exists in your mind, as someone intimately involved in the development of the docker tool and the Docker, Inc business model more so than in the minds of Docker users. You have a vested interest in making Docker encompass all that Docker, Inc produces. For many of us, this is actually against our interests. A lot of us want Docker to just be the base containerization layer with other offerings (like k8s, swarm, etc) built on top of it and branded separately. Continually adding more to the docker base layer adds confusion in the minds of people who don't follow Docker closely, makes it harder to get it approved for use in our organizations and increases the security footprint that needs to be audited. I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else rather than trying to stuff everything into one tool with one name. You have no idea how hard some of us have had to fight inside our organizations to simply deploy builds inside containers. Increasing the scope of what Docker means is just giving ammunition to our internal opponents. I understand why you're doing what you're doing...there's no money in developing that base layer unless you can parlay it into selling the other parts of your platform, but just understand that what you're doing isn't really user-friendly and many users won't pliantly go along with whatever marketing decisions you make. Like it or not, Docker is an ecosystem, not a platform. It has a life of its own that you're only partially able to shape. You have the advantage of being able to shape the roadmap for the underlying containerization layer and the goodwill that comes from putting in the work to have created initially and maintain that layer on an ongoing basis. That should be enough without leveraging it further.
  - shykes 10y ago
    > I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.
- thockingoog 10y ago
  > Kubernetes is a component (like containerd or swarmkit) That's a bit of stretch. Everything that people use to build something bigger is a "component", but that doesn't make it not a platform. Kubernetes is absolutely a platform, in that it is the base layer on which higher-level systems are built. It's somewhat less opinionated than OpenShift (which is literally Kubernetes++) or Docker (the full stack), but that is by design. Opinions are too fickle - Kubernetes is here to service the evolving fashion of opinions, while providing durable base abstractions.
  - shykes 10y ago
    That's totally fair. Maybe I should have used to word "product" instead of "platform".
    - thockingoog 10y ago
      THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc. It is the basis for many products (plural) and an ecosystem, which is really what we wanted to achieve.
- nul_byte 10y ago
  Can you explain how Docker has better security then OpenShift? (asking to learn, not a challenge).
  - shykes 10y ago
    Off the top of my head: - End-to-end content trust with crypto signatures and verifications using Notary/TUF https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ - Secrets management with encrypted storage and transport (https://blog.docker.com/2017/02/docker-secrets-management/ https://blog.docker.com/2017/02/docker-secrets-management/) - A vulnerability scanner that can detect vulnerabilities in arbitrary binaries without distro lock-in (ie. even if your developer built from source on a non-Red Hat distro, it will still catch vulnerabilities) https://docs.docker.com/datacenter/dtr/2.2/guides/admin/configure/set-up-vulnerability-scans/ https://docs.docker.com/datacenter/dtr/2.2/guides/admin/conf... - Secure orchestration out-of-the-box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... - Somewhat counter-intuitively, the default security profile is more secure in Docker than in Openshift, because the focus on "systemd everywhere" requires loosening the sandbox to allow systemd's tentacles to get through. In the past Red Hat has actually introduced CVEs in their forked version of Docker that didn't exist in the official Docker. - In Docker for AWS, Docker for Azure, Docker for Mac, Docker for Windows, we embed a specialized Linux distro that is trimmed down and locked down to the extreme, making OS surface area much much smaller than a traditional OS like Red Hat.
raesene6 10y ago
Whilst Kubernetes is really cool and has a lot of nice features I think, at the moment, it's lacking in some areas that are likely to be important for Enterprise customers who are likely to be interested in this Docker EE setup. Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing. Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.
- thockingoog 10y ago
  I would never deny that there's a lot of work to do, but let's be clear: Kubernetes' security model is evolving in concert with a large number of high-profile users' demands. Designing security in the absence of real customers would have been a mistake.
  - raesene6 10y ago
    Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.
    - thockingoog 10y ago
      My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)
esseti 10y ago
But isn't kubernetes managing docker containers? or does it support anything else?
- bdcravens 10y ago
  It supports rkt: https://kubernetes.io/docs/getting-started-guides/rkt/ https://kubernetes.io/docs/getting-started-guides/rkt/
  - ex3ndr 10y ago
    When i last checked out features of rkt on k8s it lacks of many fundamental things like log streaming and persisting data for a while after pod deletion.
  - esseti 10y ago
    i'll, thanks. just one question: how stable/good is rkt for production?
- Crsvoboda 10y ago
  Check out CRI-O. Goal is to make anything OCI compliant a first class citizen in Kubernetes. https://github.com/kubernetes-incubator/cri-o/blob/master/README.md https://github.com/kubernetes-incubator/cri-o/blob/master/RE...

shykes 10y ago

Hi, I'm the founder of Docker. > [...] a freemium model Docker had already adopted an enterprise subscription + freemium model, but the offering was less clear (case in point: you weren't aware of it). This clarifies and simplifies our offering, and upgrades the enterprise offering along the way. > [...] solves the fundamental problem of Kubernetes eating their lunch Kubernetes is a component (like containerd or swarmkit), while Docker is a platform which integrates many components (like Cloud Foundry or Openshift). So Docker and Kubernetes are not directly competitive - Docker just happens not use Kubernetes as an orchestration component. It uses SwarmKit, an open-source component developed in-house (https://github.com/docker/swarmkit https://github.com/docker/swarmkit) A better comparison would be Docker and Openshift (which is Kubernetes-based). Is Openshift eating Docker's lunch? It certainly doesn't feel that way to me, but of course I am biased. Docker has three major advantages over Openshift: it's modular, it has better security, and it's not locked to RHEL. The main advantage of Openshift of course is that it is highly integrated into the Red Hat platform, which is appealing if you are already heavily invested in it. Openshift also benefits from the demand for a commercially supported product based on kubernetes. But either way the market is so early, and the demand so strong, I believe there is room for more than one major container platform. In a few years when the market starts maturing, we'll see!

saycheese 10y ago
My understanding is Red Hat is generating more revenue than Docker selling to the enterprise market. Is this true, and if so, how does Docker plan to beat them?
- seeekr 10y ago
  Why does Docker Inc have to beat Red Hat? It's a big, growing market, enough cake for everyone?
  - bradmwalker 10y ago
    Aren't unicorn valuations based on the likelihood of winning a winner-take-all race?
    - shykes 10y ago
      No, they're based on the likelihood of achieving massive growth in revenue. In consumer markets that often requires a winner-takes-all race. In the enterprise market, which is Docker's market, winner-take-all is not as central because enterprise buyers care more about interoperability and integrations of many products made by many vendors. This is why, for example, Microsoft is seeing much more success with less tight coupling of Windows, Azure and Office.
      - tmzt 10y ago
        Yet Docker is embracing "tight coupling" if not in the architecture ('batteries not included') then certainly in the marketing of their platform. If you use Docker it's expected (by Docker) that you will use Swarm. And now it's expected that your organization will use EE (is that Java EE? no it's Docker EE.) Docker followed the Apple II model into the enterprise, it was a fancy typewriter.
        shykes 10y ago
        Our motto is "batteries included but removable". We make sure the platform works great out of the box, and offers a smooth integrated experience. That is a big differentiator for Docker. At the same time, we also make sure you can pop the hood, mess with the components directly, and swap them out in various ways. You can do this within the Docker ecosyste with Docker plugins (for things like networking, storage, logging, authorization); or you can do it outside the ecosystem by hitting the low-level open-source components directly: containerd/runc, swarmkit, notary, libnetwork, infrakit.. All these components are usable standalone, and Docker preserves the loose coupling. You're right that currently Docker does not offer swappable orchestration - not because we don't want to, but because it's hard to do that without affecting the quality of the platform. Sometimes excessive abstraction leads to bad engineering. In early versions of Docker Swarm we experimented with pluggable support for Mesos, Kubernetes etc. It worked in demos but we didn't find it fit for production. I hope this helps understand our approach better.
- shykes 10y ago
  In a growth market you don't have to beat anyone. You just have to deliver enough value to enough customers to capture part of that growth in the form of revenue. Which is the purpose of Docker EE :)
  - user5994461 10y ago
    More importantly than any of that, to capture any revenue you need to have a business model where you actually bill something! RedHat has OpenShift and support contracts. Google/AWS bill the usage directly, and get returns on other products you use. Docker didn't have much to sell.
tyingq 10y ago
"Kubernetes is a component (like containerd or swarmkit)...Docker is a platform...(like Cloud Foundry or Openshift)" I think that's pushing k8s farther to the left of what it really is, and pushing Docker farther to the right of what it really is. k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing. There are certainly potential customers debating, directly, k8s vs your full Docker platform, even if there are some gaps they have to fill with other software.
- shykes 10y ago
  > k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing. Swarmkit does in fact implement service discovery, networking, and ingress load-balancing. It also implements out-of-the-box node security and mutual TLS, secure secrets management, a built-in raft store, infrastructure-agnostic overlay networking, and various goodies which we needed to make Docker work great out of the box. containerd is a different type of component entirely - in fact it is very complementary to kubernetes. > There are certainly potential customers debating, directly, k8s vs your full Docker platform They typically debate Docker vs kubernetes-based platforms (among other possible alternatives). If they're a Red Hat shop, they typically evaluate Openshift. Sometimes there's a team building an in-house platform. Nobody ever deploys kub alone in production. There is always some form of platform on top.
  - tyingq 10y ago
    >containerd is a different type of component entirely - in fact it is very complementary to kubernetes You made the initial comparison. > Nobody ever deploys kub alone in production. There is always some form of platform on top. Which is another way of saying "even if there are some gaps they have to fill with other software". Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.
013a 10y ago
> Kubernetes is a component (like containerd or swarmkit), while Docker is a platform That's a really interesting angle to take on it. I think most users of Kubernetes would view it as the opposite; that K8s is the platform and Docker is just one component of that platform. It probably depends on which camp you've really bought into.
- shykes 10y ago
  Yes, that is a common misunderstanding with the kubernetes community. We are correcting that misunderstanding with a few simple steps: - What kubernetes needs from Docker is a simple and robust container runtime. We are spinning out containerd (the core container runtime that powers the Docker platform) to provide exactly that. We are actively working with the Kubernetes community to make sure containerd is a perfect fit for kubernetes to integrate - a better fit than Docker itself, in fact, since it will be much smaller and change only very slowly. See https://containerd.tools https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ https://blog.docker.com/2017/02/containerd-summit-recap-slid... - This in turn will free Docker to focus on serving its userbase of developers and enterprises, which do want an integrated platform. Take a look at Docker for Mac/Windows or Docker for AWS/Azure for a sense of where we are taking the platform. - If you ask the core kubernetes maintainers, they will tell you that kube is intended to be the "kernel" of your distributed system, and it's up to you to build a platform on top. So in that way, I think we agree that kubernetes is ultimately a component - nothing derogatory about that! - You mention "camps". I think this evolution is very exciting because it allows us to move beyond the concept of camps. With containerd, a lot of bridges are already being built - engineers are collaborating peacefully and focusing on solving technical problems, which is a huge relief to everyone. Nobody likes drama. - Lastly, we are making sure Docker is a very modular and loosely coupled platform. So, who knows? If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component ;) The point is, we have an opportunity to refocus the conversation on technical tradeoffs rather than silly pissing contests. For all these reasons I think 2017 will be a good year for the entire container community.
  - thockingoog 10y ago
curun1r 10y ago
> Kubernetes is a component...while Docker is a platform which integrates many components...So Docker and Kubernetes are not directly competitive I wonder whether this is a distinction that exists in your mind, as someone intimately involved in the development of the docker tool and the Docker, Inc business model more so than in the minds of Docker users. You have a vested interest in making Docker encompass all that Docker, Inc produces. For many of us, this is actually against our interests. A lot of us want Docker to just be the base containerization layer with other offerings (like k8s, swarm, etc) built on top of it and branded separately. Continually adding more to the docker base layer adds confusion in the minds of people who don't follow Docker closely, makes it harder to get it approved for use in our organizations and increases the security footprint that needs to be audited. I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else rather than trying to stuff everything into one tool with one name. You have no idea how hard some of us have had to fight inside our organizations to simply deploy builds inside containers. Increasing the scope of what Docker means is just giving ammunition to our internal opponents. I understand why you're doing what you're doing...there's no money in developing that base layer unless you can parlay it into selling the other parts of your platform, but just understand that what you're doing isn't really user-friendly and many users won't pliantly go along with whatever marketing decisions you make. Like it or not, Docker is an ecosystem, not a platform. It has a life of its own that you're only partially able to shape. You have the advantage of being able to shape the roadmap for the underlying containerization layer and the goodwill that comes from putting in the work to have created initially and maintain that layer on an ongoing basis. That should be enough without leveraging it further.
- shykes 10y ago
  > I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.
thockingoog 10y ago
> Kubernetes is a component (like containerd or swarmkit) That's a bit of stretch. Everything that people use to build something bigger is a "component", but that doesn't make it not a platform. Kubernetes is absolutely a platform, in that it is the base layer on which higher-level systems are built. It's somewhat less opinionated than OpenShift (which is literally Kubernetes++) or Docker (the full stack), but that is by design. Opinions are too fickle - Kubernetes is here to service the evolving fashion of opinions, while providing durable base abstractions.
- shykes 10y ago
  That's totally fair. Maybe I should have used to word "product" instead of "platform".
  - thockingoog 10y ago
    THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc. It is the basis for many products (plural) and an ecosystem, which is really what we wanted to achieve.
nul_byte 10y ago
Can you explain how Docker has better security then OpenShift? (asking to learn, not a challenge).
- shykes 10y ago
  Off the top of my head: - End-to-end content trust with crypto signatures and verifications using Notary/TUF https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ - Secrets management with encrypted storage and transport (https://blog.docker.com/2017/02/docker-secrets-management/ https://blog.docker.com/2017/02/docker-secrets-management/) - A vulnerability scanner that can detect vulnerabilities in arbitrary binaries without distro lock-in (ie. even if your developer built from source on a non-Red Hat distro, it will still catch vulnerabilities) https://docs.docker.com/datacenter/dtr/2.2/guides/admin/configure/set-up-vulnerability-scans/ https://docs.docker.com/datacenter/dtr/2.2/guides/admin/conf... - Secure orchestration out-of-the-box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... - Somewhat counter-intuitively, the default security profile is more secure in Docker than in Openshift, because the focus on "systemd everywhere" requires loosening the sandbox to allow systemd's tentacles to get through. In the past Red Hat has actually introduced CVEs in their forked version of Docker that didn't exist in the official Docker. - In Docker for AWS, Docker for Azure, Docker for Mac, Docker for Windows, we embed a specialized Linux distro that is trimmed down and locked down to the extreme, making OS surface area much much smaller than a traditional OS like Red Hat.

raesene6 10y ago

Whilst Kubernetes is really cool and has a lot of nice features I think, at the moment, it's lacking in some areas that are likely to be important for Enterprise customers who are likely to be interested in this Docker EE setup. Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing. Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.

thockingoog 10y ago
I would never deny that there's a lot of work to do, but let's be clear: Kubernetes' security model is evolving in concert with a large number of high-profile users' demands. Designing security in the absence of real customers would have been a mistake.
- raesene6 10y ago
  Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.
  - thockingoog 10y ago
    My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)

esseti 10y ago

But isn't kubernetes managing docker containers? or does it support anything else?

bdcravens 10y ago
It supports rkt: https://kubernetes.io/docs/getting-started-guides/rkt/ https://kubernetes.io/docs/getting-started-guides/rkt/
- ex3ndr 10y ago
  When i last checked out features of rkt on k8s it lacks of many fundamental things like log streaming and persisting data for a while after pod deletion.
- esseti 10y ago
  i'll, thanks. just one question: how stable/good is rkt for production?
Crsvoboda 10y ago
Check out CRI-O. Goal is to make anything OCI compliant a first class citizen in Kubernetes. https://github.com/kubernetes-incubator/cri-o/blob/master/README.md https://github.com/kubernetes-incubator/cri-o/blob/master/RE...