A podok közötti adatforgalom biztonságossá tere hálózati szabályzatokkal Azure Kubernetes Service (AKS)

Ha modern, mikroszolgáltatás-alapú alkalmazásokat futtat a Kubernetesben, gyakran szabályozni szeretné, hogy mely összetevők kommunikálhatnak egymással. A legkisebb jogosultság elvének alkalmazása arra vonatkozik, hogy a forgalom hogyan áramlik egy Azure Kubernetes Service fürt podja között. Tegyük fel, hogy valószínűleg közvetlenül a háttéralkalmazások felé szeretné blokkolni a forgalmat. A Kubernetes Hálózati szabályzat szolgáltatása lehetővé teszi a fürt podok közötti bejövő és bejövő forgalmára vonatkozó szabályok definiálást.

Ez a cikk bemutatja, hogyan telepítheti a hálózati házirend motorját, és hogyan hozhat létre Kubernetes hálózati szabályzatokat az AKS-hez a podok közötti forgalom szabályozásához. A hálózati szabályzatot csak Linux-alapú csomópontokhoz és podokhoz szabad használni az AKS-ban.

Előkészületek

Az Azure CLI 2.0.61-es vagy újabb verzióját kell telepítenie és konfigurálnia. A verzió azonosításához futtassa a következőt: az --version. Ha telepíteni vagy frissíteni szeretne: Az Azure CLI telepítése.

Tipp

Ha az előzetes verzióban a hálózati szabályzat funkciót használta, javasoljuk, hogy hozzon létre egy új fürtöt.

Ha továbbra is használni szeretné az előzetes verzióban hálózati szabályzatot használó meglévő tesztfürtöt, frissítse a fürtöt a legújabb ga kiadású Új Kubernetes-verzióra, majd telepítse a következő YAML-jegyzékfájlt az összeomló metrikakiszolgáló és a Kubernetes-irányítópult kijavítása érdekében. Ez a javítás csak a Calico hálózati házirendmotort használt fürtök esetén szükséges.

Ajánlott biztonsági eljárásként tekintse át ennek a YAML-jegyzéknek a tartalmát, hogy megértse, mi van telepítve az AKS-fürtön.

kubectl delete -f https://raw.githubusercontent.com/Azure/aks-engine/master/docs/topics/calico-3.3.1-cleanup-after-upgrade.yaml

A hálózati szabályzat áttekintése

Alapértelmezés szerint az AKS-fürt összes podja korlátozás nélkül küldhet és fogadhat forgalmat. A biztonság javítása érdekében meghatározhatja a forgalom áramlását vezérlő szabályokat. A háttéralkalmazások gyakran csak a szükséges előoldali szolgáltatások számára vannak elérhetővé téve, például. Vagy az adatbázis-összetevők csak a hozzájuk kapcsoló alkalmazásrétegek számára érhetők el.

A Hálózati szabályzat egy Kubernetes-specifikáció, amely hozzáférési szabályzatokat határoz meg a podok közötti kommunikációhoz. A Hálózati szabályzatok használatával egy rendezett szabálykészletet definiálhat a forgalom küldését és fogadását, és alkalmazhatja őket egy vagy több címkeválasztóval egyező podgyűjteményre.

Ezek a hálózatiszabály-szabályok YAML-jegyzékként vannak definiálva. A hálózati szabályzatok egy szélesebb körű jegyzékfájl részét is alkothatja, amely egyben üzembe helyezést vagy szolgáltatást is létrehoz.

Hálózati szabályzat beállításai az AKS-ban

Az Azure két módszert kínál a hálózati szabályzat megvalósításához. Az AKS-fürt létrehozásakor hálózati házirend-beállítást kell választania. A szabályzat beállítását a fürt létrehozása után nem lehet módosítani:

  • Az Azure saját implementációja, az Azure Hálózati szabályzatok.
  • Calico Network Policies, egy nyílt forráskódú hálózati és hálózati biztonsági megoldás, amelyet a Következő vállalat ad meg:

Mindkét implementáció Linux IPTable-ket használ a megadott szabályzatok kényszerítésében. A házirendek engedélyezett és nem engedélyezett IP-párok készleteibe vannak lefordítva. Ezek a párok ezután IPTable szűrőszabályokként programozhatóak.

Az Azure- és Calico-szabályzatok és képességeik közötti különbségek

Képesség Azure Calico
Támogatott platformok Linux Linux, Windows Server 2019 (előzetes verzió)
Támogatott hálózati lehetőségek Azure CNI Azure CNI (Windows Server 2019 és Linux) és a kubenet (Linux)
Megfelelőség a Kubernetes-specifikációnak Az összes támogatott szabályzattípus Az összes támogatott szabályzattípus
További funkciók None Bővített házirendmodell, amely a globális hálózati házirendet, a globális hálózati készletet és a gazdagép végpontját tartalmazza. További információ a kiterjesztett funkciók cli használatával való calicoctl kezeléséhez: calicoctl
Támogatás A Azure-támogatás és mérnöki csapat által támogatott Calico közösségi támogatás. A további fizetős támogatással kapcsolatos további információkért lásd a Project-támogatási lehetőségeket.
Naplózás Az IPTable-ben hozzáadott/törölt szabályok minden gazdagépen a /var/log/azure-npm.log fájlban vannak naplózva További információ: Calico component logs (A Calico-összetevők naplói)

AKS-fürt létrehozása és hálózati szabályzat engedélyezése

A hálózati szabályzatok hatásának meghatározásához hozzunk létre, majd bontsunk ki egy olyan szabályzatot, amely meghatározza a forgalom áramlását:

  • Tiltsa le a podra való összes forgalmat.
  • Forgalom engedélyezése podcímkék alapján.
  • Forgalom engedélyezése névtér alapján.

Először hozzunk létre egy hálózati szabályzatot támogató AKS-fürtöt.

Fontos

A hálózati házirend funkció csak a fürt létrehozásakor engedélyezhető. Meglévő AKS-fürtön nem engedélyezhető hálózati szabályzat.

Az Azure Network Policy használata érdekében az Azure CNI beépülő modult kell használnia, és meg kell határoznia a saját virtuális hálózatát és alhálózatát. A szükséges alhálózati tartományok tervezésével kapcsolatos további információkért lásd: Speciális hálózat beállítása. A Calico Hálózati szabályzat ugyanezekkel a beépülő modulokkal Azure CNI a Kubenet CNI beépülő modulhoz is használható.

Az alábbi példaszkprogram:

  • Egy virtuális hálózatot és alhálózatot hoz létre.
  • Létrehoz egy Azure Active Directory (Azure AD) szolgáltatásnév az AKS-fürthöz való használatra.
  • Közreműködői engedélyeket rendel az AKS-fürt szolgáltatásnévhez a virtuális hálózaton.
  • Létrehoz egy AKS-fürtöt a meghatározott virtuális hálózatban, és engedélyezi a hálózati szabályzatot.
    • A rendszer az Azure Hálózati szabályzat lehetőséget használja. Ha ehelyett Calico-t használna hálózati szabályzatként, használja a --network-policy calico paramétert. Megjegyzés: A Calico a vagy a segítségével --network-plugin azure is --network-plugin kubenet használható.

Vegye figyelembe, hogy szolgáltatásnév használata helyett felügyelt identitást is használhat az engedélyekhez. További információ: Felügyelt identitások használata.

Adja meg saját biztonságos SP_PASSWORD. A változók és RESOURCE_GROUP_NAMECLUSTER_NAME lecserélhető:

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --role Contributor --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

AKS-fürt létrehozása Azure hálózati szabályzatok számára

Hozza létre az AKS-fürtöt, és adja meg a virtuális hálózatot, a szolgáltatásnév adatait és az Azure-t a hálózati beépülő modulhoz és a hálózati szabályzathoz.

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-plugin azure \
    --network-policy azure

A fürt létrehozása néhány percet vesz igénybe. Amikor a fürt elkészült, konfigurálja a parancsot a Kubernetes-fürthöz való csatlakozásra kubectlkubectl Ez a parancs letölti a hitelesítő adatokat, és konfigurálja a Kubernetes parancssori felületét a használatukhoz:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

AKS-fürt létrehozása Calico hálózati szabályzatok számára

Hozza létre az AKS-fürtöt, és adja meg a virtuális hálózatot, a szolgáltatásnév adatait, az Azure-t a hálózati beépülő modulhoz és a calico adatokat a hálózati házirendhez. A calico hálózati szabályzatként való használata lehetővé teszi a Calico-hálózatépítést Linux és Windows csomópontkészletek esetén is.

Ha új csomópontkészleteket Windows a fürthöz, adja hozzá a és paramétereket, amelyek megfelelnek a Windows windows-admin-usernamewindows-admin-passwordwindows-admin-username Ha Calico-t Windows csomópontkészletekkel, regisztrálnia kell a következőt is: Microsoft.ContainerService/EnableAKSWindowsCalico .

Regisztrálja EnableAKSWindowsCalico a funkciójelölőt EnableAKSWindowsCalico az alábbi példában látható módon:

az feature register --namespace "Microsoft.ContainerService" --name "EnableAKSWindowsCalico"

A regisztráció állapotát az az feature list paranccsal ellenőrizheti:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAKSWindowsCalico')].{Name:name,State:properties.state}"

Ha készen áll, frissítse a Microsoft.ContainerService erőforrás-szolgáltató regisztrációját az az provider register paranccsal:

az provider register --namespace Microsoft.ContainerService

Fontos

A Calico hálózati szabályzatok Windows-csomópontokkal való használata jelenleg a Kubernetes 1.20-as vagy újabb verzióját és a Calico 3.17.2-es verzióját használó új fürtökön érhető el, és Azure CNI szükséges. Windows Calico-t engedélyező AKS-fürtök összes csomópontján a Direct Server Return (DSR) is alapértelmezés szerint engedélyezve van.

A Kizárólag a Kubernetes 1.20-at futtató, a Calico korábbi verzióit futtató Linux-csomópontkészletekkel futó fürtök esetén a Calico-verzió automatikusan frissül a 3.17.2-es verzióra.

A Windows hálózati szabályzatok előzetes verziója jelenleg előzetes verzióban érhető el.

Fontos

Az AKS előzetes verziójú funkciói önkiszolgáló, feliratkozási alapon érhetők el. Az előzetes verziók "adott időben" és "elérhetőként" érhetők el, és ki vannak zárva a szolgáltatásiszint-szerződésekből és a korlátozott jótállásból. Az AKS előzetes verzióit részlegesen lefedi az ügyfélszolgálat. Így ezek a funkciók nem éles környezetben használhatók. További információt a következő támogatási cikkekben talál:

Hozzon létre egy felhasználónevet, amely rendszergazdai hitelesítő Windows a fürtön található kiszolgálótárolókhoz. Az alábbi parancsok felhasználónevet kérnek, és WINDOWS_USERNAME egy későbbi parancsban való használatra beállítják azt (ne feledje, hogy a cikkben megadott parancsok egy BASH-rendszerhéjban vannak megadva).

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --windows-admin-username $WINDOWS_USERNAME \
    --vm-set-type VirtualMachineScaleSets \
    --kubernetes-version 1.20.2 \
    --network-plugin azure \
    --network-policy calico

A fürt létrehozása néhány percet vesz igénybe. Alapértelmezés szerint a fürt csak Linux-csomópontkészletekkel jön létre. Ha csomópontkészleteket szeretne Windows használni, hozzáadhat egyet. Például:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Amikor a fürt elkészült, konfigurálja a parancsot a Kubernetes-fürthöz való csatlakozásra kubectlkubectl Ez a parancs letölti a hitelesítő adatokat, és konfigurálja a Kubernetes parancssori felületét a használatukhoz:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Podra irányuló összes bejövő forgalom megtagadása

Mielőtt meghatározott hálózati forgalmat engedélyező szabályokat határozna meg, először hozzon létre egy hálózati szabályzatot, amely megtagadja az összes forgalmat. Ez a szabályzat kiindulási pontot biztosít ahhoz, hogy csak a kívánt forgalomhoz hozzon létre engedélyezési listát. Azt is láthatja, hogy a hálózati szabályzat alkalmazásakor a forgalom el lesz dobva.

A mintaalkalmazás-környezet és a forgalmi szabályok esetében először hozzunk létre egy development (fejlesztés) nevű névteret a példa podok futtatásához:

kubectl create namespace development
kubectl label namespace/development purpose=development

Hozzon létre egy NGINX-et futtató háttérpodot. Ez a háttérpod egy mintás háttér-webalkalmazás szimulálására használható. Hozza létre ezt a podot a fejlesztési névtérben, és nyissa meg a 80-as portot a webes forgalom kiszolgálására. Címkézze fel a podot az app=webapp,role=backend címkével, hogy a következő szakaszban hálózati szabályzattal célozható meg:

kubectl run backend --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --labels app=webapp,role=backend --namespace development --expose --port 80

Hozzon létre egy másik podot, és csatoljon egy terminál-munkamenetet annak tesztelése érdekében, hogy sikeresen eléri-e az alapértelmezett NGINX-weblapot:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

A rendszerhéj parancssorában a használatával győződjön meg arról, hogy wget hozzáfér az alapértelmezett NGINX-weblaphoz:

wget -qO- http://backend

Az alábbi példakimeneten az látható, hogy az alapértelmezett NGINX-weblapot a rendszer visszaadta:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Lépjen ki a csatolt terminál-munkamenetből. A tesztpod automatikusan törlődik.

exit

Hálózati szabályzat létrehozása és alkalmazása

Most, hogy megerősítette, hogy használhatja az alapszintű NGINX weblapot a minta háttérpodon, hozzon létre egy hálózati szabályzatot, amely megtagadja az összes forgalmat. Hozzon létre egy nevű fájlt, backend-policy.yaml és illessze be a következő YAML-jegyzékfájlt. Ez a jegyzékfájl egy podSelector használatával csatolja a szabályzatot olyan podokhoz, amelyek az app:webapp,role:backend címkével vannak felcímkézve, a mintában használt NGINX-podhoz hasonló módon. Nincsenek szabályok definiálva a bejövő forgalom alatt,így a podra irányuló összes bejövő forgalom le van tiltva:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

Nyissa meg https://shell.azure.com a Azure Cloud Shell a böngészőben.

Alkalmazza a hálózati szabályzatot a kubectl apply paranccsal, és adja meg a YAML-jegyzékfájl nevét:

kubectl apply -f backend-policy.yaml

A hálózati szabályzat tesztelése

Lássuk, használhatja-e újra az NGINX weblapot a háttérpodon. Hozzon létre egy másik tesztpodot, és csatoljon egy terminál-munkamenetet:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

A rendszerhéj parancssorában a használatával nézze meg, hogy wget hozzáfér-e az alapértelmezett NGINX-weblaphoz. Ezúttal állítson be 2 másodperces időtúllépési értéket. A hálózati szabályzat most már minden bejövő forgalmat letilt, így az oldal nem tölthető be, ahogy az alábbi példában látható:

wget -O- --timeout=2 --tries=1 http://backend
wget: download timed out

Lépjen ki a csatolt terminál-munkamenetből. A tesztpod automatikusan törlődik.

exit

Bejövő forgalom engedélyezése podcímke alapján

Az előző szakaszban egy háttér-NGINX-pod volt ütemezve, és létrejött egy hálózati szabályzat, amely megtagadja az összes forgalmat. Hozzunk létre egy előoldali podot, és frissítjük a hálózati szabályzatot úgy, hogy engedélyezze az előoldali podok forgalmát.

Frissítse a hálózati szabályzatot, hogy engedélyezze a podok forgalmát az app:webapp, role:frontend címkével és bármely névtérben. Szerkessze az előző backend-policy.yaml fájlt, és adjon hozzá matchLabels bejövő szabályokat, hogy a jegyzékfájl az alábbi példához hasonlítsa:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Megjegyzés

Ez a hálózati szabályzat egy namespaceSelector és egy podSelector elemet használ a bejövő szabályhoz. A YAML-szintaxis fontos ahhoz, hogy a bejövő forgalom szabályai additívak lesznek. Ebben a példában mindkét elemnek egyeznie kell a bejövő szabály alkalmazáshoz. Előfordulhat, hogy az 1.12 előtti Kubernetes-verziók nem megfelelően értelmezik ezeket az elemeket, és a várt módon korlátozzák a hálózati forgalmat. További információ erről a viselkedésről: Választók viselkedése.

Alkalmazza a frissített hálózati szabályzatot a kubectl apply paranccsal, és adja meg a YAML-jegyzékfájl nevét:

kubectl apply -f backend-policy.yaml

Ütemezz az app=webapp,role=frontend címkével jelölt podot, és csatoljon egy terminál-munkamenetet:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

A rendszerhéj parancssorában a használatával nézze meg, hogy wget hozzáfér-e az alapértelmezett NGINX-weblaphoz:

wget -qO- http://backend

Mivel a bejövő forgalom szabálya engedélyezi a forgalmat a címkéket felcímkéző alkalmazással: webapp,role: előtere, az előtere podról származó forgalom engedélyezett. Az alábbi példakimenet az alapértelmezett NGINX-weblapot jeleníti meg:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Lépjen ki a csatolt terminál-munkamenetből. A pod automatikusan törlődik.

exit

Pod tesztelése egyező címke nélkül

A hálózati szabályzat engedélyezi az alkalmazás címkével jelölt podok forgalmát: webalkalmazás,szerepkör:előtere , de minden más forgalmat le kell tiltani. Teszteljük, hogy a címkék nélküli másik podok hozzáférhetnek-e a háttér NGINX-podhoz. Hozzon létre egy másik tesztpodot, és csatoljon egy terminál-munkamenetet:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

A rendszerhéj parancssorában a használatával nézze meg, hogy wget hozzáfér-e az alapértelmezett NGINX-weblaphoz. A hálózati szabályzat blokkolja a bejövő forgalmat, így az oldal nem tölthető be, ahogy az alábbi példában látható:

wget -O- --timeout=2 --tries=1 http://backend
wget: download timed out

Lépjen ki a csatolt terminál-munkamenetből. A tesztpod automatikusan törlődik.

exit

Csak meghatározott névtéren belülről származó forgalom engedélyezése

Az előző példákban létrehozott egy hálózati szabályzatot, amely megtagadta az összes forgalmat, majd frissítette a szabályzatot, hogy engedélyezze az adott címkével bíró podok forgalmát. Egy másik gyakori cél a forgalom korlátozása egy adott névtéren belülre. Ha az előző példák egy fejlesztési névtér forgalmára voltak, hozzon létre egy hálózati szabályzatot, amely megakadályozza, hogy egy másik névtérből, például az éles környezetből származó forgalom elérje a podokat.

Először hozzon létre egy új névteret az éles névtér szimulálására:

kubectl create namespace production
kubectl label namespace/production purpose=production

Ütemezz az éles névtérben az app=webapp,role=frontendcímkével jelölt tesztpodot. Terminál-munkamenet csatolása:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

A rendszerhéj parancssorában a használatával győződjön meg arról, hogy wget hozzáfér az alapértelmezett NGINX-weblaphoz:

wget -qO- http://backend.development

Mivel a pod címkéi megegyeznek a hálózati szabályzatban jelenleg engedélyezett címkékkel, a forgalom engedélyezett. A hálózati szabályzat nem a névtereket, csak a podcímkéket nézi meg. Az alábbi példakimenet az alapértelmezett NGINX-weblapot jeleníti meg:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Lépjen ki a csatolt terminál-munkamenetből. A tesztpod automatikusan törlődik.

exit

A hálózati szabályzat frissítése

Frissítjük a bejövő forgalmi szabály namespaceSelector szakaszát, hogy csak a fejlesztési névtéren belülről engedélyezze a forgalmat. Szerkessze a backend-policy.yaml jegyzékfájlt az alábbi példában látható módon:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Összetettebb példákban több bejövő szabályt is definiálhat, például egy namespaceSelector, majd egy podSelector szabályt.

Alkalmazza a frissített hálózati szabályzatot a kubectl apply paranccsal, és adja meg a YAML-jegyzékfájl nevét:

kubectl apply -f backend-policy.yaml

A frissített hálózati szabályzat tesztelése

Ütemezz egy másik podot az éles névtérben, és csatoljon egy terminál-munkamenetet:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

A rendszerhéj parancssorában a parancs használatával wget láthatja, hogy a hálózati szabályzat most megtagadja a forgalmat:

wget -O- --timeout=2 --tries=1 http://backend.development
wget: download timed out

Lépjen ki a tesztpodból:

exit

Ha az éles névtérről megtagadta a forgalmat, ütemez egy tesztpodot a fejlesztési névtérben, és csatoljon egy terminál-munkamenetet:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

A rendszerhéj parancssorában a használatával láthatja, hogy a wget hálózati szabályzat engedélyezi-e a forgalmat:

wget -qO- http://backend

A forgalom azért engedélyezett, mert a pod a hálózati szabályzatban engedélyezettnek megfelelő névtérben van ütemezve. Az alábbi kimenetminta az alapértelmezett NGINX-weblapot jeleníti meg:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Lépjen ki a csatolt terminál-munkamenetből. A tesztpod automatikusan törlődik.

exit

Az erőforrások eltávolítása

Ebben a cikkben két névteret hoztunk létre, és hálózati szabályzatot alkalmaztunk. Az erőforrások törléséhez használja a kubectl delete parancsot, és adja meg az erőforrásneveket:

kubectl delete namespace production
kubectl delete namespace development

Következő lépések

További információ a hálózati erőforrásokról: Hálózati fogalmak alkalmazásokhoz a Azure Kubernetes Service (AKS) szolgáltatásban.

A szabályzatokkal kapcsolatos további információkért lásd: Kubernetes hálózati szabályzatok.