Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

215
Views
La actualización continua de Kubernetes/EKS provoca tiempo de inactividad

Tenemos la siguiente configuración para nuestro servicio que se implementa en EKS, pero provoca un tiempo de inactividad de aproximadamente 120 segundos cada vez que realizamos una implementación.

Puedo realizar correctamente solicitudes al nuevo pod cuando lo reenvío directamente, por lo que el pod en sí parece estar bien. Parece ser el AWS NLB que no está enrutando el tráfico o algo relacionado con la red, pero no estoy seguro y no sé dónde depurar más para esto.

Intenté algunas cosas sin éxito: agregué readinessProbe , intenté aumentar initialDelaySeconds a 120 , intenté cambiar a un objetivo IP ELB, en lugar de un tipo de objetivo ELB de instance , intenté reducir el intervalo de verificación de estado de NLB pero en realidad no se está aplicando y queda como 30s.

¡Cualquier ayuda sería muy apreciada!

 --- # Autoscaler for the frontend apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: my-frontend spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-frontend minReplicas: 3 maxReplicas: 8 targetCPUUtilizationPercentage: 60 --- apiVersion: apps/v1 kind: Deployment metadata: name: my-frontend labels: app: my-frontend spec: replicas: 3 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate selector: matchLabels: app: my-frontend template: metadata: labels: app: my-frontend spec: containers: - name: my-frontend image: ${DOCKER_IMAGE} ports: - containerPort: 3001 name: web resources: requests: cpu: "300m" memory: "256Mi" livenessProbe: httpGet: scheme: HTTP path: /v1/ping port: 3001 initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 10 readinessProbe: httpGet: scheme: HTTP path: /v1/ping port: 3001 initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 10 restartPolicy: Always --- apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-cert: ${SSL_CERTIFICATE_ARN} service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https" service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true" service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "10" service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true" service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60" name: my-frontend labels: service: my-frontend spec: ports: - name: http port: 80 targetPort: 3001 - name: https port: 443 targetPort: 3001 externalTrafficPolicy: Local selector: app: my-frontend type: LoadBalancer
over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Lo más probable es que esto se deba a que NLB no reaccionó lo suficientemente rápido a los cambios de destino, lo que está directamente relacionado con la configuración de su externalTrafficPolicy .

Si su aplicación no hace ningún uso de la IP del cliente, puede configurar externalTrafficPolicy en ClusterIP o dejarlo predeterminado eliminándolo.

En caso de que su aplicación requiera preservar la IP del cliente, puede usar la solución discutida en este problema de github que, en resumen, requiere que use la implementación azul-verde .

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!