Kubernetes: open source kumpara sa vendor-specific

Kumusta, ang pangalan ko ay Dmitry Krasnov. Sa loob ng higit sa limang taon, pinangangasiwaan ko ang mga kumpol ng Kubernetes at bumubuo ng mga kumplikadong arkitektura ng microservice. Sa simula ng taong ito, naglunsad kami ng serbisyo para sa pamamahala ng mga kumpol ng Kubernetes batay sa Containerum. Sa pagkuha ng pagkakataong ito, sasabihin ko sa iyo kung ano ang Kubernetes at kung paano naiiba ang pagsasama sa isang vendor sa open source.

Upang magsimula sa, kung ano ang Kubernetes. Ito ay isang sistema para sa pamamahala ng mga lalagyan sa isang malaking bilang ng mga host. Mula sa Griyego, nga pala, isinalin ito bilang "pilot" o "helmsman." Orihinal na binuo ng Google at pagkatapos ay nag-donate bilang kontribusyon sa teknolohiya sa Cloud Native Computing Foundation, isang internasyonal na non-profit na organisasyon na pinagsasama-sama ang mga nangungunang developer, end user, at container technology provider sa mundo.

Pamahalaan ang isang malaking bilang ng mga lalagyan

Ngayon, alamin natin kung anong uri ng mga lalagyan ang mga ito. Ito ay isang application kasama ang buong kapaligiran nito - pangunahin ang mga aklatan kung saan nakasalalay ang programa. Ang lahat ng ito ay nakabalot sa mga archive at ipinakita sa anyo ng isang imahe na maaaring patakbuhin anuman ang operating system, nasubok at higit pa. Ngunit mayroong isang problema - ang pamamahala ng mga lalagyan sa isang malaking bilang ng mga host ay napakahirap. Iyon ang dahilan kung bakit nilikha ang Kubernetes.

Ang isang imahe ng lalagyan ay kumakatawan sa isang application kasama ang mga dependency nito. Ang application, ang mga dependency nito, at ang OS file system na imahe ay matatagpuan sa iba't ibang bahagi ng imahe, na tinatawag na mga layer. Maaaring gamitin muli ang mga layer para sa iba't ibang lalagyan. Halimbawa, maaaring gamitin ng lahat ng application sa isang kumpanya ang base layer ng Ubuntu. Kapag nagpapatakbo ng mga lalagyan, hindi na kailangang mag-imbak ng maraming kopya ng isang base layer sa host. Nagbibigay-daan ito sa iyo na i-optimize ang imbakan at paghahatid ng larawan.

Kapag gusto naming magpatakbo ng isang application mula sa isang lalagyan, ang mga kinakailangang layer ay ipinapatong sa isa't isa at isang overlay na file system ay nabuo. Ang isang layer ng pag-record ay inilalagay sa itaas, na aalisin kapag huminto ang lalagyan. Tinitiyak nito na kapag tumakbo ang lalagyan, ang application ay palaging magkakaroon ng parehong kapaligiran, na hindi mababago. Ginagarantiyahan nito ang muling paggawa ng kapaligiran sa iba't ibang host OS. Ubuntu man o CentOS, ang kapaligiran ay palaging magiging pareho. Bilang karagdagan, ang lalagyan ay nakahiwalay sa host gamit ang mga mekanismong nakapaloob sa Linux kernel. Ang mga application sa isang lalagyan ay hindi nakakakita ng mga file, proseso ng host at mga kalapit na lalagyan. Ang paghihiwalay na ito ng mga application mula sa host OS ay nagbibigay ng karagdagang layer ng seguridad.

Mayroong maraming mga tool na magagamit upang pamahalaan ang mga lalagyan sa isang host. Ang pinakasikat sa kanila ay ang Docker. Binibigyang-daan ka nitong ibigay ang buong ikot ng buhay ng mga lalagyan. Gayunpaman, ito ay gumagana lamang sa isang host. Kung kailangan mong pamahalaan ang mga container sa maraming host, maaaring gawing impiyerno ng Docker ang buhay para sa mga inhinyero. Iyon ang dahilan kung bakit nilikha ang Kubernetes.

Ang pangangailangan para sa Kubernetes ay tiyak dahil sa kakayahang pamahalaan ang mga pangkat ng mga container sa maraming host bilang isang uri ng iisang entity. Ang kasikatan ng system ay nagbibigay ng pagkakataong bumuo ng DevOps o Development Operations, kung saan ginagamit ang Kubernetes upang patakbuhin ang mga proseso ng mismong DevOps na ito.

Figure 1. Schematic na representasyon ng kung paano gumagana ang Kubernetes

Buong automation

Ang DevOps ay karaniwang ang automation ng proseso ng pag-unlad. Sa halos pagsasalita, ang mga developer ay nagsusulat ng code na na-upload sa repositoryo. Pagkatapos ang code na ito ay maaaring awtomatikong kolektahin kaagad sa isang lalagyan na may lahat ng mga aklatan, nasubukan at "inilunsad" sa susunod na yugto - Pagtatanghal, at pagkatapos ay kaagad sa Produksyon.

Kasama ang Kubernetes, pinapayagan ka ng DevOps na i-automate ang prosesong ito para mangyari ito nang halos walang partisipasyon mula sa mga developer mismo. Dahil dito, ang build ay makabuluhang mas mabilis, dahil ang developer ay hindi kailangang gawin ito sa kanyang computer - siya ay nagsusulat lamang ng isang piraso ng code, itinutulak ang code sa repository, pagkatapos kung saan ang pipeline ay inilunsad, na maaaring isama ang proseso. ng pagbuo, pagsubok, at paglulunsad. At nangyayari ito sa bawat commit, kaya patuloy na nangyayari ang pagsubok.

Kasabay nito, ang paggamit ng isang lalagyan ay nagbibigay-daan sa iyo upang matiyak na ang buong kapaligiran ng programang ito ay ilalabas sa produksyon nang eksakto sa anyo kung saan ito sinubukan. Iyon ay, walang mga problema tulad ng "may ilang mga bersyon sa pagsubok, ang iba sa produksyon, ngunit kapag na-install namin ang mga ito, lahat ay nahulog." At dahil ngayon ay mayroon tayong trend patungo sa microservice architecture, kapag sa halip na isang malaking application ay mayroong daan-daang maliliit, upang mapangasiwaan ang mga ito nang manu-mano, isang malaking kawani ng mga empleyado ang kakailanganin. Kaya naman ginagamit namin ang Kubernetes.

Mga kalamangan, kalamangan, kalamangan

Kung pinag-uusapan natin ang mga pakinabang ng Kubernetes bilang isang platform, kung gayon mayroon itong makabuluhang mga pakinabang mula sa punto ng view ng pamamahala ng isang arkitektura ng microservice.

• Pamamahala ng maramihang mga replika. Ang pinakamahalagang bagay ay ang pamamahala ng mga container sa maraming host. Higit sa lahat, pamahalaan ang maraming replika ng application sa mga container bilang isang entity. Salamat dito, ang mga inhinyero ay hindi kailangang mag-alala tungkol sa bawat indibidwal na lalagyan. Kung nag-crash ang isa sa mga container, makikita ito ng Kubernetes at muling i-restart ito.
• Cluster network. Ang Kubernetes ay mayroon ding tinatawag na cluster network na may sariling address space. Dahil dito, ang bawat pod ay may sariling address. Ang isang subpod ay nauunawaan bilang ang minimum na yunit ng istruktura ng isang cluster kung saan ang mga container ay direktang inilulunsad. Bilang karagdagan, ang Kubernetes ay may functionality na pinagsasama ang isang load balancer at Service Discovery. Binibigyang-daan ka nitong alisin ang manu-manong pamamahala ng IP address at italaga ang gawaing ito sa Kubernetes. At ang mga awtomatikong pagsusuri sa kalusugan ay makakatulong sa pagtukoy ng mga problema at pag-redirect ng trapiko sa mga gumaganang pod.
• Pamamahala ng configuration. Kapag namamahala ng malaking bilang ng mga application, nagiging mahirap na pamahalaan ang configuration ng application. Para sa layuning ito, ang Kubernetes ay may mga espesyal na mapagkukunan ng ConfigMap. Nagbibigay-daan sa iyo ang mga ito na mag-imbak ng mga configuration at ilantad ang mga ito sa mga pod kapag nagpapatakbo ng mga application. Ang mekanismong ito ay nagbibigay-daan sa amin upang magarantiya ang pagkakapare-pareho ng pagsasaayos sa hindi bababa sa sampu o isang daang mga replika ng aplikasyon.
• Patuloy na Dami. Ang mga lalagyan ay likas na hindi nababago at kapag ang lalagyan ay itinigil, lahat ng data na nakasulat sa file system ay masisira. Ngunit ang ilang mga application ay nag-iimbak ng data nang direkta sa disk. Upang malutas ang problemang ito, ang Kubernetes ay may pagpapagana sa pamamahala ng disk storage - Persistent Volumes. Gumagamit ang mekanismong ito ng panlabas na storage para sa data at maaaring maglipat ng patuloy na storage, block o file, sa mga container. Binibigyang-daan ka ng solusyong ito na mag-imbak ng data nang hiwalay sa mga manggagawa, na nagse-save sa kanila kung masira ang parehong mga manggagawang ito.
• Load Balancer. Kahit na sa Kubernetes pinamamahalaan namin ang mga abstract na entity tulad ng Deployment, StatefulSet, atbp., sa huli ay tumatakbo ang mga container sa mga regular na virtual machine o hardware server. Hindi sila perpekto at maaaring mahulog anumang oras. Makikita ito ng mga Kubernetes at ire-redirect ang panloob na trapiko sa iba pang mga replika. Ngunit ano ang gagawin sa trapiko na nagmumula sa labas? Kung ididirekta mo lang ang trapiko sa isa sa mga manggagawa, kung nag-crash ito, magiging hindi available ang serbisyo. Upang malutas ang problemang ito, ang Kubernetes ay may mga serbisyo tulad ng Load Balancer. Idinisenyo ang mga ito para awtomatikong mag-configure ng external na cloud balancer para sa lahat ng manggagawa sa cluster. Ang external balancer na ito ay nagdidirekta ng panlabas na trapiko sa mga manggagawa at sinusubaybayan ang kanilang katayuan mismo. Kung ang isa o higit pang mga manggagawa ay hindi magagamit, ang trapiko ay ire-redirect sa iba. Nagbibigay-daan ito sa iyo na lumikha ng mga serbisyong lubos na magagamit gamit ang Kubernetes.

Pinakamahusay na gumagana ang Kubernetes kapag nagpapatakbo ng mga arkitektura ng microservice. Posibleng ipatupad ang sistema sa klasikal na arkitektura, ngunit ito ay walang kabuluhan. Kung ang isang application ay hindi maaaring tumakbo sa maraming mga replika, kung gayon ano ang pagkakaiba nito - sa Kubernetes o hindi?

Open source Kubernetes

Ang open source na Kubernetes ay isang magandang bagay: Na-install ko ito at gumagana ito. Maaari mo itong i-deploy sa sarili mong mga server ng hardware, sa sarili mong imprastraktura, mag-install ng mga master at manggagawa kung saan tatakbo ang lahat ng application. At higit sa lahat, libre ang lahat ng ito. Gayunpaman, may mga nuances.

• Ang una ay ang pangangailangan para sa kaalaman at karanasan ng mga administrador at mga inhinyero na magpapakalat at susuporta sa lahat ng ito. Dahil ang kliyente ay tumatanggap ng kumpletong kalayaan sa pagkilos sa cluster, siya ang responsable para sa pagganap ng cluster mismo. At napakadaling sirain ang lahat dito.
• Ang pangalawa ay ang kakulangan ng mga integrasyon. Kung magpapatakbo ka ng Kubernetes nang walang sikat na virtualization platform, hindi mo makukuha ang lahat ng benepisyo ng program. Gaya ng paggamit ng Persistent Volumes at Load balancer services.

Larawan 2. arkitektura ng k8s

Kubernetes mula sa vendor

Ang pagsasama sa isang cloud provider ay nagbibigay ng dalawang opsyon:

• Una, ang isang tao ay maaaring mag-click lamang sa pindutan ng "lumikha ng cluster" at makakuha ng isang cluster na na-configure na at handa nang gamitin.
• Pangalawa, ang vendor mismo ang nag-install ng cluster at nagse-set up ng integration sa cloud.

Paano ito nangyayari dito. Tinukoy ng engineer na magsisimula ng cluster kung ilang manggagawa ang kailangan niya at kung anong mga parameter (halimbawa, 5 manggagawa, bawat isa ay may 10 CPU, 16 GB ng RAM at, halimbawa, 100 GB ng disk). Pagkatapos nito ay nakakakuha ito ng access sa nabuo nang cluster. Sa kasong ito, ang mga manggagawa kung saan inilunsad ang load ay ganap na inilipat sa kliyente, ngunit ang buong management plane ay nananatili sa ilalim ng responsibilidad ng vendor (kung ang serbisyo ay ibinigay ayon sa pinamamahalaang modelo ng serbisyo).

Gayunpaman, ang pamamaraan na ito ay may mga kakulangan nito. Dahil sa katotohanan na ang management plane ay nananatili sa vendor, ang vendor ay hindi nagbibigay ng ganap na access sa kliyente, at binabawasan nito ang flexibility sa pakikipagtulungan sa Kubernetes. Minsan nangyayari na gusto ng isang kliyente na magdagdag ng ilang partikular na pagpapagana sa Kubernetes, halimbawa, pagpapatotoo sa pamamagitan ng LDAP, ngunit hindi ito pinapayagan ng configuration ng management plane.

Figure 3. Halimbawa ng isang Kubernetes cluster mula sa isang cloud provider

Ano ang pipiliin: open source o vendor

Kaya, partikular ba ang Kubernetes open source o vendor? Kung kukuha kami ng open source na Kubernetes, gagawin ng user ang gusto niya dito. Ngunit may malaking pagkakataon na mabaril ang iyong sarili sa paa. Sa vendor ay mas mahirap, dahil ang lahat ay pinag-isipan at na-configure para sa kumpanya. Ang pinakamalaking kawalan ng open source na Kubernetes ay ang kinakailangan para sa mga espesyalista. Sa isang opsyon sa vendor, ang kumpanya ay napalaya mula sa sakit na ito, ngunit kailangan nitong magpasya kung babayaran ang mga espesyalista nito o ang vendor.

Well, ang mga kalamangan ay halata, ang mga kahinaan ay kilala rin. Isang bagay ang pare-pareho: Nilulutas ng Kubernetes ang maraming problema sa pamamagitan ng pag-automate ng pamamahala ng maraming container. At alin ang pipiliin, open source o vendor - lahat ay gumagawa ng sarili nilang desisyon.

Ang artikulo ay inihanda ni Dmitry Krasnov, nangungunang arkitekto ng serbisyo ng Containerum ng #CloudMTS provider

Pinagmulan: www.habr.com