Delen via


NGroups Rolling Update

Inleiding

Wanneer de vereisten veranderen, moet u mogelijk uw NGroups en de bijbehorende containergroepen (CG's) bijwerken.

Er zijn twee updatemodi beschikbaar voor het bijwerken van NGroups: Handmatig (standaardoptie) en Rolling.

Binnen Rolling Update (RU) zijn er twee opties: in-place update en vervang update. Vervang RU is de standaardoptie.

In dit document wordt de RU uitgebreid beschreven. Handmatige update wordt hier besproken in de documentatiekoppeling voor NGroups.

Omschrijving

Bekijk een eenvoudig voorbeeld van het bijwerken van een CG-profielreferentie van cgprofile1 naar cgprofile2.

In-place Rolling Update

Wanneer we met in-place RU de verwijzing naar cgprofile2 bijwerken en een opdracht UPDATE NGroups uitgeven, worden bestaande CG's bijgewerkt met cgprofile2. De update van bestaande CG's vindt plaats in kleine batches (en niet allemaal tegelijk). Het zorgt ervoor dat er een minimale impact op uw workload is, omdat er mogelijk slechts een klein percentage CG's niet beschikbaar is tijdens de update.

We kunnen de batchgrootte en andere gerelateerde instellingen voor de rolling-updatemodus configureren met de NGroups-API.

Omdat in-place RU bestaande CG's bijwerkt, zijn er bepaalde beperkingen voor de CG-eigenschappen die azure Container Instances (ACI) afdwingt.

Zie de beperkingen van ACI voor het bijwerken van CG's. Zie hier ook voor eigenschappen voor CG's waarvoor een verwijdering (versus een update) is vereist.

Rolling Update vervangen

Als we de verwijzing naar cgprofile2 bijwerken en een opdracht UPDATE NGroups uitgeven, worden nieuwe CG's gemaakt met cgprofile2. Bestaande CG's met cgprofile1 worden verwijderd. Dit maken en verwijderen gebeurt in kleine batches (en niet allemaal tegelijk). Het zorgt ervoor dat er een minimale impact op uw workload is, omdat er slechts een klein percentage CG's wordt beïnvloed tijdens de update.

Net als in-place RU kunnen we de batchgrootte en andere gerelateerde instellingen voor de rolling-updatemodus configureren met de NGroups-API.

Omdat vervangings-RU nieuwe CG's maakt, zijn er minder beperkingen die worden afgedwongen door ACI. Als gevolg hiervan is het vervangen van RU een krachtigere optie en is dit de standaardoptie wanneer een klant RU selecteert.

Gebruik

Een rolling update activeren

Rolling update wordt geactiveerd wanneer een NGroups PUT-aanroep wordt uitgevoerd en het CG-profiel in de PUT-aanroep verschilt van het CG-profiel waarnaar momenteel wordt verwezen in de NGroups.

NGroups groepeert vervolgens exemplaren automatisch in batches en werkt één batch tegelijk bij. De parameter maxBatchPercent bepaalt de grootte van de batch.

Een batch bijwerken

  • Een in-place update roept een CG PUT-aanroep aan om elke CG van de batch bij te werken.

  • Een vervangingsupdate roept een CG PUT-aanroep aan om nieuwe CG's te maken en bestaande CG's van de batch te verwijderen. Er bestaat een correspondentie van 1:1 tussen de CG's die worden gemaakt en de CG's die worden verwijderd. De CG-namen zijn echter anders.

Als een voldoende aantal CG's in de batch gezonde signalen geeft na de pauzeTimeBetweenBatches periode, start NGroups automatisch de volgende batch voor de update. Anders stopt de implementatie. De parameter maxUnhealthyPercent geeft het totale aantal beschadigde CG's op, terwijl de parameter maxUnhealthyUpdatedPercent het totale aantal beschadigde CG's na de update aangeeft.

Hier volgt een voorbeeld van het uitgeven van een rolling update-aanvraag voor NGroups:

{ 
    "location": "{{location}}", 
    "properties": { 
        "updateProfile": { 
            "updateMode": "Rolling", 

            "rollingUpdateProfile": { 
                // Maximum percentage of total CGs which can be updated  
                // simultaneously by rolling update in one batch. 
                “maxBatchPercent”: “10”, // optional, defaults to 20% 

                // Maximum percentage of the total CGs across the whole NGroup  
                // that can be unhealthy at a time either by rolling update or health 
                // checks by liveness probes. If there are more unhealthy CGs than this,  
                // the current rolling update is marked as failed. 
                // This check is a prerequisite to start any batch. 
                “maxUnhealthyPercent”: “10”, // optional, defaults to 20% 

                // Maximum percentage of the updated CGs which can be in unhealthy state  
                // after each batch is updated. If there are more unhealthy CGs than this,  
                // the current rolling update is marked as failed. 
                “maxUnhealthyUpdatedPercent”: 10, // optional, defaults to 20% 

                // The wait time between batches after completing one batch of the rolling 
                // update and before starting the next batch. The time duration should  
                // be specified in ISO 8601 format for duration. 
                "pauseTimeBetweenBatches": "PT2M", // optional, defaults to PT1M 

                // A nullable boolean property. Default is null 
                // Sets the mode to either in-place RU (when true) or replace (default) RU. 
                “inPlaceUpdate”: null/false/true 
            } 
        }, 
        "containerGroupProfiles": [
            { 
                "resource": { 
                    "id": "/subscriptions/{{subId}}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/containerGroupProfiles/cgp1" 
                } 
            } 
        ] 
    } 
} 

Als de versie van de installatiekopieën is ingesteld op de meest recente tag voor containerinstallatiekopieën in het CG-profiel, worden automatisch de meest recente installatiekopieën opgehaald tijdens de RU. Als u onverwacht gedrag in uw toepassing wilt voorkomen, wordt u aangeraden de meest recente tag voor afbeeldingen niet te gebruiken. Gebruik in plaats daarvan specifieke versies.

Notitie

Als u vervang-RU wilt gebruiken, stelt u de tag rollingupdate.replace.enabled in: true voor de NGroups-resource. Deze tag is tijdelijk en is in de toekomst niet vereist.

“tags”: { 
    “rollingupdate.replace.enabled”: true 
} 

Status van een actieve rolling update ophalen

Voor het ophalen van de meest recente status van uw rolling update kunt u deze REST API gebruiken:

GET /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/latestRollingUpdate

Hiermee wordt een antwoord geretourneerd met relevante informatie over de RU.

Een rolling update annuleren

Als u een rolling update wilt annuleren, gebruikt u de volgende API. Nadat de RU is geannuleerd, kan de RU niet meer worden hervat/opnieuw gestart. Er moet een nieuwe RU worden geactiveerd.

POST /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/cancelRollingUpdate

U hoeft geen aanvraagbody op te geven bij het aanroepen van deze API.

Grens van een Batch in een rolling update

De CG's van een specifieke batch in een RU overschrijden geen grens van een foutmodel. Een foutmodel vertegenwoordigt een combinatie van zone/fault-domain (FD). Zone 1/FD 0 is bijvoorbeeld een foutmodelgrens, zone 1/FD 1 is een andere grens van het foutmodel en zone 2/FD 0 is nog een andere grens voor het foutmodel.

Als een klant meerdere zonegebonden NGroups heeft ingesteld met drie zones, is een batch beperkt tot CG's die maximaal tot één zone behoren. Een batch bestaat nooit uit CG's verspreid over meerdere zones.

Als een klant een multi-zonegebonden en multi-FD NGroups-installatie heeft, bestaat een batch nog steeds uit CG's die tot slechts één FD behoren in één zone.

NGroups handhaaft deze foutmodelgrens in een batch, zelfs wanneer het aantal CG's dat is geselecteerd voor een batch veel kleiner is dan de maxBatchPercent-instelling. Het weerspiegelt dat NGroups de voorkeur geeft aan veilige updates via snellere (en dus riskante) updates.

De enige keer dat een grens van een foutmodel wordt overschreden wanneer de RU beschadigde CG's voor de eerste batch selecteert. In deze batch probeert de RU alle beschadigde CG's bij te werken om de algehele beschikbaarheid van NGroups te verbeteren. Als gevolg hiervan kan de RU bij het bijwerken van beschadigde CG's de maxBatchPercent-instelling overschrijden.