Parcours Sylva : la pile cloud télécom open source

Systemd, processus, namespaces/cgroups, SELinux, diagnostic système. Base de tout le reste.

Images, registries, runtime, différences Docker/Podman/CRI-O.

Control plane, etcd, kubelet, scheduler, API server, contrôleurs.

Charts, values, hooks, gestion de versions. Les CNF sont livrés en charts.

État désiré dans Git, synchronisation, gestion multi-environnements.

Projet de Linux Foundation Europe annoncé en novembre 2022 avec Deutsche Telekom, Ericsson, Nokia, Orange, Telecom Italia, Telefónica et Vodafone : un cadre logiciel cloud-native commun pour les réseaux d'opérateurs, une implémentation de référence (sylva-core, licence Apache 2.0) et un programme de validation des fonctions réseau.

Un cluster de gestion, déployé depuis une VM de bootstrap, crée et gère de façon déclarative des clusters de charge qui hébergent les CNF. Chaque cluster est composé d'« units », des composants open source obligatoires ou optionnels (Rancher, Keycloak, Harbor, Vault, Flux, Thanos…). Deux rôles : l'opérateur d'infrastructure et l'opérateur des charges.

Gérer des clusters Kubernetes avec Kubernetes : des ressources déclaratives décrivent les clusters, des fournisseurs d'infrastructure et d'amorçage les réalisent. Sylva s'en sert pour tous ses clusters, y compris le cluster de gestion.

Un chart Helm maison transforme chaque unit en ressources Flux (GitRepository, HelmRepository, OCIRepository, Kustomization, HelmRelease) selon le contexte (bootstrap, gestion, charge) et les fournisseurs choisis. On active, désactive et règle les units dans values.yaml ; Kustomize adapte les manifestes sans les modifier.

La VM de bootstrap (Ubuntu 22.04 LTS recommandée, 4 vCPU, 8 Go de mémoire et 16 conseillés, 40 Go de disque) doit joindre l'API de l'infrastructure ou les BMC (IPMI, Redfish), Internet et les réseaux utiles ; les noms d'hôtes *.sylva doivent être résolus par le DNS.

Les valeurs d'exemple de sylva-core combinent trois distributions (kubeadm, RKE2, Canonical Kubernetes) et des fournisseurs Cluster API : OpenStack (CAPO), bare metal avec Metal3 (CAPM3), vSphere (CAPV), OpenNebula (CAPONE) et Docker (CAPD) pour les essais. On part du dossier qui correspond à sa cible.

Provisionner des serveurs physiques par leur BMC (IPMI ou Redfish) avec Metal3 et le fournisseur Cluster API CAPM3. Sylva déploie aussi des clusters OKD sur bare metal par ce fournisseur.

Une partie des composants de sylva-core vient des dépôts SUSE et Rancher : RKE2 (fournisseur Cluster API), Rancher et Rancher Turtles, Longhorn, NeuVector, Metal3 maintenu par SUSE, opérateur SR-IOV et KubeVirt de SUSE Edge. Le dépôt susetelcocloud aligne Sylva 1.7 sur SUSE Edge 3.6 : SUSE Linux Micro 6.2 configuré par Ignition, images construites avec KIWI et Edge Image Builder, charts et images de registry.suse.com.

bootstrap.sh crée un cluster temporaire qui déploie le cluster de gestion ; apply.sh installe ou met à jour ses units. On valide ensuite : nœuds Ready, pods de Rancher, Flux, Harbor, Vault et Keycloak en marche, points d'entrée exposés.

Métriques, règles d'alerte, rétention longue, alerting basé sur les SLO.

Collecte, indexation, rétention, corrélation avec les alertes.

Scan d'images (Trivy), signature, politiques d'admission, SBOM.

Avant Sylva 1.6, un cluster de charge se créait avec apply-workload-cluster.sh. Depuis la 1.6, on déclare une ressource SylvaWorkloadCluster, réconciliée depuis un dépôt Git propre à l'équipe, avec des valeurs par défaut fournies par l'administrateur (SylvaUnitsReleasePresets).

Une version de Sylva prend en charge plusieurs versions de Kubernetes (par exemple 1.29 à 1.31 pour Sylva 1.4). On monte d'une version mineure à la fois, en vérifiant la version de chaque nœud avant et après.

Après le déploiement, la plateforme expose ses interfaces sous des noms d'hôtes en .sylva (rancher.sylva, keycloak.sylva, vault.sylva, harbor.sylva, flux.sylva, thanos.sylva) : savoir les joindre, retrouver les identifiants et à quoi sert chacun.

Dans chaque cluster, la pile rancher-logging (Fluent Bit, Fluentd) collecte les journaux ; Loki les centralise dans le cluster de gestion, consultables dans Grafana. La supervision se règle dans les sections logging et monitoring de values.yaml.

La section security de values.yaml règle un émetteur de certificats externe (par exemple Vault), la vérification des signatures d'images (cosign), le chiffrement WireGuard de Calico, l'analyse NeuVector et l'opérateur SBOM. Des politiques Kyverno font partie des units.

Réseau de pods, OVN-Kubernetes, Open vSwitch, NetworkPolicy, egress.

NetworkAttachmentDefinition, macvlan, ipvlan, séparation plan de contrôle / usager / gestion.

VF, opérateur SR-IOV, NIC supportées, accès direct pour l'UPF et les fonctions à haut débit.

Allocation de pages, topologie NUMA, alignement CPU/mémoire/NIC.

Isolation de CPU, gestionnaire de topologie, noyau temps réel, réglages pour CNF.

Une classe de nœud regroupe les réglages d'un type de charge : generic (sans HugePages ni CPU pinning), intensive (HugePages, CPU manager statique) ou SR-IOV (HugePages, SR-IOV, CPU pinning, NUMA, isolation des CPU système). Réservé aux clusters RKE2 ; l'isolation des CPU ajoute nohz_full, irqaffinity et reservedSystemCPUs.