Gyakori kérdések az Azure Kubernetes Service-szel (AKS) kapcsolatban

Ez a cikk az Azure Kubernetes Service-sel (AKS) kapcsolatos gyakori kérdésekre ad választ.

Jelenleg mely Azure-régiók biztosítják az AKS-t?

Az elérhető régiók teljes listáját az AKS-régiók és a rendelkezésre állás című témakörben találja.

Eloszthatok egy AKS-fürtöt régiók között?

Szám Az AKS-fürtök regionális erőforrások, és nem terjedhetnek ki régiókra. Az üzletmenet-folytonosságra és vészhelyreállításra vonatkozó ajánlott eljárásokat a több régiót tartalmazó architektúra létrehozásával kapcsolatos útmutatásért tekintheti meg.

Eloszthatok egy AKS-fürtöt a rendelkezésre állási zónák között?

Igen. Az AKS-fürtöket egy vagy több rendelkezésre állási zónábanhelyezheti üzembe az őket támogató régiókban.

Korlátozhatjam, hogy ki fér hozzá a Kubernetes API-kiszolgálóhoz?

Igen. Az API-kiszolgálóhoz való hozzáférés korlátozásának két lehetősége van:

• Ha nyilvános végpontot szeretne fenntartani az API-kiszolgálóhoz, de korlátozni szeretné a hozzáférést megbízható IP-tartományokhoz, használja az API Server által engedélyezett IP-tartományokat .
• Használjon privát fürtöt, ha korlátozni szeretné, hogy az API-kiszolgáló csak a virtuális hálózaton belülről legyen elérhető.

Rendelkezhetek különböző virtuálisgép-méretekkel egyetlen fürtben?

Igen, több csomópontkészlet létrehozásával különböző virtuálisgép-méreteket használhat az AKS-fürtben.

Biztonsági frissítések vannak alkalmazva az AKS-ügynökcsomópontokra?

Az AKS minden héten kijavítja a "szállítói javítással" rendelkező önéletrajzokat. A javítás nélküli CVE-k a "szállítói javításra" várnak, mielőtt javítható lenne. Az AKS-rendszerképek 30 napon belül automatikusan frissülnek. Javasoljuk, hogy rendszeresen alkalmazza a frissített csomópontrendszerképet, hogy a legújabb javított rendszerképek és operációsrendszer-javítások mind alkalmazva legyenek és naprakészek legyenek. Ezt az alábbi módszerek egyikével teheti meg:

• Manuálisan, az Azure Portalon vagy az Azure CLI-vel.
• Az AKS-fürt frissítésével. A fürt automatikusan frissíti a kordon- és csatornacsomópontokat , majd online állapotba hoz egy új csomópontot a legújabb Ubuntu-lemezképpel és egy új javításverzióval vagy egy kisebb Kubernetes-verzióval. További információt az AKS-fürtök frissítését ismertető szakaszban talál.
• Csomópontrendszerkép-frissítéssel.

Mi a tárolólemezkép méretkorlátja az AKS-ben?

Az AKS nem állít be korlátot a tárolólemezkép méretére. Fontos azonban tisztában lenni azzal, hogy minél nagyobb a kép, annál nagyobb a memóriaigény. A nagyobb méret meghaladhatja az erőforráskorlátokat vagy a feldolgozó csomópontok teljes rendelkezésre álló memóriáját. Alapértelmezés szerint egy AKS-fürt virtuálisgép-méretének Standard_DS2_v2 memóriája 7 GiB értékre van állítva.

Ha egy tárolólemezkép túl nagy, például a Terabájt (TBs) tartományban, előfordulhat, hogy a Kubelet nem tudja lekérni a tárolóregisztrációs adatbázisból egy csomópontra a lemezterület hiánya miatt.

Windows Server-csomópontok

Windows Server-csomópontok esetén a Windows Update nem fut automatikusan, és nem alkalmazza a legújabb frissítéseket. A Windows Update kiadási ciklusa és a saját érvényesítési folyamata körüli rendszeres ütemezés szerint végezze el a frissítést az AKS-fürtön lévő fürtön és a Windows Server csomópontkészletén. Ez a frissítési folyamat létrehozza a legújabb Windows Server rendszerképet és javításokat futtató csomópontokat, majd eltávolítja a régebbi csomópontokat. További információ erről a folyamatról: Csomópontkészlet frissítése az AKS-ben.

Vannak olyan biztonsági fenyegetések, amelyek az AKS-t célják, amelyekkel tisztában kell lennem?

A Microsoft útmutatást nyújt a számítási feladatok biztonságossá tételéhez olyan szolgáltatásokon keresztül, mint a Microsoft Defender for Containers. A következő biztonsági fenyegetés az AKS-hez és a Kuberneteshez kapcsolódik, amellyel tisztában kell lennie:

• Az új nagy léptékű kampány a Kubeflow-t célozza meg (2021. június 8.).

Hogyan kommunikál a felügyelt vezérlősík a csomópontjaimmal?

Az AKS biztonságos alagútkommunikációval teszi lehetővé az api-kiszolgáló és az egyes csomópontok kubeletjei számára a kommunikációt még külön virtuális hálózatokon is. Az alagút mTLS-titkosítással van védve. Az AKS által használt jelenlegi fő alagút a Konnectivity, korábbi nevén apiserver-network-proxy. Ellenőrizze, hogy az összes hálózati szabály az Azure-beli szükséges hálózati szabályokat és teljes tartományneveket követi-e.

Használhatják a podok az API-kiszolgáló teljes tartománynevét a fürt IP-címe helyett?

Igen, hozzáadhatja a megjegyzést kubernetes.azure.com/set-kube-service-host-fqdn a podokhoz, hogy a változót a KUBERNETES_SERVICE_HOST fürtszolgáltatás IP-címe helyett az API-kiszolgáló tartománynevére állítsa. Ez olyan esetekben hasznos, amikor a fürt kiesik egy 7. rétegbeli tűzfalon keresztül, például az Azure Firewall alkalmazásszabályokkal való használatakor.

Miért jön létre két erőforráscsoport az AKS-sel?

Az AKS számos Azure-infrastruktúra-erőforrásra épül, beleértve a virtuálisgép-méretezési csoportokat, a virtuális hálózatokat és a felügyelt lemezeket. Ezek az integrációk lehetővé teszik az Azure-platform számos alapvető funkciójának alkalmazását az AKS által biztosított felügyelt Kubernetes-környezetben. A legtöbb Azure-beli virtuálisgép-típus például közvetlenül az AKS-sel használható, az Azure Reservations pedig arra használható, hogy automatikusan kedvezményeket kapjon ezekre az erőforrásokra.

Az architektúra engedélyezéséhez minden AKS-telepítés két erőforráscsoportra terjed ki:

1. Hozza létre az első erőforráscsoportot. Ez a csoport csak a Kubernetes szolgáltatás erőforrását tartalmazza. Az AKS-erőforrás-szolgáltató automatikusan létrehozza a második erőforráscsoportot az üzembe helyezés során. A második erőforráscsoportra példa a MC_myResourceGroup_myAKSCluster_eastus. A második erőforráscsoport nevének megadásáról a következő szakaszban olvashat.

2. A második erőforráscsoport, az úgynevezett csomópont-erőforráscsoport a fürthöz társított összes infrastruktúra-erőforrást tartalmazza. Ezek az erőforrások közé tartoznak a Kubernetes-csomópont virtuális gépei, a virtuális hálózatkezelés és a tárolás. Alapértelmezés szerint a csomópont erőforráscsoportjának neve MC_myResourceGroup_myAKSCluster_eastus. Az AKS automatikusan törli a csomópont erőforráscsoportját, amikor törli a fürtöt. Ezt a fürtöt csak olyan erőforrásokhoz érdemes használni, amelyek megosztják a fürt életciklusát.

   Feljegyzés

   Az AKS-fürt csomópont-erőforráscsoportjában lévő erőforrások módosítása nem támogatott művelet, és fürtműveleti hibákat fog okozni. Megakadályozhatja, hogy módosításokat hajtson végre a csomópont erőforráscsoportja, ha megakadályozza, hogy a felhasználók módosítsák az AKS-fürt által felügyelt erőforrásokat .

Megadhatom a saját nevemet az AKS-csomópont erőforráscsoportjának?

Igen. Alapértelmezés szerint az AKS elnevezi a csomópont erőforráscsoportját MC_resourcegroupname_clustername_location, de saját nevet is megadhat.

Saját erőforráscsoport nevének megadásához telepítse az aks-preview Azure CLI-bővítmény 0.3.2-es vagy újabb verzióját. Amikor AKS-fürtöt hoz létre a az aks create parancs használatával, használja a --node-resource-group paramétert, és adja meg az erőforráscsoport nevét. Ha Azure Resource Manager-sablont használ egy AKS-fürt üzembe helyezéséhez, az erőforráscsoport nevét a nodeResourceGroup tulajdonság használatával határozhatja meg.

• Az Azure-erőforrás-szolgáltató automatikusan létrehozza a másodlagos erőforráscsoportot.
• Egyéni erőforráscsoportnevet csak a fürt létrehozásakor adhat meg.

A csomópont erőforráscsoportjának használatakor vegye figyelembe, hogy nem:

• Adjon meg egy meglévő erőforráscsoportot a csomópont erőforráscsoporthoz.
• Adjon meg egy másik előfizetést a csomópont erőforráscsoporthoz.
• Módosítsa a csomópont erőforráscsoportjának nevét a fürt létrehozása után.
• Adja meg a csomópont erőforráscsoporton belüli felügyelt erőforrások nevét.
• A csomópont erőforráscsoportban lévő felügyelt erőforrások Azure által létrehozott címkéinek módosítása vagy törlése. További információt a következő szakaszban talál.

Módosíthatom az AKS-erőforrások címkéit és egyéb tulajdonságait a csomópont erőforráscsoportjában?

Előfordulhat, hogy váratlan skálázási és frissítési hibák lépnek fel, ha módosítja vagy törli az Azure által létrehozott címkéket és más erőforrástulajdonságokat a csomópont erőforráscsoportjában. Az AKS lehetővé teszi a végfelhasználók által létrehozott egyéni címkék létrehozását és módosítását, és ezeket a címkéket csomópontkészlet létrehozásakor 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. Egy másik lehetőség az Azure-szabályzatok létrehozása hatókörrel a felügyelt erőforráscsoporton.

Az Azure által létrehozott címkék a megfelelő Azure-szolgáltatásokhoz jönnek létre, és mindig engedélyezve kell lenniük. Az AKS-hez a címkék és k8s-azure a aks-managed címkék tartoznak. 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). További információ: Az AKS szolgáltatásszintű szerződést kínál?

Feljegyzés

Korábban a "Tulajdonos" címkenév fenntartotta az AKS számára a loadbalancer előtérbeli IP-címéhez hozzárendelt nyilvános IP-címet. Most a szolgáltatások az előtagot használják aks-managed . Örökölt erőforrások esetén ne használja az Azure-szabályzatokat a "Tulajdonos" címkenév alkalmazásához. Ellenkező esetben az AKS-fürt üzembe helyezési és frissítési műveleteinek összes erőforrása megszakad. Ez nem vonatkozik az újonnan létrehozott erőforrásokra.

Milyen Kubernetes-belépési vezérlőket támogat az AKS? Felveheti vagy eltávolíthatja a beléptető vezérlőket?

Az AKS a következő beléptető vezérlőket támogatja:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutációAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Jelenleg nem módosíthatja a belépési vezérlők listáját az AKS-ben.

Használhatok beléptető webhookokat az AKS-en?

Igen, a belépésvezérlő webhookjait használhatja az AKS-en. Javasoljuk, hogy zárja ki a belső AKS-névtereket, amelyek a vezérlősík címkéjével vannak megjelölve. Például:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

Az AKS tűzfala az API-kiszolgáló kimenő forgalmát teszi elérhetővé, így a beléptető webhookoknak elérhetőnek kell lenniük a fürtön belülről.

Hatással lehetnek a beléptető vezérlő webhookjai a kube-rendszerre és a belső AKS-névterekre?

Annak érdekében, hogy megvédje a rendszer stabilitását, és megakadályozza, hogy az egyéni beléptető vezérlők hatással legyen a kube-rendszer belső szolgáltatásaira, az AKS névtér rendelkezik egy Beléptető érvényesítővel, amely automatikusan kizárja a kube-system és az AKS belső névtereit. Ez a szolgáltatás biztosítja, hogy az egyéni beléptető vezérlők ne befolyásolják a Kube-rendszerben futó szolgáltatásokat.

Ha az egyéni belépési webhookok támogatásához kritikus használati eset áll fenn a Kube-rendszeren való üzembe helyezéshez (nem ajánlott), akkor a következő címkét vagy széljegyzetet is hozzáadhatja, hogy a Belépés kényszerítő figyelmen kívül hagyja azt.

Címke: "admissions.enforcer/disabled": "true" vagy széljegyzet: "admissions.enforcer/disabled": true

Az Azure Key Vault integrálva van az AKS-sel?

Az Azure Key Vault-szolgáltató a Secrets Store CSI-illesztőprogramhoz az Azure Key Vault Natív integrációját biztosítja az AKS-be.

Futtathatok Windows Server-tárolókat az AKS-en?

Igen, a Windows Server-tárolók elérhetők az AKS-ben. Ha Windows Server-tárolókat szeretne futtatni az AKS-ben, hozzon létre egy csomópontkészletet, amely vendég operációs rendszerként a Windows Servert futtatja. A Windows Server-tárolók csak a Windows Server 2019-et használhatják. Első lépésként tekintse meg az AKS-fürt létrehozása Windows Server-csomópontkészlettel című témakört.

A Csomópontkészlet Windows Server-támogatása bizonyos korlátozásokat tartalmaz, amelyek a Kubernetes-projektben a Windows Server felsőbb rétegéhez tartoznak. További információ ezekről a korlátozásokról: Windows Server-tárolók az AKS-korlátozásokban.

Az AKS szolgáltatásszintű szerződést kínál?

Az AKS SLA-garanciákat biztosít a Standard tarifacsomagban az Uptime SLA funkcióval.

Az ingyenes tarifacsomag nem rendelkezik társított szolgáltatásiszint-szerződéssel, de 99,5%-os szolgáltatásiszint-célkitűzéssel rendelkezik. Átmeneti csatlakozási problémák figyelhetők meg, ha frissítés, nem megfelelő állapotú aláfedő csomópontok, platformkarbantartás, egy alkalmazás túlterheli az API-kiszolgálót kérésekkel stb. Kritikus fontosságú és éles számítási feladatok esetén, vagy ha a számítási feladat nem tolerálja az API Server újraindítását, javasoljuk, hogy használja a Standard szintet, amely tartalmazza az Uptime SLA-t.

Alkalmazhatok Azure-foglalási kedvezményeket az AKS-ügynökcsomópontjaimra?

Az AKS-ügynökcsomópontok számlázása standard Azure-beli virtuális gépekként van kiszámlázva. Ha az AKS-ben használt virtuálisgép-mérethez vásárolt Azure-foglalásokat , a rendszer automatikusan alkalmazza ezeket a kedvezményeket.

Áthelyezhetem/migrálhatom a fürtöt az Azure-bérlők között?

Az AKS-fürt bérlők közötti áthelyezése jelenleg nem támogatott.

Áthelyezhetem/migrálhatom a fürtöt az előfizetések között?

A fürtök előfizetések közötti áthelyezése jelenleg nem támogatott.

Áthelyezhetem az AKS-fürtöket az aktuális Azure-előfizetésből egy másikba?

Az AKS-fürt és a hozzá tartozó erőforrások Azure-előfizetések közötti áthelyezése nem támogatott.

Áthelyezhetem az AKS-fürt vagy az AKS-infrastruktúra erőforrásait más erőforráscsoportokba, vagy átnevezhetem őket?

Az AKS-fürt és a hozzá tartozó erőforrások áthelyezése vagy átnevezése nem támogatott.

Miért tart ilyen sokáig a fürt törlése?

A legtöbb fürtöt a rendszer felhasználói kérésre törli. Bizonyos esetekben, különösen azokban az esetekben, amikor saját erőforráscsoportot hoz létre, vagy kereszt-RG feladatokat hajt végre, a törlés több időt vehet igénybe, vagy akár sikertelen is lehet. Ha a törléssel kapcsolatos probléma merül fel, ellenőrizze, hogy nincsenek-e zárolások az RG-n, hogy az RG-n kívüli erőforrások nem kapcsolódnak-e az RG-hez, és így tovább.

Miért tart ilyen sokáig a fürt létrehozása/frissítése?

Ha problémákat tapasztal a fürtműveletek létrehozásával és frissítésével kapcsolatban, győződjön meg arról, hogy nincsenek hozzárendelt szabályzatok vagy szolgáltatáskorlátozások, amelyek megakadályozhatják, hogy az AKS-fürt kezelje az erőforrásokat( például virtuális gépeket, terheléselosztókat, címkéket stb.).

Visszaállíthatom a fürtöt a törlés után?

Nem, a törlés után nem állíthatja vissza a fürtöt. A fürt törlésekor a csomópont erőforráscsoportja és annak összes erőforrása is törlődik. A második erőforráscsoportra példa a MC_myResourceGroup_myAKSCluster_eastus.

Ha meg szeretné tartani bármelyik erőforrását, a fürt törlése előtt helyezze át őket egy másik erőforráscsoportba. Ha védelmet szeretne biztosítani a véletlen törlésekkel szemben, zárolhatja a fürterőforrásokat üzemeltető AKS által felügyelt erőforráscsoportot a Csomópont erőforráscsoport zárolásával.

Mi a platformtámogatás, és mit tartalmaz?

A platformtámogatás csökkentett támogatási csomag a nem támogatott "N-3" verziójú fürtökhöz. A platformtámogatás csak az Azure-infrastruktúra támogatását tartalmazza. A platformtámogatás nem tartalmaz semmit az alábbiakhoz kapcsolódóan:

• A Kubernetes funkciói és összetevői
• Fürt vagy csomópontkészlet létrehozása
• Gyorsjavítások
• Hibajavítások
• Biztonsági javítások
• Kivezetett összetevők

A korlátozásokról további információt a platform támogatási szabályzatában talál.

Az AKS a Kubernetes kiadásaira és javításaira támaszkodik, amely egy nyílt forráskódú projekt, amely csak három alverzióból álló csúsztatóablakot támogat. Az AKS csak akkor tud teljes körű támogatást biztosítani, ha ezeket a verziókat a felsőbb rétegben szervizelik. Mivel nincs több javítás a felsőbb rétegben, az AKS ezeket a verziókat vagy elágazás nélkül hagyhatja. Ennek a korlátozásnak köszönhetően a platformtámogatás nem támogatja a kubernetes upstreamre való támaszkodást.

Az AKS automatikusan frissíti a nem támogatott fürtöket?

Az AKS automatikus frissítést kezdeményez a nem támogatott fürtök esetében. Ha egy n-3 verziójú fürt (ahol n a legújabb támogatott AKS GA alverzió) n-4-re csökken, az AKS automatikusan n-2-re frissíti a fürtöt, hogy megmaradjon az AKS támogatási szabályzatában. Alapértelmezés szerint a platform által támogatott fürtök automatikus frissítése támogatott verzióra engedélyezve van.

A Kubernetes 1.25-ös verziójának frissítése például az 1.26-os verzióra a 1.29-es GA-kiadás során. A fennakadások minimalizálása érdekében állítsa be a karbantartási időszakokat. Az automatikus frissítési csatornák részleteiért lásd az automatikus frissítési csatornákat.

Ha "NodeLost" vagy "Ismeretlen" állapotú pod/üzemelő példányok vannak, frissíthetem a fürtöt?

Igen, de nem javasoljuk. Frissítéseket kell végrehajtania, ha a fürt állapota ismert és kifogástalan.

Ha van egy fürtem, amely egy vagy több csomópontot nem kifogástalan állapotban tart, vagy le van állítva, elvégezhetem a frissítést?

Nem, a frissítés előtt törölje/távolítsa el a sikertelen állapotú csomópontokat vagy más módon a fürtből.

Fürtök törlését futtattam, de a hiba jelenik meg [Errno 11001] getaddrinfo failed

Ez a hiba leggyakrabban akkor fordul elő, ha egy vagy több hálózati biztonsági csoport (NSG) még használatban van, amelyek a fürthöz vannak társítva. Távolítsa el őket, és próbálkozzon újra a törlési kísérlettel.

Futtattam egy frissítést, de most a podok összeomlási ciklusokban vannak, és a készültségi mintavételek meghiúsulnak?

Ellenőrizze, hogy a szolgáltatásnév nem járt-e le. Lásd: Az AKS szolgáltatásnév és az AKS frissítési hitelesítő adatai.

A fürt működik, de hirtelen nem tud LoadBalancereket, PVC-ket csatlakoztatni stb.

Ellenőrizze, hogy a szolgáltatásnév nem járt-e le. Lásd: Az AKS szolgáltatásnév és az AKS frissítési hitelesítő adatai.

Skálázhatom az AKS-fürtöt nullára?

A futó AKS-fürtöket teljesen leállíthatja, így megtakaríthatja a megfelelő számítási költségeket. Emellett dönthet úgy is, hogy az összes vagy adott User csomópontkészletet 0-ra skálázza vagy automatikusan skálázza, és csak a szükséges fürtkonfigurációt tartja fenn.

A rendszercsomópontkészleteket nem lehet közvetlenül nullára méretezni.

Használhatom a virtuálisgép-méretezési csoport API-jait a manuális skálázáshoz?

Nem, a virtuálisgép-méretezési csoport API-kkal végzett skálázási műveletek nem támogatottak. Használja az AKS API-kat (az aks scale).

Használhatok virtuálisgép-méretezési csoportokat a zéró csomópontokra való manuális skálázáshoz?

Nem, a virtuálisgép-méretezési csoport API-kkal végzett skálázási műveletek nem támogatottak. Az AKS API-val nulla nem rendszercsomópont-készletre skálázhat, vagy leállíthatja a fürtöt .

Leállíthatom vagy megszüntethetem az összes virtuális gépem lefoglalását?

Bár az AKS rugalmassági mechanizmusokkal rendelkezik, hogy ellenálljon egy ilyen konfigurációnak, és helyreállítsa azt, ez nem támogatott konfiguráció. Állítsa le helyette a fürtöt .

Használhatok egyéni virtuálisgép-bővítményeket?

Nem, az AKS egy menedzselt szolgáltatás, és az IaaS-erőforrások manipulálása nem támogatott. Egyéni összetevők telepítéséhez használja a Kubernetes API-kat és mechanizmusokat. A DaemonSets használatával például telepíthet szükséges összetevőket.

Az AKS a fürt régióján kívül tárol ügyféladatokat?

Nem, minden adat a fürt régiójában van tárolva.

Szükség van az AKS-rendszerképek gyökérként való futtatására?

Az alábbi rendszerképek működési követelményei a "Futtatás gyökérként" beállításra vonatkoznak, és kivételeket kell megadni a szabályzatok esetében:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Mi az Az Azure CNI transzparens módja és a Híd mód?

Az 1.2.0-s verziótól kezdve az Azure CNI alapértelmezettként állítja be a Transzparens módot az egy bérlős Linux CNI-üzemelő példányokhoz. A transzparens mód a híd üzemmódot váltja fel. Az alábbi Híd mód és Transzparens mód szakaszokban részletesebben bemutatjuk a két mód közötti különbségeket, valamint az Azure CNI transzparens üzemmódjának előnyeit és korlátait.

Híd mód

Az Azure CNI-híd mód egy "azure0" nevű L2-hidat hoz létre "csak időben" módon. A gazdaoldali podpár veth összes adaptere ehhez a hídhoz csatlakozik. Pod-Pod a virtuális gépek közötti kommunikációban, és a fennmaradó forgalom ezen a hídon halad át. A híd egy 2. rétegbeli virtuális eszköz, amely önmagában nem tud fogadni vagy továbbítani semmit, hacsak nem köt hozzá egy vagy több valós eszközt. Ezért a Linux rendszerű virtuális gép et0-ét egy "azure0" híd alá kell alakítani, amely egy összetett hálózati topológiát hoz létre a Linux rendszerű virtuális gépen belül. Ennek tüneteként a CNI-nek más hálózati funkciókat, például a DNS-kiszolgáló frissítéseit kellett kezelnie.

Az alábbi példa bemutatja, hogyan néz ki az IP-útvonal beállítása Bridge módban. Függetlenül attól, hogy hány pod van a csomóponton, csak két útvonal létezik. Az első útvonal szerint a forgalom (az Azure0-on lévő helyi kivételével) az alhálózat alapértelmezett átjárójához kerül az "src 10.240.0.4" IP-címmel, amely a csomópont elsődleges IP-címe. A második azt mondja, hogy "10.20.x.x" Podtér a kernelnek, hogy eldöntse.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Transzparens mód

A transzparens mód egyszerű megközelítést alkalmaz a Linux-hálózatkezelés beállításához. Ebben a módban az Azure CNI nem módosítja az eth0 felület tulajdonságait a Linux rendszerű virtuális gépen. A Linux hálózati tulajdonságainak módosításával csökkenthetők a fürtök bridge móddal esetlegesen felmerülő összetett sarokproblémái. Transzparens módban az Azure CNI gazdagépoldali podpár-adaptereket veth hoz létre és ad hozzá a gazdagéphálózathoz. A virtuális gépek közötti pod-pod kommunikáció a CNI által hozzáadott IP-útvonalakon keresztül történik. A podok közötti kommunikáció lényegében a 3. rétegen és az L3 útválasztási szabályokon keresztül irányítja a podok forgalmát.

Az alábbi példa a Transzparens mód ip-útvonalának beállítását mutatja be. Minden pod felülete statikus útvonalat kap, így a forgalom dest IP-címmel lesz elküldve közvetlenül a pod gazdagépoldali veth párjának felületére.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

A Transzparens mód előnyei

• Enyhíti a conntrack DNS párhuzamos versenyfeltételét, és elkerüli az 5 másodperces DNS-késéssel kapcsolatos problémákat anélkül, hogy a csomópont helyi DNS-ét kellene beállítania (teljesítménybeli okokból továbbra is használhat csomópont helyi DNS-t).
• Kiküszöböli a kezdeti 5 másodperces DNS-késést, a CNI-híd módot, amely jelenleg a "csak időben" hídbeállítás miatt van bevezetve.
• A Bridge módban az egyik sarokeset az, hogy az Azure CNI nem tudja folyamatosan frissíteni az egyéni DNS-kiszolgáló listáit, amelyeket a felhasználók a VNET-hez vagy a hálózati adapterhez adnak hozzá. Ez a forgatókönyv azt eredményezi, hogy a CNI csak a DNS-kiszolgálólista első példányát veszi fel. Ez a probléma transzparens módban van megoldva, mivel a CNI nem módosítja az et0 tulajdonságokat. További információt itt talál.
• Az UDP-forgalom jobb kezelését és az UDP-árvízviharok elhárítását biztosítja, ha az ARP túllépi az időkorlátot. Hidak módban, ha a híd nem ismeri a cél pod MAC-címét a virtuális gép pod-pod közötti kommunikációjában, a terv szerint a csomag vihart eredményez az összes porton. Ez a probléma transzparens módban van megoldva, mivel nincs L2-eszköz az elérési úton. További információt itt talál.
• A transzparens mód jobb teljesítményt nyújt a virtuális gépek közötti pod-pod kommunikációban az átviteli sebesség és a késés tekintetében a Híd módhoz képest.

Hogyan kerülheti el az engedély tulajdonjogával kapcsolatos lassú problémákat, ha a kötet számos fájllal rendelkezik?

Hagyományosan, ha a pod nemroot felhasználóként fut (amit célszerű), a pod biztonsági környezetében meg kell adnia egy fsGroup értéket, hogy a kötet olvasható és írható legyen a pod számára. Ezt a követelményt részletesebben itt találja.

A beállítás fsGroup egyik mellékhatása, hogy minden alkalommal, amikor egy kötet csatlakoztatva van, a Kubernetesnek rekurzívan chown() kell lennie, valamint a köteten belüli összes fájlnak és chmod() könyvtárnak (néhány alább felsorolt kivétellel). Ez a forgatókönyv akkor is előfordul, ha a kötet csoporttulajdona már megfelel a kértnek fsGroup. A sok kis fájllal rendelkező nagyobb kötetek esetében költséges lehet, ami a podindítás hosszú időt vehet igénybe. Ez a forgatókönyv már ismert probléma volt az 1.20-as verzió előtt, és a kerülő megoldás a pod futtatását állítja be gyökérként:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

A probléma a Kubernetes 1.20-es verziójával lett megoldva. További információ: Kubernetes 1.20: A mennyiségi engedély módosításainak részletes szabályozása.

Használhatok FIPS-titkosítási kódtárakat az AKS-en való üzembe helyezéssel?

A FIPS-kompatibilis csomópontok mostantól támogatottak Linux-alapú csomópontkészleteken. További információ: FIPS-kompatibilis csomópontkészlet hozzáadása.

Konfigurálhatom az NSG-ket az AKS-szel?

Az AKS nem alkalmazza a hálózati biztonsági csoportokat (NSG-ket) az alhálózatára, és nem módosítja az alhálózathoz társított NSG-k egyikét sem. Az AKS csak a hálózati adapterek NSG-beállításait módosítja. CNI használata esetén gondoskodnia kell arról is, hogy az NSG-k biztonsági szabályai engedélyezik a csomópont és a pod CIDR-tartományai közötti forgalmat. Kubenet használata esetén gondoskodnia kell arról is, hogy az NSG-k biztonsági szabályai engedélyezik a csomópont és a pod CIDR közötti forgalmat. További információ: Hálózati biztonsági csoportok.

Hogyan működik az időszinkronizálás az AKS-ben?

Az AKS-csomópontok a "chrony" szolgáltatást futtatják, amely időt kér le a localhostból. A podokon futó tárolók időt kapnak az AKS-csomópontoktól. A pod tárolójából indított alkalmazások használati ideje tárolóban.

Hogyan frissülnek az AKS-bővítmények?

A rendszer automatikusan alkalmazza a javításokat, beleértve a biztonsági javításokat is az AKS-fürtre. Ha új kiadás érhető el, a fürt frissítésekor minden nagyobb, mint egy javítás, például a főverzió vagy az alverzió módosításai (amelyek az üzembe helyezett objektumok kompatibilitástörő változásait okozhatják). Az AKS kibocsátási megjegyzéseiben megtalálhatja, hogy mikor érhető el új kiadás.

Mi a linuxos AKS Linux-bővítmény célja, amelyet a Linux rendszerű virtuálisgép-méretezési csoportok példányaira telepítettem?

Az AKS Linux-bővítmény egy Azure-beli virtuálisgép-bővítmény, amely monitorozási eszközöket telepít és konfigurál a Kubernetes-feldolgozó csomópontokon. A bővítmény minden új és meglévő Linux-csomópontra telepítve van. A következő monitorozási eszközöket konfigurálja:

• Csomópont-exportőr: Hardveres telemetriát gyűjt a virtuális gépről, és metrikavégpont használatával teszi elérhetővé. Ezután egy monitorozási eszköz, például a Prometheus, képes lekaparni ezeket a metrikákat.
• Csomópont-problémaérzékelő: Célja, hogy láthatóvá tegye a különböző csomópontproblémákat a fürtfelügyeleti verem felső rétegei számára. Ez egy rendszerezett egység, amely minden csomóponton fut, észleli a csomópontokkal kapcsolatos problémákat, és események és NodeConditions használatával jelenti őket a fürt API-kiszolgálójának.
• ig: Egy eBPF-alapú nyílt forráskódú keretrendszer Linux- és Kubernetes-rendszerek hibakereséséhez és megfigyeléséhez. Olyan eszközöket (vagy kisalkalmazásokat) biztosít, amelyek célja a releváns információk összegyűjtése, lehetővé téve a felhasználók számára a teljesítményproblémák, összeomlások vagy egyéb rendellenességek okának azonosítását. Nevezetesen a Kubernetestől való függetlensége lehetővé teszi a felhasználók számára, hogy a vezérlősík hibáinak elhárításához is alkalmazzák.

Ezek az eszközök segítenek a csomópontok állapotával kapcsolatos problémák megfigyelhetőségének biztosításában, például:

• Infrastruktúra démonproblémái: Az NTP szolgáltatás leállt
• Hardverproblémák: Nem megfelelő a processzor, a memória vagy a lemez
• Kernelproblémák: Kernel holtpont, sérült fájlrendszer
• Tároló futtatókörnyezeti problémái: Nem válaszoló futtatókörnyezeti démon

A bővítmény nem igényel további kimenő hozzáférést a dokumentált AKS-kimenő követelményeken túli URL-címekhez, IP-címekhez vagy portokhoz. Nem igényel különleges engedélyeket az Azure-ban. Kubeconfig használatával csatlakozik az API-kiszolgálóhoz az összegyűjtött figyelési adatok elküldéséhez.