背景：

團隊成員都是老舊派，沒有接受過容器思想，但是應用部署都在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并沒有洗掉在重建，而是在原來的基礎上直接更新了鏡像檔案，并重啟了服務，
原地升級減少了洗掉重建環節，節省了升級時間和資源調度頻率…