背景：

团队成员都是老旧派，没有承受过容器思维。然而利用部署都在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.gzcd 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-systemkubectl get crds | grep kruisekubectl get all -n kruise-system


应用 CloneSet

CloneSet 控制器提供了高效治理无状态利用的能力，它能够对标本土的Deployment，但CloneSet提供了很多加强性能。

先创立一个namespace：

kubectl create ns kruise

部署一个nginx的测试资源：

cat <<EOF > cloneset.yamlapiVersion: apps.kruise.io/v1alpha1kind: CloneSetmetadata:  labels:    app: nginx-alpine  name: nginx-alpinespec:  replicas: 5  selector:    matchLabels:      app: nginx-alpine  template:    metadata:      labels:        app: nginx-alpine    spec:      containers:      - name: nginx        image: nginx:alpineEOFkubectl apply -f cloneset.yaml -n kruise


从输入后果看，和原生的Deployment没有啥区别 #留神，这里如果get deployment是看不到nginx-alpine这个利用的，须要get cloneset能力看到:

[root@k8s-master-01 kruise]#  kubectl get deployment -n kruiseNo resources found in kruise namespace.[root@k8s-master-01 kruise]#  kubectl get cloneset -n kruiseNAME           DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGEnginx-alpine   5         5         5               5       5       10m
kubectl get pods -n kruise -o wide


注：先不说其余，这点让我很烦啊.....四个pods全副调度在了一个node节点上了......先疏忽
至于官网pvc扩容缩容的我就不想一一测试了我就想试一下更换镜像ip是否产生扭转！因为我的初衷是放弃ip！
批改一下cloneset.yaml配置文件 减少updateStrategy配置，并批改image tag为latest

cat <<EOF > cloneset.yamlapiVersion: apps.kruise.io/v1alpha1kind: CloneSetmetadata:  labels:    app: nginx-alpine  name: nginx-alpinespec:  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:latestEOFkubectl 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:

  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