BMC (Bare-Metal Container) is relased
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>
>> 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
> 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,
More information about the Containers