mirror of
https://github.com/lingble/talos.git
synced 2026-01-07 23:21:44 +00:00
refactor: merge osd into machined
This merges `osd` API into `machined`. API was copied from `osd` into `machined`, and `osd` API was deprecated. For backwards compatibility, `machined` still implements `osd` API, so older Talos API clients can still talk to the node without changes. Docs were updated. No functional changes. Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This commit is contained in:
Andrey Smirnov
committed by
talos-bot
talos-bot
parent
19343e5f1a
commit
cbb7ca8390
@@ -166,10 +166,6 @@
|
||||
"title": "timed",
|
||||
"path": "v0.6/en/components/timed"
|
||||
},
|
||||
{
|
||||
"title": "osd",
|
||||
"path": "v0.6/en/components/osd"
|
||||
},
|
||||
{
|
||||
"title": "trustd",
|
||||
"path": "v0.6/en/components/trustd"
|
||||
|
||||
@@ -17,7 +17,7 @@ If `--nodes` is not specified, the first endpoint will be used.
|
||||
> Note: Typically there will be an `endpoint` already defined in the Talos config file.
|
||||
> Optionally, `nodes` can be included here as well.
|
||||
|
||||
For example, if a user wants to interact with `osd`, a command like `talosctl -e cluster.talos.dev memory` may be used.
|
||||
For example, if a user wants to interact with `machined`, a command like `talosctl -e cluster.talos.dev memory` may be used.
|
||||
|
||||
```bash
|
||||
$ talosctl -e cluster.talos.dev memory
|
||||
@@ -25,7 +25,7 @@ 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 `osd` api.
|
||||
In this case, `talosctl` is interacting with `apid` running on `cluster.talos.dev` and forwarding the request to the `machined` api.
|
||||
|
||||
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`.
|
||||
|
||||
@@ -35,7 +35,7 @@ NODE TOTAL USED FREE SHARED BUFFERS CACHE AVAILABLE
|
||||
node02 7938 1768 2390 145 53 3724 6571
|
||||
```
|
||||
|
||||
The `apid` instance on `cluster.talos.dev` receives the request and forwards it to `apid` running on `node02` which forwards the request to the `osd` api.
|
||||
The `apid` instance on `cluster.talos.dev` receives the request and forwards it to `apid` running on `node02` which forwards the request to the `machined` api.
|
||||
|
||||
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` ):
|
||||
|
||||
@@ -47,4 +47,4 @@ node02 257844 14408 190796 18138 49 52589 227492
|
||||
node03 257844 1830 255186 125 49 777 254556
|
||||
```
|
||||
|
||||
The `apid` instance on `cluster.talos.dev` receives the request and forwards is to `node01`, `node02`, and `node03` which then forwards the request to their local `osd` api.
|
||||
The `apid` instance on `cluster.talos.dev` receives the request and forwards is to `node01`, `node02`, and `node03` which then forwards the request to their local `machined` api.
|
||||
|
||||
@@ -16,6 +16,5 @@ This includes:
|
||||
- [kubelet](https://kubernetes.io/docs/concepts/overview/components/)
|
||||
- [networkd](networkd)
|
||||
- [timed](timed)
|
||||
- [osd](osd)
|
||||
- [trustd](trustd)
|
||||
- [udevd](udevd)
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: 'talosctl'
|
||||
---
|
||||
|
||||
`talosctl` CLI is the client to the [osd](/components/osd) service running on every node.
|
||||
`talosctl` CLI is the client to the [apid](/components/apid) service running on every node.
|
||||
`talosctl` should provide enough functionality to be a replacement for typical interactive shell operations.
|
||||
With it you can do things like:
|
||||
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: 'osd'
|
||||
---
|
||||
|
||||
Talos is unique in that it has no concept of host-level access.
|
||||
There is no ssh daemon.
|
||||
There is no interactive console session.
|
||||
There are no shells installed.
|
||||
Only what is required to run Kubernetes.
|
||||
Furthermore, there is no way to run any custom processes on the host level.
|
||||
|
||||
To make this work, we needed an out-of-band tool for managing the nodes.
|
||||
In an ideal world, the system would be self-healing and we would never have to touch it.
|
||||
But, in the real world, this does not happen.
|
||||
We still need a way to handle operational scenarios that may arise.
|
||||
|
||||
The `osd` daemon provides a way to do just that.
|
||||
Based on the Principle of Least Privilege, `osd` provides operational value for cluster administrators by providing an API for node management.
|
||||
|
||||
Interactions with `osd` are handled via [talosctl](/docs/components/talosctl) which communicates via gRPC.
|
||||
@@ -13,7 +13,6 @@ In this section we will discuss the various components of which Talos is compris
|
||||
| [machined](machined) | Talos replacement for the traditional Linux init-process. Specially designed to run Kubernetes and does not allow starting arbitrary user services. |
|
||||
| [networkd](networkd) | Handles all of the host level network configuration. Configuration is defined under the `networking` key |
|
||||
| [timed](timed) | Handles the host time synchronization by acting as a NTP-client. |
|
||||
| [osd](osd) | Because there's no concept of host-level access in Talos, this is the out-of-band management tool for the nodes. It provides access to node information and offers operational functions. |
|
||||
| [kernel](kernel) | The Linux kernel included with Talos is configured according to the recommendations outlined in the [Kernel Self Protection Project](http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project). |
|
||||
| [routerd](routerd) | Responsible for routing an incoming API request from `apid` to the appropriate backend (e.g. `osd`, `machined` and `timed`). |
|
||||
| [trustd](trustd) | To run and operate a Kubernetes cluster a certain level of trust is required. Based on the concept of a 'Root of Trust', `trustd` is a simple daemon responsible for establishing trust within the system. |
|
||||
|
||||
@@ -5,7 +5,7 @@ title: 'Configuration Overview'
|
||||
In this section, we will step through the configuration of a Talos based Kubernetes cluster.
|
||||
There are three major components we will configure:
|
||||
|
||||
- `osd` and `talosctl`
|
||||
- `apid` and `talosctl`
|
||||
- the master nodes
|
||||
- the worker nodes
|
||||
|
||||
|
||||
@@ -80,11 +80,11 @@ az network vnet create \
|
||||
# Create network security group
|
||||
az network nsg create -g $GROUP -n talos-sg
|
||||
|
||||
# Client -> OSD
|
||||
# Client -> apid
|
||||
az network nsg rule create \
|
||||
-g $GROUP \
|
||||
--nsg-name talos-sg \
|
||||
-n osd \
|
||||
-n apid \
|
||||
--priority 1001 \
|
||||
--destination-port-ranges 50000 \
|
||||
--direction inbound
|
||||
|
||||
@@ -104,7 +104,6 @@ NODE SERVICE STATE HEALTH LAST CHANGE LAST EVENT
|
||||
192.168.2.44 machined-api Running ? 192h7m48s ago Service started as goroutine
|
||||
192.168.2.44 networkd Running OK 192h7m11s ago Health check successful
|
||||
192.168.2.44 ntpd Running ? 192h7m10s ago Started task ntpd (PID 4144) for container ntpd
|
||||
192.168.2.44 osd Running OK 192h7m45s ago Health check successful
|
||||
192.168.2.44 routerd Running OK 192h7m46s ago Started task routerd (PID 3907) for container routerd
|
||||
192.168.2.44 system-containerd Running OK 192h7m48s ago Health check successful
|
||||
192.168.2.44 trustd Running OK 192h7m45s ago Health check successful
|
||||
@@ -125,7 +124,6 @@ NODE NAMESPACE ID IMAGE PID STATUS
|
||||
192.168.2.44 system apid talos/apid 4021 RUNNING
|
||||
192.168.2.44 system networkd talos/networkd 3893 RUNNING
|
||||
192.168.2.44 system ntpd talos/ntpd 4144 RUNNING
|
||||
192.168.2.44 system osd talos/osd 4086 RUNNING
|
||||
192.168.2.44 system routerd talos/routerd 3907 RUNNING
|
||||
192.168.2.44 system trustd talos/trustd 4010 RUNNING
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user