This is the multi-page printable view of this section. Click here to print.
Resource Configuration
- 1: Environments
- 2: Servers
- 3: Server Classes
- 4: Metadata
1 - Environments
Environments are a custom resource provided by the Metal Controller Manager. An environment is a codified description of what should be returned by the PXE server when a physical server attempts to PXE boot.
Especially important in the environment types are the kernel args. From here, one can tweak the IP to the metadata server as well as various other kernel options that Talos and/or the Linux kernel supports.
Environments can be supplied to a given server either at the Server or the ServerClass level. The hierarchy from most to least respected is:
.spec.environmentRef
provided atServer
level.spec.environmentRef
provided atServerClass
level"default"
Environment
created by administrator
A sample environment definition looks like this:
apiVersion: metal.sidero.dev/v1alpha1
kind: Environment
metadata:
name: default
spec:
kernel:
url: "https://github.com/talos-systems/talos/releases/download/v0.8.1/vmlinuz-amd64"
sha512: ""
args:
- init_on_alloc=1
- init_on_free=1
- slab_nomerge
- pti=on
- consoleblank=0
- random.trust_cpu=on
- ima_template=ima-ng
- ima_appraise=fix
- ima_hash=sha512
- console=tty0
- console=ttyS1,115200n8
- earlyprintk=ttyS1,115200n8
- panic=0
- printk.devkmsg=on
- talos.platform=metal
- talos.config=http://$PUBLIC_IP:9091/configdata?uuid=
initrd:
url: "https://github.com/talos-systems/talos/releases/download/v0.8.1/initramfs-amd64.xz"
sha512: ""
Example of overriding "default"
Environment
at the Server
level:
apiVersion: metal.sidero.dev/v1alpha1
kind: Server
...
spec:
environmentRef:
namespace: default
name: boot
...
Example of overriding "default"
Environment
at the ServerClass
level:
apiVersion: metal.sidero.dev/v1alpha1
kind: ServerClass
...
spec:
environmentRef:
namespace: default
name: boot
...
2 - Servers
Servers are the basic resource of bare metal in the Metal Controller Manager. These are created by PXE booting the servers and allowing them to send a registration request to the management plane.
An example server may look like the following:
apiVersion: metal.sidero.dev/v1alpha1
kind: Server
metadata:
name: 00000000-0000-0000-0000-d05099d333e0
spec:
accepted: false
configPatches:
- op: replace
path: /cluster/network/cni
value:
name: custom
urls:
- http://192.168.1.199/assets/cilium.yaml
cpu:
manufacturer: Intel(R) Corporation
version: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
system:
family: Unknown
manufacturer: Unknown
productName: Unknown
serialNumber: Unknown
skuNumber: Unknown
version: Unknown
Installation Disk
A an installation disk is required by Talos on bare metal.
This can be specified in a configPatch
:
apiVersion: metal.sidero.dev/v1alpha1
kind: Server
...
spec:
accepted: false
configPatches:
- op: replace
path: /machine/install/disk
value: /dev/sda
The install disk patch can also be set on the ServerClass
:
apiVersion: metal.sidero.dev/v1alpha1
kind: ServerClass
...
spec:
configPatches:
- op: replace
path: /machine/install/disk
value: /dev/sda
Server Acceptance
In order for a server to be eligible for consideration, it must be accepted
.
This is an important separation point which all Server
s must pass.
Before a Server
is accepted, no write action will be performed against it.
Thus, it is safe for a computer to be added to a network on which Sidero is operating.
Sidero will never write to or wipe any disk on a computer which is not marked as accepted
.
This can be tedious for systems in which all attached computers should be considered to be under the control of Sidero.
Thus, you may also choose to automatically accept any machine into Sidero on its discovery.
Please keep in mind that this means that any newly-connected computer WILL BE WIPED automatically.
You can enable auto-acceptance by pasing the --auto-accept-servers=true
flag to sidero-controller-manager
.
Once accepted, a server will be reset (all disks wiped) and then made available to Sidero.
You should never change an accepted Server
to be not accepted while it is in use.
Because servers which are not accepted will not be modified, if a server which
was accepted is changed to not accepted, the disk will not be wiped upon
its exit.
IPMI
Sidero can use IPMI information to control Server
power state, reboot servers and set boot order.
IPMI connection information can be set in the Server
spec after initial registration:
apiVersion: metal.sidero.dev/v1alpha1
kind: Server
...
spec:
bmc:
endpoint: 10.0.0.25
user: admin
pass: password
If IPMI information is set, server boot order might be set to boot from disk, then network, Sidero will switch servers to PXE boot once that is required.
Without IPMI info, Sidero can still register servers, wipe them and provision clusters, but Sidero won’t be able to reboot servers once they are removed from the cluster. If IPMI info is not set, servers should be configured to boot first from network, then from disk.
3 - Server Classes
Server classes are a way to group distinct server resources.
The “qualifiers” key allows the administrator to specify criteria upon which to group these servers.
There are currently three keys: cpu
, systemInformation
, and labelSelectors
.
Each of these keys accepts a list of entries.
The top level keys are a “logical AND”, while the lists under each key are a “logical OR”.
Qualifiers that are not specified are not evaluated.
An example:
apiVersion: metal.sidero.dev/v1alpha1
kind: ServerClass
metadata:
name: default
spec:
qualifiers:
cpu:
- manufacturer: Intel(R) Corporation
version: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
- manufacturer: Advanced Micro Devices, Inc.
version: AMD Ryzen 7 2700X Eight-Core Processor
labelSelectors:
- "my-server-label": "true"
Servers would only be added to the above class if they had EITHER CPU info, AND the label associated with the server resource.
4 - Metadata
The Metadata server manages the Machine metadata. In terms of Talos (the OS on which the Kubernetes cluster is formed), this is the “machine config”, which is used during the automated installation.
Talos Machine Configuration
The configuration of each machine is constructed from a number of sources:
- The Talos bootstrap provider.
- The
Cluster
of which theMachine
is a member. - The
ServerClass
which was used to select theServer
into theCluster
. - Any
Server
-specific patches.
The base template is constructed from the Talos bootstrap provider, using data from the associated Cluster
manifest.
Then, any configuration patches are applied from the ServerClass
and Server
.
Only configuration patches are allowed in the ServerClass
and Server
resources.
These patches take the form of an RFC 6902 JSON (or YAML) patch.
An example of the use of this patch method can be found in Patching Guide.
Also note that while a Server
can be a member of any number of ServerClass
es, only the ServerClass
which is used to select the Server
into the Cluster
will be used for the generation of the configuration of the Machine
.
In this way, Servers
may have a number of different configuration patch sets based on which Cluster
they are in at any given time.