Оператор Kubernetes в Python без рамки и SDK

В момента Go има монопол върху езиците за програмиране, които хората избират да пишат отчети за Kubernetes. За това има обективни причини като:

1. Има мощна рамка за разработване на оператори в Go - Оператор SDK.
2. Променящи играта приложения като Docker и Kubernetes са написани на Go. Написването на вашия оператор в Go означава да говорите на същия език с екосистемата.
3. Висока производителност на Go приложенията и прости инструменти за работа с паралелност от кутията.

NB: Между другото, как да напишете свое собствено изявление в Go, we вече описано в един от нашите преводи на чужди автори.

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

Запознайте се с: Copier - копирен оператор!

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

По този начин, какво трябва да има един добър оператор:

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

CRD

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

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

Нека опишем 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

И ние ще го създадем веднага просто правило — за търсене в пространството на имената с името 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 сървъра на клъстера. За целта ще използваме готова библиотека на Python kubernetes-клиент:

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 operator.',
        prog='copyrator'
    )
    parser.add_argument(
        '--namespace',
        type=str,
        default=getenv('NAMESPACE', 'default'),
        help='Operator Namespace'
    )
    parser.add_argument(
        '--rule-name',
        type=str,
        default=getenv('RULE_NAME', 'main-rule'),
        help='CRD Name'
    )
    args = parser.parse_args()

От друга страна, като използвате променливи на средата в Kubernetes, можете лесно да прехвърлите служебна информация за pod вътре в контейнера. Например, можем да получим информация за пространството от имена, в което се изпълнява 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(
        'Unsupported python version %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='[email protected]',
    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 # Оформление пакета

Докер и Хелм

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 (первый и втори).

PS И ако ви мързи да се занимавате със събития на Kubernetes или просто сте по-свикнали да използвате Bash, нашите колеги са подготвили готово решение във формата shell-оператор (Ние съобщи през април).

PPS

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

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

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