#81 La verdad es que mv saca a veces algunas herramientas que son muy top y no muy conocidas.
1 mes después
Tengo una duda de SRE y troubleshooting.
- Tengo un ALB, y un ELB en AWS.
- Me esta devolviendo el ELB 5xx.
- Miro los logs de mis servicios y nadie esta generando los 5xx. Es decir, el problema esta en el ELB.
Estos logs donde los puedo encontrar? Mi follow up question seria como integrar estos logs en algo como elastic.
Se leer la docu (https://docs.aws.amazon.com/es_es/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html) pero pregunto por como troubleshootear los problemas concretos. En este caso esos 500s.
#92 En la interfaz de CloudWatch deberías ver si esta haciendo 5xx.
https://REGION.console.aws.amazon.com/cloudwatch/home?region=REGION#metricsV2:graph=timezone'UTC;namespace='AWS*2fELB
(cambia REGION)
Para el follow up tal vez esto te pueda servir
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html#load-balancer-metrics-alb
https://www.elastic.co/es/blog/monitoring-aws-services-using-the-cloudwatch-metricset
#93 Good... En Cloudwatch veo que son todo 504. Ya vi donde esta el problema... un mini ddos de 1 minutos.
Creo que me faltan metricas en mi gateway. Porque veo que tengo las request de elb => gateway, y veo el spike de requests, pero solo el elb ha sacado los 504. Un par de instancias se han quedado colgadas y no podian responder y han hecho timeout...
Creo que ese timeout lo deberia poder sacar igual en mi gateway... asi tendria la metrica que quiero.
Hasta donde yo se en algunas regiones todavía se pueden crear ELB Classic, aunque no veo que beneficio te aporta teniendo los otros dos.
Por otro lado, #92 los logs de los ALB por defecto están deshabilitados, pero es posible habilitarlos desde la consola (o por comandos). Para habilitarlos, necesitas previamente disponer de un S3 ya que es donde los enviará. Los logs que genera los distribuye en ficheros de 5 minutos y por AZ. De manera que si el ALB lo tienes en 2AZ, te generará 2 ficheros cada 5 minutos.
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html
#96 Eso ya lo tengo. thx
edit: estoy haciendo chaos engineering con pumba
https://github.com/alexei-led/pumba
estoy tratando de detectar si mi contexto de propagacion http es correcto entre servicios.
1 mes después
#98 Tienes mil videos en Youtube sobre como empezar.
Por si te puede interesar, en su momento hice un minilab kuy sencillo para que fuese hands-on. Te lo dejo por aquí por si quisieses hacerlo.
https://github.com/VirtualCave/containers-lab/tree/master/Docker
#81 desde que conozco k9s sé cómo he podido vivir sin ello.
Es que no hay forma de operar un cluster de kubernetes de forma más eficiente,
Duda: Estoy muy acostumbrado a Azure, donde al crear una VNET puedes indicarle si queires usar una private DNS Zone o delegar la resolución de nombres en el DNS de tu empresa.
Sin embargo en AWS veo que puedo crear una Hosted Zone y atacharla a una VPC para la resolución de nombres, pero no veo cómo delegar la resolucion de nombres de una VPC a un servidor DNS externo (el de mi empresa por ejemplo)
#101 Jajajajaja hombre, en mi empresa sólo tocamos kubernetes como administradores yo y 3 compañeros más. Y tenemos ya años de experiencia. El punto de "cagada" está bastante acotado.
El resto usan Rancher con perfiles MUY acotados por namespace.
Por ciuerto, supongo que ya lo habeis puesto por aqui, pero este canal es ORO si quieres saber cositas de DevOps y SRE:
https://www.youtube.com/@PeladoNerd
En ingles este es otro Imprescindible:
#102 TechWorldwithNana mola pero la piva tiene una voz de maromo que chirria muchas veces. Eso si, el contenido es top
Por cierto, alguien con experiencia en EKS.
Sabeis cómo crear servicios LoadBalancer con IP predefinida?
Es decir, ahora mismo si despliego en EKS un servicio del tipo LoadBalancer te levanta uno, te da un fqdn random y una IP random. Pero si lo redespliegas te da otra IP y otro fqdn. La unica forma que tengo de prefijarla es levantar yo previamente el LoadBalander y usar TargetgroupBindings por servicio, pero me parece tosco.
El Azure creo que está mucho mejor resuelto y completa la solucion de Kubernetes (AKS).
#106 insinúas lo que creo que estás insinuando? porque yo pensaba lo mismo pero no hay nada de información en internet....
#109 a mí que me registren
#107 echa un ojo a AWS Load Balancer Controller
https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
Creo que soluciona lo que comentas.
#110 si, ese addon es justo lo que tengo instalado para poder usar TargetGroupBindings en los servicios. Pero no encontré nada para que me permitiese predefinir la IP del servicio.
#111 pero que quieres? Tener una IP estática en el LoadBalancer que te levanta AWS cuando haces deploy de un service en EKS?
#112 justo eso. En AKS cuando levantas un servico LoadBalander puedes indicarle en una annotation la IP que quieres que tenga, si no, te da una aleatoria.
No veo en EKS esa opción y no sé si es que no existe (lo cual me parece una cagada) o es que no soy capaz de encontrarla.
#113 si hablamos de IP pública, los ALB te la dan random y puede variar. Si es NLB es random pero creo que no cambia
Tampoco es un escenario que me haya preocupado, tiene un dnsname que te genera y si se prefiere un nombre más sencillo, pues se crea un registro cname en route53 atacando al dnsname del ALB y te da igual la IP
#100 Has probado Lens? Me parece mucho mejor estéticamente y muy intuitivo. No he probado k9s así que no puedo comparar, pero sí he usado Lens durante estos dos últimos años y me ha dado mucho.
#115 lo probé, pero me petardeaba un poco en el Mac.
#114 lo chungo de eso es que tengo que dar de alta la IP del LoadBalander en el DNS de mi empresa por cada dominio desplegado por los ingress.
Entonces, si tenemos un servicio Nginx expuesto por una IP y doy de alta en el DNS todos los dominios de los ingress desplegados (que pueden ser muchos), si redespliego el Nginx en un futuro por lo que sea y me da otra IP tenemos que modificar en el DNS tooodos los dominios de los ingress a la nueva IP que nos quiera dar.
No sé si me estoy explicando.
La solucion a la que he llegado es la de crear el LoadBalancer a parte yo y dar de alta los nodos del cluster por el puerto del Nginx, pero molaria que fuese más automático.
16 días después
Tengo una duda de terraform, supongo que este es buen sitio para preguntar
Estoy utilizando el move block para refactorizar una declaración de un recurso.
moved {
from = resource.old_identifier
to = resource.new_identifier
}Hay un par de apps referenciando el identificador viejo. Si yo elimino el moved antes de que esas apps se actualicen al nuevo van a petar no? Es que me está diciendo un SRE que la referencia se queda permanente en el estado de terraform y además de que no veo nada de eso en la docu no le encuentro el sentido, porque si es algo declarativo y la declaración deja de existir no entiendo por qué iba a quedarse guardado detrás de las cortinas.
p.d: joder 152 favs el hilo, disfrutad el ping 
#117 Nunca he usado el bloque move , siempre que he modificado el nombre de un recurso, he tirado de terraform state mv , pero entiendo que el efecto es el mismo.
Y, en teoría, si hacen referencia al recurso viejo, petarían. Tendrían que actualizarse esas apps apuntando a l anueva referencia.
¿Tienes un ejemplo de como hacen referencia a ese recurso viejo?
#118 es un redis al que estamos añadiendo más instancias. El recurso viejo estaba usando count y ahora se cambió para que sea un for each con su mapa de objetos.
ejemplo (me invento el path y varias cosas para simplificar)
en la declaración usábamos un count y se accedía por el índice, por ejemplo el id del recurso usado era azure.redis[0], así que para acceder al connectionstring es azure.redis[0].connectionstring
ahora al refactorizar con el foreach se queda en
azure.redis["service_A"] (recurso original)
y
azure.redis["service_B"] (recurso nuevo)
con el moved mantengo la referencia para que los consumidores no peten (y TF no destruya y regenere el recurso)
moved {
from = azure.redis[0]
to = azure.redis["service_A"]
}con ese moved no hay problema en que sigan usando azure.redis[0].connectionstring, pero en el momento en el que quite el move y haga el apply a la infra, yo entiendo (y no veo en ningún sitio nada que me diga lo contrario) que cualquier app que intente consumir azure.redis[0].connectionstring sin haberlo actualizado a azure.redis["service_A"].connectionstring petará
pero como el SRE me está diciendo que no ya no sé si le estoy entendiendo mal, se está explicando mal, él tiene la idea equivocada o soy yo el que la tiene
#119 pero el apply tendrás que hacerlo antes de quitar el moved, si no no tiene sentido. Después de hacer el apply, es cuando borras el moved.
