Udostępnij za pośrednictwem

Hosting Kubernetes

  • Artykuł

Platforma Kubernetes jest popularnym wyborem do hostowania aplikacji Orleans. Orleans będzie działać na platformie Kubernetes bez określonej konfiguracji, jednak może również skorzystać z dodatkowej wiedzy, którą może zapewnić platforma hostingu.

Pakiet Microsoft.Orleans.Hosting.Kubernetes dodaje integrację do hostowania aplikacji Orleans w klastrze Kubernetes. Pakiet udostępnia metodę rozszerzenia UseKubernetesHosting, która wykonuje następujące akcje:

  • SiloOptions.SiloName jest ustawiony na nazwę pod.
  • EndpointOptions.AdvertisedIPAddress jest ustawiony na adres IP zasobnika.
  • EndpointOptions.SiloListeningEndpoint & EndpointOptions.GatewayListeningEndpoint są skonfigurowane do nasłuchiwania na dowolnym adresie, z SiloPort i GatewayPortskonfigurowanymi. Wartości portów domyślnych 11111 i 30000 są używane, jeśli żadne wartości nie są ustawiane jawnie).
  • ClusterOptions.ServiceId jest ustawiony na wartość etykiety zasobnika o nazwie orleans/serviceId.
  • ClusterOptions.ClusterId jest ustawiony na wartość etykiety zasobnika o nazwie orleans/clusterId.
  • Na początku procesu uruchamiania, silos będzie sondował Kubernetes, aby znaleźć te silosy, które nie mają odpowiednich zasobników, i zaznaczyć je jako martwe.
  • Ten sam proces będzie występować w czasie wykonywania dla podzestawu wszystkich silosów, aby usunąć obciążenie na serwerze interfejsu API platformy Kubernetes. Domyślnie 2 silosy w klastrze będą monitorować platformę Kubernetes.

Należy pamiętać, że pakiet hostingowy Kubernetes nie używa rozwiązania Kubernetes do klastrowania. W przypadku klastrowania wymagany jest oddzielny dostawca klastrowania. Aby uzyskać więcej informacji na temat konfigurowania klastrowania, zobacz dokumentację konfiguracji serwera Server.

Ta funkcja nakłada pewne wymagania dotyczące sposobu wdrażania usługi:

  • Nazwy silosów muszą być zgodne z nazwami podów.
  • Zasobniki muszą mieć etykiety orleans/serviceId i orleans/clusterId, które odpowiadają etykietom ServiceId i ClusterIdsilosu. Wyżej wymieniona metoda będzie propagować te etykiety do odpowiednich opcji w Orleans pochodzących ze zmiennych środowiskowych.
  • Zasobniki muszą mieć ustawione następujące zmienne środowiskowe: POD_NAME, POD_NAMESPACE, POD_IP, ORLEANS_SERVICE_ID, ORLEANS_CLUSTER_ID.

W poniższym przykładzie pokazano, jak poprawnie skonfigurować te etykiety i zmienne środowiskowe:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dictionary-app
  labels:
    orleans/serviceId: dictionary-app
spec:
  selector:
    matchLabels:
      orleans/serviceId: dictionary-app
  replicas: 3
  template:
    metadata:
      labels:
        # This label is used to identify the service to Orleans
        orleans/serviceId: dictionary-app

        # This label is used to identify an instance of a cluster to Orleans.
        # Typically, this will be the same value as the previous label, or any
        # fixed value.
        # In cases where you are not using rolling deployments (for example,
        # blue/green deployments),
        # this value can allow for distinct clusters which do not communicate
        # directly with each others,
        # but which still share the same storage and other resources.
        orleans/clusterId: dictionary-app
    spec:
      containers:
        - name: main
          image: my-registry.azurecr.io/my-image
          imagePullPolicy: Always
          ports:
          # Define the ports which Orleans uses
          - containerPort: 11111
          - containerPort: 30000
          env:
          # The Azure Storage connection string for clustering is injected as an
          # environment variable
          # It must be created separately using a command such as:
          # > kubectl create secret generic az-storage-acct `
          #     --from-file=key=./az-storage-acct.txt
          - name: STORAGE_CONNECTION_STRING
            valueFrom:
              secretKeyRef:
                name: az-storage-acct
                key: key
          # Configure settings to let Orleans know which cluster it belongs to
          # and which pod it is running in
          - name: ORLEANS_SERVICE_ID
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['orleans/serviceId']
          - name: ORLEANS_CLUSTER_ID
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['orleans/clusterId']
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          - name: DOTNET_SHUTDOWNTIMEOUTSECONDS
            value: "120"
          request:
            # Set resource requests
      terminationGracePeriodSeconds: 180
      imagePullSecrets:
        - name: my-image-pull-secret
  minReadySeconds: 60
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

W przypadku klastrów z włączoną kontrolą dostępu opartą na rolach, może być konieczne przyznanie wymaganego dostępu kontu usługi Kubernetes dla zasobników.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: orleans-hosting
rules:
- apiGroups: [ "" ]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: orleans-hosting-binding
subjects:
- kind: ServiceAccount
  name: default
  apiGroup: ''
roleRef:
  kind: Role
  name: orleans-hosting
  apiGroup: ''

Liveness, readiness i startup sondy

Platforma Kubernetes może sondować pody w celu określenia kondycji usługi. Aby uzyskać więcej informacji, zobacz Konfigurowanie sond gotowości, kondycji i uruchamiania w dokumentacji platformy Kubernetes.

Orleans używa protokołu członkostwa klastra do szybkiego wykrywania i odzyskiwania po awarii procesu lub sieci. Każdy węzeł monitoruje podzestaw innych węzłów, wysyłając okresowe sondy. Jeśli węzeł nie odpowie na wiele kolejnych sond z wielu innych węzłów, zostanie wymuszone usunięcie z klastra. Gdy węzeł, który uległ awarii, dowie się, że został usunięty, kończy działanie natychmiast. Platforma Kubernetes ponownie uruchomi zakończony proces i podejmie próbę ponownego dołączenia klastra.

Sondy platformy Kubernetes mogą pomóc określić, czy proces w podzie prawidłowo działa i nie jest zablokowany w stanie zombie. sondy nie sprawdzają łączności między podami ani nie wykonują żadnych kontroli funkcjonalności na poziomie aplikacji. Jeśli zasobnik nie odpowie na sondę liveness, platforma Kubernetes może ostatecznie zakończyć działanie tego zasobnika i zmienić jego harmonogram. Sondy kubernetes i sondy Orleanssą zatem uzupełniające.

Zalecanym podejściem jest skonfigurowanie sond gotowości na platformie Kubernetes, które wykonują proste tylko lokalne sprawdzanie, czy aplikacja działa zgodnie z oczekiwaniami. Te sondy służą do zakończenia procesu, jeśli występuje całkowite zamrożenie, na przykład z powodu błędu środowiska uruchomieniowego lub innego mało prawdopodobnego zdarzenia.

Przydziały zasobów

Platforma Kubernetes działa w połączeniu z systemem operacyjnym w celu zaimplementowania przydziałów zasobów. Umożliwia to wymuszanie rezerwacji pamięci i procesora i/lub limitów. W przypadku podstawowej aplikacji obsługującej ładowanie interakcyjne zalecamy nie implementowanie restrykcyjnych limitów, chyba że jest to konieczne. Ważne jest, aby pamiętać, że żądania i limity różnią się znacznie w ich znaczeniu i tam, gdzie są implementowane. Przed ustawieniem żądań lub limitów pośmiń czas na uzyskanie szczegółowego zrozumienia sposobu ich implementowania i wymuszania. Na przykład pamięć może nie być mierzona równomiernie między platformą Kubernetes, jądrem systemu Linux i systemem monitorowania. Limity CPU mogą nie być wymuszane w oczekiwany sposób.

Rozwiązywanie problemów

Zasobniki uległy awarii, zgłaszając problem z KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined

Pełny komunikat o wyjątku:

Unhandled exception. k8s.Exceptions.KubeConfigException: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined
at k8s.KubernetesClientConfiguration.InClusterConfig()
  • Sprawdź, czy zmienne środowiskowe KUBERNETES_SERVICE_HOST i KUBERNETES_SERVICE_PORT są ustawione wewnątrz twojego Podu. Możesz to sprawdzić, wykonując następujące polecenie kubectl exec -it <pod_name> /bin/bash -c env.
  • Upewnij się, że automountServiceAccountToken jest ustawione na "true" na platformie Kubernetes deployment.yaml. Aby uzyskać więcej informacji, zobacz Konfigurowanie kont usługowych dla Podów.