Мамыр айының соңында тақырыбында онлайн кездесу өткізді . Біз контейнерлер, Кубернеталар және жалпы оркестрлер, инфрақұрылымды таңдау критерийлері және т.б. туралы айттық. Қатысушылар өздерінің тәжірибелерімен бөлісті.
Қатысушылар:
- Евгений Потапов, ITSumma бас директоры. Оның тұтынушыларының жартысынан көбі қазірдің өзінде көшіп жатыр немесе Кубернетеске көшкісі келеді.
- Дмитрий Столяров, Фланттың техникалық директоры. Контейнер жүйелерімен 10 жылдан астам тәжірибесі бар.
- Денис Ремчуков (ака Эрик Олдманн), COO argotech.io, бұрынғы RAO EES. Ол «қанды» кәсіпорындағы істерді айтып беруге уәде берді.
- Андрей Федоровский, News360.com техникалық директорыКомпанияны басқа ойыншы сатып алғаннан кейін ол бірқатар ML және AI жобалары мен инфрақұрылымына жауапты.
- Иван Круглов, жүйе инженері, бұрынғы Booking.com.Кубернетеспен өз қолымен көп нәрсе жасаған сол адам.
Тақырыптар:
- Қатысушылардың контейнерлер мен оркестрлер туралы түсініктері (Docker, Kubernetes және т.б.); тәжірибеде сыналған немесе талданған.
- Жағдай: Компания бірнеше жылдар бойы инфрақұрылымды дамыту жоспарын құруда. Контейнерлер мен Куберде инфрақұрылымды салу (немесе ағымдағы аудару) туралы шешім қалай қабылданады?
- Бұлт-туған дүниедегі мәселелер, не жетіспейді, ертең не болатынын армандаймыз.
Қызықты пікірталас болды, қатысушылардың пікірлері әртүрлі болды және көптеген пікірлер тудырды, сондықтан мен оларды сіздермен бөліскім келеді. Тамақ , ал төменде талқылаудан үзінді берілген.
Kubernetes қазірдің өзінде стандартты немесе керемет маркетинг пе?
«Біз оған (Кубернетес. – Ред.) ол туралы әлі ешкім білмеген кезде келдік. Біз оған ол кеткенде де келдік. Біз оны бұрын қалаған едік ». Дмитрий Столяров
Фото reddit.com сайтынан
Шамамен 5-10 жыл бұрын құралдардың саны өте көп болды және бірыңғай стандарт болмады. Әр алты ай сайын жаңа өнім пайда болды, тіпті біреуден көп. Алдымен қаңғыбас, содан кейін Тұз, аспаз, қуыршақ,... «және сіз алты ай сайын инфрақұрылымыңызды қалпына келтіресіз. Сізде конфигурацияларды қайта жазумен үнемі айналысатын бес әкімші бар », - деп еске алады Андрей Федоровский. Ол Докер мен Кубернетес қалғандарын «жаншылды» деп санайды. Докер соңғы бес жылда стандартқа айналды, соңғы екі жылда Kubernetes. Және бұл салаға пайдалы.
Дмитрий Столяров және оның командасы Куберді жақсы көреді. Олар мұндай аспапты ол болмай тұрып-ақ қалап, оны әлі ешкім білмеген кезде келді. Қазіргі уақытта ыңғайлы болу үшін олар клиентті қабылдамайды, егер олар одан Kubernetes қолданбайтынын түсінсе. Сонымен қатар, Дмитрийдің айтуынша, компанияда «қорқынышты мұраны қайта өңдеудің көптеген алып табыстары бар».
Kubernetes тек контейнерлік оркестрлеу ғана емес, ол әзірленген API, желілік құрамдас, L3 баланстау және Ingress контроллері бар конфигурацияны басқару жүйесі болып табылады, бұл ресурстарды басқаруды, масштабтауды және инфрақұрылымның төменгі қабаттарынан абстракциялауды салыстырмалы түрде жеңілдетеді.
Өкінішке орай, біз өмірімізде бәрін төлеуіміз керек. Және бұл салық үлкен, әсіресе инфрақұрылымы дамыған компанияның Кубернетеске ауысуы туралы айтатын болсақ, Иван Кругловтың айтуынша. Ол дәстүрлі инфрақұрылымы бар компанияда да, Кубермен де еркін жұмыс істей алды. Ең бастысы - компанияның және нарықтың сипаттамаларын түсіну. Бірақ, мысалы, Кубернетесті кез келген контейнерлік оркестрлік құралға жалпылайтын Евгений Потапов үшін мұндай сұрақтың қажеті жоқ.
Евгений 1990 жылдардағы жағдайға ұқсастық жасады, ол кезде объектілі-бағытталған бағдарламалау күрделі қолданбаларды бағдарламалау тәсілі ретінде пайда болды. Сол кезде пікірталас тоқтаған жоқ және OOP қолдайтын жаңа құралдар пайда болды. Содан кейін монолитті тұжырымдамадан құтылудың жолы ретінде микросервистер пайда болды. Бұл өз кезегінде контейнерлер мен оларды басқару құралдарының пайда болуына әкелді. «Менің ойымша, жақын арада біз микросервис шағын қосымшасын жазудың қажеті жоқ па деген сұрақ туындамайтын уақытқа келеді, ол әдепкі бойынша микросервис ретінде жазылады», - деп есептейді ол. Сол сияқты, Docker және Kubernetes таңдаусыз әдепкі шешімге айналады.
Азаматтығы жоқ деректер қорының мәселесі
Суретке түсіру
Қазіргі уақытта Kubernetes-те дерекқорларды іске қосу үшін көптеген рецепттер бар. Тіпті енгізу-шығару дискісімен жұмыс істейтін бөлікті, шартты түрде базаның қолданбалы бөлігінен қалай бөлуге болады. Болашақта дерекқорлар соншалықты өзгереді, олар қорапта жеткізіледі, оның бір бөлігі Docker және Kubernetes арқылы реттеледі, ал инфрақұрылымның басқа бөлігінде бөлек бағдарламалық қамтамасыз ету арқылы сақтау бөлігі қамтамасыз етіледі. ? Негіздер өнім ретінде өзгереді ме?
Бұл сипаттама кезекті басқаруға ұқсас, бірақ дәстүрлі дерекқорлардағы ақпараттың сенімділігі мен синхрондылығына қойылатын талаптар әлдеқайда жоғары, деп есептейді Андрей. Кәдімгі дерекқорлардағы кэшті пайдалану коэффициенті 99% деңгейінде сақталады. Егер жұмысшы төмендеп кетсе, жаңасы іске қосылады және кэш нөлден бастап «жылытылады». Кэш жылынбаған кезде, жұмысшы баяу жұмыс істейді, яғни оны пайдаланушы жүктемесімен жүктеу мүмкін емес. Пайдаланушы жүктемесі болмаған кезде, кэш жылытылмайды. Бұл тұйық шеңбер.
Дмитрий түбегейлі келіспейді - кворумдар мен бөлу мәселені шешеді. Бірақ Андрей бұл шешім барлығына бірдей емес екенін айтады. Кейбір жағдайларда кворум жақсы, бірақ ол желіге қосымша жүктеме жасайды. NoSQL базасы барлық жағдайларда қолайлы емес.
Кездесуге қатысушылар екі лагерьге бөлінді.
Денис пен Андрей қазіргі Кубер экожүйесінде дискіге жазылатын барлық нәрселерді - дерекқорларды және т.б. жасау мүмкін емес деп санайды. Kubernetes-те өнімді деректердің тұтастығы мен дәйектілігін сақтау мүмкін емес. Бұл негізгі қасиет. Шешім: гибридті инфрақұрылым.
Тіпті MongoDB және Cassandra сияқты заманауи бұлттық дерекқорлар немесе Kafka немесе RabbitMQ сияқты хабарлар кезегі Кубернетестен тыс тұрақты деректер қоймаларын қажет етеді.
Евгений: «Куберадағы базалар Ресейге жақын немесе жақын кәсіпорын жарақаты болып табылады, бұл Ресейде бұлтты қабылдаудың жоқтығына байланысты». Батыстағы шағын немесе орта компаниялар бұлтты болып табылады. Amazon RDS дерекқорларын пайдалану Kubernetes-пен өзіңіз араласудан оңайырақ. Ресейде олар Куберді «жергілікті» пайдаланады және хайуанаттар бағынан құтылуға тырысқанда, оған базаларды береді.
Сондай-ақ Дмитрий Кубернетесте дерекқорды сақтау мүмкін емес деген мәлімдемемен келіспейді: «База басқа. Егер сіз алып реляциялық дерекқорды итерсеңіз, онда ешқандай жағдайда. Егер сіз жартылай уақытша өмірге моральдық тұрғыдан дайын кішкентай және бұлтты туған нәрсені итерсеңіз, бәрі жақсы болады ». Дмитрий сонымен қатар дерекқорды басқару құралдары Docker немесе Kuber үшін дайын емес, сондықтан үлкен қиындықтар бар екенін айтты.
Иван, өз кезегінде, егер біз штаттық және азаматтығы жоқ ұғымдарды елемейтін болсақ та, Kubernetes-тегі кәсіпорын шешімдерінің экожүйесі әлі дайын емес екеніне сенімді. Кубермен заң шығарушы және реттеуші органдардың талаптарын орындау қиын. Мысалы, серверлерге енгізілген аппараттық құралға дейін сервер идентификациясының күшті кепілдіктерін талап ететін сәйкестендіруді қамтамасыз ету шешімін жасау мүмкін емес. Бұл сала дамып келеді, бірақ әзірге шешімі жоқ.
Қатысушылар келісе алмады, сондықтан бұл бөлімде ешқандай қорытынды жасалмайды. Бір-екі практикалық мысалды алайық.
1-жағдай. Куберден тыс базалары бар «мега-регулятордың» киберқауіпсіздігі
Дамыған киберқауіпсіздік жүйесі жағдайында контейнерлер мен оркестрлерді пайдалану шабуылдар мен басып кірулерді болдырмауға мүмкіндік береді. Мысалы, бір мегарегуляторда Денис және оның командасы нақты уақытта журналдарды талдайтын және шабуыл, бұзу немесе сәтсіздік процесін анықтайтын оқытылған SIEM қызметі бар оркестрлер тобын енгізді. Шабуыл, бірдеңе қою әрекеті немесе ransomware вирусы енген жағдайда, ол оркестр арқылы бағдарламалары бар контейнерлерді вирус жұққаннан жылдамырақ немесе шабуылдаушы шабуыл жасағаннан жылдамырақ көтереді.
2-жағдай. Booking.com дерекқорларының Кубернетеске жартылай көшуі
Booking.com сайтында негізгі деректер базасы асинхронды репликациясы бар MySQL болып табылады - құлдардың шебері және тұтас иерархиясы бар. Иван компаниядан кеткен кезде құлдарды ауыстыру жобасы іске қосылды, оны кейбір зақымданумен «атып тастауға» болады.
Негізгі базадан басқа, Кубер негізгі ағымға енгенге дейін жазылған, өздігінен жазылған оркестрі бар Кассандра инсталляциясы бар. Осыған байланысты проблемалар жоқ, бірақ ол жергілікті SSD дискілерінде тұрақты. Қашықтағы жад, тіпті бір деректер орталығында, жоғары кідіріс мәселелеріне байланысты пайдаланылмайды.
Дерекқорлардың үшінші класы - Booking.com іздеу қызметі, мұнда әрбір қызмет түйіні дерекқор болып табылады. Іздеу қызметін Kuber-ге тасымалдау әрекеттері сәтсіз аяқталды, өйткені әрбір түйін 60-80 ГБ жергілікті жадты құрайды, оны «көтеру» және «жылыту» қиын.
Нәтижесінде іздеу жүйесі Кубернетеске берілмеді және Иван жақын арада жаңа әрекеттер болады деп ойламайды. MySQL деректер базасы екі есеге ауыстырылды: тек «атып кетуден» қорықпайтын құлдар ғана. Кассандра тамаша «үйреніп кетті».
Жалпы шешімі жоқ міндет ретінде инфрақұрылымды таңдау
Суретке түсіру
Бізде жаңа компания немесе инфрақұрылымның бір бөлігі ескі әдіспен салынған компания бар делік. Ол жылдарға инфрақұрылымды дамыту жоспарын жасайды. Контейнерлер мен Куберде инфрақұрылым салу туралы шешім қалай қабылданады?
Наносекундтар үшін күресетін компаниялар талқылаудан шығарылады. Салауатты консерватизм сенімділік тұрғысынан өтеледі, бірақ соған қарамастан, жаңа тәсілдерді қарастыратын компаниялар бар.
Иван: «Мен бұлтты компанияны енді ашатын едім, өйткені ол жылдамырақ», бірақ арзанырақ емес. Венчурлық капитализмнің дамуымен стартаптарда ақшамен үлкен проблемалар болмайды, ал басты міндет – нарықты жаулап алу.
Иван осылай деп есептейді қазіргі инфрақұрылымды дамыту іріктеу критерийі болып табылады. Егер бұрын елеулі инвестициялар болса және ол жұмыс істесе, оны қайта жасаудың қажеті жоқ. Егер инфрақұрылым дамымаған болса және құралдармен, қауіпсіздікпен және мониторингпен проблемалар туындаса, онда бөлінген инфрақұрылымды қарастырған жөн.
Салықты бәрібір төлеу керек еді, ал Иван болашақта азырақ төлеуге мүмкіндік беретін салықты төлейтін еді. "Өйткені мен басқалар айдап бара жатқан пойызда болғандықтан, мен өзім жанармай құюға тура келетін басқа пойызға отырсам, әлдеқайда алыс жүремін.— дейді Иван. Компания жаңа болған кезде және кешігуге қойылатын талаптар ондаған миллисекундтар болса, Иван бүгінгі күні классикалық дерекқорлар «оралған» «операторларға» қарайды. Олар репликация тізбегін көтереді, ол істен шыққан жағдайда өздігінен ауысады және т.б.
Куберде бірнеше сервері бар шағын компания үшін бұл мағынасыз, дейді Андрей. Бірақ егер ол жүздеген немесе одан да көп серверлерге дейін өсуді жоспарласа, онда автоматтандыру және ресурстарды басқару жүйесі қажет. Істердің 90% шығындарды ақтайды. Және жүктеме мен ресурстар деңгейіне қарамастан. Стартаптардан бастап миллиондаған аудиториясы бар ірі компанияларға дейін барлығына бірте-бірте контейнерлік оркестрлік өнімдерге қарау мағынасы бар. «Иә, бұл шын мәнінде болашақ», - деп сенімді Андрей.
Денис екі негізгі критерийді атап өтті - ауқымдылық және тұрақтылық. Ол осы тапсырма үшін ең қолайлы құралдарды таңдайды. «Бұл тізеде жиналған noname және Nutanix Community Edition болуы мүмкін. Бұл көшірілетін және RTO және RPO көрсетілген параметрлері бар сервердегі дерекқоры бар Kuber қолданбасы түріндегі екінші жол болуы мүмкін »(қалпына келтіру уақыты / нүкте мақсаттары - шамамен).
Евгений персоналмен болуы мүмкін мәселені анықтады. Қазіргі уақытта нарықта «ішекті» түсінетін жоғары санатты мамандар онша көп емес. Расында да, таңдалған технология ескі болса, өмірден жалығып, шаршаған орта жастағылардан басқа адамды жұмысқа алу қиын. Басқа қатысушылар бұл жаттығу мәселесі деп есептесе де.
Таңдау мәселесін көтеретін болсақ: Amazon RDS-тегі дерекқорлары бар Public Cloud-та шағын компанияны немесе Kubernetes-тегі дерекқорлары бар «жергілікті» басқаратын болсақ, кейбір кемшіліктерге қарамастан Amazon RDS қатысушылардың таңдауы болды.
Кездесудің тыңдармандарының көпшілігі «қанды» кәсіпорыннан емес болғандықтан үлестірілген шешімдер - бұл ұмтылатын нәрсе. Деректерді сақтау жүйелері таратылған, сенімді болуы және миллисекунд бірліктерімен, ең көп ондықтармен өлшенетін кідіріс жасауы керек.Андрей сөзін аяқтады.
Kubernetes пайдалануды бағалау
Тыңдаушы Антон Жбанков Кубернетес апологтарына тұзаққа сұрақ қойды: техникалық-экономикалық негіздеме қалай таңдалды және орындалды? Неліктен Kubernetes, неге виртуалды машиналар емес, мысалы?
Суретке түсіру
Оған Дмитрий мен Иван жауап берді. Екі жағдайда да сынақ және қателік арқылы шешімдер тізбегі қабылданды, нәтижесінде екі қатысушы да Кубернетеске келді. Қазір бизнес Kuber-ге көшіру мағынасы бар бағдарламалық жасақтаманы дербес әзірлеуді бастады. Біз 1С сияқты классикалық үшінші тарап жүйелері туралы айтпаймыз. Kubernetes әзірлеушілерге үзіліссіз үздіксіз жақсарту арқылы жылдам шығарылымдар жасау қажет болғанда көмектеседі.
Андрейдің командасы виртуалды машиналар негізінде масштабталатын кластерді жасауға тырысты. Түйіндер домино сияқты құлады, бұл кейде кластердің құлауына әкелді. «Теориялық тұрғыдан, сіз оны қолыңызбен аяқтай аласыз және тірей аласыз, бірақ бұл жұмыс. Ал егер нарықта қораптан тыс жұмыс істеуге мүмкіндік беретін шешім болса, біз оған қуана барамыз. Нәтижесінде біз ауыстық», - дейді Андрей.
Мұндай талдау мен есептеудің стандарттары бар, бірақ олардың жұмыс істеп тұрған нақты жабдықта қаншалықты дәл екенін ешкім айта алмайды. Есептеулер үшін әрбір құрал мен экожүйені түсіну де маңызды, бірақ бұл мүмкін емес.
Бізді не күтіп тұр
Суретке түсіру
Технология дамыған сайын әр түрлі бөлшектер барған сайын көбейіп барады, содан кейін фазалық ауысу бар, барлығын бір құралға біріктіру үшін жеткілікті «қамырды» өлтірген сатушы пайда болады.
Linux әлемі үшін Ubuntu сияқты құрал пайда болатын уақыт келеді деп ойламайсыз ба? Мүмкін, жалғыз контейнерлеу және оркестрлеу құралы Куберді қамтуы мүмкін. Оның көмегімен жергілікті бұлттарды құру оңай болады.
Иван былай деп жауап берді: «Google қазір Anthos жасап жатыр - бұл бұлтты орналастыратын және Kuber, Service Mesh, мониторингті қамтитын олардың пакеттік ұсынысы - жергілікті микросервистерге қажет барлық байланыстыру. Біз болашақта дерлік ».
Денис сонымен қатар бұл тапсырманы контейнерсіз орындай алатын vRealize Suite өнімі бар Nutanix және VMWare туралы айтты.
Дмитрий «ауыруды» азайту және салықты азайту - жақсартулар күтілетін екі бағыт деген пікірімен бөлісті.
Талқылауды қорытындылай келе, қазіргі заманғы инфрақұрылымның келесі проблемаларын атап өтеміз
- Үш қатысушы бірден жағдай туралы мәселені анықтады.
- Әртүрлі қауіпсіздік мәселелері, соның ішінде Docker Python, қолданба серверлері және құрамдастардың бірнеше нұсқаларымен аяқталуы мүмкін.
Артық шығын, ол туралы бөлек митап жасаған дұрыс.
Оркестрация күрделі экожүйе болғандықтан оқу мәселесі.
Өнеркәсіпте жиі кездесетін мәселе - құралдарды дұрыс қолданбау.Қалған қорытындылар сізге байланысты. Әзірге Docker + Kubernetes бумасының жүйенің «орталық» бөлігіне айналуы оңай емес деген пікір бар. Мысалы, операциялық жүйелер алдымен аппараттық құралға қойылады, оны контейнерлер мен оркестрлер туралы айту мүмкін емес. Мүмкін, болашақта бұлтты басқару бағдарламалық құралы бар ОЖ және контейнерлер бірге өсетін шығар.
Суретке түсіруОсы сәтті пайдалана отырып, анама сәлем айтқым келеді, фейсбукта группамыз бар екенін еске салайын , арна түрлі техно блогтардағы қызықты жарияланымдармен. Және менің каналым онда мен өнім компанияларындағы дамуды басқару туралы айтамын.
Ақпарат көзі: www.habr.com