<p>I’m curious how to approach an upgrade/reboot situation with an application consuming messages from a Google Pub/Sub.</p>
<p>For example I am particularly interested in developing a Golang application that is deployed in Kubernetes running multiple pods and consumes messages form a Google Pub/Sub. My concern is how can I ensure there are no messages missed (or processed twice) while a pod is being upgraded.</p>
<p>I understand the application would read the message from the subscription and then must acknowledge it has received it. I feel there may be a race condition between acknowledging the message and the pod shutting down to upgrade?</p>
<p>I know doing something similar is possible with a Dataflow job as you can stop a streaming job and signal it to drain the messages.</p>
<p>I assume there has to be someway to handle this gracefully, or is this really a situation where Dataflow is better suited?</p>

<p>Kubernetes uses SIGTERM, waits 30 seconds, then SIGKILL. This gives your application an appropriate amount of time before completely killing it, which you can tweak using the <code>terminationGracePeriodSeconds: 60</code> field if the 30 second default is not enough (link 1).</p>
<p>You then need to add logic in your Golang to receive the SIGTERM signal (link 2).</p>
<p>Lastly, assuming your queue is rabbit here (but other queue's will have similar functioanlity), on receipt of a SIGTERM, you can write logic to A) Stop receiving new messages and then B) (this is optional, you could just let them finish) return an NACK and Requeue signal for all messages that the pod currently has ack'd but not finished, putting the messages back (link 3 and 4).</p>
<p>If you can avoid having to implement NACK/Requeue, and just handle SIGTERM by closing your queue listener and finishing the remainder of currently held messages (and say 30 or 60 seconds is sufficient to do so), that is much simpler and recommended.</p>
<ol>
<li><p><a href="https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace" rel="nofollow noreferrer">https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace</a></p>
</li>
<li><p><a href="https://stackoverflow.com/questions/18106749/golang-catch-signals">Golang catch signals</a></p>
</li>
<li><p><a href="https://stackoverflow.com/questions/28794123/ack-or-nack-in-rabbitmq/28817796">Ack or Nack in rabbitMQ</a></p>
</li>
<li><p><a href="https://www.rabbitmq.com/nack.html" rel="nofollow noreferrer">https://www.rabbitmq.com/nack.html</a></p>
</li>
</ol>
<h2>** Edit **</h2>
<p>For google cloud pub/sub, you can also send an Nack.</p>
<p><a href="https://pkg.go.dev/cloud.google.com/go/pubsub#Message" rel="nofollow noreferrer">https://pkg.go.dev/cloud.google.com/go/pubsub#Message</a></p>
<p>&quot;Ack indicates successful processing of a Message. If message acknowledgement fails, the Message will be redelivered. Nack indicates that the client will not or cannot process a Message. Nack will result in the Message being redelivered more quickly than if it were allowed to expire.&quot;</p>
