Ondersteuningsbeleid voor Azure Kubernetes Service

In dit artikel worden beleidsregels en beperkingen voor technische ondersteuning voor AKS (Azure Kubernetes Service) beschreven. Het bevat ook informatie over agentknooppuntbeheer, beheerde besturingsvlakonderdelen, opensource-onderdelen van derden en beveiligings- of patchbeheer.

Service-updates en -releases

Beheerde functies in AKS

Basisinfrastructuur als een dienst (IaaS) cloudonderdelen, zoals reken- of netwerkonderdelen, bieden u toegang tot besturingselementen en aanpassingsopties op laag niveau. AKS biedt daarentegen een kant-en-klare Kubernetes-implementatie die u een gemeenschappelijke set configuraties en mogelijkheden biedt die u nodig hebt voor uw cluster. Als AKS-gebruiker hebt u beperkte aanpassings- en implementatieopties. In ruil hiervoor hoeft u zich geen zorgen te maken over kubernetes-clusters of deze rechtstreeks te beheren.

Met AKS krijgt u een volledig beheerd besturingsvlak. Het besturingsvlak bevat alle onderdelen en services die u nodig hebt om Kubernetes-clusters te bedienen en te leveren aan eindgebruikers. Microsoft onderhoudt en beheert alle Kubernetes-onderdelen.

Microsoft beheert en bewaakt de volgende onderdelen via het besturingsvlak:

  • Kubelet- of Kubernetes-API-servers
  • Etcd of een compatibel sleutel-waardearchief met QoS (Quality of Service), schaalbaarheid en runtime
  • DNS-services (bijvoorbeeld kube-dns of CoreDNS)
  • Kubernetes-proxy of -netwerken, behalve wanneer BYOCNI wordt gebruikt
  • Alle andere invoegtoepassingen of systeemonderdelen die worden uitgevoerd in de kube-system-naamruimte.

AKS is geen PaaS-oplossing (Platform-as-a-Service). Sommige onderdelen, zoals agentknooppunten, hebben gedeelde verantwoordelijkheid, waar u het AKS-cluster moet helpen onderhouden. Gebruikersinvoer is bijvoorbeeld vereist om een beveiligingspatch voor het besturingssysteem (OS) van het agentknooppunt toe te passen.

De services worden beheerd in de zin dat Microsoft en het AKS-team de beschikbaarheid en functionaliteit van de service implementeren, beheren en verantwoordelijk zijn voor de beschikbaarheid en functionaliteit van de service. Klanten kunnen deze beheerde onderdelen niet wijzigen. Microsoft beperkt aanpassingen om een consistente en schaalbare gebruikerservaring te garanderen.

Gedeelde verantwoordelijkheid

Wanneer een cluster wordt gemaakt, definieert u de Kubernetes-agentknooppunten die AKS maakt. Uw workloads worden uitgevoerd op deze knooppunten.

Omdat uw agentknooppunten persoonlijke code uitvoeren en gevoelige gegevens opslaan, hebben Microsoft Ondersteuning alleen toegang tot deze gegevens op een beperkte manier. Microsoft Ondersteuning kan zich niet aanmelden, opdrachten uitvoeren of logboeken voor deze knooppunten weergeven zonder uw express-machtiging of hulp.

Wijzigingen die rechtstreeks zijn aangebracht in de agentknooppunten met behulp van een van de IaaS-API's, geven het cluster niet-ondersteund. Elke wijziging die op de agentknooppunten wordt toegepast, moet worden uitgevoerd met behulp van kubernetes-systeemeigen mechanismen zoals Daemon Sets.

Op dezelfde manier kunt u metagegevens toevoegen aan het cluster en knooppunten, zoals tags en labels, en het wijzigen van een van de door het systeem gemaakte metagegevens zorgt ervoor dat het cluster niet wordt ondersteund.

AKS-ondersteuningsdekking

Microsoft biedt technische ondersteuning voor de volgende voorbeelden:

  • Verbinding maken iviteit voor alle Kubernetes-onderdelen die de Kubernetes-service biedt en ondersteunt, zoals de API-server.
  • Beheer, uptime, QoS en bewerkingen van Kubernetes-besturingsvlakservices (bijvoorbeeld Kubernetes-besturingsvlak, API-server, enzovoort en coreDNS).
  • Etcd-gegevensopslag. Ondersteuning omvat geautomatiseerde, transparante back-ups van alle etcd-gegevens elke 30 minuten voor noodplanning en herstel van de clusterstatus. Deze back-ups zijn niet rechtstreeks beschikbaar voor u of iemand anders. Ze zorgen voor betrouwbaarheid en consistentie van gegevens. Terugdraaien of terugzetten op aanvraag wordt niet ondersteund als een functie.
  • Alle integratiepunten in het Stuurprogramma van de Azure-cloudprovider voor Kubernetes. Deze omvatten integraties in andere Azure-services, zoals load balancers, permanente volumes of netwerken (Kubernetes en Azure CNI, behalve wanneer BYOCNI wordt gebruikt).
  • Vragen over of problemen met het aanpassen van onderdelen van het besturingsvlak, zoals de Kubernetes-API-server, enzovoort, en coreDNS.
  • Problemen met netwerken, zoals Azure CNI, kubenet of andere problemen met netwerktoegang en -functionaliteit, behalve wanneer BYOCNI wordt gebruikt. Problemen kunnen DNS-omzetting, pakketverlies, routering, enzovoort zijn. Microsoft ondersteunt verschillende netwerkscenario's:
    • Kubenet en Azure CNI maken gebruik van beheerde VNET's of met aangepaste (bring your own) subnetten.
    • Verbinding maken iviteit van andere Azure-services en -toepassingen
    • Configuraties voor inkomend verkeer en inkomend verkeer of load balancer
    • Netwerkprestaties en -latentie
    • Netwerkbeleid

Notitie

Alle clusteracties die door Microsoft/AKS worden uitgevoerd, worden uitgevoerd met uw toestemming onder een ingebouwde Kubernetes-rol aks-service en ingebouwde rolbinding aks-service-rolebinding. Met deze rol kan AKS clusterproblemen oplossen en diagnosticeren, maar kan geen machtigingen wijzigen of rollen of rolbindingen maken, of andere acties met hoge bevoegdheden. Roltoegang is alleen ingeschakeld onder actieve ondersteuningstickets met Just-In-Time-toegang (JIT).

Microsoft biedt geen technische ondersteuning voor de volgende scenario's:

  • Vragen over het gebruik van Kubernetes. Microsoft Ondersteuning biedt bijvoorbeeld geen advies over het maken van aangepaste ingangscontrollers, het gebruik van toepassingsworkloads of het toepassen van softwarepakketten of hulpprogramma's van derden of opensource-softwarepakketten.

    Notitie

    Microsoft Ondersteuning kan adviseren over de functionaliteit, aanpassing en afstemming van AKS-clusters (bijvoorbeeld problemen en procedures met Kubernetes-bewerkingen).

  • Opensource-projecten van derden die niet worden geleverd als onderdeel van het Kubernetes-besturingsvlak of die zijn geïmplementeerd met AKS-clusters. Deze projecten kunnen Onder andere Istio, Helm, Envoy of andere projecten zijn.

    Notitie

    Microsoft kan best effort-ondersteuning bieden voor opensource-projecten van derden, zoals Helm. Waar het opensource-hulpprogramma van derden kan worden geïntegreerd met de Kubernetes Azure-cloudprovider of andere AKS-specifieke bugs, ondersteunt Microsoft voorbeelden en toepassingen uit microsoft-documentatie.

  • Gesloten bronsoftware van derden. Deze software kan beveiligingsscanprogramma's en netwerkapparaten of software bevatten.

  • Andere netwerkaanpassingen dan de aanpassingen die worden vermeld in de AKS-documentatie.

  • Aangepaste CNI-invoegtoepassingen of CNI-invoegtoepassingen van derden die worden gebruikt in de BYOCNI-modus .

  • Stand-by en proactieve scenario's. Microsoft Ondersteuning biedt reactieve ondersteuning om actieve problemen tijdig en professioneel op te lossen. Er wordt echter geen rekening gehouden met stand-by- of proactieve ondersteuning om operationele risico's te voorkomen, de beschikbaarheid te verhogen en de prestaties te optimaliseren. In aanmerking komende klanten kunnen contact opnemen met hun accountteam om genomineerd te worden voor de Azure Event Management-service. Het is een betaalde service die wordt geleverd door microsoft-ondersteuningstechnici die een proactieve oplossingsrisicobeoordeling en dekking tijdens het evenement omvat.

AKS-ondersteuningsdekking voor agentknooppunten

Microsoft-verantwoordelijkheden voor AKS-agentknooppunten

Microsoft en u deelt de verantwoordelijkheid voor Kubernetes-agentknooppunten, waarbij:

  • De basisinstallatiekopieën van het besturingssysteem hebben vereiste toevoegingen (zoals bewakings- en netwerkagenten).
  • De agentknooppunten ontvangen automatisch patches voor het besturingssysteem.
  • Problemen met de Kubernetes-besturingsvlakonderdelen die op de agentknooppunten worden uitgevoerd, worden automatisch hersteld. Deze onderdelen omvatten de onderstaande:
    • Kube-proxy
    • Netwerktunnels die communicatiepaden naar de Kubernetes-hoofdonderdelen bieden
    • Kubelet
    • containerd

Notitie

Als een agentknooppunt niet operationeel is, kan AKS afzonderlijke onderdelen of het hele agentknooppunt opnieuw opstarten. Deze herstartbewerkingen worden geautomatiseerd en bieden automatisch herstel voor veelvoorkomende problemen. Zie Automatisch herstellen van knooppunten als u meer wilt weten over de mechanismen voor automatisch herstel

Verantwoordelijkheden van de klant voor AKS-agentknooppunten

Microsoft biedt wekelijks patches en nieuwe installatiekopieën voor uw installatiekopieën, maar patcht ze niet standaard. Als u het besturingssysteem van uw agentknooppunt en runtime-onderdelen wilt laten patchen, moet u een regelmatig upgradeschema voor knooppuntinstallatiekopieën behouden of automatiseren.

Op dezelfde manier brengt AKS regelmatig nieuwe kubernetes-patches en secundaire versies uit. Deze updates kunnen beveiligings- of functionaliteitsverbeteringen in Kubernetes bevatten. U bent verantwoordelijk voor het bijwerken van de kubernetes-versie van uw clusters en volgens het AKS Kubernetes-versiebeleid voor ondersteuning.

Gebruikersaanpassing van agentknooppunten

Notitie

AKS-agentknooppunten worden in Azure Portal weergegeven als standaard Azure IaaS-resources. Deze virtuele machines worden echter geïmplementeerd in een aangepaste Azure-resourcegroep (voorafgegaan door MC_*). U kunt de basisinstallatiekopieën van het besturingssysteem niet wijzigen of directe aanpassingen aan deze knooppunten aanbrengen met behulp van de IaaS-API's of -resources. Aangepaste wijzigingen die niet worden uitgevoerd vanuit de AKS-API, blijven niet behouden via een upgrade, schaal, bijwerken of opnieuw opstarten. Ook kan elke wijziging in de extensies van de knooppunten, zoals customScriptExtension, leiden tot onverwacht gedrag en moet worden verboden. Vermijd het uitvoeren van wijzigingen in de agentknooppunten, tenzij Microsoft Ondersteuning u om te leiden om wijzigingen aan te brengen.

AKS beheert de levenscyclus en bewerkingen van agentknooppunten namens u en wijzigt de IaaS-resources die aan de agentknooppunten zijn gekoppeld, wordt niet ondersteund. Een voorbeeld van een niet-ondersteunde bewerking is het aanpassen van een virtuele-machineschaalset van een knooppuntgroep door configuraties handmatig te wijzigen in Azure Portal of vanuit de API.

Voor workloadspecifieke configuraties of pakketten raadt AKS het gebruik van Kubernetes daemon setsaan.

Met Kubernetes-containers met bevoegdheden daemon sets en init-containers kunt u software van derden afstemmen/wijzigen of installeren op clusteragentknooppunten. Voorbeelden van dergelijke aanpassingen zijn het toevoegen van aangepaste beveiligingsscansoftware of het bijwerken van sysctl-instellingen.

Hoewel dit pad wordt aanbevolen als de bovenstaande vereisten van toepassing zijn, kan AKS-engineering en -ondersteuning niet helpen bij het oplossen of diagnosticeren van wijzigingen die het knooppunt niet beschikbaar maken vanwege een aangepaste geïmplementeerde daemon set.

Beveiligingsproblemen en patches

Als er een beveiligingsfout wordt gevonden in een of meer van de beheerde onderdelen van AKS, worden alle betrokken clusters gepatcht door het AKS-team om het probleem te verhelpen. Het AKS-team biedt u ook upgraderichtlijnen.

Voor agentknooppunten die worden beïnvloed door een beveiligingsfout, meldt Microsoft u met details over de impact en de stappen om het beveiligingsprobleem op te lossen of te verhelpen.

Onderhoud en toegang tot knooppunten

Hoewel u zich kunt aanmelden bij agentknooppunten en deze kunt wijzigen, wordt deze bewerking afgeraden omdat wijzigingen een cluster niet kunnen ondersteunen.

Netwerkpoorten, toegang en NSG's

U kunt de NSG's alleen aanpassen op aangepaste subnetten. U kunt NSG's niet aanpassen op beheerde subnetten of op NIC-niveau van de agentknooppunten. AKS heeft uitgaande vereisten voor specifieke eindpunten, om uitgaand verkeer te beheren en de benodigde connectiviteit te garanderen, zie uitgaand verkeer beperken. Voor inkomend verkeer zijn de vereisten gebaseerd op de toepassingen die u hebt geïmplementeerd in het cluster.

Gestopte knooppunten, toewijzing ongedaan gemaakt en niet gereed

Als u uw AKS-workloads niet continu nodig hebt, kunt u het AKS-cluster stoppen, waardoor alle knooppuntpools en het besturingsvlak worden gestopt. U kunt het opnieuw starten wanneer dat nodig is. Wanneer u een cluster stopt met de az aks stop opdracht, blijft de clusterstatus gedurende maximaal 12 maanden behouden. Na 12 maanden worden de clusterstatus en alle bijbehorende resources verwijderd.

Het handmatig toewijzen van alle clusterknooppunten vanuit de IaaS-API's, de Azure CLI of Azure Portal wordt niet ondersteund om een AKS-cluster of knooppuntpool te stoppen. Het cluster wordt na 30 dagen beschouwd als niet meer ondersteund en gestopt door AKS. De clusters zijn vervolgens onderworpen aan hetzelfde bewaarbeleid van 12 maanden als een correct gestopt cluster.

Clusters met nul ready-knooppunten (of alle niet gereed) en nul actieve VM's worden na 30 dagen gestopt.

AKS behoudt zich het recht voor om besturingsvlakken te archiveren die buiten de ondersteuningsrichtlijnen zijn geconfigureerd voor langere perioden die gelijk zijn aan en meer dan 30 dagen. AKS onderhoudt back-ups van cluster-etcd-metagegevens en kan het cluster eenvoudig opnieuw implementeren. Deze herlocatie wordt gestart door een PUT-bewerking die het cluster weer ondersteunt, zoals een upgrade of schaal naar actieve agentknooppunten.

Alle clusters in een onderbroken abonnement worden onmiddellijk gestopt en na 90 dagen verwijderd. Alle clusters in een verwijderd abonnement worden onmiddellijk verwijderd.

Niet-ondersteunde kubernetes-functies voor alfa en bèta

AKS ondersteunt alleen stabiele en bètafuncties in het upstream Kubernetes-project. Tenzij anders gedocumenteerd, biedt AKS geen ondersteuning voor alfafuncties die beschikbaar zijn in het upstream Kubernetes-project.

Preview-functies of functievlagmen

Voor functies en functionaliteit waarvoor uitgebreide tests en feedback van gebruikers zijn vereist, publiceert Microsoft nieuwe preview-functies of -functies achter een functievlag. Houd rekening met deze functies als voorlopige versie of bètafuncties.

Preview-functies of functievlagfuncties zijn niet bedoeld voor productie. Doorlopende wijzigingen in API's en gedrag, bugfixes en andere wijzigingen kunnen leiden tot instabiele clusters en downtime.

Functies in openbare preview vallen onder de best effort-ondersteuning , omdat deze functies in preview zijn en niet zijn bedoeld voor productie. De technische ondersteuningsteams van AKS bieden alleen ondersteuning tijdens kantooruren. Zie de veelgestelde vragen over Azure-ondersteuning voor meer informatie.

Upstream bugs en problemen

Gezien de snelheid van ontwikkeling in het upstream Kubernetes-project, ontstaan er altijd bugs. Sommige van deze bugs kunnen niet worden gepatcht of bewerkt binnen het AKS-systeem. In plaats daarvan vereisen bugfixes grotere patches voor upstream-projecten (zoals Kubernetes, knooppunt- of agentbesturingssystemen en kernel). Voor onderdelen die microsoft bezit (zoals de Azure-cloudprovider), zetten AKS en Azure-medewerkers zich in om problemen upstream in de community op te lossen.

Wanneer de hoofdoorzaak van een probleem met technische ondersteuning wordt veroorzaakt door een of meer upstream-bugs, zullen AKS-ondersteunings- en technische teams:

  • Identificeer en koppel de upstream-bugs aan eventuele ondersteunende details om uit te leggen waarom dit probleem van invloed is op uw cluster of workload. Klanten ontvangen koppelingen naar de vereiste opslagplaatsen, zodat ze de problemen kunnen bekijken en kunnen zien wanneer een nieuwe release oplossingen biedt.

  • Potentiële tijdelijke oplossingen of oplossingen bieden. Als het probleem kan worden opgelost, wordt een bekend probleem opgeslagen in de AKS-opslagplaats. In het archief met bekende problemen wordt het volgende uitgelegd:

    • Het probleem, inclusief koppelingen naar upstream bugs.
    • De tijdelijke oplossing en details over een upgrade of een andere persistentie van de oplossing.
    • Ruwe tijdlijnen voor de opname van het probleem, op basis van het upstream-releaseritme.