{"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\/nl\/blog\/administrirovanie\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","title":{"rendered":"Is het eenvoudig en handig om een Kubernetes-cluster op te zetten? We introduceren de addon-operator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Is
\n
\nNa shell-operator<\/a><\/noindex> We stellen zijn oudere broer voor \u2014 addon-operator<\/a><\/noindex>. Dit is een Open Source-project dat wordt gebruikt voor de installatie in een Kubernetes-cluster van systeemcomponenten, die samen onder de algemene term \u2014 aanvullingen \u2014 kunnen worden genoemd.<\/a><\/noindex><\/p>\n

Waarom zouden we \u00fcberhaupt aanvullingen nodig hebben?<\/h2>\n

\nHet is geen geheim dat Kubernetes geen kant-en-klaar product is; voor het opbouwen van een 'volwassen' cluster zijn verschillende aanvullingen nodig. De addon-operator helpt bij het installeren, configureren en onderhouden van deze aanvullingen in de actuele staat.<\/p>\n

De noodzaak van extra componenten in het cluster wordt onthuld in presentatie<\/a><\/noindex> collega's driusha<\/a><\/noindex>. Kortom, de situatie met Kubernetes is op dit moment zodanig dat je voor een eenvoudige installatie om te 'spelen' kunt volstaan met de componenten uit de doos, voor ontwikkelaars en testen kun je Ingress toevoegen, maar voor een volledige installatie die je 'je productie is klaar' kunt noemen, is het nodig om een tiental verschillende aanvullingen toe te voegen: iets voor monitoring, iets voor logs, vergeet de ingress en cert-manager niet, wijs knooppuntgroepen toe, stel netwerkbeleid in, en voeg instellingen voor sysctl en pod autoscaler toe...<\/p>\n

\"Is
\n<\/p>\n

Wat is de specificiteit van het werken met hen?<\/h2>\n

\nZoals de praktijk aantoont, beperkt het zich niet tot alleen installatie. Voor comfortabel werken met het cluster moeten aanvullingen worden bijgewerkt, uitgeschakeld (uit het cluster verwijderd), en sommige willen we testen voordat ze in het productiecluster worden ge\u00efnstalleerd.<\/p>\n

Dus, is Ansible hier misschien voldoende? Misschien. Maar volledige aanvullingen leven in het algemeen niet zonder instellingen<\/b>. Deze instellingen kunnen per cluster optie verschillen (aws, gce, azure, bare-metal, do, \u2026). Sommige instellingen kunnen niet van tevoren worden ingesteld \u2014 deze moeten uit het cluster worden gehaald. En het cluster is niet statisch: voor sommige instellingen moet je wijzigingen volgen. En hier schiet Ansible te kort: er is een programma nodig dat in het cluster leeft, namelijk een Kubernetes Operator.<\/p>\n

Degenen die het in de praktijk hebben geprobeerd shell-operator<\/a><\/noindex>, zullen zeggen dat de taken van installatie en update van aanvullingen en het toezicht houden op instellingen heel goed kunnen worden opgelost met behulp van hooks<\/a><\/noindex> voor de shell-operator. Je kunt een script schrijven dat een voorwaardelijke kubectl apply<\/code> maakt en bijvoorbeeld de ConfigMap in de gaten houdt, waar de instellingen worden bewaard. Dit is ongeveer wat is gerealiseerd in de addon-operator.<\/p>\n

Hoe is het georganiseerd in de addon-operator?<\/h2>\n

\nBij het cre\u00ebren van een nieuwe oplossing zijn we uitgegaan van de volgende principes:<\/p>\n