{"id":35226,"date":"2019-10-31T22:03:05","date_gmt":"2019-10-31T19:03:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator\/"},"modified":"2019-10-31T22:03:05","modified_gmt":"2019-10-31T19:03:05","slug":"gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","title":{"rendered":"Creare un cluster Kubernetes \u00e8 semplice e conveniente? Annunciamo l'addon-operator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Creare
\n
\nIn seguito a shell-operator<\/a><\/noindex> presentiamo il suo fratello maggiore \u2014 addon-operator<\/a><\/noindex>. \u00c8 un progetto Open Source utilizzato per l'installazione, in cluster Kubernetes, di componenti di sistema che possiamo chiamare genericamente \u2014 estensioni.<\/a><\/noindex><\/p>\n

Perch\u00e9 abbiamo bisogno di estensioni?<\/h2>\n

\nNon \u00e8 un segreto che Kubernetes non sia un prodotto completo tutto-in-uno e per costruire un cluster \"maturo\" siano necessarie varie estensioni. L'addon-operator aiuta a installare, configurare e mantenere queste estensioni aggiornate.<\/p>\n

La necessit\u00e0 di componenti aggiuntivi nel cluster \u00e8 spiegata in report<\/a><\/noindex> colleghi driusha<\/a><\/noindex>. In breve, la situazione attuale con Kubernetes \u00e8 tale che per una semplice installazione \"per divertirsi\" si possono utilizzare i componenti di base, per sviluppatori e test si pu\u00f2 aggiungere Ingress, ma per un'installazione completa, di cui si pu\u00f2 dire \"la vostra produzione \u00e8 pronta\", \u00e8 necessario aggiungere una dozzina di vari estensioni: qualcosa per il monitoring, qualcosa per i log, non dimenticare ingress e cert-manager, dedicare gruppi di nodi, aggiungere politiche di rete, condire con impostazioni sysctl e un pod autoscaler...<\/p>\n

\"Creare
\n<\/p>\n

Qual \u00e8 la specificit\u00e0 del lavoro con loro?<\/h2>\n

\nCome dimostra la pratica, non basta una sola installazione. Per lavorare comodamente con il cluster, sar\u00e0 necessario aggiornare i plugin, disabilitarli (rimuoverli dal cluster) e testare alcune funzionalit\u00e0 prima di installarle nel cluster di produzione.<\/p>\n

Quindi, baster\u00e0 qui anche Ansible? Forse. Ma i plugin completi generalmente non funzionano senza configurazioni<\/b>. Queste impostazioni possono variare a seconda dell'opzione del cluster (aws, gce, azure, bare-metal, do, \u2026). Alcune impostazioni non possono essere definite in anticipo \u2014 devono essere ottenute dal cluster. E il cluster non \u00e8 statico: per alcune impostazioni \u00e8 necessario monitorare le modifiche. E qui Ansible non basta: serve un programma che viva nel cluster, ovvero Kubernetes Operator.<\/p>\n

Coloro che l'hanno provato in pratica shell-operator<\/a><\/noindex>, diranno che le attivit\u00e0 di installazione e aggiornamento dei plugin e di monitoraggio delle impostazioni possono essere tranquillamente gestite con hook<\/a><\/noindex> per shell-operator. \u00c8 possibile scrivere uno script che faccia un condizionale kubectl apply<\/code> e monitori, ad esempio, il ConfigMap dove saranno archiviate le configurazioni. Questo \u00e8 pi\u00f9 o meno ci\u00f2 che \u00e8 stato realizzato in addon-operator.<\/p>\n

Come \u00e8 organizzato in addon-operator?<\/h2>\n

\nCreando una nuova soluzione, ci siamo basati sui seguenti principi:<\/p>\n