Kubernetes gestionados «alternativos»

Introducción

Todos conocemos la oferta de Kubernetes gestionados del «big three»: EKS, GKE y AKS.

Pero a día de hoy, aparte de los anteriores y de algunos más que quieren jugar en la misma liga (Oracle o IBM, por ejemplo), existen otros proveedores menos conocidos que, no pudiendo competir en catálogo de servicios, intentan hacerse un hueco ofreciendo sencillez y precios más bajos. Una de las bondades que ha traído la «explosión» de Kubernetes es que con él y poco más (un load balancer, algo de almacenamiento y una base de datos gestionada) se puede llegar muy lejos antes de necesitar lo que ofrecen los grandes.

Así que, cuando hablamos de Kubernetes «sencillo y barato», la fórmula consiste en ofrecer el servicio de «Kubernetes gestionado» (los nodos master son alojados y gestionados por el proveedor) sin cobrar por ello. Y esto es justamente lo que proporcionan proveedores como Scaleway, Linode, OVH o DigitalOcean.

Probando un clúster gestionado

En Geko Cloud estamos desarrollando un producto basado en Kubernetes del que muy pronto tendréis más noticias, así que decidimos usarlo para probar uno de los servicios de la lista (en este caso, Digital Ocean Kubernetes Service).

Crear un cluster es muy sencillo: basta con seleccionar la versión, la región, el tipo de nodo para el pool y darle un nombre:

 

Control Panel DigitalOcean
Creación cluster k8s DO

En nuestro caso, al tratarse de una prueba, elegimos crear droplets básicos y confiar en el cluster autoscaler en caso que la aplicación fuera a necesitar más recursos.

Cuando el clúster estuvo listo (el proceso puede tardar unos 10-15 minutos), solo tuvimos que descargar el fichero kubeconfig y lanzar el proceso de instalación de la aplicación. Y ahí empezaron los problemas.

Problemas observados

Al poco rato, el API server empezó a comportarse de forma un tanto errática, respondiendo muy lentamente o devolviendo diversos errores. Síntomas:

  • Tiempos de respuesta altísimos, en ocasiones incluso superiores al minuto
    bash-5.0# time kubectl get pods -A 
    NAMESPACE                      NAME                                                 READY   STATUS              RESTARTS   AGE
    istio-system                   istio-init-crd-10-1.4.8-86xf9                        1/1     Running             1          7m1s
    …
    real    1m14.507s
    user    0m0.174s
    sys     0m0.028s
    
  • Errores de conexión
    bash-5.0# kubectl get pods -A
    Unable to connect to the server: unexpected EOF
  • Timeouts en la negociación TLS
    bash-5.0# kubectl get pods -A
    Unable to connect to the server: net/http: TLS handshake timeout

El problema tenía que estar relacionado con la instalación ya que antes de eso todo funcionaba perfectamente.

DigitalOcean, al igual que el resto de proveedores, no ofrece ningún tipo de información acerca de los recursos dedicados a los nodos master (número de nodos, tamaño de los mismos…) ni acceso a los logs o a la monitorización del control plane, así que no había forma de saber qué estaba pasando.

Una búsqueda rápida nos hizo darnos cuenta que no éramos los únicos con este tipo de problemas, aunque también vimos que muchos otros eran usuarios felices del servicio.

Solución

Esto nos hizo sospechar que no todos los nodos master eran creados por igual, y que el único parámetro del proceso de creación que podía crear la diferencia era el node pool configurado.

Para verificar nuestra teoría, primero probamos a crear un clúster con un node pool con más nodos (de 3 pasamos a 6), con idéntico resultado.

Así que probamos a crear un node pool con nodos no-básicos (CPU-Optimized en este caso). Y ahí sí dimos en el clavo: el proceso de instalación terminó sin problemas y el API server estuvo respondiendo adecuadamente todo el tiempo.

Conclusión

Está claro que nadie regala nada y que no puedes esperar tener un nodo master dedicado con 16 cores y 64 Gb de RAM pagando 20€ al mes por un droplet básico. De todos modos no estaría de más que fueran un poco más transparentes e informaran de las capacidades y limitaciones del servicio que están ofreciendo (aunque sea gratuito). De esta forma, más de uno se ahorraría dolores de cabeza y frustraciones.

Así que si tienes planteado usar este servicio para alojar una aplicación que vaya a hacer un uso más o menos intensivo del API server, será mejor que te decantes por droplets no-básicos si no quieres tener problemas de rendimiento.

Y recuerda que si necesitas cualquier cosa estaremos encantados de escucharte. ¡También puedes revisar nuestro blog para encontrar otras publicaciones útiles como ésta!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *