Sa katapusan ng Mayo nagsagawa ng online na pagpupulong sa paksa . Pinag-usapan namin ang tungkol sa mga lalagyan, Kubernetes at orkestrasyon sa prinsipyo, pamantayan sa pagpili ng imprastraktura at marami pang iba. Ang mga kalahok ay nagbahagi ng mga kaso mula sa kanilang sariling pagsasanay.
Mga Kalahok:
- Evgeniy Potapov, CEO ng ITSumma. Mahigit sa kalahati ng mga customer nito ay maaaring lumipat na o gustong lumipat sa Kubernetes.
- Dmitry Stolyarov, CTO "Flant". May 10+ taong karanasan sa pagtatrabaho sa mga container system.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ex-RAO UES. Nangako siyang pag-usapan ang mga kaso sa "madugong" negosyo.
- Andrey Fedorovsky, CTO βNews360.comβMatapos bilhin ang kumpanya ng isa pang manlalaro, responsable siya para sa ilang proyekto at imprastraktura ng ML at AI.
- Ivan Kruglov, systems engineer, ex-Booking.com.Ang parehong tao na gumawa ng maraming sa Kubernetes gamit ang kanyang sariling mga kamay.
Mga Tema:
- Mga insight ng mga kalahok tungkol sa mga container at orkestrasyon (Docker, Kubernetes, atbp.); kung ano ang sinubukan sa pagsasanay o nasuri.
- Kaso: Ang kumpanya ay gumagawa ng isang plano sa pagpapaunlad ng imprastraktura sa loob ng maraming taon. Paano ginagawa ang desisyon kung bubuo (o i-migrate ang kasalukuyang) imprastraktura sa mga container at Kuber o hindi?
- Mga problema sa cloud-native world, kung ano ang kulang, isipin natin kung ano ang mangyayari bukas.
Isang kawili-wiling talakayan ang nangyari, ang mga opinyon ng mga kalahok ay ibang-iba at nagdulot ng napakaraming komento na nais kong ibahagi sa iyo. Kumain , at sa ibaba ay isang buod ng talakayan.
Ang Kubernetes ba ay isa nang pamantayan o mahusay na marketing?
βWe came to it (Kubernetes. - Ed.) nung wala pang nakakaalam. Pinuntahan namin siya kahit wala siya. Gusto namin noon" - Dmitry Stolyarov
Larawan mula sa Reddit.com
5-10 taon na ang nakalilipas mayroong isang malaking bilang ng mga tool, at walang iisang pamantayan. Bawat anim na buwan, isang bagong produkto ang lumitaw, o higit pa sa isa. Una Vagrant, pagkatapos ay Salt, Chef, Puppet,... βat itatayo mo muli ang iyong imprastraktura tuwing anim na buwan. Mayroon kang limang administrator na patuloy na abala sa muling pagsusulat ng mga config,β paggunita ni Andrey Fedorovsky. Naniniwala siya na ang Docker at Kubernetes ay "nagsisiksikan" sa iba. Ang Docker ay naging isang pamantayan sa nakalipas na limang taon, ang Kubernetes sa nakalipas na dalawang taon. At iyon ay mabuti para sa industriya..
Gustung-gusto ni Dmitry Stolyarov at ng kanyang koponan si Kuber. Nais nila ang gayong kasangkapan bago ito lumitaw, at dumating dito nang walang nakakaalam tungkol dito. Sa kasalukuyan, para sa kaginhawahan, hindi sila kumukuha ng kliyente kung naiintindihan nila na hindi nila ipapatupad ang Kubernetes kasama niya. Kasabay nito, ayon kay Dmitry, ang kumpanya ay may "maraming napakalaking kwento ng tagumpay tungkol sa muling paggawa ng kakila-kilabot na pamana."
Ang Kubernetes ay hindi lamang container orchestration, ito ay isang configuration management system na may binuo na API, isang networking component, L3 balancing at Ingress controllers, na ginagawang medyo madaling pamahalaan ang mga mapagkukunan, sukat at abstract mula sa mas mababang mga layer ng imprastraktura.
Sa kasamaang palad, sa ating buhay kailangan nating magbayad para sa lahat. At ang buwis na ito ay malaki, lalo na kung pinag-uusapan natin ang paglipat sa Kubernetes ng isang kumpanya na may binuo na imprastraktura, tulad ng pinaniniwalaan ni Ivan Kruglov. Maaari siyang malayang magtrabaho sa isang kumpanyang may tradisyonal na imprastraktura at sa Kuber. Ang pangunahing bagay ay upang maunawaan ang mga katangian ng kumpanya at merkado. Ngunit, halimbawa, para kay Evgeny Potapov, na mag-generalize ng Kubernetes sa anumang tool sa orkestrasyon ng lalagyan, ang ganoong tanong ay hindi lumabas.
Si Evgeniy ay gumuhit ng isang pagkakatulad sa sitwasyon noong 1990s, nang lumitaw ang object-oriented programming bilang isang paraan ng programming complex application. Sa oras na iyon, nagpatuloy ang debate at lumitaw ang mga bagong tool upang suportahan ang OOP. Pagkatapos ay lumitaw ang mga microservice bilang isang paraan upang lumayo sa monolitikong konsepto. Ito, sa turn, ay humantong sa paglitaw ng mga lalagyan at mga tool sa pamamahala ng lalagyan. "Sa palagay ko ay malapit na tayong dumating sa isang oras na walang tanong tungkol sa kung ito ay nagkakahalaga ng pagsulat ng isang maliit na microservice application, ito ay isusulat bilang isang microservice bilang default," naniniwala siya. Gayundin, ang Docker at Kubernetes ay magiging karaniwang solusyon nang hindi nangangailangan ng pagpili.
Ang problema ng mga database sa stateless
Larawan ni
Sa ngayon, maraming mga recipe para sa pagpapatakbo ng mga database sa Kubernetes. Kahit na kung paano paghiwalayin ang bahagi na gumagana sa I/O disk mula, sa kondisyon, ang bahagi ng application ng database. Posible ba na sa hinaharap ang mga database ay magbabago nang labis na maihahatid sila sa isang kahon, kung saan ang isang bahagi ay isasaayos sa pamamagitan ng Docker at Kubernetes, at sa isa pang bahagi ng imprastraktura, sa pamamagitan ng hiwalay na software, ang bahagi ng imbakan ay ibibigay. ? Magbabago ba ang mga base bilang isang produkto?
Ang paglalarawan na ito ay katulad ng pamamahala ng pila, ngunit ang mga kinakailangan para sa pagiging maaasahan at pag-synchronize ng impormasyon sa mga tradisyonal na database ay mas mataas, naniniwala si Andrey. Ang ratio ng cache hit sa mga normal na database ay nananatili sa 99%. Kung ang isang manggagawa ay bumaba, isang bago ay inilunsad, at ang cache ay "nagpapainit" mula sa simula. Hanggang sa uminit ang cache, dahan-dahang gumagana ang manggagawa, na nangangahulugang hindi ito ma-load ng user load. Habang walang pag-load ng gumagamit, ang cache ay hindi umiinit. Ito ay isang mabisyo na bilog.
Sa panimula ay hindi sumasang-ayon si Dmitry - malulutas ng mga korum at sharding ang problema. Ngunit iginiit ni Andrey na ang solusyon ay hindi angkop para sa lahat. Sa ilang sitwasyon, angkop ang quorum, ngunit naglalagay ito ng karagdagang load sa network. Ang isang database ng NoSQL ay hindi angkop sa lahat ng kaso.
Ang mga kalahok sa meetup ay hinati sa dalawang kampo.
Nagtalo sina Denis at Andrey na ang lahat ng nakasulat sa disk - mga database at iba pa - ay imposibleng gawin sa kasalukuyang ecosystem ng Kuber. Imposibleng mapanatili ang integridad at pagkakapare-pareho ng data ng produksyon sa Kubernetes. Ito ay isang pangunahing tampok. Solusyon: hybrid na imprastraktura.
Kahit na ang mga modernong cloud native na database tulad ng MongoDB at Cassandra, o mga queue ng mensahe tulad ng Kafka o RabbitMQ, ay nangangailangan ng patuloy na mga tindahan ng data sa labas ng Kubernetes.
Tutol si Evgeniy: "Ang mga base sa Kubera ay isang malapit-Russian, o malapit sa negosyo na pinsala, na nauugnay sa katotohanan na walang Cloud Adoption sa Russia." Ang mga maliliit o katamtamang laki ng mga kumpanya sa Kanluran ay Cloud. Ang mga database ng Amazon RDS ay mas madaling gamitin kaysa sa pag-usisa sa Kubernetes mismo. Sa Russia ginagamit nila ang Kuber "on-premise" at naglilipat ng mga base dito kapag sinusubukan nilang alisin ang zoo.
Hindi rin sumang-ayon si Dmitry sa pahayag na walang mga database ang maaaring itago sa Kubernetes: "Ang base ay iba sa base. At kung itulak mo ang isang higanteng relational database, kung gayon sa anumang pagkakataon. Kung itulak mo ang isang bagay na maliit at cloud native, na nakahanda para sa semi-ephemeral na buhay, magiging maayos ang lahat." Binanggit din ni Dmitry na ang mga tool sa pamamahala ng database ay hindi handa para sa alinman sa Docker o Kuber, kaya't lumitaw ang malalaking paghihirap.
Si Ivan, naman, ay sigurado na kahit na mag-abstract tayo mula sa mga konsepto ng stateful at stateless, ang ecosystem ng mga enterprise solution sa Kubernetes ay hindi pa handa. Sa Kuber, mahirap mapanatili ang mga kinakailangan sa pambatasan at regulasyon. Halimbawa, imposibleng gumawa ng solusyon sa pagbibigay ng pagkakakilanlan kung saan kinakailangan ang mahigpit na garantiya ng pagkakakilanlan ng server, hanggang sa hardware na ipinasok sa mga server. Ang lugar na ito ay umuunlad, ngunit wala pang solusyon.
Ang mga kalahok ay hindi sumang-ayon, kaya walang mga konklusyon na gagawin sa bahaging ito. Magbigay tayo ng ilang praktikal na halimbawa.
Kaso 1. Cybersecurity ng isang "mega-regulator" na may mga base sa labas ng Kubera
Sa kaso ng isang binuo na sistema ng cybersecurity, ang paggamit ng mga lalagyan at orkestra ay ginagawang posible upang labanan ang mga pag-atake at panghihimasok. Halimbawa, sa isang mega-regulator, si Denis at ang kanyang team ay nagpatupad ng kumbinasyon ng isang orkestra na may sinanay na serbisyo ng SIEM na nagsusuri ng mga log sa real time at tinutukoy ang proseso ng isang pag-atake, pag-hack o pagkabigo. Sa kaganapan ng isang pag-atake, isang pagtatangkang maglagay ng isang bagay, o sa kaganapan ng isang ransomware virus invasion, ito, sa pamamagitan ng orchestrator, ay kumukuha ng mga lalagyan na may mga application nang mas mabilis kaysa sa sila ay nahawahan, o mas mabilis kaysa sa pag-atake sa kanila ng umaatake.
Kaso 2. Bahagyang paglipat ng mga database ng Booking.com sa Kubernetes
Sa Booking.com, ang pangunahing database ay MySQL na may asynchronous replication - mayroong master at isang buong hierarchy ng mga alipin. Sa oras na umalis si Ivan sa kumpanya, isang proyekto ang inilunsad upang ilipat ang mga alipin na maaaring "pagbaril" na may tiyak na pinsala.
Bilang karagdagan sa pangunahing base, mayroong pag-install ng Cassandra na may self-written orchestration, na isinulat bago pa man pumasok si Kuber sa mainstream. Walang mga problema sa bagay na ito, ngunit ito ay paulit-ulit sa mga lokal na SSD. Ang malayong imbakan, kahit na sa loob ng parehong data center, ay hindi ginagamit dahil sa problema ng mataas na latency.
Ang ikatlong klase ng mga database ay ang Booking.com search service, kung saan ang bawat service node ay isang database. Nabigo ang mga pagtatangkang ilipat ang serbisyo sa paghahanap sa Kuber, dahil ang bawat node ay 60-80 GB ng lokal na storage, na mahirap "iangat" at "magpainit".
Bilang resulta, ang search engine ay hindi inilipat sa Kubernetes, at hindi iniisip ni Ivan na magkakaroon ng mga bagong pagtatangka sa malapit na hinaharap. Ang database ng MySQL ay inilipat sa kalahati: mga Alipin lamang, na hindi natatakot na "pagbaril". Nakaayos na si Cassandra.
Ang pagpili ng imprastraktura bilang isang gawain na walang pangkalahatang solusyon
Larawan ni
Sabihin nating mayroon tayong bagong kumpanya, o isang kumpanya kung saan ang bahagi ng imprastraktura ay itinayo sa lumang paraan. Bumubuo ito ng plano sa pagpapaunlad ng imprastraktura sa loob ng maraming taon. Paano ginagawa ang desisyon kung magtatayo ng imprastraktura sa mga container at Kuber o hindi?
Ang mga kumpanyang lumalaban para sa mga nanosecond ay hindi kasama sa talakayan. Ang malusog na konserbatismo ay nagbabayad sa mga tuntunin ng pagiging maaasahan, ngunit mayroon pa ring mga kumpanya na dapat isaalang-alang ang mga bagong diskarte.
Ivan: "Talagang magsisimula ako ng isang kumpanya sa cloud ngayon, dahil lang mas mabilis ito," bagaman hindi kinakailangang mas mura. Sa pag-unlad ng venture capitalism, ang mga startup ay walang malaking problema sa pera, at ang pangunahing gawain ay upang masakop ang merkado.
Iyon ang opinyon ni Ivan ang pagbuo ng kasalukuyang imprastraktura ay isang pamantayan sa pagpili. Kung mayroong isang seryosong pamumuhunan sa nakaraan, at ito ay gumagana, kung gayon walang punto sa muling paggawa nito. Kung ang imprastraktura ay hindi binuo, at may mga problema sa mga tool, seguridad at pagsubaybay, kung gayon makatuwirang tingnan ang isang ipinamahagi na imprastraktura.
Ang buwis ay kailangang bayaran sa anumang kaso, at babayaran ni Ivan ang isa na nagpapahintulot sa kanya na magbayad ng mas mababa sa hinaharap. "Sapagkat dahil lamang sa katotohanang nakasakay ako sa tren na dinadaanan ng iba, mas malayo pa ang lalakbayin ko kaysa sa uupo ako sa ibang tren, kung saan ako mismo ang maglalagay ng gasolina."sabi ni Ivan. Kapag ang kumpanya ay bago, at ang mga kinakailangan sa latency ay sampu-sampung millisecond, pagkatapos ay titingnan ni Ivan ang "mga operator" kung saan ang mga klasikal na database ay "nakabalot" ngayon. Nagtataas sila ng chain ng pagtitiklop, na nagpapalit ng sarili sa kaso ng failover, atbp...
Para sa isang maliit na kumpanya na may ilang server, walang saysay ang Kubera," sabi ni Andrey. Ngunit kung plano nitong lumaki sa daan-daang mga server o higit pa, kailangan nito ng automation at isang sistema ng pamamahala ng mapagkukunan. 90% ng mga kaso ay katumbas ng halaga. Bukod dito, anuman ang antas ng pagkarga at mga mapagkukunan. Makatuwiran para sa lahat, mula sa mga startup hanggang sa malalaking kumpanya na may milyun-milyong audience, na unti-unting tumingin sa mga produkto ng container orchestration. "Oo, ito talaga ang hinaharap," sigurado si Andrey.
Binalangkas ni Denis ang dalawang pangunahing pamantayan - scalability at katatagan ng operasyon. Pipiliin niya ang mga tool na pinakaangkop para sa gawain. "Maaaring ito ay isang walang pangalan na binuo sa iyong mga tuhod, at mayroon itong Nutanix Community Edition. Ito ay maaaring pangalawang linya sa anyo ng isang application sa Kuber na may database sa backend, na ginagaya at may tinukoy na mga parameter ng RTO at RPO" (mga layunin sa oras ng pagbawi/punto - tinatayang).
Natukoy ni Evgeniy ang isang posibleng problema sa mga tauhan. Sa ngayon, wala pang mataas na kwalipikadong mga espesyalista sa merkado na nauunawaan ang "lakas ng loob." Sa katunayan, kung ang napiling teknolohiya ay luma na, kung gayon mahirap na kumuha ng sinuman maliban sa mga nasa katanghaliang-gulang na nababato at pagod sa buhay. Bagama't naniniwala ang ibang kalahok na ito ay usapin ng pagsasanay ng mga tauhan.
Kung ilalagay namin ang tanong ng pagpili: upang maglunsad ng isang maliit na kumpanya sa Public Cloud na may mga database sa Amazon RDS o "sa premise" na may mga database sa Kubernetes, pagkatapos sa kabila ng ilang mga pagkukulang, ang pinili ng mga kalahok ay Amazon RDS.
Dahil ang karamihan sa mga tagapakinig ng meetup ay hindi mula sa "madugong" enterprise, kung gayon mga distributed solutions ang dapat nating pagsikapan. Ang mga sistema ng pag-iimbak ng data ay dapat na ipamahagi, maaasahan, at lumikha ng latency na sinusukat sa mga yunit ng millisecond, sampu sa pinakamaramingβ, buod ni Andrey.
Pagtatasa sa Paggamit ng Kubernetes
Ang tagapakinig na si Anton Zhbankov ay nagtanong ng isang tanong sa bitag sa mga apologist ng Kubernetes: paano ka pumili at nagsagawa ng feasibility study? Bakit Kubernetes, bakit hindi virtual machine, halimbawa?
Larawan ni
Sinagot ito nina Dmitry at Ivan. Sa parehong mga kaso, sa pamamagitan ng pagsubok at pagkakamali, isang pagkakasunud-sunod ng mga desisyon ang ginawa, bilang isang resulta kung saan ang parehong mga kalahok ay dumating sa Kubernetes. Ngayon ang mga negosyo ay nagsisimula nang nakapag-iisa na bumuo ng software na makatuwirang ilipat sa Kuber. Hindi namin pinag-uusapan ang mga klasikong sistema ng third-party, gaya ng 1C. Tumutulong ang Kubernetes kapag kailangan ng mga developer na mabilis na gumawa ng mga release, na may walang tigil na Patuloy na Pagpapabuti.
Sinubukan ng koponan ni Andrey na lumikha ng isang scalable cluster batay sa mga virtual machine. Ang mga node ay nahulog tulad ng mga domino, na kung minsan ay humantong sa pagbagsak ng kumpol. "Theoretically, maaari mong tapusin ito at suportahan ito sa iyong mga kamay, ngunit ito ay nakakapagod. At kung mayroong isang solusyon sa merkado na nagpapahintulot sa iyo na magtrabaho sa labas ng kahon, pagkatapos ay masaya kaming gawin ito. At nagpalit kami bilang resulta," sabi ni Andrey.
Mayroong mga pamantayan para sa naturang pagsusuri at pagkalkula, ngunit walang makapagsasabi kung gaano katumpak ang mga ito sa totoong hardware na gumagana. Para sa mga kalkulasyon, mahalaga din na maunawaan ang bawat tool at ecosystem, ngunit hindi ito posible.
Ano ang naghihintay sa atin
Larawan ni
Habang umuunlad ang teknolohiya, lumilitaw ang parami nang parami ng magkakaibang piraso, at pagkatapos ay nagaganap ang isang phase transition, lumilitaw ang isang vendor na pumatay ng sapat na kuwarta para magsama-sama ang lahat sa isang tool.
Sa palagay mo ba ay darating ang panahon na magkakaroon ng tool tulad ng Ubuntu para sa mundo ng Linux? Marahil ay may kasamang Kuber sa isang containerization at orchestration tool. Mapapadali nito ang pagbuo ng mga on-premise na ulap.
Ang sagot ay ibinigay ni Ivan: "Ginagawa na ngayon ng Google ang Anthos - ito ang kanilang naka-package na alok na nagde-deploy ng cloud at kasama ang Kuber, Service Mesh, pagsubaybay - lahat ng hardware na kailangan para sa mga on-premise na microservice." Malapit na tayo sa future."
Binanggit din ni Denis ang Nutanix at VMWare kasama ang produktong vRealize Suite, na maaaring makayanan ang isang katulad na gawain nang walang containerization.
Ibinahagi ni Dmitry ang kanyang opinyon na ang pagbabawas ng "sakit" at pagbabawas ng mga buwis ay dalawang lugar kung saan maaari nating asahan ang mga pagpapabuti.
Upang ibuod ang talakayan, itinatampok namin ang mga sumusunod na problema ng modernong imprastraktura:
- Agad na natukoy ng tatlong kalahok ang isang problema sa stateful.
- Iba't ibang isyu sa suporta sa seguridad, kabilang ang posibilidad na magkakaroon ng maraming bersyon ng Python, mga server ng application, at mga bahagi ang Docker.
Ang sobrang paggastos, na mas mabuting pag-usapan sa isang hiwalay na pagpupulong.
Ang isang hamon sa pag-aaral bilang orkestra ay isang kumplikadong ecosystem.
Ang isang karaniwang problema sa industriya ay ang maling paggamit ng mga tool.Ang natitirang mga konklusyon ay nasa iyo. May pakiramdam pa rin na hindi madali para sa kumbinasyon ng Docker+Kubernetes na maging isang "sentral" na bahagi ng system. Halimbawa, ang mga operating system ay naka-install muna sa hardware, na hindi masasabi tungkol sa mga lalagyan at orkestrasyon. Marahil sa hinaharap, ang mga operating system at container ay magsasama sa software sa pamamahala ng ulap.
Larawan niGusto kong samantalahin ang pagkakataong ito para kamustahin ang aking ina at ipaalala sa iyo na mayroon tayong Facebook group , channel na may mga kagiliw-giliw na publikasyon mula sa iba't ibang mga tech na blog. At ang aking channel , kung saan pinag-uusapan ko ang tungkol sa pamamahala ng pag-unlad sa mga kumpanya ng produkto.
Pinagmulan: www.habr.com