Opmerking. vert.: De auteur van het originele artikel is ThΓ©o Chamley, Google Cloud Solutions Architect. In dit bericht voor de Google Cloud-blog geeft hij een samenvatting van de meer gedetailleerde handleiding van zijn bedrijf, genaamd '" Daarin verzamelden Google-experts best practices voor het gebruik van containers in de context van het gebruik van de Google Kubernetes Engine en meer, waarbij een breed scala aan onderwerpen aan bod kwam: van beveiliging tot monitoring en loggen. Wat zijn volgens Google de belangrijkste containerpraktijken?
(Op Kubernetes gebaseerde service voor het uitvoeren van containerapplicaties op Google Cloud - ca. vert.) is een van de beste manieren om workloads uit te voeren die moeten worden geschaald. zal een soepele werking van de meeste applicaties garanderen als ze in containers worden geplaatst. Maar als u wilt dat uw applicatie eenvoudig te beheren is en optimaal gebruik wilt maken van Kubernetes, moet u best practices volgen. Ze zullen de werking van de applicatie, de monitoring en foutopsporing ervan vereenvoudigen, en ook de veiligheid vergroten.
In dit artikel bespreken we een lijst met dingen die u moet weten en doen om containers effectief op Kubernetes uit te voeren. Degenen die dieper op details willen ingaan, moeten het materiaal lezen , en let ook op onze over het assembleren van containers.
1. Gebruik eigen mechanismen voor containerregistratie
Als de applicatie op een Kubernetes-cluster draait, is er niet veel aan logs nodig. Er is waarschijnlijk al een gecentraliseerd logboekregistratiesysteem ingebouwd in het cluster dat u gebruikt. In het geval van het gebruik van Kubernetes Engine is dit verantwoordelijk . (Opmerking. vert.: En als u uw eigen Kubernetes-installatie gebruikt, raden we u aan onze Open Source-oplossing eens nader te bekijken - .) Houd uw leven eenvoudig en gebruik eigen mechanismen voor containerregistratie. Schrijf logs naar stdout en stderr - ze worden automatisch ontvangen, opgeslagen en geΓ―ndexeerd.
Indien gewenst kunt u er ook logs naar schrijven . Deze aanpak maakt het gemakkelijk om er metadata aan toe te voegen. En met hen zal Stackdriver Logging de mogelijkheid hebben om door logs te zoeken met behulp van deze metadata.
2. Zorg ervoor dat containers staatloos en onveranderlijk zijn
Om containers correct te laten functioneren in een Kubernetes-cluster, moeten ze staatloos en onveranderlijk zijn. Zodra aan deze voorwaarden is voldaan, kan Kubernetes zijn werk doen en applicatie-entiteiten creΓ«ren en vernietigen waar en wanneer dat nodig is.
stateless betekent dat elke status (persistente gegevens van welke aard dan ook) buiten de container wordt opgeslagen. Hiervoor kunnen, afhankelijk van de behoeften, verschillende soorten externe opslag worden gebruikt: , , , of andere beheerde databases. (Opmerking. vert.: Lees hierover meer in ons artikel β".)
Onveranderlijk betekent dat de container tijdens zijn levensduur niet wordt gewijzigd: geen updates, patches, configuratiewijzigingen. Als u uw applicatiecode moet bijwerken of een patch moet toepassen, maakt u een nieuwe image en implementeert u deze. Het wordt aanbevolen om de containerconfiguratie (luisterpoort, runtime-omgevingsopties, etc.) extern te verplaatsen ΠΈ . Ze kunnen worden bijgewerkt zonder dat u een nieuwe containerimage hoeft te maken. Om eenvoudig pijpleidingen te maken met image-assemblage, kunt u gebruiken . (Opmerking. vert.: Wij gebruiken hiervoor een Open Source tool .)
Een voorbeeld van het bijwerken van de implementatieconfiguratie in Kubernetes met behulp van ConfigMap, gemonteerd in peulen als configuratie
3. Vermijd geprivilegieerde containers
Je draait toch geen applicaties als root op je servers? Als een aanvaller de applicatie binnendringt, krijgt hij root-toegang. Dezelfde overwegingen zijn van toepassing op het niet uitvoeren van bevoorrechte containers. Als u instellingen op de host moet wijzigen, kunt u de container specifiek opgeven mogelijkheden gebruik van de optie in Kubernetes. Als je moet veranderen systemen, Kubernetes heeft voor deze. Probeer er in het algemeen het beste van te maken en zijspancontainers om soortgelijke bevoorrechte operaties uit te voeren. Ze hoeven niet toegankelijk te zijn voor intern of extern verkeer.
Als u een cluster beheert, kunt u gebruik maken van voor beperkingen op het gebruik van geprivilegieerde containers.
4. Vermijd het uitvoeren als root
Bevoorrechte containers zijn al besproken, maar het zal nog beter zijn als u daarnaast geen applicaties als root in de container draait. Als een aanvaller een remote kwetsbaarheid vindt in een applicatie met rootrechten die code-uitvoering mogelijk maakt, waarna hij via een nog onbekende kwetsbaarheid de container kan verlaten, zal hij root krijgen op de host.
De beste manier om dit te voorkomen is om in de eerste plaats niets als root uit te voeren. Om dit te doen, kunt u de richtlijn gebruiken USER Π² Dockerfile of runAsUser in Kubernetes. De clusterbeheerder kan het handhavingsgedrag ook configureren met behulp van .
5. Maak de applicatie eenvoudig te monitoren
Net als loggen is monitoring een integraal onderdeel van applicatiebeheer. Een populaire monitoringoplossing in de Kubernetes-gemeenschap is - een systeem dat automatisch pods en services detecteert die monitoring vereisen. (Opmerking. vert.: Zie ook onze over het onderwerp monitoring met behulp van Prometheus en Kubernetes.) is in staat Kubernetes-clusters te monitoren en bevat een eigen versie van Prometheus voor applicatiemonitoring.
Kubernetes-dashboard op Stackdriver
Prometheus verwacht dat de applicatie metrische gegevens doorstuurt naar het HTTP-eindpunt. Hiervoor beschikbaar . Hetzelfde formaat wordt gebruikt door andere tools zoals ΠΈ .
6. Maak de gezondheidsstatus van de app beschikbaar
Applicatiebeheer in de productie wordt ondersteund door het vermogen om de status ervan aan het hele systeem door te geven. Is de applicatie actief? Is het goed? Bent u klaar om verkeer te ontvangen? Hoe gedraagt ββhij zich? De meest voorkomende manier om dit probleem op te lossen is het implementeren van gezondheidscontroles (gezondheidchecks). Kubernetes kent twee typen: .
Voor liveness-sonde (vitaliteitscontroles) de applicatie moet een HTTP-eindpunt hebben dat een "200 OK"-antwoord retourneert als deze functioneel is en aan de basisafhankelijkheden is voldaan. Voor gereedheidssonde (servicegereedheidscontroles) de applicatie moet een ander HTTP-eindpunt hebben dat een '200 OK'-antwoord retourneert als de applicatie zich in een goede staat bevindt, de initialisatiestappen zijn voltooid en een geldig verzoek niet tot een fout leidt. Kubernetes zal alleen verkeer naar de container routeren als de applicatie volgens deze controles gereed is. Twee eindpunten kunnen worden samengevoegd als er geen verschil is tussen de liveness- en readiness-statussen.
Meer hierover kun je lezen in het gerelateerde artikel van Sandeep Dinesh, Developer Advocate van Google: β.
7. Kies zorgvuldig uw afbeeldingsversie
De meeste openbare en privΓ©afbeeldingen gebruiken een taggingsysteem dat vergelijkbaar is met het systeem dat wordt beschreven in . Als de afbeelding een systeem gebruikt dat dichtbij is , is het noodzakelijk om rekening te houden met de specifieke kenmerken van tagging. Labelen bijvoorbeeld latest kan vaak van afbeelding naar afbeelding worden verplaatst - er kan niet op worden vertrouwd als u voorspelbare en herhaalbare builds en installaties nodig heeft.
Je kunt het label gebruiken X.Y.Z (ze zijn bijna altijd ongewijzigd), maar houd in dit geval alle patches en updates van de afbeelding bij. Als de afbeelding die u gebruikt een tag heeft X.Y, dit is een goede optie voor de gulden middenweg. Door ervoor te kiezen ontvang je automatisch patches en vertrouw je tegelijkertijd op de stabiele versie van de applicatie.
PS van vertaler
Lees ook op onze blog:
- Β«";
- Β«";
- Β«";
- «» (recensie en videoverslag);
- «» (recensie en videoverslag);
- «» (recensie en videoverslag);
- «» (recensie en videoverslag);
- Β«.
Bron: www.habr.com