前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >分享下云原生技术之外的另类话题

分享下云原生技术之外的另类话题

作者头像
用户5166556
发布2023-03-18 14:15:31
2230
发布2023-03-18 14:15:31
举报

好久没 K8S 相关的原创了,懒得更新了,主要不知道写了是否会有帮助。直到最近几天有同学跟我探讨引入了一堆云原生组件,不仅没有提高效率,反而徒增了很多心智负担。我才想起来好久没有更文了,应该为大伙分享一些自己的所见所闻。本想写点硬核技术,后来作罢;一来技术文章读起来伤脑筋,二来 K8S 相关的技术及最佳实践文章泛滥,基本遇到的问题都有解决方案,所以今天主要聊聊 K8S 技术细节之外的一些另类话题。

可以想想为啥 K8S 会成为各个云厂商及中大型公司的基础设施? 比如 Facebook 的 Twine,它的设计跟 K8S 反其道而行之,规避了 K8S 的中心化设计,能够容纳更多的节点、管理更多的机器。但是却没有进入我们的视野,究其原因,K8S 足够开源、中立,核心组件都是插件式设计,保持了软件设计的灵活性,允许社区及云厂商进行定制开发;各大云厂商尝试之后发现能够起到降本增效的作用,开始定制属于自己的技术和标准;这样下游的大中型公司可以直接使用或者购买云厂商开放出来技术或者平台;上游运营盈利者、标准制定开发者、下游使用者相互促进,从而形成了互利共赢的良性循环。

而对于有些组织,对安全有一定要求,很多服务不允许直接使用公有云,只能搭建以 K8S 为基础搭建自己的私有云平台,说着也很简单,谷歌多年的沉淀,头部云厂商都在使用,理论上没有任何技术问题。之前有个同事给我说,以 K8S 为中心的相关云原生技术其实非常简单,基于 docker 的容器化打包技术,定义好编排文件,发布到 K8S 平台,拉起服务,支持扩容.....

50W 以上的核心代码,仅次于一个操作系统;再看看 K8S 发布速度和 bug 修复数量。另外重点来了,各种组件出现的数量,各种容器运行时、各种日志收集组件 Loki、fluentd、EFK、监控工具、应用管理工具 OAM、各种集群管理工具,应接不暇,我该怎么选择? 别的不说,最起码得根据自己的使用场景,每种类型的要选择一种吧。

但是问题来了,我选择了一堆可以满足使用场景的工具,这些工具应该如何串联起来?

我之前曾面试过某上万人造车公司,问了我一个问题,以 K8S 为中心的各种基础设施,应该如何管理? 比如认证、授权,甚至如何让相关人员轻而易举的发现和使用这些基础设施?

如果使用规模比较小,可以做一个导航页面,在页面里面列举所有的组件,大家可以一目了然的看到所有的组件,自己选择使用了。如果使用规模比较大,可以做一个单点登陆认证系统,这样方便一键登录所有系统使用。

现在回想起来,我的想法实在天真。

云原生体系的组件特别多,如果大家共用一个账号肯定有问题,各自组件中申请账号又没有办法管理,所以单点登录只是最基本的要求。如果公司有 ldap 域账户可以同步过来使用,如果没有可能要自己通过其它方式录入人员信息了。某种意义上说,你要自己做一个单点登录系统,需要把各种云原生组件串联起来,或者说你需要在各种云原生组件界面上添加属于自己的登录跳转界面,这种高度定制化的功能,云原生社区没人帮你实现。

登录进去之后,老板们一定希望不同的人看到的菜单是不一样的,防止误操作,多么接地气的需求。如果云原生组件做的好,那么你就可以对接他们的菜单权限管理功能,如果没有,可能你要自己实现了。但是不管怎样,你又要定制云原生组件了。

如果身边有个同事换了个部门,需要另外一个服务的增删改查权限,怎么办? 发邮件申请,你会发现在人工智能高速发展的今天,很多事情不得不人肉完成,最后迫于无奈,你只能开发一套权限申请系统,自行申请权限,只需要对应部门的同事批准即可,不管怎样,还是会存在一定程度的开发成本和工作量。

上面这些其实都是基本权限管理,对于一些服务上线前的资源申请、服务接入、甚至一些自助日志接入系统,都需要相应的管理平台,这些平台听起来都很简单,没什么复杂度,但是结合到你的实际使用场景,很难找到现成的.....

云原生指的是你的上层应用原生了,云原生基础设施自身并不原生。

说到这里,有些同学可能要抬杠了,我们的几十台机器用的就非常简单,那么恭喜你,你之所以觉得简单,可能是享受到了 K8S 给我们带来的技术红利,也可能你的集群规模还不足以使用 K8S 进行管理。K8S 本身是用来管理上千个物理节点的。你非要用它来管理你的几十台物理机。虽然你的硬件资源不需要人肉管理,但是你需要专业运维人员去维护 K8S 集群,最终小规模集群可以带来的收益和付出的成本,基本上可以抵消;或者引入更多的成本、更高的学习复杂度。之前写过一篇关于小公司使用 K8S 带来的问题,有兴趣的可以参考:过早关注基础设施建设是万恶之源

人总是喜欢高估现在自己,很多事情看起来都不会太复杂,如果真的太复杂,基本当时就放弃了。当你真正入手去做的时候,你会发现各种不合适,各种需要定制化,领导期望一再降低,周期一直推迟,预算持续增长。这大概也就是很多云厂商重复造轮子的原因。洋洋洒洒扯了这么多,也没有说个解决方案,其实这种事情不用说,说了也没用,只是做的时候心里有谱就行了。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 云原生技术爱好者社区 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器镜像服务
容器镜像服务(Tencent Container Registry,TCR)为您提供安全独享、高性能的容器镜像托管分发服务。您可同时在全球多个地域创建独享实例,以实现容器镜像的就近拉取,降低拉取时间,节约带宽成本。TCR 提供细颗粒度的权限管理及访问控制,保障您的数据安全。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档