Kubernetes應用Pod固定IP之kruise


背景:

團隊成員都是老舊派,沒有接受過容器思想。但是應用部署都在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年的時候比較重我還是不用了…)
image.png
發現了神奇的寶藏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.忽略…
image.png

# 先下載安裝包  並解壓安裝。

# 解壓文件
tar zxvf helm-v3.5.3-linux-amd64.tar.gz

cd linux-amd64/
cp -r helm  /usr/local/bin/

# 查看版本號
helm version

image.png
確認一下版本,嗯 1.21.3!

kubectl get nodes

image.png

通過helm chart安裝kruise

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

e7ce27a86f3a41ea728774900250f7f.png
具體參數參照:http://openkruise.io/zh-cn/docs/installation.html。這里就是測試一下。沒有多么特殊的需求!
image.png
驗證一下helm 的安裝結果:

kubectl get pods -n kruise-system
kubectl get crds | grep kruise
kubectl get all -n kruise-system

eb4d47b8ae7297e95d5a4f565c3dadc.png
be2f0b2e5e91a631b14fcb2718152ae.png

使用 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

image.png
從輸出結果看,和原生的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

image.png
注:先不說其他,這點讓我很煩啊…四個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

image.png
image.png
nginx-alpine-x49vc pod發現重啟了一次 describe一下:

 kubectl describe nginx-alpine-x49vc -n kruise

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

其他:

至於其他的就去看文檔吧…就做個demo測試一下…
image.png

question:

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

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

參考:

  1. http://openkruise.io/en-us/docs/what_is_openkruise.html
  2. https://www.jianshu.com/p/cfa0d73a929a
  3. https://blog.csdn.net/easylife206/article/details/110152300
  4. https://blog.csdn.net/xujiamin0022016/article/details/112058944


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM