Kubernetes应用Pod固定IP之kruise _Kubernetes

高斋晓开卷，独共圣人语。这篇文章主要讲述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.16helm安装省略......
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-system kubectl get crds | grep kruise kubectl get all -n kruise-system

文章图片

文章图片

使用 CloneSetCloneSet 控制器提供了高效管理无状态应用的能力，它可以对标本土的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 NAMEDESIREDUPDATEDUPDATED_READYREADYTOTALAGE nginx-alpine5555510m

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测试一下......