Distribuera ett Valkey-kluster i Azure Kubernetes Service (AKS)

Den här artikeln sammanfattar stegen för att distribuera Valkey, ett BSD-datalager med hög prestanda för nyckel/värde i Azure Kubernetes Service (AKS). Valkey-distributionen fokuserar på att utnyttja repliker och tillgänglighetszoner för hög tillgänglighet och resiliens. Vi ger också vägledning för att testa motståndskraften i din Valkey-distribution med hjälp av locust-belastningstestningsramverket.

Viktigt!

Programvara med öppen källkod nämns i AKS-dokumentationen och exempel. Programvara som du distribuerar undantas från AKS-serviceavtal, begränsad garanti och Azure Support. När du använder teknik med öppen källkod tillsammans med AKS kan du läsa supportalternativen som är tillgängliga från respektive community och projektunderhållare för att utveckla en plan.

Microsoft tar ansvar för att skapa de paket med öppen källkod som vi distribuerar på AKS. Det ansvaret omfattar att ha fullständigt ägarskap för bygg-, genomsöknings-, signerings-, validerings- och snabbkorrigeringsprocessen, tillsammans med kontroll över binärfilerna i containeravbildningar. Mer information finns i Sårbarhetshantering för AKS - och AKS-stödtäckning.

Vad är Valkey?

Valkey är en förgrening av Redis-projektet som bevarar sin ursprungliga licens med öppen källkod. Valkey är en databas med höga prestanda som stöder ett nyckelvärdesdatalager och du kan använda den för cachelagring, sessionslagring, meddelandeköer med mera. Ett Valkey-kluster har flera noder som ansvarar för att vara värd för dina Valkey-datalager. Valkey fragmenterar data i mindre delar och sprider dem mellan noderna. I ett förenklat Valkey-kluster som består av tre primära noder stöder en enskild repliknod varje nod för att aktivera grundläggande redundansfunktioner. Data distribueras över noderna, vilket gör att klustret kan fortsätta att fungera även om en av noderna misslyckas.

Mer information finns i Valkey-dokumentationen.

Översikt över Valkey-lösningen

Den här lösningen distribuerar tre primära Valkey-poddar över två tillgänglighetszoner med en replikpodd per primär i en tredje zon som körs på Standard_E64_v5 SKU-noder. Du skapar två distinkta StatefulSet resurser med spec.affinity regler som säkerställer zondistribution för hög tillgänglighet. Du skapar en StatefulSet för de primära Valkey-poddarna och en annan för replikpodderna.

Anteckning

Observera att lösningen som föreslås i den här artikeln skiljer sig från Valkey-dokumentationen, där Pods hör till en enda StatefulSet, och där spec.affinity enbart säkerställer att Pods placeras på olika noder. Den automatiska initieringen av Valkey-klustret som presenteras i Valkey-dokumentationen säkerställer inte att de primära och replika-Podar för samma shard placeras i olika tillgänglighetszoner.

Nästa steg

Skapa infrastrukturresurserna för att köra ett Valkey-kluster på AKS

Deltagare

Microsoft underhåller den här artikeln. Följande deltagare skrev den ursprungligen:

• Nelly Kiboi | Tjänsttekniker
• Saverio Proto | Huvudtekniker för kundupplevelse
• Don High | Huvudkundtekniker
• LaBrina Loving | Huvudtjänsttekniker
• Ken Kilty | Huvudansvarig TPM
• Russell de Pina | Huvudansvarig för TPM
• Colin Mixon | Produktchef
• Ketan Chawda | Senior kundtekniker
• Naveed Kharadi | Kundupplevelsetekniker
• Erin Schaffer | Innehållsutvecklare 2