Discover how Talos Linux uses the concepts on Controllers and Resources.
namespace
, type
, id
).
Namespaces provide a way to avoid conflicts on duplicate resource IDs.
At the moment of this writing, all resources are local to the node and stored in memory.
So on every reboot resource state is rebuilt from scratch (the only exception is MachineConfig
resource which reflects current machine config).
etcd
keys, etc.
A controller has a single output: a set of resources of fixed type in a fixed namespace.
Only one controller can manage resource type in the namespace, so conflicts are avoided.
talosctl
provides read-only access to the resource API which includes getting specific resource,
listing resources and watching for changes.
Talos stores resources describing resource types and namespaces in meta
namespace:
--namespace
) can be omitted, as ResourceDefinition
contains default
namespace which is used if no namespace is given:
talosctl get
supports following output modes:
table
(default) prints resource list as a tableyaml
prints pretty formatted resources with details, including full metadata spec.
This format carries most details from the backend resource (e.g. comments in MachineConfig
resource)json
prints same information as yaml
, some additional details (e.g. comments) might be lost.
This format is useful for automated processing with tools like jq
.--watch
is appended to the talosctl get
command, the command switches to watch mode.
If list of resources was requested, talosctl
prints initial contents of the list and then appends resource information for every change:
*
specifies event type:
+
is created-
is deleted
is updatedevent
is added to the resource representation to describe the event type.
kube-apiserver
:
graphviz
format which can be rendered to PNG with command: