Category: 資訊相關Idea與筆記

新聞：k8s.gcr.io Redirect to registry.k8s.io – What You Need to Know | Kubernetes

簡單的說，k8s.gcr.io 要被關掉了，所以從 k8s.gcr.io 拉取的 image ，未來會有影響，例如砍掉 pod 以後，有可能拉不到 image 了。

所以要找出所有使用 k8s.gcr.io 的 deployment/statefulset/pod … 資源，方法有兩種。

第1種是用 kubectl 來找

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

簡單的說，就是列出所有 pod 的 YAML，取出裡面的 image ，整理過以後，列出來。

第二種是用 kubectl krew 安裝 community-images plugin

kubectl krew install community-images
kubectl community-images

使用以上其中一種方法找到以後，該怎麼辦？

接下來就是用 kubectl edit 去修改 image 位址。

若是用 gitops 或 helm 的方法，作法也相似，就是去修改 manifest yaml ，然後重新佈署就可以了。

文章來源：Pod rebalancing and allocations

簡單整理如下：

• 應用程式是 deployment，有兩個 pod
• 本來只有一個 node，兩個 pod 都會佈署在上面，所以如果一個 node 掛了，那麼應用程式就無法回應了。現在增加另外一個 node ，一般會預期 pod 移動一個到新的 node 上，但實際上 Kubernetes 不會做任何動作。

可以怎麼做？

• 用 Pod (anti-)affinity (參考：https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)
• 用 Pod topology spread constraints
• 用 descheduler

Pod affinity

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: ellery-lab
spec:
  # 省略
  template:
    metadata:
      labels:
        app: MyTestApp
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype
                operator: In
                values:
                - ssd

pod topology spread constraints

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: ellery-lab
spec:
  # 省略
  template:
    metadata:
      labels:
        app: MyTestApp
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            foo: bar

descheduler

這個是需要另外安裝的，安裝以後會在 kube-system 裏面找到，是一個 pod 。

The descheduler pod is run as a critical pod in the kube-system namespace to avoid being evicted by itself or by the kubelet

安裝完成以後，還需要設定 policy ，比較麻煩一些，但可以做到動態的處理，功能也比較多。

來源：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 。