| 启迪云解决方案架构师 费海强
Docker容器改变了人们对开发、部署和维护软件的思考方式,利用现代操作系统的本机隔离功能,容器支持类似于虚拟机的关注点分离,但是与基于虚拟机监控程序的虚拟机相比,它的开销要小得多,部署的灵活性也要大得多。
容器非常轻巧灵活,它们产生了新的应用程序架构,新方法是将构成应用程序的不同服务打包到单独的容器中,并在物理或虚拟机群集中部署这些容器。这就需要容器编排 - 一种自动化基于容器的应用程序的部署,管理,扩展,网络和可用性的工具。
Kubernetes,这个源自Google的开源项目可以自动化大规模部署和管理多容器应用程序的过程,虽然Kubernetes主要使用Docker,但它也适用于符合容器图像格式和运行时的Open Container Initiative(OCI)标准的任何容器系统。而且由于Kubernetes是开源的,对其使用方式的限制相对较少,任何想要运行容器的人都可以自由使用它。
Kubernetes不会取代Docker,但会增加它的功能,但是,Kubernetes 确实取代了Docker中出现的一些更高级别的技术。
其中一种技术是Docker Swarm,一个与Docker捆绑在一起的编排器,它仍然可以使用Swarm而不是Kubernetes,但Docker公司已经选择让Kubernetes成为Docker社区和Docker Enterprise版本的一部分。
并不是说Kubernetes是Swarm的直接替代品。Kubernetes比Swarm复杂得多,需要更多的工作才能部署,但同样,这项工作旨在从长远来看提供巨大的回报- 一个更易于管理,更具弹性的应用程序基础架构。对于开发工作和较小的容器集群,Docker Swarm提供了一个更简单的选择。
高级语言(如Python或C#)为用户提供抽象和库,以便他们可以专注于完成手头的任务,而不是陷入内存管理的细节。
Kubernetes与容器编排的工作方式相同,它为管理容器组提供了高级抽象,允许Kubernetes用户专注于他们期待的应用程序运行方式,而不是担心具体的实现细节。他们需要的行为与提供它们的组件分离。
Kubernetes旨在自动化和简化许多容器管理任务,它具备如下的关键功能:
许多应用程序不仅存在于一个容器中,它们是由一堆容器构建,可能是一个数据库,或是Web前端,也许是一个缓存服务器。微服务也是以这种方式构建的,通常为每个服务、Web协议和API绘制单独的数据库,以将服务联系在一起。虽然将应用程序作为微服务来构建有长期的优势,但它带来了许多短期的繁重工作。
Kubernetes减少了实现此类应用程序所需的工作量,你告诉Kubernetes如何从一组容器中组成一个应用程序,Kubernetes处理将它们推出,保持它们运行并保持组件彼此同步的细节。
应用程序需要能够上下调整以满足需求,平衡传入负载,并更好地利用物理资源。Kubernetes具备做所有这些事情的条件,并以自动化,不干涉的方式进行。
基于容器的应用程序开发工作流程的部分吸引力在于实现持续集成和交付,Kubernetes具有允许对新版本的容器映像进行优雅更新的机制,包括在出现问题时进行回滚。
Kubernetes处理许多其他基于容器的应用程序的复杂细节,让容器相互通信,处理服务发现以及为来自各种提供商(例如,亚马逊的EBS)的容器提供持久存储都通过Kubernetes及其API进行处理。
众所周知,容器是不透明的。Kubernetes提供用于获取有关容器和容器组状态的实时信息的服务,以及有关群集中开发人员操作的详细信息。
Kubernetes集群可能需要调整其目标环境,但一些调整会使未来的升级变得困难。Kubernetes的本机功能之一,自定义资源定义,允许开发人员扩展和自定义Kubernetes的API,而不会破坏与Kubernetes库存的兼容性。
Kubernetes与特定的云环境或技术无关,它可以在任何支持容器的地方运行,这意味着公共云,私有堆栈,虚拟和物理硬件以及单个开发人员的笔记本电脑都是Kubernetes可以玩的地方。Kubernetes集群也可以运行上述任何组合。这甚至包括Windows和Linux系统的混合。
Kubernetes的架构利用了各种概念和抽象,其中一些是现有的,熟悉的概念的变体,但其他一些是Kubernetes特有的。
最高级别的Kubernetes抽象(cluster)是指运行Kubernetes(本身是集群应用程序)的一组机器及其管理的容器,一个Kubernetes集群必须有一个master,即命令和控制集群中所有其他Kubernetes机器的系统。一个高可用性的Kubernetes集群在多台机器上复制master的设施,但一次只有一个主控形状运行作业调度程序和控制器管理器。
每个集群都包含Kubernetes节点,节点可以是物理机器或虚拟机,同样,这个想法是抽象的:无论应用程序运行在什么地方,Kubernetes都会处理在那个底层上的部署。还可以确保某些容器仅在虚拟机上运行或仅在裸金属上运行。
节点运行pods,这是可以创建或管理的最基本的Kubernetes对象,每个pod表示Kubernetes中应用程序或运行进程的单个实例,由一个或多个容器组成。Kubernetes开始、停止并将pod中的所有容器作为一个组复制。pods让用户关注应用程序,而不是容器本身。有关如何配置Kubernetes的详细信息,从pods的状态开始,保存在一个分布式键值存储Etcd中。
根据需要在节点上创建和销毁pods,以符合用户在pod定义中指定的所需状态。Kubernetes提供了一个称为控制器的抽象概念,用于处理如何旋转、展开和旋转pods的物流。控制器有几种不同的风格,这取决于所管理的应用程序的类型。例如,最近引入的“StatefulSet”控制器用于处理需要持久状态的应用程序。另一种控制器,部署,用于向上或向下扩展应用程序,将应用程序更新为新版本,或者在出现问题时将应用程序回滚到已知的良好版本。
因为pods根据需要生存和死亡,我们需要一个不同的抽象来处理应用程序生命周期。应用程序应该是一个持久化实体,即使运行构成应用程序的容器的pod本身不是持久的。为此,Kubernetes提供了一种称为服务的抽象。
服务描述了如何通过网络访问给定的pod组(或其他Kubernetes对象),正如Kubernetes文档所说,构成应用程序后端的pod可能会发生变化,但前端不应该知道或跟踪它。服务使这成为可能。
Kubernetes内部的一些内容使图片更加完美,该调度包裹了工作量,以使他们在整个资源平衡和使部署满足应用程序定义的要求节点。所述控制器管理器保证了系统的应用程序,工作负载,状态等-匹配ETCD的配置设置定义的期望的状态。
重要的是要记住,容器使用的低级机制(如Docker本身)都不会被Kubernetes 取代。相反,为了保持应用程序大规模运行,Kubernetes提供了一组更大的抽象来使用它们。