On 08/26/2016 06:13 PM, Josh Berkus wrote:
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 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.
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
