k8s要革技术人员的命

2016 年 4 月 25 日3,7770

本站主要内容均为原创,转帖需注明出处www.alexclouds.net

        这个说法虽然有点夸张,但是当你看到容器和微服务也在国内迅猛发展的时候,你就会认为这个趋势无可挑剔。越来越多的公司正在或者正要适用容器技术,比如时下流行的docker, 还有k8s. 网上还有一个关于K8s的视屏,kubernetes 1.2v千万并发实测,请看视频:

https://www.youtube.com/watch?v=9C6YeyyUUmI(需要翻越)在这个视频里,集群规模上升到1000个节点上到达10MQPS(即每秒1千万请求),还包括了滚动更新,没有宕机时间和任何延迟。这在互联网上也足以列入前百强的表现。况且1.3将会更大程度地提高系统的扩展性和性能,同时还会增加新功能,使得k8s更好地来适应高需求的、基于容器集群的应用。

 

         下面呢这张图很有意思,其实代表了时下的趋势,虚拟机上跑的是容器,而非hypervisor,容器是是PaaS,这是主流架构。

       k8s

 

           下面这图也解释了为什么是容器技术:

 

       whyc

 

        下面是k8s目前的架构:

 

k8s-1

 

        那么为什么会要了技术人员的命呢? 我认为恐怕首先是革运维,君不见现在谷歌的集群几万台只要一两个人管理就好了? 但是目前国内的互联网公司都有或多或少的运维团队,趋势确实在这里,高度高效的生产力要取代老旧生产力,这在逻辑上完全是合理的。

        微服务的产生带来了生产效率的成本提升,也让微服务内部的服务定义和监控成了微服务系统本身关注的问题,这和GOOGLE当初的设计一致,在提升服务的同时提高效率,减少运维人员。

 

        假如,我是说假如,GOOGLE把人工智能技术投入到k8s系统,运维全自动并取代人工指日可待。是不是有部电影里演到“skynet天网”可以全自动生存和修复? 因此好好想一想,是不是所有岗位都有被取代的危险? 只是时间问题

        据我了解,K8s显著改变了将服务带到市场的方式,k8s是经过编排的服务环境,可以动态的将复杂的容器配置任务编排到基础设施,并且将分布组件连接呈现为统一的服务。而且k8s设计之初就开始考虑了集群内部的资源利用和资源监控,编排等等。可以说,这将会是一个基本自动化的服务生产系统。

 

        1、分布式基因,k8s具有在多数据中心分发应用程序的优势,可以显著提升分布式应用程序的性能,控制成本就不说了。

        2、弹性扩容的优势,可扩容到1000多个节点集群。此外, 这个系统动态复制控制可以根据需要在几秒内调度额外的容器资源。

        3、服务,Kubernetes是一个理解应用的逻辑和物理优化的中央大脑。Kubernetes负责将复杂的容器配置任务编排到你的基础设施,并且将那些分布组件连接呈现为统一的服务。实质上,Kubernetes创建物理资源利用和pods的逻辑集合之间的桥梁,服务组成了你理解的应用程序。

 

         以上这些变化已经让运维的监控和资源告警业务必须变得跟上节奏,最终减少了资源。

         要是术语就是“容器驱动,以微服务为导向的混合云部署”就是我们的目表,保证其平稳运行需要做如下工作:

 

         1、监测系统最好追踪并且监测底层资源问题,这与Services和pods的定义相关,监测系统需要资源告警监控,如CPU,mem或是network usage都需要被应用到单独的容器或者是应用程序中去。为了操作正常,这些警报也必须在Kubernetes创建的容器中工作正常。警报提示也可以应用于Pod、服务和任何跟你的应用程序有关的标签。

         2、云提供监测。需要使用一个可以在云端监控,警报,故障排除的系统。最重要的是,这个系统可以在云端收集需要的指标。

         3、从Kubernetes API动态摄取相关信息,将逻辑组容器集合映射到逻辑的应用程序,以及不断计算聚合应用程序、服务和基础设施指标,允许您整体监控服务。

 

         微服务和容器相对复杂,因此监控和警报必须能够动态的聚合所有相关的资源,并可以测量服务和pod的整体性能。微服务带来的额外的挑战,因为要调整如何满足你的应用程序需求,编排工具也能够帮助弹性扩容基础设施,这是最复杂的。

 

         因此我个人认为,虽然k8s在国内短期内难以成熟应用,但是这个前景无疑是非常光明的。

0 0