Kubernetes – кластерленген өндіріс ортасында Docker контейнерлерін іске қосуға арналған тамаша құрал. Дегенмен, Кубернетес шеше алмайтын мәселелер бар. Жиі өндірісті орналастыру үшін процесте тоқтап қалмау үшін бізге толық автоматтандырылған Көк/Жасыл орналастыру қажет, ол сонымен қатар сыртқы HTTP сұрауларын өңдеуді және SSL жүктеуді орындауды қажет етеді. Бұл ha-proxy сияқты жүктеме теңестіргішімен біріктіруді қажет етеді. Тағы бір қиындық - бұлт ортасында жұмыс істеген кезде Кубернетес кластерінің өзін жартылай автоматты масштабтау, мысалы, түнде кластерді ішінара масштабтау.
Kubernetes-те мұндай мүмкіндіктер жоқ болса да, ол ұқсас мәселелерді шешу үшін пайдалануға болатын API ұсынады. Автоматтандырылған Көк/Жасыл орналастыруға және Kubernetes кластерін масштабтауға арналған құралдар ашық дереккөз негізінде жасалған Cloud RTI жобасының бөлігі ретінде әзірленді.
Бұл мақала, бейне транскрипт, өндірісте үзіліссіз git commit кодын қабылдайтын өндіріске дайын ортаны жасау үшін Kubernetes-ті басқа ашық бастапқы құрамдастармен бірге қалай орнату керектігін көрсетеді.
Сонымен, сіздің қосымшаларыңызға сыртқы әлемнен қол жеткізгеннен кейін, сіз автоматтандыруды толығымен орнатуды бастай аласыз, яғни оны git міндеттемесін орындай алатын және бұл git міндеттемесі өндірісте аяқталатынына көз жеткізіңіз. Әрине, осы қадамдарды орындаған кезде, орналастыруды жүзеге асырған кезде, біз тоқтап қалуға тап болғымыз келмейді. Сонымен, Kubernetes-тегі кез келген автоматтандыру API интерфейсінен басталады.
Кубернетес қораптан тыс өнімді пайдалануға болатын құрал емес. Әрине, сіз мұны жасай аласыз, kubectl және т.б. пайдалана аласыз, бірақ API - бұл платформаның ең қызықты және пайдалы нәрсе. API интерфейсін функциялар жинағы ретінде пайдалану арқылы Kubernetes қолданбасында орындағыңыз келетін дерлік кез келген нәрсеге қол жеткізе аласыз. kubectl өзі де REST API пайдаланады.
Бұл REST, сондықтан сіз осы API-мен жұмыс істеу үшін кез келген тілді немесе құралды пайдалана аласыз, бірақ реттелетін кітапханалар сіздің өміріңізді әлдеқайда жеңілдетеді. Менің командам осындай 2 кітапхана жазды: біреуі Java/OSGi үшін және біреуі Go үшін. Екіншісі жиі қолданылмайды, бірақ кез келген жағдайда сізде бұл пайдалы заттар бар. Олар жартылай лицензияланған ашық бастапқы жоба. Әртүрлі тілдерге арналған мұндай кітапханалар көп, сондықтан сіз өзіңізге қолайлысын таңдай аласыз.
Сонымен, орналастыруды автоматтандыруды бастамас бұрын, процестің тоқтап қалмайтынына көз жеткізу керек. Мысалы, біздің команда адамдар қолданбаларды барынша пайдаланып жатқан күннің ортасында өндірістік орналастыруды жүргізеді, сондықтан бұл процесте кідірістерді болдырмау маңызды. Тоқтап тұруды болдырмау үшін 2 әдіс қолданылады: көк/жасыл орналастыру немесе жылжымалы жаңарту. Соңғы жағдайда, егер сізде іске қосылған қолданбаның 5 көшірмесі болса, олар бірінен соң бірі ретпен жаңартылады. Бұл әдіс тамаша жұмыс істейді, бірақ орналастыру процесі кезінде бір уақытта жұмыс істейтін қолданбаның әртүрлі нұсқалары болса, ол қолайлы емес. Бұл жағдайда сервер ескі нұсқамен жұмыс істеп тұрған кезде пайдаланушы интерфейсін жаңартуға болады және қолданба жұмысын тоқтатады. Сондықтан бағдарламалау тұрғысынан мұндай жағдайларда жұмыс істеу өте қиын.
Бұл біздің қолданбаларды орналастыруды автоматтандыру үшін көк/жасыл орналастыруды пайдалануды қалайтын себептердің бірі. Бұл әдіс арқылы бір уақытта қолданбаның тек бір нұсқасы белсенді болуын қамтамасыз ету керек.
Көк/жасыл орналастыру механизмі осылай көрінеді. Біз қолданбаларымыз үшін трафикті ha-proxy арқылы аламыз, ол оны бірдей нұсқадағы қолданбаның іске қосылған көшірмелеріне жібереді.
Жаңа орналастыру жасалғанда, біз жаңа құрамдастарды беретін және жаңа нұсқаны орналастыратын Deployer пайдаланамыз. Қолданбаның жаңа нұсқасын қолдану репликалардың жаңа жинағының "көтерілгенін" білдіреді, содан кейін жаңа нұсқаның осы көшірмелері бөлек, жаңа подкастта іске қосылады. Дегенмен, ha-proxy олар туралы ештеңе білмейді және оларға әлі ешқандай жұмыс жүктемесін бағыттамайды.
Сондықтан, ең алдымен, көшірмелердің жүктемеге қызмет көрсетуге дайын екендігіне көз жеткізу үшін денсаулықты тексерудің жаңа нұсқаларының өнімділігін тексеру қажет.
Барлық орналастыру құрамдастары денсаулықты тексерудің қандай да бір түрін қолдауы керек. Бұл 200 мәртебесі бар кодты алған кезде өте қарапайым HTTP қоңырауын тексеру немесе көшірмелердің дерекқормен және басқа қызметтермен байланысын, динамикалық орта қосылымдарының тұрақтылығын тексеретін тереңірек тексеру болуы мүмкін. , және бәрі дұрыс басталып, жұмыс істей ме. Бұл процесс өте күрделі болуы мүмкін.
Жүйе барлық жаңартылған көшірмелердің жұмыс істеп тұрғанын тексергеннен кейін Deployer конфигурацияны жаңартады және ha-проксиді қайта конфигурациялайтын дұрыс конфигурацияны береді.
Осыдан кейін ғана трафик жаңа нұсқаның көшірмелері бар бөлімшеге бағытталады және ескі подкаст жоғалады.
Бұл механизм Kubernetes ерекшелігі емес. Көк/жасыл орналастыру тұжырымдамасы ұзақ уақыт бойы болды және ол әрқашан жүктемені теңестіргішті қолданды. Алдымен сіз барлық трафикті қолданбаның ескі нұсқасына бағыттайсыз, ал жаңартудан кейін оны толығымен жаңа нұсқаға тасымалдайсыз. Бұл принцип тек Кубернеттерде ғана қолданылмайды.
Енді мен сізді жаңа орналастыру құрамдас бөлігімен таныстырамын - денсаулықты тексеруді жүзеге асыратын, прокси-серверлерді қайта конфигурациялайтын және т.б. Бұл сыртқы әлемге қолданылмайтын және Кубернетестің ішінде бар тұжырымдама. Мен сізге ашық бастапқы құралдарды пайдаланып өзіңіздің Deployer тұжырымдамаңызды қалай жасауға болатынын көрсетемін.
Сонымен, Deployer жасайтын бірінші нәрсе - Kubernetes API арқылы RC репликация контроллерін жасау. Бұл API одан әрі орналастыру үшін подкладкалар мен қызметтерді жасайды, яғни қолданбаларымыз үшін мүлдем жаңа кластерді жасайды. RC репликалардың іске қосылғанына көз жеткізгеннен кейін, ол олардың функционалдығын денсаулықты тексеруді орындайды. Бұл әрекетті орындау үшін Deployer GET /health пәрменін пайдаланады. Ол сәйкес сканерлеу құрамдастарын іске қосады және кластердің жұмысын қолдайтын барлық элементтерді тексереді.
Барлық подкасттардың денсаулығы туралы есеп бергеннен кейін, Deployer жаңа конфигурация элементін жасайды - etcd таратылған жад, оны Kubernetes іштей пайдаланады, соның ішінде жүктеме теңестіруші конфигурациясын сақтайды. Біз etcd-ге деректерді жазамыз және жаңа деректер үшін confd monitors etcd деп аталатын шағын құрал.
Егер ол бастапқы конфигурацияда кез келген өзгерістерді анықтаса, ол жаңа параметрлер файлын жасайды және оны ha-proxy-ге тасымалдайды. Бұл жағдайда ha-proxy ешқандай қосылымдарды жоғалтпай қайта жүктеледі және қолданбаларымыздың жаңа нұсқасының жұмыс істеуіне мүмкіндік беретін жаңа қызметтерге жүктемені бағыттайды.
Көріп отырғаныңыздай, компоненттердің көптігіне қарамастан, мұнда күрделі ештеңе жоқ. Сізге тек API және т.б. көбірек назар аудару керек. Мен сізге өзіміз қолданатын ашық бастапқы орналастырушы - Amdatu Kubernetes Deployer туралы айтқым келеді.
Бұл Kubernetes орналастыруларын ұйымдастыруға арналған құрал және келесі мүмкіндіктерге ие:
- Көк/Жасыл орналастыру;
- сыртқы жүктеме балансын орнату;
- орналастыру дескрипторын басқару;
- нақты орналастыруды басқару;
- орналастыру кезінде Денсаулықты тексерудің функционалдығын тексеру;
- ортаның айнымалы мәндерін блоктарға енгізу.
Бұл Deployer Kubernetes API үстіне құрастырылған және дескрипторлар мен орналастыруларды басқаруға арналған REST API интерфейсін, сондай-ақ орналастыру процесі кезінде журналдарды ағынмен жіберуге арналған Websocket API ұсынады.
Ол жүктемені теңестіруші конфигурация деректерін etcd ішіне қояды, сондықтан сізге қораптан тыс қолдауы бар ha-proxy пайдаланудың қажеті жоқ, бірақ өзіңіздің жеке жүк теңестіруші конфигурация файлын оңай пайдаланыңыз. Amdatu Deployer Kubernetes сияқты Go бағдарламасында жазылған және Apache лицензиясы бар.
Мен орналастырушының осы нұсқасын пайдалануды бастамас бұрын, мен қажетті параметрлерді көрсететін келесі орналастыру дескрипторын қолдандым.
Бұл кодтың маңызды параметрлерінің бірі «useHealthCheck» жалауын қосу болып табылады. Орналастыру процесі кезінде ақыл-ойды тексеру қажет екенін көрсетуіміз керек. Орналастыру тексеруді қажет етпейтін үшінші тарап контейнерлерін пайдаланған кезде бұл параметрді өшіруге болады. Бұл дескриптор сондай-ақ репликалар санын және ha-proxy серверіне қажет URL мекенжайын көрсетеді. Соңында порт конфигурациясы, кескін және т. Бұл өте қарапайым JSON дескрипторы.
Ашық бастапқы Amdatu жобасының бөлігі болып табылатын тағы бір құрал - Deploymentctl. Ол орналастыруларды конфигурациялауға арналған UI бар, орналастыру тарихын сақтайды және үшінші тарап пайдаланушылары мен әзірлеушілерінен кері қоңырау шалу үшін веб-хуктарды қамтиды. Amdatu Deployer өзі REST API болғандықтан, пайдаланушы интерфейсін пайдалана алмайсыз, бірақ бұл интерфейс ешқандай API қолданбай-ақ қолдануды жеңілдетеді. Deploymentctl Angular 2 көмегімен OSGi/Vertx тілінде жазылған.
Енді күтудің қажеті болмас үшін алдын ала жазылған жазбаны пайдаланып экранда жоғарыдағыларды көрсетемін. Біз қарапайым Go қолданбасын қолданатын боламыз. Егер сіз бұрын Go қолданбасын қолданбаған болсаңыз, алаңдамаңыз, бұл өте қарапайым қолданба, сондықтан сіз оны анықтай алуыңыз керек.
Мұнда біз тек /денсаулыққа жауап беретін HTTP серверін жасаймыз, сондықтан бұл қолданба тек денсаулықты тексеруді тексереді, басқа ештеңе жоқ. Тексеру өтсе, төменде көрсетілген JSON құрылымы пайдаланылады. Онда орналастырушы орналастыратын қолданбаның нұсқасы, файлдың жоғарғы жағында көретін хабар және логикалық деректер түрі бар - біздің қолданба жұмыс істеп жатыр ма, жоқ па.
Мен соңғы жолды аздап алдадым, өйткені мен файлдың жоғарғы жағына бекітілген логикалық мәнді қойдым, ол болашақта тіпті «сау» қолданбаны орналастыруға көмектеседі. Мұны кейінірек қарастырамыз.
Ендеше, бастайық. Біріншіден, біз ~ kubectl get pods пәрмені арқылы кез келген жұмыс істейтін подкасттардың бар-жоғын тексереміз және URL мекенжайынан жауаптың жоқтығына негізделе отырып, қазіргі уақытта ешқандай орналастырулар жасалмағанына көз жеткіземіз.
Келесі экранда мен атап өткен Deploymentctl интерфейсін көресіз, онда орналастыру параметрлері орнатылады: аттар кеңістігі, қолданба атауы, орналастыру нұсқасы, көшірмелер саны, алдыңғы URL мекенжайы, контейнер атауы, сурет, ресурс шектеулері, денсаулықты тексеруге арналған порт нөмірі, т.б. Ресурс шектеулері өте маңызды, өйткені олар жабдықтың максималды мүмкін мөлшерін пайдалануға мүмкіндік береді. Мұнда сіз Орналастыру журналын да көре аласыз.
Егер сіз қазір ~ kubectl get pods пәрменін қайталасаңыз, жүйенің 20 секундқа «қатып қалғанын» көре аласыз, оның барысында ha-прокси қайта конфигурацияланады. Осыдан кейін подкаст іске қосылады және біздің көшірмені орналастыру журналында көруге болады.
Мен бейнеден 20 секунд күтуді кесіп тастадым, енді экранда қолданбаның бірінші нұсқасы орналастырылғанын көре аласыз. Мұның бәрі тек UI арқылы жасалды.
Енді екінші нұсқаны қолданып көрейік. Ол үшін қолданбаның хабарламасын «Сәлеметсіз бе, Кубернетес!» деп өзгертемін. «Сәлеметсіз бе, орналастырушы!» параметрінде жүйе бұл кескінді жасайды және оны Docker тізіліміне орналастырады, содан кейін біз Deploymentctl терезесіндегі «Орналастыру» түймесін қайтадан басамыз. Бұл жағдайда қолдану журналы қолданбаның бірінші нұсқасын қолдану кезінде болғандай автоматты түрде іске қосылады.
~ kubectl get pods пәрмені қазіргі уақытта іске қосылған қолданбаның 2 нұсқасы бар екенін көрсетеді, бірақ алдыңғы бөлік әлі де 1 нұсқасын іске қосып жатқанымызды көрсетеді.
Жүктемені теңестіруші трафикті жаңа нұсқаға қайта бағыттамас бұрын денсаулықты тексерудің аяқталуын күтеді. 20 секундтан кейін біз curl режиміне ауысамыз және қазір бізде қолданбаның 2 нұсқасы орналастырылғанын және біріншісі жойылғанын көреміз.
Бұл «сау» қолданбаны орналастыру болды. Қолданбаның жаңа нұсқасы үшін «Денсаулық» параметрін «true» параметрінен «false» параметріне өзгертсем, яғни денсаулықты тексеруден өтпеген жарамсыз қолданбаны орналастыруға тырыссам, не болатынын көрейік. Бұл әзірлеу кезеңінде қолданбада кейбір конфигурация қателері жасалса және ол осы пішінде өндіріске жіберілсе орын алуы мүмкін.
Көріп отырғаныңыздай, орналастыру жоғарыдағы барлық қадамдардан өтеді және ~kubectl get pods екі қосқыштың да жұмыс істеп тұрғанын көрсетеді. Бірақ алдыңғы орналастырудан айырмашылығы, журнал күту уақыты күйін көрсетеді. Яғни, денсаулықты тексеру сәтсіз аяқталуына байланысты қолданбаның жаңа нұсқасын қолдану мүмкін емес. Нәтижесінде жүйе қолданбаның ескі нұсқасын пайдалануға қайта оралғанын және жаңа нұсқасы жай ғана жойылғанын көресіз.
Мұның жақсы жағы - қолданбаға бір уақытта көптеген сұраулар келіп түскен жағдайда да, олар орналастыру процедурасын орындау кезінде тоқтап қалу уақытын байқамайды. Егер сіз бұл қолданбаны мүмкіндігінше көп сұрау жіберетін Gatling құрылымы арқылы сынасаңыз, бұл сұраулардың ешқайсысы қабылданбайды. Бұл біздің пайдаланушылар нақты уақытта нұсқа жаңартуларын байқамайды дегенді білдіреді. Егер ол сәтсіз болса, жұмыс ескі нұсқада жалғасады, егер ол сәтті болса, пайдаланушылар жаңа нұсқаға ауысады.
Сәтсіздікке ұшырауы мүмкін бір ғана нәрсе бар - егер денсаулықты тексеру сәтті болса, бірақ оған жұмыс жүктемесі қолданылғаннан кейін қолданба сәтсіз аяқталса, яғни құлау орналастыру аяқталғаннан кейін ғана орын алады. Бұл жағдайда ескі нұсқаға қолмен оралуға тура келеді. Сонымен, біз Kubernetes-ті оған арналған ашық бастапқы құралдармен қалай пайдалану керектігін қарастырдық. Бұл құралдарды Құрастыру/Орналастыру құбырларына құрастырсаңыз, орналастыру процесі әлдеқайда жеңіл болады. Сонымен қатар, орналастыруды бастау үшін пайдаланушы интерфейсін пайдалануға немесе, мысалы, меңгеруге міндеттемені пайдалану арқылы осы процесті толық автоматтандыруға болады.
Біздің құрастыру сервері Docker кескінін жасайды, оны Docker Hub ішіне немесе сіз пайдаланатын кез келген тізілімге жібереді. Docker Hub веб-хукты қолдайды, сондықтан біз жоғарыда көрсетілген жолмен Deployer арқылы қашықтан орналастыруды іске қоса аламыз. Осылайша сіз қолданбаңызды әлеуетті өндіріске орналастыруды толығымен автоматтандыруға болады.
Келесі тақырыпқа көшейік - Kubernetes кластерін масштабтау. kubectl пәрмені масштабтау пәрмені екенін ескеріңіз. Көбірек көмек арқылы біз бар кластердегі көшірмелердің санын оңай көбейте аламыз. Дегенмен, іс жүзінде біз әдетте тармақтардың емес, түйіндердің санын көбейткіміз келеді.
Сонымен қатар, жұмыс уақытында сізге Amazon қызметтерінің құнын арттыру қажет болуы мүмкін, ал түнде Amazon қызметтерінің құнын төмендету үшін іске қосылған қолданба даналарының санын азайту қажет болуы мүмкін. Бұл тек тармақтардың санын масштабтау жеткілікті болады дегенді білдірмейді, себебі түйіндердің бірі жұмыс істемей тұрса да, ол үшін Amazon-ға ақы төлеуге тура келеді. Яғни, бөтелкелерді масштабтаумен бірге пайдаланылатын машиналар санын масштабтау қажет болады.
Бұл қиын болуы мүмкін, өйткені біз Amazon немесе басқа бұлттық қызметті қолданамыз ба, Кубернетес пайдаланылатын машиналар саны туралы ештеңе білмейді. Онда жүйені түйін деңгейінде масштабтауға мүмкіндік беретін құрал жетіспейді.
Сондықтан біз түйіндер мен түйіршіктерге қамқорлық жасауымыз керек. Біз Kubernetes жұмысшы түйіндерінің санын конфигурациялау үшін AWS API және Scaling топ машиналарын пайдаланып жаңа түйіндерді іске қосуды оңай масштабтай аламыз. Сондай-ақ, Kubernetes кластеріндегі түйіндерді тіркеу үшін cloud-init немесе ұқсас сценарийді пайдалануға болады.
Жаңа машина Масштабтау тобында басталады, түйін ретінде іске қосылады, шебердің тізілімінде тіркеледі және жұмыс істей бастайды. Осыдан кейін алынған түйіндерде пайдалану үшін көшірмелердің санын көбейтуге болады. Масштабты азайту көп күш жұмсауды талап етеді, өйткені мұндай қадам «қажет емес» машиналарды өшіргеннен кейін бұрыннан жұмыс істеп тұрған қолданбаларды жоюға әкелмейтініне көз жеткізу керек. Мұндай сценарийді болдырмау үшін түйіндерді «жоспарланбаған» күйге орнату керек. Бұл DaemonSet қосқыштарын жоспарлау кезінде әдепкі жоспарлаушы бұл түйіндерді елемейтінін білдіреді. Жоспарлаушы бұл серверлерден ештеңені жоймайды, бірақ ол жерде жаңа контейнерлерді де іске қоспайды. Келесі қадам су төгетін түйінді шығару болып табылады, яғни одан басқа құрылғыға немесе бұл үшін жеткілікті сыйымдылығы бар басқа түйіндерге жұмыс істеп тұрған түйіндерді ауыстыру. Осы түйіндерде контейнерлер жоқ екеніне көз жеткізгеннен кейін оларды Kubernetes жүйесінен жоюға болады. Осыдан кейін олар Кубернетес үшін өмір сүруін тоқтатады. Әрі қарай, қажет емес түйіндерді немесе машиналарды өшіру үшін AWS API пайдалануыңыз керек.
Amdatu Scalerd, AWS API-ге ұқсас басқа ашық бастапқы масштабтау құралын пайдалануға болады. Ол кластердегі түйіндерді қосу немесе жою үшін CLI береді. Оның қызықты ерекшелігі - келесі json файлын пайдаланып жоспарлаушыны конфигурациялау мүмкіндігі.
Көрсетілген код түнгі кезеңде кластердің сыйымдылығын екі есе азайтады. Ол қол жетімді көшірмелердің санын және Amazon кластерінің қажетті сыйымдылығын теңшейді. Бұл жоспарлаушыны пайдалану түнде түйіндердің санын автоматты түрде азайтады және таңертең оларды көбейтеді, Amazon сияқты бұлттық қызметтің түйіндерін пайдалану құнын үнемдейді. Бұл мүмкіндік Kubernetes ішіне кіріктірілмеген, бірақ Scalerd пайдалану бұл платформаны қалағаныңызша масштабтауға мүмкіндік береді.
Көптеген адамдар маған: «Бәрі жақсы және жақсы, бірақ менің деректер базам туралы не деуге болады, ол әдетте статикалық болып табылады?» Kubernetes сияқты динамикалық ортада осындай нәрсені қалай іске қосуға болады? Менің ойымша, сіз мұны істемеуіңіз керек, Kubernetes-те деректер қоймасын іске қосуға тырыспауыңыз керек. Бұл техникалық тұрғыдан мүмкін және Интернетте осы тақырып бойынша оқулықтар бар, бірақ бұл сіздің өміріңізді айтарлықтай қиындатады.
Иә, Kubernetes-те тұрақты дүкендер тұжырымдамасы бар және Mongo немесе MySQL сияқты деректер қоймаларын іске қосып көруге болады, бірақ бұл өте көп еңбекті қажет ететін тапсырма. Бұл деректер қоймалары динамикалық ортамен өзара әрекеттесуді толық қолдамайтындығына байланысты. Дерекқорлардың көпшілігі маңызды конфигурацияны қажет етеді, соның ішінде кластерді қолмен конфигурациялау, автомасштабтауды және басқа ұқсас нәрселерді ұнатпайды.
Сондықтан Kubernetes-те деректер қоймасын іске қосу арқылы өміріңізді қиындатпауыңыз керек. Таныс қызметтерді пайдалана отырып, олардың жұмысын дәстүрлі түрде ұйымдастырыңыз және жай ғана Kubernetes-ке оларды пайдалану мүмкіндігін беріңіз.
Тақырыпты қорытындылау үшін мен сізді менің командам жұмыс істеп жатқан Kubernetes негізіндегі Cloud RTI платформасымен таныстырғым келеді. Ол орталықтандырылған тіркеуді, қолданбаларды және кластерді бақылауды және пайдалы болатын басқа да көптеген пайдалы мүмкіндіктерді қамтамасыз етеді. Ол мониторинг көрсету үшін Grafana сияқты әртүрлі ашық бастапқы құралдарды пайдаланады.
Ha-proxy жүктеме балансын неге Kubernetes көмегімен пайдалану керектігі туралы сұрақ туындады. Жақсы сұрақ, себебі қазіргі уақытта жүктемені теңестірудің 2 деңгейі бар. Kubernetes қызметтері әлі де виртуалды IP мекенжайларында орналасқан. Оларды сыртқы хост машиналарындағы порттар үшін пайдалана алмайсыз, себебі Amazon өзінің бұлттық хостын шамадан тыс жүктесе, мекенжай өзгереді. Сондықтан біз ha-проксиді қызметтердің алдына қоямыз - трафиктің Kubernetes-пен үздіксіз байланысуы үшін статикалық құрылымды жасау.
Тағы бір жақсы сұрақ - көк/жасыл орналастыру кезінде дерекқор схемасының өзгерістеріне қалай қамқорлық жасауға болады? Кубернетесті пайдалануына қарамастан, дерекқор схемасын өзгерту қиын міндет болып табылады. Ескі және жаңа схеманың үйлесімді болуын қамтамасыз ету керек, содан кейін дерекқорды жаңартып, содан кейін қолданбаларды өздері жаңартуға болады. Дерекқорды жылдам ауыстырып, қолданбаларды жаңартуға болады. Мен мүлде жаңа дерекқор кластерін жаңа схемамен жүктеген адамдарды білемін, бұл Mongo сияқты схемасыз дерекқорыңыз болса, бұл опция, бірақ бәрібір бұл оңай тапсырма емес. Басқа сұрақтарыңыз болмаса, назарларыңызға рахмет!
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com