Virtual Kubelet

大家好， 趁打开流量主的东风，特此贡献一篇长文，分析一下目前国内国外几大著名云厂商的kubernetes服务，以飨诸君。 文起之前，先聊态度。 我本人是十分看好k8s的发展的，为何？ 理因古往今来，能给资本家省钱，能给企业省资源，能把人全栈化，能把业务自动化的玩意，肯定是会受追捧的。君不见docker兴起之时，mesos启势之际，到k8s一统天下。国内企业，技术人员已经有能力消化和适用K8S这类理念和框架了，其带来的好处和收益或许不亚于pc时代的linux服务器，故而有人称之为云时代的linux系统，鄙人确也深以为然。他有啥好处？看起来其实十分简单： scaling: k8s直接按需扩展pods recovery:k8s帮你监管pods,出问题了自动修复 monitoring:k8s包含了很多监控能力 free: k8s是免费的 easy&fast:部署应用贼快贼方便，ci/cd集成容易 然而，K8S是银弹（silver bullet）吗？ 显然不是。 我一直强调其是一种理念，开发架构部署时的理念，原则上，你需要具备应用现代化，云原生化，DDD的能力，才能更好结合K8s帮助企业应用数字化转型。通过将业务模型和软件架构改造，配合k8s来做，这才是正确的使用方式。 你问我一个简单的CMS或者企业内部应用sap的，Oracle，需要K8S么？ 我只能说可能不适合。语言，框架，开源软件

最近，我们做了一个把Grofers的所有服务迁移到Kubernetes上的决定。 Grofers是杂货领域印度最大的低价在线超市，成立于2013年12月01日，由Albinder Dhindsa和Saurabh Kumar创立，总部位于印度德里的卫星城市Gurugram。其主要提供各种类别的产品，如杂货、水果和蔬菜、美容和保健、家庭护理、婴儿护理、宠物护理、面包和肉类以及海鲜等产品。 在迁移前端网站到Kubernetes上的过程中，我们发现默认的滚动更新部署策略并不如理想中那么好，所以我们不得不使用蓝绿策略来代替（后面会详细讨论）。 对于那些想要做同样迁移工作的人，这篇博客可以作为一个指南，因为当前缺乏这块主题相关的资源，所以这可以节省他们的时间和精力。 首先我们会介绍一些基础知识，然后一步一步的介绍怎么实现，最后再通过运行负载测试来考察不同策略的效果。 什么是Kubernetes？ Kubernetes是一个开放源代码的容器编排系统，用于自动化应用程序的部署，扩展和管理。 我不会介绍Kubernetes所有的基础知识（可以在这里查看其它好的资源[1]）。这篇文章中我只会介绍两个非常常见的部署策略。 第一个是蓝绿策略。对于部署单页面网站应用（网站资源使用版本控制），推荐使用该策略。 另一个是滚动更新策略

Kubernetes是起源于Google、在最近三五年里大热的容器编排工具。战胜了其他竞争对手之后，Kubernetes现在毋庸置疑地在云计算环境中占据垄断地位。在收购了Heptio、Bitnami等颇有影响的初创公司之后，VMware成为Kubernetes全球社区中举足轻重的贡献者。2020年3月，VMware发布了Cloud Foundation 4，内置革命性的Tanzu平台，全面支持Kubernetes在云中更高效透明的运维管理。 与此同时，相当多的用户和厂商在不断尝试将Kubernetes应用于边缘计算环境中。然而，边缘计算毕竟不同于云计算，很多云中习以为常的基本假设，在边缘上是不成立、或者成本过高以至于不现实的。 本篇将浅析其中的原委，并比较不同技术方案的优缺点。这里专注于设备层的探讨，而不是云边缘（Cloud Edge）或移动边缘计算（MEC）。对于Kubernetes来讲，后两者的技术环境与云中相比差别不大，基本可以无缝迁移。 第六篇 设备集群上的Kubernetes 原生Kubernetes的基本假设 Kubernetes原本设计是在云计算环境中运行，所以它的基本假设就是云计算资源、基础设施即服务（IaaS）的特性，包括： - 计算是充分的、可分布式部署的 - 网络是稳定的、可双向联通的 - 存储是易失的、本地的，或持久化的、网络化的 - 管理是远程的、自动化的

前言 弹性伸缩是Kubernetes中比较常用的功能。在Kubernetes中，弹性是分为两个层次的，一个是调度层（Pod）弹性，一个是资源层（Node）弹性。通常会通过HPA、CronHPA、VPA等模型进行Pod的横向或者纵向的伸缩，再通过 cluster-autoscaler 或者 virtual-kubelet 进行资源层伸缩。两层之间是通过无法调度的 Pod 进行解耦，这样设计的好处是两层职责明确，坏处是解耦后相互结合的策略过于简单，一旦当我们需要更精细的调度策略就无能为力了，因为在Kubernetes中最小的生命周期管理单元是一个Pod，而传统的Kubernetes负载控制器（例如：Deployment、StatefulSet）管理的Pod是共享相同的调度策略的。因此，当你希望控制一个负载在不同资源上的细粒度分配时，就无能为力了。然而这种场景又是在弹性伸缩中经常遇到的。因此，为了解决应用负载弹性场景下精细化调度的诉求， kubernetes-elastic-workload 应运而生了。 弹性伸缩精细化调度的问题分析 假设：有一个应用经过容量规划，预计最多有4个副本运行在ECS上，平时低峰时保留2个副本，超过4个副本的场景弹性伸缩到虚拟节点，防止干扰其他正常容量规划的应用。 在Kubernetes中，任何一种负载都要解决两个问题，一个是调度问题，一个是生命周期管理问题

作者 | 阿里云容器技术专家 莫源 本文整理自莫源于 8 月 31 日 K8s & cloudnative meetup 深圳场 的演讲内容。 关注“阿里巴巴云原生”公众号，回复关键词 “资料”， 即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱。 导读 ：Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0，终有一天容器会和 Serverless 进行一场决战，分出胜负。实际上，容器和 Serverless 是可以共存并且互补的，特别是在 Autoscaling 相关的场景下，Serverless 可以与容器完美兼容，弥补容器场景在使用简单、速度、成本的缺欠，在本文中将会为大家介绍容器在弹性场景下的原理、方案与挑战，以及 Serverless 是如何帮助容器解决这些问题的。 当我们在谈论"弹性伸缩"的时候 当我们在谈论"弹性伸缩"的时候，我们在谈论什么？"弹性伸缩"对于团队中不同的角色有不同的意义，而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图，表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量，因为应用的资源申请量相比节点而言会小很多，因此曲线相对比较平滑；

作者 | 阿里云容器技术专家 莫源 <br /> <br /> 本文整理自莫源于 8 月 31 日 K8s & cloudnative meetup 深圳场 的演讲内容。 关注“阿里巴巴云原生”公众号，回复关键词 “资料” ，即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱。 导读 ：Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0，终有一天容器会和 Serverless 进行一场决战，分出胜负。实际上，容器和 Serverless 是可以共存并且互补的，特别是在 Autoscaling 相关的场景下，Serverless 可以与容器完美兼容，弥补容器场景在使用简单、速度、成本的缺欠，在本文中将会为大家介绍容器在弹性场景下的原理、方案与挑战，以及 Serverless 是如何帮助容器解决这些问题的。 当我们在谈论"弹性伸缩"的时候 当我们在谈论"弹性伸缩"的时候，我们在谈论什么？"弹性伸缩"对于团队中不同的角色有不同的意义，而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图，表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量，因为应用的资源申请量相比节点而言会小很多