Wat zijn containernetwerklogboeken?

Containernetwerklogboeken in Advanced Container Networking Services voor Azure Kubernetes Service (AKS) helpen u bij het onderzoeken van welke workloads hebben gecommuniceerd, welke bestemmingen ze hebben bereikt en of verkeer is doorgestuurd of geblokkeerd. Gebruik metrische gegevens om een netwerkprobleem op te sporen en gebruik vervolgens logboeken om het betrokken verkeer te onderzoeken. Een flow-oordeel alleen bepaalt niet of een applicatieverzoek is geslaagd.

Afhankelijk van het stroomtype, de zichtbaarheidsconfiguratie en de bewaarde aggregatievelden, kunnen logboeken het volgende omvatten:

• Bron- en doel-IP-adressen, podnamen en servicenamen
• Naamruimten, poorten en protocollen
• Verkeersrichting en beleidsbeoordelingen

Met deze context kunt u netwerkgedrag correleren met specifieke workloads, verbindingsproblemen oplossen, beveiligingsbeleid valideren en forensische analyse uitvoeren. Containernetwerklogboeken hebben betrekking op Laag 3-verkeer (IP), Laag 4-verkeer (TCP/UDP) en Laag 7-verkeer (HTTP/gRPC).

Voor opgeslagen logs helpt aanpasbare aggregatie van flowlogs u een balans te vinden tussen operationele zichtbaarheid, gegevensvolume en kosten. Aggregatie geeft een overzicht van vergelijkbare waarnemingen, met behoud van communicatiepatronen van werkbelastingen en aantallen doorgestuurde of weggevallen waarnemingen. Voeg groeperingsvelden toe buiten de standaardinstellingen van de service om deze samenvattingen aan te passen aan uw behoeften. De volumevermindering is afhankelijk van hoeveel verkeer dezelfde groeperingswaarden deelt. Zie Stroomlogboekaggregatie voor meer informatie.

Een verzamelmodus kiezen

Begin met containernetwerklogboeken instellen. De handleiding maakt onderscheid tussen verzameling, optioneel doorsturen naar Azure Monitor en verificatie.

Opgeslagen logboeken

Definieer op een ondersteund Cilium-cluster waarvoor ACNS is ingeschakeld, welk verkeer moet worden verzameld voordat opgeslagen logboeken worden verwacht. Als u de service alleen inschakelt, selecteert u geen verkeer of configureert u langetermijnretentie.

Als u logboeken wilt verzamelen, definieert u ContainerNetworkLog aangepaste resources die verkeer selecteren op naamruimte, pod, labels, IP-adres, numerieke Cilium-beveiligingsidentiteit, protocol of oordeel. Nadat de configuratie de agents heeft bereikt, schrijven knooppunten die overeenkomend verkeer observeren de geselecteerde logs. Meerdere resources kunnen tegelijkertijd verkeer verwerken.

Gebruik filters om u te richten op de flows die belangrijk zijn. Gebruik aggregatie van flowlogboeken om deze stromen samen te vatten en de groeperingsvelden aan te passen om het onderscheid te behouden dat uw onderzoeken nodig hebben. Samen kunt u met deze besturingselementen afstemmen wat u verzamelt en hoe dit wordt samengevat. Bekijk het resulterende gegevensvolume: smallere filters kunnen de verzameling verminderen, terwijl meer groeperingsvelden het aantal records kunnen verhogen.

Hoe de modus voor opgeslagen logboeken werkt

Advanced Container Networking Services maakt gebruik van eBPF-technologie met Cilium om netwerkstromen op elk knooppunt vast te leggen. Zodra ACNS is ingeschakeld en er een ContainerNetworkLog aangepaste resource wordt toegepast, verzamelt de Cilium-agent verkeer dat overeenkomt met het filter en schrijft logboeken in JSON-indeling naar /var/log/acns/hubble/events.log elke host. Logboekgeneratie wordt volledig binnen het cluster uitgevoerd en is niet afhankelijk van Azure Monitor.

Voor productiegebruik raden we u aan de Azure Monitor-invoegtoepassing in te schakelen. Wanneer deze functie is ingeschakeld, verzamelen Container Insights-agents host-lokale logboeken, passen beperkingslimieten toe en verzenden ze naar een Log Analytics werkruimte, waar u langetermijnretentie, KQL-query's en de ingebouwde Azure portal- en Grafana-dashboards krijgt. Dit is het meest geïntegreerde traject en de meeste klanten zouden dit moeten kiezen.

Als uw team een bestaande pijplijn voor waarneembaarheid heeft, kunt u in plaats daarvan dezelfde hostlogboeken doorsturen naar een openTelemetry-compatibele collector- of logboekregistratieservice, naast Azure Monitor of in plaats daarvan.

Zie de Container Insights-documentatie voor meer informatie over throttling en Container Insights.

Containernetwerklogboeken gebruiken met of zonder Azure Monitor

Gebruik Azure Monitor voor geïntegreerde query's en dashboards of bewaar uw bestaande pijplijn voor logboekregistratie.

Zonder een forwarding-pipeline blijven logs in roterende, node-lokale bestanden en worden ze niet bewaard voor langdurige onderzoeken.

Belangrijkste mogelijkheden van de opgeslagen logboekmodus

Pas uw observability aan uw behoeften aan: kies welk verkeer u wilt verzamelen en welke details u wilt gebruiken om onderscheid te maken wanneer u dit groepeert in opgeslagen logboeken.

• Aanpasbare filters. Definieer aangepaste ContainerNetworkLog-resources om verkeer te selecteren op bron- of doelnamespace, pod, label, IP-adres of CIDR-bereik, Cilium-beveiligingsidentiteit, protocol of uitkomst. Verkeer dat overeenkomt met de filters van een geconfigureerde resource komt in aanmerking voor verzameling, waardoor u controle hebt over wat u verzamelt en u helpt bij het beheren van het innamevolume.

• Aanpasbare aggregatie van flowlogboeken. Gebruik aggregatie om het opgeslagen logboekvolume te verminderen terwijl u de details behoudt die u nodig hebt voor netwerkonderzoeken. Standaard combineert aggregatie stroomobservaties met overeenkomende groeperingsveldwaarden elke 30 seconden tot samengevatte records. Voeg groeperingsvelden toe om details te bewaren buiten de standaardinstellingen van de service. Meer groeperingsvelden kunnen meer records produceren, dus koppel aggregatie met gerichte filters om een balans te vinden tussen onderzoeksbehoeften en inname- en opslagkosten. Meer informatie over flowlogaggregatie.

• Opties voor logboekopslag. ACNS schrijft logboeken altijd lokaal op elk knooppunt. Van daaruit kunt u kiezen hoe u ze kunt gebruiken:

  • Lokale hostbestanden (altijd ingeschakeld): Logboeken worden opgeslagen op hostknooppunten op /var/log/acns/hubble. Bestanden worden automatisch geroteerd bij 50 MB, en oudere logboeken worden overschreven. Gebruik dit rechtstreeks voor kortetermijnbewaking, realtime bewaking of doorsturen van de bestanden naar een openTelemetry-compatibele collector- of logboekregistratieservice voor extra logboekbeheer.

  • Azure Monitor (aanbevolen): Schakel de invoegtoepassing Azure Monitor in om logboeken in een Log Analytics werkruimte te verzamelen en op te slaan. U krijgt veilige, compatibele opslag met langetermijnretentie, KQL-query's, anomaliedetectie, historische analyse en waarschuwingen via de beheerde service voor Prometheus. Logboekgeneratie wordt nog steeds uitgevoerd via de Cilium-agent en de ContainerNetworkLog CRD; Azure Monitor voegt de verbruikslaag bovenaan toe.

    De ContainerNetworkLogs tabel maakt standaard gebruik van de analyselaag . U kunt overschakelen naar de Basic-laag voor lagere opname- en retentiekosten, terwijl u een vergelijkbare waarneembaarheidservaring behoudt. Elke laag heeft een toegewezen Azure portaldashboard dat is geoptimaliseerd voor de querymogelijkheden. Zie Log Analytics tabelplannen voor meer informatie over tabelplannen. Zie Het tabelplan instellen voor meer informatie over het instellen van het tabelplan.

• Visualisatie in de Azure-portal. Voer query's uit en analyseer logboeken in Log Analytics of gebruik het dashboard voor uw tariefplan. Bekijk de query- en bewaarmogelijkheden van het plan voordat u het kiest. Zie Visualiseer logboeken in de Azure portal voor meer informatie.

Logboeken visualiseren in de Azure-portal

Voor gedetailleerde onderzoeken opent u Monitoring> op de pagina van uw AKS-cluster in de Azure-portal. Voer in de ontvangende Log Analytics werkruimte een query uit op de ContainerNetworkLogs tabel.

Selecteer op de pagina van uw AKS-cluster in de Azure-portal Bewaking> om de ingebouwde stroomlogboekdashboards weer te geven. U hebt geen Azure Managed Grafana exemplaar nodig en er worden geen extra kosten in rekening gebracht voor de dashboards. ACNS en loginname- en retentiekosten zijn nog steeds van toepassing.

Kies het dashboard dat overeenkomt met uw ContainerNetworkLogs table plan:

Beide dashboards laten zien welke AKS-workloads met elkaar communiceren, inclusief netwerkaanvragen, antwoorden, verliezen en fouten. Gebruik het dashboard dat overeenkomt met de tabellaag die is geconfigureerd voor uw ContainerNetworkLogs tabel.

De Azure portaldashboards hebben de volgende belangrijke onderdelen:

• Overzicht van netwerkstatus. Bekijk verkeersoverzichten en doorgestuurde of genegeerde waarnemingen en gebruik vervolgens de serviceafhankelijkheidsgrafiek om communicatiepaden te identificeren die het onderzoeken waard zijn. Protocolspecifieke details zijn afhankelijk van zichtbaarheid en bewaarde velden. Geaggregeerde observatieaantallen zijn geen unieke aanvraagaantallen.

  

• Stroomlogboeken en foutenlogboeken. Het dashboard scheidt stroomlogboeken van foutenlogboeken in verschillende weergaven, zodat u zich kunt richten op fouten zonder normaal verkeer te doorzoeken. Gebruik de ingebouwde filters om de resultaten te beperken op basis van protocol, naamruimte of beoordeling. Als u bijvoorbeeld fouten met DNS-omzetting wilt oplossen, filtert u foutenlogboeken op basis van het DNS-protocol.

  

  De details die beschikbaar zijn in het dashboard, zijn afhankelijk van de verzamelde verkeersgegevens en de aggregatieconfiguratie. Zie Aggregatie van stroomlogboeken aanpassen om de details in uw opgeslagen logboeken aan te passen.

  Gebruik de beschikbare tijdstempels en bron-/doelgegevens om records te correleren met een onderzoek. Een geaggregeerd record biedt geen afzonderlijke tijdstempel voor elke observatie in de groep.

  

• Belangrijkste naamruimten, workloads en DNS-fouten. In deze sectie worden de meest actieve naamruimten, workloads met het hoogste verkeer, poortgebruik en meest frequente DNS-fouten weergegeven. Gebruik deze om te bepalen welke workloads het meeste verkeer genereren, verwijderde aanvragen spotten en protocoldistributie vergelijken (bijvoorbeeld TCP versus UDP). Ongebruikelijke patronen, zoals onverwachte pieken of onbekende bestemmingen, kunnen duiden op onjuiste configuraties of beveiligingsproblemen.

  

Aggregatie van stroomlogboek

Drukke workloads kunnen veel herhaalde flowwaarnemingen genereren tussen dezelfde eindpunten. Door elke observatie afzonderlijk op te slaan, neemt de hoeveelheid gegevens die u moet opnemen, behouden en zoeken toe, zelfs wanneer uw directe vraag simpelweg is welke workloads met elkaar communiceerden en of hun verkeer is doorgestuurd of geblokkeerd.

Aggregatie biedt een beginpunt met een lager volume voor historisch netwerkonderzoek. Elk knooppunt combineert geselecteerde stroomobservaties die dezelfde groeperingsveldwaarden delen binnen een aggregatie-interval. In plaats van elke observatie afzonderlijk te schrijven, schrijft het een samengevat record voor elke groep, inclusief aantallen inkomende, uitgaande en waarnemingen met onbekende richting.

Voorbeeld: Voor en na aggregatie

Overweeg twee clientpods, client-1 en client-2, die communiceren met een server-pod via TCP-poort 80 tijdens één venster van 30 seconden. Elke pod behoort tot een afzonderlijke workload met dezelfde naam als de pod. De volgende observaties illustreren het opzetten van verbindingen, gegevensoverdracht en reacties.

Voor aggregatie: tien waarnemingen

In deze illustratie ziet één knooppunt elk item eenmaal op de clienteindpunten: client-naar-server-observaties zijn uitgaand verkeer en antwoorden zijn inkomend. Alle oordelen zijn FORWARDED, en de andere standaardgroeperingswaarden zijn identiek binnen elke groep die hieronder wordt weergegeven.

Na standaardaggregatie: vier samengevatte records

De tien waarnemingen worden omgezet in vier records, met behoud van alle tien waarnemingen in hun tellingen. U kunt nog steeds zien welke workloads met elkaar communiceerden, de doelpoorten en het volume dat in elke richting is waargenomen, zonder dat u elke TCP-vlagovergang afzonderlijk hoeft op te slaan.

De groepen blijven om deze redenen gescheiden:

• Verschillende werkbelastingen: bron- en doelworkloadmetagegevens zijn standaardgroeperingsvelden.
• Origineel verkeer en antwoorden: eindpuntwaarden, doelpoorten en is_reply zijn verschillend, zodat de twee richtingen niet in één record worden samengevouwen.
• Verschillende antwoordbestemmingspoorten:12345 en 23456 worden bewaard als doelpoorten voor antwoordverkeer. Bronpoorten, afzonderlijke podnamen en TCP-vlaggen worden niet bewaard door de standaardgroeperingsconfiguratie.

Standaardinstellingen voor aggregatie

Aggregatie is standaard ingeschakeld voor opgeslagen logboeken, met een aggregatieinterval van 30 seconden en de standaardgroeperingsvelden die worden vermeld in de volgende tabel. Binnen het interval van elk knooppunt worden waarnemingen met dezelfde waarden voor alle groeperingsvelden gecombineerd tot een samengevatte record.

Een veld kan alleen een waarde bevatten wanneer die informatie beschikbaar is in de oorspronkelijke stroom. Standaardgroepering schakelt DNS- of HTTP-inspectie niet in.

Deze standaardwaarden behouden de communicatie van workloads, doelpoorten, oordelen en antwoordcodes. Ze behouden niet elk detail per stroom: afzonderlijke podnamen, bron- en doel-IP-adressen, clientbronpoorten, DNS-querynamen en HTTP-URL's staan niet in deze standaardlijst.

Aanvullende velden breiden deze lijst uit; ze vervangen het niet. U kunt met spec.aggregation.additionalFields groepering aanpassen zonder standaardvelden te verwijderen of het interval van 30 seconden te wijzigen. Als u een standaardveld herhaalt, wordt er geen andere kopie toegevoegd. Wijzigingen zijn van invloed op toekomstige records en weggelaten details uit historische logboeken kunnen niet worden hersteld.

Aggregatie van flowlogboeken aanpassen

Aggregatie van stroomlogboeken aanpassen aan uw operationele en onderzoeksvereisten door extra groeperingsvelden te kiezen buiten de standaardwaarden van de service. U bepaalt welk onderscheid uw samengevatte logboeken behouden, van verkeersrichting en DNS-aanvraag/antwoordtype tot afzonderlijke IP-adressen, DNS-namen of HTTP-URL's. Kies elk willekeurig veld dat wordt ondersteund door het flowschema van uw cluster om de vragen te beantwoorden die voor u belangrijk zijn.

Voeg velden toe aan spec.aggregation.additionalFields in een ContainerNetworkLog-resource om aggregatie aan te passen. De extra velden worden groeperingssleutels: stromen met verschillende waarden voor deze velden worden opgeslagen in afzonderlijke groepen.

Als u bijvoorbeeld de volgende velden toevoegt, worden waarnemingen gescheiden die anders dezelfde aggregatiegroep delen:

Deze velden zijn voorbeelden, geen volledige toestaanlijst. U kunt geldige veldpaden opgeven uit het Hubble-bericht Flow in de flow.proto-definitie van Cilium. Gebruik velden die worden ondersteund door de Cilium-versie die wordt uitgevoerd op uw cluster; de gekoppelde main vertakking kan velden bevatten die uw cluster nog niet ondersteunt. De oorspronkelijke stroom moet de waarde van een veld bevatten om die te behouden.

Velden met een hogere kardinaliteit, zoals IP-adressen, afzonderlijke podnamen, bronpoorten, DNS-namen en HTTP-URL's, zijn beschikbaar wanneer u dat detailniveau nodig hebt. Omdat ze veel afzonderlijke waarden kunnen hebben, kan het inschakelen ervan het logboekvolume en de opname- en opslagkosten in het cluster verhogen. Voordat u ze inschakelt, moet u de gevolgen voor het verwachte volume, de kosten en gevoelige gegevens beoordelen. Bewaak vervolgens het gebruik om het detailniveau dat u nodig hebt af te stemmen op uw budget.

Logboeken met de bewaarde velden worden op elk knooppunt waarop overeenkomend verkeer wordt waargenomen naar /var/log/acns/hubble/events.log geschreven. Wanneer Azure Monitor doorsturen is geconfigureerd, kunt u query's uitvoeren op de verzamelde logboeken in Log Analytics met behulp van de kolommen die beschikbaar zijn in de ContainerNetworkLogs tabel, inclusief bewaarde eigenschappen die worden weergegeven in de dynamische kolommen. Gebruik het tabelschema om de kolom of dynamische eigenschap te identificeren waarnaar in uw query moet worden verwezen.

Verkeer selecteren op beveiligingsidentiteit

Gebruik Cilium-beveiligingsidentiteiten in bron- of doelfilters om te kiezen welk verkeer moet worden vastgelegd. Combineer identiteitsfilters met criteria voor naamruimte, pod, protocol of verdict. Bijvoorbeeld: selecteer TCP-verkeer van een naamruimte naar eindpunten die Cilium als wereld classificeert.

Een beveiligingsidentiteit is de classificatie van een eindpunt van Cilium, niet een Azure beheerde identiteit of een gebruikersidentiteit. De configuratie accepteert numerieke id's, geen aliassen zoals world. Zie het voorbeeld van identiteit en de waarden.

Aanpasbare filters en aggregatie bieden aanvullende mogelijkheden: filters selecteren de te verzamelen flows, terwijl extra groeperingsvelden bepalen hoe alle geselecteerde flows in het cluster worden samengevat.

Inzicht in de reikwijdte en de kosten

Aanvullende velden zijn van toepassing op alle geselecteerde opgeslagen logboeken in het cluster. Ze zijn niet beperkt tot de filters in de resource waarmee ze worden opgevraagd.

Als bijvoorbeeld één resource l7.type aanvraagt en een andere traffic_direction aanvraagt, maken beide velden deel uit van de groeperingsconfiguratie van het cluster. Als u de eerste resource verwijdert, wordt het veld alleen verwijderd als geen andere geldige resource erom vraagt. Velden die door de service worden geleverd, blijven aanwezig.

Meer afzonderlijke veldwaarden kunnen meer records produceren. Begin met de velden die nodig zijn voor uw onderzoek, controleer het ingestievolume en verwijder tijdelijke toevoegingen wanneer u klaar bent. Stem wijzigingen af met andere teams die logboeken van hetzelfde cluster verzamelen.

Gebruik Containernetwerklogboeken configureren voor volledige YAML-voorbeelden en verificatiestappen.

Logboeken op aanvraag

Met logboeken op aanvraag kunt u flowlogs in realtime inspecteren zonder een opgeslagen logboekresource te definiëren of permanente opslag in te stellen. Schakel ACNS in en verbind eerst uw Hubble-client. Gebruik deze modus wanneer u direct inzicht nodig hebt tijdens het oplossen van problemen.

ACNS biedt twee hulpprogramma's voor opname op aanvraag. Als u een van beide hulpprogramma's wilt instellen, raadpleegt u de modus Logboeken op aanvraag configureren.

Hubble CLI

Met de Hubble CLI kunt u stroomlogboeken rechtstreeks vanuit uw terminal opvragen, filteren en analyseren. Het is vooral handig wanneer u fijnmazige filters nodig hebt, bijvoorbeeld het isoleren van verkeer op naamruimte, podlabel of oordeel tijdens een actieve foutopsporingssessie.

Hubble UI

De Hubble-gebruikersinterface biedt een grafische weergave van service-naar-service-communicatie. Het is handig als u verkeerspaden visueel wilt traceren, welke services communiceren en afwijkingen herkennen zonder CLI-opdrachten te schrijven.

Belangrijke voordelen van logboeken op aanvraag

• Er is geen opgeslagen logboekconfiguratie vereist. Nadat u Hubble hebt verbonden met uw CLUSTER met ACNS, inspecteert u de beschikbare flows zonder een ContainerNetworkLog resource te definiëren.
• Realtime zichtbaarheid. Inspecteer liveverkeer en bekijk pakketmetagegevens wanneer er problemen optreden.
• Snelle probleemoplossing. Filter gegevensstromen interactief via de Hubble CLI, of bekijk servicediagrammen visueel in de Hubble-UI.
• Er is geen permanente opslag vereist. Controleer livestromen zonder historische logboekopslag in te stellen. Servicekosten voor ACNS zijn nog steeds van toepassing.

Aanbevelingen voor opgeslagen logboeken

1. Begin met één workload en een duidelijke vraag. Selecteer de toepassing en het netwerkverkeer dat nodig is voor het onderzoek. Controleer recente records, controleer het volume en breid de verzameling indien nodig uit. Vermijd het inschakelen van een brede verzameling om te testen of logboekregistratie werkt.

2. Aggregatie aanpassen aan uw operationele behoeften. Kies extra groeperingsvelden die u helpen uw vragen te beantwoorden en de impact van het volume en de kosten te beoordelen. Coördineer wijzigingen in het hele cluster met andere teams en verwijder tijdelijke toevoegingen wanneer het onderzoek afloopt. Behandel DNS-namen en URL's als mogelijk gevoelige operationele gegevens.

3. Gebruik eerst de vooraf gemaakte dashboards. De ingebouwde Azure portaldashboards hebben betrekking op veelvoorkomende gebruiksvoorbeelden, zoals servicecommunicatiepatronen, foutpercentages en DNS-fouten. Begin daar. Voeg alleen aangepaste deelvensters of Log Analytics-queries toe als u zichtbaarheid nodig hebt die de vooraf gemaakte dashboards niet bieden.

4. Controleer regelmatig. Naarmate workloads en verkeerspatronen veranderen, moeten uw filters mogelijk worden bijgewerkt. Controleer regelmatig het gegevensvolume en de stroomdekking om ervoor te zorgen dat u nog steeds het juiste verkeer tegen redelijke kosten vastlegt.

Beperkingen

Vereisten voor gegevensvlak en functie:

• De modus Opgeslagen logboeken werkt alleen met het gegevensvlak Cilium.
• Stroomlogboeken van laag 7 worden alleen vastgelegd wanneer ondersteuning voor laag 7-beleid is ingeschakeld. Zie Een Laag 7-beleid configureren voor meer informatie.
• DNS-stromen en metrische gegevens worden alleen vastgelegd wanneer een FQDN-netwerkbeleid (Cilium Fully Qualified Domain Name) wordt toegepast. Zie Een FQDN-beleid configureren voor meer informatie.

Aggregatie-afwegingen:

• Aanvullende velden kunnen onderscheid behouden, zoals bron- en doel-IP-adressen, HTTP-URL's of DNS-querynamen. De oorspronkelijke stroom moet de gegevens bevatten.
• Velden zijn van toepassing op geselecteerde opgeslagen logs in het cluster en kunnen recordaantallen en innamekosten verhogen.
• Wijzigingen zijn van invloed op nieuw verzamelde gegevens. Ze herstellen geen details uit historische logboeken, wijzigen het tabelschema niet en voorzien niet elke gebeurtenis in een geaggregeerd record van een tijdstempel. Gebruik on-demand logs voor realtime inspectie per flow.

Opslag en platform:

• Het host-lokale bestand /var/log/acns/hubble/ is beperkt tot 50 MB per knooppunt en wordt automatisch geroteerd. Als u langetermijnretentie nodig hebt, schakelt u Azure Monitor (aanbevolen) in of stuurt u het bestand door naar uw eigen logboekregistratieservice.
• Het tabelplan Voor hulplogboeken wordt niet ondersteund.

Prijsstelling

Zie Advanced Container Networking Services - Prijzen voor meer informatie over prijzen.

Verwante inhoud

• DNS-namen identificeren die zijn gekoppeld aan fouten

• Netwerklogboeken van containers instellen

• Geavanceerde Container Networking Services voor AKS

• Containernetwerkobservatie in Geavanceerde Container Netwerkdiensten

• Container Network Security in Advanced Container Networking Services