KUDO – Operatory w Kubernetes

monotype.pl

KUDO – Operatory w Kubernetes

KUDO (Kubernetes Universal Declarative Operator) pozwala nam na deklaratywne podejście do budowania operatorów w Kubernetes. Operatory to rozszerzenia oprogramowania Kubernetes, które wykorzystują niestandardowe zasoby do zarządzania aplikacjami i ich komponentami. Kubernetes zawiera wbudowaną automatyzację do obsługi prostych obciążeń (ang. workloads), złożone scenariusze często wymagają operatora. Właśnie w tym zadaniu pomaga nam KUDO.

Budowanie operatorów w Kubernetes nie jest łatwe. Podczas gdy istniejące narzędzia i biblioteki, takie jak kubebuilder i Operator Framework oraz Kubernetes Control Loop, pomagają w niektórych aspektach, opracowanie operatora jest wciąż dość dużym przedsięwzięciem. To właśnie różni się podejście KUDO. Wykorzystuje uniwersalne i deklaratywne podejście (UD, ang. Universal and Declarative), nie wymaga żadnego kodu i znacznie przyspiesza rozwój operatorów. W skrócie KUDO wykonuje wszystkie „ciężkie zadania” w Kubernetes, pozwalając programistom skoncentrować się na zadaniu.

Dla kogo przeznaczone jest KUDO

KUDO został zbudowany, aby pomóc zespołom deweloperów / operatorów w zarządzaniu operacjami „nieprotypowymi” na Kubernetes, w tym usługami stanowymi poprzez zarządzanie operatorami, kiedy potrzebujemy wsparcia czegoś więcej, niż tylko pierwsze wdrożenie. KUDO został zbudowany w celu obsługi aktualizacji usług wraz z tworzeniem kopii zapasowych, odzyskiwaniem i potrzebą obserwowalności. W skrócie: użyłbyś KUDO, gdy kubectl apply -f . nie wystarcza do zarządzania cyklem życia aplikacji. Na przykład:

  • masz stanową usługę i musisz zautomatyzować określone przepływy pracy, takie jak tworzenie kopii zapasowych i przywracanie. Ewentualnie może być konieczne wykonanie dodatkowej logiki podczas wykonywania typowych zadań, takich jak konieczność ponownego wykonania pewnych zadań podczas skalowania w górę i w dół
  • masz aplikację złożoną z mikrousług, w której proces wdrażania ma wiele etapów szeregowych lub równoległych (np. generowanie dynamicznej konfiguracji lub oczekiwanie na zakończenie migracji) i musisz zautomatyzować powtarzalne zadania w całym cyklu życia aplikacji

Instalacja

$ brew tap kudobuilder/tap
$ brew install kudo-cli
$ kubectl kudo init

Więcej informacji można znaleźć w dokumentacji.

Przykładowa struktura operatora

Podstawowa struktura plików wygląda następująco:

.
├── operator.yaml
├── params.yaml
└── templates
    └── deployment.yaml

Gdzie:

  • operator.yaml – to główny plik YAML definiujący metadane oraz cały cykl życia operatora. Zadania i plany są zdefiniowane właśnie w tym pliku. W tym miejscu ustawiane są także metadane zawierające nazwę, wersję i osoby obsługujące kod operatora.
  • params.yaml – określa parametry operatora. Podczas instalacji parametry te można zastąpić, umożliwiając dostosowanie.
  • templates – Folder szablonów zawiera wszystkie obiekty Kubernetes z szablonami, które zostaną zastosowane w klastrze po instalacji na podstawie przepływu pracy zdefiniowanego w pliku operator.yaml.

Metadane, zadania oraz plany opisane są w pliku operator.yaml.

apiVersion: kudo.dev/v1beta1
kudoVersion: 0.10.1
name: example
operatorVersion: "0.1.0"
appVersion: "1.7.9"
kubernetesVersion: 1.13.0
maintainers:
- email: john@example.com
  name: John Doe
plans:
  deploy:
    phases:
    - name: deploy
      steps:
      - name: deploy
        tasks:
        - install
tasks:
- kind: Apply
  name: install
  spec:
    resources:
    - deployment.yaml

Parametry, którymi można sterować operatorem, zapisane są w pliku params.yaml:

apiVersion: kudo.dev/v1beta1
parameters: 
  - name: replicas
    description: Number of replicas that should be run
    default: 2
    

Szablon, który zostanie wykorzystany przez operatora do zbudowania obiektów w Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-deployment
spec:
  replicas: {{ .Params.replicas }}
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      name: application
  template:
    metadata:
      name: application
      labels:
        name: application
    spec:
      containers:
        - name: application
          image: gcr.io/kubernetes-e2e-test-images/echoserver:2.2
          ports:
            - containerPort: 8080
          resources:
            limits:
              memory: "32Mi"
              cpu: "250m"
            requests:
              memory: "32Mi"
              cpu: "125m"

Uruchomienie operatora

$ kubectl kudo install ./ --instance example    instance.kudo.dev/v1beta1/example created   

$ kubectl get pods,deployments.apps
NAME                                          READY   STATUS    RESTARTS   AGE
pod/application-deployment-55f7d7db56-hncl4   1/1     Running   0          22s
pod/application-deployment-55f7d7db56-n7ggc   1/1     Running   0          22s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/application-deployment   2/2     2            2           22s

Plan

$ kubectl kudo plan status --instance example 
Plan(s) for "example" in namespace "default":
.
└── example (Operator-Version: "example-0.1.0" Active-Plan: "deploy")
    └── Plan deploy ( strategy) [COMPLETE]
        └── Phase deploy ( strategy) [COMPLETE]
            └── Step deploy [COMPLETE]

Podsumowanie

Wdrażanie oprogramowania w Kubernetes ma wiele różnych postaci, a wiedza o tym, który z nich jest odpowiedni dla twojego przypadku użycia, jest ważna dla długoterminowego sukcesu. KUDO umożliwia nam rozbicie procesu wdrażania na wielokrotnie używalne etapy, dzięki którym mamy wysoką kontrolę nad przebiegiem wdrożenia, szczególnie ważną, kiedy pracujemy już na produkcji.

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *