编辑：阿冒
设计：沐由
全社会、全民迈向数字化的当下，1亿月活（MAU）的App已不鲜见，不要说一些我们日常离不开的软件，哪怕是像知乎这样的知识平台，也已经做到了月活过亿。
(相关资料图)
即便如此，在这些明星App中却少有App能够承受每秒100万次以上的查询——不过凡事总有例外，Skyscanner是一款可搜索超过1000家航空公司上百万条航路的应用，一旦临近假期，Skyscanner的每秒查询量会迅速飙升到每秒百万级的巨大体量。
你看不到的是，Skyscanner会在最短时间内迅速调动1000台服务器+3W多个pods，为全球客户的查询提供支持，帮助你在最短时间内找到最快捷、最便宜的机票……
你也一定不会相信，所有这一切庞大资源从容调度的背后，Skyscanner居然只配置了区区6名维护工程师。究竟是公司BOSS太抠门，还是说队伍中暗藏了扫地僧一样的大神？
来自开源社区的明星技术
其实，Skyscanner的秘密说来很简单：Kubernetes。作为一种用于管理云平台上容器化应用的开源技术，Kubernetes为现代化应用的规划、部署、更新和维护带来了革命性的新机制。
兴许是为了方便起见，国内技术圈的大佬们将Kubernetes简称为K8s，8代表了被省略的8个字母ubernete——如此神奇的脑回路令人百思不解，不过这并不妨碍K8s的风行。
此前的模式下，应用的部署一般通过插件或脚本来安装进行，表面上无需专业技术人员介入，但是却导致应用与操作系统绑定，而且很难进行应用的升级/回滚等操作。
K8s的强大在于，容器的启动速度极快、占用资源极少、部署速度极快，打包更方面，带来了更好的开发体验，让微服务变得愈发简单，而且应用的监控与管理也变得前所未有的高效……
以上，当然只是K8s的凤毛麟角而已，更多益处本文也不作赘述。如果K8s带来的只有美好，那自然再也美满不过，然而事物的两面性存在于任何事物之上，K8s亦不能例外。
事实上，尽管在企业的业务创新与管理方面，buff叠满的K8s令人无限期待，不过就算是那些颇具技术实力的企业，在面临自建容器集群时也必然会头皮发麻。
作为来自开源社区的明星技术，K8s的背后是成千上万的代码提交者和贡献者，以及超过1000+的厂商，势必就造成了诸多的发行版本，而且社区自身也大约会每隔三个月就发布一个次要版本。
即便是做好版本管理，并建立了容器集群之后，企业仍旧有大量的技术工作要做：兼容性测试、安全验证、网络适配等等，以及与系统对接之类的“业务工作”，不一而足。
没错，我们也能列举出关于K8s的大量DeBuff，不过这并非是本文的目标，我们只是想说明，企业热切希望利用K8s为在自身目标带来有效的提升，但是他们在“核心业务”之外要做的工作，实在是有点太多，而且难以把控。
这样看来，我们本节开始给出的答案就有些不严谨，甚至是不正确了，因此我们要为之加上一个前提，即Skyscanner仰仗的神器并不是普通的K8s，而是Amazon EKS（Elastic Kubernetes Service）。
让容器操作与管理得心应手
Amazon EKS是亚马逊云科技的一项托管服务，提供高度可用、可扩展且安全的Kubernetes服务。作为社区的积极参与者和贡献者，Amazon EKS与上游Kubernetes保持100%兼容——这一点非常重要。
很多厂商往往对开源项目进行“魔改”，所谓的“魔改”，是通过一定程度上对于软、硬件的修改，以使其在功能上得到加强或优化，暂时达到或接近客户的需求，虽然在当前的很多数字化项目中并非常态，但是却不鲜见。
然而，“魔改”毕竟是违反了设计者原先的技术设想与体系架构，必然会带来稳定性、安全性等一系列问题，并且很有可能导致不可预知的严重后果。
亚马逊云科技不会做任何的“魔改”。也就是说，上游的Kubernetes是什么样，亚马逊云科技均会以云原生的形式，将之在云上进行严格的适配和移植，从而确保客户的业务应用可以在其中完美地运行。
无论何时，Amazon EKS保证至少支持四个生产就绪版本的 Kubernetes。与此同时，Amazon EKS还提供了14个月的版本技术支持，明显长于社区的9个月，这就意味着哪怕是社区不再支持的版本，照样可以在Amazon EKS上得到支持。
Amazon EKS架构示意图
对于像Kubernetes这样的软件来说，从开源社区走出来到进入到最终的生产环境，其实中间还有很长的一段路要走，包括跟云上的安全等能力进行结合，与其他组件的兼容性测试、网络适配等过程，客户往往需要做一大堆类似“重复造轮子”的工作。
Amazon EKS则不然，亚马逊云科技的技术和服务队伍已经帮助做了以上各类繁复和枯燥的工作。得益于此，客户可以直接将他们的精力与资源全部投入到自己的容器业务上，轻松构建可靠、稳定和安全的应用程序。
Amazon EKS带来的不仅是高性能、可靠和安全的Kubernetes服务，它也使得Kubernetes的操作和管理变得前所未有的简单起来。
比如，在令人望而却步、头皮发麻的集群管理方面，Amazon EKS提供了一键式的升级控制平面及数据平面的功能，让以往复杂的操作简单易用到极致，而且强大、安全。
按下现代化应用的“加速键”
随着企业业务的互联网化发展，大规模的容器业务应用已经成为不争的事实。面对不断变化的市场，企业需要与时俱进、推陈出新，永远有大量的新业务准备上线。
然而，成百上千的POD启动必然会带来很多问题，譬如过度消耗系统资源、严重迟滞存储性能等等……那么，Amazon EKS能够带来哪些显著的提升呢？
在支撑大规模容器业务应用方面，Amazon EKS不止拥有高可用架构，还包括了弹性伸缩、共享服务平台、成本可视化等优势。
以弹性伸缩为例，这里就不得不说到Amazon Karpenter了。作为新一代的Kubernetes自动扩容工具，Karpenter的表现令人惊叹：它会动态选择最适合的计算资源，自动添加或删除所需的计算资源，进行高性能的规模测试，等等。
空口无凭，还是让数字来说话。在Amazon EC2规格为c5.large的环境下，从0增加到100的扩容，Cluster Autoscaler需要超过4分钟，Karpenter仅需2分钟；从100减少到1的缩容，Cluster Autoscaler需要6分多钟，而Karpenter仅需30秒。
随着业务应用容器化程度不断加深，越来越多客户也在基于Amazon EKS构建共享服务平台，旨在同时兼顾到安全的管控和开发的灵活性。微服务和容器化的大规模使用加速了业务应用迭代上线的速度，方便了开发人员，但是从运维的角度而言，也对其所需云资源的快速按需配置供给以及安全合规管控方面带来了挑战。
客户通过在Amazon EKS上构建共享服务平台，平衡了开发和运维的冲突。而共享服务平台在本质上是运维事先定义好可用模板，其中包括数据库、节点规模等，开发人员可以按需取用，真正做到让运维与开发“相视一笑泯恩仇。
其实，以上的各种神奇均建立在IaaS（基础设施即代码）之上。由于这种代码库式，客户只需要简单的几行代码，甚至比摆积木还简单，就可以快速部署起庞大而高效的基础设施。
目前已经有数十万客户正在借助亚马逊云科技Amazon EKS 平台，交付和运行着数不胜数的现代化应用。在构建共享服务平台方面，Amazon EKS提供了Blueprints解决方案，与常用的Kubernetes生态工具链集成，高度可扩展、可定制，满足各种现代化应用的严苛要求。
在数字化的发展大潮中，越来越多的企业正在脱颖而出。得益于亚马逊云科技提供的一系列服务，初创企业同样可以基于最先进的基础设施和更优的成本控制，实现创业梦想。
