Hi I have question about golang micro service via kubernetes container. Example I have 2 deploy of code name A and B.

1. A have 1 pod do a sent request to create document in B service.
2. B have autoscaling config between 1 - 5 pod waiting for request from A and process to create a document in many collection.

Sometime service A have error "EOF" from service B and I go to check log in service B couldn't find error that makes pod terminate or crashloopbackoff status from kubectl terminal it like service B just stop running this process.

I wonder cause of error "EOF" is about autoscaling config in B service in my understanding high traffic to B service have to scale up pod to 5 pod but when traffic go down pod must scale down too.

It is possible if any process working in pod that would to scale down it terminated before process success?

CodePudding user response：

When pods are terminated (due to scale down), they receive a term signal and are deregistered from the load balancer. The problem in your case might be, that running processes are terminated imediatelly and connections get closed. You can try to circumvent the problem with a preStop lifecycle hook for your container, i.e. give your running processes time to finish before the pod gets terminated.

  lifecycle:
    preStop:
      exec:
        command:
          - "sleep"
          - "10"

With this hook, on scale down the pod will be deregistered from the load balancer imediately, preventing it from receiving further requests, and the preStop lifecycle hook will be executed. In this case it just waits 10 seconds. Only after the hook is finished, the container will receive the term signal.

https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

CodePudding user response：

Make sure your service B can do a graceful shutdown.

On scale down, or delete, the pod will first receive a TERM signal. Then, after a grace period, it will send a KILL if needed.

Your service should respect TERM and stop all internal processes (goroutines in your case) and then terminate. If you manage there will be no need for a KILL signal.

It's described in the Pod Lifecycle documentation