3 ms·
I thought it might be worth highlighting the final section, where some consequences of this decision have been highlighted: 'There will be some unfortunate
by zwischenzug 11y ago
I thought it might be worth highlighting the final section, where some consequences of this decision have been highlighted:
'There will be some unfortunate side-effects of this. Most of them are relatively minor (for example, docker inspect will not show an IP address), but some are significant. In particular, containers started by docker run might not be able to communicate with containers started by Kubernetes, and network integrators will have to provide CNI drivers if they want to fully integrate with Kubernetes.'
It will be interesting to see what would happen if a number of significant and interested enterprise parties unite to embrace runC or similar in earnest, relegating Docker's solution set to just another implementation. RedHat + Google + (say) Microsoft and it's game over.
- justincormack 11y agoRunc is part of the open containers spec set up by Docker and CoreOS. So it is Docker's solution as well as the community's. They recently open sourced containerd which is based on runc so they are clearly embracing it.