Rancher 2.3实现K8S一键式升级!再也不用同步升级Rancher啦!
在Rancher 2.3之前,Rancher的新版本总是随着Kubernetes的新版本一起发布,如果你想要使用最新版本的Kubernetes,那么你需要先升级Rancher才能使用。Rancher 2.3改变了这一模式——现在,可以为可用的Kubernetes版本更新元数据存储,从而使Rancher服务器的升级过程与Kubernetes集群的升级过程解耦。
Kubernetes 版本控制
关于发行版的版本控制在Kubernetes文档中已经有详细的介绍,值得一提的是,每个Kubernetes的版本都遵循X.Y.Z的格式:
-
X=主要版本
-
Y=次要版本
-
Z=修复版本(补丁版本)
Kubernetes社区大致每三个月会发布一个次要版本(1.14->1.15),这些发行的版本会更新许多所需功能以及改进。尽管被标记为“次要版本”,但这些版本依旧十分重要!
补丁版本(1.15.1->1.15.2)的更新会更加频繁并且十分重要,因为它们包含了及其重要的安全性和适用于最新次要版本的bug修复。它们解决了:
-
安全漏洞
-
修复影响大部分用户无法解决的问题
-
基于Kubernetes的客户和产品拦截
Kubernetes官方希望集群将“合理地”更新到生产环境中,并且“大致”运行的是最新补丁版本。他们可以同时发布三个次要版本。这一切意味着,如果你的Kubernetes版本在最新版本后面有一些补丁版本,此时如果你想知道“何时才是升级集群的最佳时机”,那么答案可能是尽早升级以确保集群安全可靠。如果你的Kubernetes版本后面有几个次要版本,那么答案是在升级路径变得困难之前,应该现在就升级。
而Rancher努力通过实现“一键升级”以使这一过程变得简单和易于管理。在Rancher 2.3之前,Rancher的新版本始终适配Kubernetes最新的补丁版本。重要的安全修复已移植到新发布的版本,因此Rancher升级后即可使用Kubernetes新的补丁版本。
K8s版本和Rancher版本的解耦
在Rancher 2.3之前的版本中,将Rancher启动的集群升级到最新版本的Kubernetes需要两个步骤:
1、 升级Rancher server
2、 在下游集群中升级Kubernetes版本
现在,一切都不一样了。在Rancher 2.3中,你可以直接升级Kubernetes集群到最新版本,并且无需升级Rancher。因为,在Rancher 2.3中解耦了Rancher中的Kubernetes元数据。
Rancher部署的集群运行RKE,这是Rancher的一款开源的Kubernetes发行版,它可以让你在任意地方运行Docker。在Rancher 2.3之前,启动不同Kubernetes版本的信息存储在不同的地方。这个数据与代码库中的数据接近,因此更新任一值都需要发布一个新的Rancher版本。没有一个位置可以让系统访问需要传递给集群的值。Rancher 2.3重构了整个方法以满足以下需求:
-
将Kubernetes元数据持续交付给兼容的Rancher server
-
清晰地将所有元数据组件映射到Kubernetes版本
-
可以从Rancher API轻松访问所有内容
-
离线设置的可用性和支持路径
-
使启用或禁用升级程序、设置升级中使用的值易于配置
请注意:Kubernetes API会在两个次要版本之间更改,因此升级次要版本不一定能成功。例如,在Kubernetes 1.15中 API发生了重大更改,而在你的Rancher server中支持的最高版本是Kubernetes 1.14,如果此时你想要升级Kubernetes到1.15版本的话,需要升级Rancher以支持Kubernetes 1.15。
Rancher元数据
Rancher定期同步和下载元数据,这些数据不能直接从UI中获取,但是用户可以在API里查看。
RKE元数据配置决定了Rancher同步元数据的频率以及下载数据的位置。你可以从UI的【设置】下找到,也可以通过API的/v3/settings/rke-metadata-config
这个路径获取。它包括以下选项:
当然,你也可以选择手动更新,操作地址在右上角:Tools > Drivers > Refresh Kubernetes Metadata。对于离线设置,可以选择将URL配置复制到默认的Rancher元数据存储库。你也可以下载包含所需系统镜像的文件,只需点击Rancher UI左下角的Rancher版本即可下载。
运作方式如下:
Rancher v2.3.0一开始默认可选择以下Kubernetes版本:
Kubernetes发布了1.15.5版本,修复了一个重要的CVE,而我们目前的版本1.15.4受到安全漏洞的影响。
Rancher测试团队会测试新版本,让其可以在Rancher中使用。用户仅需通过选择Tools > Drivers > Refresh Kubernetes Metadata即可更新元数据。
最新的Kubernetes版本(1.14.8、1.15.5和1.16.2)现在在同一个Rancher版本(v2.3.0)中可以使用。
通过这一更改,你可以按计划保证集群处于最新状态,而与Rancher发布Rancher server新版本的时间无关。
Rancher一向致力于让Kubernetes的各个方面都变得简单,并且我们将继续添加更多功能以及进行更多优化,我们希望收到你的反馈!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Red Hat 敦促英特尔处理器用户尽快打上 ZombieLoad v2 安全补丁
外媒 Softpedia 报道称,红帽(RedHat)昨日向外界通报了影响英特尔 CPU 微体系架构的一系列新安全漏洞,不过它们已经在新版 Linux 内核中得到了修补,建议受影响的客户尽快更新。 据悉,这三个漏洞分别为 CVE-2018-12207(页面大小变更的机器检查错误)、CVE-2019-11135(TSX 异步中止)、以及 CVE-2019-0155 和 CVE-2019-0154(i915 显示驱动相关的漏洞)。 (题图 viaSoftpedia) 红帽安全团队将这些漏洞标记为重要、认为它们会对安全造成一定的影响。若被攻击者得逞,系统将向其敞开对敏感数据的读取权限,波及所有受支持的红帽企业版(RedHat Enterprise)Linux 操作系统。 Red Hat 意识到了一个微体系结构(硬件)实施漏洞,问题可能导致无特权的本地攻击者绕过常规的系统安全机制,引发系统范围内的拒绝服务等状况。 目前仅知漏洞会影响英特尔公司的处理器,但因缺陷存在于硬件层面,因此需要实施内核级的修复更新。此问题会影响 Red Hat Enterprise Linux 8 和更早的所有发行版。 ...
- 下一篇
KTV歌曲推荐-深入浅出协同过滤
前言 推荐算法有很多,最基础的就是协同过滤,前段时间对KTV数据比较感兴趣,大家去唱歌也只是唱熟悉的歌,那是不是有办法给大家一些建议拓展一下唱歌的宽度呢。KTV推荐可能要考虑很多因素,比如唱歌者的音域,年龄,地区,喜好,等等。第一版算法暂时只从item base的角度出发去给用户推荐。由于是个人兴趣,所以没有模型反馈迭代的过程,有兴趣的可以自己实现。 协同过滤算法 协同过滤又叫行为相似召回,其实就是基于共现的一种相似度计算。 Item Base的协同过滤算法有几个关键概念: 相似度计算 相似度计算有很多种:共现相似度,欧几里得距离,皮尔逊相关系数,等等这里使用的是共现相似度,公式如下: 其中N(i)为喜欢i歌曲的用户数,同样N(j)为喜欢j歌曲的用户数,分子为同时喜欢i,j的用户数。该公式为改良公式,分子中加入了N(j)对相似度进行惩罚。这里不细讲。 ItemBase和UserBase UserBase 寻找兴趣相似的用户,然后将偏好相同的用户的歌曲推荐给被推荐用户,表中发现A和C用户都喜欢i和k歌曲所以两个用户相似,所以将C用户的歌曲l推荐给A用户。如果用共现的方式去表述就是。这里细...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- 设置Eclipse缩进为4个空格,增强代码规范
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能