>
> Other thoughts?
>

Kubernetes labels and selectors?  You could attach a label to each node
that expresses architecture and a matching selector to the pod.  This would
allow you to do it, assuming of course that there's no API wierdness
between the scheduler and node if they're running on different archs.

Labels and selectors are completely arbitrary, so you could extend that to
match OS (Linux vs Windows), arch, location, etc.  Right now, this is used
for things like DR regions, CPU, etc.

Overall as of K8S 1.2 the implementation is moving to node affinity instead
of the current model, but the idea is the same.

- Matt M

On Fri, Aug 26, 2016 at 11:24 AM, Jon Stanley <jonstan...@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 10:58 AM, Richard Henwood
> <richard.henw...@arm.com> wrote:
>
> > After briefly chatting with Josh at RH summit, the short term goal is
> 'build Atomic Host for AArch64'.
> > Following that, I guess there might be some work to make Atomic Registry
> 'do the right thing'? And orchestration 'do the right thing'?
>
> 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?
>
>

Reply via email to