On 08/26/2016 06:13 PM, Josh Berkus wrote:
In general if you think of a datacenter of mixed architecture, you would want a global resource allocator that is architecture aware. Making architecture-specific clusters reduces your flexibility in making resource allocation decisions.On 08/26/2016 11:24 AM, Jon Stanley wrote:Will kube schedule a container on a host that can't run it? i.e. a container with x86 code on a AArch64 host, or vice versa? I think that it needs to DTRT sooner rather than later if the scheduling isn't smart yet. In the meantime I assume that you could run a separate cluster of ARM vs. x86, but that would probably be less than ideal I think. Other thoughts?Oh, I wasn't even thinking of mixed clusters. Figured it wouldn't be possible. Also, while I can imagine having an x86 kube-master and a bunch of ARM kubelets, I'm not sure that there's much of a real cases for mix-and-match kubelets.
In the virt world there has been a tendency to create cluster of a like architecture - where arch is actually a very particular x86 cpu family/generation. This was required for VM migration flexibility and the need to map VM CPU capabilities to the host CPU capabilities. For containers, that CPU mapping need does not exist - so the clusters can be more diverse.
The current state of Kube however is not arch aware afaik - although we could manage that via node labels, it would be clunky. So short term, arch specific clusters. But the goal should be arch-aware orchestrators.
Note: container naming/packaging in general is not architecture aware either. Docker Hub packages are mixed arch, even though Docker recommends using different registries for different archs. The RH container image naming standards that leverages container labels embeds an arch label for all the Fedora/RH/CentOS images. Skopeo can inspect those labels remotely. But there is more work to be done at the community level for arch awareness.
-sg