{"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\/no\/blog\/administrirovanie\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","title":{"rendered":"Er det enkelt og praktisk \u00e5 sette opp et Kubernetes-kluster? Vi lanserer addon-operator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Er
\n
\nI kj\u00f8lvannet av shell-operator<\/a><\/noindex> vi presenterer hans eldre bror \u2014 addon-operator<\/a><\/noindex>. Dette er et Open Source-prosjekt som brukes til \u00e5 installere systemkomponenter i en Kubernetes-klynge, som samlet kan kalles tillegg.<\/a><\/noindex><\/p>\n

Hvorfor trenger vi i det hele tatt noen tillegg?<\/h2>\n

\nDet er ingen hemmelighet at Kubernetes ikke er et klart produkt alt-i-ett, og for \u00e5 bygge en 'moden' klynge vil det v\u00e6re behov for ulike tillegg. Addon-operatoren vil hjelpe med \u00e5 installere, konfigurere og holde disse tilleggene oppdatert.<\/p>\n

Behovet for ekstra komponenter i klyngen er tatt opp i foredraget<\/a><\/noindex> kolleger driusha<\/a><\/noindex>. Kort sagt, situasjonen med Kubernetes i dag er slik at for enkel installasjon for \u00e5 'leke' kan man klare seg med innebygde komponenter, for utvikling og testing kan man legge til Ingress, men for en fullverdig installasjon, hvor man kan si 'produksjonen er klar', m\u00e5 man legge til rundt ti forskjellige tillegg: noe for overv\u00e5king, noe for logger, ikke glem ingress og cert-manager, tildele grupper av noder, legge til nettverksregler, krydre med sysctl-innstillinger og pod autoscaler\u2026<\/p>\n

\"Er
\n<\/p>\n

Hva er spesifisiteten ved \u00e5 jobbe med dem?<\/h2>\n

\nSom praksis viser, er det ikke nok med en enkel installasjon. For komfortabelt arbeid med klyngen, m\u00e5 tilleggene oppdateres, deaktiveres (fjernes fra klyngen), og noe vil man kanskje teste f\u00f8r installasjon i produksjonsklyngen.<\/p>\n

S\u00e5, kanskje Ansible er tilstrekkelig her? Kanskje. Men fullverdige tillegg lever vanligvis ikke uten konfigurasjoner<\/b>. Disse innstillingene kan variere avhengig av klyngealternativet (aws, gce, azure, bare-metal, do, \u2026). Noen innstillinger kan ikke defineres p\u00e5 forh\u00e5nd \u2014 de m\u00e5 hentes fra klyngen. Og klyngen er ikke statisk: for enkelte innstillinger m\u00e5 man f\u00f8lge med p\u00e5 endringene. Her er ikke Ansible tilstrekkelig: man trenger et program som lever i klyngen, dvs. Kubernetes Operator.<\/p>\n

De som har pr\u00f8vd det i praksis shell-operator<\/a><\/noindex>, vil si at oppgavene med \u00e5 installere og oppdatere tillegg og holde \u00f8ye med konfigurasjoner, ganske enkelt kan l\u00f8ses med hookene<\/a><\/noindex> for shell-operator. Man kan skrive et skript som gj\u00f8r en betinget kubectl apply<\/code> og holder \u00f8ye med for eksempel ConfigMap, hvor konfigurasjonene vil bli lagret. Omtrent dette er implementert i addon-operator.<\/p>\n

Hvordan er dette organisert i addon-operator?<\/h2>\n

\nN\u00e5r vi skapte en ny l\u00f8sning, baserte vi oss p\u00e5 f\u00f8lgende prinsipper:<\/p>\n