Plan de control cloud
Un plan de control cloud este stratul de interfețe, API-uri și servicii care permite provizionarea, configurarea și administrarea infrastructurii — separat de planul de date, care rulează efectiv sarcinile de lucru și transportă traficul. Fiecare furnizor are propriul său plan de control; termenul acoperă și sistemele care gestionează mai mulți furnizori ca un singur plan.
Orice infrastructură are două straturi distincte. Planul de date este infrastructura propriu-zisă: mașinile virtuale care rulează aplicația, rețeaua care transportă pachetele între ele, discul care servește operațiile de citire și scriere. Planul de control este tot ce folosiți pentru a decide cum ar trebui să arate acea infrastructură și pentru a o modifica — API-ul, consola, CLI-ul, sistemul de permisiuni care decide cine are voie să facă o modificare. Când creați o mașină virtuală într-o consolă cloud, redimensionați un disc sau deschideți un port de firewall, operați planul de control. Instanța care pornește, gigabiții suplimentari care devin disponibili, traficul care începe să circule — acesta este planul de date răspunzând la ce i-a spus planul de control să facă.
Distincția devine mai utilă odată ce o echipă folosește mai mult de un furnizor. AWS are un plan de control. La fel Google Cloud, Azure, Hetzner și orice alt furnizor — fiecare cu propria consolă, propria formă de API, propriile credențiale, propria denumire pentru ceea ce se numește „security group” sau „firewall rule”. O echipă care rulează trei clouduri și douăzeci de servere bare-metal operează de fapt trei sau patru planuri de control separate în paralel, plus orice altceva folosesc pentru a administra serverele care nu se află în niciun cloud. Nimic nu obligă acele planuri de control să fie în concordanță unele cu altele, iar în afara propriului proces, nimic nu păstrează o modificare făcută într-unul dintre ele vizibilă pentru cineva care se uită în altul.
„Plan de control cloud” este folosit și într-un sens mai restrâns — în interiorul Kubernetes, planul de control este API server-ul, scheduler-ul și controller-manager-ul care decid unde rulează pod-urile, spre deosebire de kubelet-uri și containerele care le rulează efectiv pe noduri. Un plan de control „multi-cloud” sau „unificat” extinde aceeași idee la nivelul mai multor furnizori: un singur loc pentru a vedea și a acționa asupra infrastructurii care se află fizic în mai multe conturi, regiuni și furnizori diferiți, în locul unei interfețe per furnizor. Nu înlocuiește planurile de control ale furnizorilor de bază — o cerere ajunge tot ca un apel API către AWS, Hetzner sau agentul de flotă de pe un server bare-metal — ci se plasează în fața lor astfel încât persoana care face modificarea trebuie să învețe un singur sistem.
De ce contează distincția din punct de vedere operațional
Majoritatea incidentelor de infrastructură și a lacunelor de audit își au originea în probleme ale planului de control, nu ale planului de date: o modificare pe care nimeni n-a înregistrat-o, o permisiune pe care nimeni n-a revocat-o, o regulă de firewall deschisă în consola unui furnizor pe care nimeni altcineva din echipă nu o poate vedea. Când fiecare cloud are propriul plan de control și propria pistă de audit, „cine a modificat asta și când” devine o întrebare la care răspundeți autentificându-vă în trei sau patru console diferite și comparând manual marcajele de timp — sau la care nu răspundeți deloc. Pentru echipele supuse unor cadre de conformitate precum NIS2, această lacună nu este doar incomodă: istoricul modificărilor, controlul accesului și dovezile privind incidentele sunt exact ce cere în primul rând un auditor sau un reglementator, iar un plan de control fragmentat este motivul pentru care aceste dovezi de multe ori nu există într-un singur loc.
Cum se integrează Sencai
Sencai este un plan de control care se plasează deasupra celor native: se conectează la conturi din unsprezece furnizori cloud, plus servere on-premise și bare-metal printr-un agent de flotă ușor, și inventariază ce rulează deja în momentul conectării unui cont — fără a fi necesară nicio migrare. De acolo, provizionarea, pornirea, oprirea, redimensionarea și distrugerea instanțelor funcționează la fel, indiferent de furnizor. Puteți conecta conturi existente (nimic nu se mută, credențialele rămân revocabile la furnizor) sau puteți lăsa Sencai să provizioneze și să factureze capacitatea direct, combinând ambele abordări într-o singură organizație. Fiecare acțiune, la nivelul fiecărui furnizor conectat, ajunge într-un singur jurnal de audit append-only, înlănțuit prin hash, astfel încât „cine a modificat asta și când” este o interogare, nu o investigație.
Vezi inventarierea și provizionarea →