「K8S」不是“银弹”，但却欲罢不能的东西
随着互联网技术的不断演进，新的技术栈不断呈现，同时也冲击和影响着着传统的软件领域的开发、运维和实施体系，网上也有大量的文章会宣传K8S带来的优点和特性，诸如自我修复，水平扩展，滚动更新，版本回退等，这些优点和特性确实给我们的开发、运维和实施带来革命性的提升，但是也有很多企业在宣传时候往往过于夸大，并结合微服务概念，将其包装为以绝杀一切的“银弹”，真有这样的银弹吗，显然不是。下面结合笔者在实际的项目应用中，K8s到底给我们带来什么改变？ 我们又将面对什么挑战或问题？
K8S带来什么改变K8S全称Kubernetes，是一个容器的编排和调度的集群平台，首先它是一个集群平台，其次它主要用来管理容器的编排和调度，因此它主要解决的问题让应用的日常运行提供高可用性，同时降低管理诸多容器的运维难度，从K8S的特性来看，也是一一对应的， 如自动化编排：自愈，快速缩放，一键部署和升降级，备份恢复等。
K8S集群是用于管理容器的编排和调度，因此K8S和容器是相互依存的，所以讲为什么要用K8S就不得不讲我们为什么要用容器技术。
在没有K8S和容器化技术，我们部署一个Web应用集群是这样的：
传统集群架构
传统集群架构是部署在虚拟机上的，每一个虚拟机可能是一个linux操作系统，操作系统上安装tomcat中间件，在tomcat里运行java的war包。
在日常的部署和运维中，我们需要在每一台虚拟机上去做相同的操作，同时分发相同的java包，一旦发生调整优化的时候，我们就需要每一台去做调整，费时费力，也非常容易出错，常见的就是软件包分发不一致或者单个服务器配置不一致，导致各类问题。 此外，一般一台虚拟机我们只会部署一个类型的应用，比如java应用，如果要在一台虚拟机上部署多应用时候，依赖组件可能会发生冲突，比如你要同时部署一个php5.2或5.7应用的时候，就非常困难。
在使用K8S和容器化技术，我们部署一个Web应用集群是这样的：
开发发布代码后，Jenkins将其打包成一个镜像放入镜像仓库，一个镜像中包含了一个最小集合的操作系统内核+运行环境（如tomcat中间件）+程序包。K8S会调用kubelet命令集，从镜像仓库中拉取对应版本的镜像，并通过runc的底层命令，将其在已部署docker或containerd的node（虚拟机）上运行起来，并根据yaml部署文件，确定使用CPU和内存等资源和需要对外暴露的集群访问端口。
对于一线的实施运维来说，工作量一下子解放了，只要K8S和容器化的基础环境部署后，后续所有的运维不需要关心中间件，也不需要关心不一致性和程序运行环境，基本做到开箱即用，不需要在现场去做更多的事情。由于k8S主要使用命令行来管理，如果安装rancher提供k8s的图形化管理工具，学习成本及其低，一般的运维人员不需要会linux，也不需要了解tomcat，只要会使用鼠标，在rancher界面上去操作我们的部署、更新，集群节点的增加减少等等。
为什么说K8S不是“银弹”1、使用简单和方便是相对的
使用K8S和容器化平台后，对于客户或1线的实施人员来说，使用非常简单，哪怕不懂技术，也可以使用的7788，但是所有使用的方便简单，建立在后台的开发人员身上。怎么打包成一个可用的镜像文件，怎么提供现场一个可靠的yaml部署文件，如果使用rancher的应用商店部署，怎么提供一个可靠的charts文件等等。
此外，由于新技术栈的应用，如果K8s集群和容器化平台出错，对于使用传统部署架构积累的经验来说就难以适用，对于排错人员的水平是有一定能力要求的。
2、自愈有前提
K8s平台可以配置健康检查，当监测到应用超出健康检查的阈值时候，应用就会自动重启自我修复，常见的比如应用的pod所在的node节点的虚拟机挂了，重启可以漂移到其它正常的node节点上。但是自愈依赖2个很重要的前提 1）K8s的空余资源足够，如果运行资源不够，是无法自愈的 2）程序要没有问题，如果有问题，比如在高并发或大数据量情况下出现GC或程序存在大量线程等待导致程序卡死，自愈并不能解决实际问题 3)依赖的单点服务出问题，比如数据库，则应用自愈也是毫无意义的
3、动态水平扩展有限制
在高并发场景下，能根据用户请求和并发量动态扩展应用节点，达到支持更高的并发，但在实际应用场景中，并不那么美好。1）要确认有没有足够的资源来满足你进行动态水平扩展2）如果是web应用，每拓展一个应用，就会增加数据库连接数，应用可以扩但数据库总的连接数是有上限的 3）扩展应用的启动速度不是那么快的时候，可能是个灾难，举例，在高并发场景下，由于压力太大，比如原先7个，要启动新的应用节点，但是在启动新的过程中，突然老的开始挂了，但由于新的启动时间过长，又来不及启，这个时候就会发现好像水平扩展和我们想象的就完全不一样，并不是那么美好了。当然也有解决方案，采取限流让超出的流量不打到应用上，但是用户体验可能就会下降。
4、使用资源要求高要求多
为了保证K8S的高可用性，不管从服务器资源还是服务器的要求来说都是由一定要求的。
首先讲服务器资源，传统部署模式下，一般使用虚拟机，虚拟机是构建在物理机上，一般一台物理机是允许一定量的虚拟机CPU和内存超配的，建立的理论基础是不可能同时这台物理机上的所有虚拟机会CPU会100%或内存100%，如果前者发生会导致虚拟机运行缓慢，如果后者则虚拟机崩溃。而采用容器化部署后，一方面要预留一定的冗余资源，1）容器可能会占满服务器资源导致虚拟机出现问题 2）要预留足够的满足滚动更新，自愈和水平扩展的资源要求 。
此外，采用容器化部署还会存在一定的资源浪费，比如一个node的工作节点如果是16核32G，而恰好跑在（自动调度）这个node上的2个应用一个是8核16G，另外一个4核8G，则剩余的资源就只有4核8G，如果没有小于或等于这样资源要求的应用，这个资源可能就是被浪费的，始终不会被使用到。因此相比传统部署，资源的冗余度可能会达到30%-40%，如果还需要一些K8s之外的配套应用，比如监控，限流，熔断等，可能要求的资源会更加多。
其次，K8S平台对网络通信要求和硬盘读写有着比较高的要求，K8S依赖etcd数据库，如果通讯延迟时间过长，导致etcd不同步，整个k8s集群就会出问题，如果硬盘读写不达标，官网是要达到50Mib/s左右，实际如果要流畅运行基本要达到150Mib/s左右，才能让容器应用跑的更加流畅。
总结k8s相对传统的软件部署架构来说，是个革命性的，美好的东西。但是我们要客观看待，k8s不是银弹，不能解决所有问题，要拥抱技术带来的变化和美好，也要正视和解决存在的挑战和问题。
导航取快递？菜鸟驿站打造“1分钟极速取件”，用好服务赢好口碑
这两年连快递行业，竞争异常激烈，围绕用户需求，不断在卷时效、卷体验。
今年以来，菜鸟驿站在快递最后一公里，力推“1分钟极速取件”新服务标准，在取件全链路上使出了“洪荒之力”，卷创新、卷科技。从提供基础的代收服务，向高品质的社区服务及体验迈进。怎样才能更快，更便捷地在小区取快递，这件事，正是菜鸟驿站一直在行动的。
9月初，行业首个包裹导航——菜鸟驿站“货架地图”功能全新上线，它能在线精准还原菜鸟驿站里的货架布局，快速导航包裹的位置并实景显示。用户只要打开手机APP便能快速根据导航，找到包裹所在的货架位置。如有多个包裹，还能规划“免绕路”的取件路线，非常方便。目前，“货架地图”已覆盖杭州、上海、重庆、成都、广州等多个城市的1000多家菜鸟驿站。其中，杭州近7成菜鸟驿站已上线。
菜鸟驿站的目标显然不止于此，它挖掘了更多更细微的用户需求，比如4月，菜鸟驿站自助查件功能开放。通过菜鸟App查件功能，以及驿站里的自助查件区，可以快速获取多电商平台包裹取件码，减少找站长要取件码的等候时间。目前，小Yi自助查件区已在全国200多个城市1.3万多家菜鸟驿站落地，并在持续加大推广中。
同一个月，“夜间取件”服务上线，首批覆盖杭州、成都、广州、上海等多个城市的1000多家菜鸟驿站。经过数字化改造后的菜鸟驿站，营业时间在晚间将延长至24时，取包裹的市民只要用手机扫下二维码，驿站门锁就能自动打开，提供自助取件服务，早上7点-9点也可延续夜间取件模式代班。这使得菜鸟驿站的服务，变成了“707”工作制：早上7点上班，午夜0点下班，一周7天无休，大大方便了喜欢网购但工作繁忙的晚归族。
同时，菜鸟驿站在取件服务商也一直致力于“高效”二字，为了节约用户的时间。在今年2月，“闲忙状态”查看功能开通。通过菜鸟App，能一目了然地看到菜鸟驿站的忙碌程度（畅通、忙碌、拥挤），还能实时预估当前取件时长，便于提前做好规划、错峰取件。截至目前，该功能已覆盖全国10多万家菜鸟驿站。
菜鸟对于改进用户体验的思考从未停止，对于智慧物流的追求也一直在路上，这是菜鸟一直以来的企业理念造就的，也是当下中国快递业高质高速发展的一个缩影。相信在菜鸟的行动下，用户的物流体验会越来越好。
编辑 陈哲
