Hosting platformy Kubernetes

  • Artykuł

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

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

  • SiloOptions.SiloName jest ustawiona na nazwę zasobnika.
  • EndpointOptions.AdvertisedIPAddress jest ustawiona na adres IP zasobnika.
  • EndpointOptions.SiloListeningEndpoint I EndpointOptions.GatewayListeningEndpoint są skonfigurowane do nasłuchiwania na dowolnym adresie ze skonfigurowanymi SiloPort elementami i GatewayPort. Wartości portów domyślnych 11111 i 30000 są używane, jeśli żadne wartości nie są ustawiane jawnie).
  • ClusterOptions.ServiceId jest ustawiona na wartość etykiety zasobnika o nazwie orleans/serviceId.
  • ClusterOptions.ClusterId jest ustawiona na wartość etykiety zasobnika o nazwie orleans/clusterId.
  • Na początku procesu uruchamiania silos będzie sondować kubernetes, aby znaleźć, które silosy nie mają odpowiednich zasobników i oznaczyć te silosy 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ą oglądać 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.

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

  • Nazwy silosów muszą być zgodne z nazwami zasobników.
  • Zasobniki muszą mieć etykietę i orleans/clusterId odpowiadającą orleans/serviceId silosom ServiceId i ClusterId. Wyżej wymieniona metoda będzie propagować te etykiety do odpowiednich opcji z Orleans zmiennych środowiskowych.
  • Zasobniki muszą mieć następujące zmienne środowiskowe: POD_NAME, , POD_NAMESPACEPOD_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 obsługą kontroli dostępu opartej na rolach konto usługi Kubernetes dla zasobników może również wymagać udzielenia wymaganego dostępu:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: orleans-hosting
rules:
- apiGroups: [ "" ]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
---
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 probes

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

Orleans używa protokołu członkostwa w klastrze 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, zostanie natychmiast zakończony. 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 zasobniku jest wykonywany i nie jest zablokowany w stanie zombie. sondy nie weryfikują łączności między zasobnikami ani nie wykonują żadnych testów 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 i Orleanssondy kubernetes są zatem uzupełnieniem.

Zalecaną metodą jest skonfigurowanie sond liveness na platformie Kubernetes, które wykonują proste 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.

Limity przydziałów zasobów

Platforma Kubernetes działa w połączeniu z systemem operacyjnym w celu zaimplementowania przydziałów zasobów. Umożliwia to wymuszanie rezerwacji procesora CPU i pamięci 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 przydziału procesora CPU mogą nie być wymuszane w oczekiwany sposób.

Rozwiązywanie problemów

Zasobniki uległy awarii, narzekając, że 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 KUBERNETES_SERVICE_HOST zmienne środowiskowe i KUBERNETES_SERVICE_PORT są ustawiane wewnątrz zasobnika. Możesz to sprawdzić, wykonując następujące polecenie kubectl exec -it <pod_name> /bin/bash -c env.
  • Upewnij się, że automountServiceAccountToken ustawiono wartość true na platformie Kubernetes deployment.yaml. Aby uzyskać więcej informacji, zobacz Konfigurowanie kont usług dla zasobników