IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes#4279
These APIs were deprecated in 0.13, now it's time to drop them for 0.14.
They were not used anywhere in Talos, so no changes on Talos side.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Our CI amd64 builders are 3-4 times faster to build Talos than our arm64
builders when building Talos.
Our Dockerfile was restructured a while ago to support cross-compilation
on all platforms but CI was still using amd64/arm64 workers, so arm64
part was done on arm64 builders.
As our CI runs on Talos, `binfmt_misc` is not enabled in the kernel, but
buildkit has built-in QEMU emulation layer which works just fine for
those small pieces which actually need to run arm64 binaries on amd64
(mostly `apk add` in the installer container). Interesting enough,
buildkit QEMU support fails for `ca-certificates` script which runs
after install. At the same time I believe we don't need
`ca-certificates` in the installer, as installer doesn't download
anything from the network, and `ca-certificates` were added a while ago
when installer was actually downloading configuration on its own.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Note: Talos can be still run under `Firecracker`, support for
Firecracker was only removed for `talosctl cluster create`.
Reason:
* code is untested/unmaintained, and probably doesn't work correctly
* firecracker Go SDK pulls lots of dependencies and it blocks CNI Go
module update
Bonus: `talosctl-linux-amd64` shrinks by 2 MiB.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
KubeSpan manager uses list of KubeSpan peers prepared from the discovery
and local KubeSpan identity to set up and update configuration of the
Wireguard interface.
As new peers are getting added or deleted, manager takes care of
updating the Wireguard config.
Manager also keeps track of all peers and their state coming from the
Wireguard link status: whether the connection is up or not, some stats,
last actually used endpoint, etc.
Manager cycles through the available peer endpoints until it finds the
one which works.
Manager exposes peer status as `PeerStatus` resources.
Example:
```
$ talosctl -n 172.20.0.2 get kubespanpeerstatuses
NODE NAMESPACE TYPE ID VERSION LABEL ENDPOINT STATE RX TX
172.20.0.2 kubespan KubeSpanPeerStatus GpO3gs5n09WpoiVANbzRL5nwrkRi+9Q19qoeC8RTkQ4= 30 talos-default-worker-2 172.20.0.6:51820 up 640 1920
172.20.0.2 kubespan KubeSpanPeerStatus j4CRlKByMcTWOBS2ifZcPzcUr3lXdBOc/I4AxGmhXxI= 30 talos-default-worker-1 172.20.0.5:51820 up 672 1888
172.20.0.2 kubespan KubeSpanPeerStatus o5EPScFrD895A5EpVyKU8hFR+vi25D0CJMYsoaXN3Qk= 28 talos-default-master-3 172.20.0.4:51820 up 640 1920
172.20.0.2 kubespan KubeSpanPeerStatus rBp5wyHdxqZkq5CWher2DcPcGgwHrFOwB6fP/ReFRlE= 16 talos-default-master-2 172.20.0.3:51820 up 432 2088
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Signed-off-by: Seán C McCord <ulexus@gmail.com>
Co-authored-by: Seán C McCord <ulexus@gmail.com>
Also downgrade some indirect dependencies that don't have a good reason to be updated.
Closes#4111.
Closes#4112.
Closes#4116.
Closes#4117.
Closes#4121.
Closes#4122.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
This relies on changes in GRUB and other utilities to respect
`SOURCE_DATE_EPOCH`.
Variable `SOURCE_DATE_EPOCH` is set to the timestamp of the last git
commit which makes it deterministic, but still changes for each
release/commit.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
GCP does not consider generated .tar file to be valid.
This reverts commit b2507b41d250b989b9c13ad23e16202cd53a18d2.
Refs #4023.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Use `vtprobuf` optimized Marshal/Unmarshal methods which do not depend
on reflection to reduce memory and CPU usage while using Talos API.
See https://github.com/planetscale/vtprotobuf and
https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/
Co-authored-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Sparse file generation replaced with Go native calls.
Final artifact `.tar` reproducible with new tar flags and using GNU tar
instead of busybox one, but as the image itself is not reproducible,
this only helps a bit.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Resources code extensively uses DeepCopy to prevent in-memory copy of
the resource to be mutated outside of the resource model.
Previous implementation relied on YAML serialization to copy the
machine configuration which was slow, potentially might lead to panics
and it generates pressure on garbage collection.
This implementation uses k8s code generator to generate DeepCopy methods
with some manual helpers when code generator can't handle it.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Plus, convert a few absolute URLs with a version number to relative URLs without versions.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
This PR can be split into two parts:
* controllers
* apid binding into COSI world
Controllers
-----------
* `k8s.EndpointController` provides control plane endpoints on worker
nodes (it isn't required for now on control plane nodes)
* `secrets.RootController` now provides OS top-level secrets (CA cert)
and secret configuration
* `secrets.APIController` generates API secrets (certificates) in a bit
different way for workers and control plane nodes: controlplane nodes
generate directly, while workers reach out to `trustd` on control plane
nodes via `k8s.Endpoint` resource
apid Binding
------------
Resource `secrets.API` provides binding to protobuf by converting
itself back and forth to protobuf spec.
apid no longer receives machine configuration, instead it receives
gRPC-backed socket to access Resource API. apid watches `secrets.API`
resource, fetches certs and CA from it and uses that in its TLS
configuration.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This removes networkd, updates network ready condition, enables all the
controllers which were previously disabled.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
The structure of the controllers is really similar to addresses and
routes:
* `LinkSpec` resource describes desired link state
* `LinkConfig` controller generates `LinkSpecs` based on machine
configuration and kernel cmdline
* `LinkMerge` controller merges multiple configuration sources into a
single `LinkSpec` paying attention to the config layer priority
* `LinkSpec` controller applies the specs to the kernel state
Controller `LinkStatus` (which was implemented before) watches the
kernel state and publishes current link status.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Go cross-compilation is not quite compatible with Go race detector, as C
toolchain is not cross-compilation ready.
Workaround is really simple: for race-enabled builds, don't build
multi-arch installer image (that is installer image which contains both
amd64 and arm64 Talos artifacts), but build installer artifacts only for
the target arch (skipping cross-compilation).
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
The problem is that `pkg/machinery` is a submodule, so regular go walk
over the pattern `./...` doesn't include submodules, so we have to call
explicitly for the submodule.
This also enables go generate for all `./pkg`.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
* without `-print0` / `-0`, paths with spaces were skipped sometimes;
* `--stdin-filename` flag incorrectly consumed the first file.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
This controller queries addresses of all the interfaces in the system
and presents them as resources. The idea is that can be a source for
many decisions - e.g. whether network is ready (physical interface has
scope global address assigned).
This is also good for debugging purposes.
Examples:
```
$ talosctl -n 172.20.0.2 get addresses
NODE NAMESPACE TYPE ID VERSION
172.20.0.2 network AddressStatus cni0/10.244.0.1/24 1
172.20.0.2 network AddressStatus cni0/fe80::9c87:cdff:fe8e:5fdc/64 2
172.20.0.2 network AddressStatus eth0/172.20.0.2/24 1
172.20.0.2 network AddressStatus eth0/fe80::ac1b:9cff:fe19:6b47/64 2
172.20.0.2 network AddressStatus flannel.1/10.244.0.0/32 1
172.20.0.2 network AddressStatus flannel.1/fe80::440b:67ff:fe99:c18f/64 2
172.20.0.2 network AddressStatus lo/127.0.0.1/8 1
172.20.0.2 network AddressStatus lo/::1/128 1
172.20.0.2 network AddressStatus veth178e9b31/fe80::6040:1dff:fe5b:ae1a/64 2
172.20.0.2 network AddressStatus vethb0b96a94/fe80::2473:86ff:fece:1954/64 2
```
```
$ talosctl -n 172.20.0.2 get addresses -o yaml eth0/172.20.0.2/24
node: 172.20.0.2
metadata:
namespace: network
type: AddressStatuses.net.talos.dev
id: eth0/172.20.0.2/24
version: 1
owner: network.AddressStatusController
phase: running
spec:
address: 172.20.0.2/24
local: 172.20.0.2
broadcast: 172.20.0.255
linkIndex: 4
linkName: eth0
family: inet4
scope: global
flags: permanent
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This is the first PR of many which implement new COSI network
configuration. This controller provides low-level status of the network
interfaces (links) not touching on the addresses of the interface.
The information gathered resembles output of `ip link show` command.
Examples:
```
$ talosctl -n 172.20.0.2 get links
NODE NAMESPACE TYPE ID VERSION TYPE KIND HW ADDR OPER STATE LINK STATE
172.20.0.2 net LinkStatus bond0 1 ether bond fe:c4:d6:4c:04:05 down false
172.20.0.2 net LinkStatus cni0 5 ether bridge 22:cc:25:7e:64:19 up true
172.20.0.2 net LinkStatus dummy0 1 ether dummy 0e:f6:f3:ef:53:29 down false
172.20.0.2 net LinkStatus eth0 4 ether ae:1b:9c:19:6b:47 up true
172.20.0.2 net LinkStatus flannel.1 2 ether vxlan be:c5:4f:eb:da:5c unknown true
172.20.0.2 net LinkStatus ip6tnl0 1 tunnel6 ip6tnl 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 down false
172.20.0.2 net LinkStatus lo 4 loopback 00:00:00:00:00:00 unknown true
172.20.0.2 net LinkStatus sit0 1 sit sit 00:00:00:00 down false
172.20.0.2 net LinkStatus teql0 1 void down false
172.20.0.2 net LinkStatus tunl0 1 ipip ipip 00:00:00:00 down false
172.20.0.2 net LinkStatus veth1c1422df 2 ether veth 6a:2d:68:be:8e:8f up true
172.20.0.2 net LinkStatus veth2ce7ce8d 1 ether veth 52:fc:98:82:f7:29 up true
```
```
$ talosctl -n 172.20.0.2 get links eth0 -o yaml
node: 172.20.0.2
metadata:
namespace: net
type: LinkStatuses.net.talos.dev
id: eth0
version: 4
owner: network.LinkStatusController
phase: running
spec:
index: 4
type: ether
linkIndex: 0
flags: UP,BROADCAST,RUNNING,MULTICAST,LOWER_UP
hardwareAddr: ae:1b:9c:19:6b:47
broadcastAddr: ff:ff:ff:ff:ff:ff
mtu: 1500
queueDisc: pfifo_fast
operationalState: up
kind: ""
slaveKind: ""
linkState: true
speedMbit: 4294967295
port: Other
duplex: Unknown
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
