Kubernetes – Almacenamiento con Rancher Longhorn, Parte2.

Kubernetes – Almacenamiento con Rancher Longhorn, Parte2.

Announcing Longhorn: an open source project for microservices-based distributed block storage

En esta edición de mis aventuras con #k8s, acabo de instalar una implementación de almacenamiento desarrollada por Rancher. Desde mi punto de vista es parte2 porque fue la primera solución de almacenamiento distribuido que utilice hace meses, pero tenía varios temas, por ejemplo, cuando un pod era eliminado y este tenía un pvc montado, muchas veces no eran eliminados junto con su pod/deployment, otras veces si el pod/deployment era relanzado, el pvc tardaba minutos en montarse al pod.

Hace unos meses lanzaron nueva versión y tiene bastantes mejoras, además he tenido experiencias con Linstor que en mi pequeño ambiente son algo incomodas, actualmente tengo un controller de Linstor, si esta falla, falla la creación de volúmenes y por consecuente la creación de pods.

Instalar Longhorn es increíblemente fácil, con tan solo ejecutar kubectl -f url/de/yaml tendremos en marcha nuestro almacenamiento distribuido. Usando Rancher UI es mucho mas fácil, así lo he hecho esta vez, la ventaja de hacerlo desde Rancher UI es que podemos acceder al Dashboard de Longhorn desde Rancher usando las mismas credenciales.

https://rancher.com/blog/2017/announcing-longhorn-microservices-block-storage/

En ese enlace se puede leer sobre el diseño de Longhorn:

Storage Orchestration
Replica Operations
Replica Rebuild
Backup of Snapshots
Deployment Models

Documentar el proceso de instalación está de más, en YouTube podemos ver el video de Adrian Goins.

https://www.youtube.com/watch?v=q5JzZbiw4LE

Y para los que quieren entender más a profundidad como funciona Longhorn, les recomiendo ver un video de Rancher Labs titulado: Kubernetes Master Class – Using Persistent Storage in Kubernetes and Project Longhorn.

https://www.youtube.com/watch?v=BnHMAJ8azBU&t=

En los próximos días estaré moviendo todo lo que tengo en Linstor a Longhorn, espero no perder información en el proceso!!!

RIPE Atlas – Estado actual en República Dominicana.

RIPE Atlas – Estado actual en República Dominicana.

Para los que no saben que es RIPE Atlas, es un Proyecto de RIPE NCC, su meta es colectar información de las conexiones a Internet usando un pequeño “probe” que se coloca en la red de un usuario, empresa o proveedor de Internet. Luego este probe realiza pruebas predefinidas para colectar valores como latencia, jitter y hasta pruebas de puertos, probar si DNS está respondiendo en servidores específicos.

No es un proyecto nuevo, los primeros registros se iniciaron en el 2010. Desde entonces existen países que han recibido esto como una herramienta para mejorar, pero lamentablemente otros no lo han hecho de esa manera debido al poco apoyo recibido. Tomaremos como ejemplo Republica Dominicana.

En nuestro país actualmente tenemos registrados 49 probes de los cuales solo 15 están conectados hoy [20/10/2019]. Si miramos detenidamente podremos ver que el primer probe en DO se conecto a la red de Atlas hace 4 años y 17 días y tiene 2 años desconectado.

¿Por qué pasa esto?

Mi opinión es que luego de recibir este pequeño aparato y conectarlo a la red, el usuario no siente que esta obteniendo un beneficio y en cualquier momento decide desconectarlo porque ya entiende que no lo necesita, lamentablemente esto también pasa en empresas, si miramos la lista de probes abandonados ahí muchos que al parecer fueron registrados por una empresa o proveedor y sufrieron la misma suerte.

¿Como podemos mejorar esto?

Tenemos que comprometernos a mejorar la infraestructura de Internet, hasta el menor esfuerzo como es hospedar un probe de RIPE Atlas aporta a mejorar Internet ya que permite que instituciones con áreas dedicadas al desarrollo usen esta plataforma para realizar pruebas de conectividad y entender mejor como cambian las redes de interconexión a través de los años.

¿Qué puedo hacer luego de tener un Probe?

Con RIPE Atlas tenemos que cumplir una condición para poder hacer uso de la plataforma, tenemos que acumular créditos, estos créditos se pueden conseguir dejando nuestro probe encendido y conectado a la red para que genere crédito a nuestro favor o recibiendo una donación de otro usuario. Luego que contamos con créditos podemos crear nuestras propias métricas.

Por ejemplo, hace un tiempo cree una métrica para medir la latencia desde Republica Dominicana a los DNS Resolver de CloudFlare.

En esta conjuración solicite 20 probes, todos de Republica Dominicana, actualmente están participando solo 9.

En la pestana de Latest Results podemos ver los últimos resultados de esta métrica.

En esta pestaña podemos apreciar la cantidad de RTT y HOPs utilizados por el probe para alcanzar a 1.0.0.1 que es uno de los DNS Open Resolver de CF. Lamentablemente uno de los probe está fuera de línea.

Otra pestaña de la cual podemos sacar ventaja es Tracemon.

Esta nos entrega un mapa con los saltos que hicieron los probe para llegar a su destino final, en cada punto podemos ver IP utilizada y ASN al cual pertenece esa IP.

Esto que acabo de mostrar aquí son de las configuraciones mas sencillas que se pueden crear en la plataforma, no soy ningún experto, pero sigo intentando sacarle partido a RIPE Atlas. Actualmente tengo dos probes corriendo, uno con mi ASN ( AS207036 ) y otro detrás del ASN de CLARO.

Para cerrar, si estas interesado en hospedar un probe de manera seria y con compromiso de tenerlo conectado, contáctame, actualmente estoy registrado como Embassador en Republica Dominicana, esto quiere decir que puedo asignar probes de algunos que tengo disponible.

AS207036 – Por qué y para qué?

AS207036 – Por qué y para qué?

El título de esta entrada tiene una razón de ser.

Porque existe AS207036 ?

Simple, leyendo RFC1925 encontraremos el siguiente párrafo:

The Twelve Networking Truths, Section 2.4:

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

Operational Network:

https://aanetworks.org/

Esta es la diferencia entre correr routers en GNS3 y correr routers con un propósito, en los últimos años he operado AS207036 y cada día que pasa se vuelve parte esencial de mi red operacional, primero vamos a listar que hace AS207036.

1 – Anunciar vía BGP prefijos IPv4

2 – Anunciar vía BGP prefijos IPv6

https://bgp.he.net/AS207036

Hace unos días solicite que el CountryCode fuera cambiado de Germany (DE) a Dominican Republic (DO), ahora soy “The King of the Hill” …..

El LIR en RIPE que tengo es lo mejor!! https://asn.servperso.net/

Lo importante aquí es todo lo que puedo hacer usando esas direcciones IP de las cuales tengo total control y no dependo de NAT para tener servicios como servidores web (donde estas leyendo este post), VPN, email server y otros.

Y ya que en .DO aun no se brinda conectividad a Internet vía IPv6, tengo acceso a Internet usando direcciones IPv6.

Al final del día que he ganado con toda esta configuración y complejidad?

Experiencia!!!

Kubernetes – Almacenamiento con Linstor.

Kubernetes – Almacenamiento con Linstor.

Hace ya un tiempo que escribí sobre k8s, otros proyectos han tomado tiempo y recursos, hace unas semanas retome el clúster que tengo en casa para terminar las configuraciones necesarias y mover lo más que pueda de algunas máquinas virtuales que tengo en vSphere y que entiendo desempeñarían mejor estando en Kubernetes.

Inicialmente las pruebas fueron realizadas con longhorn, algunos problemas los cuales no inspiran mucha confianza me hicieron no escribir sobre esa implementación, claramente Rancher dice que es un proyecto aun en beta.

Hace unas semanas leí sobre Linstor [ http://vitobotta.com/2019/08/07/linstor-storage-with-kubernetes/ ], la instalación fue realizada en Ubuntu que es la misma distribución que estoy usando. He decidido usar esta implementación porque usa LVM como backend en los equipos que aportaran almacenamiento para el clúster, además de esto los nodos que están aportando almacenamiento no necesariamente deben tener k8s, al menos eso es lo que entiendo y algo que debo validar.

Instalando Linstor.

Prepararemos nuestros equipos con los siguientes pasos:

apt-get install linux-headers-$(uname -r)
add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update
apt install drbd-utils drbd-dkms lvm2
modprobe drbd
lsmod | grep -i drbd
echo drbd > /etc/modules-load.d/drbd.conf

 

En este punto ya los equipos están listos para instalar los componentes de Linstor. Para estar seguro de que todo estaba bien procedí a reiniciar el nodo.

Seleccionamos un equipo para que sea controlador del cluster de Linstor, además este mismo equipo puede aportar almacenamiento así que también instalaremos el componente de satellite.

apt install linstor-controller linstor-satellite linstor-client

Ahora habilitamos e inicializamos los componentes.

systemctl enable --now linstor-controller
systemctl start linstor-controller

En los demás equipos instalamos el componente de satélite.

apt install linstor-satellite linstor-client

Habilitamos el servicio y lo iniciamos.

systemctl enable --now linstor-satellite
systemctl start linstor-satellite

Desde el controller agregamos los equipos satélites.

linstor node create kube1 172.22.35.25
linstor node create kube2 172.22.35.26
linstor node create kube3 172.22.35.27

Esperamos unos minutos y ejecutamos:

linstor node list

Este comando nos mostrará la lista de nodos disponibles, será algo así:

Ya contamos con un clúster de Linstor pero aun no estamos presentando almacenamiento a este, procederemos a crear almacenamiento administrado por LVM, Linstor soporta ZFS, esta es una herramienta que nunca he usado en el pasado de manera seria así que prefiero LVM que tiene años disponible en las distribuciones Linux.

En cada máquina virtual para Kubernetes agregue dos discos, uno para el sistema operativo y otro para almacenamiento que ahora será usado en su totalidad con Linstor.

Lo primero es preparar el disco físico para ser usado en LVM.

pvcreate /dev/sdb

Luego creamos un volumen group (vg).

vgcreate kube /dev/sdb

He seleccionado kube para que sea el nombre del Volume Group.

Procederemos a crear un thin pool, esto nos permitirá crear volúmenes más grandes que el espacio físico del cual disponemos.

lvcreate -l 100%FREE --thinpool kube/lvmthinpool

Una vez realizados estos pasas en cada nodo que aportara almacenamiento al cluster, volvemos al controller para crear un storage-pool.

linstor storage-pool create lvmthin kube1 linstor-pool kube/lvmthinpool
linstor storage-pool create lvmthin kube2 linstor-pool kube/lvmthinpool
linstor storage-pool create lvmthin kube3 linstor-pool kube/lvmthinpool

validamos que nuestro storage-pool fue creado.

linstor storage-pool list

Debemos recibir lo siguiente:

Listo, ya contamos con una plataforma para provisionar almacenamiento a Kubernetes, lo interesante es que también podría provisionar almacenamiento a otras plataformas tales como Proxmox.

Kubernetes – que necesitamos?

Para habilitar que Kubernetes pueda usar almacenamiento proveniente de Linstor, debemos contar con el plugin CSI y crear StorageClass, recomiendo tener una versión de Kubernetes mínimo 1.13 para que todo funcione bien ya que ahí plugins que no están habilitados por defecto antes de esta versión. Al momento de crear los CRD estos fallaban con un mensaje que especificaba la falta de CSINodeInfo, actualizando RKE a 1.14.6 se resolvió.

Instalaremos todo lo necesario para usar Linstor usando esta línea la cual descargar la versión 0.7.2 del CSI y usando sed estamos cambian un valor de ejemplo por el controlador de Linstor que en mi caso es 172.22.35.25. Esto debe ser ejecutado en la misma maquina de donde administramos k8s.

curl https://raw.githubusercontent.com/LINBIT/linstor-csi/v0.7.0/examples/k8s/deploy/linstor-csi-1.14.yaml | sed "s/linstor-controller.example.com/172.22.35.25/g" | kubectl apply -f -

Podemos ver el avance del de la instalación con:

watch kubectl -n kube-system get all

Procederemos a crear un Storage Class usando este yaml

El número de réplicas debe ser el número de nodos de Kubernetes.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor
provisioner: linstor.csi.linbit.com
parameters:
  autoPlace: "3"
  storagePool: "linstor-pool"

Para este punto ya podemos hacer solicitudes de volúmenes usando un PresistentVolumeClaim

En mi caso ya tenia varios yaml con requerimientos de pvc, aquí uno.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: services
  name: adguard-config
spec:
  storageClassName: linstor
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
       storage: 2Gi

Podemos ver que el STATUS es Bound, esto quiere decir que satisfactoriamente Linstor asigno espacio a Kubernetes para este volumen.

Desde el punto de vista de Linstor usando

linstor volume list

Podemos ver lo siguiente:

Estos son todos los volúmenes que están siendo usados por contenedores en Kubernetes.

Listo!

Ya puedo usar el cluster de Kubernetes, bueno por la cantidad de volúmenes que se ven en la imagen se puede deducir que lo estoy usando. He movido varios servicios hacia el clúster y hasta ahora muy feliz con Kubernetes.

El próximo paso es los respaldos, para esto estaré usando Velero de Heptio/VMware.

 

LACNIC31 – dia 4

LACNIC31 – dia 4

Hemos tenido otra sesión de discusión sobre políticas las cuales se busca que sean aceptadas mediante consenso, vuelvo y repito, esto es un tema el cual no quiero abordar sin tener cierto conocimiento de como es el proceso de aplicación y aprobación de estas, más adelante será.

https://www.lacnic.net/3635/49/evento/agenda-lacnic-31#miercoles-fpp

A las 11:30 inicio el FTL (Foro Técnico de LACNIC), recomendado para todos aquellos apasionados a las tecnologías como yo.

Aquí una lista de los temas presentados en el FTL y un pequeño comentario personal:

Introducción Foro Técnico de LACNIC

Esta es la presentación y que pasa en el FTL, también aprovecharon para invitar a otros a que participen en esta iniciativa de LACNIC.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/presentacion-ftl-2019.pdf

Video: https://youtu.be/ZGkDtoqvAIk

Problemas de seguridad del mundo real en una nube pública

Muchos de los problemas presentados aquí son conocidos y si no me equivoco existen implementaciones para mitigar ataques ya sean internos o externos, siendo los ataques internos (otro tenant o un empleado furioso) los más difíciles de detectar.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/charliekaufman.pdf

Video: https://youtu.be/HyGqL5YIfxc

UpDown RPKI LACNIC

Super interesante presentación sobre la funcionalidad UpDowm de RPKI, necesito investigar un monto sobre y esto y de posibles automatizaciones con BIRD y RouterOS que son las plataformas de enrutamiento que actualmente estoy usando.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/12-updown_rpki_lacnic.pdf

Video: https://youtu.be/RP6ePaLcp-Q

Juntos es posible, el paradigma de compartir los costos

Una presentación la cual me deja pensando y me apena, aquí podemos ver como se logra completar un proyecto que aporta a una nación de manera gigantesca, un IXP es parte de la infraestructura necesaria para que un país pueda sostenerse en caso de incidentes que afecten enlaces internacionales, lamentablemente, en RD tenemos poco interés en resolver este tema.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/63-juntos.pdf

Video: https://youtu.be/2QveRcIPOCw

Automatización de listas de prefijos en peering BGP – Cómo hacerlo y su importancia

Excelente presentación donde nos muestran herramientas para crear de manera automática las listas que usaremos en los filtros de BGP y así poder controlar anuncios recibidos por ASN conectados al nuestro. Usando IRR como fuente de información se crean listas para permitir que una subred sea anunciada a otros o aceptadas por nosotros mismos.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/48-lacnic31-douglasfischer_automatizacaodelistasdeprefixosbgp.pdf

Video: https://youtu.be/qBD7zCnbTF4

Privacidad en DNS

Esta demostrado que cada día la información generada por un computador es de mucho valor para terceros, soy muy participe de exponer lo mínimo de mi información personal al Internet, muchas veces se expone esta información de manera voluntaria, pero en otras ocasiones somos víctimas de técnicas para colectar dicha información.

Estas técnicas son desconocidas por muchas personas y es difícil entender porque deben hacer cambios en sus redes si todo esta funcionando bien. Personalmente no utilizo DNS de terceros, esta presentación me da mas razones para seguir corriendo mis propios DNS y apunarlos a los root zones sin necesidad de un resolver de una entidad la cual puede usar mi información para sacar beneficios.

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/fgont-lacnic-ftl2019-dns-privacy-final.pdf

Video: https://youtu.be/Gq_QHu8mCQs

Servicios de información de RIPE NCC para operadores

Desde hace alrededor de dos anos estoy usando varias herramientas de RIPE NCC, una de estas es RIPE Stats ( https://stats.ripe.net ), mucha información interesante desde el punto de vista curioso y mucho mas del punto de vista técnico.

https://stat.ripe.net/AS207036#tabId=at-a-glance

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/lacnic-31-en_comms-3.pdf

Video: https://youtu.be/cpIQOaA4bI0

BSDRP – Una opción de softrouter con FRR

Este es un viejo conocido y mucho mas aun porque esta basado en el sistema operativo que mas me ha gustado en todo el tiempo que he usado OpenSource, FreeBSD.

BSDRP es un proyecto fundado por la misma persona que una vez trabajo en FreeNAS. Este señor es un maestro en los equipos de embebidos.

Algo que tenia ganas de preguntar es porque uso FRR y no BIRD, no quería montar un flame-war 😊

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/4-bsdrp-lacnic31.pdf

Video: https://youtu.be/8DdtN_fj_uQ

RIPE Atlas Anchors en Máquinas Virtuales

Atlas, una plataforma que aporta un montón para un operador de redes, lamentablemente en RD ahí poco compromiso con este tipo de iniciativa.

Hace más de dos años que tengo un corriendo detrás de mi ASN (AS207036), he solicitado otro para ponerlo detrás de CLARO (AS6400).

https://atlas.ripe.net/probes/?search=&status=&af=&country=DO

Aquí se pueden ver los desplegados en DO y la gran cantidad de probes abandonados.

https://atlas.ripe.net/probes/28779/ – aaNetworks Probe – parece que tener que renombrarlo a Probe1

Presentación: https://www.lacnic.net/innovaportal/file/3635/1/ripe-atlas-virtual-machine-anchors-lacnic-31_last.pdf

Video: https://youtu.be/A7AvGVayQAA