Nätverksbegrepp för Windows-containrar

10 minuter

Processorn på en Windows-standarddator har ett kernelläge och ett användarläge. De viktigaste OPERATIVSYSTEM-komponenterna och de flesta enhetsdrivrutiner körs i kernelläge och appar körs i användarläge. När du implementerar containrar på datorn skapar varje container en isolerad, lätt miljö för att köra appar på värdoperativsystemet. Containern delar det mesta av värdoperativsystemets kernel för åtkomst till filsystemet och registret.

Windows-containrar behöver ett containeroperativsystem. Containern är beroende av OS-kerneln för att hantera tjänster som filsystem, nätverk, processschemaläggning och minneshantering. Containeroperativsystemet är det operativsystem som ingår i den paketerade körningen. Du kan använda olika versioner av Windows med dina containrar för att ge åtkomst till specifika os-funktioner eller annan nödvändig programvara.

Nätverksisolering och säkerhet

Windows-containrar stöder två typer av körningsisolering: Process och Hyper-V. Den primära skillnaden är omfattningen av isoleringen som skapas mellan containern, värdoperativsystemet och de andra containrarna på värdoperativsystemet.

Processisolering är den vanligaste metoden. Flera containerinstanser som körs på samma värd isoleras via namnområdet och inställningarna för resurskontroll, tillsammans med andra processisoleringsfunktioner.

Varje container delar samma kernel med värd-OS:et och andra containrar på värdmaskinen.
Varje container har ett virtuellt nätverkskort som ansluter till en virtuell växel.
Varje containerslutpunkt placeras i sitt eget nätverksnamnområde. Standardnamnet för nätverket är platsen för värddatorns virtuella nätverkskort och värdnätverksstacken.

Hyper-V isolering ger förbättrad säkerhet och bredare kompatibilitet mellan värden och containrar. Flera containerinstanser körs på samma värd, men varje container körs på en optimerad virtuell dator. Den virtuella datorn tillhandahåller isolering på maskinvarunivå mellan varje container och containervärden.

Varje container har i princip sin egen kernel.
För att framtvinga nätverksisolering mellan containrarna på värden skapas ett nätverksnamnområde för varje container.
Containrarna körs med Hyper-V-isolering där det virtuella nätverkskortet för containern är installerat. Windows Server-containrar använder ett virtuellt värdnätverkskort för att ansluta till den virtuella växeln. Hyper-V isolering använder ett syntetiskt nätverkskort för virtuella datorer (som inte exponeras för den virtuella datorn) för att ansluta till den virtuella växeln.

diagram som visar hur den virtuella datorn tillhandahåller isolering på maskinvarunivå mellan varje container och containervärden.

Nätverkshantering med värdnätverkstjänsten (HNS)

Windows använder värdnätverkstjänsten (HNS) och Värdberäkningstjänsten (HCS) för att skapa containrar och koppla slutpunkter till nätverket.

Network: HNS skapar en Hyper-V virtuell växel för varje nätverk och HNS skapar nödvändiga NAT- och IP-pooler.
Slutpunkter: HNS skapar nätverksnamnområdet för varje containerändpunkt och HNS/HCS lägger till den virtuella nätverksadaptern i nätverksnamnområdet. HNS skapar virtuella växelportar. HNS tilldelar IP-adressen, DNS-information (Domain Name System), vägar och så vidare till slutpunkten enligt det konfigurerade nätverksdrivrutinsläget.
Principer: För standard-NAT-nätverket skapar HNS WinNAT-portvidarebefordringsregler och mappningar med motsvarande TILLÅT-regler för Windows-brandväggen. För alla andra nätverk använder HNS VFP (Virtual Filtering Platform) för att skapa principer för belastningsutjämning, ACL:er och inkapsling.

Brandväggsinteraktion

Beroende på containerkonfigurationen och typen av nätverksdrivrutin tillämpas port-ACL:er av en kombination av Windows-brandväggen och Azure Virtual Filtering Platform (VFP). Följande värden använder Windows-värdarnas brandvägg (förstärkt med nätverksnamnrymder) och VFP:

Utgående standard: TILLÅT ALLT.
Standard inkommande: TILLÅT ALL (TCP, UDP, ICMP, IGMP) oönskad nätverkstrafik. NEKA ALL annan nätverkstrafik som inte kommer från dessa protokoll.

Nätverksdrivrutiner

Windows stöder fem olika nätverksdrivrutiner eller lägen för Docker-containrar: NAT, Transparent, Overlay, L2Bridge och L2Tunnel. Förutom det NAT-standardnätverk som skapats av Docker i Windows kan du också definiera anpassade containernätverk med hjälp av kommandot docker network create från Docker CLI.

I följande tabell sammanfattas de typer av nätverksdrivrutiner som är tillgängliga för Docker-containrar i Windows. Välj den nätverksdrivrutin som uppfyller kraven för den fysiska nätverksinfrastrukturen och värdkonfigurationen (en eller flera noder).

Nätverksdrivrutin	Vanliga användningsområden	Container-till-container (enskild nod)	Container-till-extern (enskild nod + flera noder)	Container-till-container kommunikation (över flera noder)
NAT (standard)	Bra för utvecklare	Samma undernät: Bryggd anslutning via Hyper-V virtuell växel Korsundernät: Stöds inte (endast ett internt NAT-prefix)	Dirigeras via hantering av virtuellt nätverkskort (bundet till WinNAT)	Stöds inte direkt: kräver att portar exponeras via värddatorn
Transparent	Bra för utvecklare eller små distributioner	Samma undernät: Bryggd anslutning via Hyper-V virtuell växel Korsundernät: Dirigeras genom containervärd.	Dirigeras via containerhost med direkt åtkomst till (fysiskt) nätverkskort	Dirigeras via containervärd med direkt åtkomst till (fysiskt) nätverkskort
Överlagring	Bra för flera noder; krävs för Docker Swarm, tillgängligt i Kubernetes	Samma undernät: Bryggd anslutning via Hyper-V virtuell växel Över subnät: Nätverkstrafik kapslas in och dirigeras genom det virtuella nätverkskortet för hantering.	Stöds inte direkt – kräver den andra containerslutpunkten som är ansluten till NAT-nätverket på Windows Server 2016 eller VFP NAT-regeln i Windows Server 2019.	Samma/korsande undernät: Nätverkstrafiken kapslas in med hjälp av VXLAN och dirigeras via hantering av virtuellt nätverkskort
L2Bridge	Används för Kubernetes och Microsoft Software Designed Network (SDN)	Samma undernät: Bryggd anslutning via Hyper-V virtuell växel Korssubnät: Container-MAC-adress skrivs om vid både inkommande och utgående trafik och dirigeras.	MAC-adress för container
skrivs om vid infart och utfart	Samma undernät: Bryggd anslutning Korsundernät: dirigeras via hantering av virtuellt nätverkskort på WSv1809 och senare
L2Tunnel	Endast Azure	Samma/korsande undernät: Hårfäst på den fysiska värdens Hyper-V virtuella växel till där principen tillämpas.	Trafiken måste gå via en virtuell Azure-nätverksgateway	Samma/korsande subnät: Kopplat till den fysiska värdens Hyper-V virtuella switch där policyn tillämpas.

Avancerade nätverksalternativ

Du kan dra nytta av flera alternativ för nätverksdrivrutiner för Windows-specifika funktioner. Här följer några exempel:

Få åtkomst till Switch Embedded Teaming för containervärdnätverk genom att ange flera nätverkskort för din Windows-container.
Ange VLAN-ID för ett nätverk för att konfigurera VLAN-isolering för alla containerslutpunkter som ansluter till nätverket.
Ange principen OutboundNAT för ett nätverk så att din container får åtkomst till omvärlden.