欢迎光临
我们一直在努力

送容器下乡

Kubernetes 上天了

2020 年里,Kubernetes 的疆界有了一个有趣的扩展——美国人把 Kubernetes 和 Istio 装到了 F16 战斗机上。战斗机应该算是边缘了吧?读了几篇相关材料,发现整个过程远不止一个极限部署这么简单,DoD 在军方的大背景下,实现了一整套基于 DevSecOps 理念的云原生生态,那么一个问题就是,为什么单独要说 Kubernetes 和 Istio 呢?只是因为热门吗?

我的看法是,容器化和容器编排,是云原生的“阵眼”。云原生是个覆盖方方面面的体系,除了我们熟知的容器链条等技术要素之外,还以方法论的方式渗透到整个 IT 环境的市场、商务、架构、开发、运维、安全等各个方面。而其中的容器技术,其底蕴来自于几十年来整个业界不断的虚拟化和隔离技术的积累,是云原生的众多概念中,最能被“看得见,摸得着”的形象。同时作为制品和运行时的一等公民,容器和(Kubernetes 的)声明式 API 结合起来,已经能够满足绝大多数业务应用的运行需要。一个常见的 Kubernetes 环境,有足够条件能够符合 12 要素中至少一半的要求。这个组合是最常见也是最应该的云原生入门选择。很大程度上,Kubernetes 能走到哪里,云原生才能走到哪里。

部署是个大问题

回到前面的新闻,把 Kubernetes 装到哪里,当然不代表成功,但是它代表了一个重要的方向,YAML 架构师们都知道——只要这东西起来了,给我一个 Helm,就能搞他个天翻地覆。所以从诞生之初直到现在,Kubernetes 的部署都是个大问题。

然而一谈到 F16 之流的边缘部署,不可避免的会想到奇奇怪怪的设备们,长期以来都有一个固定的句式——我们给 XX 减肥,把它塞到资源有限的 YY 设备里。不过这对 Kubernetes 可能不太合适。

我一直对“魔改”这个事情有点抵触——感觉像是在车子上跳下来,虽然会有一个更高的速度,但是很难保障你真的就是火箭鱼雷航天飞机,下车才是刚起步,更多的情况是,跳车之后快了一瞬间,才发现跟不上了。

资源不足的设备,和上不了容器的用是一样的,如果存在真正的需求,它们自然会适应实际需要,无法适应只能说是需求不强。强扭的瓜不甜,只想要瓜不管甜不甜的可以忽略。

所以在我一个 YAML 架构师的眼里,Kubernetes 下乡,应该是基于原装的 Kubernetes,在一定程度内,满足大部分容器化业务的支撑需要,其它的东西,应该是设备归设备、虚机归虚机。Kubernetes 目前的下乡重点,应该在边缘机房,而非末梢节点。

什么样的 Kubernetes 能下乡

那么要让 Kubernetes 下乡,除了要求“原装货”,乡下有点什么不一样呢?

非标准环境

通常的边缘环境不会是标准数据中心,少到两三台利旧服务器,大到几个一体化机柜,各个节点会有参差不齐的硬件水平和规模,散热、供电水平通常达不到一个持续高可用运行的需要。

弱网络

和散热供电一样,位于边缘的节点的网络可能会有较高的延迟,甚至较长时间的断网,周期性的网络不可用,以及需要隧道才能互访的情况。

此外还有跨地域边缘节点组成的集群,节点之间、节点和控制平面之间的通信同时都可能遭遇网络问题,会把情况进一步的复杂化。

反锁定

我们历尽千辛万苦将 Kubernetes 送到乡下之后,可能会有很多嗷嗷待哺的容器化应用要运行,以及各方厂商的种种设备尝试接入进行就近处理,因此对通用性的需要是显而易见的,简单说就是远端的计算节点应该有足够的软硬件兼容性,能够以一定的标准运行在通用硬件、虚拟化和操作系统上,支撑多种厂商的、或通用或边缘的软件系统的运行。

低运维

通常来说,运维人员还是围绕数据中心工作的,被“下放”的 Kubernetes 必须能够在一个少运维甚至零运维的情况下运行,原本在数据中心如臂使指的虚拟化、Ansible 之流可能都会因为前方条件的不足而受到种种限制,此时就要求我们的远端节点有强大的自愈、自治和被远程运维的能力。

没结论

这几天偶尔看了一些边缘集群的一些东西,看到减肥蔚然成风,想起多年以前我对 Java 太吃内存的嘲讽,有感而发。

文章来源于互联网:送容器下乡

赞(0)
未经允许不得转载:莱卡云 » 送容器下乡