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年的时候比较重我还是不用了...)

发现了神奇的宝藏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！
修改一下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并没有删除在重建，而是在原来的基础上直接更新了镜像文件，并重启了服务。
原地升级减少了删除重建环节，节省了升级时间和资源调度频率......

其他：

至于其他的就去看文档吧....就做个demo测试一下......

question:

1. 如下图所示....5个pod都调度在一个节点上，有时间要研究一下调度策略。将pod打散。

2. 也在群里问了一下大佬。如果节点下线该怎么办？kruise也就不灵了......
3. 不过仅保持ip 不变这样的需求kruise已经很不错了。已经满足了我的需求了。有时间深度研究一下！
4. 看文档，看文档，看文档。弄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