Kubernetes оператор на Python без фреймворкове и SDK

Go в момента е монополист сред програмните езици, които хората избират за написване на оператори за Kubernetes. Има обективни причини за това, като:

1. Съществува мощен фреймуърк за разработка на оператори на Go — Operator SDK.
2. На Go са написани приложения, които измениха играта, като Docker и Kubernetes. Да напишете свой оператор на Go означава да говорите с екосистемата на един и същ език.
3. Високата производителност на приложенията на Go и лесните инструменти за работа с concurrency "от кутията".

NB: Между другото, как да напишете свой оператор на Go, ние вече описахме в един от нашите преводи на чуждестранни автори.

Но какво, ако изучаването на Go ви пречи отсъствието на време или елементарно, мотивация? В статията е даден пример как може да се напише качествен оператор, използвайки един от най-популярните езици, който почти всеки DevOps инженер познава — Python.

Представяме ви: Копиратор — копировален оператор!

За пример ще разгледаме разработката на прост оператор, предназначен за копиране на ConfigMap, както при появата на нов namespace, така и при промяна на една от двете същности: ConfigMap и Secret. От практическа гледна точка операторът може да бъде полезен за масово обновление на конфигурации на приложение (чрез обновление на ConfigMap) или за обновление на секретни данни — например, ключове за работа с Docker Registry (при добавяне на Secret в namespace).

И така, какво трябва да притежава един добър оператор:

1. Взаимодействието с оператора се осъществява чрез Custom Resource Definitions (по-долу — CRD).
2. Операторът може да бъде настроен. За целта ще използваме флагове на командния ред и променливи на средата.
3. Създаването на Docker контейнер и Helm график е организирано така, че потребителите да могат лесно (буквално с една команда) да инсталират оператора в своя Kubernetes клъстер.

CRD

За да знае операторът кои ресурси и къде да търси, трябва да зададем правило за него. Всяко правило ще бъде представено под формата на един обект CRD. Какви полета трябва да има този CRD?

1. Тип ресурс, който ще търсим (ConfigMap или Secret).
2. Списък на namespace’ите, в които трябва да се намират ресурсите.
3. Селектор, по който ще търсим ресурси в namespace.

Нека опишем CRD:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: copyrator.flant.com
spec:
  group: flant.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: copyrators
    singular: copyrator
    kind: CopyratorRule
    shortNames:
    - copyr
  validation:
    openAPIV3Schema:
      type: object
      properties:
        ruleType:
          type: string
        namespaces:
          type: array
          items:
            type: string
        selector:
          type: string

И веднага ще създадем простило правило — за търсене в namespace с име default всички ConfigMap с етикети вида copyrator: "true":

apiVersion: flant.com/v1
kind: CopyratorRule
metadata:
  name: main-rule
  labels:
    module: copyrator
ruleType: configmap
selector:
  copyrator: "true"
namespace: default

Готово! Сега трябва да получим информация за нашето правило. Веднага да уточня, че няма да пишем заявки към API Server на кластера. Ще използваме готова Python библиотека kubernetes-client:

import kubernetes
from contextlib import suppress


CRD_GROUP = 'flant.com'
CRD_VERSION = 'v1'
CRD_PLURAL = 'copyrators'


def load_crd(namespace, name):
    client = kubernetes.client.ApiClient()
    custom_api = kubernetes.client.CustomObjectsApi(client)

    with suppress(kubernetes.client.api_client.ApiException):
        crd = custom_api.get_namespaced_custom_object(
            CRD_GROUP,
            CRD_VERSION,
            namespace,
            CRD_PLURAL,
            name,
        )
    return {x: crd[x] for x in ('ruleType', 'selector', 'namespace')}

В резултат на работата на този код ще получим следното:

{'ruleType': 'configmap', 'selector': {'copyrator': 'true'}, 'namespace': ['default']}

Отлично: успяхме да получим правилото за оператора. И най-важното — направихме го по начина, по който се прави в Kubernetes.

Променливи на средата или флагове? Взимаме всичко!

Преминаваме към основната конфигурация на оператора. Има два основни подхода за конфигуриране на приложения:

1. да се използват параметри на командния ред;
2. да се използват променливи на средата.

Параметрите на командния ред позволяват да се четат настройки по-гъвкаво, с поддръжка и валидиране на типове данни. В стандартната библиотека на Python има модул argparser, който ще използваме. Подробности и примери за неговите възможности можете да намерите в официалната документация.

Ето как за нашия случай ще изглежда пример за настройка за четене на флаговете на командния ред:

   parser = ArgumentParser(
        description='Copyrator - copy оператор.',
        prog='copyrator'
    )
    parser.add_argument(
        '--namespace',
        type=str,
        default=getenv('NAMESPACE', 'default'),
        help='Namespace на оператора'
    )
    parser.add_argument(
        '--rule-name',
        type=str,
        default=getenv('RULE_NAME', 'main-rule'),
        help='Име на CRD'
    )
    args = parser.parse_args()

От друга страна, с помощта на променливи на средата в Kubernetes, можем лесно да пренесем служебна информация за pod вътре в контейнера. Например, информацията за namespace, в който е стартиран pod, можем да получим с помощта на следната конструкция:

env:
- name: NAMESPACE
  valueFrom:
     fieldRef:
         fieldPath: metadata.namespace 

Логиката на работа на оператора

За да разберем как да разделим методите за работа с ConfigMap и Secret, ще използваме специални карти. По този начин ще можем да разберем какви методи са ни необходими за следене и създаване на обекта:

LIST_TYPES_MAP = {
    'configmap': 'list_namespaced_config_map',
    'secret': 'list_namespaced_secret',
}

CREATE_TYPES_MAP = {
    'configmap': 'create_namespaced_config_map',
    'secret': 'create_namespaced_secret',
}

След това е необходимо да получим събития от API сървъра. Реализираме това по следния начин:

def handle(specs):
    kubernetes.config.load_incluster_config()
    v1 = kubernetes.client.CoreV1Api()

    # Получаваме метода за следене на обектите
    method = getattr(v1, LIST_TYPES_MAP[specs['ruleType']])
    func = partial(method, specs['namespace'])

    w = kubernetes.watch.Watch()
    for event in w.stream(func, _request_timeout=60):
        handle_event(v1, specs, event)

След получаване на събитието, преминаваме към основната логика на неговата обработка:

# Типы событий, на которые будем реагировать
ALLOWED_EVENT_TYPES = {'ADDED', 'UPDATED'}


def handle_event(v1, specs, event):
    if event['type'] not in ALLOWED_EVENT_TYPES:
        return

    object_ = event['object']
    labels = object_['metadata'].get('labels', {})

    # Ищем совпадения по selector'у
    for key, value in specs['selector'].items():
        if labels.get(key) != value:
            return
    # Получаем активные namespace'ы
    namespaces = map(
        lambda x: x.metadata.name,
        filter(
            lambda x: x.status.phase == 'Active',
            v1.list_namespace().items
        )
    )
    for namespace in namespaces:
        # Очищаем метаданные, устанавливаем namespace
        object_['metadata'] = {
            'labels': object_['metadata']['labels'],
            'namespace': namespace,
            'name': object_['metadata']['name'],
        }
        # Вызываем метод создания/обновления объекта
        methodcaller(
            CREATE_TYPES_MAP[specs['ruleType']],
            namespace,
            object_
        )(v1)

Основната логика е готова! Сега трябва да опаковаме всичко това в един Python пакет. Оформяме файла setup.py, пишем там метаинформация за проекта:

from sys import version_info

from setuptools import find_packages, setup

if version_info[:2] < (3, 5):
    raise RuntimeError(
        'Неподдържана версия на python %s.' % '.'.join(version_info)
    )


_NAME = 'copyrator'
setup(
    name=_NAME,
    version='0.0.1',
    packages=find_packages(),
    classifiers=[
        'Development Status :: 3 - Alpha',
        'Programming Language :: Python',
        'Programming Language :: Python :: 3',
        'Programming Language :: Python :: 3.5',
        'Programming Language :: Python :: 3.6',
        'Programming Language :: Python :: 3.7',
    ],
    author='Flant',
    author_email='maksim.nabokikh@flant.com',
    include_package_data=True,
    install_requires=[
        'kubernetes==9.0.0',
    ],
    entry_points={
        'console_scripts': [
            '{0} = {0}.cli:main'.format(_NAME),
        ]
    }
)

NB: Клиентът kubernetes за Python има собствено версиониране. Повече информация за съвместимостта на версиите на клиента и версиите на Kubernetes може да се намери в матрицата за съвместимост.

Сега нашият проект изглежда така:

copyrator
├── copyrator
│   ├── cli.py # Логика за работа с командния ред
│   ├── constant.py # Константи, които споменахме по-горе
│   ├── load_crd.py # Логика за зареждане на CRD
│   └── operator.py # Основна логика на работата на оператора
└── setup.py # Оформяне на пакета

Docker и Helm

Dockerfile ще бъде до безобразие прост: взимаме базовия образ python-alpine и инсталираме нашия пакет. Оптимизацията му отлагаме за по-добри времена:

FROM python:3.7.3-alpine3.9

ADD . /app

RUN pip3 install /app

ENTRYPOINT ["copyrator"]

Разгърнатето за оператора също е много просто:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Chart.Name }}
spec:
  selector:
    matchLabels:
      name: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        name: {{ .Chart.Name }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: privaterepo.yourcompany.com/copyrator:latest
        imagePullPolicy: Always
        args: ["--rule-type", "main-rule"]
        env:
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
      serviceAccountName: {{ .Chart.Name }}-acc

Накрая, е необходимо да създадете съответната роля за оператора с необходимите права:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ .Chart.Name }}-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: {{ .Chart.Name }}
rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "watch", "list"]
  - apiGroups: [""]
    resources: ["secrets", "configmaps"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: {{ .Chart.Name }}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: {{ .Chart.Name }}
subjects:
- kind: ServiceAccount
  name: {{ .Chart.Name }}

Резюме

Така, без страх, упрек и изучаване на Go, ние успяхме да създадем свой собствен оператор за Kubernetes на Python. Разбира се, той все още има какво да развива: в бъдеще ще може да обработва няколко правила, да работи в паралел, да наблюдава промените в своите CRD...

За да се запознаете по-добре с кода, ние сме го събрали в публичен репозиторий. Ако искате примери на по-сериозни оператори, реализирани с помощта на Python, можете да обърнете внимание на два оператора за разгръщане на mongodb (първи и втора част на цикъла). Накратко ще повторя:).

P.S. А ако ви мързи да се запознавате с събитията на Kubernetes или просто ви е по-нормално да използвате Bash — нашите колеги приготвиха готово решение под формата на shell-operator (ние обявиха го през април).

P.P.S.

Прочетете също в нашия блог:

• «Да подготвим Kubernetes кластер лесно и удобно? Анонсираме addon-operator»;
• «Представяме shell-operator: създаването на оператори за Kubernetes стана още по-лесно»;
• «Разширяваме и допълваме Kubernetes (преглед и видео на доклада)»;
• «Пишем оператор за Kubernetes на Golang»;
• «Оператори за Kubernetes: как да стартирате stateful приложения».

Източник: habr.com