乐趣区

关于kubernetes:Kubernetes应用Pod固定IP之kruise

jiezi

背景：

团队成员都是老旧派，没有承受过容器思维。然而利用部署都在 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 打散。

  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
退出移动版