背景：
团队成员都是老旧派，没有接受过容器思想。但是应用部署都在kubernetes集群上面了，然后他们以为应用的ip是不可变的。嗯，然后我就顺便看了一眼让容器保持ip不变的资料。早些时候报名了罗伟老师的k8s网络训练营。由于时间问题直播仅看了几次。但是受益匪浅。正好今天看群里小伙伴聊天讨论到了pod分配静态ip的方案就参考了一下：阿里云的-Terway：https://help.aliyun.com/document_detail/97467.html腾讯云的-VPC-CNIhttps://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.htmlOpenKruise 是 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.忽略......
确认一下版本，嗯 1.21.3！
通过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 的安装结果：
使用 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才能看到:
注：先不说其他，这点让我很烦啊.....四个pods全部调度在了一个node节点上了......先忽略至于官方pvc扩容缩容的我就不想一一测试了我就想试一下更换镜像ip是否发生改变！因为我的初衷是保持ip！修改一下cloneset.yaml配置文件 增加updateStrategy配置，并修改image tag为latest
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:
