In this section we will discuss the various components of which Talos is comprised.
|apid||When interacting with Talos, the gRPC API endpoint you’re interact with directly is provided by |
|containerd||An industry-standard container runtime with an emphasis on simplicity, robustness and portability. To learn more see the containerd website.|
|machined||Talos replacement for the traditional Linux init-process. Specially designed to run Kubernetes and does not allow starting arbitrary user services.|
|networkd||Handles all of the host level network configuration. Configuration is defined under the |
|timed||Handles the host time synchronization by acting as a NTP-client.|
|kernel||The Linux kernel included with Talos is configured according to the recommendations outlined in the Kernel Self Protection Project.|
|routerd||Responsible for routing an incoming API request from |
|trustd||To run and operate a Kubernetes cluster a certain level of trust is required. Based on the concept of a ‘Root of Trust’, |
|udevd||Implementation of |
When interacting with Talos, the gRPC api endpoint you will interact with directly is
Apid acts as the gateway for all component interactions.
Apid provides a mechanism to route requests to the appropriate destination when running on a control plane node.
We’ll use some examples below to illustrate what
apid is doing.
When a user wants to interact with a Talos component via
talosctl, there are two flags that control the interaction with
-e | --endpoints flag is used to denote which Talos node ( via
apid ) should handle the connection.
Typically this is a public facing server.
-n | --nodes flag is used to denote which Talos node(s) should respond to the request.
--nodes is not specified, the first endpoint will be used.
Note: Typically there will be an
endpointalready defined in the Talos config file. Optionally,
nodescan be included here as well.
For example, if a user wants to interact with
machined, a command like
talosctl -e cluster.talos.dev memory may be used.
$ talosctl -e cluster.talos.dev memory NODE TOTAL USED FREE SHARED BUFFERS CACHE AVAILABLE cluster.talos.dev 7938 1768 2390 145 53 3724 6571
In this case,
talosctl is interacting with
apid running on
cluster.talos.dev and forwarding the request to the
If we wanted to extend our example to retrieve
memory from another node in our cluster, we could use the command
talosctl -e cluster.talos.dev -n node02 memory.
$ talosctl -e cluster.talos.dev -n node02 memory NODE TOTAL USED FREE SHARED BUFFERS CACHE AVAILABLE node02 7938 1768 2390 145 53 3724 6571
apid instance on
cluster.talos.dev receives the request and forwards it to
apid running on
node02 which forwards the request to the
We can further extend our example to retrieve
memory for all nodes in our cluster by appending additional
-n node flags or using a comma separated list of nodes (
-n node01,node02,node03 ):
$ talosctl -e cluster.talos.dev -n node01 -n node02 -n node03 memory NODE TOTAL USED FREE SHARED BUFFERS CACHE AVAILABLE node01 7938 871 4071 137 49 2945 7042 node02 257844 14408 190796 18138 49 52589 227492 node03 257844 1830 255186 125 49 777 254556
apid instance on
cluster.talos.dev receives the request and forwards is to
node03 which then forwards the request to their local
Containerd provides the container runtime to launch workloads on Talos as well as Kubernetes.
Talos services are namespaced under the
system namespace in containerd whereas the Kubernetes services are namespaced under the
A common theme throughout the design of Talos is minimalism.
We believe strongly in the UNIX philosophy that each program should do one job well.
init included in Talos is one example of this, and we are calling it “
We wanted to create a focused
init that had one job - run Kubernetes.
To that extent,
machined is relatively static in that it does not allow for arbitrary user defined services.
Only the services necessary to run Kubernetes and manage the node are available.
Networkd handles all of the host level network configuration.
Configuration is defined under the
By default, we attempt to issue a DHCP request for every interface on the server. This can be overridden by supplying one of the following kernel arguments:
talos.network.interface.ignore- specify a list of interfaces to skip discovery on
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>as documented in the kernel here
Timed handles the host time synchronization.
The Linux kernel included with Talos is configured according to the recommendations outlined in the Kernel Self Protection Project (KSSP).
Security is one of the highest priorities within Talos. To run a Kubernetes cluster a certain level of trust is required to operate a cluster. For example, orchestrating the bootstrap of a highly available control plane requires the distribution of sensitive PKI data.
To that end, we created
Based on the concept of a Root of Trust,
trustd is a simple daemon responsible for establishing trust within the system.
Once trust is established, various methods become available to the trustee.
It can, for example, accept a write request from another node to place a file on disk.
Additional methods and capability will be added to the
trustd component in support of new functionality in the rest of the Talos environment.
Udevd handles the kernel device notifications and sets up the necessary links in