Kubernetes-те ресурстарды жаңартудың бірнеше нұсқасы бар: қолдану, өңдеу, түзету және ауыстыру. Әрқайсысының не істейтіні және оларды қашан пайдалану керектігі туралы шатасу бар. Оны анықтап көрейік.
егер «kubernetes қолданылады және ауыстыру» тіркесі орналасқан , бұл дұрыс емес. «kubernetes application vs patch» бірінші сілтемесі құжаттама болып табылады kubectl patch, ол салыстыруды қамтымайды apply и patch. Бұл мақалада әртүрлі нұсқалар, сондай-ақ олардың әрқайсысын дұрыс пайдалану қарастырылады.
Kubernetes ресурсының өмірлік циклі кезінде (қызмет, орналастыру, кіру және т.б.) кейде осы ресурстың кейбір сипаттарын өзгерту, қосу немесе жою қажет. Мысалы, ескертпе қосыңыз, көшірмелердің санын көбейтіңіз немесе азайтыңыз.
Kubernetes CLI
CLI арқылы Kubernetes кластерлерімен жұмыс істеп жатсаңыз, сіз бұрыннан таныссыз. apply и edit. Команда apply файлдан ресурс спецификациясын оқиды және Kubernetes кластеріне «жоғарғы» жасайды, яғни. егер ол жоқ болса ресурсты жасайды және бар болса оны жаңартады. Команда edit API арқылы ресурсты оқиды, содан кейін мәтіндік редакторда ашылатын жергілікті файлға ресурс сипаттамасын жазады. Файлды өңдеп, сақтағаннан кейін, kubectl енгізілген өзгерістерді API арқылы кері жібереді, ол бұл өзгерістерді ресурсқа мұқият қолданады.
Командаларды бәрі біле бермейді patch и replace. Команда patch пәрмен жолында тек өзгертілген бөлігін қамтамасыз ете отырып, ресурс сипаттамасының бөлігін өзгертуге мүмкіндік береді. Команда replace сияқты жұмыс істейді edit, бірақ барлығын қолмен жасау керек: ресурс сипаттамасының ағымдағы нұсқасын жүктеп алу керек, мысалы, kubectl get -o yaml, өңдеңіз, содан кейін пайдаланыңыз replace өзгертілген спецификацияға сәйкес ресурсты жаңарту. Команда replace ресурсты оқу мен ауыстыру арасында қандай да бір өзгерістер орын алса, жұмыс істемейді.
Kubernetes API
Сіз әдістермен таныс шығарсыз CoreV1().Pods().Update(), replaceNamespacedService немесе patch_namespaced_deployment, арқылы кластерлермен жұмыс жасасаңыз кейбір бағдарламалау тілін қолдану. Кітапхана бұл әдістерді әдістер арқылы HTTP сұраулары арқылы өңдейді PUT и PATCH. Бола тұра update и replace пайдалану PUTмен patch, ол қаншалықты тривиальды болса да, пайдаланады PATCH.
Ол Айта кету керек, kubectl сонымен қатар API арқылы кластерлермен жұмыс істейді. Басқаша айтқанда, kubectlстандартты API мүмкіндіктеріне қосымша ықшам және оқылатын пішінде ішкі пәрмендерді қамтамасыз ету мүмкіндігін қамтамасыз ететін Go тіліне арналған клиент кітапханасының жоғарғы жағындағы қаптама болып табылады. Мысалы, сіз бұрыннан байқағаныңыздай, әдіс apply алдыңғы абзацта жоғарыда айтылмаған. Қазіргі уақытта (мамыр 2020 ж., шамамен. аудармашы) барлық логика kubectl apply, яғни. жоқ ресурстарды жасау және барларын жаңарту толығымен код жағында жұмыс істейді kubectl. Бар күш-жігер жұмсалуда apply API жағына, бірақ ол әлі бета нұсқасында. Төменде толығырақ жазамын.
Әдепкі бойынша патч
Ең жақсы пайдаланылған patch, ресурсты жаңартқыңыз келсе. Екі клиент кітапханасы да Kubernetes API және kubectl (таңқаларлық емес, өйткені бұл клиент кітапханасы үшін қаптама, шамамен. аудармашы).
Стратегиялық жұмыс жасаңыз
Барлық командалар kubectl apply, edit и patch әдісін қолданыңыз PATCH бар ресурсты жаңарту үшін HTTP сұрауларында. Егер сіз командалардың орындалуын толығырақ қарастырсаңыз, онда олардың барлығы тәсілді пайдаланады пәрменіне қарамастан ресурстарды жаңарту үшін patch басқа тәсілдерді қолдануы мүмкін (төменде бұл туралы толығырақ). Стратегиялық біріктіру түзету тәсілі берілген спецификацияны бар спецификациямен біріктіру арқылы "дұрыс алуға" әрекет жасайды. Нақтырақ айтқанда, ол нысандарды да, массивтерді де біріктіруге тырысады, яғни өзгерістер қосымша болады. Мысалы, пәрменді іске қосу patch подконтейнер спецификациясындағы жаңа орта айнымалысы бар ортаның айнымалы мәнін қайта жазудың орнына бар орта айнымалыларына қосуды тудырады. Бұл тәсілді пайдаланып жою үшін берілген спецификацияда параметр мәнін нөлге мәжбүрлеу керек. Командалардың қайсысы kubectl Жаңарту үшін қолданған дұрыс па?
Егер сіз өз ресурстарыңызды пайдаланып құрсаңыз және басқарсаңыз kubectl apply, жаңарту кезінде оны үнемі қолданған дұрыс kubectl applyдейін kubectl конфигурацияны басқара алады және қолданбадан қолданбаға сұралған өзгерістерді дұрыс бақылай алады. Артықшылықты әрқашан пайдаланыңыз apply ол бұрын қолданылған спецификацияны қадағалап отырады, бұл спецификация сипаттары мен массив элементтері қашан анық жойылатынын білуге мүмкіндік береді. Бұл пайдалануға мүмкіндік береді apply сипаттарды және массив элементтерін жою үшін, ал қалыпты стратегиялық біріктіру жұмыс істемейді. Командалар edit и patch ескертпелерді жаңартпаңыз kubectl apply өзгерістерін қадағалау үшін пайдаланады, сондықтан Kubernetes API арқылы бақыланатын және жасалған, бірақ пәрмендер арқылы жасалған кез келген өзгерістер edit и patch, келесі пәрмендерге көрінбейді apply, яғни apply үшін кіріс спецификациясында көрсетілмесе де, оларды жоймайды apply (Құжаттама бұл туралы айтады edit и patch пайдаланылған жазбаларға жаңартулар жасаңыз apply, бірақ іс жүзінде - жоқ).
Егер сіз пәрменді пайдаланбасаңыз apply, ретінде пайдалануға болады edit, Сонымен patch, жасалып жатқан өзгертуге сәйкес келетін пәрменді таңдау. BOM сипаттарын қосқанда және өзгерткенде, екі тәсіл де шамамен бірдей. Спецификация сипаттарын немесе жиым элементтерін жою кезінде edit бір реттік ұшыру сияқты әрекет етеді apply, соның ішінде спецификацияның өңделгенге дейін және кейін қандай болғанын қадағалау, осылайша сипаттарды және массив элементтерін ресурстан анық жоюға болады. Сипаттың мәнін спецификацияда нөлге нақты орнату керек patchоны ресурстан жою үшін. Біріктіруді стратегиялық түзету арқылы массив элементін жою күрделірек, себебі ол біріктіру директиваларын пайдалануды талап етеді. Неғұрлым өміршең баламалар үшін төмендегі жаңартудың басқа тәсілдерін қараңыз.
Жоғарыдағы пәрмендерге ұқсас әрекет ететін клиент кітапханасында жаңарту әдістерін енгізу үшін kubectl, сұрауларда орнатылуы керек content-type в application/strategic-merge-patch+json. Егер сіз спецификациядағы сипаттарды жойғыңыз келсе, олардың мәндерін дәл осылай нөлге орнатуыңыз керек. kubectl patch. Жиым элементтерін жою қажет болса, жаңарту спецификациясына біріктіру директиваларын қосу керек немесе жаңартуларға басқа тәсілді пайдалану керек.
Жаңартулардың басқа тәсілдері
Kubernetes басқа екі жаңарту әдісін қолдайды: и . JSON біріктіру патч тәсілі кіріс ретінде ішінара Kubernetes спецификациясын қабылдайды және стратегиялық біріктіру патч әдісіне ұқсас біріктіру нысандарын қолдайды. Екеуінің айырмашылығы - ол тек массив ауыстыруды, соның ішінде подкаст сипаттамасындағы контейнер массивін қолдайды. Бұл JSON біріктіру патчын пайдаланған кезде кез келген контейнердің кез келген қасиеті өзгерген жағдайда барлық контейнерлер үшін толық сипаттамаларды беру қажет дегенді білдіреді. Осылайша, бұл тәсіл BOM ішіндегі массивтен элементтерді жою үшін пайдалы. Пәрмен жолында JSON біріктіру патчын пайдалану арқылы таңдауға болады kubectl patch --type=merge. Kubernetes API интерфейсімен жұмыс істегенде сұрау әдісін пайдалану керек PATCH және орнату content-type в application/merge-patch+json.
JSON патч тәсілі ресурстың ішінара спецификациясын қамтамасыз етудің орнына массивтің әрбір элементі ресурсқа жасалып жатқан өзгертудің сипаттамасын көрсететін массив ретінде ресурсқа енгізгіңіз келетін өзгерістерді қамтамасыз етуді пайдаланады. Бұл тәсіл жасалып жатқан өзгерістерді білдірудің икемді және күшті әдісі болып табылады, бірақ ішінара ресурс сипаттамасын жіберудің орнына, Кубернеттен тыс бөлек пішімде енгізілген өзгертулерді тізімдеу құнына байланысты. IN kubectl көмегімен JSON патчын таңдауға болады kubectl patch --type=json. Kubernetes API пайдаланған кезде бұл тәсіл сұрау әдісі арқылы жұмыс істейді PATCH және орнату content-type в application/json-patch+json.
Бізге сенімділік қажет - ауыстыруды пайдаланыңыз
Кейбір жағдайларда ресурс оқылған және жаңартылған уақыт арасында ресурсқа ешқандай өзгерістер енгізілмегеніне сенімді болуыңыз керек. Басқаша айтқанда, барлық өзгерістер болатынына көз жеткізу керек атомдық. Бұл жағдайда ресурстарды жаңарту үшін пайдалану керек replace. Мысалы, егер сізде бірнеше көздер арқылы жаңартылатын есептегіші бар ConfigMap болса, екі көз бір уақытта есептегішті жаңартпайтынына сенімді болуыңыз керек, бұл жаңартудың жоғалуына әкеледі. Көрсету үшін тәсілді пайдаланып оқиғалар тізбегін елестетіңіз patch:
- A және B API интерфейсінен ресурстың ағымдағы күйін алады
- Әрқайсысы есептегішті бір ұлғайту және «жаңартылған» ескертпесіне сәйкесінше «A» немесе «B» қосу арқылы сипаттаманы жергілікті түрде жаңартады.
- Және ол ресурсты сәл жылдамырақ жаңартады
- B ресурсты жаңартады
Нәтижесінде A жаңартуы жоғалады. Соңғы операция patch жеңеді, санауыш екінің орнына біреуге ұлғаяды және «жаңартылған» ескертпенің мәні «В» әрпімен аяқталады және «А» жоқ. Жоғарыда айтылғандарды тәсілді пайдаланып жаңартулар орындалғанда не болатынын салыстырайық replace:
- A және B API интерфейсінен ресурстың ағымдағы күйін алады
- Әрқайсысы есептегішті бір ұлғайту және «жаңартылған» ескертпесіне сәйкесінше «A» немесе «B» қосу арқылы сипаттаманы жергілікті түрде жаңартады.
- Және ол ресурсты сәл жылдамырақ жаңартады
- B ресурсты жаңартуға тырысады, бірақ жаңартуды API қабылдамады, себебі ресурс нұсқасы спецификацияда
replaceKubernetes ішіндегі ресурстың ағымдағы нұсқасына сәйкес келмейді, себебі ресурс нұсқасы A ауыстыру әрекеті арқылы ұлғайтылған.
Жоғарыда көрсетілген жағдайда, B ресурсты қайта алып, жаңа күйге өзгертулер енгізіп, әрекетті қайталауы керек replace. Бұл есептегішті екіге көбейтеді және «жаңартылған» ескертпесі соңында «AB» белгісін қосады.
Жоғарыда келтірілген мысал орындау кезінде мұны білдіреді replace Бүкіл ресурс толығымен ауыстырылды. Қолданылатын спецификация replace, ішінара немесе келесідей бөліктерде болмауы керек apply, бірақ толықтыруды қоса алғанда толық resourceVersion спецификация метадеректеріне. Қоспаған болсаңыз resourceVersion немесе сіз берген нұсқа ағымдағы емес, ауыстыру қабылданбайды. Сондықтан пайдаланудың ең жақсы тәсілі replace – ресурсты оқып шығыңыз, оны жаңартыңыз және дереу ауыстырыңыз. Қолдану kubectl, ол келесідей болуы мүмкін:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Айта кету керек, дәйекті түрде орындалатын келесі екі команда сәтті орындалады, өйткені deployment.yaml қасиетін қамтымайды .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlБұл жоғарыда айтылғандарға қайшы келетін сияқты, яғни. «қосу resourceVersion спецификация метадеректеріне." Бұлай айту дұрыс емес пе? Жоқ, олай емес, өйткені егер kubectl сіз көрсетпегеніңізді ескертеді resourceVersion, ол оны ресурстан оқиды және сіз көрсеткен спецификацияға қосады, содан кейін ғана оны орындайды replace. Егер сіз атомдылыққа сенсеңіз, бұл ықтимал қауіпті болғандықтан, сиқыр толығымен жағында жұмыс істейді kubectl, API интерфейсімен жұмыс істейтін клиенттік кітапханаларды пайдаланған кезде оған сенбеу керек. Бұл жағдайда ағымдағы ресурс сипаттамасын оқып, оны жаңартып, содан кейін орындауға тура келеді PUT сұрау.
Сіз патч жасай алмайсыз - біз ауыстырамыз
Кейде API өңдей алмайтын кейбір өзгертулер енгізу қажет. Мұндай жағдайларда ресурсты жою және қайта жасау арқылы күштеп ауыстыруға болады. Бұл пайдалану арқылы жасалады kubectl replace --force. Пәрменді іске қосу ресурстарды дереу жояды, содан кейін оларды берілген спецификациядан қайта жасайды. API-де «күштеп ауыстыру» өңдегіші жоқ және мұны API арқылы орындау үшін екі әрекетті орындау керек. Алдымен ресурсты орнату арқылы жою керек gracePeriodSeconds нөлге (0) және propagationPolicy «Фон» бөліміне өтіп, осы ресурсты қажетті спецификациямен қайта жасаңыз.
Ескерту: Бұл тәсіл ықтимал қауіпті және анықталмаған күйге әкелуі мүмкін.
Сервер жағында қолданыңыз
Жоғарыда айтылғандай, Kubernetes әзірлеушілері логиканы енгізу бойынша жұмыс істеуде apply -дан kubectl Kubernetes API ішінде. Логика apply Kubernetes 1.18 арқылы қол жетімді kubectl apply --server-side немесе әдісті пайдаланып API арқылы PATCH с content-type application/apply-patch+YAML.
Ескерту: JSON да жарамды YAML, сондықтан спецификацияны JSON ретінде жіберуге болады
content-typeболадыapplication/apply-patch+yaml.
Бұл логикадан басқа kubectl API арқылы барлығына қолжетімді болады, apply сервер жағында спецификациядағы өрістерге кім жауапты екенін қадағалап отырады, осылайша оны қайшылықсыз өңдеу үшін қауіпсіз бірнеше рет қол жеткізуге мүмкіндік береді. Басқаша айтқанда, егер apply сервер жағында кеңірек таралады, әртүрлі клиенттер үшін әмбебап қауіпсіз ресурстарды басқару интерфейсі пайда болады, мысалы, kubectl, Pulumi немесе Terraform, GitOps, сондай-ақ клиенттік кітапханаларды пайдаланатын өздігінен жазылған сценарийлер.
Нәтижелері
Кластерлердегі ресурстарды жаңартудың әртүрлі тәсілдеріне қысқаша шолу сізге пайдалы болды деп үміттенемін. Бұл жай ғана қолдану және ауыстыру емес екенін білу жақсы; ресурсты қолдану, өңдеу, түзету немесе ауыстыру арқылы жаңартуға болады. Негізінде, әрбір тәсілдің өз қолдану саласы бар. Атомдық өзгерістер үшін ауыстыру жақсырақ; әйтпесе қолданба арқылы стратегиялық біріктіру патчын пайдалану керек. Кем дегенде, «kubernetes қолданылады және ауыстыру» деп іздеу кезінде Google немесе StackOerflow-қа сенуге болмайтыныңызды түсінуіңізді күтемін. Кем дегенде, осы мақала ағымдағы жауапты ауыстырмайынша.
Ақпарат көзі: www.habr.com