Freigeben über


Bereitstellen und Konfigurieren eines Valkey-Clusters auf Azure Kubernetes Service (AKS)

In diesem Artikel konfigurieren wir und stellen einen Valkey-Cluster auf Azure Kubernetes Service (AKS) bereit, einschließlich der Erstellung eines Valkey-Cluster-ConfigMaps, primärer und Replikat-Cluster-Pods, um Redundanz und Zonenreplikation sicherzustellen, sowie eines Pod Disruption Budgets (PDB), um hohe Verfügbarkeit zu gewährleisten.

Hinweis

Dieser Artikel enthält Verweise auf die Begriffe Master (primär) und Slave (Replikat), die Begriffe sind, die Von Microsoft nicht mehr verwendet werden. Sobald der Begriff aus der Valkey-Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Herstellen einer Verbindung mit dem AKS-Cluster

Hinweis

Wenn Sie Terraform verwenden, stellen Sie sicher, dass Sie die Platzhalter im Code durch die tatsächlichen Ausgaben der Terraform-Befehle ersetzen, wenn Sie die Infrastruktur bereitstellen.

  • Konfigurieren Sie kubectl, um mithilfe des Befehls az aks get-credentials eine Verbindung mit Ihrem AKS-Cluster herzustellen.

    az aks get-credentials --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_CLUSTER_NAME --overwrite-existing --output table
    

Erstellen eines Namespace

  • Erstellen Sie für den Valkey-Cluster einen Namespace, indem Sie den Befehl kubectl create namespace verwenden.

    kubectl create namespace valkey --dry-run=client --output yaml | kubectl apply -f -
    

    Beispielausgabe:

    namespace/valkey created
    

Erstellen von Geheimnissen

  1. Generieren Sie ein zufälliges Kennwort für den Valkey-Cluster mithilfe von OpenSSL, und speichern Sie es mithilfe des Befehls az keyvault secret set in Ihrem Azure Key Vault.

    export SECRET=$(openssl rand -base64 32)
    echo requirepass $SECRET > /tmp/valkey-password-file.conf
    echo primaryauth $SECRET >> /tmp/valkey-password-file.conf
    az keyvault secret set --vault-name $MY_KEYVAULT_NAME --name valkey-password-file --file /tmp/valkey-password-file.conf --output none
    rm /tmp/valkey-password-file.conf
    
    
  2. Legen Sie die Richtlinie so fest, dass die benutzerseitig zugewiesene Identität das Geheimnis mithilfe des Befehls az keyvault set-policy abrufen kann.

    az keyvault set-policy --name $MY_KEYVAULT_NAME --object-id $userAssignedObjectID --secret-permissions get --output table
    

Abrufen der vom Benutzer zugewiesenen Identitätsdetails

  • Rufen Sie die Identitäts-ID und die Objekt-ID ab, die vom Azure Key Vault Secrets Provider-Add-On mithilfe des az aks show Befehls erstellt wurde.

    export userAssignedIdentityID=$(az aks show --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId --output tsv)
    export userAssignedObjectID=$(az aks show --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId --output tsv)
    

Konfigurieren des Zugriffs auf das im Azure Key Vault gespeicherte Valkey-Kennwort

  • Erstellen Sie eine SecretProviderClass-Ressource, um auf das im Schlüsseltresor gespeicherte Valkey-Kennwort zuzugreifen, indem Sie den Befehl kubectl apply verwenden.

    export TENANT_ID=$(az account show --query tenantId --output tsv)
    kubectl apply -f - <<EOF
    ---
    apiVersion: secrets-store.csi.x-k8s.io/v1
    kind: SecretProviderClass
    metadata:
      name: valkey-password
      namespace: valkey
    spec:
      provider: azure
      parameters:
        usePodIdentity: "false"
        useVMManagedIdentity: "true"
        userAssignedIdentityID: "${userAssignedIdentityID}"
        keyvaultName: ${MY_KEYVAULT_NAME}              # the name of the AKV instance
        objects: |
          array:
            - |
              objectName: valkey-password-file
              objectAlias: valkey-password-file.conf
              objectType: secret
        tenantId: "${TENANT_ID}" # the tenant ID of the AKV instance
    EOF
    

Erstellen der Valkey-Konfigurationsdatei

  • Erstellen Sie eine ConfigMap Ressource zum Speichern der Valkey-Konfigurationsdatei.

    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: valkey-cluster
      namespace: valkey
    data:
      valkey.conf:  |+
        cluster-enabled yes
        cluster-node-timeout 15000
        cluster-config-file /data/nodes.conf
        appendonly yes
        protected-mode yes
        dir /data
        port 6379
        include /etc/valkey-password/valkey-password-file.conf
    EOF
    

    Beispielausgabe:

    configmap/valkey-cluster created
    

Erstellen von primären Valkey-Clusterpods

  • Erstellen Sie eine StatefulSet-Ressource mit dem spec.affinity-Ziel, alle primären Replikate in Zone 1 und Zone 2 beizubehalten, vorzugsweise auf verschiedenen Knoten, indem Sie den Befehl kubectl apply verwenden.

    kubectl apply -f - <<EOF
    ---
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: valkey-masters
      namespace: valkey
    spec:
      serviceName: "valkey-masters"
      replicas: 3
      selector:
        matchLabels:
          app: valkey
      template:
        metadata:
          labels:
            app: valkey
            appCluster: valkey-masters
        spec:
          terminationGracePeriodSeconds: 20
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: agentpool
                    operator: In
                    values:
                    - valkey
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                    - ${MY_LOCATION}-1
                - matchExpressions:
                  - key: agentpool
                    operator: In
                    values:
                    - valkey
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                    - ${MY_LOCATION}-2
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 100
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - valkey
                  topologyKey: topology.kubernetes.io/zone
              - weight: 90
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - valkey
                  topologyKey: kubernetes.io/hostname
          containers:
          - name: role-master-checker
            image: "${MY_ACR_REGISTRY}.azurecr.io/valkey:latest"
            command:
              - "/bin/bash"
              - "-c"
            args:
              [
                "while true; do role=\$(valkey-cli --pass \$(cat /etc/valkey-password/valkey-password-file.conf | awk '{print \$2; exit}') role | awk '{print \$1; exit}');     if [ \"\$role\" = \"slave\" ]; then valkey-cli --pass \$(cat /etc/valkey-password/valkey-password-file.conf | awk '{print \$2; exit}') cluster failover; fi; sleep 30; done"
              ]
            volumeMounts:
            - name: valkey-password
              mountPath: /etc/valkey-password
              readOnly: true
          - name: valkey
            image: "${MY_ACR_REGISTRY}.azurecr.io/valkey:latest"
            env:
            - name: VALKEY_PASSWORD_FILE
              value: "/etc/valkey-password/valkey-password-file.conf"
            - name: MY_POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            command:
              - "valkey-server"
            args:
              - "/conf/valkey.conf"
              - "--cluster-announce-ip"
              - "\$(MY_POD_IP)"
            resources:
              requests:
                cpu: "100m"
                memory: "100Mi"
            ports:
                - name: valkey
                  containerPort: 6379
                  protocol: "TCP"
                - name: cluster
                  containerPort: 16379
                  protocol: "TCP"
            volumeMounts:
            - name: conf
              mountPath: /conf
              readOnly: false
            - name: data
              mountPath: /data
              readOnly: false
            - name: valkey-password
              mountPath: /etc/valkey-password
              readOnly: true
          volumes:
          - name: valkey-password
            csi:
              driver: secrets-store.csi.k8s.io
              readOnly: true
              volumeAttributes:
                secretProviderClass: valkey-password
          - name: conf
            configMap:
              name: valkey-cluster
              defaultMode: 0755
      volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: managed-csi-premium
          resources:
            requests:
              storage: 20Gi
    EOF
    

    Beispielausgabe:

    statefulset.apps/valkey-masters created
    

Erstellen von Valkey-Replikatclusterpods

  • Erstellen Sie eine zweite StatefulSet Ressource für die Valkey-Replikate mit dem spec.affinity Ziel, alle Replikate in Zone 3, vorzugsweise in verschiedenen Knoten, mithilfe des kubectl apply Befehls beizubehalten.

    kubectl apply -f - <<EOF
    ---
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: valkey-replicas
      namespace: valkey
    spec:
      serviceName: "valkey-replicas"
      replicas: 3
      selector:
        matchLabels:
          app: valkey
      template:
        metadata:
          labels:
            app: valkey
            appCluster: valkey-replicas
        spec:
          terminationGracePeriodSeconds: 20
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: agentpool
                    operator: In
                    values:
                    - valkey
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                    - ${MY_LOCATION}-3
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 90
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - valkey
                  topologyKey: kubernetes.io/hostname
          containers:
          - name: valkey
            image: "${MY_ACR_REGISTRY}.azurecr.io/valkey:latest"
            env:
            - name: VALKEY_PASSWORD_FILE
              value: "/etc/valkey-password/valkey-password-file.conf"
            - name: MY_POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            command:
              - "valkey-server"
            args:
              - "/conf/valkey.conf"
              - "--cluster-announce-ip"
              - "\$(MY_POD_IP)"
            resources:
              requests:
                cpu: "100m"
                memory: "100Mi"
            ports:
                - name: valkey
                  containerPort: 6379
                  protocol: "TCP"
                - name: cluster
                  containerPort: 16379
                  protocol: "TCP"
            volumeMounts:
            - name: conf
              mountPath: /conf
              readOnly: false
            - name: data
              mountPath: /data
              readOnly: false
            - name: valkey-password
              mountPath: /etc/valkey-password
              readOnly: true
          volumes:
          - name: valkey-password
            csi:
              driver: secrets-store.csi.k8s.io
              readOnly: true
              volumeAttributes:
                secretProviderClass: valkey-password
          - name: conf
            configMap:
              name: valkey-cluster
              defaultMode: 0755
      volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: managed-csi-premium
          resources:
            requests:
              storage: 20Gi
    EOF
    

    Beispielausgabe:

    statefulset.apps/valkey-replicas created
    

Überprüfen der Pod- und Knotenverteilung

  • Überprüfen Sie mithilfe der Befehle master-N und replica-N, ob kubectl get nodes und kubectl get pods auf verschiedenen Knoten und in verschiedenen Zonen ausgeführt werden.

    kubectl get pods -n valkey -o wide
    kubectl get node -o custom-columns=Name:.metadata.name,Zone:".metadata.labels.topology\.kubernetes\.io/zone"
    

    Beispielausgabe:

    NAME                READY   STATUS    RESTARTS   AGE     IP             NODE                             NOMINATED NODE   READINESS GATES
    valkey-masters-0    1/1     Running   0          2m55s   10.224.0.4     aks-valkey-18693609-vmss000004   <none>           <none>
    valkey-masters-1    1/1     Running   0          2m31s   10.224.0.137   aks-valkey-18693609-vmss000000   <none>           <none>
    valkey-masters-2    1/1     Running   0          2m7s    10.224.0.222   aks-valkey-18693609-vmss000001   <none>           <none>
    valkey-replicas-0   1/1     Running   0          88s     10.224.0.237   aks-valkey-18693609-vmss000005   <none>           <none>
    valkey-replicas-1   1/1     Running   0          70s     10.224.0.18    aks-valkey-18693609-vmss000002   <none>           <none>
    valkey-replicas-2   1/1     Running   0          48s     10.224.0.242   aks-valkey-18693609-vmss000005   <none>           <none>
    Name                                Zone
    aks-nodepool1-17621399-vmss000000   centralus-1
    aks-nodepool1-17621399-vmss000001   centralus-2
    aks-nodepool1-17621399-vmss000003   centralus-3
    aks-valkey-18693609-vmss000000      centralus-1
    aks-valkey-18693609-vmss000001      centralus-2
    aks-valkey-18693609-vmss000002      centralus-3
    aks-valkey-18693609-vmss000003      centralus-1
    aks-valkey-18693609-vmss000004      centralus-2
    aks-valkey-18693609-vmss000005      centralus-3
    

    Warten Sie ungefähr drei Minuten, bis alle master-N- und replica-N-Pods ausgeführt werden, bevor Sie mit dem nächsten Schritt fortfahren.

Erstellen von monitorlosen Diensten

  • Erstellen Sie drei Headless-Service-Ressourcen (die erste für den gesamten Cluster, die zweite für die Primärinstanzen und die dritte für die Replikate), um die IP-Adressen der Valkey-Pods mit dem Befehl kubectl apply abzurufen.

    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: valkey-cluster
      namespace: valkey
    spec:
      clusterIP: None
      ports:
      - name: valkey-port
        port: 6379
        protocol: TCP
        targetPort: 6379
      selector:
        app: valkey
      sessionAffinity: None
      type: ClusterIP
    EOF
    
    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: valkey-masters
      namespace: valkey
    spec:
      clusterIP: None
      ports:
      - name: valkey-port
        port: 6379
        protocol: TCP
        targetPort: 6379
      selector:
        app: valkey
        appCluster: valkey-masters
      sessionAffinity: None
      type: ClusterIP
    EOF
    
    kubectl apply -f - <<EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: valkey-replicas
      namespace: valkey
    spec:
      clusterIP: None
      ports:
      - name: valkey-port
        port: 6379
        protocol: TCP
        targetPort: 6379
      selector:
        app: valkey
        appCluster: valkey-replicas
      sessionAffinity: None
      type: ClusterIP
    EOF
    

    Beispielausgabe:

    service/valkey-cluster created
    service/valkey-masters created
    service/valkey-replicas created
    

Erstellen von Budgets für Podunterbrechungen (Pod Distribution Budget, PDB)

  • Erstellen Sie ein Pod Disruption Budget (PDB), um sicherzustellen, dass ein Pod höchstens während freiwilliger Unterbrechungen, z. B. Upgrades oder Wartung, nicht verfügbar ist. Dadurch wird die Stabilität und Verfügbarkeit der Valkey-Anwendung innerhalb des Kubernetes-Clusters beibehalten.

    kubectl apply -f - <<EOF
    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: valkey
      namespace: valkey
    spec:
      maxUnavailable: 1
      selector:
        matchLabels:
          app: valkey
    EOF
    

    Beispielausgabe:

    poddisruptionbudget.policy/valkey created
    

Ausführen des Valkey-Clusters

In einem Valkey-Cluster ist die Slot-Zuordnung ein grundlegender Bestandteil der Verteilung von Daten über Knoten hinweg. Valkey-Cluster (ähnlich wie Redis-Cluster) teilen den Schlüsselbereich in 16.384 Hashplätze auf, die gleichmäßig über die primären Knoten im Cluster verteilt werden.

In den folgenden Abschnitten richten wir einen Drei-Knoten-Valkey-Cluster mit drei Replikaten ein, um Folgendes sicherzustellen:

  • Vollständige Steckplatzabdeckung (alle 16.384 Steckplätze).
  • Hohe Verfügbarkeit über Replikation.
  • Ordnungsgemäße Rollenzuweisung und Clusterintegritätsüberprüfung.

Initialisieren des Valkey-Clusters mit primären Knoten in Zone 1 und 2 und Konfigurieren der Slotverteilung

  • Erstellen Sie den Cluster mit drei primären Knoten in Zone 1 und 2, und verteilen Sie alle 16.384 Hashplätze über sie mithilfe des kubectl exec Befehls gleichmäßig.

    kubectl exec -it -n valkey valkey-masters-0 -- valkey-cli --cluster create --cluster-yes --cluster-replicas 0 \
                        valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379 \
                        valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379 \
                        valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379 \
                        --pass ${SECRET}
    

    Beispielausgabe:

    >>> Performing hash slots allocation on 3 nodes...
    Master[0] -> Slots 0 - 5460
    Master[1] -> Slots 5461 - 10922
    Master[2] -> Slots 10923 - 16383
    M: ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35 valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379
       slots:[0-5460] (5461 slots) master
    M: fd1fb98db83976478e05edd3d2a02f9a13badd80 valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379
       slots:[5461-10922] (5462 slots) master
    M: ea47bf57ae7080ef03164a4d48b662c7b4c8770e valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379
       slots:[10923-16383] (5461 slots) master
    >>> Nodes configuration updated
    >>> Assign a different config epoch to each node
    >>> Sending CLUSTER MEET messages to join the cluster
    Waiting for the cluster to join
    ...
    >>> Performing Cluster Check (using node valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379)
    M: ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35 valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379
       slots:[0-5460] (5461 slots) master
    M: ea47bf57ae7080ef03164a4d48b662c7b4c8770e 10.224.0.176:6379
       slots:[10923-16383] (5461 slots) master
    M: fd1fb98db83976478e05edd3d2a02f9a13badd80 10.224.0.247:6379
       slots:[5461-10922] (5462 slots) master
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [OK] All 16384 slots covered.
    

Hinzufügen der Valkey-Replikate in Zone 3, um hohe Verfügbarkeit zu ermöglichen

  • Fügen Sie ein Replikat pro primärem Knoten in einer anderen Zone hinzu, um die Fehlertoleranz und die automatische Failoverfunktion mithilfe der folgenden kubectl exec Befehle sicherzustellen.

    kubectl exec -ti -n valkey valkey-masters-0 -- valkey-cli --cluster add-node \
                        valkey-replicas-0.valkey-replicas.valkey.svc.cluster.local:6379 \
                        valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379  --cluster-slave \
                        --pass ${SECRET}
    
    kubectl exec -ti -n valkey valkey-masters-0 -- valkey-cli --cluster add-node \
                        valkey-replicas-1.valkey-replicas.valkey.svc.cluster.local:6379 \
                        valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379  --cluster-slave \
                        --pass ${SECRET}
    
    kubectl exec -ti -n valkey valkey-masters-0 -- valkey-cli --cluster add-node \
                        valkey-replicas-2.valkey-replicas.valkey.svc.cluster.local:6379 \
                        valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379  --cluster-slave \
                        --pass ${SECRET}
    

    Beispielausgabe:

    >>> Adding node valkey-replicas-0.valkey-replicas.valkey.svc.cluster.local:6379 to cluster valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379
    >>> Performing Cluster Check (using node valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379)
    M: ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35 valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379
       slots:[0-5460] (5461 slots) master
    M: ea47bf57ae7080ef03164a4d48b662c7b4c8770e 10.224.0.176:6379
       slots:[10923-16383] (5461 slots) master
    M: fd1fb98db83976478e05edd3d2a02f9a13badd80 10.224.0.247:6379
       slots:[5461-10922] (5462 slots) master
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [OK] All 16384 slots covered.
    Automatically selected master valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379
    >>> Send CLUSTER MEET to node valkey-replicas-0.valkey-replicas.valkey.svc.cluster.local:6379 to make it join the cluster.
    Waiting for the cluster to join
    >>> Configure node as replica of valkey-masters-0.valkey-masters.valkey.svc.cluster.local:6379.
    [OK] New node added correctly.
    >>> Adding node valkey-replicas-1.valkey-replicas.valkey.svc.cluster.local:6379 to cluster valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379
    >>> Performing Cluster Check (using node valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379)
    M: fd1fb98db83976478e05edd3d2a02f9a13badd80 valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379
       slots:[5461-10922] (5462 slots) master
    S: 0ebceb60cbcc31da9040159440a1f4856b992907 10.224.0.224:6379
       slots: (0 slots) slave
       replicates ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35
    M: ea47bf57ae7080ef03164a4d48b662c7b4c8770e 10.224.0.176:6379
       slots:[10923-16383] (5461 slots) master
    M: ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35 10.224.0.14:6379
       slots:[0-5460] (5461 slots) master
       1 additional replica(s)
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [OK] All 16384 slots covered.
    Automatically selected master valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379
    >>> Send CLUSTER MEET to node valkey-replicas-1.valkey-replicas.valkey.svc.cluster.local:6379 to make it join the cluster.
    Waiting for the cluster to join
    >>> Configure node as replica of valkey-masters-1.valkey-masters.valkey.svc.cluster.local:6379.
    [OK] New node added correctly.
    >>> Adding node valkey-replicas-2.valkey-replicas.valkey.svc.cluster.local:6379 to cluster valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379
    >>> Performing Cluster Check (using node valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379)
    M: ea47bf57ae7080ef03164a4d48b662c7b4c8770e valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379
       slots:[10923-16383] (5461 slots) master
    S: 0ebceb60cbcc31da9040159440a1f4856b992907 10.224.0.224:6379
       slots: (0 slots) slave
       replicates ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35
    S: fa44edff683e2e01ee5c87233f9f3bc35c205dce 10.224.0.103:6379
       slots: (0 slots) slave
       replicates fd1fb98db83976478e05edd3d2a02f9a13badd80
    M: ee6ac1d00d3f016b6f46c7ce11199bc1a7809a35 10.224.0.14:6379
       slots:[0-5460] (5461 slots) master
       1 additional replica(s)
    M: fd1fb98db83976478e05edd3d2a02f9a13badd80 10.224.0.247:6379
       slots:[5461-10922] (5462 slots) master
       1 additional replica(s)
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [OK] All 16384 slots covered.
    Automatically selected master valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379
    >>> Send CLUSTER MEET to node valkey-replicas-2.valkey-replicas.valkey.svc.cluster.local:6379 to make it join the cluster.
    Waiting for the cluster to join
    >>> Configure node as replica of valkey-masters-2.valkey-masters.valkey.svc.cluster.local:6379.
    [OK] New node added correctly.
    

Überprüfen Sie die Rollen der Pods und den Replikationsstatus

  • Vergewissern Sie sich, dass jedes primäre Und Replikat ordnungsgemäß konfiguriert ist und dass Replikationsbeziehungen mithilfe der folgenden kubectl exec Befehle eingerichtet werden.

    for x in $(seq 0 2); do echo "valkey-masters-$x"; kubectl exec -n valkey valkey-masters-$x  -- valkey-cli --pass ${SECRET} role; echo; done
    for x in $(seq 0 2); do echo "valkey-replicas-$x"; kubectl exec -n valkey valkey-replicas-$x -- valkey-cli --pass ${SECRET} role; echo; done
    

    Beispielausgabe:

    valkey-masters-0
    master
    84
    10.224.0.224
    6379
    84
    valkey-masters-1
    master
    84
    10.224.0.103
    6379
    84
    valkey-masters-2
    master
    70
    10.224.0.200
    6379
    70
    valkey-replicas-0
    slave
    10.224.0.14
    6379
    connected
    98
    valkey-replicas-1
    slave
    10.224.0.247
    6379
    connected
    98
    valkey-replicas-2
    slave
    10.224.0.176
    6379
    connected
    84
    

Nächste Schritte

Weitere Informationen zum Bereitstellen von Open-Source-Software auf Azure Kubernetes Service (AKS) finden Sie in den folgenden Artikeln:

Mitwirkende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Nelly Kiboi | Servicetechnikerin
  • Saverio Proto | Principal Customer Experience Engineer
  • Don High | Leitender Kundeningenieur
  • LaBrina Loving | Hauptingenieurin für Dienstleistungen
  • Ken Kilty | Leitender TPM
  • Russell de Pina | Leiter TPM
  • Colin Mixon | Produktmanager
  • Ketan Chawda | Senior Customer Engineer
  • Naveed Kharadi | Customer Experience Engineer
  • Erin Schaffer | Inhaltsentwickler 2