Openshift Networking Services

Kubernetes Service Deep Dive

Semperti
Semperti
Sep 9 · 19 min read

Introducción

En lo que respecta a redes dentro de Openshift o Kubernetes, tenemos muchas aristas por revisar. Estas aristas son las tradicionales de cualquier centro de datos, pero definido por software y dentro de los nodos que componen nuestros clusters.

En este post vamos a trabajar desglosando todo lo que sucede a la hora de conectar dos aplicaciones dentro de Openshift como así también qué sucede cuando un cliente externo se conecta a un servicio dentro de Openshift por medio de recursos services.

Los escenarios son los siguientes.

  • Conexión Interna entre aplicaciones dentro de Openshift.
  • Conexión Externa a una aplicación dentro de Openshift.

¿Cómo conectamos pod en Openshift?

Image for post
Image for post

Si nosotros quisiéramos tener múltiples réplicas de una aplicación, tendríamos que levantar múltiples servidores ofreciendo la misma aplicación y a su vez para poder tener un único punto de acceso común deberíamos agregar un balanceador de carga (load balancer) que nos permita por una misma dirección ip (virtual ip) poder acceder a múltiples réplicas de una aplicación en distintos servidores. Un load balancer nos permite extendernos en las cantidad de servidores aplicativos manteniendo un único punto de acceso, la dirección ip virtual (VIP).

Image for post
Image for post

Ahora bien, en el mundo de los contenedores es exactamente igual, en vez de servidores tenemos Pods con interfaces virtuales y se conectan a los puertos de un switch virtual. Como verán, es lo mismo que en el ambiente físico.

Image for post
Image for post

Ahora bien, las ventajas de utilizar un cluster de Openshift es poder tener múltiples réplicas de nuestras aplicaciones. La unidad de delivery de aplicaciones en kubernetes es el pod, dentro de un pod podemos definir uno o más contenedores. Este objeto puede ser replicado. En el ambiente tradicional tenemos un load balancer que nos permite acceder por un único punto de acceso a múltiples servidores, en el caso de kubernetes de manera interna este servicio es ofrecido por un recurso llamado service.

Image for post
Image for post

Si un el pod rojo quisiera consumir el servicio ofrecido por los pods azules no llamaría a la ip de los pods directamente sino que llamaría a la ip del servicio y es la ip del servicio por medio de un mecanismo quien distribuye el tráfico entre los pods azules.

Kubernetes Services

Como hemos visto anteriormente un service se asemeja a el funcionamiento de un proxy o load balancer externo pero la funcionalidad no está implementada en un pod, en este caso los services están definidos por múltiples reglas de iptables distribuidas en todos los nodos de kubernetes u openshift.

Veamos como se define un service, que tipos existen y cómo se implementan estas series de reglas de iptables.

El recurso Service define:

  • Service (Proxy)
  • ClusterIP
  • Selector de pods (label)
  • EndPoints: pods

Documentación

$ oc explain service
KIND: Service
VERSION: v1
DESCRIPTION:
Service is a named abstraction of software service (for example, mysql)
consisting of local port (for example 3306) that the proxy listens on, and
the selector that determines which pods will answer requests sent through
the proxy.
...

Si quisiéramos indagar en sub opciones solo tenemos que concatenar la especificación, por ejemplo

oc explain service.spec.type.

Services Type

  • ClusterIP: Valor por defecto. Aloca una ip de un rango interno del cluster, rango no ruteado y no alcanzable desde el exterior. La ip de ClusterIP es el único punto de acceso para balancear entre los distintos pods agrupados por un selector en un recurso EndPoints.
  • ExternalName: Sirve para mapear un servicio con un nombre de host externo.
  • NodePort: Construido sobre ClusterIP y aloca un puerto en todos los nodos del cluster para poder rutear el puerto al ClusterIP.
  • LoadBalancer: Construido sobre NodePort, al definir un servicio crea un load balancer externo en un servicio de nube. Habla con la API de AWS, Azure, GCP

Veamos cómo son definidos los servicios.

ClusterIP

$ oc new-project test-services
$ oc new-app django-psql-example
....
--> Creating resources ...
secret "django-psql-example" created
service "django-psql-example" created
route.route.openshift.io "django-psql-example" created
imagestream.image.openshift.io "django-psql-example" created
buildconfig.build.openshift.io "django-psql-example" created
deploymentconfig.apps.openshift.io "django-psql-example" created
service "postgresql" created
deploymentconfig.apps.openshift.io "postgresql" created

En el output de la instrucción encontraremos el detalle de todos los recurso creados y con ellos el recurso services. Si inspeccionamos la salida veremos dos servicios el del front django-psql-example y el de la base postgresql.

$ oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
django-psql-example ClusterIP 172.30.85.132 <none> 8080/TCP 2m36s
postgresql ClusterIP 172.30.194.95 <none> 5432/TCP 2m36s

Ahora bien, en esta salida encontramos el detalle de tipo de servicio que es ClusterIP, la ip que representa el único punto de acceso y el puerto. Veamos la definición del servicio django-psql-example en formato yaml.

$ oc get service django-psql-example -o yaml
apiVersion: v1
kind: Service
metadata:
annotations:
description: Exposes and load balances the application pods
openshift.io/generated-by: OpenShiftNewApp
service.alpha.openshift.io/dependencies: '[{"name": "postgresql", "kind": "Service"}]'
creationTimestamp: "2020-09-05T22:42:16Z"
labels:
app: django-psql-example
template: django-psql-example
name: django-psql-example
namespace: test-services
resourceVersion: "777808"
selfLink: /api/v1/namespaces/test-services/services/django-psql-example
uid: 33caecf7-705a-4ae7-992a-b102fb7fa69c
spec:
clusterIP: 172.30.85.132
ports:
- name: web
port: 8080
protocol: TCP
targetPort: 8080
selector:
name: django-psql-example
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}

En la definición vamos a encontrar varias cosas interesantes:

  • CluterIP: ip única para todo el set de pods 127.30.85.123.
  • Ports: Los puertos tanto para el puerto propio del servicio port: 8080 y el port que escucharán los pods targetPort: 8080 ambos TCP.
  • Selector: El label por el cual seleccionaremos los pods entre todos los pods del namespaces name: django-psql-example.
  • Type: ClusterIP
  • SessionAffinity: Si vamos a tener algun tipo de afinidad con los pods que respondan nuestras peticiones.

Pero ahora bien, ¿dónde están las direcciones de nuestros pods?. Esto se define en el recurso EndPoints.

$ oc get endpoints
NAME ENDPOINTS AGE
django-psql-example 10.254.5.61:8080 53m
postgresql 10.254.5.59:5432 53m

Como verán tenemos una ip de pods por cada endpoints. Veamos en detalle el recurso endpoints.

$ oc get endpoints django-psql-example -o yaml 
apiVersion: v1
kind: Endpoints
metadata:
annotations:
endpoints.kubernetes.io/last-change-trigger-time: "2020-09-05T22:44:04Z"
creationTimestamp: "2020-09-05T22:42:16Z"
labels:
app: django-psql-example
template: django-psql-example
name: django-psql-example
namespace: test-services
resourceVersion: "778454"
selfLink: /api/v1/namespaces/test-services/endpoints/django-psql-example
uid: 0c9c8941-572d-443f-9893-c7d014d5ac3a
subsets:
- addresses:
- ip: 10.254.5.61
nodeName: worker2.ocp4.labs.semperti.local
targetRef:
kind: Pod
name: django-psql-example-1-hhng7
namespace: test-services
resourceVersion: "778452"
uid: e30da900-20a2-4929-b6c7-689995e470d2
ports:
- name: web
port: 8080
protocol: TCP

Interesante!, veamos la ip y nombre del pod, el nodo donde está corriendo y los puertos que escuchan el pod. Listemos el pod por medio del selector definido en el recurso service.

$ oc get pods -o wide -l name=django-psql-example
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
django-psql-example-1-hhng7 1/1 Running 0 50m 10.254.5.61 worker2.ocp4.labs.semperti.local <none> <none>

Ahora bien, que pasa si aumentamos una réplica de django-psql-example

$ oc scale dc django-psql-example --replicas=2
deploymentconfig.apps.openshift.io/django-psql-example scaled

Revisemos de nuevo los endpoints y encontramos la lista de los dos pods con los datos de ip, nombre, nodo, namespaces y puertos.

$ oc get endpoints django-psql-example -o yaml
apiVersion: v1
kind: Endpoints
metadata:
annotations:
endpoints.kubernetes.io/last-change-trigger-time: "2020-09-05T23:40:40Z"
creationTimestamp: "2020-09-05T22:42:16Z"
labels:
app: django-psql-example
template: django-psql-example
name: django-psql-example
namespace: test-services
resourceVersion: "794095"
selfLink: /api/v1/namespaces/test-services/endpoints/django-psql-example
uid: 0c9c8941-572d-443f-9893-c7d014d5ac3a
subsets:
- addresses:
- ip: 10.254.4.24
nodeName: worker0.ocp4.labs.semperti.local
targetRef:
kind: Pod
name: django-psql-example-1-grddz
namespace: test-services
resourceVersion: "794093"
uid: 06ae0ac2-f239-4e82-950e-dd4eb9d28374
- ip: 10.254.5.61
nodeName: worker2.ocp4.labs.semperti.local
targetRef:
kind: Pod
name: django-psql-example-1-hhng7
namespace: test-services
resourceVersion: "778452"
uid: e30da900-20a2-4929-b6c7-689995e470d2
ports:
- name: web
port: 8080
protocol: TCP

Verificamos las ips de los pods filtrando por el selector utilizado en la definición del servicio.

$ oc get pods -o wide -l name=django-psql-example
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
django-psql-example-1-grddz 1/1 Running 0 3m49s 10.254.4.24 worker0.ocp4.labs.semperti.local <none> <none>
django-psql-example-1-hhng7 1/1 Running 0 60m 10.254.5.61 worker2.ocp4.labs.semperti.local <none> <none>

Endpoints.

Para indicar el escalado de un nuevo pod, lo hacemos expresando el estado deseado por medio de la API de Kubernetes, único punto de acceso al cluster de kuberntes. Una vez que la API recibe el request, lo auténtica y lo autoriza, almacena en su base de datos clave/valor (etcd). El scheduler descubre el nuevo estado y es el encargado de seleccionar el nodo donde se aloja este pod. Luego es agregado el nombre de nodo en la definición del pod. El controller es el encargado de mantener la cantidad de réplicas de los pods. En caso de descubrir que en la definición existe una nueva réplica, dispara una tarea en el nodo donde se aloja el pod. Es kubelet (sysadmin del nodo) quien se encarga de levantar el pod indicando al runtime de contenedores (cri-io) que cree el o los contenedores definidos en el pod. Por último es kubeproxy (netadmin) es quién se encarga de definir las reglas de networking para el pod. El recurso de Openshift ReplicationController y el nativo de Kubernets ReplicaSet, son los encargados de mantener las réplicas deseadas.

Al momento de levantar un nuevo pod dos procesos son relevantes para decidir cuándo van a agregarse a lista de endopoints. En primer lugar, luego de un intervalo definido en el readiness probe es lanzado un chequeo (ej, GET HTTP) para verificar si el proceso está listo para recibir tráfico de negocio. Si es exitoso el pod es considerado como Ready y es agregado a la lista de Endpoints para participar del balanceo.

Este mecanismo nos asegura que vamos a agregar a la lista de servicios solo los pods que estan listos para poder brindar servicio.

IPTables.. ¿Dónde?

Primero veamos quien las implementa, esto cambia según el color de Kubernetes que vayamos a implementar. En el caso de Openshift existe un Cluster Operator, Openshift Network Operator. El Cluster Operator está implementado en el proyecto openshfit-sdn-operator y controla el despliegue en el proyecto openshift-sdn.

El proyecto openshift-sdn tiene tres tipos de pods: los pods de ovs-xxx que son los procesos de OpenVSwitch, switch donde se conectan todos los pods dentro de un nodo; los pods de sdn-controller-xxx que son el controlador de la red definida por software de openshift (SDN, Software Defined Network) y los pods de sdn-xxx que son los pods en cada uno de los nodos del cluster que implementan las reglas de iptables y definen los services. Este último pod es kubeproxy con sombrero rojo.

Si vemos el log de los pods de sdn-xxx vamos encontrar estas entradas de manera repetida e indican que las reglas son sincronizadas periódicamente.

$ oc logs sdn-hhshh
...
I0906 11:10:29.770925 2486 proxier.go:371] userspace proxy: processing 0 service events
I0906 11:10:29.771057 2486 proxier.go:350] userspace syncProxyRules took 50.199974ms
...

Ahora bien, volvamos a la definición del servicio y veamos donde estan implementadas las reglas de iptables. Para esto accedemos al pod y ejecutamos iptables-save | grep ‘test-services/django-psql-example’

$ oc rsh sdn-hhshh
sh-4.2# iptables-save | grep 'test-services/django-psql-example'
-A KUBE-SERVICES ! -s 10.254.0.0/16 -d 172.30.85.132/32 -p tcp -m comment --comment "test-services/django-psql-example:web cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 172.30.85.132/32 -p tcp -m comment --comment "test-services/django-psql-example:web cluster IP" -m tcp --dport 8080 -j KUBE-SVC-GIGN3HAIPPOO23F3
sh-4.2#

Que interesante!. La primer regla indica que va a ser aplicada a todo los paquetes que NO (negación, !) tenga red origen 10.254.0.0/16, destino 172.30.85.132/32 (la ip de ClusterIP) y con puerto destino 8080/TCP aplica (-j) KUBE-MARK-MASQ. La segunda regla indica que todo lo que sea con destino 172.30.85.132/32, port 8080/TCP aplica la regla KUBE-SVC-GIGN3HAIPPOO23F3. Veamos ahora que indica la regla KUBE-SVC-GIGN3HAIPPOO23F3.

sh-4.2# iptables-save | grep KUBE-SVC-GIGN3HAIPPOO23F3
:KUBE-SVC-GIGN3HAIPPOO23F3 - [0:0]
-A KUBE-SERVICES -d 172.30.85.132/32 -p tcp -m comment --comment "test-services/django-psql-example:web cluster IP" -m tcp --dport 8080 -j KUBE-SVC-GIGN3HAIPPOO23F3
-A KUBE-SVC-GIGN3HAIPPOO23F3 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-7ANA7OTZZO5QKVWN
-A KUBE-SVC-GIGN3HAIPPOO23F3 -j KUBE-SEP-JBBKRG73QF24CZJD

Veamos que las segunda instrucción tiene el argumento -m statistic — mode random — probability 0.50000000000. Este argumento indica que el 50% de los paquetes serán aceptados por esta línea redirigidos a la regla KUBE-SEP-7ANA7OTZZO5QKVWN, el 50% restante caerá a la línea siguiente con destino KUBE-SEP-JBBKRG73QF24CZJD. Veamos que son estas últimas dos reglas.

sh-4.2# iptables-save | grep KUBE-SEP-7ANA7OTZZO5QKVWN
:KUBE-SEP-7ANA7OTZZO5QKVWN - [0:0]
-A KUBE-SVC-GIGN3HAIPPOO23F3 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-7ANA7OTZZO5QKVWN
-A KUBE-SEP-7ANA7OTZZO5QKVWN -s 10.254.4.24/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-7ANA7OTZZO5QKVWN -p tcp -m tcp -j DNAT --to-destination 10.254.4.24:8080
sh-4.2# iptables-save | grep KUBE-SEP-JBBKRG73QF24CZJD
:KUBE-SEP-JBBKRG73QF24CZJD - [0:0]
-A KUBE-SVC-GIGN3HAIPPOO23F3 -j KUBE-SEP-JBBKRG73QF24CZJD
-A KUBE-SEP-JBBKRG73QF24CZJD -s 10.254.5.61/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-JBBKRG73QF24CZJD -p tcp -m tcp -j DNAT --to-destination 10.254.5.61:8080

En la última regla se aplica un DNAT (Destination Network Address Translation) hacia la ip 10.254.4.24:8080 que es la ip de nuestro pod que brinda el servicio. En la segunda regla vemos que aplica a la otra ip del pod 10.254.5.61:8080. Esto nos indica una aleatoriedad estadística en la distribución del tráfico donde el 50% caerá en una y el restante en la otra.

Pero qué pasa si escalo la cantidad de pods?. ¿ Cómo se distribuyen las probabilidades ?. Escaló los pods a tres con oc scale dc django-psql-example — replicas=3 -n test-services y veamos las distribuciones.

$ oc rsh sdn-hhshh
sh-4.2# iptables-save | grep KUBE-SVC-GIGN3HAIPPOO23F3
:KUBE-SVC-GIGN3HAIPPOO23F3 - [0:0]
-A KUBE-SERVICES -d 172.30.85.132/32 -p tcp -m comment --comment "test-services/django-psql-example:web cluster IP" -m tcp --dport 8080 -j KUBE-SVC-GIGN3HAIPPOO23F3
-A KUBE-SVC-GIGN3HAIPPOO23F3 -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-7ANA7OTZZO5QKVWN
-A KUBE-SVC-GIGN3HAIPPOO23F3 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-JBBKRG73QF24CZJD
-A KUBE-SVC-GIGN3HAIPPOO23F3 -j KUBE-SEP-XU6QRWQ6NFR3D34U
sh-4.2#

En el caso de tres réplicas, la probabilidad cambia. Indica que el 33.33% de los paquetes caerán en random mode en la primera línea. Del 76,66% de los paquetes restantes, el 50% de esos 76.66% caerá en la segunda línea y lo que reste caerá en la última línea.

Para conexiones por ráfagas, cómo GETs a un API REST, vimos que las cantidad de conexiones se distribuyen de manera homogénea, no así en ciertos escenarios donde se puede aplicar afinidad y esto viene acompañado de caso de uso. Generalmente el tráfico es distribuido de manera homogénea entre los pods. Siempre y cuando no haya algún tipo de afinidad definida.

NodePort

Image for post
Image for post

Un cliente como un dispositivo de red como un load balancer puede acceder al socket que corresponde a la ip de host con el puerto asignado dinámicamente, internamente el servicio redirigirá el tráfico al pod que haya sido seleccionado. Esto es útil para poder trabajar con Load Balancers y exponer nuestras aplicaciones no solo via http/https, sino también vía socket tcp. La desventaja es que todos los nodos del cluster abrirán un puerto localmente para cada servicio, en ambientes con Openshift no se recomienda utilizar este tipo de servicio a no ser que sea justificado.

Probemos como lo vemos desde la línea de comandos. Utilizamos la misma aplicación y creamos el nuevo servicio con type port NodePort. Borramos el servicio original para poder re-crearlo con el flag de nodePort.

$ oc delete svc django-psql-example
service "django-psql-example" deleted

Creamos el servicio por medio de la cli de Openshift, también podemos utilizar un manifiesto definido en un archivo y realizar el oc apply -f service-nodeport.yaml o en su defecto con el comando kubectl apply -f service-nodeport.yaml haciendo definido el manifest por practicidad vamos a crearlo desde el cliente oc.

$ oc expose dc django-psql-example --type=NodePort --name=django-psql-example
service/django-psql-example created

Verificamos el servicio con tipo nodePort. Podemos ver que encontramos una ip de ClusterIP, un puerto en PORT(s) y un puerto adicional al 8080 el 31070 que representa el puerto que estará abierto en todos los nodos del cluster.

$ oc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
django-psql-example NodePort 172.30.191.202 <none> 8080:32291/TCP 109s
postgresql ClusterIP 172.30.1.44 <none> 5432/TCP 7h36m

Veamos el manifiesto yaml para verificar la definición de nodeport: 30096.

$ oc get svc django-psql-example -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-09-06T19:23:08Z"
labels:
app: django-psql-example
template: django-psql-example
name: django-psql-example
namespace: test-nodeport
resourceVersion: "1121267"
selfLink: /api/v1/namespaces/test-nodeport/services/django-psql-example
uid: 715909af-caa9-467b-8e5b-11e3a99624d5
spec:
clusterIP: 172.30.191.202
externalTrafficPolicy: Cluster
ports:
- nodePort: 32291
port: 8080
protocol: TCP
targetPort: 8080
selector:
name: django-psql-example
sessionAffinity: None
type: NodePort
status:
loadBalancer: {}

Ahora si bien entramos a los nodos worker y vemos el puerto, podremos ver que está arriba.

$ oc debug node/worker0.ocp4.labs.semperti.local --image=rhel7/rhel-tools
...
sh-4.2# chroot /host
sh-4.4# ss -putan | grep -i listen | grep 32291
tcp LISTEN 0 128 *:32291 *:* users:(("openshift-sdn-n",pid=2490,fd=20))
sh-4.4#

y si le pegamos a la ip del host vemos que la conexión es exitosa y nos responde el framework web de python, django.

$ curl -kv http://10.252.7.235:32291/ | head -1 
* About to connect() to 10.252.7.235 port 32291 (#0)
* Trying 10.252.7.235...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.252.7.235 (10.252.7.235) port 32291 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.252.7.235:32291
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: gunicorn/19.5.0
< Date: Sun, 06 Sep 2020 19:25:48 GMT
< Connection: close
< Content-Type: text/html; charset=utf-8
< X-Frame-Options: SAMEORIGIN
< Content-Length: 18324
<
{ [data not shown]
<!doctype html>
* Failed writing body (3802 != 5742)
100 18324 100 18324 0 0 407k 0 --:--:-- --:--:-- --:--:-- 416k
* Closing connection 0
curl: (23) Failed writing body (3802 != 5742)

Si revisamos las reglas de iptables para el servicio encontraremos definiciones para la ip de ClusterIP como KUBE-SERVICE y en las últimas líneas las reglas KUBE-NODEPORTS que indican la definición para el port externo.

$ oc rsh sdn-v9k76
sh-4.2# iptables-save | grep test-nodeport/django-psql-example
-A KUBE-SERVICES ! -s 10.254.0.0/16 -d 172.30.191.202/32 -p tcp -m comment --comment "test-nodeport/django-psql-example: cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 172.30.191.202/32 -p tcp -m comment --comment "test-nodeport/django-psql-example: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-5YXNK7KOCSOUM3AE
-A KUBE-NODEPORTS -p tcp -m comment --comment "test-nodeport/django-psql-example:" -m tcp --dport 32291 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "test-nodeport/django-psql-example:" -m tcp --dport 32291 -j KUBE-SVC-5YXNK7KOCSOUM3AE
sh-4.2#

Si vemos las reglas son exactamente las mismas que para el servicio de ClusterIP.

sh-4.2# iptables-save | grep KUBE-SVC-5YXNK7KOCSOUM3AE
:KUBE-SVC-5YXNK7KOCSOUM3AE - [0:0]
-A KUBE-SERVICES -d 172.30.191.202/32 -p tcp -m comment --comment "test-nodeport/django-psql-example: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-5YXNK7KOCSOUM3AE
-A KUBE-NODEPORTS -p tcp -m comment --comment "test-nodeport/django-psql-example:" -m tcp --dport 32291 -j KUBE-SVC-5YXNK7KOCSOUM3AE
-A KUBE-SVC-5YXNK7KOCSOUM3AE -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WBMKBITY6POBVI7J
-A KUBE-SVC-5YXNK7KOCSOUM3AE -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ZRETU3UTQ3EXCFUX
-A KUBE-SVC-5YXNK7KOCSOUM3AE -j KUBE-SEP-2CQOQG2SNEWYJXXO

ExternalName

Por ejemplo, podemos agregar un servicio interno para poder llegar a un servicio de storage de objeto provisto por MinIO implementado externamente al cluster. MinIO, hosteado en la ip 10.252.7.230 con entrada en el DNS externo minio.ocp4.labs.semperti.local.

$ oc create service externalname  minio --external-name minio.ocp4.labs.semperti.local

Vemos a continuación que solo tiene una referencia a la URL externa.

$ oc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
django-psql-example ClusterIP 172.30.85.132 <none> 8080/TCP 23h
minio ExternalName <none> minio.ocp4.labs.semperti.local <none> 3s
postgresql ClusterIP 172.30.194.95 <none> 5432/TCP 23h

Al alcanzar el servicio por el nombre interno definido en el proyecto, nos conectamos directamente a la ip externa 10.252/7.230.

$ oc rsh django-psql-example-1-grddz 
(app-root) sh-4.2$ curl -v http://minio:9000/
* About to connect() to minio port 9000 (#0)
* Trying 10.252.7.230...
* Connected to minio (10.252.7.230) port 9000 (#0)
> GET / HTTP/1.1```

La ventaja es, si tuviéramos un backup de s3 para DEV, TEST y PROD, en la definición de nuestra aplicaciones solo llamamos al servicio de la misma manera en todos los ambientes, solo cambiaría el endpoint en cada uno de los servicios.

LoadBalancer

oc expose dc django-psql-example — port=8080 — type=LoadBalancer

Podemos ver como la url del load balancer (AWS ELB) en la columna EXTERNAL-IP

$ oc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
django-psql-example LoadBalancer 172.30.7.213 ac5c317cb9b0843588100b1b8889d999-389844834.us-east-2.elb.amazonaws.com 8080:30927/TCP 3s
postgresql ClusterIP 172.30.201.42 <none> 5432/TCP 72s

La definición en formato yaml es la misma que en nodePort con la diferencia en status.loadbalancer.ingress.

$ oc get svc django-psql-example -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-09-06T22:45:30Z"
finalizers:
- service.kubernetes.io/load-balancer-cleanup
labels:
app: django-psql-example
template: django-psql-example
name: django-psql-example
namespace: test-loadbalancer
resourceVersion: "1275803"
selfLink: /api/v1/namespaces/test-loadbalancer/services/django-psql-example
uid: c5c317cb-9b08-4358-8100-b1b8889d9997
spec:
clusterIP: 172.30.7.213
externalTrafficPolicy: Cluster
ports:
- nodePort: 30927
port: 8080
protocol: TCP
targetPort: 8080
selector:
name: django-psql-example
sessionAffinity: None
type: LoadBalancer
status:
loadBalancer:
ingress:
- hostname: ac5c317cb9b0843588100b1b8889d999-389844834.us-east-2.elb.amazonaws.com

En lo que respecta a reglas de iptables podemos ver son las mismas para el nodePort

$ oc rsh sdn-lz596
sh-4.2# iptables-save | grep test-loadbalancer/django-psql-example
-A KUBE-SERVICES ! -s 10.128.0.0/14 -d 172.30.7.213/32 -p tcp -m comment --comment "test-loadbalancer/django-psql-example: cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 172.30.7.213/32 -p tcp -m comment --comment "test-loadbalancer/django-psql-example: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-AD7VE3QSWBRYRSA5
-A KUBE-NODEPORTS -p tcp -m comment --comment "test-loadbalancer/django-psql-example:" -m tcp --dport 30927 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "test-loadbalancer/django-psql-example:" -m tcp --dport 30927 -j KUBE-SVC-AD7VE3QSWBRYRSA5
sh-4.2#

Conclusiones

¿ Qué vamos a ver en próximas entradas ?.

Ingress Controller

  • ¿Cómo funciona el ruteo externo?.
  • ¿Qué componentes lo conforman?
  • ¿Cómo trabajan técnicamente?
  • ¿Patrones de diseño de acceso de aplicaciones?
  • ¿Router Shardering?

Links

Image for post
Image for post

Ing. Gonzalo Acosta es Site Reliability Engineer en Semperti. Acompaña a clientes en el proceso de diseño, adopción y capacitiación de tecnologías cloud. Profesional con mas 14 años en la industria IT. Antes de incorporarse como SRE/DevOps en Semperti se ha desarrolado como Arquitecto de Infraestructura y Unix SysAdmin en el sector de Telecomunicaciones. Deportista como estilo de vida, ex triatleta Ironman, mejor duatleta y hoy runner en busca de un maratón.

Semperti

Hacemos trascender la misión de nuestros clientes sin alterar su identidad.

Semperti

Written by

Semperti

Un Consultor de TI especializado en diseño e implementación de soluciones tecnológicas altamente complejas. Base en Argentina & Chile.

Semperti

Semperti

Ayudamos a nuestros clientes adoptar nuevas plataformas haciendo foco en los aspectos que van más allá de lo tecnológico. Nos apoyamos en nuestro equipo, las más importantes marcas y un ecosistema de partners para diseñar, construir y gestionar soluciones innovadoras que permitan

Semperti

Written by

Semperti

Un Consultor de TI especializado en diseño e implementación de soluciones tecnológicas altamente complejas. Base en Argentina & Chile.

Semperti

Semperti

Ayudamos a nuestros clientes adoptar nuevas plataformas haciendo foco en los aspectos que van más allá de lo tecnológico. Nos apoyamos en nuestro equipo, las más importantes marcas y un ecosistema de partners para diseñar, construir y gestionar soluciones innovadoras que permitan

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store