🥇Kubernetes ოპერატორი Python-ში ჩარჩოებისა და SDK-ის გარეშე

Go-ს ამჟამად აქვს მონოპოლია პროგრამირების ენებზე, რომლებსაც ადამიანები ირჩევენ Kubernetes-ისთვის განცხადებების დასაწერად. ამის ობიექტური მიზეზები არსებობს, მაგალითად:

არსებობს ძლიერი ჩარჩო Go-ში ოპერატორების განვითარებისთვის - ოპერატორი SDK.
თამაშის შემცვლელი აპლიკაციები, როგორიცაა Docker და Kubernetes, იწერება Go-ში. თქვენი ოპერატორის Go-ში ჩაწერა ნიშნავს ეკოსისტემასთან ერთსა და იმავე ენაზე ლაპარაკს.
Go აპლიკაციების მაღალი წარმადობა და მარტივი ინსტრუმენტები კონკურენტულთან მუშაობისთვის.

NB: სხვათა შორის, როგორ დაწეროთ საკუთარი განცხადება Go-ში, ჩვენ უკვე აღწერილი უცხოელი ავტორების ჩვენს ერთ-ერთ თარგმანში.

მაგრამ რა მოხდება, თუ Go-ის სწავლაში დროის ნაკლებობა ან, მარტივად რომ ვთქვათ, მოტივაცია შეგიშლით ხელს? სტატიაში მოცემულია მაგალითი იმისა, თუ როგორ შეგიძლიათ დაწეროთ კარგი განცხადება ერთ-ერთი ყველაზე პოპულარული ენის გამოყენებით, რომელიც თითქმის ყველა DevOps ინჟინერმა იცის - Python.

შეხვდით: ქსეროქსი - კოპირების ოპერატორი!

მაგალითად, განიხილეთ მარტივი განცხადების შემუშავება, რომელიც შექმნილია ConfigMap-ის კოპირებისთვის, ან როდესაც გამოჩნდება ახალი სახელთა სივრცე, ან როდესაც იცვლება ორი ერთეულიდან ერთი: ConfigMap და Secret. პრაქტიკული თვალსაზრისით, ოპერატორი შეიძლება იყოს გამოსადეგი აპლიკაციის კონფიგურაციების მასობრივი განახლებისთვის (ConfigMap-ის განახლებით) ან საიდუმლო მონაცემების განახლებისთვის - მაგალითად, Docker Registry-თან მუშაობის გასაღებები (საიდუმლოების დამატებისას სახელთა სივრცეში).

აქედან გამომდინარე, რა უნდა ჰქონდეს კარგ ოპერატორს:

ოპერატორთან ურთიერთქმედება ხორციელდება გამოყენებით მორგებული რესურსების განმარტებები (შემდგომში CRD).
ოპერატორის კონფიგურაცია შესაძლებელია. ამისათვის ჩვენ გამოვიყენებთ ბრძანების ხაზის დროშებს და გარემოს ცვლადებს.
Docker კონტეინერისა და Helm სქემის კონსტრუქცია შექმნილია ისე, რომ მომხმარებლებს შეუძლიათ ადვილად (სიტყვასიტყვით ერთი ბრძანებით) დააინსტალირონ ოპერატორი მათ Kubernetes კლასტერში.

CRD

იმისათვის, რომ ოპერატორმა იცოდეს, რა რესურსები მოძებნოს და სად ეძებოს, ჩვენ უნდა დავადგინოთ მისთვის წესი. თითოეული წესი წარმოდგენილი იქნება როგორც ერთი CRD ობიექტი. რა ველები უნდა ჰქონდეს ამ CRD-ს?

რესურსის ტიპი, რომელსაც ჩვენ ვეძებთ (ConfigMap ან Secret).
სახელთა სივრცის სია, რომელშიც უნდა იყოს განთავსებული რესურსები.
შერჩევა, რომლითაც მოვიძიებთ რესურსებს სახელთა სივრცეში.

მოდით აღვწეროთ 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 სერვერზე. ამისათვის ჩვენ გამოვიყენებთ მზა პითონის ბიბლიოთეკას 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']}

შესანიშნავია: ჩვენ მოვახერხეთ ოპერატორის წესის მიღება. და რაც მთავარია, ჩვენ გავაკეთეთ ის, რასაც კუბერნეტის გზა ჰქვია.

გარემოს ცვლადები თუ დროშები? ჩვენ ყველაფერს ვიღებთ!

მოდით გადავიდეთ მთავარი ოპერატორის კონფიგურაციაზე. აპლიკაციების კონფიგურაციის ორი ძირითადი მიდგომა არსებობს:

გამოიყენეთ ბრძანების ხაზის პარამეტრები;
გამოიყენეთ გარემოს ცვლადები.

ბრძანების ხაზის ვარიანტები საშუალებას გაძლევთ წაიკითხოთ პარამეტრები უფრო მოქნილად, მონაცემთა ტიპის მხარდაჭერით და დადასტურებით. პითონის სტანდარტულ ბიბლიოთეკას აქვს მოდული 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 მუშაობს შემდეგი კონსტრუქციით:

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: Python-ის kubernetes კლიენტს აქვს საკუთარი ვერსია. დამატებითი ინფორმაცია კლიენტის ვერსიებსა და Kubernetes ვერსიებს შორის თავსებადობის შესახებ შეგიძლიათ იხილოთ აქ თავსებადობის მატრიცები.

ახლა ჩვენი პროექტი ასე გამოიყურება:

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-ებში ცვლილებები...

კოდის უფრო დეტალურად დასათვალიერებლად, ჩვენ ჩავწერეთ იგი საჯარო საცავი. თუ გსურთ პითონის გამოყენებით დანერგილი უფრო სერიოზული ოპერატორების მაგალითები, შეგიძლიათ ყურადღება მიაქციოთ ორ ოპერატორს mongodb-ის განსათავსებლად (первый и მეორე).

PS და თუ ძალიან ეზარებათ Kubernetes-ის მოვლენებთან გამკლავება ან უბრალოდ უფრო მიჩვეული ხართ Bash-ის გამოყენებას, ჩვენმა კოლეგებმა მოამზადეს მზა გამოსავალი ფორმაში. ჭურვი-ოპერატორი (ჩვენ გამოაცხადა აპრილში).

PPS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

წყარო: www.habr.com

Kubernetes ოპერატორი Python-ში ჩარჩოებისა და SDK-ის გარეშე

შეხვდით: ქსეროქსი - კოპირების ოპერატორი!

CRD

გარემოს ცვლადები თუ დროშები? ჩვენ ყველაფერს ვიღებთ!

ოპერატორის ლოგიკა

დოკერი და ჰელმი

სულ

PPS

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება