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

Go во моментов има монопол на програмските јазици што луѓето избираат да пишуваат изјави за Kubernetes. Постојат објективни причини за ова, како што се:

1. Постои моќна рамка за развој на оператори во Go - Оператор SDK.
2. Апликациите што менуваат игри како Docker и Kubernetes се напишани во Go. Да го напишете вашиот оператор во Go значи да зборувате ист јазик со екосистемот.
3. Високи перформанси на Go апликациите и едноставни алатки за работа со истовременост надвор од кутијата.

NB: Патем, како да напишете сопствена изјава во Go, ние веќе опишано во еден од нашите преводи од странски автори.

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

Запознајте: Копир - оператор за копирање!

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

Значи, што треба да има добар оператор:

1. Интеракцијата со операторот се врши со користење Прилагодени дефиниции за ресурси (во натамошниот текст CRD).
2. Операторот може да се конфигурира. За да го направите ова, ќе користиме знаменца на командната линија и променливи на околината.
3. Изградбата на графиконот за контејнер и Хелм Докер е дизајнирана така што корисниците можат лесно (буквално со една команда) да го инсталираат операторот во нивниот кластер 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']}

Одлично: успеавме да добиеме правило за операторот. И што е најважно, го направивме она што се нарекува Кубернетски начин.

Променливи на животната средина или знаменца? Ние земаме сè!

Ајде да преминеме на конфигурацијата на главниот оператор. Постојат два основни пристапи за конфигурирање на апликации:

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

Опциите на командната линија ви овозможуваат пофлексибилно да ги читате поставките, со поддршка и валидација за типови на податоци. Стандардната библиотека на Пајтон има модул 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, можете лесно да пренесете информации за услугата за подлогата внатре во контејнерот. На пример, можеме да добиеме информации за именскиот простор во кој работи подлогата со следнава конструкција:

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)

Главната логика е подготвена! Сега треба да го спакуваме сето ова во еден Пајтон пакет. Ја подготвуваме датотеката 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 има своја верзија. Повеќе информации за компатибилноста помеѓу верзиите на клиентот и верзиите на Кубернетес може да најдете во матрици за компатибилност.

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

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

Докер и Хелм

Dockerfile ќе биде неверојатно едноставна: земете ја основната слика од питон-алпски и инсталирајте го нашиот пакет. Да ја одложиме нејзината оптимизација до подобри времиња:

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

П.С. И ако сте премногу мрзливи да се занимавате со настани на Кубернет или едноставно сте повеќе навикнати да користите Bash, нашите колеги подготвија готово решение во форма школка-оператор (Ние објавија тоа во април).

PPS

Прочитајте и на нашиот блог:

• «Дали е лесно и погодно да се подготви кластер Кубернетес? Објавуваме додаток-оператор";
• «Воведување на школка-оператор: создавањето оператори за Kubernetes штотуку стана полесно";
• «Проширување и дополнување на Kubernetes (преглед и видео извештај)";
• «Пишување оператор за Кубернетес во Голанг";
• «Оператори за Kubernetes: како да стартувате државни апликации".

Извор: www.habr.com