Az Azure Kubernetes Service (AKS) alapvető Kubernetes-fogalmai

Ez a cikk az Azure Kubernetes Service (AKS) egy felügyelt Kubernetes-szolgáltatás alapfogalmait ismerteti, amelyekkel nagy méretekben helyezhet üzembe és üzemeltethet tárolóalapú alkalmazásokat az Azure-ban. Segít megismerni a Kubernetes infrastruktúra-összetevőit, és jobban megismerni a Kubernetes működését az AKS-ben.

Mi az a Kubernetes?

A Kubernetes egy gyorsan fejlődő platform, amely a tárolóalapú alkalmazásokat és azok kapcsolódó hálózati és tárolási összetevőit kezeli. A Kubernetes az alkalmazás számítási feladataira összpontosít, nem a mögöttes infrastruktúra-összetevőkre. A Kubernetes deklaratív megközelítést biztosít az üzemelő példányokhoz, amelyet a felügyeleti műveletekhez használható, robusztus API-k nyújtanak.

Modern, hordozható, mikroszolgáltatás-alapú alkalmazásokat hozhat létre és futtathat a Kubernetes használatával az alkalmazásösszetevők rendelkezésre állásának vezényléséhez és kezeléséhez. A Kubernetes állapot nélküli és állapotalapú alkalmazásokat is támogat.

Nyílt platformként a Kubernetes lehetővé teszi az alkalmazások létrehozását az előnyben részesített programozási nyelv, operációs rendszer, kódtárak vagy üzenetkezelő busz használatával. A meglévő folyamatos integrációs és folyamatos kézbesítési (CI/CD) eszközök integrálhatók a Kubernetes-lel a kiadások ütemezéséhez és üzembe helyezéséhez.

Az AKS egy felügyelt Kubernetes-szolgáltatást biztosít, amely csökkenti az üzembe helyezés és az alapvető felügyeleti feladatok összetettségét. Az Azure platform kezeli az AKS vezérlősíkot, és csak az alkalmazásokat futtató AKS-csomópontokért kell fizetnie.

Kubernetes-fürtarchitektúra

Egy Kubernetes-fürt két összetevőre osztható:

  • A vezérlősík, amely az alapvető Kubernetes-szolgáltatásokat és az alkalmazás-számítási feladatok vezénylését biztosítja, és
  • Az alkalmazás számítási feladatait futtató csomópontok.

Kubernetes vezérlősík és csomópontösszetevők

Vezérlősík

AKS-fürt létrehozásakor az Azure-platform automatikusan létrehozza és konfigurálja a hozzá tartozó vezérlősíkot. Ez az egybérlős vezérlősík díjmentesen elérhető a felhasználótól absztrakció alatt álló felügyelt Azure-erőforrásként. Csak az AKS-fürthöz kapcsolódó csomópontokért kell kifizetnie. A vezérlősík és erőforrásai csak abban a régióban találhatók, ahol a fürtöt létrehozta.

A vezérlősík a következő alapvető Kubernetes-összetevőket tartalmazza:

Összetevő Leírás
kube-apiserver Az API-kiszolgáló elérhetővé teszi az alapul szolgáló Kubernetes API-kat, és biztosítja az interakciót a felügyeleti eszközökkel, például kubectl a Kubernetes-irányítópulttal.
etcd Az etcd egy magas rendelkezésre állású kulcs-érték tároló a Kubernetesben, amely segít fenntartani a Kubernetes-fürt és -konfiguráció állapotát.
kube-scheduler Alkalmazások létrehozásakor vagy méretezésekor az ütemező határozza meg, hogy mely csomópontok futtathatják a számítási feladatot, és elindítja az azonosított csomópontokat.
kube-controller-manager A vezérlőkezelő számos kisebb vezérlőt felügyel, amelyek olyan műveleteket hajtanak végre, mint a podok replikálása és a csomópontműveletek kezelése.

Ne feledje, hogy közvetlenül nem férhet hozzá a vezérlősíkhoz. A Kubernetes vezérlősíkjának és csomópontfrissítéseinek vezénylése az Azure CLI-n vagy az Azure Portalon keresztül történik. A lehetséges problémák elhárításához tekintse át a vezérlősík naplóit az Azure Monitor használatával.

Feljegyzés

Ha egy vezérlősíkot szeretne konfigurálni vagy közvetlenül elérni, üzembe helyezhet egy ön által felügyelt Kubernetes-fürtöt az Azure-fürt API-szolgáltatójával.

Csomópontok

Az alkalmazások és a támogató szolgáltatások futtatásához Kubernetes-csomópontra van szükség. Minden AKS-fürt rendelkezik legalább egy csomóponttal, egy Azure-beli virtuális géppel (VM), amely a Kubernetes-csomópont összetevőit és a tároló futtatókörnyezetét futtatja.

A csomópontok a következő alapvető Kubernetes-összetevőket tartalmazzák:

Összetevő Leírás
kubelet A kubernetes-ügynök, amely feldolgozza a vezérlősíkról érkező vezénylési kéréseket, valamint ütemezi és futtatja a kért tárolókat.
kube-proxy A proxy kezeli az egyes csomópontok virtuális hálózatkezelését, a hálózati forgalom irányítását és a szolgáltatások és podok IP-címkezelését.
tároló futtatókörnyezete A tároló futtatókörnyezete lehetővé teszi a tárolóalapú alkalmazások futtatását és használatát más erőforrásokkal, például a virtuális hálózattal vagy a tárolóval. További információkért lásd a tároló futtatókörnyezetének konfigurációját.

Azure-beli virtuális gép és támogatási erőforrások Kubernetes-csomóponthoz

A csomópontok Azure-beli virtuálisgép-mérete határozza meg a processzorokat, a memóriát, a méretet és az elérhető tártípust, például a nagy teljesítményű SSD-t vagy a normál HDD-t. Tervezze meg a csomópont méretét, hogy az alkalmazások nagy mennyiségű processzort és memóriát vagy nagy teljesítményű tárterületet igényelnek-e. Skálázza fel az AKS-fürt csomópontjainak számát az igények kielégítése érdekében. A skálázással kapcsolatos további információkért tekintse meg az alkalmazások skálázási beállításait az AKS-ben.

Az AKS-ben a fürt csomópontjaihoz tartozó virtuálisgép-rendszerkép Ubuntu Linuxon, Azure Linuxon vagy Windows Server 2022-n alapul. Amikor létrehoz egy AKS-fürtöt, vagy kibővíti a csomópontok számát, az Azure-platform automatikusan létrehozza és konfigurálja a kért virtuális gépek számát. Az ügynökcsomópontok számlázása standard virtuális gépekként történik, így a rendszer automatikusan alkalmazza a virtuálisgép-méretre vonatkozó kedvezményeket, beleértve az Azure-foglalásokat is.

Felügyelt lemezek esetén az alapértelmezett lemezméret és -teljesítmény a kiválasztott virtuálisgép-termékváltozat és vCPU-szám alapján van hozzárendelve. További információ: Operációsrendszer-lemez alapértelmezett méretezése.

Feljegyzés

Ha speciális konfigurálásra és vezérlésre van szüksége a Kubernetes-csomópont tároló-futtatókörnyezetében és operációs rendszerében, üzembe helyezhet egy ön által felügyelt fürtöt az Azure Fürt API-szolgáltatóval.

Operációs rendszer konfigurálása

Az AKS támogatja az Ubuntu 22.04-et és az Azure Linux 2.0-t a Kubernetes 1.25-ös vagy újabb verziójú fürtök csomópont operációs rendszereként. Az Ubuntu 18.04 a Kubernetes 1.24-s és újabb verzióihoz készült csomópontkészlet létrehozásakor is megadható.

Az AKS a Windows Server 2022-t támogatja alapértelmezett operációs rendszerként a Kubernetes 1.25-ös vagy újabb kubernetes rendszerű fürtök windowsos csomópontkészleteihez. A Windows Server 2019 a Kubernetes 1.32-s és újabb verzióihoz készült csomópontkészlet létrehozásakor is megadható. A Windows Server 2019 a Kubernetes 1.32-es verziójának megszűnése után megszűnik, és a jövőbeli kiadásokban nem támogatott. A kivonással kapcsolatos további információkért tekintse meg az AKS kibocsátási megjegyzéseit.

Tároló futtatókörnyezetének konfigurálása

A tároló-futtatókörnyezetek olyan szoftverek, amelyek tárolókat hajtanak végre, és egy csomóponton kezelik a tárolólemezképeket. A futtatókörnyezet segít absztrakciót adni a sys-hívásoknak vagy az operációs rendszer-specifikus funkcióknak a tárolók Linuxon vagy Windowson való futtatásához. Linux-csomópontkészletek containerd esetén a Kubernetes 1.19-es és újabb verziójában használatos. Windows Server 2019 és 2022 csomópontkészletek esetén általánosan elérhető, containerd és ez az egyetlen futtatókörnyezeti lehetőség a Kubernetes 1.23-s és újabb verziójában. 2023 májusától a Docker megszűnik, és már nem támogatott. A kivonással kapcsolatos további információkért tekintse meg az AKS kibocsátási megjegyzéseit.

Containerdaz OCI (Open Container Initiative) szabványnak megfelelő alapvető tároló-futtatókörnyezet, amely biztosítja a tárolók végrehajtásához és a csomóponton lévő lemezképek kezeléséhez szükséges minimális funkcionalitást. A kubelet a cri (tároló futtatókörnyezeti felület) beépülő modul használatával közvetlenül containerd kommunikál a csomópontokkal és csomópontkészletekkelcontainerd, így a Docker CRI-implementációval összehasonlítva eltávolítja az adatfolyam további ugrásait. Így jobb podindítási késést és kevesebb erőforrás-(PROCESSZOR- és memóriahasználatot) lát.

Containerd A Kubernetes összes GA-verzióján működik az AKS-ben, az 1.19-es verziótól kezdve minden Kubernetes-verzióban, és támogatja az összes Kubernetes- és AKS-funkciót.

Fontos

A Kubernetes 1.19-s vagy újabb verzióján létrehozott Linux-csomópontkészletekkel rendelkező fürtök alapértelmezés szerint a containerd tároló-futtatókörnyezetre lesznek létrehozva. A korábban támogatott Kubernetes-verziók csomópontkészleteivel rendelkező fürtök kapják a Dockert a tároló futásidejéhez. A Linux-csomópontkészletek akkor frissülnek, containerd ha a csomópontkészlet Kubernetes-verziója egy támogatott containerdverzióra frissül.

containerd Általánosan elérhető a Windows Server 2019 és 2022 csomópontkészletekkel rendelkező fürtök esetében, és ez az egyetlen tároló-futtatókörnyezeti lehetőség a Kubernetes 1.23-s vagy újabb verziójához. Továbbra is használhatja a Docker-csomópontkészleteket és -fürtöket az 1.23-asnál korábbi verziókban, de a Docker 2023 májusától már nem támogatott. További információ: Windows Server-csomópontkészlet hozzáadása a következővel containerd: .

Javasoljuk, hogy tesztelje a számítási feladatokat az AKS-csomópontkészleteken containerd , mielőtt fürtöket használ a csomópontkészletekhez támogatott containerd Kubernetes-verzióval.

containerd korlátozások/különbségek

  • Ezért containerdazt javasoljuk, hogy crictl a Docker parancssori felület helyett használja a podok, tárolók és tárolólemezképek hibaelhárítását a Kubernetes-csomópontokon. További információkért lásd az crictláltalános használati és ügyfélkonfigurációs beállításokat.

    • Containerd nem biztosítja a Docker parancssori felületének teljes funkcionalitását. Ez csak hibaelhárításhoz érhető el.
    • crictl Kubernetes-barátabb nézetet kínál a tárolókról, olyan fogalmakkal, mint a podok stb.
  • Containerd szabványos naplózási formátum használatával állítja be a naplózást cri . A naplózási megoldásnak támogatnia kell a naplózási formátumot, például az cri Azure Monitor for Containerst.

  • A továbbiakban nem férhet hozzá a Docker motorhoz, /var/run/docker.sockés nem használhatja a Docker-in-Dockert (DinD).

    • Ha jelenleg alkalmazásnaplókat vagy monitorozási adatokat nyer ki a Docker-motorból, használja helyette a Container Elemzések. Az AKS nem támogatja a sávon kívüli parancsok futtatását az ügynökcsomópontokon, amelyek instabilitást okozhatnak.
    • Nem javasoljuk képek készítését vagy közvetlenül a Docker motor használatát. A Kubernetes nem ismeri teljesen a felhasznált erőforrásokat, és ezek a módszerek számos problémát jelentenek az itt és itt leírtak szerint.
  • Rendszerképek készítésekor továbbra is használhatja a docker-buildelési munkafolyamatot a szokásos módon, hacsak nem készít lemezképeket az AKS-fürtön belül. Ebben az esetben érdemes lehet a rendszerképek ACR Tasks használatával történő létrehozásához javasolt megközelítésre váltani, vagy egy biztonságosabb fürtbeli beállításra, például a Docker Buildxre.

Erőforrás-foglalások

Az AKS csomóponterőforrásokkal segíti a csomópont működését a fürt részeként. Ez a használat eltérést okozhat a csomópont teljes erőforrásai és az AKS-ben kiosztható erőforrások között. Ezeket az információkat a felhasználók által üzembe helyezett podok kéréseinek és korlátainak beállításakor jegyezze fel.

A csomópont kiosztható erőforrásának megkereséséhez használja a kubectl describe node következő parancsot:

kubectl describe node [NODE_NAME]

A csomópontok teljesítményének és működésének fenntartása érdekében az AKS két típusú erőforrást, processzort és memóriát foglal le minden csomóponton. Ahogy a csomópontok egyre nagyobbak lesznek az erőforrásokban, az erőforrás-foglalás növekszik a felhasználó által üzembe helyezett podok felügyeletére való nagyobb igény miatt. Ne feledje, hogy az erőforrás-foglalások nem módosíthatók.

Feljegyzés

Az AKS-bővítmények, például a Container Elemzések (OMS) használata további csomóponterőforrásokat használ fel.

CPU

A fenntartott CPU a csomópont típusától és a fürt konfigurációtól függ, ami a további funkciók futtatása miatt kevésbé kiosztható PROCESSZORt okozhat. Az alábbi táblázat a PROCESSZOR-foglalást mutatja millicore-ban:

Processzormagok a gazdagépen 0 2 4 8 16 32 64
Kube-reserved (millicores) 60 100 140 180 260 420 740

Memory (Memória)

Az AKS fenntartott memóriája két érték összegét tartalmazza:

Fontos

Az AKS 1.29 előzetes verziója 2024 januárjában érhető el, és tartalmazza a memóriafoglalások bizonyos módosításait. Ezeket a módosításokat a következő szakaszban találja.

AKS 1.29 és újabb verziók

  1. kubelet A démon alapértelmezés szerint rendelkezik a memory.available<100Mi kiürítési szabálysal. Ez a szabály biztosítja, hogy a csomópontok mindig legalább 100Mi kiosztható állapotban vannak. Ha egy gazdagép a rendelkezésre álló memória küszöbértéke alatt van, az kubelet aktiválja az egyik futó pod leállítását, és felszabadítja a memóriát a gazdagépen.

  2. A memóriafoglalások aránya a következő kisebb érték szerint van beállítva: 20 MB * A csomóponton támogatott maximális podok száma + 50 MB , vagy a teljes rendszermemória-erőforrás 25%-a.

    Példák:

    • Ha a virtuális gép 8 GB memóriát biztosít, és a csomópont legfeljebb 30 podot támogat, az AKS 20 MB * 30 maximális podot + 50 MB = 650 MB-ot foglal le a kube-reserved számára. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
    • Ha a virtuális gép 4 GB memóriát biztosít, és a csomópont legfeljebb 70 podot támogat, az AKS 25% * 4 GB = 1000 MB-ot foglal le a kube-reserved számára, mivel ez kevesebb, mint 20 MB * 70 Maximális pod + 50 MB = 1450 MB.

    További információ: Csomópontonkénti maximális podok konfigurálása egy AKS-fürtben.

AKS-verziók az 1.29-et megelőzően

  1. kubelet a démon alapértelmezés szerint rendelkezik a memory.available<750Mi kiürítési szabálysal. Ez a szabály biztosítja, hogy a csomópontok mindig legalább 750Mi kioszthatóak. Ha egy gazdagép a rendelkezésre álló memória küszöbértéke alatt van, az kubelet aktiválja az egyik futó pod leállítását, és memóriát szabadít fel a gazdagépen.
  2. A kubelet démon memóriafoglalásainak regresszív aránya a megfelelő működéshez (kube-reserved).
    • Az első 4 GB memória 25%-a
    • A következő 4 GB memória 20%-a (legfeljebb 8 GB)
    • A következő 8 GB memória 10%-a (legfeljebb 16 GB)
    • A következő 112 GB memória 6%-a (legfeljebb 128 GB)
    • 128 GB-nál nagyobb memória 2%-a

Feljegyzés

Az AKS további 2 GB-ot foglal le olyan Windows-csomópontok rendszerfolyamataihoz, amelyek nem részei a számított memóriának.

A memória- és CPU-foglalási szabályok a következőkre vannak kialakítva:

  • Az ügynökcsomópontok kifogástalan állapotának megőrzése, beleértve néhány olyan üzemeltetési rendszer podot, amely kritikus fontosságú a fürt állapota szempontjából.
  • A csomópont kevesebb kiosztható memóriát és processzort jelent, mint amennyit egy Kubernetes-fürt részeként jelentene.

Ha például egy csomópont 7 GB-ot kínál, a memória 34%-át nem lehet lefoglalni, beleértve a 750Mi kemény kiürítési küszöbértéket is.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

A Kubernetes-re vonatkozó foglalások mellett a mögöttes csomópont operációs rendszere az operációs rendszer funkcióinak fenntartásához is fenntart egy mennyiségű PROCESSZOR- és memóriaerőforrást.

A kapcsolódó ajánlott eljárásokért tekintse meg az AKS alapszintű ütemezőfunkcióinak ajánlott eljárásait.

Csomópontkészletek

Feljegyzés

Az Azure Linux-csomópontkészlet általánosan elérhető (GA). Az előnyökről és az üzembe helyezés lépéseiről az AKS-hez készült Azure Linux Container Host bemutatása című témakörben olvashat.

Az azonos konfigurációban lévő csomópontok csomópontkészletekbe vannak csoportosítva. Minden Kubernetes-fürt legalább egy csomópontkészletet tartalmaz. Az alapértelmezett csomópontkészletet létrehozó AKS-fürt létrehozásakor megadhatja a csomópontok és a méretek kezdeti számát. Az AKS alapértelmezett csomópontkészlete az ügynökcsomópontokat futtató mögöttes virtuális gépeket tartalmazza.

Feljegyzés

A fürt megbízható működésének biztosítása érdekében legalább két csomópontot kell futtatnia az alapértelmezett csomópontkészletben.

Az AKS-fürtöket az alapértelmezett csomópontkészletre skálázhatja vagy frissítheti. Egy adott csomópontkészlet skálázását vagy frissítését is választhatja. Frissítési műveletek esetén a futó tárolók a csomópontkészlet más csomópontjaira lesznek ütemezve, amíg az összes csomópont frissítése sikeresen meg nem fejeződik.

További információ: Csomópontkészletek létrehozása és csomópontkészletek kezelése.

Operációsrendszer-lemez alapértelmezett méretezése

Amikor új fürtöt hoz létre, vagy új csomópontkészletet ad hozzá egy meglévő fürthöz, a virtuális processzorok száma alapértelmezés szerint meghatározza az operációsrendszer-lemez méretét. A vCPU-k száma a virtuálisgép-termékváltozaton alapul. Az alábbi táblázat az operációsrendszer-lemez alapértelmezett méretét sorolja fel az egyes virtuálisgép-termékváltozatokhoz:

Virtuálisgép-termékváltozat-magok (vCPU-k) Az operációsrendszer-lemez alapértelmezett szintje Kiépített IOPS Kiosztott átviteli sebesség (Mbps)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2300 150
64+ P30/1024G 5000 200

Fontos

Az operációsrendszer-lemez alapértelmezett méretezése csak akkor használható új fürtökön vagy csomópontkészleteken, ha a rövid élettartamú operációsrendszer-lemezek nem támogatottak, és nincs megadva az operációsrendszer-lemez alapértelmezett mérete. Az operációsrendszer-lemez alapértelmezett mérete hatással lehet a fürt teljesítményére vagy költségeire. A fürt vagy a csomópontkészlet létrehozása után nem módosíthatja az operációsrendszer-lemez méretét. Ez az alapértelmezett lemezméretezés hatással van a 2022 júliusában vagy később létrehozott fürtökre vagy csomópontkészletekre.

Csomópontválasztók

Több csomópontkészlettel rendelkező AKS-fürtön előfordulhat, hogy meg kell adnia a Kubernetes Schedulernek, hogy melyik csomópontkészletet használja egy adott erőforráshoz. A bejövőforgalom-vezérlők például nem futtathatók Windows Server-csomópontokon. A csomópontválasztókkal különböző paramétereket definiálhat, például a csomópont operációs rendszerét annak szabályozásához, hogy a podok hol legyenek ütemezve.

Az alábbi egyszerű példa egy NGINX-példányt ütemez egy Linux-csomóponton a "kubernetes.io/os": linux csomópontválasztó használatával:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

További információ: Ajánlott eljárások az AKS speciális ütemező funkcióihoz.

Csomópont-erőforráscsoport

AKS-fürt létrehozásakor meg kell adnia egy Azure-erőforráscsoportot a fürterőforrások létrehozásához. Ezen erőforráscsoport mellett az AKS-erőforrás-szolgáltató létrehoz és kezel egy külön erőforráscsoportot, a csomópont erőforráscsoportját. A csomópont erőforráscsoportja a következő infrastruktúra-erőforrásokat tartalmazza:

  • A csomópontkészletek összes csomópontjának virtuálisgép-méretezési csoportjai és virtuális gépei
  • A fürt virtuális hálózata
  • A fürt tárhelye

A csomópont erőforráscsoportja alapértelmezés szerint a következő formátumban van hozzárendelve: MC_resourceGroupName_clusterName_location. A fürt létrehozása során megadhatja a csomópont erőforráscsoportjához rendelt nevet. Azure Resource Manager-sablon használata esetén a tulajdonság használatával határozhatja meg a nodeResourceGroup nevet. Az Azure CLI használatakor a paramétert --node-resource-group a az aks create paranccsal használja, ahogyan az a következő példában is látható:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Az AKS-fürt törlésekor az AKS-erőforrás-szolgáltató automatikusan törli a csomópont erőforráscsoportját.

A csomópont erőforráscsoportja a következő korlátozásokkal rendelkezik:

  • A csomópont erőforráscsoporthoz nem adhat meg meglévő erőforráscsoportot.
  • Nem adhat meg másik előfizetést a csomópont erőforráscsoporthoz.
  • A fürt létrehozása után nem módosíthatja a csomópont erőforráscsoportjának nevét.
  • A csomópont erőforráscsoporton belül nem adhatja meg a felügyelt erőforrások nevét.
  • A csomópont erőforráscsoporton belül nem módosíthatja és nem törölheti a felügyelt erőforrások Azure-beli címkéit.

Az Azure által létrehozott címkék módosítása az AKS-fürt csomóponterőforrás-csoportjában lévő erőforrásokon nem támogatott művelet, amely megszakítja a szolgáltatásiszint-célkitűzést (SLO). Ha módosítja vagy törli az Azure által létrehozott címkéket vagy más erőforrástulajdonságokat a csomópont erőforráscsoportjában, váratlan eredményeket kaphat, például skálázási és frissítési hibákat. Az AKS kezeli az infrastruktúra életciklusát a csomópont erőforráscsoportjában, így a módosítások nem támogatott állapotba helyezik a fürtöt. További információ: Az AKS szolgáltatásszintű szerződést kínál?

Az AKS lehetővé teszi a csomópont erőforráscsoportban lévő erőforrásokra propagált címkék létrehozását és módosítását, és ezeket a címkéket a fürt létrehozásakor vagy frissítésekor is hozzáadhatja. Előfordulhat, hogy egyéni címkéket szeretne létrehozni vagy módosítani, például egy üzleti egység vagy költséghely hozzárendeléséhez. A felügyelt erőforráscsoporton hatókörrel rendelkező Azure-szabályzatokat is létrehozhat.

Ha csökkenteni szeretné a csomópont erőforráscsoportjában a fürtöket érintő változások esélyét, engedélyezheti a csomóponti erőforráscsoport zárolását , hogy megtagadási hozzárendelést alkalmazzon az AKS-erőforrásokra. További információ: Teljes mértékben felügyelt erőforráscsoport (előzetes verzió).

Figyelmeztetés

Ha nincs engedélyezve a csomóponterőforrás-csoport zárolása, közvetlenül módosíthatja a csomópont erőforráscsoportjának bármely erőforrását. Ha közvetlenül módosítja az erőforrásokat a csomópont erőforráscsoportjában, a fürt instabillá vagy nem válaszolhatóvá válhat.

Podok

A Kubernetes podokkal futtatja az alkalmazás példányait. Egyetlen pod az alkalmazás egyetlen példányát jelöli.

A podok általában 1:1-alapú leképezéssel rendelkeznek egy tárolóval. Speciális esetekben a podok több tárolót is tartalmazhatnak. A többtárolós podok ugyanazon a csomóponton vannak ütemezve, és lehetővé teszik a tárolók számára a kapcsolódó erőforrások megosztását.

Pod létrehozásakor definiálhat erőforrás-kérelmeket egy bizonyos mennyiségű CPU-ra vagy memóriára vonatkozóan. A Kubernetes Scheduler úgy próbálja teljesíteni a kérést, hogy a podokat úgy ütemezi, hogy az elérhető erőforrásokkal rendelkező csomóponton fusson. Megadhatja a maximális erőforráskorlátokat is, hogy a pod ne használjon túl sok számítási erőforrást a mögöttes csomópontból. Ajánlott eljárásunk az összes pod erőforráskorlátainak belefoglalása, hogy a Kubernetes Scheduler azonosíthassa a szükséges, engedélyezett erőforrásokat.

További információ: Kubernetes-podok és Kubernetes-podok életciklusa.

A pod egy logikai erőforrás, de az alkalmazás számítási feladatai a tárolókon futnak. A podok általában rövid élettartamú, eldobható erőforrások. Az egyénileg ütemezett podok hiányoznak a magas rendelkezésre állás és a redundancia kubernetes-funkciói közül. Ehelyett a Kubernetes-vezérlők, például az üzembehelyezési vezérlő üzembe helyezik és kezelik a podokat.

Üzembe helyezések és YAML-jegyzékek

Az üzembe helyezés azonos podokat jelöl, amelyeket a Kubernetes üzembehelyezési vezérlő felügyel. Az üzembe helyezés határozza meg a létrehozandó podreplikák számát. A Kubernetes Scheduler biztosítja, hogy a további podok kifogástalan állapotú csomópontokra legyenek ütemezve, ha a podok vagy csomópontok problémákba ütköznek. Az üzemelő példányokat frissítheti a podok, a tárolólemezkép vagy a csatolt tároló konfigurációjának módosításához.

Az üzembehelyezési vezérlő kezeli az üzembehelyezési életciklust, és a következő műveleteket hajtja végre:

  • Adott számú replikát ürít ki és zár le.
  • Replikákat hoz létre az új üzembehelyezési definícióból.
  • A folyamat addig folytatódik, amíg az üzembe helyezés összes replikája frissül.

Az AKS-ben a legtöbb állapot nélküli alkalmazásnak az egyes podok ütemezése helyett az üzembe helyezési modellt kell használnia. A Kubernetes figyelheti az üzembe helyezés állapotát és állapotát, hogy a szükséges számú replika fusson a fürtben. Ha egyénileg van ütemezve, a podok nem indulnak újra, ha problémát tapasztalnak, és nem ütemezik át őket kifogástalan állapotú csomópontokra, ha az aktuális csomópontjuk problémát tapasztal.

Nem szeretné megszakítani a felügyeleti döntéseket frissítési folyamattal, ha az alkalmazáshoz minimális számú elérhető példányra van szükség. A podkimaradási költségvetések határozzák meg, hogy egy üzemelő példány hány replikáját lehet levenni egy frissítés vagy csomópont frissítése során. Ha például öt replika van az üzemelő példányban, megadhat egy négyes podkimaradást, amely lehetővé teszi, hogy egyszerre csak egy replikát töröljön vagy ütemezzen újra. A poderőforrás-korlátokhoz hasonlóan ajánlott eljárásunk az olyan alkalmazások podkimaradási költségvetésének meghatározása, amelyeknél a replikák minimális száma mindig jelen van.

Az üzemelő példányok létrehozása és kezelése általában a vagy kubectl applya kubectl create . Az üzembe helyezést úgy hozhatja létre, hogy YAML formátumban definiál egy jegyzékfájlt. Az alábbi példa egy NGINX-webkiszolgáló alapszintű üzembehelyezési jegyzékfájlt mutat be:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

A YAML-jegyzékfájl üzembehelyezési specifikációinak részletezése a következő:

Specifikáció Leírás
.apiVersion Megadja az erőforrás létrehozásakor használni kívánt API-csoportot és API-erőforrást.
.kind Megadja a létrehozni kívánt erőforrás típusát.
.metadata.name Megadja az üzembe helyezés nevét. Ez a példa YAML-fájl futtatja az nginx-lemezképet a Docker Hubról.
.spec.replicas Megadja, hogy hány podot kell létrehozni. Ez a példa YAML-fájl három duplikált podot hoz létre.
.spec.selector Meghatározza, hogy az üzembe helyezés mely podokat érinti.
.spec.selector.matchLabels {key, value} párok térképét tartalmazza, amelyek lehetővé teszik, hogy az üzembe helyezés megkeresse és kezelje a létrehozott podokat.
.spec.selector.matchLabels.app Meg kell egyeznie .spec.template.metadata.labels.
.spec.template.labels Megadja az objektumhoz csatolt {key, value} párokat.
.spec.template.app Meg kell egyeznie .spec.selector.matchLabels.
.spec.spec.containers Megadja a podhoz tartozó tárolók listáját.
.spec.spec.containers.name A DNS-címkeként megadott tároló nevét adja meg.
.spec.spec.containers.image Megadja a tárolórendszerkép nevét.
.spec.spec.containers.ports Megadja a tárolóból közzéteendő portok listáját.
.spec.spec.containers.ports.containerPort Megadja a pod IP-címén közzéteendő portok számát.
.spec.spec.resources Megadja a tároló által igényelt számítási erőforrásokat.
.spec.spec.resources.requests Megadja a szükséges számítási erőforrások minimális mennyiségét.
.spec.spec.resources.requests.cpu Megadja a minimálisan szükséges processzormennyiséget.
.spec.spec.resources.requests.memory Megadja a minimálisan szükséges memóriamennyiséget.
.spec.spec.resources.limits Megadja az engedélyezett számítási erőforrások maximális mennyiségét. A kubelet kényszeríti ezt a korlátot.
.spec.spec.resources.limits.cpu Megadja a maximálisan engedélyezett processzormennyiséget. A kubelet kényszeríti ezt a korlátot.
.spec.spec.resources.limits.memory Megadja az engedélyezett memória maximális mennyiségét. A kubelet kényszeríti ezt a korlátot.

Összetettebb alkalmazások hozhatók létre úgy, hogy a YAML-jegyzékbe belevesznek olyan szolgáltatásokat, mint a terheléselosztók.

További információ: Kubernetes-környezetek.

Csomagkezelés a Helmel

A Helmt gyakran használják a Kubernetes-alkalmazások kezelésére. Az erőforrásokat olyan meglévő nyilvános Helm-diagramok létrehozásával és használatával helyezheti üzembe, amelyek az alkalmazáskód és a Kubernetes YAML-jegyzékek csomagolt verzióját tartalmazzák. A Helm-diagramokat tárolhatja helyileg vagy egy távoli adattárban, például egy Azure Container Registry Helm-diagram-adattárban.

A Helm használatához telepítse a Helm-ügyfelet a számítógépre, vagy használja a Helm-ügyfelet az Azure Cloud Shellben. Keressen vagy hozzon létre Helm-diagramokat, majd telepítse őket a Kubernetes-fürtbe. További információ: Meglévő alkalmazások telepítése a Helmrel az AKS-ben.

StatefulSets és DaemonSets

A Központi telepítési vezérlő a Kubernetes Schedulert használja, és replikákat futtat bármely elérhető, elérhető erőforrásokkal rendelkező csomóponton. Bár ez a megközelítés elegendő lehet állapot nélküli alkalmazásokhoz, az üzembehelyezési vezérlő nem ideális olyan alkalmazásokhoz, amelyek a következő specifikációkat igénylik:

  • Állandó elnevezési konvenció vagy tárolás.
  • Egy replika, amely a fürtön belüli egyes csomópontokon található.

Két Kubernetes-erőforrás azonban lehetővé teszi az ilyen típusú alkalmazások kezelését: StatefulSets és DaemonSets.

A StatefulSets az egyes pod-életciklusokon túl is fenntartja az alkalmazások állapotát. A DaemonSets biztosít egy futó példányt minden csomóponton a Kubernetes rendszerindítási folyamatának korai szakaszában.

StatefulSets

A modern alkalmazásfejlesztés gyakran állapot nélküli alkalmazásokat céloz meg. Az állapotalapú alkalmazásokhoz, például az adatbázis-összetevőkhöz hasonlóan a StatefulSeteket is használhatja. Az üzembe helyezésekhez hasonlóan a StatefulSet is létrehoz és kezel legalább egy azonos podot. A StatefulSet replikái az üzembe helyezési, méretezési, frissítési és megszüntetési műveletek kecses, szekvenciális megközelítését követik. Az elnevezési konvenció, a hálózatnevek és a tárterület megmarad, mivel a replikák ütemezve vannak egy StatefulSettel.

Az alkalmazást YAML formátumban is megadhatja a következővel kind: StatefulSet: . Innen a StatefulSet-vezérlő kezeli a szükséges replikák üzembe helyezését és kezelését. Az adatok az Azure Managed Disks vagy az Azure Files által biztosított állandó tárolóba írhatók. A StatefulSets esetén az alapul szolgáló állandó tároló akkor is megmarad, ha a StatefulSet törlődik.

További információ: Kubernetes StatefulSets.

Fontos

A StatefulSet replikái ütemezve vannak, és egy AKS-fürt bármely elérhető csomópontja között futnak. Ha gondoskodni szeretne arról, hogy a készlet legalább egy podja egy csomóponton fusson, inkább egy DaemonSetet kell használnia.

Démonkészletek

Adott naplógyűjtéshez vagy monitorozáshoz előfordulhat, hogy podot kell futtatnia az összes csomóponton, vagy egy csomópontkészletet. A DaemonSets használatával üzembe helyezhet egy vagy több azonos podot. A Démonkészlet-vezérlő biztosítja, hogy minden megadott csomópont a pod egy példányát futtassa.

A DaemonSet-vezérlő a fürt rendszerindítási folyamatának korai szakaszában ütemezheti a csomópontokon lévő podokat az alapértelmezett Kubernetes-ütemező elindítása előtt. Ez a képesség biztosítja, hogy a DaemonSet állapotú podok az üzembe helyezés vagy a StatefulSet hagyományos podjai előtt legyenek ütemezve.

A StatefulSetshez hasonlóan a DaemonSet is definiálható YAML-definíció kind: DaemonSetrészeként.

További információ: Kubernetes DaemonSets.

Feljegyzés

Ha a virtuális csomópontok bővítményt használja, a DaemonSets nem hoz létre podokat a virtuális csomóponton.

Névterek

A Kubernetes-erőforrások, például a podok és az üzemelő példányok logikailag névterekbe vannak csoportosítva az AKS-fürtök felosztásához, valamint az erőforrásokhoz való hozzáférés létrehozásához, megtekintéséhez vagy kezeléséhez. Létrehozhat például névtereket az üzleti csoportok elkülönítéséhez. A felhasználók csak a hozzájuk rendelt névtereken belüli erőforrásokat használhatják.

Kubernetes-névterek az erőforrások és alkalmazások logikai felosztásához

AKS-fürt létrehozásakor a következő névterek érhetők el:

Névtér Leírás
alapértelmezett Ahol a podok és az üzemelő példányok alapértelmezés szerint létrejönnek, ha nincs megadva. Kisebb környezetekben az alkalmazásokat közvetlenül az alapértelmezett névtérbe helyezheti üzembe további logikai elkülönítések létrehozása nélkül. Ha a Kubernetes API-val (például a kubernetes API-val kubectl get pods) kommunikál, a rendszer az alapértelmezett névteret használja, ha nincs megadva.
kube-system Ahol az alapvető erőforrások léteznek, például olyan hálózati funkciók, mint a DNS és a proxy, vagy a Kubernetes-irányítópult. Ebben a névtérben általában nem helyez üzembe saját alkalmazásokat.
kube-public Általában nincs használatban, használhatja arra, hogy az erőforrások az egész fürtben láthatók legyenek, és bármely felhasználó megtekintheti.

További információ: Kubernetes-névterek.

Következő lépések

Az alapvető Kubernetes- és AKS-fogalmakkal kapcsolatos további információkért tekintse meg az alábbi cikkeket: