來源:Zero-Downtime Rolling Deployments in Kubernetes | Rakuten Engineering Blog
以下是摘錄。
在刪除掉 Pod 之前,流量還是會導向 Pod,要處理這種狀況,就需要去處理 SIGTERM。
文章建議三種方法。
- 在 pre-stop hook 裡用 sleep
- 延遲應用程式中止
- 動態延遲應用程式中止
在 pre-stop hook 裡用 sleep
spec:
terminationGracePeriodSeconds: 60
containers:
- name: "{{APP_NAME}}"
lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","sleep 20"]
缺點,sleep 的時間是要去測量跟估算的,每個應用程式不同。而且,pre-stop 的主要用途不是用來做這事情的。
延遲應用程式中止
這個是要改應用程式的程式碼。
這裡有舉一個 wrapper script 的例子
#!/bin/bash
HAPROXY_PID=-1
# wait for 10 seconds, then send a USR1 signal to HAproxy
kill_haproxy(){
sleep 10
kill -USR1 $HAPROXY_PID
}
# invoke kill_haproxy function when receives the TERM signal
trap kill_haproxy SIGTERM
# Support the user hitting Ctrl-C, but only in interactive shells
if [[ -t 1 ]] ; then
trap 'kill -USR1 "$HAPROXY_PID"' SIGINT
fi
haproxy -f config.cfg & HAPROXY_PID=$!
if [ -z "$HAPROXY_PID" ]
then
echo "haproxy: Haproxy failed to start"
else
echo "haproxy: haproxy started"
fi
在 Dockerfile 就這樣用
FROM alpine:3.5
# install bash, tini and haproxy
RUN apk add --no-cache bash tini haproxy=2.0.14-r0
# Run tini
ENTRYPOINT ["/usr/local/bin/tini", "—"]
CMD ["/launcher.sh"]
缺點跟前者差不多。
動態延遲應用程式中止
這個說不一定可用,就跳過了。
結論
好好處理 SIGTERM 。
沒有留言:
張貼留言