Pero a que estas atacando? Piensa que tienes que acceder a través del ingress controller, y esto significa que tienes que atacar al servicio del ingressController.
Lanza el curl contra la IP publica del LoadBalancer
#31 Claro, estaba atacando a grafana desde nginx. Los curls no los hago desde mi PC, los hacía desde dentro del POD de nginx. Haciendo curl al NGINX recibo perfectamente el 502.
El nginx en los logs ataca al pod de grafana y no es capaz de alcanzarlo. El tema que eso debería gestionarlo Kubernetes no? Utilizarán su API para hablar entre PODs...
#32 Si deberian, lanza un kubectl get endpoints a ver si ese servicio de grafana tiene como endpoint el pod de grafana
Despues lanza un curl al servicio de Grafana a ver si esta funcionando como deberia
PS C:\Users\X> kubectl get endpoints -n monitoring
NAME ENDPOINTS AGE
alertmanager-operated 10.244.0.3:9094,10.244.0.3:9094,10.244.0.3:9093 19h
kube-prometheus-stack-1643-alertmanager 10.244.0.3:9093 19h
kube-prometheus-stack-1643-operator 10.244.0.2:10250 19h
kube-prometheus-stack-1643-prometheus 10.244.0.5:9090 19h
kube-prometheus-stack-1643570798-grafana 10.244.0.2:3000 19h
kube-prometheus-stack-1643570798-kube-state-metrics 10.244.0.4:8080 19h
kube-prometheus-stack-1643570798-prometheus-node-exporter 10.0.10.133:9100,10.0.10.205:9100,10.0.10.218:9100 + 1 more... 19h
prometheus-operated 10.244.0.5:9090 19hEl endpoint es 10.244.0.2:3000 y el curl desde nginx devolvía:
bash-5.1$ curl -k -v http://10.244.0.2:3000
* Trying 10.244.0.2:3000...
* connect to 10.244.0.2 port 3000 failed: Host is unreachable
* Failed to connect to 10.244.0.2 port 3000 after 3078 ms: Host is unreachable
* Closing connection 0
curl: (7) Failed to connect to 10.244.0.2 port 3000 after 3078 ms: Host is unreachable
No sé... quizás como están en diferentes nodos sea la subnet del load balancer, pero todos estos paquetes deberían ir por la API que está permitido por defecto por Oracle. Es más, he ido permitiendo todo el tráfico en cada subnet por si acaso.
#35 Creo que has acertado de pleno, no sé como no miré antes ....
Readiness probe failed: Get "http://10.244.1.130:8181/ready": dial tcp 10.244.1.130:8181: i/o timeout (Client.Timeout exceeded while awaiting headers)Edit: ahora en algún punto, el paquete lo "dropean" porque no recibo respuesta del curl:
bash-5.1$ curl -k -v http://10.86.65.70:80
* Trying 10.86.65.70:80...
* connect to 10.86.65.70 port 80 failed: Operation timed out
* Failed to connect to 10.86.65.70 port 80 after 130311 ms: Operation timed out
* Closing connection 0
curl: (28) Failed to connect to 10.86.65.70 port 80 after 130311 ms: Operation timed outEdit: teóricamente kubernetes muy top, pero menudo trabajo...
Edit 2: Nada, me cansé y empecé literalmente de 0 borrando el clúster. Hice el deploy con los cambios que indiqué antes, y ahora todo ha funcionado a la primera....
Gracias por la ayuda #35
#36 tenías tostado coredns, y probablemente calico también, por tanto el cluster estaba tostado a nivel de networking.
Es un problema raro, pero oye, si ya está solucionado me alegro
#2 #3 Ahora que tengo Kubernetes montado y aparentemente estoy entiendo su funcionamiento, aprovecho para preguntar:
Tengo dos opciones:
- Crear un volumen en el nodo y simplemente tener la BD en el nodo como lo tengo ahora, pero dentro de un container.
- Crear un volumen compartido
En el segundo caso:
- La BD actual (Postgresql) si creo un pods, con su servicio necesitaría un volumen persistente en caso que falle un nodo cualquiera tenga acceso a la BD correcto?
- Lo mismo con la web, entiendo que necesito otro volumen persistente.
Quizás, sea algo excesivo este nivel de redundancia
Directamente no soy partidario de albergar bases de datos en pods, sobretodo si son base de datos críticas
#40 Sí, creo que es algo con lo que tener mucho cuidado. El tema que la BD lo ideal sería que fuera accesible por el clúster, de forma que puedo repartir todos los procesos que ejecuto en diferentes hosts. Podría añadir servidores de diferentes ubicaciones etc...
Y si encima, kubernetes me gestiona los enlaces entre nodos es algo que simplifica bastante una vez montado...
Ahora mismo, todo lo principal está en dos hosts porque tengo dos BD replicadas...
Host A. Base de datos principal donde se hacen todas las escrituras., se ejecutan los scripts de Python, etc...
Host B. Base de datos secundaria donde se replica y está la web etc...
El Host B puede escribir en la DB del Host A.
#39 ojo que montar bbdds en pods es algo más complicado de lo que parece.
Vamos por partes, lo primero es que si necesitas almacenamiento persistente dentro de un pod, si o si necesitas crear un Persistente Volume Claim (PVC) del tipo que tú necesites (no te recomiendo nunca utilizar espacio del nodo, si no que utilices los tipos de almacenamiento que te da el Cloud provider, algún tipo de block storage tendrá Oracle)
Por tanto, si quieres crear un cluster de Postgres, necesitarías al menos un PVC para la instancia primaria y otra para la standby o read-replica.
Si el pod del frontend necesita también almacenamiento persistente pues lo mismo, un PVC del tipo que necesites.
Por otro lado, si quieres crear cosas más complejas que levantar un simple por de Postgres, échale un ojo a Helm, que hará toda tu vida muchísimo más sencilla en este sentido.
Mi duda es que pasa si un pod pasa del host A al B. Mi experiencia con AWS, es que los PVC son EBS, y si pasa eso, el solito hace attach al nodo donde se levanta el pod y, si es en la misma AZ; aquí no pasa nada.
Pero no sé donde tiene montado el cluster de k8s
#44 En ese caso, solo has de preocuparte de crear un Persistent Volume con su Persistent Volume Claim y attach al pod
Como te han dicho con PVC te vale, eso si yo tiraría de servicios que te diera el cloud provider lo maximo posible (bds, load balancers, certificados, etc)
#45 #46 Perfecto, lo único que mi estructura ahora mismo es al siguiente:
Actual:
1x VPS (Host A), servidores de 8 cores y hace escrituras constantes a la DB. Servidor que contiene la DB.
1x VPS (Host B), servidor de 6 cores y hace lecturas en la DB de replica (suya) y muy pocas escrituras en la DB primaria (Host A)
Lo nuevo:
4x Nodos de Oracle que los dejaré en 3 nodos ya que así aprovecho su capa gratuita. Estos nodos son muy básicos, poca potencia. Aquí debería mover la web y quizás la Base de datos porque es la única forma que tengo de hacer uso del PVC en Oracle. La contra que tendría que hacer todas las escrituras a través de red externa (Host A hacia al clúster).
Entonces creo que lo simple es meter en un contenedor la DB y dejarlo como está ahora mismo en el Host A... Podría plantear la secundaria en el clúster de Oracle...
Tengo tantos cambios pendientes que ya no sé que es lo más conviene...
Tengo varios pods que actúan como proxies de la siguiente forma:
El fichero que define el servicio y pod:
apiVersion: v1
kind: Service
metadata:
name: squid-service
labels:
app: squid
spec:
type: NodePort
ports:
- port: 3128
targetPort: 3128
nodePort: 31280
selector:
app: squid
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: squid-deployment
spec:
selector:
matchLabels:
app: squid
template:
metadata:
labels:
app: squid
spec:
containers:
- name: squid
image: ubuntu/squid:edge
ports:
- containerPort: 3128
name: squid
protocol: TCP
volumeMounts:
- name: squid-config-volume
mountPath: /etc/squid/squid.conf
subPath: squid.conf
- name: squid-data
mountPath: /var/spool/squid
volumes:
- name: squid-config-volume
configMap:
name: squid-config
items:
- key: squid
path: squid.conf
El problema que me conecto a los pods por la IP del nodo y su puerto, esperando que ahora mi IP sea la IP del Nodo (proxy) al que me he conectado, pero me devuelve la IP de un Nodo aleatorio....
Vamos que el servicio está asignandome el pod erróneo...
¿Creo servicios independientes? ¿Hay algo mal en la definición del servicio?
PD: ¿Quizás sea por los labels que no son dinámicos?
Edit: Lo he solucionado creando 4 servicios y 4 deployments independientes. No hay otra alternativa que haya podido encontrar
#48 los servicios, sean del tipo que sean hacen balanceo de carga entre sus endpoints. Por tanto, si tienes un servicio para todos los pods del daemonset, cada vez te redirigirá contra el que vea conveniente
#48 no se si te he entendido. Quieres que un cliente vaya a un nodo, y sus posteriores peticiones siempre vayan a ese mismo nodo? Si es así, lo que buscas es sticky session
#50 Sí, pero sabiendo lo que ha comentado #49 directamente hice un servicio para cada nodo etc... Así, tengo 4 servicios independientes con sus correspondiente endpoint y deployment + replicaset (1). Al ser un proxy, no tiene sentido que se balancee a otros nodos si falla y me quiero conectar al que yo decida desde el otro extremo.
#51 es una solución, pero huele bastante raro que debas crear un nuevo endpoint + service + deployment por cada nodo, no es la mejor forma de escalar 
por ejemplo, y si se cae uno de los 4 nodos? ese endpoint deja de dar servicio
#51 Lo que te ocurre es que no lo estas haciendo "The kubernetes way". Me explico:
Tu desde un pod de Kubernetes puedes (asignandole una ServiceAccount con permisos) atacar a la api de kubernetes y obtener todos los endpoints que hay bajo un determinado servicio. Esto es lo ideal porque si mañana metes mas nodos, esto se escala automaticamente al ser un DaemonSet. Obteniendo la info de los endpoints de la API de k8s puedes atacar directamente al clusterIp de los pods, que entiendo que es lo que necesitas hacer.
Lo que no me queda claro es porque quieres acceder a los NODOS.
#52 Correcto, si se cae un nodo adiós endpoint etc... Al final, no aprovecharía las posibilidades que da Kubernetes. Sufría lo mismo que teniendo un simple contenedor de docker o un servicio en linux.
#53 Claro, efectivamente eso sería lo ideal pero sin balanceo a menos que hubiera una perdida de un Nodo. En mi caso concreto, tengo varios proxies por lo que me interesa que cada Pod esté en un nodo para tener una IP pública diferente, y salir por ese Nodo. En caso que fallase uno de los Nodos, podría plantearse que se migrase el Pod y salir por en Load Balancer (IP extra) en vez del Nodo en que resida el Pod migrado.
Quizás, no me explique correctamente con el 'acceder'. Necesito salir por el nodo que yo prefiera, a menos que haya una caída de uno de los nodos -> Load Balancer. Un servidor A se comunica con 3 nodos y necesita 3 IPs diferentes, lo que significa que debo conectarme a 3 pods que estén ubicados en nodos diferentes.
#54 no entiendo porque necesitas salir por una IP u otra. Es decir, entiendo que necesitas un egress, pero te estás montando un egress por nodo, lo cual es absurdo ya que si sales directamente desde el pod de la app ya sales con la IP del nodo.
Si lo que necesitas es salir siempre con la misma IP, pues levanta el proxy con condiciones de Affinity para que levante siempre en un mismo nodo(o grupo de nodos) y gestiona las reglas de acceso en base a esos nodos
no se en que plataforma estas trabajando, pero quizás podrías estudiar tener varias gateway NAT, y que cada pod pille la NAT que deba
#55wdaoajw:directamente desde el pod de la app ya sales con la IP del nodo
Y esto es lo que está pasando ahora mismo. Necesito 1 pod en cada Nodo, de ahí que ahora tenga 1 servicio 1 pod 1 endpoint por Nodo.
Antes tenía el DaemonSet, pero el servicio me daba el pod que le diese la gana. Necesito saber que estoy atacando a un proxy/pod concreto.
Partimos del principio y explico mi situación. Tengo 2 scripts cada uno se conecta a un proxy (pod) porque necesito 2 IPs diferentes. Ahora tengo montado 2 pods, 2 servicios y 2 endpoints. Ahora mismo está perfecto, pero si falla un Nodo pues pierdo el pod y no tengo replica ni nada.
La mejora sería que se crease un nuevo pod y me diera la IP del Load Balancer o la del otro Nodo (no es ideal, pero me serviría), claro que mi script estaría llamando a la IP del Nodo caído, por lo que independientemente de lo que haga en el clúster, el script seguiría preguntando a la IP del nodo caído (esto lo puedo solucionar desde el lado del script, obviamente).
No sé si me he explicado.
#56 No creo que pueda hacer eso
#57 Pero las dos IPs por las que sales necesitas que sean fijas? Es indiferente el salir por una o por otra?
#58 No es indiferente. Necesito salir siempre por la misma que haya elegido, siempre deben ser fijas.
#59 En ese caso lo ideal seria que te hicieras con un par de IPs publicas fijas del cloud provider, se las asignaras a 2 instancias y salieras a través de ellas.
