Mula Pebrero Tila sa amin ay isang kawalang-hanggan ang lumipas. Ang tanging bagay na nagpapaliwanag ng kaunti sa paghihiwalay ay na nakapasok kami sa Cloud Native Computing Foundation, na-certify ang aming pamamahagi ng Kubernetes sa ilalim ng Certified Kubernetes Conformance Program, at nailunsad din ito sa serbisyo ang pagpapatupad nito ng Kubernetes Cluster Autoscaler.
Oras na para sa ikatlong @Kubernetes Meetup! Sa madaling sabi:
- Sasabihin sa iyo ng Gazprombank kung paano nila ginagamit ang Kubernetes sa kanilang R&D para pamahalaan ang OpenStack;
- Mail.ru Cloud Solutions - kung paano sukatin ang mga application sa K8S gamit ang mga scaler at kung paano nila inihanda ang kanilang pagpapatupad ng Kubernetes Cluster Autoscaler;
- at ang ahensya ng Wunderman Thompson - kung paano tinutulungan sila ng Kubernetes na i-optimize ang kanilang diskarte sa pag-unlad at kung bakit mas marami ang Dev kaysa sa Ops sa DevOps.
Ang pulong ay magaganap sa Hunyo 21 (Biyernes) sa 18:30 sa Moscow office ng Mail.ru Group (Leningradsky Prospekt, 39, gusali 79). ay kinakailangan at magsasara sa Hunyo 20 nang 11:59 a.m. (o mas maaga kung maubusan ang espasyo).
"Kubernetes para sa mga developer: ilang Dev ang mayroon sa DevOps?"
Grigory Nikonov, Wunderman Thompson, Managing Director
Wala kaming mga kumpol ng 500 node. Wala kaming mahigpit na DevOps. Wala kaming nakalaang mga pangkat ng produkto. Ngunit marami kaming kawili-wiling proyekto at sagot sa mga tanong na nakita namin habang binubuo at sinusuportahan ang mga proyektong ito. Una sa lahat, kami ay mga developer at nakasanayan na naming gumawa ng mga tool sa aming sarili na aming gagamitin. Marahil ay tutulungan ka rin nila sa iyong trabaho.
Ang ahensya ng Wunderman Thompson ay isa sa mga pioneer sa pagbuo ng mga solusyon sa Internet sa Russia, at ngayon ay bumubuo ng parehong mga simpleng landing page at kumplikadong distributed system. Tumutulong ang Kubernetes na i-optimize ang diskarte sa pag-unlad, at tinutulungan ang mga customer ng ahensya na mag-host at magpatakbo ng mga nilikhang solusyon.
Sa mga distributed system na may malaking bilang ng mga integrasyon at panloob na bahagi, ang arkitektura ng microservices ay isang natural na tugon sa mga kinakailangan para sa pag-upgrade at pagpapanatili ng solusyon, ngunit ang paglipat sa naturang arkitektura ay nagdudulot ng isang buong serye ng mga problema na nauugnay sa pag-bersyon at paglalathala. Ang katotohanan na kami ay isang ahensya, at hindi isang dedikadong pangkat ng produkto, at hindi patuloy na pinapanatili ng aming mga developer ang naka-deploy na konteksto ng isang partikular na solusyon sa kanilang mga makina, nagpapataw ng sarili nitong mga kinakailangan sa muling paggawa ng kapaligiran ng pag-unlad, ang kakayahang gumawa ng mga pagbabago sa ilang mga koponan nang sabay-sabay at bumalik sa proyekto pagkatapos ng ilang oras. Bilang tugon sa mga hamong ito, bumuo kami ng mga proseso at tool na nagpapadali para sa aming mga developer at DevOps na bumuo at suportahan ang mga solusyon na kanilang ginagawa.
Malalaman mo kung bakit mas Dev ang DevOps kaysa sa Ops, at kung paano mababawasan ng katamaran ang oras at gastos sa pag-develop/suporta, pati na rin ang:
- kung paano binago ng Kubernetes ang paraan ng pagbuo namin ng mga proyekto;
- kung ano ang hitsura ng ikot ng buhay ng aming code;
- anong mga tool ang ginagamit namin para sa kinokontrol na pag-publish ng mga microservice;
- kung paano namin malulutas ang problema ng pag-assemble ng mga hindi na ginagamit na artifact;
- kung paano tayo nag-deploy sa cluster nang may kasiyahan.
"Pag-scale ng mga application gamit ang Kubernetes Cluster Autoscaler: ang mga nuances ng Autoscaler at ang pagpapatupad ng Mail.ru Cloud Solutions"
Alexander Chadin, Mail.ru Cloud Solutions, developer ng mga serbisyo ng PaaS
Sa mundo ngayon, inaasahan ng mga user na palaging online at laging available ang iyong application - at samakatuwid ay kayang pangasiwaan ang anumang daloy ng trapiko, gaano man ito kalaki. Nag-aalok ang Kubernetes ng medyo eleganteng solusyon na nagbibigay-daan sa iyong sukatin ang sarili ayon sa pagkarga - Kubernetes Cluster Autoscaler.
Sa pangkalahatan, sa Kubernetes mayroong dalawang uri ng pag-scale batay sa kung ano ang eksaktong sinusukat namin: mas maraming kopya ng application o higit pang mga mapagkukunan. Vertical scaling, kapag dinagdagan namin ang bilang ng mga replika ng application sa loob ng mga kasalukuyang node. At mas kumplikadong pahalang na pag-scale - pinapataas namin ang bilang ng mga node.
Sa pangalawang kaso, makakapagtaas kami ng higit pang mga kopya ng application - na titiyakin ang mataas na kakayahang magamit nito. Pag-uusapan natin ang tungkol sa pahalang na pag-scale gamit ang Cluster Autoscaler. Ito ay hindi lamang maaaring tumaas ngunit bawasan din ang bilang ng mga node depende sa pagkarga. Halimbawa, kapag tumaas ang load, babawasan mismo ng Autoscaler ang bilang ng mga node sa kinakailangang halaga at sa gayon ang pagbabayad para sa mga mapagkukunan ng provider.
Sa meetup, sasabihin namin sa iyo ang higit pa tungkol sa mga nuances ng Kubernetes Cluster Autoscaler, pati na rin kung anong mga paghihirap ang naranasan namin noong inilunsad ang aming pagpapatupad ng Cluster Autoscaler bilang bahagi ng serbisyo ng Mail.ru Cloud Containers. Matututo ka:
- anong mga scaler ang magagamit sa Kubernetes, ano ang mga tampok ng kanilang paggamit;
- kung ano ang dapat mong bigyang pansin kapag gumagamit ng mga scaler;
- kung paano namin pinag-segment ang mga node ayon sa mga availability zone gamit ang Node Groups;
- kung paano namin ipinatupad ang suporta para sa Kubernetes Cluster Autoscaler sa MCS.
“R&D sa Gazprombank: kung paano nakakatulong ang K8S na pamahalaan ang OpenStack”
Maxim Kletskin, Gazprombank, tagapamahala ng produkto
Sa isang mundo kung saan ang trend ay para sa lahat bilang isang serbisyo, Time-to-Market ang higit sa lahat. Ito ay kinakailangan upang mabilis na bumuo ng mga aplikasyon upang subukan ang mga hypotheses at makahanap ng mga bagong merkado sa sandali ng kanilang paunang pagbuo. Ang bilis ay lalong mahalaga para sa mga bangko, at ang mga bagong teknolohiya ay nakakatulong dito - lalo na, ang mga teknolohiya ng containerization at Kubernetes.
Si Maxim Kletskin ay isang product manager sa Gazprombank at gumagawa ng sandbox para sa paglulunsad ng mga pilot na produkto. Ang R&D ng Gazprombank ay nagsasagawa ng iba't ibang pag-aaral sa kanilang cloud, na OpenStack. Ang Kubernetes ay ginagamit dito sa dalawang anyo: 1) Kubernetes on Bare Metal bilang management layer ng OpenStack cloud at 2) K8S bilang OpenShift distribution para sa development.
Sa ulat ay pag-uusapan natin ang tungkol sa unang kaso at alamin kung paano ginagamit ng Gazprombank ang Kubernetes upang pamahalaan ang OpenStack. Kung titingnan mo ang arkitektura ng OpenStack, makikita mo na ito ay medyo atomic, kaya ang paggamit ng Kubernetes bilang layer ng pamamahala ng OpenStack ay tila napaka-interesante at lohikal. Gagawin din nitong mas madaling magdagdag ng mga node sa isang cluster ng OpenStack at mapataas ang pagiging maaasahan ng Control Plane. At, tulad ng icing sa cake, pasimplehin nito ang koleksyon ng telemetry mula sa cluster.
Matututo ka:
- bakit R&D bank: sinusubok at eksperimento namin;
- kung paano namin nilagyan ng container ang OpenStack;
- paano at bakit i-deploy ang OpenStack sa K8S.
Pagkatapos ng mga pagtatanghal, maayos kaming lilipat sa format na @Kuserbesanetes After-Party, at naghanda din kami ng ilang cool na anunsyo para sa iyo. Tiyaking magparehistro , sinusuri namin ang lahat ng aplikasyon sa loob ng ilang araw.
Tungkol sa mga bagong kaganapan sa serye ng @Kubernetes Meetup at iba pang mga kaganapan Agad naming inanunsyo sa aming Telegram channel:
Interesado na magsalita sa susunod na @Kubernetes Meetup? Maaari mong isumite ang iyong aplikasyon dito:
Pinagmulan: www.habr.com
