Niveau 1 · Infrastructure télécom et hybride
Architecture Kubernetes et Red Hat OpenShift
Nous concevons, mettons à niveau et exploitons des clusters de production sur bare-metal et VMware. L’admission des charges, les chemins réseau télécom et les contrôles de cycle de vie GitOps sont conçus et testés ensemble, avec une validation restricted-v2 sur les charges applicatives OpenShift prises en charge.
Sprint d’évaluation de 2 semaines, 14 500 $US forfaitaires · crédité à 100 % sur un retainer annuel ou un contrat managé signé dans les 30 jours
Images exigeant root, CRD incompatibles, réseaux plats et changements oc/kubectl manuels font échouer les déploiements de laboratoire en entreprise. Persistance, identité, DNS et registres restent souvent sans tests jusqu’à l’incident.
Refonte des images, Helm et Kustomize pour UID non-root arbitraires, seccomp RuntimeDefault et capacités supprimées. Validation SCC et racine en lecture seule lorsque compatible ; exceptions Operators examinées séparément.
Multus, SR-IOV, dual-stack IPv4/IPv6 et MetalLB/BGP selon distribution et matériel. NetworkPolicy, mTLS et tests des chemins de trafic répondent aux exigences d’isolation et de latence.
Gérer les clusters bare-metal IPI/UPI et vSphere par des changements GitOps revus. Valider le graphe de mise à jour pris en charge, les transitions EUS, les API dépréciées, la compatibilité des Operators, les budgets de disruption et le comportement de drainage ; répéter les mises à niveau et la récupération etcd pour la version installée.
Intégrer les classes de stockage ODF/Ceph ou CSI vSAN prises en charge, les métriques Prometheus/Thanos et les pipelines de logs Loki/Vector. Tester la persistance, l’extension du stockage, la restauration, l’acheminement des alertes et le routage des journaux d’audit avec les propriétaires des applications.
restricted-v2 n’impose pas seul une racine en lecture seule. Les Operators peuvent exiger des permissions revues. La disponibilité dépend de la redondance, des applications et du chemin de mise à niveau supporté.
Des chemins distincts de gestion, de migration et de routage hybride, reliés par des dépendances de plateforme validées.
Gestion des télécommunications
Virtualisation et plateforme de conteneurs
Stockage hybride et virtualisation
Les interfaces des éléments varient selon la version. Les migrations warm MTV nécessitent une fenêtre de bascule finale ; le retour après des écritures sur la cible exige une réconciliation des données. Les privilèges du cluster et l’hébergement ENM sont revus pour chaque charge prise en charge.
Télécharger la source Mermaid (.mmd)Vous conservez code, manifestes, schémas, runbooks et preuves livrés dans vos dépôts. Le SOW définit les systèmes, critères d’acceptation et prérequis d’accès.
Configuration machines, ingress, stockage, namespaces et RBAC avec overlays GitOps par environnement.
Helm/Kustomize, preuves restricted-v2 applicables et registre séparé des exceptions approuvées.
Règles ingress/egress, réseaux secondaires, IP et politiques mTLS documentés et testés.
Scans d’API, prérequis, perturbations, reprise etcd et résultats de restauration des données.
Dimensionnement du plan de contrôle, segmentation entrante et sortante et disposition du stockage ODF en source Mermaid dans votre dépôt.
Liaisons de groupes OIDC à moindre privilège, quotas de namespace et LimitRanges, pour que les locataires travaillent en project-admin sans exception cluster-admin.
Ce que couvre le sprint à 14 500 $US pour ce service. L’accès reste en lecture seule du début à la fin, et vous conservez les livrables, que vous poursuiviez ou non.
Jours 1 à 3
Revue en lecture seule des versions de cluster, des Operators, des attributions de SCC, des exceptions anyuid et privilégiées, des attachements réseau et des classes de stockage.
Jours 4 à 6
Charges qui ne peuvent pas tourner sous restricted-v2, conflits Multus/SR-IOV et IPAM, et blocages de mise à niveau comme les PodDisruptionBudgets et les API obsolètes.
Jours 7 à 9
Architecture de référence du cluster en source Mermaid (.mmd), ordre de remédiation des charges et plan de répétition des mises à niveau et de la reprise.
Jour 10
Constats, changements de politiques et de RBAC nécessaires et backlog à périmètre fixe pour votre équipe ou le binôme d’ingénieurs principaux.
Nous migrons et soutenons les systèmes de gestion télécom et l’infrastructure hybride, automatisons la validation et le déploiement des charges, et construisons les portails et intégrations d’API réseau qui exposent ces plateformes à vos équipes et à vos clients.
Une mise à niveau qui s’arrête en plein drainage, ou une charge qui ne peut pas récupérer ses données, coûte plus que ce que la plateforme a économisé. La préparation doit être prouvée pour le cluster et pour chaque application séparément.
Adapté à
Un cluster sain peut héberger une charge refusée à l’admission, privée d’image ou incapable de restaurer ses données. Nous vérifions séparément plateforme et applications, avec leurs dépendances externes.
Pour la revue
Distribution, version, topologie, connectivité du registre, classes de stockage et exigences des charges.
Consigner versions, Operators, registre, identité, réseau et stockage. Valider les manifestes selon le SCC et les droits du namespace, puis tester ingress, persistance et chemin de déploiement approuvé.
Distribution et version, agencement du cluster et rôles des nœuds, registre et sources d’images, fournisseur d’identité, classes de stockage et pilotes CSI, l’inventaire des Operators, et une procédure de sauvegarde vérifiée pour etcd et les données persistantes.
Analyser les incidents avec les équipes plateforme et applicatives. Préparer mises à jour et tests de reprise pour l’état du cluster, les données persistantes et services externes selon la version installée.
Liste de préparation, résultats d’admission, configuration versionnée et preuves distinctes de reprise plateforme et applicative.
Identifiez les responsables plateforme, applications et infrastructure. Confirmez les accès, abonnements éditeurs, approbations de changement et la validation des workloads et de la reprise des données.
Couverture du support
Découvrez un exemple de périmètre. Nous convenons des interfaces, droits et critères d’acceptation avant livraison ; utilisez le design de la mission pour déployer.
Utilisez nos modèles pour définir les travaux et valider les livrables. Adaptez-les à votre environnement. Ils sont illustratifs, sans résultats clients, procédures certifiées ni instructions exécutables en production.
Exemple de résultat attendu
Préparation Kubernetes / OpenShift
Comparez propriété de plateforme, support des Operators et reprise applicative avant de choisir une distribution Kubernetes.
Points à examiner pour les mises à jour EUS de Red Hat OpenShift : compatibilité des Operators, pauses des pools workers et prérequis de reprise.
Planifier une migration VMware vers Red Hat OpenShift Virtualization : inventaire, exigences cibles, pilotes et reprise lors de la bascule.
