Skip to main content

2 posts tagged with "GKE"

View All Tags

· 3 min read

GKE 環境上可以啟動 CA(Cluster-Autoscaling) 來根據資源使用量調整節點的數量,可以視為節點層級的 HPA

基本上只要節點的資源使用率過低,該節點就會被嘗試回收並且將所有的 Workload 都轉移到其他的節點

如果有特別特別重要的 Pod 希望該 Pod 能夠抑制 CA 的行為,有該 Pod 運行的節點都不能被踢除回收的話,可以於 annotations 中加入下列設定

    cluster-autoscaler.kubernetes.io/safe-to-evict: 'false'

該節點就會讓節點沒有辦法順利踢除因此最後不會回收該節點,該指令也要小心使用,若用不好可能會導致節點資源使用率過低最後產生額外的花費。

應用程式本身需要更長時間去調整 GracePeriod (預設 30 秒),可以直接修改 pod.spec.terminationGracePeriodSeconds 此欄位即可

$ kc explain pod.spec.terminationGracePeriodSeconds
KIND: Pod
VERSION: v1

FIELD: terminationGracePeriodSeconds <integer>

DESCRIPTION:
Optional duration in seconds the pod needs to terminate gracefully. May be
decreased in delete request. Value must be non-negative integer. The value
zero indicates stop immediately via the kill signal (no opportunity to shut
down). If this value is nil, the default grace period will be used instead.
The grace period is the duration in seconds after the processes running in
the pod are sent a termination signal and the time when the processes are
forcibly halted with a kill signal. Set this value longer than the expected
cleanup time for your process. Defaults to 30 seconds.

簡易 bash 腳本可以備份目前環境中的所有 secret 物件

function dump_secret {
for i in $(kubectl -n $1 get --no-headers secret | awk '{print $1}'); do
kubectl -n $1 get secret -o yaml $i > $i.yaml;
done
}

function dump_secrets {
for i in $(kubectl get ns --no-headers | awk '{print $1}'); do
if [ ! -d "./$i" ]; then
mkdir $i
fi
echo "Dump $i"
cd $i
dump_secret $i
cd ..
done
}

· 2 min read

GCP 本身有自己的 IAM roles,可以讓所有 GCP 使用者有特定的權限去存取 GKE 叢集,譬如

  1. Kubernetes Engine Cluster Admin
  2. Kubernetes Engine Cluster Viewer
  3. Kubernetes Engine Developer

然而這類型的設定卻有一些限制

  1. 沒有辦法針對 namespace 內去詳細設定
  2. 不方便針對 cluster 層級設定,譬如一個專案內若是有多個 GKE cluster,則權限會全部套用

但是這類型的操作與 gcloud 的整合非常順,可以很輕鬆的就讓所有團得人員獲得 GKE 的存取權限,進而使用 kubectl 等指令

若今天想要修改權限改使用 Kubernetes RBAC 的方式,達到稍微細緻以 namespace 為基底的權限, 並且以群組信箱來當作 subjet 的話則需要一些額外步驟

  1. 將 Google Group 與 GKE 連動,可參考 GKE RBAC
  2. 於 Google Group 將使用者都加入到該群組中
  3. 於 GCP 給予該 Google Group ([email protected]) 一個 Kubernetes Engine Cluster Viewer 的權限,因為所有人都至少要能夠透過 gcloud 去認證獲得 KUBECONFIG 來存取,因此至少要可讀

另外群組的部分,可以採用 nested group,就是所有真正的 group 都加入到上述的 gke-security-groups 內,因此 RBAC 設定的部分就可以採用 [email protected], [email protected] 等方式來設定。

一切完畢後就依照 Kubernetes RBAC 的設定,準備 Role/RoleBinding,其中 RoleBinding 的 Subjects 改成

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: xxxxxxxxxx
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: xxxxxxxxxxxx
roleRef:
kind: Role
name: xxxxxxxxxx
apiGroup: rbac.authorization.k8s.io