1. Einführung
GCP unterstützt seit Langem mehrere Schnittstellen auf VM-Instanzebene. Mit mehreren Schnittstellen kann eine VM bis zu sieben neue Schnittstellen (Standard + 7 Schnittstellen) mit verschiedenen VPCs verbinden. GKE-Netzwerke erweitern dieses Verhalten jetzt auf die Pods, die auf den Knoten ausgeführt werden. Vor der Einführung dieses Features durften alle NodePools in GKE-Clustern nur eine Schnittstelle haben und konnten daher nur einer einzelnen VPC zugeordnet werden. Mit dem Feature „Multi-Netzwerke auf Pods“ können Nutzer jetzt mehr als eine Schnittstelle für Knoten und Pods in einem GKE-Cluster aktivieren.
Umfang
In dieser Anleitung erstellen Sie eine umfassende GKE-Umgebung mit mehreren NICs, die die in Abbildung 1 dargestellten Anwendungsfälle veranschaulicht.
- Erstellen Sie „netdevice-l3-pod“ mit Busybox, um Folgendes zu tun:
- PING- und wget -S-Befehle für die Instanz „netdevice-apache“ im Netzwerk „netdevice-vpc“ über „eth2“ ausführen
- PING- und wget -S-Befehle für die l3-apache-Instanz in der l3-VPC über eth1 ausführen
- Erstellen Sie einen L3-Pod, der Busybox verwendet, um einen PING- und wget -S-Befehl an die L3-Apache-Instanz über eth1 zu senden.
In beiden Anwendungsfällen ist die eth0-Schnittstelle des Pods mit dem Standardnetzwerk verbunden.
Abbildung 1
Lerninhalte
- Subnetz vom Typ L3 erstellen
- Subnetz vom Typ „netdevice“ erstellen
- GKE-Knotenpool mit mehreren NICs einrichten
- Pod mit Netdevice- und L3-Funktionen erstellen
- Pod mit L3-Funktionen erstellen
- GKE-Objektnetzwerk erstellen und validieren
- Verbindung zu Remote-Apache-Servern mit PING, wget und Firewall-Logs validieren
Voraussetzungen
- Google Cloud-Projekt
2. Terminologie und Konzepte
Primäre VPC: Die primäre VPC ist eine vorkonfigurierte VPC, die mit einer Reihe von Standardeinstellungen und -ressourcen ausgestattet ist. Der GKE-Cluster wird in dieser VPC erstellt.
Subnetz: In Google Cloud ist ein Subnetz die Möglichkeit, ein CIDR-Routing (Classless Inter-Domain Routing) mit Netzmasken in einer VPC zu erstellen. Ein Subnetz hat einen einzelnen primären IP-Adressbereich, der den Knoten zugewiesen ist und mehrere sekundäre Bereiche haben kann, die zu Pods und Diensten gehören können.
Knotennetzwerk: Das Knotennetzwerk bezieht sich auf eine dedizierte Kombination aus VPC- und Subnetzpaar. Innerhalb dieses Knotennetzwerks werden den Knoten, die zum Knotenpool gehören, IP-Adressen aus dem primären IP-Adressbereich zugewiesen.
Sekundärer Bereich: Ein sekundärer Google Cloud-Bereich ist ein CIDR und eine Netzmaske, die zu einer Region in einer VPC gehören. GKE verwendet dies als Layer 3-Pod-Netzwerk. Eine VPC kann mehrere sekundäre Bereiche haben und ein Pod kann eine Verbindung zu mehreren Pod-Netzwerken herstellen.
Netzwerk (L3 oder Gerät): Ein Netzwerkobjekt, das als Verbindungspunkt für Pods dient. Im Tutorial sind die Netzwerke „l3-network“ und „netdevice-network“. Das Gerät kann entweder „netdevice“ oder „dpdk“ sein. Das Standardnetzwerk ist obligatorisch und wird bei der Clustererstellung auf Grundlage des Subnetzes des Standardknotenpools erstellt.
Layer 3-Netzwerke entsprechen einem sekundären Bereich in einem Subnetz und werden so dargestellt:
VPC -> Subnetzname -> Name des sekundären Bereichs
Ein Gerätenetzwerk entspricht einem Subnetz in einer VPC und wird so dargestellt:
VPC -> Subnetzname
Standard-Pod-Netzwerk: Google Cloud erstellt während der Clustererstellung ein Standard-Pod-Netzwerk. Das Standard-Pod-Netzwerk verwendet die primäre VPC als Knotennetzwerk. Das Standard-Pod-Netzwerk ist standardmäßig auf allen Clusterknoten und Pods verfügbar.
Pods mit mehreren Schnittstellen: Pods mit mehreren Schnittstellen in GKE können keine Verbindung zum selben Pod-Netzwerk herstellen, da jede Schnittstelle des Pods mit einem eindeutigen Netzwerk verbunden sein muss.
Projekt für das Codelab aktualisieren
In diesem Codelab werden $variables verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu erleichtern.
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectid=YOUR-PROJECT-NAME
echo $projectid
3. Primäre VPC einrichten
Primäre VPC erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create primary-vpc --project=$projectid --subnet-mode=custom
Knoten und sekundäre Subnetze erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks subnets create primary-node-subnet --project=$projectid --range=192.168.0.0/24 --network=primary-vpc --region=us-central1 --enable-private-ip-google-access --secondary-range=sec-range-primay-vpc=10.0.0.0/21
4. GKE-Cluster erstellen
Erstellen Sie den privaten GKE-Cluster und geben Sie die primären VPC-Subnetze an, um den Standardknotenpool mit den erforderlichen Flags „–enable-multi-networking“ und „–enable-dataplane-v2“ zu erstellen, um Knotenpools mit mehreren NICs zu unterstützen.
Erstellen Sie den GKE-Cluster in Cloud Shell:
gcloud container clusters create multinic-gke \
--zone "us-central1-a" \
--enable-dataplane-v2 \
--enable-ip-alias \
--enable-multi-networking \
--network "primary-vpc" --subnetwork "primary-node-subnet" \
--num-nodes=2 \
--max-pods-per-node=32 \
--cluster-secondary-range-name=sec-range-primay-vpc \
--no-enable-master-authorized-networks \
--release-channel "regular" \
--enable-private-nodes --master-ipv4-cidr "100.100.10.0/28" \
--enable-ip-alias
MultiNIC-GKE-Cluster validieren
Authentifizieren Sie sich in Cloud Shell beim Cluster:
gcloud container clusters get-credentials multinic-gke --zone us-central1-a --project $projectid
Prüfen Sie in Cloud Shell, ob zwei Knoten aus dem Standardpool generiert wurden:
kubectl get nodes
Beispiel:
user@$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-multinic-gke-default-pool-3d419e48-1k2p Ready <none> 2m4s v1.27.3-gke.100
gke-multinic-gke-default-pool-3d419e48-xckb Ready <none> 2m4s v1.27.3-gke.100
5. netdevice-vpc einrichten
netdevice-vpc-Netzwerk erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create netdevice-vpc --project=$projectid --subnet-mode=custom
netdevice-vpc-Subnetze erstellen
Erstellen Sie in Cloud Shell das Subnetz, das für das Netzwerk mit mehreren NICs verwendet wird:
gcloud compute networks subnets create netdevice-subnet --project=$projectid --range=192.168.10.0/24 --network=netdevice-vpc --region=us-central1 --enable-private-ip-google-access
Erstellen Sie in Cloud Shell ein Subnetz für die Instanz „netdevice-apache“:
gcloud compute networks subnets create netdevice-apache --project=$projectid --range=172.16.10.0/28 --network=netdevice-vpc --region=us-central1 --enable-private-ip-google-access
Cloud Router- und NAT-Konfiguration
Cloud NAT wird im Tutorial für die Installation von Softwarepaketen verwendet, da die VM-Instanz keine externe IP-Adresse hat.
Erstellen Sie den Cloud Router in Cloud Shell.
gcloud compute routers create netdevice-cr --network netdevice-vpc --region us-central1
Erstellen Sie das NAT-Gateway in Cloud Shell.
gcloud compute routers nats create cloud-nat-netdevice --router=netdevice-cr --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
Instanz „netdevice-apache“ erstellen
Im folgenden Abschnitt erstellen Sie die netdevice-apache-Instanz.
Erstellen Sie die Instanz in Cloud Shell:
gcloud compute instances create netdevice-apache \
--project=$projectid \
--machine-type=e2-micro \
--image-family debian-11 \
--no-address \
--image-project debian-cloud \
--zone us-central1-a \
--subnet=netdevice-apache \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo 'Welcome to the netdevice-apache instance !!' | tee /var/www/html/index.html
EOF"
6. l3-vpc einrichten
l3-vpc-Netzwerk erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create l3-vpc --project=$projectid --subnet-mode=custom
L3-VPC-Subnetze erstellen
Erstellen Sie in Cloud Shell ein Subnetz mit primärem und sekundärem Bereich. Der sekundäre Bereich(sec-range-l3-subnet) wird für das L3-Netzwerk mit mehreren NICs verwendet:
gcloud compute networks subnets create l3-subnet --project=$projectid --range=192.168.20.0/24 --network=l3-vpc --region=us-central1 --enable-private-ip-google-access --secondary-range=sec-range-l3-subnet=10.0.8.0/21
Erstellen Sie in Cloud Shell ein Subnetz für die l3-apache-Instanz:
gcloud compute networks subnets create l3-apache --project=$projectid --range=172.16.20.0/28 --network=l3-vpc --region=us-central1 --enable-private-ip-google-access
Cloud Router- und NAT-Konfiguration
Cloud NAT wird im Tutorial für die Installation von Softwarepaketen verwendet, da die VM-Instanz keine externe IP-Adresse hat.
Erstellen Sie den Cloud Router in Cloud Shell.
gcloud compute routers create l3-cr --network l3-vpc --region us-central1
Erstellen Sie das NAT-Gateway in Cloud Shell.
gcloud compute routers nats create cloud-nat-l3 --router=l3-cr --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
l3-apache-Instanz erstellen
Im folgenden Abschnitt erstellen Sie die l3-apache-Instanz.
Erstellen Sie die Instanz in Cloud Shell:
gcloud compute instances create l3-apache \
--project=$projectid \
--machine-type=e2-micro \
--image-family debian-11 \
--no-address \
--image-project debian-cloud \
--zone us-central1-a \
--subnet=l3-apache \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo 'Welcome to the l3-apache instance !!' | tee /var/www/html/index.html
EOF"
7. Knotenpool mit mehreren NICs erstellen
Im folgenden Abschnitt erstellen Sie einen Knotenpool mit mehreren NICs, der aus den folgenden Flags besteht:
–additional-node-network (erforderlich für Schnittstellen vom Gerätetyp)
Beispiel:
--additional-node-network network=netdevice-vpc,subnetwork=netdevice-subnet
–additional-node-network und –additional-pod-network ( erforderlich für Schnittstellen vom Typ L3)
Beispiel:
--additional-node-network network=l3-vpc,subnetwork=l3-subnet --additional-pod-network subnetwork=l3-subnet,pod-ipv4-range=sec-range-l3-subnet,max-pods-per-node=8
Maschinentyp: Berücksichtigen Sie beim Bereitstellen des Knotenpools die Abhängigkeit des Maschinentyps. Ein Maschinentyp wie „e2-standard-4“ mit 4 vCPUs kann beispielsweise insgesamt bis zu 4 VPCs unterstützen. Das Gerät „netdevice-l3-pod“ hat insgesamt drei Schnittstellen (default, netdevice und l3). Daher wird in der Anleitung der Maschinentyp „e2-standard-4“ verwendet.
Erstellen Sie in Cloud Shell den Knotenpool, der aus einem Typgerät und L3 besteht:
gcloud container --project "$projectid" node-pools create "multinic-node-pool" --cluster "multinic-gke" --zone "us-central1-a" --additional-node-network network=netdevice-vpc,subnetwork=netdevice-subnet --additional-node-network network=l3-vpc,subnetwork=l3-subnet --additional-pod-network subnetwork=l3-subnet,pod-ipv4-range=sec-range-l3-subnet,max-pods-per-node=8 --machine-type "e2-standard-4"
8. Multi-NIC-Knotenpool validieren
Prüfen Sie in Cloud Shell, ob drei Knoten aus dem Knotenpool „multinic-node-pool“ generiert wurden:
kubectl get nodes
Beispiel:
user@$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-multinic-gke-default-pool-3d419e48-1k2p Ready <none> 15m v1.27.3-gke.100
gke-multinic-gke-default-pool-3d419e48-xckb Ready <none> 15m v1.27.3-gke.100
gke-multinic-gke-multinic-node-pool-135699a1-0tfx Ready <none> 3m51s v1.27.3-gke.100
gke-multinic-gke-multinic-node-pool-135699a1-86gz Ready <none> 3m51s v1.27.3-gke.100
gke-multinic-gke-multinic-node-pool-135699a1-t66p Ready <none> 3m51s v1.27.3-gke.100
9. Netzwerk des Netzwerkgeräts erstellen
In den folgenden Schritten generieren Sie ein Kubernetes-Objekt vom Typ „Network“ und „GKENetworkParamSet“, um das „netdevice“-Netzwerk zu erstellen, das in späteren Schritten zum Zuordnen von Pods verwendet wird.
netdevice-network-Objekt erstellen
Erstellen Sie in Cloud Shell das Netzwerkobjekt YAML netdevice-network.yaml mit dem VI-Editor oder Nano. Beachten Sie, dass „Routen zu“ das Subnetz 172.16.10.0/28 (netdevice-apache) in der netdevice-VPC ist.
apiVersion: networking.gke.io/v1
kind: Network
metadata:
name: netdevice-network
spec:
type: "Device"
parametersRef:
group: networking.gke.io
kind: GKENetworkParamSet
name: "netdevice"
routes:
- to: "172.16.10.0/28"
Wenden Sie in Cloud Shell „netdevice-network.yaml“ an:
kubectl apply -f netdevice-network.yaml
Prüfen Sie in Cloud Shell, ob der Status des Netdevice-Netzwerks „Bereit“ ist.
kubectl describe networks netdevice-network
Beispiel:
user@$ kubectl describe networks netdevice-network
Name: netdevice-network
Namespace:
Labels: <none>
Annotations: networking.gke.io/in-use: false
API Version: networking.gke.io/v1
Kind: Network
Metadata:
Creation Timestamp: 2023-07-30T22:37:38Z
Generation: 1
Resource Version: 1578594
UID: 46d75374-9fcc-42be-baeb-48e074747052
Spec:
Parameters Ref:
Group: networking.gke.io
Kind: GKENetworkParamSet
Name: netdevice
Routes:
To: 172.16.10.0/28
Type: Device
Status:
Conditions:
Last Transition Time: 2023-07-30T22:37:38Z
Message: GKENetworkParamSet resource was deleted: netdevice
Reason: GNPDeleted
Status: False
Type: ParamsReady
Last Transition Time: 2023-07-30T22:37:38Z
Message: Resource referenced by params is not ready
Reason: ParamsNotReady
Status: False
Type: Ready
Events: <none>
GKENetworkParamSet erstellen
Erstellen Sie in Cloud Shell das Netzwerkobjekt YAML netdevice-network-parm.yaml mit dem VI-Editor oder Nano. Die Spezifikation entspricht dem Deployment des Subnetzes „netdevice-vpc“.
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
name: "netdevice"
spec:
vpc: "netdevice-vpc"
vpcSubnet: "netdevice-subnet"
deviceMode: "NetDevice"
Wenden Sie in Cloud Shell „netdevice-network-parm.yaml“ an.
kubectl apply -f netdevice-network-parm.yaml
Prüfen Sie in Cloud Shell den Status von „netdevice-network“: „Status Reason GNPParmsReady“ und „NetworkReady“:
kubectl describe networks netdevice-network
Beispiel:
user@$ kubectl describe networks netdevice-network
Name: netdevice-network
Namespace:
Labels: <none>
Annotations: networking.gke.io/in-use: false
API Version: networking.gke.io/v1
Kind: Network
Metadata:
Creation Timestamp: 2023-07-30T22:37:38Z
Generation: 1
Resource Version: 1579791
UID: 46d75374-9fcc-42be-baeb-48e074747052
Spec:
Parameters Ref:
Group: networking.gke.io
Kind: GKENetworkParamSet
Name: netdevice
Routes:
To: 172.16.10.0/28
Type: Device
Status:
Conditions:
Last Transition Time: 2023-07-30T22:39:44Z
Message:
Reason: GNPParamsReady
Status: True
Type: ParamsReady
Last Transition Time: 2023-07-30T22:39:44Z
Message:
Reason: NetworkReady
Status: True
Type: Ready
Events: <none>
Prüfen Sie in Cloud Shell den gkenetworkparamset-CIDR-Block 192.168.10.0/24, der in einem späteren Schritt für die Pod-Schnittstelle verwendet wird.
kubectl describe gkenetworkparamsets.networking.gke.io netdevice
Beispiel:
user@$ kubectl describe gkenetworkparamsets.networking.gke.io netdevice
Name: netdevice
Namespace:
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1
Kind: GKENetworkParamSet
Metadata:
Creation Timestamp: 2023-07-30T22:39:43Z
Finalizers:
networking.gke.io/gnp-controller
networking.gke.io/high-perf-finalizer
Generation: 1
Resource Version: 1579919
UID: 6fe36b0c-0091-4b6a-9d28-67596cbce845
Spec:
Device Mode: NetDevice
Vpc: netdevice-vpc
Vpc Subnet: netdevice-subnet
Status:
Conditions:
Last Transition Time: 2023-07-30T22:39:43Z
Message:
Reason: GNPReady
Status: True
Type: Ready
Network Name: netdevice-network
Pod CID Rs:
Cidr Blocks:
192.168.10.0/24
Events: <none>
10. L3-Netzwerke erstellen
In den folgenden Schritten generieren Sie ein Kubernetes-Objekt vom Typ „Network“ und „GKENetworkParamSet“, um das L3-Netzwerk zu erstellen, das in späteren Schritten zum Zuordnen von Pods verwendet wird.
L3-Netzwerkobjekt erstellen
Erstellen Sie in Cloud Shell das Netzwerkobjekt YAML l3-network.yaml mit dem VI-Editor oder Nano. Beachten Sie, dass „Routen zu“ das Subnetz 172.16.20.0/28 (l3-apache) in der l3-VPC ist.
apiVersion: networking.gke.io/v1
kind: Network
metadata:
name: l3-network
spec:
type: "L3"
parametersRef:
group: networking.gke.io
kind: GKENetworkParamSet
name: "l3-network"
routes:
- to: "172.16.20.0/28"
Wenden Sie in Cloud Shell „l3-network.yaml“ an:
kubectl apply -f l3-network.yaml
Prüfen Sie in Cloud Shell, ob der Status des L3-Netzwerks „Ready“ (Bereit) ist.
kubectl describe networks l3-network
Beispiel:
user@$ kubectl describe networks l3-network
Name: l3-network
Namespace:
Labels: <none>
Annotations: networking.gke.io/in-use: false
API Version: networking.gke.io/v1
Kind: Network
Metadata:
Creation Timestamp: 2023-07-30T22:43:54Z
Generation: 1
Resource Version: 1582307
UID: 426804be-35c9-4cc5-bd26-00b94be2ef9a
Spec:
Parameters Ref:
Group: networking.gke.io
Kind: GKENetworkParamSet
Name: l3-network
Routes:
to: 172.16.20.0/28
Type: L3
Status:
Conditions:
Last Transition Time: 2023-07-30T22:43:54Z
Message: GKENetworkParamSet resource was deleted: l3-network
Reason: GNPDeleted
Status: False
Type: ParamsReady
Last Transition Time: 2023-07-30T22:43:54Z
Message: Resource referenced by params is not ready
Reason: ParamsNotReady
Status: False
Type: Ready
Events: <none>
GKENetworkParamSet erstellen
Erstellen Sie in Cloud Shell das Netzwerkobjekt YAML l3-network-parm.yaml mit dem VI-Editor oder Nano. Die Spezifikation entspricht der Bereitstellung des L3-VPC-Subnetzes.
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
name: "l3-network"
spec:
vpc: "l3-vpc"
vpcSubnet: "l3-subnet"
podIPv4Ranges:
rangeNames:
- "sec-range-l3-subnet"
Wenden Sie in Cloud Shell „l3-network-parm.yaml“ an.
kubectl apply -f l3-network-parm.yaml
Prüfen Sie in Cloud Shell, ob der Grund für den Status des L3-Netzwerks „GNPParmsReady“ und „NetworkReady“ ist:
kubectl describe networks l3-network
Beispiel:
user@$ kubectl describe networks l3-network
Name: l3-network
Namespace:
Labels: <none>
Annotations: networking.gke.io/in-use: false
API Version: networking.gke.io/v1
Kind: Network
Metadata:
Creation Timestamp: 2023-07-30T22:43:54Z
Generation: 1
Resource Version: 1583647
UID: 426804be-35c9-4cc5-bd26-00b94be2ef9a
Spec:
Parameters Ref:
Group: networking.gke.io
Kind: GKENetworkParamSet
Name: l3-network
Routes:
To: 172.16.20.0/28
Type: L3
Status:
Conditions:
Last Transition Time: 2023-07-30T22:46:14Z
Message:
Reason: GNPParamsReady
Status: True
Type: ParamsReady
Last Transition Time: 2023-07-30T22:46:14Z
Message:
Reason: NetworkReady
Status: True
Type: Ready
Events: <none>
Prüfen Sie in Cloud Shell den für die Erstellung der Pod-Schnittstelle verwendeten gkenetworkparamset-L3-Netzwerk-CIDR 10.0.8.0/21.
kubectl describe gkenetworkparamsets.networking.gke.io l3-network
Beispiel:
user@$ kubectl describe gkenetworkparamsets.networking.gke.io l3-network
Name: l3-network
Namespace:
Labels: <none>
Annotations: <none>
API Version: networking.gke.io/v1
Kind: GKENetworkParamSet
Metadata:
Creation Timestamp: 2023-07-30T22:46:14Z
Finalizers:
networking.gke.io/gnp-controller
Generation: 1
Resource Version: 1583656
UID: 4c1f521b-0088-4005-b000-626ca5205326
Spec:
podIPv4Ranges:
Range Names:
sec-range-l3-subnet
Vpc: l3-vpc
Vpc Subnet: l3-subnet
Status:
Conditions:
Last Transition Time: 2023-07-30T22:46:14Z
Message:
Reason: GNPReady
Status: True
Type: Ready
Network Name: l3-network
Pod CID Rs:
Cidr Blocks:
10.0.8.0/21
Events: <none>
11. netdevice-l3-pod erstellen
Im folgenden Abschnitt erstellen Sie den netdevice-l3-Pod, auf dem Busybox ausgeführt wird. Busybox ist ein „Schweizer Taschenmesser“, das mehr als 300 gängige Befehle unterstützt. Der Pod ist so konfiguriert, dass er über eth1 mit der L3-VPC und über eth2 mit dem VPC-Netzwerkgerät kommuniziert.
Erstellen Sie in Cloud Shell den Busybox-Container mit dem Namen „netdevice-l3-pod.yaml“ mit dem VI-Editor oder Nano.
apiVersion: v1
kind: Pod
metadata:
name: netdevice-l3-pod
annotations:
networking.gke.io/default-interface: 'eth0'
networking.gke.io/interfaces: |
[
{"interfaceName":"eth0","network":"default"},
{"interfaceName":"eth1","network":"l3-network"},
{"interfaceName":"eth2","network":"netdevice-network"}
]
spec:
containers:
- name: netdevice-l3-pod
image: busybox
command: ["sleep", "10m"]
ports:
- containerPort: 80
restartPolicy: Always
Wenden Sie in Cloud Shell die Datei „netdevice-l3-pod.yaml“ an.
kubectl apply -f netdevice-l3-pod.yaml
Erstellung von „netdevice-l3-pod“ validieren
Prüfen Sie in Cloud Shell, ob „netdevice-l3-pod“ ausgeführt wird:
kubectl get pods netdevice-l3-pod
Beispiel:
user@$ kubectl get pods netdevice-l3-pod
NAME READY STATUS RESTARTS AGE
netdevice-l3-pod 1/1 Running 0 74s
Prüfen Sie in Cloud Shell die IP-Adressen, die den Pod-Schnittstellen zugewiesen sind.
kubectl get pods netdevice-l3-pod -o yaml
Im bereitgestellten Beispiel enthält das Feld networking.gke.io/pod-ips die IP-Adressen, die den Pod-Schnittstellen aus dem L3-Netzwerk und dem Netdevice-Netzwerk zugeordnet sind. Die Standard-IP-Adresse des Netzwerks 10.0.1.22 wird unter „podIPs“ aufgeführt:
user@$ kubectl get pods netdevice-l3-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"networking.gke.io/default-interface":"eth0","networking.gke.io/interfaces":"[\n{\"interfaceName\":\"eth0\",\"network\":\"default\"},\n{\"interfaceName\":\"eth1\",\"network\":\"l3-network\"},\n{\"interfaceName\":\"eth2\",\"network\":\"netdevice-network\"}\n]\n"},"name":"netdevice-l3-pod","namespace":"default"},"spec":{"containers":[{"command":["sleep","10m"],"image":"busybox","name":"netdevice-l3-pod","ports":[{"containerPort":80}]}],"restartPolicy":"Always"}}
networking.gke.io/default-interface: eth0
networking.gke.io/interfaces: |
[
{"interfaceName":"eth0","network":"default"},
{"interfaceName":"eth1","network":"l3-network"},
{"interfaceName":"eth2","network":"netdevice-network"}
]
networking.gke.io/pod-ips: '[{"networkName":"l3-network","ip":"10.0.8.4"},{"networkName":"netdevice-network","ip":"192.168.10.2"}]'
creationTimestamp: "2023-07-30T22:49:27Z"
name: netdevice-l3-pod
namespace: default
resourceVersion: "1585567"
uid: d9e43c75-e0d1-4f31-91b0-129bc53bbf64
spec:
containers:
- command:
- sleep
- 10m
image: busybox
imagePullPolicy: Always
name: netdevice-l3-pod
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
networking.gke.io.networks/l3-network.IP: "1"
networking.gke.io.networks/netdevice-network: "1"
networking.gke.io.networks/netdevice-network.IP: "1"
requests:
networking.gke.io.networks/l3-network.IP: "1"
networking.gke.io.networks/netdevice-network: "1"
networking.gke.io.networks/netdevice-network.IP: "1"
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-f2wpb
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: gke-multinic-gke-multinic-node-pool-135699a1-86gz
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoSchedule
key: networking.gke.io.networks/l3-network.IP
operator: Exists
- effect: NoSchedule
key: networking.gke.io.networks/netdevice-network
operator: Exists
- effect: NoSchedule
key: networking.gke.io.networks/netdevice-network.IP
operator: Exists
volumes:
- name: kube-api-access-f2wpb
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2023-07-30T22:49:28Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2023-07-30T22:49:33Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2023-07-30T22:49:33Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2023-07-30T22:49:28Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: containerd://dcd9ead2f69824ccc37c109a47b1f3f5eb7b3e60ce3865e317dd729685b66a5c
image: docker.io/library/busybox:latest
imageID: docker.io/library/busybox@sha256:3fbc632167424a6d997e74f52b878d7cc478225cffac6bc977eedfe51c7f4e79
lastState: {}
name: netdevice-l3-pod
ready: true
restartCount: 0
started: true
state:
running:
startedAt: "2023-07-30T22:49:32Z"
hostIP: 192.168.0.4
phase: Running
podIP: 10.0.1.22
podIPs:
- ip: 10.0.1.22
qosClass: BestEffort
startTime: "2023-07-30T22:49:28Z"
Netdevice-L3-Pod-Routen validieren
Prüfen Sie in Cloud Shell die Routen zu netdevice-vpc und l3-vpc von netdevice-l3-pod aus:
kubectl exec --stdin --tty netdevice-l3-pod -- /bin/sh
Instanz erstellen und Pod-Schnittstellen validieren:
ifconfig
In diesem Beispiel ist „eth0“ mit dem Standardnetzwerk, „eth1“ mit dem „l3-network“ und „eth2“ mit dem „netdevice-network“ verbunden.
/ # ifconfig
eth0 Link encap:Ethernet HWaddr 26:E3:1B:14:6E:0C
inet addr:10.0.1.22 Bcast:10.0.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:446 (446.0 B) TX bytes:558 (558.0 B)
eth1 Link encap:Ethernet HWaddr 92:78:4E:CB:F2:D4
inet addr:10.0.8.4 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:446 (446.0 B) TX bytes:516 (516.0 B)
eth2 Link encap:Ethernet HWaddr 42:01:C0:A8:0A:02
inet addr:192.168.10.2 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:50581 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26169 (25.5 KiB) TX bytes:2148170 (2.0 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Prüfen Sie vom netdevice-l3-Pod aus die Routen zum netdevice-VPC (172.16.10.0/28) und zum l3-VPC (172.16.20.0/28).
Instanz erstellen und Pod-Routen validieren:
ip route
Beispiel:
/ # ip route
default via 10.0.1.1 dev eth0 #primary-vpc
10.0.1.0/24 via 10.0.1.1 dev eth0 src 10.0.1.22
10.0.1.1 dev eth0 scope link src 10.0.1.22
10.0.8.0/21 via 10.0.8.1 dev eth1 #l3-vpc (sec-range-l3-subnet)
10.0.8.1 dev eth1 scope link
172.16.10.0/28 via 192.168.10.1 dev eth2 #netdevice-vpc (netdevice-apache subnet)
172.16.20.0/28 via 10.0.8.1 dev eth1 #l3-vpc (l3-apache subnet)
192.168.10.0/24 via 192.168.10.1 dev eth2 #pod interface subnet
192.168.10.1 dev eth2 scope link
Wenn Sie zur Cloud Shell zurückkehren möchten, beenden Sie den Pod über die Instanz.
exit
12. L3-Pod erstellen
Im folgenden Abschnitt erstellen Sie den L3-Pod, auf dem Busybox ausgeführt wird. Busybox ist ein „Schweizer Taschenmesser“, das mehr als 300 gängige Befehle unterstützt. Der Pod ist so konfiguriert, dass er nur über „eth1“ mit dem L3-VPC kommuniziert.
Erstellen Sie in Cloud Shell den Busybox-Container mit dem Namen „l3-pod.yaml“ mit dem VI-Editor oder Nano.
apiVersion: v1
kind: Pod
metadata:
name: l3-pod
annotations:
networking.gke.io/default-interface: 'eth0'
networking.gke.io/interfaces: |
[
{"interfaceName":"eth0","network":"default"},
{"interfaceName":"eth1","network":"l3-network"}
]
spec:
containers:
- name: l3-pod
image: busybox
command: ["sleep", "10m"]
ports:
- containerPort: 80
restartPolicy: Always
Wenden Sie in Cloud Shell die Datei „l3-pod.yaml“ an.
kubectl apply -f l3-pod.yaml
Erstellung des L3-Pods validieren
Prüfen Sie in Cloud Shell, ob „netdevice-l3-pod“ ausgeführt wird:
kubectl get pods l3-pod
Beispiel:
user@$ kubectl get pods l3-pod
NAME READY STATUS RESTARTS AGE
l3-pod 1/1 Running 0 52s
Prüfen Sie in Cloud Shell die IP-Adressen, die den Pod-Schnittstellen zugewiesen sind.
kubectl get pods l3-pod -o yaml
Im bereitgestellten Beispiel enthält das Feld networking.gke.io/pod-ips die IP-Adressen, die den Pod-Schnittstellen aus dem L3-Netzwerk zugeordnet sind. Die Standard-IP-Adresse des Netzwerks 10.0.2.12 wird unter „podIPs“ aufgeführt:
user@$ kubectl get pods l3-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"networking.gke.io/default-interface":"eth0","networking.gke.io/interfaces":"[\n{\"interfaceName\":\"eth0\",\"network\":\"default\"},\n{\"interfaceName\":\"eth1\",\"network\":\"l3-network\"}\n]\n"},"name":"l3-pod","namespace":"default"},"spec":{"containers":[{"command":["sleep","10m"],"image":"busybox","name":"l3-pod","ports":[{"containerPort":80}]}],"restartPolicy":"Always"}}
networking.gke.io/default-interface: eth0
networking.gke.io/interfaces: |
[
{"interfaceName":"eth0","network":"default"},
{"interfaceName":"eth1","network":"l3-network"}
]
networking.gke.io/pod-ips: '[{"networkName":"l3-network","ip":"10.0.8.22"}]'
creationTimestamp: "2023-07-30T23:22:29Z"
name: l3-pod
namespace: default
resourceVersion: "1604447"
uid: 79a86afd-2a50-433d-9d48-367acb82c1d0
spec:
containers:
- command:
- sleep
- 10m
image: busybox
imagePullPolicy: Always
name: l3-pod
ports:
- containerPort: 80
protocol: TCP
resources:
limits:
networking.gke.io.networks/l3-network.IP: "1"
requests:
networking.gke.io.networks/l3-network.IP: "1"
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-w9d24
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: gke-multinic-gke-multinic-node-pool-135699a1-t66p
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoSchedule
key: networking.gke.io.networks/l3-network.IP
operator: Exists
volumes:
- name: kube-api-access-w9d24
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2023-07-30T23:22:29Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2023-07-30T23:22:35Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2023-07-30T23:22:35Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2023-07-30T23:22:29Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: containerd://1d5fe2854bba0a0d955c157a58bcfd4e34cecf8837edfd7df2760134f869e966
image: docker.io/library/busybox:latest
imageID: docker.io/library/busybox@sha256:3fbc632167424a6d997e74f52b878d7cc478225cffac6bc977eedfe51c7f4e79
lastState: {}
name: l3-pod
ready: true
restartCount: 0
started: true
state:
running:
startedAt: "2023-07-30T23:22:35Z"
hostIP: 192.168.0.5
phase: Running
podIP: 10.0.2.12
podIPs:
- ip: 10.0.2.12
qosClass: BestEffort
startTime: "2023-07-30T23:22:29Z"
L3-Pod-Routen validieren
Prüfen Sie in Cloud Shell die Routen zu l3-vpc von netdevice-l3-pod:
kubectl exec --stdin --tty l3-pod -- /bin/sh
Instanz erstellen und Pod-Schnittstellen validieren:
ifconfig
Im Beispiel ist eth0 mit dem Standardnetzwerk und eth1 mit dem L3-Netzwerk verbunden.
/ # ifconfig
eth0 Link encap:Ethernet HWaddr 22:29:30:09:6B:58
inet addr:10.0.2.12 Bcast:10.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:446 (446.0 B) TX bytes:558 (558.0 B)
eth1 Link encap:Ethernet HWaddr 6E:6D:FC:C3:FF:AF
inet addr:10.0.8.22 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:446 (446.0 B) TX bytes:516 (516.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Prüfen Sie vom l3-pod aus die Routen zur l3-vpc (172.16.20.0/28).
Instanz erstellen und Pod-Routen validieren:
ip route
Beispiel:
/ # ip route
default via 10.0.2.1 dev eth0 #primary-vpc
10.0.2.0/24 via 10.0.2.1 dev eth0 src 10.0.2.12
10.0.2.1 dev eth0 scope link src 10.0.2.12
10.0.8.0/21 via 10.0.8.17 dev eth1 #l3-vpc (sec-range-l3-subnet)
10.0.8.17 dev eth1 scope link #pod interface subnet
172.16.20.0/28 via 10.0.8.17 dev eth1 #l3-vpc (l3-apache subnet)
Wenn Sie zur Cloud Shell zurückkehren möchten, beenden Sie den Pod über die Instanz.
exit
13. Firewall-Updates
Damit Verbindungen vom GKE-Multinic-Pool zum netdevice-vpc möglich sind, sind Ingress-Firewallregeln für die l3-vpc erforderlich. Sie erstellen Firewallregeln, in denen der Quellbereich als das Pod-Netzwerk-Subnetz angegeben wird, z.B. „netdevice-subnet“ oder „sec-range-l3-subnet“.
Beispiel: Der neu erstellte Container „l3-pod“, die eth2-Schnittstelle „10.0.8.22“ (aus dem sec-range-l3-Subnetz zugewiesen) ist die Quell-IP-Adresse, wenn eine Verbindung zur l3-apache-Instanz in der l3-VPC hergestellt wird.
netdevice-vpc: Allow from netdevice-subnet to netdevice-apache
Erstellen Sie in Cloud Shell die Firewallregel in der netdevice-vpc, die den Zugriff des netdevice-Subnetzes auf die netdevice-apache-Instanz ermöglicht.
gcloud compute --project=$projectid firewall-rules create allow-ingress-from-netdevice-network-to-all-vpc-instances --direction=INGRESS --priority=1000 --network=netdevice-vpc --action=ALLOW --rules=all --source-ranges=192.168.10.0/24 --enable-logging
l3-vpc: Allow from sec-range-l3-subnet to l3-apache
Erstellen Sie in Cloud Shell die Firewallregel in der L3-VPC, die den Zugriff von „sec-range-l3-subnet“ auf die L3-Apache-Instanz ermöglicht.
gcloud compute --project=$projectid firewall-rules create allow-ingress-from-l3-network-to-all-vpc-instances --direction=INGRESS --priority=1000 --network=l3-vpc --action=ALLOW --rules=all --source-ranges=10.0.8.0/21 --enable-logging
14. Pod-Verbindung validieren
Im folgenden Abschnitt prüfen Sie die Verbindung zu den Apache-Instanzen über den netdevice-l3-Pod und den l3-Pod. Dazu melden Sie sich in den Pods an und führen einen wget-Befehl mit der Option -S aus, um einen Download der Startseite der Apache-Server zu validieren. Da das Gerät „netdevice-l3-pod“ mit Schnittstellen aus den Netzwerken „netdevice-network“ und „l3-network“ konfiguriert ist, ist eine Verbindung zu den Apache-Servern in „netdevice-vpc“ und „l3-vpc“ möglich.
Wenn Sie dagegen „wget -S“ über den L3-Pod ausführen, ist keine Verbindung zum Apache-Server in „netdevice-vpc“ möglich, da der L3-Pod nur mit einer Schnittstelle aus dem L3-Netzwerk konfiguriert ist.
IP-Adresse des Apache-Servers abrufen
Rufen Sie in der Cloud Console die IP-Adresse der Apache-Server ab, indem Sie zu „Compute Engine“ → „VM-Instanzen“ navigieren.
netdevice-l3-pod to netdevice-apache connectivity test (Konnektivitätstest von netdevice-l3-pod zu netdevice-apache)
Melden Sie sich in Cloud Shell im Pod „netdevice-l3“ an:
kubectl exec --stdin --tty netdevice-l3-pod -- /bin/sh
Pingen Sie vom Container aus die netdevice-apache-Instanz anhand der IP-Adresse, die Sie im vorherigen Schritt erhalten haben.
ping <insert-your-ip> -c 4
Beispiel:
/ # ping 172.16.10.2 -c 4
PING 172.16.10.2 (172.16.10.2): 56 data bytes
64 bytes from 172.16.10.2: seq=0 ttl=64 time=1.952 ms
64 bytes from 172.16.10.2: seq=1 ttl=64 time=0.471 ms
64 bytes from 172.16.10.2: seq=2 ttl=64 time=0.446 ms
64 bytes from 172.16.10.2: seq=3 ttl=64 time=0.505 ms
--- 172.16.10.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.446/0.843/1.952 ms
/ #
Führen Sie in Cloud Shell ein „wget -S“ für die netdevice-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus. „200 OK“ gibt an, dass die Webseite erfolgreich heruntergeladen wurde.
wget -S <insert-your-ip>
Beispiel:
/ # wget -S 172.16.10.2
Connecting to 172.16.10.2 (172.16.10.2:80)
HTTP/1.1 200 OK
Date: Mon, 31 Jul 2023 03:12:58 GMT
Server: Apache/2.4.56 (Debian)
Last-Modified: Sat, 29 Jul 2023 00:32:44 GMT
ETag: "2c-6019555f54266"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
saving to 'index.html'
index.html 100% |********************************| 44 0:00:00 ETA
'index.html' saved
/ #
netdevice-l3-pod to l3-apache connectivity test
Führen Sie in Cloud Shell einen Ping an die l3-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus.
ping <insert-your-ip> -c 4
Beispiel:
/ # ping 172.16.20.3 -c 4
PING 172.16.20.3 (172.16.20.3): 56 data bytes
64 bytes from 172.16.20.3: seq=0 ttl=63 time=2.059 ms
64 bytes from 172.16.20.3: seq=1 ttl=63 time=0.533 ms
64 bytes from 172.16.20.3: seq=2 ttl=63 time=0.485 ms
64 bytes from 172.16.20.3: seq=3 ttl=63 time=0.462 ms
--- 172.16.20.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.462/0.884/2.059 ms
/ #
Löschen Sie in Cloud Shell die vorherige Datei „index.html“ und führen Sie „wget -S“ für die l3-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus. „200 OK“ weist auf einen erfolgreichen Download der Webseite hin.
rm index.html
wget -S <insert-your-ip>
Beispiel:
/ # rm index.html
/ # wget -S 172.16.20.3
Connecting to 172.16.20.3 (172.16.20.3:80)
HTTP/1.1 200 OK
Date: Mon, 31 Jul 2023 03:41:32 GMT
Server: Apache/2.4.56 (Debian)
Last-Modified: Mon, 31 Jul 2023 03:24:21 GMT
ETag: "25-601bff76f04b7"
Accept-Ranges: bytes
Content-Length: 37
Connection: close
Content-Type: text/html
saving to 'index.html'
index.html 100% |*******************************************************************************************************| 37 0:00:00 ETA
'index.html' saved
Wenn Sie zur Cloud Shell zurückkehren möchten, beenden Sie den Pod über die Instanz.
exit
Konnektivitätstest zwischen L3-Pod und Netdevice-Apache
Melden Sie sich in Cloud Shell bei l3-pod an:
kubectl exec --stdin --tty l3-pod -- /bin/sh
Pingen Sie vom Container aus die netdevice-apache-Instanz anhand der IP-Adresse, die Sie im vorherigen Schritt erhalten haben. Da l3-pod keine Schnittstelle hat, die mit netdevice-network verknüpft ist, schlägt der Ping fehl.
ping <insert-your-ip> -c 4
Beispiel:
/ # ping 172.16.10.2 -c 4
PING 172.16.10.2 (172.16.10.2): 56 data bytes
--- 172.16.10.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Optional:Führen Sie in Cloud Shell einen „wget -S“ für die netdevice-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus, die ein Zeitlimit überschreitet.
wget -S <insert-your-ip>
Beispiel:
/ # wget -S 172.16.10.2
Connecting to 172.16.10.2 (172.16.10.2:80)
wget: can't connect to remote host (172.16.10.2): Connection timed out
Konnektivitätstest von l3-pod zu l3-apache
Führen Sie in Cloud Shell einen Ping an die l3-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus.
ping <insert-your-ip> -c 4
Beispiel:
/ # ping 172.16.20.3 -c 4
PING 172.16.20.3 (172.16.20.3): 56 data bytes
64 bytes from 172.16.20.3: seq=0 ttl=63 time=1.824 ms
64 bytes from 172.16.20.3: seq=1 ttl=63 time=0.513 ms
64 bytes from 172.16.20.3: seq=2 ttl=63 time=0.482 ms
64 bytes from 172.16.20.3: seq=3 ttl=63 time=0.532 ms
--- 172.16.20.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.482/0.837/1.824 ms
/ #
Führen Sie in Cloud Shell ein „wget -S“ für die l3-apache-Instanz basierend auf der IP-Adresse aus dem vorherigen Schritt aus. „200 OK“ gibt an, dass die Webseite erfolgreich heruntergeladen wurde.
wget -S <insert-your-ip>
Beispiel:
/ # wget -S 172.16.20.3
Connecting to 172.16.20.3 (172.16.20.3:80)
HTTP/1.1 200 OK
Date: Mon, 31 Jul 2023 03:52:08 GMT
Server: Apache/2.4.56 (Debian)
Last-Modified: Mon, 31 Jul 2023 03:24:21 GMT
ETag: "25-601bff76f04b7"
Accept-Ranges: bytes
Content-Length: 37
Connection: close
Content-Type: text/html
saving to 'index.html'
index.html 100% |*******************************************************************************************************| 37 0:00:00 ETA
'index.html' saved
/ #
15. Firewalllogs
Mit Firewallregel-Logging können Sie die Auswirkungen Ihrer Firewallregeln überwachen, überprüfen und analysieren. Sie können beispielsweise feststellen, ob eine Firewallregel, die Traffic abweisen soll, wie vorgesehen funktioniert. Das Logging von Firewallregeln ist auch nützlich, wenn Sie ermitteln müssen, wie viele Verbindungen von einer bestimmten Firewallregel betroffen sind.
Im Tutorial haben Sie das Firewall-Logging beim Erstellen der Firewallregeln für eingehenden Traffic aktiviert. Sehen wir uns die Informationen an, die aus den Logs stammen.
Rufen Sie in der Cloud Console „Logging“ → „Log-Explorer“ auf.
Fügen Sie die Abfrage unten gemäß dem Screenshot ein und wählen Sie „Abfrage ausführen“ aus: jsonPayload.rule_details.reference:("network:l3-vpc/firewall:allow-ingress-from-l3-network-to-all-vpc-instances")
Eine genauere Betrachtung einer Erfassung liefert Sicherheitsexperten Informationen wie Quell- und Ziel-IP-Adresse, Port, Protokoll und Knotenpoolname.
Wenn Sie weitere Firewalllogs aufrufen möchten, gehen Sie zu „VPC-Netzwerk“ → „Firewall“ → „allow-ingress-from-netdevice-network-to-all-vpc-instances“ und wählen Sie dann „In Logs Explorer ansehen“ aus.
16. Bereinigen
Löschen Sie die Komponenten der Anleitung in Cloud Shell.
gcloud compute instances delete l3-apache netdevice-apache --zone=us-central1-a --quiet
gcloud compute routers delete l3-cr netdevice-cr --region=us-central1 --quiet
gcloud container clusters delete multinic-gke --zone=us-central1-a --quiet
gcloud compute firewall-rules delete allow-ingress-from-l3-network-to-all-vpc-instances allow-ingress-from-netdevice-network-to-all-vpc-instances --quiet
gcloud compute networks subnets delete l3-apache l3-subnet netdevice-apache netdevice-subnet primary-node-subnet --region=us-central1 --quiet
gcloud compute networks delete l3-vpc netdevice-vpc primary-vpc --quiet
17. Glückwunsch
Sie haben erfolgreich einen Knotenpool mit mehreren NICs konfiguriert und erstellt sowie Pods mit Busybox erstellt, um die Konnektivität vom Typ L3 und Gerätetyp zu Apache-Servern mit PING und wget zu prüfen.
Außerdem haben Sie gelernt, wie Sie Firewall-Logs verwenden, um Quell- und Zielpakete zwischen den Pod-Containern und Apache-Servern zu prüfen.
Cosmopup findet Tutorials toll!!
