5 ms·

Also interested how the Rocket/Docker debate will fit in with this?

ecnahc515 12y ago
Kubernetes is actually in the process of getting rocket support in addition to existing support for Docker. More details can be found here: https://github.com/GoogleCloudPlatform/kubernetes/pull/5518 https://github.com/GoogleCloudPlatform/kubernetes/pull/5518
kelseyhightower 12y ago
This is a great question. CoreOS is currently working on adding support for Rocket[0] to Kubernetes. There is still a lot of work to do here, but things are progressing nicely. Kubernetes is a true opensource project and accepts contributions that makes sense. Supporting another container runtime engine makes sense in terms of choice for the community and forces clean separation between Kubernetes, the cluster manager, and the underlying container runtime engine. When it comes to Rocket vs Docker I think the competition will be good for both projects and the community as a whole. At the end of the day, both projects and the communities behind them want people to be successful with containers. [0] https://github.com/GoogleCloudPlatform/kubernetes/pull/5518 https://github.com/GoogleCloudPlatform/kubernetes/pull/5518
- Alupis 12y ago
  > both projects and the communities behind them want people to be successful with containers. I think it's better said, Docker wants people to be successful with containers, so long as it's Docker containers.[1][2][3] We've seen a lot of very open work coming from the CoreOS team with Rocket and the ACI... unfortunately we've only seen negativity and mud slinging coming from the other camp.[2][4][5][6][7] Docker is more interested in having an "open" implementation, rather than an open specification. The things is... an Open Specification is far more important for industry changing technology like containers. [1] https://news.ycombinator.com/item?id=8683705 https://news.ycombinator.com/item?id=8683705 [2] https://news.ycombinator.com/item?id=8938409 https://news.ycombinator.com/item?id=8938409 [3] https://news.ycombinator.com/item?id=8789181 https://news.ycombinator.com/item?id=8789181 [4] https://news.ycombinator.com/item?id=8938066 https://news.ycombinator.com/item?id=8938066 [5] https://news.ycombinator.com/item?id=8938176 https://news.ycombinator.com/item?id=8938176 [6] https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643 [7] https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538
  - curun1r 12y ago
    Don't kid yourself...it's been negative on both sides. CoreOS called Docker fundamentally flawed, though they've backed away from that a bit. From what I can tell, CoreOS was happy to let Docker, Inc control the container platform and build orchestration tools on top of Docker, since it's pretty clear that no one is willing to pay for the base containerization layer and the only money to be made is in orchestration. But then Docker released their own orchestration strategy and that started the current period we're in where both companies have come off as being very unprofessional and concerned only with their own future success. Between Docker trying to build almost everything into the actual Docker executable (it's a container runner, API server, build tool, process monitor, cloud provisioner and orchestration tool...those last two are only not the case because they got called on the strategy) and CoreOS's pointless pushing of rkt (rkt itself isn't pointless, but the PR to add rkt support to Docker was, as was implementing Docker support in rkt). Both sides have foolishly put their own interests ahead of the container ecosystem. To say that either of the two companies has been the bad actor in all the drama would be biased. They've both come across like spoiled little children trying to get their way. As someone who has been pushing my company (~8000 employees) to consider implementing a containerized deployment strategy, it's been hugely inconvenient to have to concede to people arguing against containerization all the points around how unprofessional the companies in the space have been, both in behavior and coding practices.
    - fredkelly 12y ago
      +1, This has been my interpretation too, I feel like a lot of the rkt PR was subtly aimed at Docker, it was very much "this is why it's better" rather than "this is why it's good".
      - politician 12y ago
        Honestly, as a consumer of both projects, I'm happy that rkt exists because it provides a working demonstration of a solution where container images are orthogonal to other concepts such as orchestration. If it went the other way, our vendors would be swearing up and down that the only way for this container thing to work is if we install their complete solution. I love my Apple MacBook Pro and its soldered components, but I need my data center to be meaningfully upgradable.

Kubernetes is actually in the process of getting rocket support in addition to existing support for Docker. More details can be found here: https://github.com/GoogleCloudPlatform/kubernetes/pull/5518 https://github.com/GoogleCloudPlatform/kubernetes/pull/5518

kelseyhightower 12y ago

This is a great question. CoreOS is currently working on adding support for Rocket[0] to Kubernetes. There is still a lot of work to do here, but things are progressing nicely. Kubernetes is a true opensource project and accepts contributions that makes sense. Supporting another container runtime engine makes sense in terms of choice for the community and forces clean separation between Kubernetes, the cluster manager, and the underlying container runtime engine. When it comes to Rocket vs Docker I think the competition will be good for both projects and the community as a whole. At the end of the day, both projects and the communities behind them want people to be successful with containers. [0] https://github.com/GoogleCloudPlatform/kubernetes/pull/5518 https://github.com/GoogleCloudPlatform/kubernetes/pull/5518

Alupis 12y ago
> both projects and the communities behind them want people to be successful with containers. I think it's better said, Docker wants people to be successful with containers, so long as it's Docker containers.[1][2][3] We've seen a lot of very open work coming from the CoreOS team with Rocket and the ACI... unfortunately we've only seen negativity and mud slinging coming from the other camp.[2][4][5][6][7] Docker is more interested in having an "open" implementation, rather than an open specification. The things is... an Open Specification is far more important for industry changing technology like containers. [1] https://news.ycombinator.com/item?id=8683705 https://news.ycombinator.com/item?id=8683705 [2] https://news.ycombinator.com/item?id=8938409 https://news.ycombinator.com/item?id=8938409 [3] https://news.ycombinator.com/item?id=8789181 https://news.ycombinator.com/item?id=8789181 [4] https://news.ycombinator.com/item?id=8938066 https://news.ycombinator.com/item?id=8938066 [5] https://news.ycombinator.com/item?id=8938176 https://news.ycombinator.com/item?id=8938176 [6] https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643 [7] https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538
- curun1r 12y ago
  Don't kid yourself...it's been negative on both sides. CoreOS called Docker fundamentally flawed, though they've backed away from that a bit. From what I can tell, CoreOS was happy to let Docker, Inc control the container platform and build orchestration tools on top of Docker, since it's pretty clear that no one is willing to pay for the base containerization layer and the only money to be made is in orchestration. But then Docker released their own orchestration strategy and that started the current period we're in where both companies have come off as being very unprofessional and concerned only with their own future success. Between Docker trying to build almost everything into the actual Docker executable (it's a container runner, API server, build tool, process monitor, cloud provisioner and orchestration tool...those last two are only not the case because they got called on the strategy) and CoreOS's pointless pushing of rkt (rkt itself isn't pointless, but the PR to add rkt support to Docker was, as was implementing Docker support in rkt). Both sides have foolishly put their own interests ahead of the container ecosystem. To say that either of the two companies has been the bad actor in all the drama would be biased. They've both come across like spoiled little children trying to get their way. As someone who has been pushing my company (~8000 employees) to consider implementing a containerized deployment strategy, it's been hugely inconvenient to have to concede to people arguing against containerization all the points around how unprofessional the companies in the space have been, both in behavior and coding practices.
  - fredkelly 12y ago
    +1, This has been my interpretation too, I feel like a lot of the rkt PR was subtly aimed at Docker, it was very much "this is why it's better" rather than "this is why it's good".
    - politician 12y ago
      Honestly, as a consumer of both projects, I'm happy that rkt exists because it provides a working demonstration of a solution where container images are orthogonal to other concepts such as orchestration. If it went the other way, our vendors would be swearing up and down that the only way for this container thing to work is if we install their complete solution. I love my Apple MacBook Pro and its soldered components, but I need my data center to be meaningfully upgradable.