Il 24 novembre si è concluso Slёrm Mega, un'intensivo avanzato su Kubernetes. si terrà a Mosca dal 18 al 20 maggio.
L'idea di Slёrm Mega: dare uno sguardo sotto il cofano del cluster, analizzare in teoria e pratica le complessità dell'installazione e configurazione di un cluster production-ready («the-not-so-easy-way»), esaminare i meccanismi di sicurezza e resilienza delle applicazioni.
Bonus di Mega: coloro che frequentano Slёrm Base e Slёrm Mega acquisiranno tutte le conoscenze necessarie per sostenere l'esame per il e uno sconto del 50% sull'esame.
Un ringraziamento speciale a Selectel per aver fornito il cloud per la pratica, che ha permesso a ciascun partecipante di lavorare nel proprio cluster completo, evitando di aggiungere ulteriori 5.000 al prezzo del biglietto.
Chi sono Bondarev e Selivanov, non lo dirò, chi è interessato, .
Slёrm Mega. Primo giorno.
Il primo giorno di Slёrm Mega abbiamo caricato i partecipanti con 4 argomenti. Pavel Selivanov ha parlato del processo di creazione di un cluster resiliente dall'interno, del funzionamento di Kubeadm e del testing e troubleshooting del cluster.
La prima pausa caffè. Di solito è un «colpo di campana per l'insegnante», ma a Slёrm, mentre gli studenti bevono caffè, gli insegnanti continuano a rispondere alle domande.
E nonostante il piccolo cartello «Intervallo II» sopra la testa di Pavel Selivanov, rimanere in pausa non è destino per lui.
Sergey Bondarev e Marcel Ibraev aspettano il loro turno per salire al podio.
Durante la pausa mi sono avvicinato a Sergey Bondarev e gli ho chiesto: «Cosa consiglieresti a tutti gli ingegneri Kubernetes in base alla tua esperienza con i cluster dei nostri clienti?»
Sergey ha dato un semplice consiglio: «Chiudete l'accesso a internet al server API. Perché ci sono periodicamente minacce alla sicurezza che possono consentire l'accesso al cluster a utenti non autorizzati.»
Dopo un paio di minuti e una bottiglia d'acqua minerale, Pavel Selivanov si è lanciato in tema «Autorizzazione nel cluster tramite fornitore esterno», precisamente LDAP (Nginx + Python) e OIDC (Dex + Gangway).
Nella prossima pausa, il suo consiglio agli ingegneri Kubernetes è stato dato da Marcel Ibraev, relatore di Slёrm, Certified Kubernetes Administrator: «Dirò una cosa che può sembrare banale, ma dato quanto spesso mi imbatto in questo, c'è il sospetto che non tutti lo considerino. Non bisognerebbe fidarsi ciecamente di vari How-To presenti su Internet che spiegano quanto sia fantastico un certo tipo di soluzione. Nel contesto di Kubernetes, questo acquista un significato particolare. Infatti, Kubernetes è un sistema complesso e l'aggiunta di una soluzione che non è stata testata nel proprio progetto specifico e nella propria installazione del cluster può portare a conseguenze negative, nonostante quanto scritto su Internet riguardo alla sua efficacia. Anche solo Kubernetes stesso, senza un approccio ponderato, può nuocere al vostro progetto, "ciò che è buono per il russo, è morte per il tedesco". Pertanto, testiamo, verifichiamo e proviamo qualsiasi soluzione prima di implementarla. Solo in questo modo si tenerà conto di tutte le sfaccettature possibili.».
Dopo il pranzo, è entrato in gioco Sergey Bondarev. Il suo tema è la Network policy, in particolare un'introduzione a CNI e Network Security Policy.
Su Internet ci sono molte informazioni sulla Network Policy. Tra gli amministratori si sente l'opinione che senza le Network Policies si possa fare, ma i professionisti della sicurezza amano molto questo strumento e richiedono che le Network Policies siano attivate.
Il timone di Kubernetes è stato assunto da Sergey Bondarev, con il tema "Applicazioni sicure e ad alta disponibilità nel cluster". Ha alcune tematiche preferite: PodSecurityPolicy, PodDisruptionBudget, LimitRange/ResourceQuota.
Il tema di Megi, con cui Pavel ha partecipato a DevOpsConf: .
Dopo aver spiegato quanto sia facile hackerare un cluster Kubernetes, gli amministratori scettici dicono: "Aha, lo dicevo, il vostro Kubernetes è una schifezza piena di buchi". Pavel spiega che è possibile configurare la sicurezza nel cluster, e non è difficile, semplicemente per impostazione predefinita le configurazioni di sicurezza sono disattivate. Maggiori dettagli nella trascrizione .
— Chi ha rotto il cluster? Lui ha rotto il cluster! Lo vedo benissimo da qui!
Nei Sliorm non è mai tutto facile e semplice, per non annoiarsi. Ma questa volta Telegram ha deciso di mostrare a tutti il quinto punto:
Marcel Ibraev, [22 nov. 2019, 16:52:52]:
Colleghi, attualmente ci sono interruzioni nel funzionamento di Telegram, tenetelo a mente
Si è conclusa la prima giornata, ricca e piena di conoscenze pratiche. Il secondo giorno ci sarà ancora più pratica, con l'avvio di un cluster di database usando PostgreSQL, l'avvio di un cluster RabbitMQ e la gestione dei segreti in Kubernetes.
Slurm Mega. Secondo giorno.
Il presentatore ha iniziato il secondo giorno con un annuncio vivace: «Questa mattina, come ha detto ieri Pavel, ci aspetta un vero hardcore. Parlando il linguaggio dei chirurghi, ci immergeremo nelle viscere di Kubernetes!»
Il massaggiatore di eventi è un'intera storia a sé. Uno dei problemi di Slurm è che le persone si disattivano e si addormentano a causa del sovraccarico informativo. Abbiamo sempre cercato di trovare un modo per affrontare questa situazione, e all'ultimo Slurm piccole attività con il pubblico hanno dato buoni risultati. Questa volta abbiamo assunto una persona appositamente addestrata. Nel chat si scherzava molto su «concorsi interessanti», ma il fatto rimane: non abbiamo mai visto partecipanti così energici.
Marsel Ibraev ha ricevuto supporto e ha iniziato a studiare applicazioni stateful nel cluster. In particolare, l'avvio di un cluster di database usando PostgreSQL e l'avvio di un cluster RabbitMQ.
Dopo pranzo, Sergey Bondarev si è occupato di K8S. Il suo tema era «Gestione dei segreti». Era affiancato da Mulder e Scully. Hanno studiato la gestione dei segreti in Kubernetes e Vault. E anche «La verità è là fuori».
E così è continuato fino a tardi, quando Pavel Selivanov ha parlato di Horizontal Pod Autoscaler.
Slurm Mega. Terzo giorno.
Sergey Bondarev ha energicamente svegliato il pubblico al mattino, parlando di backup e ripristino dopo i guasti. Ha verificato personalmente il backup e il ripristino del cluster utilizzando Heptio Velero e etcd.
Sergey ha continuato il tema della rotazione annuale dei certificati nel cluster: il rinnovo dei certificati del control-plane tramite kubeadm. Proprio prima di pranzo, per stuzzicare l'appetito dei partecipanti o per farlo svanire del tutto, Pavel Selivanov ha sollevato il tema del deployment dell'applicazione.
Sono stati esaminati strumenti di templating e deployment, e insieme strategie per il deployment.
Pavel Selivanov ha presentato un nuovo argomento: Service Mesh, installazione di Istio. L'argomento si è rivelato così ricco che si potrebbe fare un intenso incontro dedicato. Stiamo discutendo dei piani, seguite gli annunci.
L'importante è che tutto funzioni correttamente. Perché è tempo di pratica:
Costruzione di CI/CD per avviare contemporaneamente il deployment dell'applicazione e l'aggiornamento del cluster. Nei progetti didattici tutto funziona bene. Ma la vita a volte è piena di sorprese.
Che la Slurm sia con te!
Fonte: habr.com
