Dołączanie aplikacji (wersja zapoznawcza)

W tym artykule założono, że utworzono wolumin trwały (PV) i trwałe oświadczenie woluminu (PVC). Aby uzyskać informacje o tworzeniu pv, zobacz Tworzenie woluminu trwałego. Aby uzyskać informacje na temat tworzenia pcv, zobacz Tworzenie trwałego oświadczenia woluminu.

Dodawanie woluminów pamięci podręcznej do zasobników aio-dp-runner-worker-0

Te zasobniki są częścią stanowego zestawu. Nie można edytować zestawu stanowego w celu dodania punktów instalacji. Zamiast tego wykonaj następującą procedurę:

1. Dump the statefulSet to yaml:

   kubectl get statefulset -o yaml -n azure-iot-operations aio-dp-runner-worker > stateful_worker.yaml
   

2. Edytuj stanowy zestaw, aby uwzględnić nowe instalacji woluminów pamięci podręcznej w woluminach i woluminach:

   volumeMounts: 
   - mountPath: /etc/bluefin/config 
     name: config-volume 
     readOnly: true 
   - mountPath: /var/lib/bluefin/registry 
     name: nfs-volume 
   - mountPath: /var/lib/bluefin/local 
     name: runner-local
     ### Add the next 2 lines ###
   - mountPath: /mnt/esa 
     name: esa4 
   
   volumes: 
   - configMap: 
       defaultMode: 420 
       name: file-config 
     name: config-volume 
   - name: nfs-volume 
   persistentVolumeClaim: 
     claimName: nfs-provisioner
     ### Add the next 3 lines ### 
   - name: esa4 
     persistentVolumeClaim: 
       claimName: esa4
   

3. Usuń istniejący stanowyset:

   kubectl delete statefulset -n azure-iot-operations aio-dp-runner-worker
   

   Spowoduje to usunięcie wszystkich aio-dp-runner-worker-n zasobników. Jest to zdarzenie na poziomie awarii.

4. Utwórz nowy stanowy zestaw procesów roboczych aio-dp-runner-worker za pomocą instalacji woluminów pamięci podręcznej:

   kubectl apply -f stateful_worker.yaml -n azure-iot-operations
   

   Po uruchomieniu aio-dp-runner-worker-n zasobników dołączają one instalację do woluminów pamięci podręcznej. PCV powinien przekazać to w stanie.

5. Po ponownym skonfigurowaniu procesów roboczych przetwarzania danych w celu uzyskania dostępu do woluminów pamięci podręcznej należy ręcznie zaktualizować konfigurację potoku, aby użyć ścieżki lokalnej odpowiadającej zainstalowanej lokalizacji woluminu pamięci podręcznej na dyskach POD procesu roboczego.

   Aby zmodyfikować potok, użyj polecenia kubectl edit pipeline <name of your pipeline>. W tym potoku zastąp etap danych wyjściowych następującym kodem YAML:

   output:
     batch:
       path: .payload
       time: 60s
     description: An example file output stage
     displayName: Sample File output
     filePath: '{{{instanceId}}}/{{{pipelineId}}}/{{{partitionId}}}/{{{YYYY}}}/{{{MM}}}/{{{DD}}}/{{{HH}}}/{{{mm}}}/{{{fileNumber}}}'
     format:
       type: jsonStream
     rootDirectory: /mnt/esa
     type: output/file@v1
   

Konfigurowanie aplikacji natywnej kubernetes

1. Aby skonfigurować ogólny pojedynczy zasobnik (aplikacja natywna Kubernetes) względem oświadczenia trwałego woluminu (PVC), utwórz plik o nazwie o configPod.yaml następującej zawartości:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: example-static
     labels:
       app: example-static
     ### Uncomment the next line and add your namespace only if you are not using the default namespace (if you are using azure-iot-operations) as specified from Line 6 of your pvc.yaml. If you are not using the default namespace, all future kubectl commands require "-n YOUR_NAMESPACE" to be added to the end of your command.
     # namespace: YOUR_NAMESPACE
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: example-static
     template:
       metadata:
         labels:
           app: example-static
       spec:
         containers:
           - image: mcr.microsoft.com/cbl-mariner/base/core:2.0
             name: mariner
             command:
               - sleep
               - infinity
             volumeMounts:
               ### This name must match the 'volumes.name' attribute in the next section. ###
               - name: blob
                 ### This mountPath is where the PVC is attached to the pod's filesystem. ###
                 mountPath: "/mnt/blob"
         volumes:
           ### User-defined 'name' that's used to link the volumeMounts. This name must match 'volumeMounts.name' as specified in the previous section. ###
           - name: blob
             persistentVolumeClaim:
               ### This claimName must refer to the PVC resource 'name' as defined in the PVC config. This name must match what your PVC resource was actually named. ###
               claimName: YOUR_CLAIM_NAME_FROM_YOUR_PVC
   

   Uwaga

   Jeśli używasz własnej przestrzeni nazw, wszystkie przyszłe kubectl polecenia wymagają -n YOUR_NAMESPACE dołączenia do polecenia . Na przykład należy użyć kubectl get pods -n YOUR_NAMESPACE zamiast standardowego kubectl get pods.

2. Aby zastosować ten plik yaml, uruchom następujące polecenie:

   kubectl apply -f "configPod.yaml"
   

3. Użyj polecenia kubectl get pods , aby znaleźć nazwę zasobnika. Skopiuj tę nazwę, ponieważ jest ona potrzebna do następnego kroku.

4. Uruchom następujące polecenie i zastąp POD_NAME_HERE wartość skopiowaną z poprzedniego kroku:

   kubectl exec -it POD_NAME_HERE -- bash
   

5. Zmień katalogi na ścieżkę /mnt/blob instalacji, jak określono z pliku configPod.yaml.

6. Aby na przykład napisać plik, uruchom polecenie touch file.txt.

7. W witrynie Azure Portal przejdź do konta magazynu i znajdź kontener. Jest to ten sam kontener, który został określony w pv.yaml pliku. Po wybraniu kontenera zobaczysz file.txt wypełnione w kontenerze.

Następne kroki

Po wykonaniu tych kroków rozpocznij monitorowanie wdrożenia przy użyciu usług Azure Monitor i Kubernetes Monitoring lub monitorowania innych firm przy użyciu rozwiązań Prometheus i Grafana:

Monitorowanie innych firm