Instalowanie i uruchamianie przepływów pracy Argo na platformie NSIS Magnum Kubernetes

Argo Workflows umożliwia uruchamianie złożonych przepływów zadań na Kubernetes. Może

zapewniają niestandardową logikę zarządzania zależnościami między zadaniami,

zarządzać sytuacjami, w których niektóre etapy przepływu pracy kończą się niepowodzeniem,

równoległe uruchamianie zadań w celu przetwarzania danych lub zadań uczenia maszynowego,

uruchamiać potoki CI/CD,

tworzenie przepływów pracy za pomocą skierowanych grafów acyklicznych (DAG) itp.

Argo stosuje zorientowane na mikrousługi, natywne dla kontenerów podejście, w którym każdy krok przepływu pracy działa jako kontener.

Co będziemy omawiać

Uwierzytelnianie w klastrze

Zastosuj wstępną konfigurację do PodSecurityPolicy.

Zainstaluj Argo Workflows w klastrze

Uruchamiaj przepływy pracy Argo z chmury

Uruchamiaj przepływy pracy Argo lokalnie

Uruchom przykładowy przepływ pracy z dwoma zadaniami

Wymagania wstępne

Nr 1 Konto: Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 kubectl wskazał na klaster Kubernetes: Jeśli tworzysz nowy klaster, na potrzeby tego artykułu nazwij go argo-cluster. Zobacz Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.

Uwierzytelnianie w klastrze

Uwierzytelnijmy się w argo-cluster. Uruchom z komputera lokalnego następujące polecenie, aby utworzyć plik konfiguracyjny w bieżącym katalogu roboczym:

openstack coe cluster config argo-cluster

Spowoduje to wyświetlenie polecenia ustawiającego zmienną środowiskową KUBECONFIG wskazującą lokalizację klastra, np.

export KUBECONFIG=/home/eouser/config

Uruchom to polecenie.

Zastosuj wstępną konfigurację

OpenStack Magnum domyślnie stosuje pewne ograniczenia bezpieczeństwa dla kapsuł działających w klastrze, zgodnie z praktyką „najmniejszych uprawnień”. Argo Workflows będzie wymagać dodatkowych uprawnień, aby działać poprawnie.

Najpierw utwórz dedykowaną przestrzeń nazw dla artefaktów Argo Workflows:

kubectl create namespace argo

Następnym krokiem jest utworzenie RoleBinding, który doda magnum:podsecuritypolicy:privileged ClusterRole. Utwórz plik argo-rolebinding.yaml z następującą zawartością:

argo-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: argo-rolebinding
  namespace: argo
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: magnum:podsecuritypolicy:privileged

i złożyć wniosek za pomocą:

kubectl apply -f argo-rolebinding.yaml

Instalacja przepływów pracy Argo

Aby wdrożyć Argo na klastrze, uruchom następujące polecenie:

kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.4.4/install.yaml

Dostępny jest również Argo CLI do uruchamiania zadań z wiersza poleceń. Jego instalacja wykracza poza zakres tego artykułu.

Uruchamiaj przepływy pracy Argo z chmury

Zwykle konieczne jest uwierzytelnienie na serwerze za pomocą loginu interfejsu użytkownika. Tutaj zamierzamy przełączyć tryb uwierzytelniania, stosując następującą poprawkę do wdrożenia. (W przypadku produkcji może być konieczne włączenie odpowiedniego mechanizmu uwierzytelniania). Prześlij następujące polecenie:

kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

Usługa Argo domyślnie udostępniana jest jako usługa Kubernetes typu ClusterIp, co można zweryfikować wpisując poniższe polecenie:

kubectl get services -n argo
NAME          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)          AGE
argo-server   ClusterIP   10.254.132.118      <none>         2746:31294/TCP   1d

Aby udostępnić tę usługę w Internecie, należy przekonwertować typ ClusterIP na LoadBalancer, łatając usługę następującym poleceniem:

kubectl -n argo patch service argo-server -p '{"spec": {"type": "LoadBalancer"}}'

Po kilku minutach zostanie wygenerowany LoadBalancer w chmurze, a zewnętrzny adres IP zostanie wypełniony:

kubectl get services -n argo
NAME          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)          AGE
argo-server   LoadBalancer   10.254.132.118   64.225.134.153   2746:31294/TCP   1d

Adres IP w naszym przypadku to 64.225.134.153.

Argo jest domyślnie obsługiwane przez HTTPS z samopodpisanym certyfikatem, na porcie 2746. Tak więc, wpisując https://<your-service-external-ip>:2746 powinieneś być w stanie uzyskać dostęp do usługi:

Uruchom przykładowy przepływ pracy z dwoma zadaniami

Aby uruchomić przykładowy przepływ pracy, należy najpierw zamknąć początkowe wyskakujące okienka w interfejsie użytkownika. Następnie przejdź do ikony „Workflows” w lewym górnym rogu i kliknij ją, po czym może być konieczne naciśnięcie przycisku „Continue” w kolejnym wyskakującym okienku.

Następnym krokiem jest kliknięcie przycisku „Submit New Workflow” w lewej górnej części ekranu, co spowoduje wyświetlenie ekranu podobnego do poniższego:

Chociaż można uruchomić przepływ pracy dostarczony przez Argo jako początek, zapewniamy tutaj alternatywny minimalny przykład. Aby go uruchomić, należy utworzyć plik, który możemy nazwać argo-article.yaml i skopiować w miejsce przykładowego manifestu YAML:

argo-article.yaml

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: workflow-
  namespace: argo
spec:
  entrypoint: my-workflow
  serviceAccountName: argo
  templates:
  - name: my-workflow
    dag:
      tasks:
      - name: downloader
        template: downloader-tmpl
      - name: processor
        template: processor-tmpl
        dependencies: [downloader]
  - name: downloader-tmpl
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        print("Files downloaded")
  - name: processor-tmpl
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        print("Files processed")

Ta próbka makietuje przepływ pracy z 2 zadaniami. Najpierw uruchamiane jest zadanie downloadera, a po jego zakończeniu zadanie procesora wykonuje swoją część. Kilka najważniejszych informacji na temat tej definicji przepływu pracy:

Oba zadania działają jako kontenery. Tak więc dla każdego zadania kontener python:alpine3.6 jest najpierw pobierany z rejestru DockerHub. Następnie kontener ten wykonuje prostą pracę polegającą na wydrukowaniu tekstu. W produkcyjnym przepływie pracy, zamiast używać skryptu, kod z logiką zostanie pobrany z rejestru kontenerów jako niestandardowy obraz Docker.

Kolejność wykonywania skryptu jest tutaj definiowana przy użyciu DAG (Directed Acyclic Graph). Pozwala to na określenie zależności zadań w sekcji zależności. W naszym przypadku zależność jest umieszczona na Processorze, więc rozpocznie się dopiero po zakończeniu Downloadera. Gdybyśmy pominęli zależności od Processora, działałby on równolegle z Downloaderem.

Każde zadanie w tej sekwencji jest uruchamiane jako kapsuła Kubernetes. Po wykonaniu zadania kapsuła kończy działanie, co zwalnia zasoby w klastrze.

Możesz uruchomić tę próbkę, klikając przycisk „+Create”. Po zakończeniu przepływu pracy powinieneś zobaczyć wynik, jak poniżej:

Ponadto po kliknięciu każdego kroku po prawej stronie ekranu wyświetlanych jest więcej informacji. Np. klikając na krok Procesor, możemy zobaczyć jego logi w prawej dolnej części ekranu.

Wyniki pokazują, że rzeczywiście w kontenerze został wydrukowany komunikat „Pliki przetworzone”:

Co robić dalej

W przypadku produkcji należy rozważyć alternatywny mechanizm uwierzytelniania i zastąpienie samodzielnie podpisanych certyfikatów HTTPS certyfikatami wygenerowanymi przez urząd certyfikacji.