o_m/Shutterstock.comKubernetes Pods zouden zonder tussenkomst moeten werken, maar soms kun je een probleem tegenkomen waarbij een container niet werkt zoals het zou moeten. Het herstarten van de pod kan helpen de normale werking te herstellen.
Kubectl heeft geen directe manier om afzonderlijke pods opnieuw op te starten. Pods zijn bedoeld om te blijven werken totdat ze worden vervangen als onderdeel van uw implementatieroutine. Dit is meestal wanneer u een nieuwe versie van uw containerimage vrijgeeft.
Hier zijn een paar technieken die u kunt gebruiken als u Pods opnieuw wilt starten zonder een nieuwe image te maken of uw CI-pipeline uit te voeren. Ze kunnen helpen als u denkt dat een nieuwe set containers uw werklast weer aan het draaien zal krijgen.
Het aantal replica's schalen
Hoewel er geen herstart van kubectl is, kunt u iets soortgelijks bereiken door het aantal containerreplica's dat u uitvoert te schalen. Dit werkt wanneer uw Pod deel uitmaakt van een Deployment, StatefulSet, ReplicaSet of Replication Controller.
kubectl scale deployment my-deployment –replicas=0 kubectl scale deployment my-deployment –replicas=3
Als u uw implementatie naar 0 schaalt, worden al uw bestaande pods verwijderd. Wacht tot de pods zijn beëindigd, gebruik kubectl get pods om hun status te controleren en schaal de implementatie vervolgens terug naar het beoogde aantal replica's. Kubernetes zal nieuwe pods maken met nieuwe containerinstanties.
Downtimeless opnieuw opstarten met rollouts
Handmatige aanpassing van het aantal replica's heeft een beperking: terugschalen naar 0 zal een periode van downtime creëren waarin er geen Pods beschikbaar zijn om uw gebruikers van dienst te zijn. Een alternatieve optie is om een rollende herstart te starten waarmee u een set pods kunt vervangen zonder downtime. Het is beschikbaar met Kubernetes v1.15 en hoger.
kubectl rollout herstart deployment my-deployment Advertisement
Als u deze opdracht uitvoert, zal Kubernetes uw pods geleidelijk beëindigen en vervangen, terwijl enkele containers worden gegarandeerd blijf de hele tijd operationeel. Door het gefaseerde karakter van de uitrol kunt u klanten blijven bedienen terwijl u effectief “herstarten” uw Pods achter de schermen.
Nadat de uitrol is voltooid, heeft u hetzelfde aantal replica's als voorheen, maar elke container is een nieuwe instantie. U kunt de status van de uitrol controleren door kubectl get pods te gebruiken om Pods weer te geven en te kijken hoe ze worden vervangen. Er is ook een kubectl-uitrolstatus deployment/my-deployment die ook de huidige voortgang laat zien.
kubectl-uitrol werkt met implementaties, DaemonSets en StatefulSets. Meestal zou dit uw beste optie moeten zijn wanneer u uw containers wilt beëindigen en onmiddellijk nieuwe wilt starten.
(Ab)ReplicaSet Monitoring gebruiken
Als uw Pod deel uitmaakt van een ReplicaSet of implementatie, kunt u een vervanging starten door deze eenvoudig te verwijderen. De ReplicaSet merkt dat de pod is verdwenen, aangezien het aantal containerinstanties onder het aantal doelreplica's daalt.
kubectl delete pod my-pod
De ReplicaSet zal ingrijpen om het minimale beschikbaarheidsniveau te herstellen. Er wordt automatisch een nieuwe pod gemaakt, waarbij een nieuwe container wordt gestart om de oude te vervangen.
Advertentie
Dit is technisch gezien een bijwerking – het is beter om de schaal- of uitrolopdrachten te gebruiken die explicieter zijn en zijn ontworpen voor dit gebruik. Desalniettemin kan handmatige verwijdering een nuttige techniek zijn als u de identiteit kent van een enkele zich misdragende Pod in een ReplicaSet of implementatie. Een uitrol zou alle beheerde pods vervangen, niet alleen degene die een storing vertoont.
U kunt de techniek om alle defecte pods te vervangen uitbreiden met een enkele opdracht:
kubectl delete pods –field-selector=status.phase=Mislukt
Elke pod met de status Mislukt zal worden beëindigd en verwijderd. De replicatiecontroller zal de discrepantie opmerken en nieuwe pods toevoegen om de status terug te brengen naar het geconfigureerde aantal replica's. Als u zeker weet dat de oude pods zijn mislukt vanwege een tijdelijke fout, moeten de nieuwe pods in goede staat blijven werken.
Pod-annotaties wijzigen
Een andere manier om te forceren dat een Pod moet worden vervangen, is door een annotatie toe te voegen of te wijzigen. Kubernetes zal de pod vervangen om de wijziging toe te passen.
U kunt de opdracht kubectl annotate gebruiken om een annotatie toe te passen:
kubectl annotate pods my-pod app-version=”2″ –overwrite < p>Met deze opdracht wordt de app-versieannotatie op my-pod bijgewerkt. De –overwrite vlag instrueert Kubectl om de wijziging toe te passen, zelfs als de annotatie al bestaat. Zonder dit kunt u alleen nieuwe annotaties toevoegen als veiligheidsmaatregel om onbedoelde wijzigingen te voorkomen.
Advertentie
Het bijwerken van de omgevingsvariabelen van een implementatie heeft een soortgelijk effect als het wijzigen van annotaties. Dit is ideaal wanneer u al een app-versienummer, build-ID of implementatiedatum in uw omgeving onthult.
kubectl set env deployment my-deployment APP_VERSION=”2″
Conclusie
Kubernetes-pods zouden normaal gesproken moeten werken totdat ze worden vervangen door een nieuwe implementatie. Als gevolg hiervan is er geen directe manier om “herstarten” een enkele pod. Als een van uw containers een probleem ondervindt, probeer deze dan te vervangen in plaats van opnieuw op te starten. De subtiele verandering in terminologie past beter bij het staatloze bedrijfsmodel van Kubernetes Pods.
Schaal het aantal replica's, start een uitrol of verwijder handmatig Pods van een ReplicaSet om oude containers te beëindigen en nieuwe nieuwe instanties te starten. Roll-outs zijn de voorkeursoplossing voor moderne Kubernetes-releases, maar de andere benaderingen werken ook en kunnen meer geschikt zijn voor specifieke scenario's.
Je moet vooral aan deze twee vragen denken: wil je alle pods in je implementatie of ReplicaSet moet worden vervangen, en is elke uitvaltijd acceptabel? Handmatige verwijdering van pods kan ideaal zijn als u “herstarten” een individuele Pod zonder downtime, op voorwaarde dat u meer dan één replica gebruikt, terwijl scale een optie is wanneer de uitrolopdracht niet kan worden gebruikt en u zich geen zorgen maakt over een korte periode van onbeschikbaarheid.< /p>