背景：
团队成员都是老旧派，没有接受过容器思想。但是应用部署都在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
<br />确认一下版本，嗯 1.21.3！
kubectl get nodes
<a name="d4xyY"></a>
## 通过helm chart安装kruise
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.10.0/kruise-chart.tgz
<br />具体参数参照：[http://openkruise.io/zh-cn/docs/installation.html](http://openkruise.io/zh-cn/docs/installation.html)。这里就是测试一下。没有多么特殊的需求！<br /><br />验证一下helm 的安装结果：
kubectl get pods -n kruise-system kubectl get crds | grep kruise kubectl get all -n kruise-system
<br />
<a name="PoYNc"></a>
## 使用 CloneSet
CloneSet 控制器提供了高效管理无状态应用的能力，它可以对标本土的Deployment，但CloneSet提供了很多增强功能。
先创建一个namespace：
kubectl create ns kruise
部署一个nginx的测试资源：
cat <
- name: nginx
image: nginx:alpine
EOF kubectl apply -f cloneset.yaml -n kruise
<br />从输出结果看，和原生的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并没有删除在重建，而是在原来的基础上直接更新了镜像文件，并重启了服务。
原地升级减少了删除重建环节，节省了升级时间和资源调度频率……
其他：
question:
- 如下图所示….5个pod都调度在一个节点上，有时间要研究一下调度策略。将pod打散。
- 也在群里问了一下大佬。如果节点下线该怎么办？kruise也就不灵了……
- 不过仅保持ip 不变这样的需求kruise已经很不错了。已经满足了我的需求了。有时间深度研究一下！
-
参考：
- https://www.jianshu.com/p/cfa0d73a929a
- https://blog.csdn.net/easylife206/article/details/110152300
- https://blog.csdn.net/xujiamin0022016/article/details/112058944
若有收获，就点个赞吧
0 人点赞
