{"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\/en\/blog\/administrirovanie\/gotovit-kubernetes-klaster-prosto-i-udobno-anonsiruem-addon-operator","title":{"rendered":"Is setting up a Kubernetes cluster easy and convenient? Announcing the addon-operator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Is
\n
\nFollowing shell-operator<\/a><\/noindex> we present its older brother \u2014 addon-operator<\/a><\/noindex>. This is an Open Source project used to install the system components in a Kubernetes cluster, which can be collectively referred to as add-ons.<\/a><\/noindex><\/p>\n

Why do we even need add-ons?<\/h2>\n

\nIt's no secret that Kubernetes is not a ready-made, all-in-one product, and building a 'mature' cluster requires various add-ons. The addon-operator helps install, configure, and keep these add-ons up to date.<\/p>\n

The need for additional components in the cluster is outlined in presentation<\/a><\/noindex> colleagues driusha<\/a><\/noindex>. In short, the current state of Kubernetes is such that for a simple installation just to play around, the out-of-the-box components may suffice. For development and testing, you can add Ingress, but for a full installation that can be called 'your production is ready', you need to add about a dozen different add-ons: something for monitoring, something for logs, not forgetting ingress and cert-manager, defining node groups, adding network policies, seasoning with sysctl settings and pod autoscaler...<\/p>\n

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

What is the specificity of working with them?<\/h2>\n

\nAs practice shows, it's not just about installation. For comfortable operation with the cluster, add-ons need to be updated, disabled (removed from the cluster), and some things will need testing before being installed in the production cluster.<\/p>\n

So, maybe Ansible is enough here? Perhaps. But full-fledged add-ons generally do not operate without configurations<\/b>. These settings may vary depending on the cluster option (aws, gce, azure, bare-metal, do, ...). Some settings cannot be predefined\u2014they need to be obtained from the cluster. And the cluster is not static: for some settings, it will be necessary to monitor changes. This is where Ansible falls short: a program is required that resides in the cluster, i.e., a Kubernetes Operator.<\/p>\n

Those who have tried it in practice shell-operator<\/a><\/noindex>, will say that the tasks of installing and updating add-ons and monitoring configurations can indeed be solved using . In general, Airflow hooks are the connection points to external services and libraries. For example,<\/a><\/noindex> for shell-operator. You can write a script that will perform a conditional kubectl apply<\/code> and monitor, for instance, the ConfigMap where the settings are stored. This is essentially what is implemented in the addon-operator.<\/p>\n

How is this organized in addon-operator?<\/h2>\n

\nWhen creating a new solution, we based it on the following principles:<\/p>\n