OpenKruise v0，rabbitmq面试题总结

1. 新增 kruise-daemon 组件

过去已经使用过 OpenKruise 的同学一定知道，Kruise 安装之后运行的组件是 kruise-manager，它是一个中心化部署的 Operator 组件，包含了一系列 controller 控制器以及 webhook。

而从 v0.8.0 开始，我们又增加了 kruise-daemon 这个节点组件，通过 DaemonSet 部署到每个节点上。这样，一直以来社区小伙伴们提的类似镜像预热、容器重启等需求，就有途径去实现啦！

Tips：

目前 kruise 提供的官方镜像支持 Linux 的 amd64（x86）、arm64、arm/v7 架构，如果你的集群中存在非以上架构的节点，暂时是无法正常运行 kruise-daemon 的，有这类需求的同学可以提issue 说明你的需求。
如果你存在上述情况，或者你不希望在某些节点上安装 kruise-daemon，可以在 helm 安装的时候通过 daemon.affinity 参数来指定 kruise-daemon 部署的亲和性规则。

2. 规模化镜像预热能力

在 Kubernetes 生态中，过去并没有一个成熟的镜像预热开源解决方案，可能更多的是一些公司在内部会落地一些适配于本地场景的预热，这其中也包括阿里巴巴。不过从 v0.8.0 开始，我们将阿里巴巴所做的镜像预热能力完全通用化输出到 OpenKruise 中，并且阿里内部的镜像预热也完全统一到这套开源的实现上来了。

OpenKruise 镜像预热的具体实现原理，我们会在后续的专项文章中做详细介绍，这里只以一个最简单的例子演示下如何做一个镜像的预热：

apiVersion: apps.kruise.io/v1alpha1

kind: ImagePullJob

metadata:

name: job-nginx

spec:

image: nginx:1.9.1 # [required] 完整的镜像名 name:tag

parallelism: 10 # [optional] 最大并发拉取的节点梳理, 默认为 1

selector: # [optional] 指定节点的名字列表或标签选择器 (只能设置其中一种)，不设置表示全部节点

names:
- node-1
- node-2
  
  matchLabels:
  
  node-type: xxx
  
  completionPolicy:
  
  type: Always # [optional] 默认为 Always
  
  activeDeadlineSeconds: 1200 # [optional] 无默认值, 只对 Alway 类型生效
  
  ttlSecondsAfterFinished: 300 # [optional] 无默认值, 只对 Alway 类型生效
  
  pullPolicy: # [optional] 每个节点上拉镜像的侧脸，默认 backoffLimit=3, timeoutSeconds=600
  
  backoffLimit: 3
  
  timeoutSeconds: 300
  
  ImagePullJob 有两种 completionPolicy 类型：
  - Always 表示这个 job 是一次性预热，不管成功、失败都会结束
  - activeDeadlineSeconds：整个 job 的 deadline 结束时间
  - ttlSecondsAfterFinished：结束后超过这个时间，自动清理删除 job
  - Never 表示这个 job 是长期运行、不会结束，并且会每天都会在匹配的节点上重新预热一次指定的镜像
    
    详细信息参考官网文档：https://openkruise.io/zh-cn/docs/imagepulljob.html
    
    3. SidecarSet 全新重构实现
    
    SidecarSet 是一个用于管理 sidecar 容器的控制器。在用户创建了 SidecarSet 之后，Kruise 能为后续创建的符合规定条件的 Pod 中自动注入用户定义的 sidecar 容器，以及对已注入的 sidecar 容器做原地升级同时不影响业务容器的运行。
    
    在过去版本中，SidecarSet 的局限性较多，比如用户无法声明只对某个 namespace 生效、sidecar 原地升级时灰度能力较弱等。在 v0.8.0 中，我们全新重构了 SidecarSet 的 controller 和 webhook，并且在 CRD 定义上新增了一些更多能力的策略字段。举一些例子：
    1. spec.namespace：指定只管理具体某个命名空间的 sidecar 注入和升级
    2. 多种注入策略：
    3. podInjectPolicy：指定 sidecar 容器注入到 Pod 原 containers 列表的前面还是后面
    4. shareVolumePolicy：与 Pod 中原容器共享卷策略
    5. transferEnv：从原 Pod 中哪些容器里共享哪些环境变量
    6. 多种原地升级策略：
    7. maxUnavailable：升级过程中最大不可用数量
    8. partition：保留旧版本的数量（灰度/分批发布）
    9. selector：只升级符合 selector 条件 Pod 中的 sidecar（金丝雀发布）
    10. scatter：按标签打散发布
    详细信息参考官网文档：https://openkruise.io/zh-cn/docs/sidecarset.html
    
    4. 新的 feature-gate 机制
    
    过去 OpenKruise 中的 CRD 以及 controller/webhook 开关，主要配置在 CUSTOM_RESOURCE_ENABLE 环境变量中，而其他一些可配置开关则集中在命令行参数中，带来的问题一来是较为分散，二来一些关联多个 CRD 的功能开关其实很难用 CRD 开关来控制。
    
    因此，目前新增的 feature-gate 机制已经代替了 CUSTOM_RESOURCE_ENABLE 环境变量，聚焦于功能层面。
    
    自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
    
    深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
    
    因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
    
    既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
    
    由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
    
    如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
    
    总结
    
    我们总是喜欢瞻仰大厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。
    
    面试题多多少少对于你接下来所要做的事肯定有点帮助，但我更希望你能透过面试题去总结自己的不足，以提高自己核心技术竞争力。每一次面试经历都是对你技术的扫盲，面试后的复盘总结效果是极好的！
    
    厂的大神们，但实际上大神也不过凡人，与菜鸟程序员相比，也就多花了几分心思，如果你再不努力，差距也只会越来越大。
    
    面试题多多少少对于你接下来所要做的事肯定有点帮助，但我更希望你能透过面试题去总结自己的不足，以提高自己核心技术竞争力。每一次面试经历都是对你技术的扫盲，面试后的复盘总结效果是极好的！
    
    [外链图片转存中…(img-Vi0gkTbj-1711950898725)]

分类:热门推荐日期:2024-05-13浏览:1评论:0

总结

镜像 节点

相关推荐