BMC (Bare-Metal Container) is relased

Kuniyasu Suzaki k.suzaki at aist.go.jp
Wed Dec 21 01:34:20 UTC 2016


From: Jeremy Eder <jeder at redhat.com>
Subject: Re: BMC (Bare-Metal Container) is relased
Date: Tue, 20 Dec 2016 10:04:12 -0500

>  Eric W. Biederman <ebiederm at xmission.com>
> wrote:
> 
>> In the past I have always seen this sort of problem handled as a
>> property to the scheduler, and a declaration that a certain job needs
>> certain properties.
> 
> Indeed, we have discussed this as a property of the scheduler in kubernetes.
> 
> - Nodes are given attributes (i.e. THP=never)
> - Users declare their requirements (i.e. THP=never)
> - User submits job, scheduler does matching to node
> - Node executes job
> 
> This allows for shared control plane, serving disparate workloads on hybrid
> infra.
> 
> ​THP=never is just another node attribute, as could be things like
> - Does a DPDK-capable NIC or GPU or FPGA exist, and is unused
> - What kernel version is it running
> - Is the node tuned correctly
> 
> ...myriad other possibilities, in a rapidly evolving space.

It sounds interesting. I did not know that kubernetes has such a function.
Is there HP or paper to described the detail? I want to compare the function with our BMC (Bare-Metal Container).

I guess the function requires nodes which turn on/off THP.
On the other hand, BMC boots a node with the Linux kernel which is suitable for an application.
BMC needs the overhead to boot a node and allows to select a node with consideration of machine architecture, power usage, etc.

--------
Kuniyasu Suzaki, National Institute of Advanced Industrial Science and Technology,
http://staff.aist.go.jp/k.suzaki



More information about the Containers mailing list