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

• Zie voor release-informatie de release-opmerkingen van AKS.
• Zie de AKS-roadmap voor meer informatie over preview-functies.

Beheerde functies in AKS

Met basisinfrastructuur als een dienst (IaaS)-cloudonderdelen, zoals reken- of netwerkonderdelen, hebt 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-diensten zoals 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, waarbij u het AKS-cluster moet 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 Support kan zich niet aanmelden, opdrachten uitvoeren of logboeken voor deze knooppunten weergeven zonder uw uitdrukkelijke toestemming of hulp.

Elke wijziging die direct aan de agentknooppunten wordt gedaan met behulp van een van de IaaS-API's, maakt het cluster niet ondersteunbaar. Alle wijzigingen die worden toegepast op de agentknooppunten moeten worden uitgevoerd met behulp van kubernetes-systeemeigen mechanismen zoals een DaemonSet.

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

AKS-ondersteuningsdekking

In de volgende secties worden de ondersteunde en niet-ondersteunde scenario's voor technische ondersteuning van AKS beschreven.

Ondersteunde scenario’s

Microsoft biedt technische ondersteuning voor de volgende voorbeelden:

• Connectiviteit met alle Kubernetes-onderdelen die de Kubernetes-service biedt en ondersteunt, zoals de API-server.
• Beheer, uptime, QoS en bewerkingen van Kubernetes-besturingsvlakservices zoals Kubernetes-besturingsvlak, API-server etcden coreDNS.
• etcd gegevensopslag. Ondersteuning omvat geautomatiseerde, transparante back-ups van alle gegevens om de etcd 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 etcden 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.
  • Connectiviteit met andere Azure-services en -toepassingen.
  • Door Microsoft beheerde ingresscontrollers of load balancer-configuraties.
  • Netwerkprestaties en latentie.
  • Onderdelen en functionaliteiten van door Microsoft beheerd netwerkbeleid .

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).

Niet ondersteunde scenario's

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.

  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.

  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.

• Het configureren of oplossen van problemen met toepassingsspecifieke code of het gedrag van toepassingen of hulpprogramma's van derden die worden uitgevoerd in het AKS-cluster. Dit omvat problemen met de implementatie van toepassingen die niet zijn gerelateerd aan het AKS-platform zelf.

• Uitgifte, verlenging of beheer van certificaten voor toepassingen die worden uitgevoerd op AKS.

• Andere netwerkaanpassingen dan de aanpassingen die worden vermeld in de AKS-documentatie. Microsoft Ondersteuning kan bijvoorbeeld geen apparaten of virtuele apparaten configureren die bedoeld zijn om uitgaand verkeer te bieden voor het AKS-cluster, zoals VPN's of firewalls.

  Op basis van best effort kan Microsoft Ondersteuning adviseren over de configuratie die nodig is voor Azure Firewall, maar niet voor andere apparaten van derden.

• Op maat gemaakte of van derden afkomstige CNI-plug-ins die worden gebruikt in de modus BYOCNI.

• Het configureren of oplossen van problemen met niet-door Microsoft beheerde netwerkbeleidsregels. Hoewel het gebruik van netwerkbeleid wordt ondersteund, kan Microsoft Ondersteuning geen problemen onderzoeken die voortvloeien uit aangepaste netwerkbeleidsconfiguraties.

• Niet-door Microsoft beheerde ingresscontrollers configureren of problemen oplossen, zoals nginx, kong, traefik, enzovoort. Dit omvat het aanpakken van functionaliteitsproblemen die zich voordoen na AKS-specifieke bewerkingen, zoals een ingresscontroller die niet meer werkt na een Kubernetes-versie-upgrade. Dergelijke problemen kunnen voortvloeien uit incompatibiliteit tussen de versie van de ingangscontroller en de nieuwe Kubernetes-versie. Voor een volledig ondersteunde optie kunt u overwegen een door Microsoft beheerde controller voor inkomend verkeer te gebruiken.

• Configureren of oplossen van problemen DaemonSet (inclusief scripts) die worden gebruikt voor het aanpassen van knooppuntconfiguraties. Hoewel het gebruik DaemonSet de aanbevolen methode is om software van derden af te stemmen, te wijzigen of te installeren op clusteragentknooppunten wanneer de parameters van het configuratiebestand onvoldoende zijn, kan Microsoft Ondersteuning geen problemen oplossen die voortvloeien uit de aangepaste scripts die worden DaemonSet gebruikt vanwege hun aangepaste aard.

• 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.

• Kwetsbaarheden/CVEs met een oplossing van de leverancier die minder dan 30 dagen oud is. Zolang u de bijgewerkte VHD gebruikt, zou u geen containerimage kwetsbaarheden/CVE's moeten hebben waarvoor een leverancieroplossing beschikbaar is die ouder is dan 30 dagen. Het is de verantwoordelijkheid van de klant om de VHD bij te werken en gefilterde lijsten aan Microsoft-ondersteuning te bieden. Nadat u uw VHD hebt bijgewerkt, is het de verantwoordelijkheid van de klant om het rapport beveiligingsproblemen/CVE's te filteren en alleen een lijst met beveiligingsproblemen/CV's op te geven met een leverancieroplossing die ouder is dan 30 dagen. Als dat het geval is, zorgt Microsoft-ondersteuning ervoor dat ze intern werken en onderdelen aanpakken met een oplossing van een leverancier die meer dan 30 dagen geleden is uitgebracht. Daarnaast biedt Microsoft alleen ondersteuning voor beveiligingsproblemen/CVE-gerelateerde onderdelen voor door Microsoft beheerde onderdelen. Bijvoorbeeld AKS-knooppuntinstallatiekopieën, beheerde containerinstallatiekopieën voor toepassingen die worden geïmplementeerd tijdens het maken van het cluster of via de installatie van een beheerde invoegtoepassing. Ga naar Beveiligingsbeheer voor Azure Kubernetes Service (AKS) voor meer informatie over beveiligingsbeheer voor AKS.

• Aangepaste codevoorbeelden of scripts. Hoewel Microsoft Ondersteuning kleine codevoorbeelden en beoordelingen van kleine codevoorbeelden in een ondersteuningsaanvraag kan bieden om te laten zien hoe u functies van een Microsoft-product gebruikt, kan Microsoft Ondersteuning geen aangepaste codevoorbeelden bieden die specifiek zijn voor uw omgeving of toepassing.

AKS-ondersteuningsdekking voor agentknooppunten

In de volgende secties worden de verantwoordelijkheden van Microsoft en klanten voor AKS-agentknooppunten beschreven.

Microsoft-verantwoordelijkheden voor AKS-agentknooppunten

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

• De basis-OS-afbeelding van het besturingssysteem heeft 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 volgende items:
  • Kube-proxy
  • Netwerktunnels die communicatiepaden naar de Kubernetes-hoofdonderdelen bieden
  • Kubelet
  • containerd

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 images voor uw imagenodes. Als u het besturingssysteem en runtime-onderdelen van uw agentknooppunt up-to-date wilt houden, moet u deze patches en updates regelmatig handmatig of automatisch toepassen. Zie voor meer informatie:

• Werk AKS-knooppuntinstallatiekopieën handmatig bij.
• AKS-knooppuntafbeeldingen automatisch bijwerken

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.

Gebruikersaanpassing van agentknooppunten

Note

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 vanuit de AKS API worden uitgevoerd, blijven niet behouden bij een upgrade, schalen, update of herstart. Ook kan elke wijziging in de extensies van de knooppunten, zoals de CustomScriptExtension , leiden tot onverwacht gedrag en moet worden verboden. Voer geen wijzigingen uit aan de agentknooppunten, tenzij de Microsoft-ondersteuning u vraagt wijzigingen aan te brengen.

AKS beheert de levenscyclus en de bewerkingen van agentknooppunten namens u, en het wijzigen van 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 aan een Kubernetes DaemonSette gebruiken.

Met Kubernetes privileged DaemonSet 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 DaemonSet.

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 mogelijk niet aanpassen op beheerde subnetten of op NIC-niveau van de agentknooppunten. AKS heeft vereisten voor uitgaand verkeer naar specifieke eindpunten om het verkeer te beheren en de benodigde connectiviteit te garanderen. Zie uitgaand verkeer beperken voor meer informatie. Voor inkomend verkeer zijn de vereisten gebaseerd op de toepassingen die u in het cluster hebt geïmplementeerd.

Gestopte, gedealloceerde en niet gereed knooppunten

Als u uw AKS-workloads niet continu nodig hebt, kunt u het AKS-cluster stoppen, waardoor alle knooppuntgroepen 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 loskoppelen van alle clusterknooppunten via de IaaS-API's, de Azure CLI of de Azure-portal wordt niet ondersteund om een AKS-cluster of knooppuntgroep 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 clustermetagegevens etcd en kan het cluster gemakkelijk opnieuw implementeren. Deze herverdeling wordt gestart door een PUT-bewerking die het cluster weer ondersteund maakt, zoals een upgrade of opschalen naar actieve agent-knooppunten.

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 functievlaggen

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 bedoeld zijn 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 maatregelen bieden. Als het probleem kan worden opgelost, wordt een bekend probleem opgeslagen in de AKS-opslagplaats. In de melding van bekende problemen wordt 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.