1. Introducción
Desde hace mucho tiempo, GCP es compatible con varias interfaces a nivel de instancia de VM. Con varias interfaces, una VM puede conectar hasta 7 interfaces nuevas (predeterminada + 7 interfaces) a diferentes VPC. Las Herramientas de redes de GKE ahora extienden este comportamiento a los Pods que se ejecutan en los nodos. Antes de esta función, los clústeres de GKE permitían que todos los grupos de nodos tuvieran una sola interfaz y, por lo tanto, se asignaran a una sola VPC. Con la función de varias redes en Pods, un usuario ahora puede habilitar más de una sola interfaz en los nodos y para los Pods de un clúster de GKE.
Qué compilarás
En este instructivo, compilarás un entorno multinic integral de GKE que ilustre los casos de uso ilustrados en la Figura 1.
- Cree netdevice-l3-pod aprovechando merchantbox para hacer lo siguiente:
- Haz un PING y wget -S a la instancia netdevice-apache en netdevice-vpc sobre eth2
- Haz un PING y wget -S a la instancia l3-apache en l3-vpc sobre eth1
- Crear un l3-pod que aprovechecartebox para realizar un PING y wget -S a instancia l3-apache a través de eth1
En ambos casos de uso, la interfaz eth0 del Pod está conectada a la red predeterminada.
Figura 1
Qué aprenderás
- Cómo crear una subred de tipo l3
- Cómo crear una subred de tipo de netdevice
- Cómo establecer un grupo de nodos de GKE de varias NIC
- Cómo crear un Pod con capacidades netdevice y l3
- Cómo crear un Pod con capacidades l3
- Cómo crear y validar la red de objetos de GKE
- Cómo validar la conectividad a los servidores remotos de Apache con registros PING, wget y firewall
Requisitos
- Proyecto de Google Cloud
2. Terminología y conceptos
VPC principal: La VPC principal es una VPC preconfigurada que viene con un conjunto de parámetros de configuración y recursos predeterminados. El clúster de GKE se crea en esta VPC.
Subred: en Google Cloud, una subred es la forma de crear enrutamiento entre dominios sin clases (CIDR) con máscaras de red en una VPC. Una subred tiene un solo rango de direcciones IP principal que se asigna a los nodos y puede tener varios rangos secundarios que pueden pertenecer a los Pods y Services.
Red de nodos: La red de nodos se refiere a una combinación dedicada de un par de VPC y subred. Dentro de esta red de nodos, a los nodos que pertenecen al grupo se les asignan direcciones IP del rango de direcciones IP principal.
Rango secundario: Un rango secundario de Google Cloud es un CIDR y una máscara de red que pertenecen a una región en una VPC. GKE lo usa como una red de Pods de capa 3. Una VPC puede tener varios rangos secundarios, y un Pod puede conectarse a varias redes de Pods.
Red (L3 o dispositivo): Es un objeto de red que funciona como punto de conexión para los Pods. En el instructivo, las redes son l3-network y netdevice-network, en las que el dispositivo puede ser netdevice o dpdk. La red predeterminada es obligatoria y se crea cuando se crea el clúster según la subred default-nodepool.
Las redes de capa 3 corresponden a un rango secundario en una subred, representado de la siguiente manera:
VPC -> Nombre de la subred -> Nombre del rango secundario
Las redes de dispositivos corresponden a una subred en una VPC, representada de la siguiente manera:
VPC -> Nombre de la subred
Red de Pods predeterminada: Google Cloud crea una red de Pods predeterminada durante la creación del clúster. La red de Pods predeterminada usa la VPC principal como la red de nodos. De forma predeterminada, la red de Pods predeterminada está disponible en todos los nodos y Pods del clúster.
Pods con varias interfaces: Los Pods con varias interfaces en GKE no pueden conectarse a la misma red de Pods porque cada interfaz del Pod debe estar conectada a una red única.
Actualiza el proyecto para que sea compatible con el codelab
En este codelab, se usa $variables para facilitar la implementación de la configuración de gcloud en Cloud Shell.
Dentro de Cloud Shell, realiza lo siguiente:
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectid=YOUR-PROJECT-NAME
echo $projectid
3. Configuración de la VPC principal
Crea la VPC principal
Dentro de Cloud Shell, realiza lo siguiente:
gcloud compute networks create primary-vpc --project=$projectid --subnet-mode=custom
Crea el nodo y las subredes secundarias
Dentro de Cloud Shell, realiza lo siguiente:
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. Creación del clúster de GKE
Crea el clúster de GKE privado especificando las subredes deprimary-vpc para crear el grupo de nodos predeterminado con las marcas necesarias –enable-multi-networking y –enable-dataplane-v2 para admitir grupos de nodos de varias NIC.
En Cloud Shell, crea el clúster de GKE:
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
Valida el clúster de multinic-gke
Dentro de Cloud Shell, autentica con el clúster:
gcloud container clusters get-credentials multinic-gke --zone us-central1-a --project $projectid
En Cloud Shell, verifica que se generen dos nodos a partir del default-pool:
kubectl get nodes
Ejemplo:
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. Configuración de netdevice-vpc
Crea la red netdevice-vpc
Dentro de Cloud Shell, realiza lo siguiente:
gcloud compute networks create netdevice-vpc --project=$projectid --subnet-mode=custom
Crea las subredes netdevice-vpc
En Cloud Shell, crea la subred que se usa para netdevice-network de multinic:
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
En Cloud Shell, crea una subred para la instancia 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
Configuración de Cloud Router y NAT
En el instructivo, se usa Cloud NAT para instalar paquetes de software, ya que la instancia de VM no tiene una dirección IP externa.
En Cloud Shell, crea el Cloud Router.
gcloud compute routers create netdevice-cr --network netdevice-vpc --region us-central1
En Cloud Shell, crea la puerta de enlace NAT.
gcloud compute routers nats create cloud-nat-netdevice --router=netdevice-cr --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
Crea la instancia netdevice-apache
En la siguiente sección, crearás la instancia netdevice-apache.
En Cloud Shell, crea la instancia:
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. Configuración de l3-vpc
Crea la red l3-vpc
Dentro de Cloud Shell, realiza lo siguiente:
gcloud compute networks create l3-vpc --project=$projectid --subnet-mode=custom
Crea las subredes l3-vpc
En Cloud Shell, crea una subred de rango principal y una secundaria. El rango secundario(sec-range-l3-subnet) se usa para la red l3-multinic:
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
En Cloud Shell, crea una subred para la instancia l3-apache:
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
Configuración de Cloud Router y NAT
En el instructivo, se usa Cloud NAT para instalar paquetes de software, ya que la instancia de VM no tiene una dirección IP externa.
En Cloud Shell, crea el Cloud Router.
gcloud compute routers create l3-cr --network l3-vpc --region us-central1
En Cloud Shell, crea la puerta de enlace NAT.
gcloud compute routers nats create cloud-nat-l3 --router=l3-cr --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
Crea la instancia l3-apache
En la siguiente sección, crearás la instancia l3-apache.
En Cloud Shell, crea la instancia:
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. Crea el grupo de nodos de varias NIC
En la siguiente sección, crearás un grupo de nodos de varias NIC que consta de las siguientes marcas:
–additional-node-network (obligatoria para las interfaces de tipo de dispositivo)
Ejemplo:
--additional-node-network network=netdevice-vpc,subnetwork=netdevice-subnet
–additional-node-network y –additional-pod-network ( obligatoria para las interfaces de tipo L3)
Ejemplo:
--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
Tipo de máquina: cuando implementes el grupo de nodos, considera la dependencia del tipo de máquina. Por ejemplo, un tipo de máquina como “e2-standard-4” con 4 CPU virtuales puede admitir hasta 4 VPC en total. Por ejemplo, netdevice-l3-pod tendrá un total de 3 interfaces (default, netdevice y l3); por lo tanto, el tipo de máquina que se usa en el instructivo es e2-standard-4.
En Cloud Shell, crea el grupo de nodos que consta de un dispositivo de tipo y una capa 3:
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. Valida el grupo de nodos múltiples
En Cloud Shell, verifica que se generen tres nodos a partir del grupo de nodos multinic:
kubectl get nodes
Ejemplo:
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. Crea el comando netdevice-network
En los siguientes pasos, generarás un objeto de Kubernetes Network y GKENetworkParamSet para crear la red netdevice-network que se usará para asociar los Pods en pasos posteriores.
Crea el objeto netdevice-network
En Cloud Shell, crea el objeto de red YAML netdevice-network.yaml con el editor VI o nano. Ten en cuenta las "rutas a" es la subred 172.16.10.0/28 (netdevice-apache) en netdevice-vpc.
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"
En Cloud Shell, aplica netdevice-network.yaml:
kubectl apply -f netdevice-network.yaml
En Cloud Shell, valida que el tipo de estado netdevice-network esté Listo.
kubectl describe networks netdevice-network
Ejemplo:
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>
Crea el GKENetworkParamSet
En Cloud Shell, crea el objeto de red YAML netdevice-network-parm.yaml con el editor VI o nano. La especificación se asigna a la implementación de la subred netdevice-vpc.
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
name: "netdevice"
spec:
vpc: "netdevice-vpc"
vpcSubnet: "netdevice-subnet"
deviceMode: "NetDevice"
En Cloud Shell, aplica netdevice-network-parm.yaml.
kubectl apply -f netdevice-network-parm.yaml
En Cloud Shell, valida el motivo del estado de netdevice-network GNPParmsReady y NetworkReady:
kubectl describe networks netdevice-network
Ejemplo:
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>
En Cloud Shell, valida el bloque CIDR 192.168.10.0/24 de gkenetworkparamset que se usa para la interfaz de Pods en un paso posterior.
kubectl describe gkenetworkparamsets.networking.gke.io netdevice
Ejemplo:
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. Crea las redes l3
En los siguientes pasos, generarás un objeto de Kubernetes Network y GKENetworkParamSet para crear la red l3 que se usará para asociar los Pods en pasos posteriores.
Crea el objeto de red l3
En Cloud Shell, crea el objeto de red YAML l3-network.yaml con el editor VI o nano. Ten en cuenta las "rutas a" es la subred 172.16.20.0/28 (l3-apache) en l3-vpc.
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"
En Cloud Shell, aplica l3-network.yaml:
kubectl apply -f l3-network.yaml
En Cloud Shell, valida que el tipo de estado de la red l3 sea Listo.
kubectl describe networks l3-network
Ejemplo:
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>
Crea el GKENetworkParamSet
En Cloud Shell, crea el objeto de red YAML l3-network-parm.yaml con el editor VI o nano. Ten en cuenta que las especificaciones se asignan a la implementación de la subred l3-vpc.
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
name: "l3-network"
spec:
vpc: "l3-vpc"
vpcSubnet: "l3-subnet"
podIPv4Ranges:
rangeNames:
- "sec-range-l3-subnet"
En Cloud Shell, aplica l3-network-parm.yaml.
kubectl apply -f l3-network-parm.yaml
En Cloud Shell, valida que el motivo del estado de la red l3 sea GNPParmsReady y NetworkReady:
kubectl describe networks l3-network
Ejemplo:
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>
En Cloud Shell, valida el CIDR 10.0.8.0/21 de gkenetworkparamset l3-network que se usó para crear la interfaz del Pod.
kubectl describe gkenetworkparamsets.networking.gke.io l3-network
Ejemplo:
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. Crea el netdevice-l3-pod
En la siguiente sección, crearás el comando netdevice-l3-pod ejecutándose ocupadobox, conocido como "navaja suiza". que admite más de 300 comandos comunes. El Pod está configurado para comunicarse con l3-vpc mediante eth1, y netdevice-vpc con eth2.
En Cloud Shell, crea el contenedor de la caja, que está ocupado, llamado netdevice-l3-pod.yaml, con el editor VI o 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
En Cloud Shell, aplica netdevice-l3-pod.yaml
kubectl apply -f netdevice-l3-pod.yaml
Valida la creación de netdevice-l3-pod
En Cloud Shell, verifica que se esté ejecutando netdevice-l3-pod:
kubectl get pods netdevice-l3-pod
Ejemplo:
user@$ kubectl get pods netdevice-l3-pod
NAME READY STATUS RESTARTS AGE
netdevice-l3-pod 1/1 Running 0 74s
Dentro de Cloud Shell, valida las direcciones IP asignadas a las interfaces del Pod.
kubectl get pods netdevice-l3-pod -o yaml
En el ejemplo proporcionado, el campo networking.gke.io/pod-ips contiene las direcciones IP asociadas a las interfaces del Pod de l3-network y netdevice-network. La dirección IP de la red predeterminada, 10.0.1.22, se detalla en podIP:
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"
Valida las rutas netdevice-l3-pod
En Cloud Shell, valida las rutas a netdevice-vpc y l3-vpc desde netdevice-l3-pod:
kubectl exec --stdin --tty netdevice-l3-pod -- /bin/sh
Desde la instancia, valida las interfaces del Pod:
ifconfig
En el ejemplo, eth0 está conectado a la red predeterminada, eth1 está conectado a l3-network y eth2 está conectado a netdevice-network.
/ # 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)
En netdevice-l3-pod, valida las rutas a netdevice-vpc (172.16.10.0/28) y l3-vpc (172.16.20.0/28).
Desde la instancia, valida las rutas del Pod:
ip route
Ejemplo:
/ # 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
Para regresar a Cloud Shell, sal del Pod de la instancia.
exit
12. Cree el l3-pod
En la siguiente sección, crearás el l3-pod activo ocupado que se conoce como “navaja Suiza”. que admite más de 300 comandos comunes. El Pod está configurado para comunicarse con l3-vpc usando solo eth1.
En Cloud Shell, crea el contenedor de la caja, que está ocupado, llamado l3-pod.yaml, con el editor VI o 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
En Cloud Shell, aplica l3-pod.yaml.
kubectl apply -f l3-pod.yaml
Valida la creación de l3-pod
En Cloud Shell, verifica que se esté ejecutando netdevice-l3-pod:
kubectl get pods l3-pod
Ejemplo:
user@$ kubectl get pods l3-pod
NAME READY STATUS RESTARTS AGE
l3-pod 1/1 Running 0 52s
Dentro de Cloud Shell, valida las direcciones IP asignadas a las interfaces del Pod.
kubectl get pods l3-pod -o yaml
En el ejemplo proporcionado, el campo networking.gke.io/pod-ips contiene las direcciones IP asociadas a las interfaces del pod de l3-network. La dirección IP de la red predeterminada, 10.0.2.12, se detalla en podIP:
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"
Valida las rutas l3-pod
En Cloud Shell, valida las rutas a l3-vpc desde netdevice-l3-pod:
kubectl exec --stdin --tty l3-pod -- /bin/sh
Desde la instancia, valida las interfaces del Pod:
ifconfig
En el ejemplo, eth0 está conectado a la red predeterminada, eth1 está conectado a l3-network.
/ # 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)
En l3-pod, valida las rutas a l3-vpc (172.16.20.0/28).
Desde la instancia, valida las rutas del Pod:
ip route
Ejemplo:
/ # 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)
Para regresar a Cloud Shell, sal del Pod de la instancia.
exit
13. Actualizaciones de firewall
Para permitir la conectividad del grupo multicnic de GKE a las reglas de firewall de entrada netdevice-vpc y l3-vpc de firewall de entrada. Crearás reglas de firewall que especifican el rango de origen como la subred de la red del Pod, p.ej., netdevice-subnet y sec-range-l3-subnet.
Por ejemplo, el contenedor recién creado, l3-pod, interfaz 10.0.8.22 eth2 (asignado desde sec-range-l3-subnet) es la dirección IP de origen cuando se conecta a la instancia l3-apache en l3-vpc.
netdevice-vpc: Permitir de netdevice-subnet a netdevice-apache
En Cloud Shell, crea la regla de firewall en netdevice-vpc que permite el acceso de netdevice-subnet a la instancia netdevice-apache.
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: Permitir de sec-range-l3-subnet a l3-apache
En Cloud Shell, crea la regla de firewall en l3-vpc que permite el acceso de sec-range-l3-subnet a la instancia l3-apache.
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. Valida la conectividad del Pod
En la siguiente sección, verificarás la conectividad a las instancias de Apache desde netdevice-l3-pod y l3-pod. Para ello, accederás a los Pods y ejecutarás wget -S, que valida la descarga de la página principal de los servidores apache. Como netdevice-l3-pod está configurado con interfaces de netdevice-network y l3-network, es posible tener conectividad con los servidores Apache en netdevice-vpc y l3-vpc.
Por el contrario, cuando se realiza una operación wget -S desde el l3-pod, la conectividad con el servidor Apache en netdevice-vpc no es posible, ya que el l3-pod solo se configura con una interfaz de l3-network.
Obtén la dirección IP del servidor Apache
En la consola de Cloud, navega a Compute Engine → Instancias de VM para obtener la dirección IP de los servidores Apache
Prueba de conectividad de netdevice-l3-pod a netdevice-apache
En Cloud Shell, inicia sesión en netdevice-l3-pod:
kubectl exec --stdin --tty netdevice-l3-pod -- /bin/sh
Desde el contenedor, haz ping a la instancia netdevice-apache en función de la dirección IP obtenida en el paso anterior.
ping <insert-your-ip> -c 4
Ejemplo:
/ # 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
/ #
En Cloud Shell, realiza una instancia wget -S a netdevice-apache según la dirección IP obtenida en el paso anterior. 200 OK indica que la página web se descargó correctamente.
wget -S <insert-your-ip>
Ejemplo:
/ # 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
/ #
Prueba de conectividad de netdevice-l3-pod a l3-apache
En Cloud Shell, haz ping a la instancia l3-apache en función de la dirección IP obtenida en el paso anterior.
ping <insert-your-ip> -c 4
Ejemplo:
/ # 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
/ #
En Cloud Shell, borra el archivo index.html anterior y realiza una instancia de wget -S a l3-apache según la dirección IP obtenida en el paso anterior. 200 OK indica que la página web se descargó correctamente.
rm index.html
wget -S <insert-your-ip>
Ejemplo:
/ # 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
Para regresar a Cloud Shell, sal del Pod de la instancia.
exit
Prueba de conectividad de l3-pod a netdevice-apache
Dentro de Cloud Shell, inicia sesión en l3-pod:
kubectl exec --stdin --tty l3-pod -- /bin/sh
Desde el contenedor, haz ping a la instancia netdevice-apache en función de la dirección IP obtenida en el paso anterior. Dado que l3-pod no tiene una interfaz asociada con netdevice-network, el ping fallará.
ping <insert-your-ip> -c 4
Ejemplo:
/ # 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
Opcional: Dentro de Cloud Shell, realiza una instancia wget -S a netdevice-apache según la dirección IP obtenida en el paso anterior que agotará el tiempo de espera.
wget -S <insert-your-ip>
Ejemplo:
/ # 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
Prueba de conectividad de l3-pod a l3-apache
En Cloud Shell, haz ping a la instancia l3-apache en función de la dirección IP obtenida en el paso anterior.
ping <insert-your-ip> -c 4
Ejemplo:
/ # 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
/ #
En Cloud Shell, realiza una instancia wget -S a l3-apache según la dirección IP obtenida en el paso anterior. 200 OK indica que la página web se descargó correctamente.
wget -S <insert-your-ip>
Ejemplo:
/ # 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. Registros de firewall
Los registros de reglas de firewall te permiten inspeccionar, verificar y analizar los efectos de tus reglas de firewall. Por ejemplo, puedes determinar si una regla de firewall diseñada para denegar tráfico está funcionando según lo previsto. Este registro también es útil si necesitas determinar cuántas conexiones se ven afectadas por una regla de firewall determinada.
En el instructivo, habilitaste el registro de firewall cuando creaste las reglas de firewall de entrada. Observemos la información obtenida de los registros.
En la consola de Cloud, navega a Logging → Explorador de registros
Inserta la siguiente consulta según la captura de pantalla y selecciona Run query jsonPayload.rule_details.reference:("network:l3-vpc/firewall:allow-ingress-from-l3-network-to-all-vpc-instances")
Cuando se observa una captura más detallada, se proporcionan elementos de información para los administradores de seguridad. que van desde la dirección IP de origen y de destino, el puerto, el protocolo y el nombre del grupo de nodos.
Para explorar más registros de firewall, ve a Red de VPC → Firewall → allow-ingress-from-netdevice-network-to-all-vpc-instances y, luego, selecciona Ver en el Explorador de registros.
16. Limpia
En Cloud Shell, borra los componentes del instructivo.
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. Felicitaciones
Felicitaciones. Configuraste y validaste correctamente la creación de un grupo de nodos de varias NIC y la creación de Pods que se ejecutan en purchasebox para validar la conectividad de L3 y de tipo de dispositivo a los servidores Apache con PING y wget.
También aprendiste a aprovechar los registros de firewall para inspeccionar los paquetes de origen y destino entre los contenedores de Pods y los servidores Apache.
Cosmopup cree que los instructivos son increíbles.
Lecturas adicionales y Videos
- Cómo crear un clúster de GKE (demostración)
- GKE: Conceptos de las herramientas de redes
- Contenedores y Blogs de Kubernetes