背景:

团队成员都是老旧派,没有接受过容器思想。但是应用部署都在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年的时候比较重我还是不用了...)
image.png
发现了神奇的宝藏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.忽略......
image.png

# 先下载安装包  并解压安装。

# 解压文件
tar zxvf helm-v3.5.3-linux-amd64.tar.gz

cd linux-amd64/
cp -r helm  /usr/local/bin/

# 查看版本号
helm version

image.png
确认一下版本,嗯 1.21.3!

kubectl get nodes

image.png

通过helm chart安装kruise

helm install kruise https://github.com/openkruise/kruise/releases/download/v0.10.0/kruise-chart.tgz

e7ce27a86f3a41ea728774900250f7f.png
具体参数参照:
http://openkruise.io/zh-cn/docs/installation.html。这里就是测试一下。没有多么特殊的需求!
image.png
验证一下helm 的安装结果:

kubectl get pods -n kruise-system
kubectl get crds | grep kruise
kubectl get all -n kruise-system

eb4d47b8ae7297e95d5a4f565c3dadc.png
be2f0b2e5e91a631b14fcb2718152ae.png

使用 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

image.png
从输出结果看,和原生的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

image.png
注:先不说其他,这点让我很烦啊.....四个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

image.png
image.png

nginx-alpine-x49vc pod发现重启了一次 describe一下:

 kubectl describe nginx-alpine-x49vc -n kruise

image.png
嗯镜像发生了改变!变成了新部署的。但是ip地址pod name确实保留了原有的 没有发生改变!
从输出可以看到,Container nginx definition changed, will be restarted,Pod并没有删除在重建,而是在原来的基础上直接更新了镜像文件,并重启了服务。
原地升级减少了删除重建环节,节省了升级时间和资源调度频率......

其他:

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

question:

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

image.png

  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