背景:
團隊成員都是老舊派,沒有接受過容器思想。但是應用部署都在kubernetes集群上面了,然后他們以為應用的ip是不可變的。嗯,然后我就順便看了一眼讓容器保持ip不變的資料。早些時候報名了羅偉老師的k8s網絡訓練營。由於時間問題直播僅看了幾次。但是受益匪淺。正好今天看群里小伙伴聊天討論到了pod分配靜態ip的方案就參考了一下:
阿里雲的-Terway:
https://help.aliyun.com/document_detail/97467.html
騰訊雲的-VPC-CNI
https://cloud.tencent.com/document/product/457/50355
注:這都是雲商的托管kubernetes集群中現有的方案。今天看文章貌似看到了jd也有類似的方案…
個人的線上是基於tke1.20.6的集群還有一個搭建在騰訊雲的1.21.2的kubeadm的高可用集群。具體的就是all in 騰訊雲。tke不想用騰訊雲的VPC-CNI。怎么說呢,覺得有點浪費資源…今天正好群里討論看到了小伙伴分享的openkruise還有騰訊開源的藍鯨的容器平台(藍鯨比較早的時候就玩過17年的時候比較重我還是不用了…)

發現了神奇的寶藏kruise?試用一下
注: 貌似是阿里雲開源的,感謝阿里雲的開源,還有群內大佬的分享!
OpenKruise 是什么
參照:http://openkruise.io/zh-cn/docs/what_is_openkruise.html
OpenKruise 是 Kubernetes 的一個標准擴展,它可以配合原生 Kubernetes 使用,並為管理應用容器、sidecar、鏡像分發等方面提供更加強大和高效的能力。
核心功能
- 原地升級原地升級是一種可以避免刪除、新建 Pod 的升級鏡像能力。它比原生 Deployment/StatefulSet 的重建 Pod 升級更快、更高效,並且避免對 Pod 中其他不需要更新的容器造成干擾。
- Sidecar 管理支持在一個單獨的 CR 中定義 sidecar 容器,OpenKruise 能夠幫你把這些 Sidecar 容器注入到所有符合條件的 Pod 中。這個過程和 Istio 的注入很相似,但是你可以管理任意你關心的 Sidecar。
- 跨多可用區部署定義一個跨多個可用區的全局 workload,容器,OpenKruise 會幫你在每個可用區創建一個對應的下屬 workload。你可以統一管理他們的副本數、版本、甚至針對不同可用區采用不同的發布策略。
- 鏡像預熱支持用戶指定在任意范圍的節點上下載鏡像。
- 容器重建/重啟支持用戶重建/重啟存量 Pod 中一個或多個容器。
- …
Controllers 與 Webhooks
- CloneSet提供更加高效、確定可控的應用管理和部署能力,支持優雅原地升級、指定刪除、發布順序可配置、並行/灰度發布等豐富的策略,可以滿足更多樣化的應用場景。
- Advanced StatefulSet基於原生 StatefulSet 之上的增強版本,默認行為與原生完全一致,在此之外提供了原地升級、並行發布(最大不可用)、發布暫停等功能。
- SidecarSet對 sidecar 容器做統一管理,在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。
- UnitedDeployment通過多個 subset workload 將應用部署到多個可用區。
- BroadcastJob配置一個 job,在集群中所有滿足條件的 Node 上都跑一個 Pod 任務。
- Advanced DaemonSet基於原生 DaemonSet 之上的增強版本,默認行為與原生一致,在此之外提供了灰度分批、按 Node label 選擇、暫停、熱升級等發布策略。
- AdvancedCronJob一個擴展的 CronJob 控制器,目前 template 模板支持配置使用 Job 或 BroadcastJob。
- ImagePullJob支持用戶指定在任意范圍的節點上下載鏡像。
- ContainerRecreateRequest為用戶提供了重建/重啟存量 Pod 中一個或多個容器的能力。
- Deletion Protection該功能提供了刪除安全策略,用來在 Kubernetes 級聯刪除的機制下保護用戶的資源和應用可用性。
- PodUnavailableBudget對比Kubernetes PDB只提供針對Pod Eviction的防護,PUB能夠防護Pod Deletion、Eviction、Update多種voluntary disruption場景。
- WorkloadSpread約束無狀態 workload 的區域分布,賦予單一 workload 的多區域和彈性部署的能力。
安裝 OpenKruise
參照:http://openkruise.io/zh-cn/docs/installation.html
前提: helm 安裝 kubernetes集群版本最好大於1.16
helm安裝省略…
https://github.com/helm/helm/releases/ 下載對應helm包。當然了 我的安裝的比較早是3.5.3.忽略…

# 先下載安裝包 並解壓安裝。
# 解壓文件
tar zxvf helm-v3.5.3-linux-amd64.tar.gz
cd linux-amd64/
cp -r helm /usr/local/bin/
# 查看版本號
helm version

確認一下版本,嗯 1.21.3!
kubectl get nodes

通過helm chart安裝kruise
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.10.0/kruise-chart.tgz

具體參數參照:http://openkruise.io/zh-cn/docs/installation.html。這里就是測試一下。沒有多么特殊的需求!

驗證一下helm 的安裝結果:
kubectl get pods -n kruise-system
kubectl get crds | grep kruise
kubectl get all -n kruise-system


使用 CloneSet
CloneSet 控制器提供了高效管理無狀態應用的能力,它可以對標本土的Deployment,但CloneSet提供了很多增強功能。
先創建一個namespace:
kubectl create ns kruise
部署一個nginx的測試資源:
cat <<EOF > cloneset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
labels:
app: nginx-alpine
name: nginx-alpine
spec:
replicas: 5
selector:
matchLabels:
app: nginx-alpine
template:
metadata:
labels:
app: nginx-alpine
spec:
containers:
- name: nginx
image: nginx:alpine
EOF
kubectl apply -f cloneset.yaml -n kruise

從輸出結果看,和原生的Deployment沒有啥區別 #注意,這里如果get deployment是看不到nginx-alpine這個應用的,需要get cloneset才能看到:
[root@k8s-master-01 kruise]# kubectl get deployment -n kruise
No resources found in kruise namespace.
[root@k8s-master-01 kruise]# kubectl get cloneset -n kruise
NAME DESIRED UPDATED UPDATED_READY READY TOTAL AGE
nginx-alpine 5 5 5 5 5 10m
kubectl get pods -n kruise -o wide

注:先不說其他,這點讓我很煩啊…四個pods全部調度在了一個node節點上了…先忽略
至於官方pvc擴容縮容的我就不想一一測試了我就想試一下更換鏡像ip是否發生改變!因為我的初衷是保持ip!
x修改一下cloneset.yaml配置文件 增加updateStrategy配置,並修改image tag為latest
cat <<EOF > cloneset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
labels:
app: nginx-alpine
name: nginx-alpine
spec:
replicas: 5
updateStrategy:
type: InPlaceIfPossible
inPlaceUpdateStrategy:
gracePeriodSeconds: 10
selector:
matchLabels:
app: nginx-alpine
template:
metadata:
labels:
app: nginx-alpine
spec:
containers:
- name: nginx
image: nginx:latest
EOF
kubectl apply -f cloneset.yaml -n kruise


nginx-alpine-x49vc pod發現重啟了一次 describe一下:
kubectl describe nginx-alpine-x49vc -n kruise

嗯鏡像發生了改變!變成了新部署的。但是ip地址pod name確實保留了原有的 沒有發生改變!
從輸出可以看到,Container nginx definition changed, will be restarted,Pod並沒有刪除在重建,而是在原來的基礎上直接更新了鏡像文件,並重啟了服務。
原地升級減少了刪除重建環節,節省了升級時間和資源調度頻率…
其他:
至於其他的就去看文檔吧…就做個demo測試一下…

question:
- 如下圖所示…5個pod都調度在一個節點上,有時間要研究一下調度策略。將pod打散。

- 也在群里問了一下大佬。如果節點下線該怎么辦?kruise也就不靈了…
- 不過僅保持ip 不變這樣的需求kruise已經很不錯了。已經滿足了我的需求了。有時間深度研究一下!
- 看文檔,看文檔,看文檔。弄demo只是為了測試一下
