Espacios de nombres y aislamiento de Contrail
En el capítulo 3, se lee namespace o NS en Kubernetes y, al principio de este capítulo, hemos mencionado las asignaciones de objetos entre Kubernetes y Contrail. En esta sección’verá cómo funciona namespace en entornos de contrail y cómo contrail amplía aún más el conjunto de características.
Una analogía que se obtiene al introducir el namespace el concepto es OpenStack project, o bien tenant. Y eso es exactamente de lo Contrail lo mira. Siempre que una nueva namespace objeto se crea, contrail-kube-manager (KM) recibirá un aviso sobre el evento de creación de objetos y creará el proyecto correspondiente en Contrail.
Para diferenciar varios clústeres de Kubernetes en Contrail, se agregará un nombre de clúster Kubernetes al espacio de nombres Kubernetes o al nombre del proyecto. El nombre de clúster predeterminado Kubernetes es k8s. Por lo tanto, si crea un espacio de nombres Kubernetes ns-user-1, en una k8s-ns-user-1 el proyecto se creará en Contrail tal y como puede ver en la Figure 1, donde se muestra el contrail interfaz gráfica de usuario (GUI).
El Kubernetes cluster name se puede configurar, pero solo durante el proceso de implementación. Si no’lo configura k8s será el valor predeterminado. Una vez creado el clúster, no se puede cambiar el nombre. Para ver el cluster
name, debe ir a la contrail-kube-manager (KM) y compruebe su archivo de configuración.
Para ubicar el contenedor del Docker de KM:
$ docker ps -a | grep kubemanager 2260c7845964 ...snipped... ago Up 2 minutes kubemanager_kubemanager_1
Para iniciar una sesión en el contenedor de KM:
$ docker exec -it kubemanager_kubemanager_1 bash
Para encontrar el cluster_name ,
$ grep cluster /etc/contrail/contrail-kubernetes.conf
cluster_name=k8s #<---
cluster_project={}
cluster_network={}
El resto de este libro se referirá a todos estos términos namespace, NS, tenant, y project cambia.
Espacios de nombres no aislados
Debe tener en cuenta que un requisito de red básica de Kubernetes es para una red – plana o sin TDR cualquier conjunto Pod puede comunicarse con cualquier conjunto Pod – en cualquier espacio de nombres y cualquier proveedor CNI debe asegurarse de que. Por lo tanto, en Kubernetes, de forma predeterminada, todos los espacios de nombres no se aíslan:
El término aislado y no aislado se encuentra únicamente en el contexto de las redes (Contrail).
k8s-default-pod-network and k8s-default-service-network
Para proporcionar funciones de red a todos los espacios de nombres no aislados, debe haber una tabla de enrutamiento y reenvío virtual o una instancia de enrutamiento común. En el entorno Contrail Kubernetes, dos redes virtuales predeterminadas se preconfiguran’ en K8S espacio de nombres predeterminado para pod y para Service, respectivamente. Lo que corresponde, hay dos tablas VRF, cada una con el mismo nombre que su red virtual correspondiente.
El nombre de las dos tablas de redes virtuales/VRF tiene este formato:
<k8s-cluster-name>-<namespace name>-[pod|service]-network
Por lo tanto, para el espacio de nombres predeterminado con un nombre de clúster predeterminado, k8s, los dos nombres de las redes virtuales/VRF son:
k8s-default-pod-network: la red virtual Pod/tabla VRF, con la subred predeterminada10.32.0.0/12k8s-default-service-network: la tabla/VRF de red virtual de servicio, con una subred predeterminada10.96.0.0/12
La subred predeterminada para Pod o servicio es configurable.
Es importante saber que estas dos redes virtuales predeterminadas se comparten entre todos los espacios de nombres no aislados. Esto significa que estarán disponibles para cualquier nuevo espacio de nombres no aislado que cree, implícitamente. ’Por qué los pods de todos los espacios de nombres no aislados, incluidos los espacios de nombres predeterminados, se pueden comunicar entre sí.
Por otro lado, cualquier red virtual que cree se aislará con otras redes virtuales, independientemente del mismo espacio de nombres o de otros distintos. La comunicación entre Juniper en dos redes virtuales distintas requiere una política de red Contrail.
Más adelante, cuando lea acerca del servicio Kubernetes, es posible que se pregunte por qué los paquetes destinados a la red virtual de servicio/la tabla VRF pueden llegar al pod de back-end en la red virtual Pod/la tabla VRF. Una vez más, la buena noticia es a causa de Contrail Directiva de red. De forma predeterminada, la Directiva de red Contrail está habilitada entre las redes de servicio y Pod, lo que permite que los paquetes que llegan a la red virtual de servicio o la tabla VRF alcancen la Pod, y viceversa.
Espacios de nombres aislados
Por el contrario, los espacios de nombres aislados tienen su propia red Pod-Network y de servicio predeterminada, y por lo tanto, se crean también dos nuevas tablas VRF para cada espacio de nombres aislado. Las mismas subredes fijas 10.32.0.0/12 y 10.96.0.0/12 son compartidas por las redes Pod y de servicio en los espacios de nombres aislados. Sin embargo, dado que las redes tienen una tabla VRF diferente, se aísla de forma predeterminada con otro espacio de nombres. Los pods que se inician en espacios de nombres aislados solo pueden comunicarse con el servicio y los pods en el mismo espacio de nombres. Las configuraciones adicionales, por ejemplo, la política, son necesarias para que la caja Pod pueda conectar con la red fuera del espacio de nombres actual.
Para ilustrar este concepto,’deje que un ejemplo lo utilice. Supongamos que tiene tres espacios de nombres: el default espacio de nombres y dos espacios de nombres de usuario: ns-non-isolated y ns-isolated. En cada espacio de nombres puede crear una red virtual de usuario: vn-left-1. Finalizará a las siguientes redes virtuales o VRF en Contrail:
default-domain:k8s-default:k8s-default-pod-network
default-domain:k8s-default:k8s-default-service-network
default-domain:k8s-default:k8s-vn-left-1-pod-network
default-domain:k8s-ns-non-isolated:k8s-vn-left-1-pod-network
default-domain:k8s-ns-isolated:k8s-ns-isolated-pod-network
default-domain:k8s-ns-isolated:k8s-ns-isolated-service-network
default-domain:k8s-ns-isolated:k8s-vn-left-1-pod-network
Los nombres anteriores se enumeran en el formato FQDN. En Contrail, dominio es el objeto de nivel superior, seguido por proyecto/inquilino y, a continuación, por redes virtuales.
La Figure 2 , de expertos, lo ilustra todo esto.
A continuación se muestra el archivo YAML para crear un espacio de nombres aislado:
$ cat ns-isolated.yaml apiVersion: v1 kind: Namespace metadata: annotations: "opencontrail.org/isolation" : "true" name: ns-isolated
Y para crear el NS:
kubectl create -f ns-isolated.yaml $ kubectl get ns NAME STATUS AGE contrail Active 8d default Active 8d ns-isolated Active 1d #<--- kube-public Active 8d kube- system Active 8d
Las anotaciones en metadatos son una forma adicional de comparar un espacio de nombres K8S estándar (no aislado). El valor de True indica que se trata de un espacio de nombres aislado:
annotations: "opencontrail.org/isolation" : "true"
Puede ver que esta parte de la definición es Juniper’extensión. El servicio contrail-kube-manager (KM) Lee el espacio de nombres metadata desde Kube-apiserver, analiza la información definida en la annotations objeto y observa que el isolation Flag se establece en true. A continuación, crea el inquilino con la instancia de enrutamiento correspondiente (una para pod y una para el servicio) en lugar de usar las instancias de enrutamiento de espacio de nombres predeterminadas para el espacio de nombres aislado. Fundamentalmente, la forma de implementar el aislamiento.
En las siguientes secciones se comprobará que el aislamiento de enrutamiento funciona.
Comunicación con los pods a través de NS
Crear un espacio de nombres no aislado y un espacio de nombres aislado:
$ cat ns-non-isolated.yaml apiVersion: v1 kind: Namespace metadata: name: ns-non-isolated $ cat ns-isolated.yaml apiVersion: v1 kind: Namespace metadata: annotations: "opencontrail.org/isolation": "true" name: ns-isolated $ kubectl apply -f ns-non-isolated.yaml namespace/ns-non-isolated created $ kubectl apply -f ns-isolated.yaml namespace/ns-isolated created $ kubectl get ns | grep isolate ns-isolated Active 79s ns-non-isolated Active 73s
En ambos espacios de nombres y en el espacio de nombres predeterminado, cree una implementación para iniciar un conjunto de servidores WebServer:
#deploy-webserver-do.yaml
apiVersion: apps/v1
- {key: app, operator: In, values: [webserver]}
$ kubectl apply -f deploy-webserver-do.yaml -n default
deployment.extensions/webserver created
$ kubectl apply -f deploy-webserver-do.yaml -n ns-non-isolated
deployment.extensions/webserver created
$ kubectl apply -f deploy-webserver-do.yaml -n ns-isolated
deployment.extensions/webserver created
$ kubectl get pod -o wide -n default
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-tjfn6 1/1 Running ... 10.47.255.242 cent333 ...
$ kubectl get pod -o wide -n ns-non-isolated...
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-nrxq6 1/1 Running ... 10.47.255.248 cent222 ...
$ kubectl get pod -o wide -n ns-isolated
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-6l7j2 1/1 Running ... 10.47.255.239 cent222 ...
Ping entre todos los pods en tres espacios de nombres:
#default ns to non-isolated new ns: succeed $ kubectl -n default exec -it webserver-85fc7dd848-tjfn6 -- ping 10.47.255.248 PING 10.47.255.248 (10.47.255.248): 56 data bytes 64 bytes from 10.47.255.248: seq=0 ttl=63 time=1.600 ms ^C --- 10.47.255.248 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.600/1.600/1.600 ms #default ns to isolated new ns: fail $ kubectl -n default exec -it webserver-85fc7dd848-tjfn6 -- ping 10.47.255.239 PING 10.47.255.239 (10.47.255.239): 56 data bytes ^C --- 10.47.255.239 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
El resultado de la prueba muestra que la comunicación es bidireccional entre dos espacios de nombres no aislados (espacio de nombres ns-non-isolated y default, en este caso) funciona, pero el tráfico procedente de un espacio de nombres no aislado (default NS) hacia un espacio de nombres aislado no pasa a través de él. ¿Qué sucede con el tráfico dentro del mismo espacio de nombres aislado?
Con la potencia de deployment puede comprobarlo rápidamente: en un espacio de nombres aislado ns-isolated, clonar uno más Pod mediante la ampliación de la implementación con replicas=2 y ping entre los dos pods:
$ kubectl scale deployment webserver --replicas=2 $ kubectl get pod -o wide -n ns-isolated NAME READY STATUS RESTARTS AGE IP NODE webserver-85fc7dd848-6l7j2 1/1 Running 0 8s 10.47.255.239 cent222 webserver-85fc7dd848-215k8 1/1 Running 0 8s 10.47.255.238 cent333 $ kubectl -n ns-isolated exec -it webserver-85fc7dd848-6l7j2 -- ping 10.47.255.238 PING 10.47.255.238 (10.47.255.238): 56 data bytes 64 bytes from 10.47.255.238: seq=0 ttl=63 time=1.470 ms ^C --- 10.47.255.238 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.470/1.470/1.470 ms
El paquete de ping pasa ahora. Para resumir los resultados de las pruebas:
El tráfico no se aísla entre los espacios de nombres no aislados.
El tráfico se aísla entre un espacio de nombres aislado y todos los demás inquilinos del clúster.
El tráfico no se aísla en el mismo espacio de nombres.
El aislamiento de nivel Pod puede lograrse a través de Kubernetes Directiva de red o de grupos de seguridad de Contrail, todo ello tratado más adelante en este capítulo.