Kubernetes-hosting

Kubernetes is een populaire keuze voor het hosten van Orleans toepassingen. Orleans wordt uitgevoerd in Kubernetes zonder specifieke configuratie; het kan echter ook profiteren van extra kennis die het hostingplatform biedt.

Het Microsoft.Orleans.Hosting.Kubernetes-pakket voegt integratie toe voor het hosten van een Orleans toepassing in een Kubernetes-cluster. Het pakket biedt een extensiemethode, UseKubernetesHostingwaarmee de volgende acties worden uitgevoerd:

Hiermee stelt u SiloOptions.SiloName in als de podnaam.
Stelt EndpointOptions.AdvertisedIPAddress in op het IP-adres van de pod.
Configureert EndpointOptions.SiloListeningEndpoint en EndpointOptions.GatewayListeningEndpoint om op elk adres te luisteren, met de geconfigureerde SiloPort en GatewayPort. Standaardpoortwaarden van 11111 en 30000 worden gebruikt als waarden niet expliciet zijn ingesteld.
Hiermee stelt u ClusterOptions.ServiceId in op de waarde van het podlabel met de naam orleans/serviceId.
Hiermee stelt u ClusterOptions.ClusterId in op de waarde van het podlabel met de naam orleans/clusterId.
Vroeg in het opstartproces test de silo Kubernetes om te vinden welke silo's geen bijbehorende pods hebben en markeert deze silo's als dood.
Hetzelfde proces vindt tijdens runtime plaats voor een subset van alle silo's om de belasting op de API-server van Kubernetes te verminderen. Standaard houden twee silo's in het cluster Kubernetes in de gaten.

Houd er rekening mee dat het Kubernetes-hostingpakket geen Kubernetes gebruikt voor clustering. Er is nog steeds een afzonderlijke clusterprovider nodig. Zie de documentatie Server-configuratie voor meer informatie over het configureren van clustering.

Implementeren in Kubernetes met .NET Aspire

.NET Aspire vereenvoudigt de implementatie van Kubernetes door automatisch Kubernetes-manifesten te genereren vanuit uw AppHost-configuratie. In plaats van YAML-bestanden handmatig te schrijven, kan Aspire de benodigde implementatie-, service- en configuratiebronnen produceren op basis van de afhankelijkheidsgrafiek van uw toepassing.

De Kubernetes-hostingintegratie toevoegen

Installeer eerst het NuGet-pakket Aspire.Hosting.Kubernetes in uw AppHost-project:

dotnet add package Aspire.Hosting.Kubernetes

Voeg vervolgens een Kubernetes-omgeving toe aan uw AppHost:

var builder = DistributedApplication.CreateBuilder(args);

// Add the Kubernetes environment
var k8s = builder.AddKubernetesEnvironment("k8s");

// Add your Orleans silo project
var silo = builder.AddProject<Projects.MySilo>("silo");

builder.Build().Run();

U kunt desgewenst de Kubernetes-omgevingseigenschappen aanpassen:

builder.AddKubernetesEnvironment("k8s")
    .WithProperties(k8s =>
    {
        k8s.HelmChartName = "my-orleans-app";
    });

Kubernetes-manifesten genereren

Gebruik de Aspire CLI om Kubernetes-manifesten te genereren vanuit uw Aspire-project:

aspire publish -o ./k8s-manifests

Hiermee wordt een volledige set Kubernetes YAML-bestanden gegenereerd in de opgegeven uitvoermap, waaronder:

Deployments of StatefulSets voor elke service in uw AppHost
Services voor netwerkconnectiviteit
ConfigMaps en Secrets voor configuratie
Helm-grafieken voor eenvoudiger implementatiebeheer
PersistentVolumes en PersistentVolumeClaims voor opslagbronnen

Implementeren in uw cluster

Nadat u de manifesten hebt gegenereerd, implementeert u deze met behulp van kubectl of Helm:

# Using kubectl
kubectl apply -f ./k8s-manifests

# Or using Helm (if Helm charts were generated)
helm install my-orleans-app ./k8s-manifests/charts/my-orleans-app

Voordelen van door Aspire gegenereerde manifesten

Consistente configuratie: omgevingsvariabelen, poorten en resourceverwijzingen worden automatisch gesynchroniseerd
Afhankelijkheidsbeheer: Services worden geconfigureerd met de juiste verbindingsreeksen en serviceverwijzingen
Orleans-aware: De Orleans hostingintegratie zorgt ervoor dat de juiste siloconfiguratie is opgenomen
Helm-ondersteuning: Gegenereerde Helm-grafieken maken geparameteriseerde implementaties in omgevingen mogelijk

Aanbeveling

Bekijk en pas de gegenereerde manifesten indien nodig aan voor productie-implementaties. Gebruik externe parameters om omgevingsspecifieke waarden te configureren.

Zie de documentatie over De Integratie van Aspire Kubernetes voor gedetailleerde informatie over de Integratie van Aspire Kubernetes.

Zie .NET Aspire-integratie voor meer informatie over het Orleans configureren met .NET AspireOrleans.

Handmatige Kubernetes-configuratie

Deze functionaliteit legt enkele vereisten op voor de implementatie van de service:

Silonamen moeten overeenkomen met podnamen.
Pods moeten de orleans/serviceId en orleans/clusterId labels hebben die overeenkomen met de ServiceId en ClusterId van de silo. De UseKubernetesHosting methode geeft deze labels door aan de bijbehorende Orleans opties van omgevingsvariabelen.
Pods moeten de volgende omgevingsvariabelen hebben ingesteld: POD_NAME, POD_NAMESPACE, POD_IP, ORLEANS_SERVICE_ID, ORLEANS_CLUSTER_ID.

In het volgende voorbeeld ziet u hoe u deze labels en omgevingsvariabelen correct configureert:

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 identifies the service to Orleans
        orleans/serviceId: dictionary-app

        # This label identifies an instance of a cluster to Orleans.
        # Typically, this is the same value as the previous label, or any
        # fixed value.
        # In cases where you don't use rolling deployments (for example,
        # blue/green deployments),
        # this value can allow for distinct clusters that don't communicate
        # directly with each other,
        # but 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 Orleans uses
          - containerPort: 11111
          - containerPort: 30000
          env:
          # The Azure Storage connection string for clustering is injected as an
          # environment variable.
          # You must create it 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's 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

Voor clusters met RBAC-functionaliteit kan het verlenen van de vereiste toegang tot het Kubernetes-serviceaccount voor de pods ook nodig zijn:

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, gereedheid en opstarttests

Kubernetes kan pods testen om de servicestatus te bepalen. Zie Liveness, Readiness and Startup Probes configureren in de Kubernetes-documentatie voor meer informatie.

Orleans gebruikt een clusterlidmaatschapsprotocol om onmiddellijk proces- of netwerkfouten te detecteren en te herstellen. Elk knooppunt bewaakt een subset van andere knooppunten en verzendt periodieke tests. Als een knooppunt niet reageert op meerdere opeenvolgende tests van meerdere andere knooppunten, wordt het knooppunt door het cluster geforceerd verwijderd. Zodra een mislukt knooppunt weet dat het wordt verwijderd, wordt het onmiddellijk beëindigd. Kubernetes start het beëindigde proces opnieuw op, waarna het probeert zich weer bij het cluster aan te sluiten.

Kubernetes-tests helpen bepalen of een proces in een pod wordt uitgevoerd en niet vastzit in een zombiestatus. Deze tests controleren de connectiviteit of reactiesnelheid tussen pods niet en voeren ook geen functionaliteitscontroles op toepassingsniveau uit. Als een pod niet reageert op een livenessprobe, kan Kubernetes die pod uiteindelijk beëindigen en opnieuw inplannen. Kubernetes-tests en Orleans -tests zijn daarom complementair.

De aanbevolen aanpak is het configureren van Liveness Probes in Kubernetes die een eenvoudige, lokale controle uitvoeren dat de toepassing naar behoren wordt uitgevoerd. Deze sondes dienen om het proces te beëindigen als er bijvoorbeeld een volledige bevriezing optreedt vanwege een runtimefout of een andere onwaarschijnlijke gebeurtenis.

Resourcequota

Kubernetes werkt met het besturingssysteem om resourcequota te implementeren. Hierdoor kunnen CPU- en geheugenreserveringen en/of limieten worden afgedwongen. Voor een primaire toepassing die interactieve belasting biedt, wordt het implementeren van beperkende limieten niet aanbevolen, tenzij dat nodig is. Het is belangrijk om te weten dat aanvragen en limieten aanzienlijk verschillen in betekenis en implementatielocatie. Voordat u aanvragen of limieten instelt, moet u een gedetailleerd inzicht krijgen in hoe ze worden geïmplementeerd en afgedwongen. Het is bijvoorbeeld mogelijk dat het geheugen niet uniform wordt gemeten tussen Kubernetes, de Linux-kernel en het bewakingssysteem. CPU-quota worden mogelijk niet afgedwongen zoals verwacht.

Probleemoplossing

Pods storten neer en klagen over `KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined`.

Volledige uitzonderingsbericht:

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()

Controleer of de omgevingsvariabelen KUBERNETES_SERVICE_HOST en KUBERNETES_SERVICE_PORT zijn ingesteld in de Pod. Controleer door de opdracht kubectl exec -it <pod_name> /bin/bash -c envuit te voeren.
Zorg ervoor dat automountServiceAccountToken is ingesteld op true in de Kubernetes deployment.yaml. Zie Serviceaccounts configureren voor podsvoor meer informatie.

Feedback

Is deze pagina nuttig?

Last updated on 2026-01-23