Skapa ett Azure Kubernetes Service-kluster

Ditt företag planerar att distribuera en molnbaserad videorenderingstjänst med Azure Kubernetes Service (AKS) som molnbaserad utvecklingsplattform. Innan du kan distribuera ett program måste du skapa ditt AKS-kluster.

Nu ska vi gå igenom några begrepp så att du kan distribuera ett nytt AKS-kluster.

Kubernetes-kluster

Kubernetes baseras på kluster. I stället för en enda virtuell dator (VM) använder Kubernetes flera virtuella datorer som fungerar som en, så kallade noder. Kubernetes är en klusterbaserad orkestrerare som ger ditt program flera fördelar, till exempel tillgänglighet, övervakning, skalning och löpande uppdateringar.

Klusternoder

Ett kluster är nodbaserat och det finns två typer av noder i ett Kubernetes-kluster som tillhandahåller specifika funktioner.

• Kontrollplansnoder: Dessa noder är värdar för klustrets kontrollplansaspekter och är reserverade för tjänster som styr klustret. De ansvarar för att tillhandahålla det API som du och alla andra noder använder för att kommunicera. Inga arbetsbelastningar distribueras eller schemaläggs på dessa noder.
• Noder: Dessa noder ansvarar för att köra anpassade arbetsbelastningar och program, till exempel komponenter från din molnbaserade videorenderingstjänst.

Klusterarkitekturer

Använd en klusterarkitektur för att konceptualisera antalet kontrollplan och noder som du distribuerar i ditt Kubernetes-kluster.

Exempelvis ska antalet noder i ett kluster till exempel alltid vara fler än två. När en nod blir otillgänglig försöker Kubernetes-schemaläggaren schemalägga om nodens arbetsbelastningar till de återstående noderna i klustret.

Det finns två populära klusterarkitekturer för Kubernetes-baserade distributioner.

Ett enskilt kontrollplan och flera noder

Det enda kontrollplanet till flera noder per klusterarkitektur är det vanligaste arkitekturmönstret och är det enklaste att distribuera, men det ger inte hög tillgänglighet till klustrets kärnhanteringstjänster.

Om kontrollplansnoden inte är tillgänglig av någon anledning kan ingen annan interaktion ske med klustret. Det här problemet uppstår även om du är operatör eller av arbetsbelastningar som använder Kubernetes-API:er för att kommunicera tills, åtminstone, API-servern är online igen.

Den här arkitekturen är mindre tillgänglig än andra men bör räcka för de flesta situationer. Det är mindre troligt att kärnhanteringstjänsterna blir otillgängliga än att en nod går offline. Kontrollplansnoderna är föremål för färre ändringar än noder och är mer motståndskraftiga.

För ett produktionsscenario kanske den här arkitekturen inte är den bästa lösningen.

Ett enskilt kontrollplan och en enskild nod

Arkitekturen för en kontrollplan till en nod är en variant av den tidigare arkitekturen och används i utvecklingsmiljöer. Den här arkitekturen tillhandahåller bara en enda nod som är värd för både kontrollplanet och en arbetsnod. Den är användbar när du testar eller experimenterar med olika Kubernetes-begrepp. Arkitekturen med ett enskilt kontrollplan och en enskild nod begränsar klusterskalningen, vilket gör att den här arkitekturen inte är lämplig för produktion och mellanlagring.

Konfigurera ett AKS-kluster

En viktig skillnad mellan Kubernetes och AKS är att i ett AKS-kluster hanteras kontrollplanet av Microsoft för tillgänglighet. Du behöver inte konfigurera kontrollplanet när du skapar ett kluster. Du behöver bara konfigurera noderna för att köra dina arbetsbelastningar.

När du skapar ett nytt AKS-kluster har du flera olika objekt att konfigurera. Varje objekt påverkar den slutliga konfigurationen av klustret för beräkningsresursallokering.

Dessa objekt är:

• Nodpooler.
• Antal noder.
• Vm-storlek för nod.

Nodgrupper

Du skapar nodpooler för att gruppera noder i ditt AKS-kluster. När du skapar en nodpool anger du VM-storlek och OS-typ (Linux eller Windows) för varje nod i nodpoolen baserat på programkrav. En nodpool med systemläge är reserverad för kritiska systemtjänster och används vanligtvis inte för att köra programarbetsbelastningar. För att vara värd för användarprogrampoddar ska nodpoolläget vara Användare.

Som standard har ett AKS-kluster en Linux-nodpool (systemläge) oavsett om du skapar den via Azure-portalen eller CLI. Du kan konfigurera den för att lägga till Windows-nodpooler tillsammans med standardpooler för Linux-noder när klustret skapas i portalen, CLI-parametrar eller Azure Resource Manager-mallar (ARM-mallar).

Nodpooler använder vm-skalningsuppsättningar som den underliggande infrastrukturen så att klustret kan skala antalet noder i en nodpool. Nya noder som skapas i nodpoolen har alltid samma storlek som du angav när du skapade nodpoolen.

Antal noder

Antalet noder är antalet noder som klustret har i en nodpool. Noder är virtuella Azure-datorer och du kan ändra deras storlek och antal så att de matchar ditt användningsmönster.

Du kan ändra nodantalet senare i klustrets konfigurationspanel. Det är även bästa praxis att hålla detta antal så lågt som möjligt för att undvika onödiga kostnader och outnyttjad beräkningskraft.

Vm-storlek för nod

Välj från en mängd olika VM-specifikationer. I utvecklingssyfte kan du välja B-serien för att spara på kostnaderna. I övningarna använder du serie B2, standardstorleken. Om du vill ha mer vägledning för att välja en virtuell dator baserat på dina behov ber du Microsoft Copilot i Azure att hitta den bästa virtuella datorn