Kubernetes barındırma

Kubernetes, Orleans uygulamaları barındırmak için popüler bir seçimdir. Orleans Kubernetes'te belirli bir yapılandırma olmadan çalışır; ancak barındırma platformunun sağladığı ek bilgilerden de yararlanabilir.

Microsoft.Orleans.Hosting.Kubernetes paketi, kubernetes kümesinde bir Orleans uygulaması barındırmak için tümleştirme ekler. Paket, UseKubernetesHostingaşağıdaki eylemleri gerçekleştiren bir uzantı yöntemi sağlar:

Kubernetes barındırma paketinin kümeleme için Kubernetes kullanmadığını unutmayın. Ayrı bir kümeleme sağlayıcısı hala gereklidir. Kümeleme yapılandırma hakkında daha fazla bilgi için Sunucu yapılandırması belgelerine bakın.

ile Kubernetes'e dağıtma Aspire

Aspire Otomatik olarak AppHost yapılandırmanızdan Kubernetes bildirimleri oluşturarak Kubernetes dağıtımını basitleştirir. YAML dosyalarını el ile yazmak yerine, Aspire uygulamanızın bağımlılık grafiğine göre gerekli dağıtım, hizmet ve yapılandırma kaynaklarını üretebilir.

Kubernetes barındırma tümleştirmesini ekleme

İlk olarak, yükleyin Aspire. AppHost projenizde Hosting.Kubernetes NuGet paketi:

dotnet add package Aspire.Hosting.Kubernetes

Ardından AppHost'unuza bir Kubernetes ortamı ekleyin:

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

İsteğe bağlı olarak Kubernetes ortam özelliklerini özelleştirebilirsiniz:

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

Kubernetes bildirimleri oluşturma

Aspire Projenizden Aspire Kubernetes bildirimleri oluşturmak için CLI'yi kullanın:

aspire publish -o ./k8s-manifests

Bu, belirtilen çıkış dizininde aşağıdakiler dahil olmak üzere eksiksiz bir Kubernetes YAML dosyaları kümesi oluşturur:

  • AppHost'unuzda her hizmet için dağıtımlar veya StatefulSets
  • Ağ bağlantısı hizmetleri
  • Yapılandırma için ConfigMap'ler ve Gizli Anahtarlar
  • Daha kolay dağıtım yönetimi için Helm grafikleri
  • Depolama kaynakları için PersistentVolumes ve PersistentVolumeClaims

Kümenize dağıtın

Bildirimleri oluşturduktan sonra, onları kubectl veya Helm kullanarak dağıtın.

# 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

Aspire tarafından oluşturulan bildirimlerin avantajları

  • Tutarlı yapılandırma: Ortam değişkenleri, bağlantı noktaları ve kaynak başvuruları otomatik olarak eşitlenir.
  • Bağımlılık yönetimi: Hizmetler doğru bağlantı dizeleri ve hizmet başvuruları ile yapılandırılır.
  • Orleans-aware: Barındırma Orleans tümleştirmesi uygun silo yapılandırmasının dahil edilmesini sağlar.
  • Helm desteği: Oluşturulan Helm grafikleri, ortamlar arasında parametreli dağıtımlara izin verir.

Tip

Üretim dağıtımları için, oluşturulan bildirimleri gerektiği gibi gözden geçirin ve özelleştirin. Ortama özgü değerleri yapılandırmak için dış parametreleri kullanın.

Kubernetes tümleştirmesi Aspire hakkında ayrıntılı bilgi için Kubernetes tümleştirme belgelerine bakınAspire.

Orleans öğesini Aspire ile yapılandırma hakkında daha fazla bilgi için AspireOrleans tümleştirmesine bkz.

El ile Kubernetes yapılandırması

Bu işlevsellik, hizmet dağıtımına bazı gereksinimler uygular:

  • Silo adları pod adlarla eşleşmelidir.
  • Podların, silo orleans/serviceId ve orleans/clusterId etiketlerine karşılık gelen ServiceId ve ClusterId etiketleri olmalıdır. UseKubernetesHosting yöntemi, bu etiketleri ortam değişkenlerinden alarak ilgili Orleans seçeneklere yayar.
  • Podlarda şu ortam değişkenleri ayarlanmalıdır: POD_NAME, POD_NAMESPACE, POD_IP, ORLEANS_SERVICE_ID, ORLEANS_CLUSTER_ID.

Aşağıdaki örnekte bu etiketlerin ve ortam değişkenlerinin doğru yapılandırılması gösterilmektedir:

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

RBAC özellikli kümeler için podlar için Kubernetes hizmet hesabına gerekli erişimin verilmesi de gerekebilir:

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: ''

Canlılık, hazırlık ve çalıştırma yoklamaları

Kubernetes, hizmet durumunu belirlemek için podları yoklayabilir. Daha fazla bilgi için Kubernetes belgelerindeki Canlılık, Hazırlık ve Başlangıç Yoklamalarını Yapılandırma bölümüne bakın.

Orleans işlem veya ağ hatalarını hemen algılamak ve kurtarmak için bir küme üyeliği protokolü kullanır. Her düğüm, düzenli aralıklarla yoklamalar göndererek diğer düğümlerin bir alt kümesini izler. Bir düğüm, birçok diğer düğümden gelen ardışık birçok yoklamaya yanıt vermezse, küme düğümü zorla kaldırır. Başarısız bir düğüm kaldırıldığını öğrendiği anda hemen sonlanır. Kubernetes sonlandırılan işlemi yeniden başlatır ve ardından kümeye yeniden katılmayı dener.

Kubernetes yoklamaları, poddaki bir işlemin yürütülüp yürütülmediğinin ve zombi durumunda takılmadığının belirlenmesine yardımcı olur. Bu yoklamalar podlar arası bağlantıyı veya yanıt hızını doğrulamaz ve uygulama düzeyinde işlevsellik denetimleri gerçekleştirmez. Bir pod canlılık yoklamasına yanıt vermezse Kubernetes sonunda bu podu sonlandırabilir ve yeniden zamanlayabilir. Bu nedenle Kubernetes yoklamaları ve Orleans yoklamaları tamamlayıcı niteliktedir.

Önerilen yaklaşım, Kubernetes'te uygulamanın amaçlandığı gibi çalıştığını doğrulayan basit, yalnızca yerel bir kontrol yapan Liveness Probe yapılandırmaktır. Bu problar, örneğin bir çalışma zamanı hatası veya nadir bir olay nedeniyle tam donma olması durumunda süreci sonlandırmak için kullanılır.

Kaynak kotaları

Kubernetes , kaynak kotalarını uygulamak için işletim sistemiyle birlikte çalışır. Bu, CPU ve bellek ayırmalarının ve/veya sınırlarının zorunlu tutmasına olanak tanır. Etkileşimli yük sunan bir birincil uygulama için, gerekli olmadıkça kısıtlayıcı sınırların uygulanması önerilmez. İsteklerin ve sınırların anlam ve uygulama konumunda önemli ölçüde farklılık gösterdiğini unutmayın. İstekleri veya sınırları ayarlamadan önce, bunların nasıl uygulandığını ve yürütüldüğünü ayrıntılı olarak anlamak için zaman ayırın. Örneğin, bellek Kubernetes, Linux çekirdeği ve izleme sistemi arasında tekdüzen olarak ölçülemeyebilir. CPU kotaları beklendiği gibi uygulanmayabilir.

Sorun giderme

Podlar, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined ile ilgili bir hata bildirerek çöküyor.

Tüm özel durum iletisi:

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()
  • KUBERNETES_SERVICE_HOST ve KUBERNETES_SERVICE_PORT ortam değişkenlerinin Pod içinde ayarlanıp ayarlanmadığını denetleyin. komutunu kubectl exec -it <pod_name> /bin/bash -c envyürüterek denetleyin.
  • Kubernetes automountServiceAccountToken içinde true olarak deployment.yaml ayarlandığını kontrol edin. Daha fazla bilgi için bkz. Podlar için Hizmet Hesaplarını Yapılandırma.
  • Last updated on