Cloud-Kernel: Wann und wozu?

[Bachsau]

Hallo! Ich habe gesehen, dass es in den Paket-Archiven einen "Cloud-Kernel" gibt, aber so gut wie keine Informationen darüber gefunden, in welchen Situationen man diesen einsetzen sollte, und was ihn vom normalen Kernel unterscheidet. Klar, es heißt, der sei für "Cloud"-Instanzen, wie beispielsweise bei Amazon oder Azure. Aber heißt das, dass er auf allen vServern die bessere Wahl ist, wie z.B. bei meinem KVM-basierten Root-Server von Netcup, oder ist das eine Minimal-Konfiguration, die für hohe Leistung auf ganz bestimmten Plattformen ausgelegt ist?

[TRex]

Du meinst linux-image-cloud-amd64 - du könntest die boot-config extrahieren (siehe Dateiliste: https://packages.debian.org/bullseye/am ... 4/filelist) und mit der eines "normalen" Kernels vergleichen.

Alternativ die Suchmaschine seiner Wahl bemühen und das hier finden:

https://www.collabora.com/news-and-blog ... loud-team/

A cloud-specific Linux package (linux-image-cloud) allowed us to disable features that are not relevant in cloud environments and enable what is really important. For example, features related to bluetooth and sound support are disabled and some drivers needed by the cloud providers are enabled.

[Bachsau]

Alternativ die Suchmaschine seiner Wahl bemühen und das hier finden:

https://www.collabora.com/news-and-blog ... loud-team/

Ja, das ist ein hübscher Fortschritts-Bericht des "Cloud-Teams", aber eben auch mehr oder weniger alles, was ich bislang dazu finden konnte. Debian dokumentiert sonst sehr gut, aber eine klare Beschreibung von Funktion, Einsatzzweck und Zielsetzung sieht anders aus.

Einzig das

As of now, Azure, AWS and GCE are supported but it is easily extendable.

deutet darauf hin, dass der Kernel eben nicht universell einsetzbar ist, sondern ganz konkret auf bestimmte Anbieter abgestimmt, und eventuell auch in den Einsatzmöglichkeiten beschränkt ist…

For some time, the team has been using FAI (Fully Automatic Installation) to build cloud images instead of bootstrap-vz.

Kurzlebige, automatisch aktivierte Instanzen? Darauf deutet zumindest dieser Artikel hin. Dort wird allerdings nicht explizit auf den Kernel Bezug genommen, sondern auf die oben erwähnten Images. Das könnte also heißen, dass der Cloud-Kernel nur oder vor allem für den Einsatz mit eben diesen Images vorgesehen ist. Aber ganz klar ist das nicht.

Mit den ganzen Konfigurationsmöglichkeiten des Kernels kenne ich mich nicht aus, aber wenn ich mir das hier so ansehe, sieht es mir mehr wie die Konfiguration für ein eingebettetes System aus, und nicht wie etwas, das für den Betrieb einer langlebigen, interaktiven VM vorgesehen ist.

[bluestar]

Mit den ganzen Konfigurationsmöglichkeiten des Kernels kenne ich mich nicht aus, aber wenn ich mir das hier so ansehe, sieht es mir mehr wie die Konfiguration für ein eingebettetes System aus, und nicht wie etwas, das für den Betrieb einer langlebigen, interaktiven VM vorgesehen ist.

Der Kernel ist schlicht und ergreifend „optimiert“ um letztlich weniger anfällig für Sicherheitslücken und daraus resultierende Reboot-Notwendigkeiten zu sein. Der Kernel ist somit extra für langlebige Systeme gemacht.

[zobel]

Mit den ganzen Konfigurationsmöglichkeiten des Kernels kenne ich mich nicht aus, aber wenn ich mir das hier so ansehe, sieht es mir mehr wie die Konfiguration für ein eingebettetes System aus, und nicht wie etwas, das für den Betrieb einer langlebigen, interaktiven VM vorgesehen ist.

Der Kernel ist schlicht und ergreifend „optimiert“ um letztlich weniger anfällig für Sicherheitslücken und daraus resultierende Reboot-Notwendigkeiten zu sein. Der Kernel ist somit extra für langlebige Systeme gemacht.

Und das Entfernen von nicht benötigten Teilen aus dem Kernel beschleunigt die Boot-Zeit eines Debian Images in der Cloud. Und zwar erheblich. Und gerade wenn man zB für CI/CD Pipelines dauernd neue Debian Images bei div. Cloud Providern neu startet ist die Boot-Zeit ein erhebliches Kriterium.