Use machine-id as the source for the default hostname (e.g. `talos-2gd-76y`) instead of DHCP-assigned IP (e.g. `talos-172-20-0-2`). This way, DHCP IP changes won't impact the hostname. Defaults to true for Talos version >=1.2.
Closessiderolabs/talos#5896.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Instead of writing PKI "once" around the startup time, keep writing PKI
files as the certificates get updated. `etcd` is able to reload
certificates, so we should keep updating them e.g. if the hostname/IPs
change over time.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Clear the kubelet certificates and kubeconfig when hostname changes so that on next start, kubelet goes through the bootstrap process and new certificates are generated and the node is joined to the cluster with the new name.
Fixessiderolabs/talos#5834.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Fixes#4836
Firewall mark is `uint32` attached to the packet in the Linux kernel
(it's not transmitted on the wire). This is a shared value for all
networking software, so multiple components might attempt to set and
match on the firewall mark.
Cilium and Calico CNIs are using firewall marks internally, but they
touch only some bits of the firewall mark.
The way KubeSpan was implemented before this PR, it was doing direct
match on the firewall mark, and setting the whole `uint32`, so it comes
into conflict with any other networking component using firewall marks.
The other problem was that firewall mark 0x51820 (0x51821) was too
"wide" touching random bits of the 32-bit value for no good reason.
So this change contains two fixes:
* make firewall mark exactly a single bit (we use bits `0x20` and `0x40`
now)
* match and mark packets with the mask (don't touch bits outside of the
mask when setting the mark and ignore bits outside of the mask when
matching on the mark).
This was tested successfully with both Cilium CNI (default config +
`ipam.mode=kubernetes`) and Calico CNI (default config).
One thing to note is that for KubeSpan and Talos it's important to make
sure that `podSubnets` in the machine config match CNI setting for
`podCIDRs`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Capture handle should be closed in the same goroutine with packet
reading.
Fix a spurious error which might appear in `talosctl pcap`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This uses the `go-packet` library with native bindings for the packet
capture (without `libpcap`). This is not the most performant way, but it
allows us to avoid CGo.
There is a problem with converting network filter expressions (like
`tcp port 3222`) into BPF instructions, it's only available in C
libraries, but there's a workaround with `tcpdump`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This fixes a problem when platform network configuration might have
already been applied from the cached on disk representation, and in that
base e.g. `bond0` MAC is same as `eth0`, so Talos might mistakenly pick
up `bond0` as a slave to itself instead of `eth0`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The testcase explains it better, but tl;dr is that this allows to do
strategic merge patching e.g. for the Pod Security configuration.
Fixes#5895
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Overwrite cluster's server URL in the kubeconfig file used by kubelet when the cluster control plane endpoint is changed in machineconfig, so that kubelet doesn't lose connectivity to kube-apiserver.
Closessiderolabs/talos#4470.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
This PR allows the ability to generate `secrets.yaml` (`talosctl gen secrets`) using a Kubernetes PKI directory path (e.g. `/etc/kubernetes/pki`) as input. Also introduces the flag `--kubernetes-bootstrap-token` to be able to set a static Kubernetes bootstrap token to the generated `secrets.yaml` file instead of a randomly-generated one. Closessiderolabs/talos#5894.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Refactor things to remove the bootstrap sequence, this should help with
the task of sequencer concurrency changes and immediate API feedback.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR removes pre-v0.10 docs from the drop down. They will remain in
the content so folks can still read them if needed.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
This PR adds support for building talosctl for FreeBSD on
amd64 and arm64 architectures.
It also pulls in the latest go-blockdevice library to ensure the FreeBSD
stubs are there for proper build.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
The download of the talos configuration may fail because the substituted
information like the hostname may not be initialized yet. Therefore we
retry the download and resubstitute the variables each time.
Fixes#3272
Signed-off-by: Philipp Sauter <philipp.sauter@siderolabs.com>
The end result is that every Talos CLI accepts both JSON and strategic
patches to patch machine configuration.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
I would like to rewrite whole cert generation process, but for now a few
fixes:
* client cert doesn't need any SANs
* peer cert should contain only non-localhost SANs
* server cert same as before (localhost + addresses)
See https://etcd.io/docs/v3.5/op-guide/security/ for details.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
There were two issues with using discovery service for join and promote:
* on join, that resulted in joining too fast which triggers race bugs in
etcd cert generation (to be fixed as separate PR)
* on promote, Talos has to connect to non-learner member of the cluster
which is somehow "automatic" with Kuberentes discovery, as it only
lists `kube-apiserver` running which is up only when etcd on the same
node is healthy. etcd client doesn't allow to avoid learner members,
as even getting a member list from a learner doesn't work (to be fixed
as a separate PR)
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Remove code which is no longer needed.
Taken from #5806
Co-authored-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Adds a new command `talosctl gen secrets` to generate a `secrets.yaml` file with Talos and Kubenetes secrets. This file can later be used like `talosctl gen config ... --with-secrets secrets` to generate a config with these pre-generated secrets. Closessiderolabs/talos#5861.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
This PR moves circular package from internal packages to the public pkg folder as the package is stable enough.
Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
This format is much easier to understand when compared to JSON patches,
it allows for more patch validation, and it should provide better user
experience.
This just implements the config merge, but it doesn't yet hook it up to
any CLI utility, so no user-facing docs.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The example configuration generated by talosctl contains
```yaml
extraKernelArgs:
- talos.platform=metal
```
in the install section, which, if uncommented, causes the installer to append the
`talos.platform` option twice. Thus, if the platform is set/changed here, it will
not be respected. This change allows the existing value to be overridden.
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Instead of dropping whole peer try to find non-overlapping set of IPs to
route to.
Fixes#5828
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
this commits adds dracut style vlan support to allow
installing talos in networks where ports is not tagged
with a default vlan.
Signed-off-by: Eirik Askheim <eirik@x13.no>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
There should be no functional change with this PR.
The primary driver is supporting strategic merge configuration patches.
For such type of patches machine config should be loaded from incomplete
fragments, so it becomes critically important to distinguish between a
field having zero value vs. field being set in YAML.
E.g. with following struct:
```go
struct { AEnabled *bool `yaml:"a"` }
```
It's possible to distinguish between:
```yaml
a: false
```
and no metion of `a` in YAML.
Merging process trewats zero values as "not set" (skips them when
merging), so it's important to allow overriding value to explicit
`false`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
