Kubernetes vs Mesos vs Swarm

Introduction 如果您正在阅读本文,您可能会问自己什么是容器编排引擎,它们解决了哪些问题,以及它们之间的区别。本文将尝试对Kubernetes,Docker Swarm和Apache Mesos进行high-level overview,以及它们的一些显着的相似点和不同点。 Container Orchestration Engines 虽然定义各不相同,但Kubernetes,Docker和Swarm都属于一类DevOps基础架构管理工具,称为Container Orchestration Engines(COE)。 COE在资源池和在这些资源上运行的应用程序容器之间提供抽象层。 与容器一起,COE解决的主要问题是如何在云或数据中心中采用多个离散资源,并将它们组合到一个池中,可以在其上部署各种应用程序。这些应用程序的范围可以从简单的三层Web体系结构到大规模数据摄取和处理,以及介于两者之间的所有内容。 这些工具中的每一个都提供不同的功能集,并且在成熟度,学习曲线和易用性方面各不相同。他们可以共享的一些高级功能包括: Container scheduling — 其中包括执行启动和停止容器等功能;在集合资源中分配容器;收回失败的容器;将容器从故障主机重新平衡到健康主机,并通过容器扩展应用程序,无论是手动还是自动。 High availability — 应用程序和容器,或编排系统本身的高可用性。 Health checks — 确定容器或应用程序运行的健康性检测 Service discovery — 其用于确定分布式计算架构中的各种服务在网络上的位置。 Load Balancing requests — 无论是在集群内部生成还是从外部客户端生成的请求的负载均衡 将各种类型(网络,本地)存储附加到群集中的容器。 NOTE,此列表并非详尽无遗,而是表示编排引擎提供的某些高级服务。值得一提的是,虽然这里讨论的每个工具都会在某种程度上执行这些功能,但实现方式可能会有很大差异。 Kubernetes Container Orchestration Capabilities Kubernetes(也称为“k8s”)于2014年6月首次发布,用Go编写。从古希腊语翻译,Kubernetes这个词的意思是“舵手。”该项目起源于谷歌开源,并且基于他们大规模运行容器的经验。 在功能方面,它可能是本文中检查的三个选项中最本地集成的。 Kubernetes使用非常广泛,背后有一个庞大的社区。 Google将Kubernetes用于自己的Container as a Service(CaaS)产品,称为Google Container Engine(GKE)。还有许多其他平台支持Kubernetes,包括Red Hat OpenShift和Microsoft Azure。 Docker是目前由Kubernetes支持的最普遍的容器引擎,但也支持CoreOS rkt(发音为“rocket”)。 Kubernetes使用基于YAML的部署模型。除了在主机上调度容器之外,Kubernetes还提供许多其他功能。 主要功能包括内置自动扩展,负载平衡,卷管理和秘密管理。此外,还有一个Web UI可帮助管理和排除群集故障。通过包含这些功能,Kubernetes通常比Swarm或Mesos需要更少的第三方软件。 将Kubernetes与Swarm和Mesos区分开来的还是“pods”的概念,它是一组容器,它们被组合在一起构成Kubernetes术语中的“服务”。 虽然可以将Kubernetes主服务器配置为高可用性集群,但这不像单节点主服务器那样受支持,并且是Kubernetes的高级用例。 Kubernetes的学习曲线有些陡峭,并且可以比Swarm更加努力地配置。部分由于其功能更紧密的集成,Kubernetes有时被认为比这里讨论的其他两个编排引擎更“opinionated”。 Swarm Container Orchestration Capabilities Docker Swarm是Docker的本机Container Orchestration Engine。最初于2015年11月发布,它也是用Go编写的。 Swarmkit是版本1.12中包含的Swarm的Docker本机版本,对于那些希望使用Swarm的人来说,这是Docker的推荐版本。...

September 17, 2018 · 1 min · 134 words · Me

Genetic Algorithm for mulit-Objective Optimization of containers allocation in cloud architecture

Introduction Mainly talk about the Microservice architecture The containerization of applications is one of the technologies enabling microservices architectures. microservices can be scaleb up by simply creating new containers until the desired by scalability level is achieved. Docker is one of the most successful implementations of container architectures. Goals: -»> consolidation 合并, 巩故, elasticity弹性, 弹力, load balancing, and scalability可扩展性. Examples: -»> Docker Swarm, Apache Mesos, and Google Kubernetes. Four traditional research: -»> System provisioning, system performance, reliability, and network overhead....

July 21, 2018 · 2 min · 267 words · Me

Large-scale cluster management at Google with Borg

Introduction The cluster management system we internally call Borg admits, schedulers, starts, restarts, and monitors the full range of applications that Google runs. Borg provides three main benefits: it hides the details of resource management and failure handing so its users can focus on application development instead operates with very high reliability and availability and supports applications that do the same lets us run workloads across tens of thousands of machines effectively....

July 14, 2018 · 2 min · 286 words · Me

container scheduling

Introduction Linux containers allow applications to run in complete isolation from one another without the extra overhead of running entirely separate operating systems. Linux容器允许应用程序彼此完全隔离运行,而无需运行完全独立的操作系统的额外开销。This approach eliminates memory overheads associated with virtualization and virtual machines and helps businesses run their day-to-day applications. software containers become the new pillars for software deployment and today Internet. Docker, a software container implemenation, has emerged not only as a new virtualization technologies but also an application delivery platform....

July 13, 2018 · 5 min · 955 words · Me

Real time scheduling introduction

Real time scheduling introduction Requirements For the traditional scheduling Algorithms, we looked at turn-around time (or throughput), fairness, mean response time. But real-time systems have very different requirements, characterized by different metrics. timeliness … how closely does it meet its timing requirements (e.g. ms/day of accumulated tardiness) predictability … how much deviation is there in delivered timeliness And in the real-time system, here are some other concepts: feasibility … whether or not it is possible to meet the requirements for a particular task set hard real-time … there are strong requirements that specified tasks be run a specified intervals (or within a specified response time)....

4 min · 713 words · Me