Kubernetes Operator på Python utan ramverk och SDK

Go är för närvarande en monopollanguage bland programmeringsspråk som människor väljer för att skriva operatorer för Kubernetes. Det finns objektiva skäl till detta, som:

1. Det finns ett kraftfullt ramverk för att utveckla operatorer i Go — Operator SDK.
2. Applikationer som har "förändrat spelreglerna" som Docker och Kubernetes är skrivna i Go. Att skriva sin egen operator i Go innebär att prata med ekosystemet på ett gemensamt språk.
3. Hög prestanda för applikationer i Go och enkla verktyg för att hantera concurrency "direkt ur lådan".

NB: Förresten har vi redan beskrivit hur man skriver sin egen operator i Go i en av våra översättningar av utländska författare. Men vad gör man om brist på tid eller helt enkelt brist på motivation hindrar dig från att studera Go? Artikeln ger ett exempel på hur man kan skriva en solid operator med ett av de mest populära språken som nästan varje DevOps-ingenjör känner till —

Möt: Kopiatorn — kopieringsoperatorn! Python.

För vårt exempel kommer vi att titta på utvecklingen av en enkel operator som är avsedd för att kopiera ConfigMap antingen vid skapandet av ett nytt namespace eller vid ändringar i en av två entiteter: ConfigMap och Secret. Ur ett praktiskt perspektiv kan operatorn vara användbar för massiv uppdatering av applikationskonfigurationer (genom att uppdatera ConfigMap) eller för att uppdatera känsliga data — till exempel nycklar för att arbeta med Docker Registry (vid tillägg av ett Secret i namespace).

vad som bör finnas hos en bra operator

Så, Interaktion med operatorn sker genom:

1. (hädanefter — CRD). ) för själva Operatorn kan konfigureras. För detta kommer vi att använda kommandoradsflaggor och miljövariabler.
2. Byggandet av Docker-container och Helm-diagram är utformat så att användarna enkelt kan (bokstavligen med ett kommando) installera operatorn i sitt Kubernetes-kluster.
3. CRD

För att operatorn ska veta vilka resurser och var den ska söka, behöver vi definiera en regel för den. Varje regel kommer att representeras som ett enda CRD-objekt. Vilka fält bör detta CRD ha?

, som vi kommer att söka efter (ConfigMap eller Secret).

1. ResurstyperListan över namespace
2. , där resurserna ska finnas.Väljare
3. , som vi kommer att söka efter resurser i namespace.Vi beskriver CRD:

Опишем 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

Och vi ska genast skapa en enkel regel — för att söka i namnområdet med namnet default alla ConfigMap med etiketter av typen copyrator: "true":

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

Klart! Nu måste vi på något sätt få information om vår regel. Jag vill genast påpeka att vi inte kommer att skriva förfrågningar till API-servern själva. Vi kommer att använda ett färdigt Python-bibliotek 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')}

Som ett resultat av denna kod får vi följande:

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

Perfekt: vi lyckades få regeln för operatören. Och det viktigaste — vi gjorde detta, så att säga, på Kubernetes sätt.

Miljövariabler eller flaggor? Vi tar allt!

Vi går vidare till huvudkonfigurationen för operatören. Det finns två grundläggande tillvägagångssätt för att konfigurera applikationer:

1. använda kommandoradsparametrar;
2. använda miljövariabler.

Kommandoradsparametrar gör det möjligt att läsa inställningar mer flexibelt, med stöd för och validering av datatyper. I Python-biblioteket finns en modul argparser, som vi kommer att använda. Detaljer och exempel på dess möjligheter finns tillgängliga i den officiella dokumentationen.

Så här ser ett exempel på inställning av läsning av kommandoradsflaggor ut för vårt fall:

   parser = ArgumentParser(
        description='Copyrator - kopiera operatör.',
        prog='copyrator'
    )
    parser.add_argument(
        '--namespace',
        type=str,
        default=getenv('NAMESPACE', 'default'),
        help='Operatörs Namnområde'
    )
    parser.add_argument(
        '--rule-name',
        type=str,
        default=getenv('RULE_NAME', 'main-rule'),
        help='CRD Namn'
    )
    args = parser.parse_args()

Å andra sidan kan vi enkelt föra in tjänsteinformation om podden i containern med hjälp av miljövariabler i Kubernetes. Till exempel kan vi få information om det namespace där podden körs med följande konstruktion:

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

Operatorns arbetslogik

För att förstå hur vi delar upp metoderna för att arbeta med ConfigMap och Secret, använder vi speciella kartor. Då kan vi förstå vilka metoder vi behöver för att övervaka och skapa objekt:

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

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

Därefter måste vi få händelser från API-servern. Vi implementerar detta på följande sätt:

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

    # Hämta metoden för övervakning av objekt
    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)

Efter att ha mottagit händelsen går vi vidare till den huvudsakliga logiken för att bearbeta den:

# Типы событий, на которые будем реагировать
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)

Den huvudsakliga logiken är klar! Nu behöver vi packa allt detta i ett enda Python-paket. Vi upprättar filen setup.py, skriver in metadata om projektet:

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='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: Klienten kubernetes för Python har sin egen versionering. Mer om kompatibiliteten mellan klientversioner och Kubernetes-versioner kan du läsa i kompatibilitetsmatrisen.

Just nu ser vårt projekt ut så här:

copyrator
├── copyrator
│   ├── cli.py # Logik för arbete med kommandoraden
│   ├── constant.py # Konstanter som vi nämnde tidigare
│   ├── load_crd.py # Logik för inläsning av CRD
│   └── operator.py # Huvudlogik för operatorn
└── setup.py # Utformning av paketet

Docker och Helm

Dockerfilen kommer att bli extremt enkel: vi tar basbilden python-alpine och installerar vårt paket. Dess optimering får vänta tills senare:

FROM python:3.7.3-alpine3.9

ADD . /app

RUN pip3 install /app

ENTRYPOINT ["copyrator"]

Distribution för operatören är också mycket enkel:

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

Slutligen måste vi skapa en motsvarande roll för operatören med nödvändiga rättigheter:

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 }}

Resultat

På så sätt, utan rädsla eller fördömelse och utan att studera Go, har vi lyckats skapa vår egen operatör för Kubernetes i Python. Självklart finns det mycket mer att utveckla: i framtiden kan den hantera flera regler, arbeta i flera trådar, och självständigt övervaka ändringar i sina CRD...

För att du ska kunna lära känna koden bättre har vi lagt den i ett offentligt arkiv. Om du är intresserad av exempel på mer seriösa operatörer som har implementerats med Python kan du titta på två operatörer för distribution av mongodb (första och andra).

P.S. Och om du inte orkar förstå dig på Kubernetes-händelser eller föredrar att använda Bash – våra kollegor har förberett en färdig lösning i form av shell-operator (vi tillkännagav gjorde det i april).

P.P.S.

Läs även i vår blogg:

• «Att förbereda en Kubernetes-kluster är enkelt och bekvämt? Vi presenterar addon-operatorn»;
• «Presenterar shell-operator: att skapa operatörer för Kubernetes har blivit ännu enklare»;
• «Utökar och kompletterar Kubernetes (översikt och videoföreläsning)»;
• «Skriver en operator för Kubernetes i Golang»;
• «Operatörer för Kubernetes: hur man kör stateful-applikationer».

Källa: habr.com