Üzembe helyezési és fürt megbízhatósági ajánlott eljárások az Azure Kubernetes Service -hez (AKS)

Ez a cikk az Azure Kubernetes Service (AKS) számítási feladataihoz üzembe helyezési és fürtszintű fürtszintű fürt megbízhatóságának ajánlott eljárásait ismerteti. A cikk olyan fürtüzemeltetőknek és fejlesztőknek szól, akik az alkalmazások AKS-ben való üzembe helyezéséért és kezeléséért felelősek.

A cikkben ismertetett ajánlott eljárások a következő kategóriákba vannak rendezve:

Üzembe helyezési szintű ajánlott eljárások

Az alábbi üzembe helyezési szintű ajánlott eljárások segítenek biztosítani az AKS-számítási feladatok magas rendelkezésre állását és megbízhatóságát. Ezek az ajánlott eljárások helyi konfigurációk, amelyeket a podok és az üzemelő példányok YAML-fájljaiban implementálhat.

Pod-megszakítási költségvetések (PDF-ek)

Ajánlott eljárások útmutatója

Pod-megszakítási költségvetések (PDB-k) használatával biztosíthatja, hogy a podok minimális száma elérhető maradjon az önkéntes megszakítások, például a frissítési műveletek vagy a podok véletlen törlése során.

A podkimaradási költségvetések (PDB-k) segítségével meghatározhatja, hogyan reagálnak az üzemelő példányok vagy replikakészletek az önkéntes megszakítások, például a frissítési műveletek vagy a podok véletlen törlése során. PDF-ek használatával megadhat egy minimális vagy maximális elérhetetlen erőforrásszámot. A PDB-k csak az önkéntes fennakadások esetén érintik a kiürítési API-t.

Tegyük fel például, hogy fürtfrissítést kell végrehajtania, és már van definiálva PDB. A fürtfrissítés végrehajtása előtt a Kubernetes ütemezője biztosítja, hogy a PDB-ben meghatározott podok minimális száma elérhető. Ha a frissítés miatt a rendelkezésre álló podok száma a PDF-fájlokban meghatározott minimum alá csökkenne, az ütemező további podokat ütemez más csomópontokon, mielőtt engedélyezi a frissítés folytatását. Ha nem állít be PDB-t, az ütemező nem korlátozza azoknak a podoknak a számát, amelyek a frissítés során nem érhetők el, ami erőforrások hiányához és a fürt esetleges kimaradásához vezethet.

A következő PÉLDA PDB-definíciós fájlban a minAvailable mező meghatározza az önkéntes megszakítások során elérhető podok minimális számát. Az érték lehet abszolút szám (például 3) vagy a podok kívánt számának százalékos értéke (például 10%).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

További információ: A pdf-fájlok használatával való rendelkezésre állás megtervezése és az alkalmazás megszakítási költségvetésének megadása.

Pod CPU- és memóriakorlátjai

Ajánlott eljárások útmutatója

Állítsa be a pod cpu- és memóriakorlátjait az összes podra, hogy a podok ne használhassák fel a csomópont összes erőforrását, és hogy védelmet biztosítsanak a szolgáltatás fenyegetései, például a DDoS-támadások során.

A pod cpu- és memóriakorlátjai határozzák meg a pod által használható maximális processzor- és memóriamennyiséget. Ha egy pod túllépi a megadott korlátokat, a rendszer megjelöli az eltávolításra. További információ: A Kubernetes cpu-erőforrásegységei és a Kubernetes memóriaerőforrás-egységei.

A processzor- és memóriakorlátok beállítása segít fenntartani a csomópont állapotát, és minimalizálni a csomópont többi podjára gyakorolt hatást. Kerülje a podkorlát beállítását, amely magasabb, mint amit a csomópontok támogatnak. Minden AKS-csomópont meghatározott mennyiségű processzort és memóriát foglal le az alapvető Kubernetes-összetevők számára. Ha a csomópont által támogatottnál magasabb podkorlátot állít be, előfordulhat, hogy az alkalmazás túl sok erőforrást próbál felhasználni, és negatív hatással van a csomópont többi podjára. A fürtgazdáknak erőforráskvótákat kell beállítaniuk egy névtéren, amelyhez erőforrás-kérelmek és korlátok megadása szükséges. További információ: Erőforráskvóták kényszerítése az AKS-ben.

A következő példa poddefiníciós fájlban a resources szakasz a pod processzor- és memóriakorlátait állítja be:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

További információ: CPU-erőforrások hozzárendelése tárolókhoz és podokhoz , valamint memóriaerőforrások hozzárendelése tárolókhoz és podokhoz.

Leállítás előtti horgok

Ajánlott eljárások útmutatója

Adott esetben használjon leállítás előtti horgokat a tároló kecses leállításához.

A PreStop rendszer közvetlenül azelőtt hívja meg a horogot, hogy egy api-kérés vagy felügyeleti esemény, például a preemption, az erőforrás-versengés vagy az élesség/indítási mintavétel hibája miatt a tároló leáll. A horog hívása PreStop meghiúsul, ha a tároló már leállított vagy befejezett állapotban van, és a horognak a KIFEJEZÉS jel előtt kell befejeződnie a tároló elküldéséhez. A pod leállítási türelmi időszakának visszaszámlálása a PreStop horog végrehajtása előtt kezdődik, így a tároló végül a befejezési türelmi időszakon belül leáll.

Az alábbi példa poddefiníciós fájl bemutatja, hogyan használható horog a PreStop tároló kecses leállítására:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

További információkért lásd a tároló életciklus-horgait és a podok leállítását.

maxUnavailable

Ajánlott eljárások útmutatója

Adja meg, hogy egy gördülő frissítés során legfeljebb hány pod érhető el az maxUnavailable üzemelő példány mezője alapján, hogy a frissítés során a podok minimális száma elérhető maradjon.

A maxUnavailable mező a frissítési folyamat során elérhetetlen podok maximális számát adja meg. Az érték lehet abszolút szám (például 3) vagy a podok kívánt számának százalékos értéke (például 10%). maxUnavailable a gördülő frissítések során használt Delete API-ra vonatkozik.

Az alábbi példa üzembehelyezési jegyzék a maxAvailable mező használatával állítja be azoknak a podoknak a maximális számát, amelyek a frissítési folyamat során nem érhetők el:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade

További információ: Maximálisan nem érhető el.

Podtopológia oldalpárokra vonatkozó korlátozásai

Ajánlott eljárások útmutatója

A podtopológia elterjedtségének korlátozásai segítségével biztosíthatja, hogy a podok különböző csomópontokon vagy zónákban legyenek elosztva a rendelkezésre állás és a megbízhatóság javítása érdekében.

A podtopológia spread korlátozásával szabályozhatja, hogy a podok hogyan oszlanak el a fürtben a csomópontok topológiája alapján, és a podokat különböző csomópontok vagy zónák között terjessze el a rendelkezésre állás és a megbízhatóság javítása érdekében.

Az alábbi példa poddefiníciós fájl azt mutatja be, hogyan használható a mező a topologySpreadConstraints podok különböző csomópontok közötti elosztására:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

További információkért lásd a podtopológia oldalpárokra vonatkozó korlátozásait.

Készültségi, éles és indítási mintavételek

Ajánlott eljárások útmutatója

Szükség esetén konfigurálja a felkészültséget, az élettartamot és az indítási mintavételeket a nagy terhelés és az alacsonyabb tároló-újraindítások rugalmasságának javítása érdekében.

Készültségi mintavételek

A Kubernetesben a kubelet készültségi mintavételekkel jelzi, hogy egy tároló készen áll-e a forgalom elfogadására. A podok akkor tekinthetők késznek, ha az összes tárolója készen áll. Ha egy pod nem áll készen, a rendszer eltávolítja a szolgáltatás terheléselosztóiból. További információ: Készültségi mintavételek a Kubernetesben.

Az alábbi példa poddefiníciós fájl a készültségi mintavétel konfigurációját mutatja be:

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

További információ: Készültségi mintavételek konfigurálása.

Élőség-mintavételek

A Kubernetesben a kubelet élőségi mintavételekkel jelzi, hogy mikor kell újraindítani egy tárolót. Ha egy tároló nem tudja végrehajtani az élettartam-mintavételt, a tároló újraindul. További információ: Liveness Probes in Kubernetes.

Az alábbi példa poddefiníciós fájl egy élőségi mintavétel konfigurációját mutatja be:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Egy másik típusú élőségi mintavétel HTTP GET-kérést használ. Az alábbi példa poddefiníciós fájl egy HTTP GET kérelem élőségi mintavételi konfigurációját mutatja be:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

További információ: Az élőség-mintavételek konfigurálása és az élőség http-kérésének definiálása.

Indítási mintavételek

A Kubernetesben a kubelet indítási mintavételekkel jelzi, hogy mikor indult el egy tárolóalkalmazás. Az indítási mintavétel konfigurálásakor a készültségi és az élettartam-mintavételek nem indulnak el, amíg az indítási mintavétel sikeres nem lesz, így biztosítva, hogy a készültségi és az élettartam-mintavételek ne zavarják az alkalmazás indítását. További információ: Indítási mintavételek a Kubernetesben.

Az alábbi példa poddefiníciós fájl egy indítási mintavétel konfigurációját mutatja be:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Többreplika-alkalmazások

Ajánlott eljárások útmutatója

Helyezzen üzembe legalább két replikát az alkalmazásból, hogy magas rendelkezésre állást és rugalmasságot biztosítson csomópont-leépítési forgatókönyvekben.

A Kubernetesben az replicas üzemelő példány mezőjével megadhatja a futtatni kívánt podok számát. Az alkalmazás több példányának futtatása segít biztosítani a magas rendelkezésre állást és rugalmasságot a csomópontok leépítési forgatókönyveiben. Ha a rendelkezésre állási zónák engedélyezve vannak, a replicas mezővel megadhatja, hogy hány podot szeretne futtatni több rendelkezésre állási zónában.

Az alábbi példa poddefiníciós fájl bemutatja, hogyan használható a mező a replicas futtatni kívánt podok számának megadására:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

További információ: Ajánlott aktív-aktív magas rendelkezésre állású megoldás áttekintése az AKS-hez és replikákhoz az üzembe helyezési specifikációkban.

Ajánlott eljárások a fürt- és csomópontkészletek szintjén

Az alábbi fürt- és csomópontkészletszintű ajánlott eljárások segítenek biztosítani az AKS-fürtök magas rendelkezésre állását és megbízhatóságát. Ezeket az ajánlott eljárásokat az AKS-fürtök létrehozásakor vagy frissítésekor implementálhatja.

Rendelkezésreállási zónák

Ajánlott eljárások útmutatója

Az AKS-fürtök létrehozásakor több rendelkezésre állási zónát is használhat a magas rendelkezésre állás biztosításához a zónalebontási forgatókönyvekben. Ne feledje, hogy a fürt létrehozása után nem módosíthatja a rendelkezésre állási zóna konfigurációját.

A rendelkezésre állási zónák egy régióban lévő adatközpontok különálló csoportjai. Ezek a zónák elég közel vannak ahhoz, hogy alacsony késésű kapcsolatok legyenek egymáshoz, de elég messze vannak egymástól ahhoz, hogy csökkenjen annak a valószínűsége, hogy egynél több zónát érintenek a helyi kimaradások vagy időjárás. A rendelkezésre állási zónák használata segít az adatok szinkronizálásában és elérhetőségében a zónaleállási forgatókönyvekben. További információ: Futtatás több zónában.

Fürt automatikus skálázása

Ajánlott eljárások útmutatója

A fürt automatikus skálázásával biztosíthatja, hogy a fürt képes legyen kezelni a megnövekedett terhelést, és csökkentse a költségeket alacsony terhelés esetén.

Az AKS-ben az alkalmazásigényeknek való megfelelés érdekében előfordulhat, hogy módosítania kell a számítási feladatokat futtató csomópontok számát. A fürt automatikus skálázási összetevője figyeli a fürt azon podjait, amelyek erőforrás-korlátozások miatt nem ütemezhetők. Amikor a fürt automatikus skálázója problémákat észlel, felskálázza a csomópontkészlet csomópontjainak számát az alkalmazásigény kielégítése érdekében. Emellett rendszeresen ellenőrzi a csomópontokat, hogy nincs-e futó pod, és szükség szerint skálázza le a csomópontok számát. További információ: Fürt automatikus skálázása az AKS-ben.

A paramétert --enable-cluster-autoscaler AKS-fürt létrehozásakor használhatja a fürt automatikus skálázásának engedélyezéséhez, ahogyan az alábbi példában látható:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

A fürt automatikus skálázását egy meglévő csomópontkészleten is engedélyezheti, és a fürtszintű automatikus skálázási profil alapértelmezett értékeinek módosításával részletesebb adatokat konfigurálhat a fürt automatikus skálázási eszközéről.

További információ: A fürt automatikus skálázásának használata az AKS-ben.

Standard Load Balancer

Ajánlott eljárások útmutatója

A Standard Load Balancer használatával nagyobb megbízhatóságot és erőforrásokat, több rendelkezésre állási zónát, HTTP-mintavételt és funkciót támogathat több adatközpontban.

Az Azure-ban a Standard Load Balancer termékváltozat úgy van kialakítva, hogy a hálózati réteg forgalmának terheléselosztására legyen kialakítva, ha nagy teljesítményre és alacsony késésre van szükség. A Standard Load Balancer a nagy rugalmasság érdekében a régiókon belüli és a régiók közötti forgalmat és rendelkezésre állási zónákat irányítja. Az AKS-fürt létrehozásakor ajánlott és alapértelmezett termékváltozat a Standard termékváltozat.

Az alábbi példa a LoadBalancer Standard Load Balancert használó szolgáltatásjegyzéket mutatja be:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

További információ: Standard terheléselosztó használata az AKS-ben.

Rendszer-csomópontkészletek

Dedikált rendszercsomópontkészletek használata

Ajánlott eljárások útmutatója

A rendszercsomópont-készletek használatával biztosíthatja, hogy más felhasználói alkalmazások ne fussanak ugyanazon a csomóponton, ami erőforráshiányt és a rendszer podjait is érintheti.

Dedikált rendszercsomópont-készletek használatával biztosíthatja, hogy más felhasználói alkalmazás ne fusson ugyanazon a csomóponton, ami a versenyfeltételek miatt szűkös erőforrásokat és lehetséges fürtkimaradásokat okozhat. Dedikált rendszercsomópontkészlet használatához használhatja a CriticalAddonsOnly rendszercsomópont-készleten lévő fertőzöttet. További információ: Rendszercsomópontkészletek használata az AKS-ben.

Automatikus skálázás a rendszercsomópont-készletekhez

Ajánlott eljárások útmutatója

Konfigurálja a rendszercsomópont-készletek automatikus skálázási eszközét a csomópontkészlet minimális és maximális méretezési korlátainak beállításához.

A csomópontkészletek automatikus skálázási funkciójának használatával konfigurálhatja a csomópontkészlet minimális és maximális méretezési korlátait. A rendszercsomópont-készletnek mindig képesnek kell lennie a skálázásra a rendszer podok igényeinek megfelelően. Ha a rendszercsomópont-készlet nem tud skálázni, a fürt elfogy az erőforrásokból az ütemezés, a skálázás és a terheléselosztás kezeléséhez, ami nem válaszoló fürthöz vezethet.

További információ: A fürt automatikus skálázásának használata csomópontkészleteken.

Rendszercsomópont-készletenként legalább három csomópont

Ajánlott eljárások útmutatója

Győződjön meg arról, hogy a rendszercsomópontok készletei legalább három csomóponttal rendelkeznek a rögzítési/frissítési forgatókönyvek elleni rugalmasság biztosítása érdekében, ami a csomópontok újraindításához vagy leállításához vezethet.

A rendszercsomópont-készletek rendszer podok futtatására szolgálnak, például a kube-proxy, a coredns és az Azure CNI beépülő modul. Javasoljuk, hogy győződjön meg arról, hogy a rendszercsomópont-készletek legalább három csomóponttal rendelkeznek a rögzítési/frissítési forgatókönyvek elleni rugalmasság biztosítása érdekében, ami a csomópontok újraindításához vagy leállításához vezethet. További információ: Rendszercsomópontok készleteinek kezelése az AKS-ben.

Gyorsított hálózatkezelés

Ajánlott eljárások útmutatója

A gyorsított hálózatkezeléssel kisebb késést, kisebb jittert és csökkentett processzorhasználatot biztosíthat a virtuális gépeken.

A gyorsított hálózatkezelés lehetővé teszi az egygyökerű I/O virtualizálást (SR-IOV) a támogatott virtuálisgép-típusok esetében, ami jelentősen javítja a hálózati teljesítményt.

Az alábbi ábra bemutatja, hogyan kommunikál két virtuális gép a gyorsított hálózatkezelés nélkül:

További információ: Gyorsított hálózatkezelés – áttekintés.

Képverziók

Ajánlott eljárások útmutatója

A képek nem használhatják a címkét latest .

Tárolórendszerképek címkéi

A tárolólemezképek címkéjének latest használata kiszámíthatatlan működéshez vezethet, és megnehezíti a rendszerkép fürtben való futtatásának nyomon követését. Ezeket a kockázatokat minimálisra csökkentheti, ha a buildeléskor és futásidőben integrálja és futtatja a tárolókban a vizsgálati és szervizelési eszközöket. További információ: Ajánlott eljárások a tárolólemezkép-kezeléshez az AKS-ben.

Csomópontrendszerkép frissítései

Az AKS több automatikus frissítési csatornát biztosít a csomópont operációs rendszer lemezképeinek frissítéséhez. Ezekkel a csatornák használatával szabályozhatja a frissítések időzítését. Javasoljuk, hogy csatlakozzon ezekhez az automatikus frissítési csatornákhoz, hogy a csomópontok a legújabb biztonsági javításokat és frissítéseket futtassa. További információ: Csomópont operációsrendszer-lemezképeinek automatikus frissítése az AKS-ben.

Standard szint éles számítási feladatokhoz

Ajánlott eljárások útmutatója

A standard szint használata a termékterhelésekhez a fürt megbízhatóságának és erőforrásainak növelése, a fürt legfeljebb 5000 csomópontjának támogatása, valamint az alapértelmezetten engedélyezett üzemidő-SLA. Ha LTS-re van szüksége, fontolja meg a Prémium szint használatát.

Az Azure Kubernetes Service (AKS) standard szintje pénzügyileg támogatott, 99,9%-os üzemidejű szolgáltatásiszint-szerződést (SLA) biztosít az éles számítási feladatokhoz. A standard szint nagyobb megbízhatóságot és erőforrásokat biztosít a fürtökhöz, akár 5000 csomópontot is támogat egy fürtben, és alapértelmezés szerint engedélyezve van az üzemidős SLA. További információ: Tarifacsomagok az AKS-fürtkezeléshez.

Azure CNI dinamikus IP-foglaláshoz

Ajánlott eljárások útmutatója

Konfigurálja az Azure CNI-t a dinamikus IP-foglaláshoz a jobb IP-kihasználtság és az AKS-fürtök IP-kimerülésének megakadályozása érdekében.

Az Azure CNI dinamikus IP-foglalási képessége a pod IP-címeit az AKS-fürtöt üzemeltető alhálózattól eltérő alhálózatról foglalja le, és a következő előnyöket nyújtja:

• Jobb IP-kihasználtság: Az IP-címek dinamikusan vannak lefoglalva a pod alhálózatából származó fürt podjaihoz. Ez a fürt IP-címeinek jobb kihasználtságát eredményezi a hagyományos CNI-megoldáshoz képest, amely minden csomóponthoz statikusan kiosztja az IP-címeket.
• Méretezhető és rugalmas: A csomópont- és pod-alhálózatok egymástól függetlenül méretezhetők. Egyetlen pod-alhálózat megosztható egy fürt több csomópontkészletén vagy több, ugyanabban a virtuális hálózaton üzembe helyezett AKS-fürtön. A csomópontkészlethez külön pod-alhálózatot is konfigurálhat.
• Nagy teljesítmény: Mivel a pod virtuális hálózati IP-címekhez van rendelve, közvetlen kapcsolattal rendelkeznek a virtuális hálózat többi fürt podja és erőforrásai felé. A megoldás a teljesítmény romlása nélkül támogatja a nagy méretű fürtöket.
• Különálló virtuálishálózat-házirendek podokhoz: Mivel a podok külön alhálózattal rendelkeznek, külön virtuális hálózati házirendeket konfigurálhat hozzájuk, amelyek eltérnek a csomópontszabályzatoktól. Ez számos hasznos forgatókönyvet tesz lehetővé, például lehetővé teszi az internetkapcsolatot csak a podok és nem a csomópontok számára, a csomópontkészletek podjának forrás IP-címét egy Azure NAT-átjáró használatával, és NSG-k használatával szűri a csomópontkészletek közötti forgalmat.
• Kubernetes hálózati szabályzatok: Az Azure Hálózati szabályzatok és a Calico is ezzel a megoldással dolgozik.

További információ: Az Azure CNI hálózatkezelésének konfigurálása ip-címek dinamikus lefoglalásához és továbbfejlesztett alhálózati támogatáshoz.

v5 termékváltozatú virtuális gépek

Ajánlott eljárások útmutatója

V5-ös virtuálisgép-termékváltozatok használata a frissítések során és után nyújtott teljesítmény javításához, az általános hatás csökkentéséhez és az alkalmazások megbízhatóbb kapcsolatához.

Az AKS csomópontkészleteihez használjon v5-ös termékváltozatú virtuális gépeket rövid élettartamú operációsrendszer-lemezekkel, hogy elegendő számítási erőforrást biztosítson a kube-system podokhoz. További információ: Ajánlott eljárások a teljesítményhez és a nagy számítási feladatok skálázására az AKS-ben.

Ne használjon B sorozatú virtuális gépeket

Ajánlott eljárások útmutatója

Ne használjon B sorozatú virtuális gépeket az AKS-fürtökhöz, mert alacsony a teljesítményük, és nem működnek jól az AKS-sel.

A B sorozatú virtuális gépek alacsony teljesítményűek, és nem működnek jól az AKS-sel. Ehelyett v5-ös termékváltozatú virtuális gépek használatát javasoljuk.

Prémium szintű lemezek

Ajánlott eljárások útmutatója

A Premium Disks használatával 99,9%-os rendelkezésre állást érhet el egy virtuális gépen (virtuális gépen).

Az Azure Premium Disks konzisztens almilliszekundumos lemezkéséssel és magas IOPS-sel rendelkezik. A prémium lemezeket úgy tervezték, hogy alacsony késést, nagy teljesítményt és konzisztens lemezteljesítményt biztosítsanak a virtuális gépek számára.

Az alábbi PÉLDA YAML-jegyzék egy prémium szintű lemez tárolási osztálydefinícióját mutatja be:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

További információ: Azure Premium SSD v2-lemezek használata az AKS-en.

Container Insights

Ajánlott eljárások útmutatója

Engedélyezze a Container Insights számára a tárolóalapú alkalmazások teljesítményének monitorozását és diagnosztizálását.

A Container Insights az Azure Monitor egyik funkciója, amely az AKS-ből gyűjti és elemzi a tárolónaplókat. Az összegyűjtött adatokat nézetek és előre összeállított munkafüzetek gyűjteményével elemezheti.

A Container Insights monitorozását különböző módszerekkel engedélyezheti az AKS-fürtön. Az alábbi példa bemutatja, hogyan engedélyezheti a Container Insights monitorozását egy meglévő fürtön az Azure CLI használatával:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

További információt a Kubernetes-fürtök figyelésének engedélyezése című témakörben talál.

Azure Policy

Ajánlott eljárások útmutatója

Az AKS-fürtökre vonatkozó biztonsági és megfelelőségi követelmények alkalmazása és betartatása az Azure Policy használatával.

Az Azure Policy használatával beépített biztonsági szabályzatokat alkalmazhat és érvényesíthet az AKS-fürtökön. Az Azure Policy segít kikényszeríteni a szervezeti szabványokat, és felmérni a megfelelőséget. Az AKS Azure Policy bővítményének telepítése után egyéni szabályzatdefiníciókat vagy kezdeményezésnek nevezett szabályzatdefiníciókat alkalmazhat a fürtökre.

További információ: AKS-fürtök védelme az Azure Policy használatával.

Következő lépések

Ez a cikk az Azure Kubernetes Service- (AKS-) fürtök üzembe helyezésének és megbízhatóságának ajánlott eljárásait ismerteti. További ajánlott eljárásokért tekintse meg az alábbi cikkeket:

• Magas rendelkezésre állás és vészhelyreállítás áttekintése az AKS-hez
• AKS-fürtök nagy léptékű futtatása
• AKS-fürt alaparchitektúrája