Quest'anno Plesk ha deciso di inviare alcune persone a KubeCon, il principale evento su Kubernetes al mondo. In Russia non ci sono conferenze tematiche simili. Certo, parliamo di K8s e tutti lo desiderano, ma non si riuniscono così tante aziende praticanti in un unico luogo. Sono stato uno dei partecipanti, poiché lavoro su una piattaforma basata su Kubernetes.
Sull'organizzazione
Le dimensioni della conferenza sono impressionanti: 7000 partecipanti, un immenso centro espositivo. Il passaggio da una sala all'altra richiedeva 5-7 minuti. Erano in corso fino a 30 relazioni contemporaneamente su vari temi. C'era un'enorme quantità di aziende con i loro stand, alcuni dei quali mettevano in palio diversi buoni e un po' di premi interessanti, e distribuivano anche vari omaggi come magliette, penne e altre cose carine. Tutta la comunicazione era in inglese, ma non ho avuto nessuna difficoltà. Se questo è l'unico fattore per cui non partecipi a conferenze all'estero, vai pure. L'inglese nell'IT è più semplice dell'inglese comune grazie all'abbondanza di termini familiari che scrivi e leggi ogni giorno nel codice e nella documentazione. Anche nella comprensione delle relazioni non ci sono stati problemi. Avevo così tante informazioni in mente che alla sera assomigliavo a un server colpito da un overflow di buffer, ricevendo tutto direttamente nel subconscio.
Sulle relazioni
Voglio raccontare brevemente delle relazioni che mi sono piaciute di più e che consiglio di guardare.
Questa presentazione ha avuto un impatto significativo su di me perché ha toccato un dolore forte. Abbiamo molti servizi frammentati, supportati e sviluppati da persone diverse nel team. Seguiamo approcci come infrastruttura come codice, ma ci sono alcune questioni irrisolte. Esiste un repository con codice su Ansible, ma lo stato attuale e l'inventario sono conservati sulla macchina dello sviluppatore che esegue lo script, dove ci sono anche le credenziali. Parte delle informazioni possono essere trovate in Confluence, ma non è sempre chiaro dove. Non c'è un luogo dove semplicemente premere un pulsante e tutto vada bene. Si propone di fare una descrizione e posizionarla nel repository non solo con il codice ma anche con gli strumenti di deployment. Descrivere da dove ottenere lo stato e le credenziali, eseguire il make Install e godere del risultato. Vorrei più ordine nei servizi, seguirò i rilasci di CNAB, li utilizzerò, implementerò, convincerò. Un buon modello per la scrittura del Readme nel repository.
Ci sono molte informazioni sugli errori comuni nella scrittura di operatori. Ritengo che questa presentazione sia obbligatoria per chiunque desideri scrivere il proprio operatore per Kubernetes. Sono state considerate tutte le questioni relative agli stati, alla raccolta dei rifiuti, alla concorrenza e tutto il resto. Molto informativo. Mi è piaciuta molto una citazione dal codice dei volumi persistenti di Kubernetes:
K8s predica la difficoltà di integrazione a favore della semplicità di implementazione.
Questa presentazione esplora dettagliatamente uno degli elementi architettonici principali del cluster — il piano di controllo, in particolare un insieme di controller. Viene descritta la loro funzione e architettura, e i principi di base per creare un proprio controller utilizzando esempi già esistenti.
Tra i momenti più originali c'è la raccomandazione di non mascherare situazioni anomale con il comportamento corretto del controller, ma di modificare il comportamento in un certo modo per dare un segnale al sistema sull'emergere di problemi.
Un'esperienza molto interessante, con molte informazioni e ricette su cosa considerare quando si ha un carico davvero alto. In Kubernetes si sono messi bene, gestendo 50 cluster. Hanno parlato di tutti gli aspetti per spremere la massima prestazione. Consiglio di guardare la presentazione prima di prendere decisioni tecniche sui cluster.
La presentazione dopo la quale ho capito che è assolutamente necessario provare Loki per i log nel cluster e, probabilmente, rimanere con esso. Il punto è: Elasticsearch è pesante. Grafana ha voluto sviluppare una soluzione leggera e scalabile adatta per il debug dei problemi. La soluzione si è dimostrata elegante: Loki estrae dal Kubernetes meta-informazioni (etichette, come Prometheus) e le utilizza per organizzare i log. In questo modo, è possibile selezionare porzioni di log per servizio, trovare un pod specifico, scegliere un orario specifico, filtrare per codice errore. Questi filtri funzionano senza ricerca a testo completo. Così, restringendo gradualmente il campo di ricerca, si può arrivare a un errore specifico. Alla fine, la ricerca viene comunque coinvolta, ma poiché il campo è ristretto, la velocità è sufficiente senza indicizzazione. Facendo clic su di esso, viene caricato il contesto: un paio di righe prima e un paio di righe di log dopo. Così, appare come una ricerca di file di log e un grep su di esso, ma un po' più comodo e nello stesso interfaccia dove si trovano le metriche. È in grado di contare il numero di occorrenze della query di ricerca. Le query stesse assomigliano al linguaggio di Prometheus e sono semplici. Il relatore ha richiamato la nostra attenzione sul fatto che la soluzione non è molto adatta per l'analisi. Consiglio vivamente di guardare a tutti coloro che hanno bisogno di log, è una presentazione molto semplice.
I processi di deployment canary e blue-green sono mostrati in modo molto chiaro. Consiglio di vedere la presentazione a chi non l'ha ancora apprezzata. I relatori presentano la soluzione come un'estensione per il promettente sistema CI-CD ARGO. È più facile ascoltare la lingua inglese del relatore proveniente dalla Russia rispetto a quella degli altri relatori.
Uno degli aspetti più complessi della gestione di un cluster rimane la configurazione della sicurezza, in particolare i diritti di accesso alle risorse. I primitivi incorporati di K8s permettono di configurare l'autorizzazione come si desidera. Come mantenere senza dolori il loro stato aggiornato? Come capire cosa sta succedendo con i diritti di accesso e fare debug dei ruoli creati? In questa presentazione viene fornita non solo una panoramica di diversi strumenti per il debug dell'autorizzazione in k8s, ma anche raccomandazioni generali per costruire politiche semplici ed efficaci.
Altri interventi
Non consiglio. Alcuni erano di tipo captain, altri invece molto complessi. Ti consiglio di dare un'occhiata a questa playlist e di guardare tutto ciò che è contrassegnato come keynote. Questo ti permetterà di avere una visione ampia dell'industria intorno alle Cloud Native Apps, e poi è utile premere ctrl+f e cercare le parole chiave, le aziende, i prodotti e gli approcci di tuo interesse.
Qui c'è un link alla playlist con le presentazioni, prestaci attenzione
Sui stand delle aziende
Allo stand di Haproxy mi hanno regalato una maglietta per mio figlio. Dubito che per questo sostituirò Nginx con haproxy in produzione, ma li ricordo meglio di tutti. Chi sa cosa faranno i nuovi proprietari con Nginx.
Nello stand di IBM ci sono state brevi presentazioni per tutti e tre i giorni, e attiravano le persone sorteggiando Oculus Go, cuffie Beats e droni. Occorreva restare mezz'ora allo stand. Due volte in tre giorni ho tentato la sorte — non ho vinto. Anche VMWare e Microsoft hanno avuto brevi presentazioni.
Nello stand di Ubuntu ho fatto quello che, pare, abbia fatto tutti — mi sono fotografato con Shuttleworth. Un tipo socievole, si è rallegrato sapendo che la uso dal 8.04 e che il server è rimasto attivo per 10 anni senza dist upgrade senza un solo downtime (ma senza accesso a Internet).
Ubuntu sta sviluppando il suo MicroK8s — Veloce, Leggero, Developer Upstream Kubernetes
Non sono riuscito a passare oltre Dmitry Stolyarov, abbiamo parlato delle difficoltà quotidiane degli ingegneri che supportano Kubernetes. Le presentazioni le delega ai suoi colleghi, ma sta preparando un nuovo formato per presentare il materiale. Ha anche invitato a iscriversi al canale di Flant su youtube.
IBM, Cisco, Microsoft, VMWare hanno investito molti soldi negli stand. Gli stand degli amici open source erano più modestii. Ho parlato allo stand con i rappresentanti di Grafana, mi hanno convinto — bisogna provare Loki. Sembra che la ricerca full-text nel sistema di logging sia necessaria solo per l'analisi, mentre per il troubleshooting basti un sistema come Loki. Ho parlato con gli sviluppatori di Prometheus. Non hanno intenzione di creare uno storage a lungo termine per le metriche e di downsampling dei dati. Consigliano di vedere cortex e thanos come soluzioni. Ci sono stati moltissimi stand, ci sarebbe voluto un giorno intero per visitarli tutti. Una decina di soluzioni per il monitoraggio come servizio. Cinque servizi di sicurezza. Cinque servizi di performance. Una decina di UI per Kubernetes. Molti offrono k8s come servizio. Tutti vogliono il loro pezzo di mercato.
Amazon e Google hanno affittato dei cortili con erba artificiale sul tetto, allestendo lettini. Amazon distribuiva tazze e versava limonata, mentre allo stand parlava delle novità nel lavoro con gli spot instance. Google distribuiva biscotti con il logo di Kubernetes e ha creato una bella area fotografica, mentre allo stand pescava alla grande con una rete per l'enterprise.
Su Barcellona
Innamorato di Barcellona. Ci sono stato per la seconda volta, la prima nel 2012 per un tour panoramico. È incredibile, ma molti fatti sono tornati alla memoria; sono riuscito a raccontare molto ai miei colleghi, sono stato una sorta di mini-guida. L'aria fresca del mare mi ha subito liberato dall'allergia. Deliziosi frutti di mare, paella, sangria. Architettura molto calda e soleggiata. Bassi edifici, molta vegetazione. In questi tre giorni abbiamo camminato a piedi per circa 50 chilometri; in questa città si desidera passeggiare ancora e ancora. Tutto ciò dopo le presentazioni, la sera.
Cosa ho capito di principale
Sono molto felice di aver avuto l'opportunità di partecipare a questa conferenza. Ha chiarito ciò che prima non era chiaro. Mi ha ispirato, rendendo evidenti alcune cose.
Un pensiero ricorrente è emerso: Kubernetes non è un punto di arrivo, ma uno strumento. Una piattaforma per costruire piattaforme.
E il compito principale di tutto il movimento: raccogliere e lanciare applicazioni scalabili
Le principali direzioni su cui la comunità sta lavorando si sono cristallizzate. In un certo senso, come sono emersi i 12 fattori per le applicazioni, è nata una lista di ciò che e come fare per l'infrastruttura nel suo insieme. Se volete, si possono chiamare tendenze:
- Ambientazioni dinamiche
- Cloud pubblici, ibridi e privati
- Container
- Service mesh
- Microservizi
- Infrastruttura immutabile
- API dichiarativa
Queste tecniche consentono di costruire sistemi con le seguenti caratteristiche:
- Protetti dalla perdita di dati
- Elastici (che si adattano al carico)
- Gestibili
- Osservabili (tre pilastri: monitoraggio, registrazione, tracciamento)
- In grado di rilasciare cambiamenti significativi frequentemente e in modo prevedibilmente sicuro.
CNCF seleziona i migliori progetti (una lista ristretta) e sostiene queste cose:
- Automazione sana
- Codice aperto
- Libertà di scelta del fornitore di servizi
Kubernetes è complesso. È semplice in termini ideologici e a pezzi, ma complesso nel suo complesso. Nessuno ha mostrato soluzioni all-in-one. Nel mercato di k8s come servizio, e in tutto il resto del mercato, è un vero far west: il supporto è venduto a 50$ e a 1000$ al mese. Ognuno si addentra in qualche parte e scava in essa. Qualcuno si occupa di monitoraggio e dashboard, qualcuno di performance, qualcun altro di sicurezza.
K8S, sta solo iniziando!
Fonte: habr.com
