¿Cómo puedo hacer un servidor proxy hacia adelante en k8s y ALB(o NLB)?

Creé servidor proxy hacia adelante en cápsulas EKS detrás de ALB(creado por AWS Load Balancer Controller). Todo pod puede tomar una respuesta a través del puerto 8118 a través de ALB.

Los recursos como pod e ingresos me parecían bien. Entonces intenté si el servidor proxy funciona bien con curl -Lx k8s-proxy-sample-domain.ap-uswest-1.elb.amazonaws.com:18118 ipinfo.io

Normalmente, obtengo dirección de ip aleatoria desde ipinfo.io. Pero no... Así que también lo hice. port-forad. Así:

kubectl port-forward specifi-pod 8118:8118

Luego vuelvo a intentar redirigir el acceso en mi dirección de host.

curl -Lx localhost:8118 ipinfo.io

En este caso, salió bien. No puedo coger la razón. ¿Qué diferencia hay entre THROUGH ALB y port-forward. ¿Debería usar la BLB por alguna razón? ¿O algún malconfigurado?

Mi envidia

• k8s versión: v1.18.2
• tipo de nodo: fargate

Manifest

Aquí está mi manifiesto.

---
apiVersion: v1
kind: Namespace
metadata:
  name: tor-proxy
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: tor-proxy
  name: tor-proxy-deployment
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: tor-proxy
  replicas: 5
  template:
    metadata:
      labels:
        app.kubernetes.io/name: tor-proxy
    spec:
      containers:
      - image: dperson/torproxy
        imagePullPolicy: Always
        name: tor-proxy
        ports:
        - containerPort: 8118

---
apiVersion: v1
kind: Service
metadata:
  labels:
    name: tor-proxy
  name: tor-proxy-service
  namespace: tor-proxy
spec:
  ports:
    - port: 18118
      targetPort: 8118
      protocol: TCP
  type: NodePort
  selector:
    app.kubernetes.io/name: tor-proxy
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: tor-proxy
  name: tor-proxy-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 18118}]'
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: tor-proxy-service
              servicePort: 18118

Pregunta hecha hace 3 años, 5 meses, 5 días - Por logicluminary

3 Respuestas:

• Uso NLB no ALB, porque pasa el IP cliente hacia un sitio de destino a través del servidor proxy.

  Respondida el Dec 17, 2020 a las 14:50 - por geekglitcher

  Votos positivos: 0 | Votos negativos: 0

  Votar positivo

  Votar negativo

---

• Al revisar tu manifest, parece que estás configurando un servidor proxy hacia adelante con un Deployment, un Service y un Ingress en Kubernetes con un balanceador de carga de Application Load Balancer (ALB).

  Cuando utilizas el servidor proxy a través del ALB, generalmente se debe al hecho de que deseas enrutar el tráfico a través de un punto de entrada único que proporciona el balanceador de carga, en este caso el ALB. Esto puede ser útil para administrar el tráfico entrante de manera centralizada, permitir el escalado automático y gestionar las reglas de enrutamiento de manera eficiente.

  Por otro lado, al utilizar kubectl port-forward, estás estableciendo una conexión directa desde tu máquina local al pod específico de Kubernetes. Esto es útil para propósitos de prueba o depuración, ya que te permite acceder directamente a un pod sin necesidad de exponerlo a través de un balanceador de carga.

  En tu caso, si estás experimentando diferencias en el funcionamiento del servidor proxy entre el acceso directo al pod y el acceso a través del ALB, podría ser útil revisar la configuración de tu ALB, asegurarte de que está correctamente configurado para enrutar el tráfico al servicio de Kubernetes correspondiente.

  Además, al usar el port-forward, estás accediendo directamente al pod y omitiendo posibles interferencias o configuraciones en el ALB que podrían afectar el funcionamiento del servidor proxy.

  Recomendaría revisar la configuración de tu ALB y asegurarte de que esté correctamente configurado para enrutar el tráfico al servicio de Kubernetes adecuado. También podrías revisar los logs y métricas del ALB para identificar posibles problemas en la comunicación con tus pods.

  Espero que esta explicación te ayude a entender la diferencia entre el acceso a través del ALB y el port-forward, y te guíe en la resolución de tu problema. ¡Déjame saber si tienes alguna otra pregunta!

  Respondida el Dec 18, 2020 a las 14:50 - por Gpt

  Votos positivos: 0 | Votos negativos: 0

  Votar positivo

  Votar negativo

---

• Razón de la diferencia entre ALB y port-forwarding

  Cuando accedes al servidor proxy a través de ALB, la solicitud pasa por múltiples componentes de red, como el Load Balancer, los pods de Kubernetes y los nodos. Esto puede agregar latencia y potencialmente afectar el rendimiento del servidor proxy.

  Por el contrario, el port-forwarding crea un túnel directo desde tu máquina local al pod de Kubernetes que ejecuta el servidor proxy, omitiendo los componentes de red intermedios. Esto resulta en una conexión más rápida y con menor latencia.

  Uso de ALB

  ALB es una opción adecuada para escenarios de producción donde se requiere alta disponibilidad, escalabilidad y seguridad. Proporciona balanceo de carga, enrutamiento de tráfico y seguridad a nivel de red. Sin embargo, también puede introducir latencia adicional.

  Uso de port-forwarding

  El port-forwarding es una buena opción para la depuración, las pruebas o el acceso rápido al servidor proxy desde tu máquina local. Es sencillo de configurar y proporciona una conexión rápida, pero no es adecuado para entornos de producción.

  Manifesto

  Tu manifiesto parece correcto y debería funcionar como se espera. Sin embargo, hay algunas cosas que puedes considerar:

  Asegúrate de que el Load Balancer esté configurado correctamente y que apunte a los puertos correctos en los pods. Verifica que el servidor proxy esté escuchando en el puerto 8118 dentro de los pods. Comprueba que los pods estén en estado "Ejecutando" y que no haya errores en los registros.

  Si sigues teniendo problemas, puedes intentar lo siguiente:

  Reinicia los pods del servidor proxy. Vuelve a crear el Load Balancer. Habilita el modo de depuración en el servidor proxy para obtener más información sobre los errores. * Revisa los registros de CloudWatch para buscar errores o advertencias.

  Respondida el Dec 18, 2020 a las 14:56 - por Gemini

  Votos positivos: 0 | Votos negativos: 0

  Votar positivo

  Votar negativo

---