Fixes#4947
It turns out there's something related to boot process in BIOS mode
which leads to initramfs corruption on later `kexec`.
Booting via GRUB is always successful.
Problem with kexec was confirmed with:
* direct boot via QEMU
* QEMU boot via iPXE (bundled with QEMU)
The root cause is not known, but the only visible difference is the
placement of RAMDISK with UEFI and BIOS boots:
```
[ 0.005508] RAMDISK: [mem 0x312dd000-0x34965fff]
```
or:
```
[ 0.003821] RAMDISK: [mem 0x711aa000-0x747a7fff]
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#5003
This implements a way to configure API server admission plugins via
Talos machine configuration.
If Pod Security admission is enabled, default cluster-wide policy is
generated which enforces baseline policy.
Policy can be overridden per-namespace.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Second way to collect talos and pod logs in the cluster.
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4694
User services run alongside with Talos system services.
Every user service container root filesystem should be already present
in the Talos root filesystem.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Updated wording, added some cross references, and generally updated the
controlplane troubleshooting document.
Signed-off-by: Seán C McCord <ulexus@gmail.com>
Pin talos default k8s version to `talosctl gen config`
Signed-off-by: Charlie Haley <charlie.haley@hotmail.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4727
On worker nodes, static pods are injected, but status can't be monitored
by Talos. On control plane nodes full status is available via
`StaticPodStatus`.
Pod definition is left as `Unstructured` in the machine configuration,
and no specific validation is performed to avoid pulling in Kubernetes
libraries into Talos machinery package.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
They were supported internally, but never properly exposed in the
machine configuration.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Cordon & drain a node when the Shutdown message is received.
Also adds a '--force' option to the shutdown command in case the control
plane is unresponsive.
Signed-off-by: Tim Jones <timniverse@gmail.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Include filename content if value begins with @ (see curl for example).
Add multiple config-path option on cmdline to apply them in order.
ex:
```
talosctl-linux-amd64 gen config talos1 https://127.0.0.1:6443 --config-patch-control-plan @cidrs.json --config-patch-worker @sysctls-workders.json --config-path @cluster-name.json
```
Load JSON patch from YAML.
This applies to all commands handling config patches.
Closes: https://github.com/talos-systems/talos/issues/4764
Signed-off-by: Sébastien Bernard <sbernard@nerim.net>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
docs: add documentation for creating cluster on Hyper-V
Signed-off-by: nebulait <40148908+nebula-it@users.noreply.github.com>
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
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>
Simple way to run Talos on Oracle Cloud:
* create network and disable security list
* create tcp load balancer for kube-apiserver and talos-api
* launch the contolplane
* add the workers
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4815
This implements the following steps:
* machine configuration updates
* pulling and unpacking system extension images
* validating, listing system extensions
* re-packing system extensions
* preserving installed extensions in `/etc/extensions.yaml`
Once extension is enabled, raw information can be queried with:
```
$ talosctl -n 172.20.0.2 cat /etc/extensions.yaml
layers:
- image: 000.ghcr.io-smira-gvisor-c927b54-dirty.sqsh
metadata:
name: gvisor
version: 20220117.0-v1.0.0
author: Andrew Rynhard
description: |
This system extension provides gVisor using containerd's runtime handler.
compatibility:
talos:
version: '> v0.15.0-alpha.1'
```
This was tested with the `gvisor` system extension.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Containerd doesn't support merging plugin configuration from multiple
sources, and Talos has several pieces which configure CRI plugin:
(see https://github.com/containerd/containerd/issues/5837)
* base config
* registry mirror config
* system extensions
* ...
So we implement our own simple way of merging config parts (by simply
concatenating text files) to build a final `cri.toml`.
At the same time containerd migrated to a new format to specify registry
mirror configuration, while old way (via CRI config) is going to be
removed in 1.7.0. New way also allows to apply most of registry
configuration (except for auth) on the fly.
Also, containerd was updated to 1.6.0-rc.0 and runc to 1.1.0.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Drop the rewrite rule which seems to be causing issues for
`ingress-nginx` when Kubernetes IPv4-only cluster runs in the
IPv6-enabled environment.
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>
