The Con­tainer Wars: Ku­ber­netes vs Ama­zon ECS

Among con­tainer orches­tra­tion tech­nolo­gies, Ku­ber­netes and Ama­zon ECS lead the pack. How­ever, on what ba­sis should sys­tems ad­min­is­tra­tors choose one over the other? This ar­ti­cle will help them make an in­formed choice.

OpenSource For You - - Contents -

Ship­ping con­tain­ers are re­garded as ubiq­ui­tous and stan­dard­ised. They can be ac­ces­si­ble from any­where in the world by fol­low­ing sim­ple pro­ce­dures. Soft­ware con­tain­ers op­er­ate in some­what a sim­i­lar man­ner. Pack­ing the soft­ware con­tainer in­volves defin­ing what is re­quired for your ap­pli­ca­tion to work. This in­cludes the op­er­at­ing sys­tem, li­brary files, con­fig­u­ra­tion files, ap­pli­ca­tion bi­na­ries and other com­po­nents of the tech­nol­ogy stack.

A con­tainer im­age is used to cre­ate con­tain­ers that can op­er­ate in al­most any en­vi­ron­ment, from stan­dard desk­top sys­tems to data cen­tres and even on the cloud. Con­tain­ers are re­garded as highly ef­fi­cient as many of them can run on the same ma­chine al­low­ing full re­source util­i­sa­tion. Con­tainer tech­nol­ogy was in­tro­duced in the late 1970s but be­came ex­tremely pop­u­lar only when Docker was in­tro­duced in 2013. Since then, con­tainer tech­nol­ogy has dras­ti­cally changed the DevOps land­scape and the way ap­pli­ca­tions are de­vel­oped, shipped and run.

A sin­gle con­tainer or­di­nar­ily runs a sin­gle ap­pli­ca­tion. The run­ning of mul­ti­ple op­er­a­tions si­mul­ta­ne­ously with a sin­gle con­tainer has been made pos­si­ble with the con­cept of con­tainer orches­tra­tion.

The im­por­tance of con­tain­ers

• Ef­fec­tive DevOps and con­tin­u­ous de­liv­ery: When the ap­pli­ca­tion con­sists of mul­ti­ple con­tain­ers with clear in­ter­faces among them, it is sim­ple to up­date a con­tainer, as­sess the im­pact and even roll back to an ear­lier ver­sion. By hav­ing mul­ti­ple con­tain­ers, the same ca­pa­bil­ity en­ables up­dat­ing ev­ery con­tainer with­out any sort of hic­cup.

• En­vi­ron­ment repli­ca­tion: When mak­ing use of con­tain­ers, it is fairly easy to in­stan­ti­ate iden­ti­cal copies of the full ap­pli­ca­tion stack and con­fig­u­ra­tion. This can be per­formed by us­ing new de­vel­op­ers and new sup­port teams to safely re­search and ex­per­i­ment in to­tal iso­la­tion.

• Test­ing: With con­tain­ers, a stress test can be per­formed to en­sure the en­vi­ron­ment re­quired matches with the nor­mal op­er­a­tional re­quire­ments.

• Scal­a­bil­ity: By build­ing an ap­pli­ca­tion from mul­ti­ple con­tainer in­stances, adding more con­tain­ers scales out

ca­pac­ity and through­put. Sim­i­larly, con­tain­ers can be re­moved when the de­mand falls. Us­ing orches­tra­tion frame­works such as Ku­ber­netes and Apache Me­sos fur­ther sim­pli­fies elas­tic scaling.

• Per­for­mance: As com­pared to vir­tual ma­chines, con­tain­ers are very light­weight and have min­i­mal im­pact on per­for­mance.

• Hun­dred per cent avail­abil­ity: With the de­ploy­ment of mul­ti­ple con­tain­ers, re­dun­dancy can be built into the ap­pli­ca­tion. So, if any con­tainer fails, the other peers will take over to pro­vide the ser­vice.

Con­tainer orches­tra­tion

Con­tainer orches­tra­tion is de­fined as the process of au­to­mated ar­range­ment, co­or­di­na­tion and the man­age­ment of com­puter sys­tems, mid­dle­ware and ser­vices.

Con­tainer orches­tra­tion is linked with ser­vice-ori­ented ar­chi­tec­ture, vir­tu­al­i­sa­tion, pro­vi­sion­ing, con­verged in­fra­struc­ture and dy­namic data cen­tres. It is re­garded as the process of align­ing the busi­ness re­quests with the ap­pli­ca­tions, data and in­fra­struc­ture. It de­fines the poli­cies and ser­vice lev­els via au­to­mated work­flows, pro­vi­sion­ing and change man­age­ment. It cre­ates a pow­er­ful ap­pli­ca­tion­aligned in­fra­struc­ture that can be scaled up or down depend­ing on ap­pli­ca­tion needs. Orches­tra­tion re­duces the time and ef­fort for de­ploy­ing mul­ti­ple in­stances of a sin­gle ap­pli­ca­tion.

Con­tainer orches­tra­tion tools of­fer pow­er­ful and ef­fec­tive so­lu­tions for cre­at­ing, man­ag­ing and up­dat­ing mul­ti­ple con­tain­ers in co­or­di­na­tion across mul­ti­ple hosts. Orches­tra­tion al­lows the users to share data be­tween ser­vices and process tasks in an asyn­chro­nous fash­ion.

Orches­tra­tion of­fers the fol­low­ing unique fea­tures: Pro­vi­sion­ing hosts

In­stan­ti­at­ing a set of con­tain­ers

Reschedul­ing failed con­tain­ers

Link­ing con­tain­ers to­gether via sim­ple ad­min­is­tra­tionori­ented GUI in­ter­faces

Ex­pos­ing ser­vices to ma­chines out­side of the clus­ter Scaling in, out and down the clus­ter by adding or re­mov­ing con­tain­ers at any point of time

Con­sider an ex­am­ple in which IT soft­ware in­fra­struc­ture com­prises Apache, PHP, Python, Ruby, Node.js and Re­act apps run­ning on a few con­tain­ers which are con­nected to a repli­cated DB. In such a case, there is no re­quire­ment for con­tainer orches­tra­tion. But when the ap­pli­ca­tion keeps on grow­ing rapidly with time, it re­quires mas­sive re­sources in terms of CPU, RAM, etc. That’s when it needs to be split into smaller chunks, where ev­ery chunk is re­spon­si­ble for an in­de­pen­dent task, main­tained by re­spec­tive teams like mi­croser­vices. So, now there is a re­quire­ment for a caching layer, as well as a queu­ing sys­tem to in­crease per­for­mance, ef­fec­tively syn­chro­nise the tasks and share data suc­cess­fully among the ser­vices.

Var­i­ous chal­lenges come into this op­er­a­tional sce­nario, like ser­vice dis­cov­ery, load bal­anc­ing, con­fig­u­ra­tion man­age­ment, stor­age man­age­ment, reg­u­lar sys­tem health checks, auto-con­fig­u­ra­tion of nodes and zero-down­time de­ploy­ments.

Con­tainer orches­tra­tion pro­vides ef­fec­tive and pow­er­ful so­lu­tions to meet var­i­ous de­mands. There are many play­ers in the mar­ket like Ku­ber­netes, AWS ECS and Docker Swarm. So, it is im­por­tant to com­pare the per­for­mance of Ku­ber­netes against that of AWS ECS to as­sist IT sysad­mins in se­lect­ing the bet­ter of the two.

Ku­ber­netes

Ku­ber­netes is an open source plat­form de­signed by Google and now main­tained by the Cloud Na­tive Com­put­ing Foun­da­tion. It is re­garded as the most fea­ture-rich and widely used orches­tra­tion frame­work for au­to­ma­tion, scaling and op­er­at­ing ap­pli­ca­tion con­tain­ers across clus­ters of hosts, and it pro­vides con­tainer-cen­tric in­fra­struc­ture. It works with a range of con­tainer tools in­clud­ing Docker.

Ku­ber­netes is de­signed to work in mul­ti­ple en­vi­ron­ments in­clud­ing bare metal, on-premise VMs and pub­lic clouds.

With Ku­ber­netes, one can per­form the fol­low­ing op­er­a­tions:

Or­ches­trate con­tain­ers across mul­ti­ple hosts.

Make ef­fec­tive use of hard­ware to max­imise re­sources to run all sorts of en­ter­prise apps.

Con­trol and au­to­mate ap­pli­ca­tion de­ploy­ments and up­dates.

Mount and add stor­age to state­ful apps.

Scale con­tainer­ised ap­pli­ca­tions and all re­sources, on-the-fly.

Man­age all sorts of ser­vices, which guar­an­tee that all de­ployed apps are run­ning in the same way as they are de­ployed.

Per­form reg­u­lar health checks and trou­bleshoot the apps with auto place­ment, auto restart, auto repli­ca­tion and auto scaling.

Ku­ber­netes ar­chi­tec­ture

Ku­ber­netes fol­lows the mas­ter-slave ar­chi­tec­tural model.

The fol­low­ing are the com­po­nents of Ku­ber­netes’ ar­chi­tec­ture.

Ku­ber­netes mas­ter: This is the main con­trol­ling unit of the clus­ter, which per­forms the tasks of man­ag­ing all sorts of work­loads and com­mu­ni­ca­tion across the en­tire sys­tem. It con­trols all nodes con­nected in the clus­ter.

API server: This is re­garded as a key com­po­nent to serve the Ku­ber­netes API us­ing JSON over HTTP, and pro­vides both in­ter­nal as well as ex­ter­nal in­ter­faces to Ku­ber­netes. Sched­uler: This tracks the re­source util­i­sa­tion of ev­ery node to en­sure that no ex­cess work­load is sched­uled with re­gard to avail­able re­sources. The sched­uler keeps track of re­source re­quire­ments, avail­abil­ity, and a va­ri­ety of user-pro­vided con­straints and pol­icy di­rec­tives like QoS, lo­ca­tion of data, etc.

Repli­ca­tion con­troller: This con­trols how many iden­ti­cal copies of a pod should be run­ning on the clus­ter.

Nodes: These are ma­chines that per­form the re­quested and as­signed tasks. The rub­ber­necks mas­ter con­trols all nodes con­nected in the clus­ter.

Kubelet: This is pri­mar­ily re­spon­si­ble for know­ing the state of each node with re­gard to its per­for­mance. It per­forms the tasks of start­ing, stop­ping and main­tain­ing ap­pli­ca­tion con­tain­ers as or­gan­ised by the con­trol plane. Proxy: This is re­garded as the im­ple­men­ta­tion of the net­work proxy and load bal­ancer, and pro­vides ab­strac­tion of the ser­vice level along with other net­work op­er­a­tions. It is also re­spon­si­ble for rout­ing traf­fic to the ap­pro­pri­ate con­tainer, based on the IP and port num­ber of the in­com­ing re­quest.

Pod: This is a group of one or more con­tain­ers de­ployed in a sin­gle node. All con­tain­ers in a pod share an IP ad­dress, IPC, host name and other re­sources. Pods ab­stract net­work and stor­age away from the un­der­ly­ing con­tainer, which helps in mak­ing con­tain­ers move across the clus­ter in a proper man­ner.

Ama­zon ECS (Elas­tic Con­tainer Ser­vice)

Ama­zon Elas­tic Con­tainer Ser­vice (Ama­zon ECS) is a highly scal­able and fast con­tainer man­age­ment ser­vice pro­vided by Ama­zon AWS (Ama­zon Web Ser­vices). It sup­ports Docker con­tain­ers and al­lows users to run ap­pli­ca­tions on a clus­ter of Ama­zon EC2 in­stances, elim­i­nat­ing the need for end users to in­stall, op­er­ate and scale their own clus­ter man­age­ment in­fra­struc­ture.

It al­lows users to launch and stop con­tainer-based ap­pli­ca­tions with sim­ple API calls, and to cre­ate state-of-art clus­ters via a cen­tralised ser­vice. Ama­zon ECS also helps users to sched­ule the place­ment of con­tain­ers across the clus­ter depend­ing on re­source needs, iso­la­tion poli­cies and avail­abil­ity re­quire­ments.

Ama­zon ECS can be used to cre­ate a con­sis­tent de­ploy­ment and build ex­pe­ri­ence. It can man­age and scale batch and ex­tract-trans­form-load (ETL) work­loads, and build so­phis­ti­cated ap­pli­ca­tion ar­chi­tec­tures on a mi­croser­vices model. Its main fea­tures are listed be­low.

Task def­i­ni­tion: The task def­i­ni­tion is a text file, in JSON for­mat. It de­scribes the con­tain­ers that to­gether form an ap­pli­ca­tion. Task def­i­ni­tions spec­ify var­i­ous pa­ram­e­ters for the ap­pli­ca­tion, e.g., con­tainer im­age repos­i­to­ries, ports, stor­age, etc.

Tasks and the sched­uler: A task is an in­stance of a task def­i­ni­tion, cre­ated at run­time on a con­tainer in­stance within the clus­ter. The task sched­uler is re­spon­si­ble for plac­ing tasks on con­tainer in­stances.

Ser­vice: A ser­vice is a group of tasks that is cre­ated and main­tained as in­stances of a task def­i­ni­tion. The sched­uler main­tains the de­sired count of tasks in the ser­vice. A ser­vice can op­tion­ally run be­hind a load bal­ancer, which dis­trib­utes traf­fic across the tasks that are as­so­ci­ated with the ser­vice. Clus­ter: A clus­ter is a log­i­cal group­ing of EC2 in­stances on which ECS tasks are run.

Con­tainer agent: The con­tainer agent runs on each EC2 in­stance within an ECS clus­ter. The agent sends teleme­try data about the in­stance’s tasks and re­source util­i­sa­tion to Ama­zon ECS. It will also start and stop tasks based on re­quests from ECS.

Im­age repos­i­tory: Ama­zon ECS down­loads con­tainer im­ages from con­tainer reg­istries, which may ex­ist within or out­side of AWS, such as an ac­ces­si­ble pri­vate Docker registry or Docker hub.

Fig­ure 2 high­lights the ar­chi­tec­ture of Ama­zon ECS.

The AWS ser­vices that are used with ECS are:

Elas­tic load bal­ancer: Routes traf­fic to con­tain­ers.

Elas­tic block store: Pro­vides per­sis­tent block stor­age for ECS tasks.

CloudWatch: Col­lects met­rics from ECS.

Vir­tual pri­vate cloud: ECS clus­ter runs within the vir­tual pri­vate cloud.

CloudTrail: Logs ECS API calls.

The ad­van­tages of Ku­ber­netes over Ama­zon ECS are:

Can be de­ployed on phys­i­cal hard­ware, over pub­lic clouds or any­where on an end user ma­chine.

Con­sists of a wide range of stor­age op­tions like SANs and pub­lic clouds.

Is sup­ported both by Google and Red Hat.

Has large com­mu­nity sup­port.

The fi­nal ver­dict

Ku­ber­netes is re­garded as the bet­ter orches­tra­tion con­tainer tool when com­pared to Ama­zon ECS, as it can be de­ployed any­where and has more hy­brid fea­tures with re­gard to scal­a­bil­ity and health checks, as com­pared to Ama­zon ECS.

Fig­ure 1: Ku­ber­netes ar­chi­tec­ture and com­po­nents

Fig­ure 2: Ama­zon ECS ar­chi­tec­ture and com­po­nents

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.