As explained in https://github.com/talos-systems/talos/issues/4880#issuecomment-1022656510,
right now the recommended way to push logs to log collectors is by
running a configuring Filebeat in the local cluster, with a DaemonSet
using the host network, and pointing Talos to push logs to an UDP port
on 127.0.0.1.
I updated both v0.14 and v0.15 docs, as it should be more clear for both
versions.
Signed-off-by: Florian Klink <flokli@flokli.de>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Adds a guide on how to create an installer with a customized kernel with
proprietary drivers.
Signed-off-by: Andrew Rynhard <andrew@rynhard.io>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR moves to give curl commands for the vmware assets instead of
relying on the local paths that I was using. This matches what we're
doing for gcp docs as well.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
Fixes a small typo in the vmware docs
Signed-off-by: Shahar Naveh <shaharnaveh@users.noreply.github.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR updates the vmware docs to introduce a script to help with the
automation, as well as introduce the setup of talos-vmtoolsd and
reworking the format a bit.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
It references legacy `BootstrapStatus` which was removed with the
dropped support for bootkube-based control plane.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4656
As now changes to kubelet configuration can be applied without a reboot,
`talosctl upgrade-k8s` can handle the kubelet upgrades as well.
The gist is simply modifying machine config and waiting for `Node`
version to be updated, rest of the code is required for reliability of
the process.
Also fixed a bug in the API while watching deleted items with
tombstones.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Makes `talosctl` autocomplete the most used dynamic positional parameters like resource definitions, IDs of resource definitions, and also values for arguments like `--nodes` and `--context`.
Signed-off-by: Nico Berlee <nico.berlee@on2it.net>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Update Go modules to the latest versions including talos-systems/
released modules.
In preparation for 0.14-beta release.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The gist is that `kubelet` service code only manages the container
lifecycle, while `kubelet` configuration is managed now in the
controllers and resources.
New resources:
* `secrets.Kubelet` contains Kubelet PKI derived directly from the
machine configuration
* `k8s.KubeletConfig` contains Kubelet non-secret config derived
directly from the machine configuration
* `k8s.NodeIPConfig` contains configuration on picking up Node IP for
the kubelet (from machine configuration)
* `k8s.NodeIP` contains actual Node IPs picked from the node addresses
based on `NodeIPConfig`
* `k8s.KubeletSpec` contains final `kubelet` container configuration,
including merged arguments, KubeletConfig, etc. It is derived from
`KubeletConfig`, `Nodename` and `NodeIP`.
Final controller `KubeletServiceController` writes down configuration
and PKI to disk, and manages restart/start of the `kubelet` service
which is a pure wrapper around container lifecycle.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR solves problems:
1. You want to run controlplane from etcd-backup, and make
changes/investigation and be sure that controlplane
does no change resources.
2. Run controlplane in less memory only for quorum.
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Co-authored-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Still no proper tags for Kubernetes modules (known issue upstream).
Also bump dependencies.
Closes#4605closes#4606
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Related to #4448
The only remaining part is filtering out SideroLink addresses when Talos
looks for a node address.
See also https://github.com/talos-systems/siderolink/pull/2
The way to test it out:
```
$ talosctl cluster create ... --extra-boot-kernel-args
siderolink.api=172.20.0.1:4000
```
(where 172.20.0.1 is the bridge IP)
Run `siderolink-agent` (test implementation):
```
$ sudo _out/siderolink-agent-linux-amd64
```
Now on the host, there should be a `siderolink` Wireguard userspace
tunnel:
```
$ sudo wg
interface: siderolink
public key: 2aq/V91QyrHAoH24RK0bldukgo2rWk+wqE5Eg6TArCM=
private key: (hidden)
listening port: 51821
peer: Tyr6C/F3FFLWtnzqq7Dsm54B40bOPq6++PTiD/zqn2Y=
endpoint: 172.20.0.1:47857
allowed ips: fdae:41e4:649b:9303:b6db:d99c:215e:dfc4/128
latest handshake: 2 minutes, 2 seconds ago
transfer: 3.62 KiB received, 1012 B sent
...
```
Each Talos node will be registered as a peer, tunnel is established.
You can now ping Talos nodes from the host over the tunnel:
```
$ ping fdae:41e4:649b:9303:b6db:d99c:215e:dfc4
PING fdae:41e4:649b:9303:b6db:d99c:215e:dfc4(fdae:41e4:649b:9303:b6db:d99c:215e:dfc4) 56 data bytes
64 bytes from fdae:41e4:649b:9303:b6db:d99c:215e:dfc4: icmp_seq=1 ttl=64 time=0.352 ms
64 bytes from fdae:41e4:649b:9303:b6db:d99c:215e:dfc4: icmp_seq=2 ttl=64 time=0.437 ms
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>