Services en Kubernetes (1)

Los servicios en kubernetes son una abstraccion en la cual se define como se accede a un grupo de pods y son otro objeto definible en la api.

El grupo de pods a los que se aplica se suele determinar via label selector.

De esta forma, cuando se crea un servicio, se evalua el conjunto de pods al que aplica y se crean objetos endpoint apuntando a ellos.

¿Como va el trafico a esos pods? La Service cluster IP

Por defecto, al crear un servicio se crea una service cluster ip virtual. Asi en cada nodo del cluster se crean reglas iptables que redirigen el tráfico enviado hacia dicha cluster ip hacia los pods a los que aplica el servicio.

Es decir, si un cliente dentro del cluster hace una peticion a la cluster ip de ese servicio, el trafico se redirige a los pods implicados.

El backend seleccionado sera aleatorio, aunque se puede elegir una afinidad de sesion en base a la ip del cliente via opcion "ClientIP".

DNS

Aunque la cluster ip se puede especificar, en kubernetes no es necesario saberla y es que, al crear un servicio, se crear una entrada DNS interna que apunta a ella. De esta forma los pods que quieran enviar trafico a los seleccionados por el servicio pueden llamarlo por nombre, que resolvera a la cluster ip y a su vez redirigira via iptables a los pods en cuestion.

Puertos

Ademas al definir un servicio, se especifica el puerto que se quiere exponer ("port") y el puerto de destino de los pods a los que aplica el servicio ("targetPort"). El targetPort ademas de un numero puede ser un string, lo que permite que el puerto definido en los pod a los que aplica el servicio sean diferentes pero el nombre el mismo.

TCP y UDP son los protocolos soportados.

Comunicacion entre pods

Cuando un pod quiere comunicarse con otro via servicio, apuntara al nombre del servicio, el cual resuelve a la virtual ip del mismo.

Como hemos visto, cada nodo lleva reglas iptables que redirigiran el trafico a uno de los pods seleccionados. Si está en otro nodo diferente a donde esta el pod que hace la peticion, el trafico ira via network plugin, flannel por ejemplo y la gateway flannel0.

Exposicion al exterior

Todo esto se aplica para exponer pods a clientes dentro del cluster, pero si queremos exponerlos fuera tenemos otras 2 opciones principalmente.

En vez de cluster ip podemos usar LoadBalancer, el cual se usa para utilizar un balanceador del proveedor cloud en el que podamos tener nuestro cluster, como Google Cloud Engine.

La otra opcion es NodePort, la cual levanta en cada nodo del cluster un servicio (kube-proxy) escuchando en un puerto.
Esto ademas permite via balanceador externo acceder a los pods implicados en el servicio, simplemente apuntando dicho balanceador a todos los nodos del cluster y el puerto en el que escucha kube-proxy.

Dicho puerto puede ser aleatorio o especificado via "nodePort".

Resumiendo, con nodePort llamas desde el exterior a un balanceador que enviara el trafico al puerto de un nodo donde escucha kube-proxy, el cual enviara el trafico al backend correspondiente.