Bienvenidos a la página personal de José Domingo Muñoz Rodríguez, aquí podrás encontrar…

Accede a las entradas de mi blog donde escribo de Informática y Educación.

Blog Pledin

Accede a los materiales de los cursos que he impartido.

Plataforma Pledin

Accede a los contenido de los módulos de FP que estoy impartiendo en la actualidad.

Módulos FP

Últimos posts...


Recursos de Kubernetes: Ingress

Hasta ahora tenemos dos opciones principales para acceder a nuestras aplicaciones desde el exterior:

  1. Utilizando servicios del tipo NodePort: Esta opción no es muy viable para entornos de producción ya que tenemos que utilizar puertos aleatorios desde 30000-40000.
  2. Utilizando servicios del tipo LoadBalancer: Esta opción sólo es válida si trabajamos en un proveedor Cloud que nos cree un balanceador de carga para cada una de las aplicaciones, en cloud público puede ser una opción muy cara.

La solución puede ser utilizar un Ingress controller que nos permite utilizar un proxy inverso (HAproxy, nginx, traefik,…) que por medio de reglas de encaminamiento que obtiene de la API de Kubernetes nos permite el acceso a nuestras aplicaciones por medio de nombres.

ingress

  • Vamos a desplegar una pod que implementa un proxy inverso (podemos utilizar varias opciones: nginx, HAproxy, traefik,…) que esperará peticiones HTTP y HTTPS.
  • Por lo tanto el Ingress Controller será el nodo del cluster donde se ha instalado el pod. En nuestro caso, para realizar el despliegue vamos utilizar un recurso de Kubernetes llamado DaemontSet que asegura que el despliegue se hace en todos los nodos del cluster y que los puertos que expone los pods (80 y 443) están mapeado y son accesible en los nodos. Por lo que cada uno de los nodos del cluster va a poseer una copia del Ingress Controller.
  • No es necesario que al servicio al que accede el Ingress Controller este configurado del tipo NodePort.
Seguir leyendo...

Kubernetes: Desplegando la aplicación LetsChat

En este ejemplo vamos a instalar una aplicación web (CMS), llamado letschat. LetsChat nos ofrece la posibilidad de tener un sistema de chat. Está escrito en node.js y utiliza una base de datos mongo. Por lo tanto vamos a crear dos deployments:

  • Uno con la aplicación letschat, este deployment lo vamos poder escalar sin problemas.
  • Otro con la base de datos mongo.

En el directorio letschat tenemos los ficheros yaml que describen los dos despliegues, además de los que describen los dos servicios:

  • El fichero mongo-srv.yaml crea un servicio del tipo ClustrIP para poder acceder a mongo:

      apiVersion: v1
      kind: Service
      metadata:
        name: mongo
      spec:
        ports:
        - name: mongo
          port: 27017
          targetPort: mongo
        selector:
          name: mongo
    
  • El fichero letschat-srv.yaml crea el servicio NodePort para poder acceder desde el exterior a la aplicación:

      apiVersion: v1
      kind: Service
      metadata:
        name: letschat
      spec:
        type: NodePort
        ports:
        - name: http
          port: 8080
          targetPort: http-server
        selector:
          name: letschat
    
Seguir leyendo...

Kubernetes: Desplegando la aplicación GuestBook (Parte 2)

Nuestra aplicación guestbook nos daba un error porque no podía acceder a la base de datos redis, además la forma que teníamos para acceder a la aplicación era utilizando la redirección de puerto usando la instrucción kubectl port-forward.

En este ejemplo vamos a crear dos servicios.

Definición del servicio para poder acceder a la base de datos redis

En este caso no tenemos que acceder a la base de datos desde el exterior. Es la aplicación la que internamente debe poder acceder a ella, por tanto vamos a crear un servicio del tipo ClusterIP. En el fichero redis-master-srv.yaml encontramos la definición del servicio para acceder al master de redis:

apiVersion: v1
kind: Service
metadata:
  name: redis-master
  labels:
    app: redis
    role: master
    tier: backend
spec:
  ports:
  - port: 6379
    targetPort: redis-server
  selector:
    app: redis
    role: master
    tier: backend
  type: ClusterIP

De forma similar el fichero redis-slave-srv.yaml define el servicio apra acceder al slave de redis.

Seguir leyendo...

Más posts...

Últimos cursos...

Blogroll

Revistas Libres de Software Libre

cc

Licencia

Licencia: Puedes copiar y modificar todos los contenidos, pero siempre respetando los términos de la licencia CC-BY-SA.

Ver