Заўв. перав.: Аўтар арыгінальнага артыкула - Théo Chamley, архітэктар хмарных рашэнняў Google. У гэтай публікацыі для блога Google Cloud ён прадставіў кароткі выціск з больш дэталёвага кіраўніцтва яго кампаніі, названага «». У ім спецыялісты Google сабралі лепшыя практыкі па эксплуатацыі кантэйнераў у кантэксце выкарыстання Google Kubernetes Engine і не толькі, закрануўшы шырокі спектр тэм: ад бяспекі да маніторынгу і часопісавання. Такім чынам, якія практыкі ў працы з кантэйнерамі найболей важныя па меркаванні Google?
(заснаваны на Kubernetes сэрвіс для запуску кантэйнерызаваных прыкладанняў у Google Cloud - заўв. перав.) - Адзін з лепшых спосабаў запуску працоўных нагрузак, якія маюць патрэбу ў маштабаванні. забяспечыць беспраблемнае функцыянаванне большасці прыкладанняў, калі яны кантэйнерызаваны. Але калі вы хочаце, каб дадаткам было лёгка кіраваць, і хочаце скарыстацца ўсімі перавагамі Kubernetes, неабходна прытрымлівацца лепшым практыкам. Яны спросцяць эксплуатацыю прыкладання, яго маніторынг і адладку, а таксама падвысяць бяспеку.
У гэтым артыкуле мы пройдземся па спісе таго, што варта ведаць і рабіць для эфектыўнага функцыянавання кантэйнераў у Kubernetes. Жадаючым паглыбіцца ў дэталі варта прачытаць матэрыял , а таксама звярнуць увагу на наш аб зборцы кантэйнераў.
1. Выкарыстоўвайце родныя механізмы кантэйнераў для лагавання
Калі дадатак запушчана ў кластары Kubernetes, для логаў трэба не так шмат. Цэнтралізаваная сістэма лагавання, верагодна, ужо ўбудавана ў выкарыстоўваны кластар. У выпадку выкарыстання Kubernetes Engine за гэта адказвае . (Заўв. перав.: А ў выпадку выкарыстання ўласнай усталёўкі Kubernetes рэкамендуем прыгледзецца да нашага Open Source-рашэння. .) Не ўскладняйце сабе жыццё і выкарыстоўвайце родныя механізмы часопісавання кантэйнераў. Пішыце логі ў stdout і stderr - яны будуць аўтаматычна атрыманы, захаваны і праіндэксаваны.
Пры жаданні можна таксама пісаць логі ў . Такі падыход дазволіць лёгка дадаваць да іх метададзеныя. А разам з імі ў Stackdriver Logging з'явіцца магчымасць пошуку па логах з выкарыстаннем гэтых метададзеных.
2. Пераканайцеся, што кантэйнеры - stateless і immutable
Для карэктнага функцыянавання кантэйнераў у кластары Kubernetes яны павінны быць stateless і immutable. Калі гэтыя ўмовы выкананы, Kubernetes зможа выконваць сваю працу, ствараючы і знішчаючы сутнасці прыкладання, калі і дзе гэта неабходна.
Без грамадзянства азначае, што любы стан (пастаянныя дадзеныя любога віду) захоўваюцца па-за кантэйнерам. Для гэтага, у залежнасці ад запатрабаванняў, могуць быць задзейнічаны розныя выгляды вонкавых сховішчаў: , , , ці іншыя кіраваныя базы дадзеных. (Заўв. перав.: Больш падрабязна пра гэта чытайце таксама ў нашым артыкуле «".)
Нязменны азначае, што кантэйнер не будзе мадыфікаваны падчас свайго жыцця: ніякіх абнаўленняў, патчаў, змен у канфігурацыі. Калі вам трэба абнавіць код прыкладання або прымяніць патч, стварыце новую выяву і задэплойце яго. Рэкамендуецца выносіць канфігурацыю кантэйнера (порт для праслухоўвання, опцыі выкананага асяроддзя і да т.п.) па-за - у и . Іх можна абнаўляць без неабходнасці збіраць новую выяву кантэйнера. Для простага стварэння пайплайнаў са зборкай вобразаў можна выкарыстоўваць . (Заўв. перав.: Мы для гэтых мэт выкарыстоўваем Open Source-інструмент .)
Прыклад абнаўлення канфігурацыі Deployment у Kubernetes з дапамогай ConfigMap, прымантаванага ў поды ў якасці канфігу.
3. Пазбягайце прывілеяваных кантэйнераў
Вы ж не запускаеце прыкладанні пад root'ом на сваіх серверах, праўда? Калі зламыснік пракрадзецца ў дадатак, ён атрымае доступ з правамі root. Тыя ж меркаванні справядлівыя і для таго, каб не запускаць прывілеяваныя кантэйнеры. Калі патрабуецца змяняць налады на хасце, можна выдаць кантэйнеру канкрэтныя магчымасці з дапамогай опцыі у Kubernetes. Калі трэба змяняць sysctls, у Kubernetes ёсць для гэтага. А ўвогуле, старайцеся максімальна выкарыстоўваць і sidecar-кантэйнеры для выканання падобных прывілеяваных аперацый. Яны не маюць патрэбы ў даступнасці ні для ўнутранага, ні для знешняга трафіку.
Калі вы адмініструеце кластар, можаце скарыстацца для абмежаванняў ва ўжыванні прывілеяваных кантэйнераў.
4. Пазбягайце запуску пад root
Аб прывілеяваных кантэйнерах ужо сказана, але будзе яшчэ лепш, калі ў дадатак да гэтага вы не будзеце запускаць пад root'ом прыкладанні ўсярэдзіне кантэйнера. Калі зламыснік знойдзе ў дадатку з правамі root выдаленую ўразлівасць з магчымасцю выканання кода, пасля чаго зможа выйсці з меж кантэйнера праз пакуль яшчэ невядомую ўразлівасць, тое атрымае root'а на хасце.
Лепшы шлях пазбегнуць гэтага - у першую чаргу не запускаць нічога пад root'ом. Для гэтага можна скарыстацца дырэктывай USER в Dockerfile або runAsUser у Kubernetes. Адміністратар кластара можа таксама наладзіць прымусовыя паводзіны з дапамогай .
5. Зрабіце прыкладанне простым для маніторынгу
Як і лагіраванне, маніторынг - неад'емная частка кіравання дадаткам. Папулярным рашэннем для маніторынгу ў супольнасці Kubernetes з'яўляецца - сістэма, якая аўтаматычна выяўляе поды і сэрвісы, якія патрабуюць маніторынгу. (Заўв. перав.: Гл. таксама наш па тэме маніторынгу з дапамогай Prometheus і Kubernetes.) здольны маніторыць кластары Kubernetes і ўключае ў сябе сваю версію Prometheus для маніторынгу прыкладанняў.
Панэль маніторынгу Kubernetes у Stackdriver
Prometheus чакае, што дадатак пракіне метрыкі на HTTP endpoint. Для гэтага даступныя . Такі ж фармат выкарыстоўваюць іншыя інструменты накшталт и .
6. Зрабіце даступным стан здароўя прыкладання
Кіраванню дадаткам у production дапамагае яго здольнасць паведамляць аб сваім стане ўсёй сістэме. Ці запушчана дадатак? Ці ў парадку яно? Ці гатова прымаць трафік? Як сябе паводзіць? Найбольш распаўсюджаным спосабам вырашэння гэтай праблемы з'яўляецца рэалізацыя праверак здароўя. (health checks). У Kubernetes ёсць два іх тыпы: .
Для liveness probe (праверкі на жыццяздольнасць) прыкладанне павінна мець HTTP endpoint, які вяртае адказ "200 OK", калі яно функцыянуе і яго асноўныя залежнасці задаволены. Для readiness probe (праверкі на гатоўнасць да абслугоўвання) прыкладанне павінна мець іншы HTTP endpoint, які вяртае адказ "200 OK", калі дадатак знаходзіцца ў здаровым стане, крокі па ініцыялізацыі выкананы і любы карэктны запыт не прыводзіць да памылкі. Kubernetes будзе накіроўваць трафік на кантэйнер толькі ў выпадку гатоўнасці дадатку ў адпаведнасці з гэтымі праверкамі. Два endpoint'а могуць аб'яднаныя, калі розніца паміж станамі жыццяздольнасці (liveness) і гатоўнасці (readiness) няма.
Больш падрабязна пра гэта можна прачытаць у адпаведным артыкуле ад Sandeep Dinesh, Developer Advocate з Google: «.
7. Уважліва выбірайце версію выявы
Большасць публічных і прыватных выяў выкарыстоўваюць сістэму тэгавання, падобную на апісаную ў . Калі выява ўжывае сістэму, блізкую да , неабходна ўлічваць спецыфіку тэгавання. Напрыклад, тэг latest можа часта перамяшчацца з выявы на выяву - на яго нельга спадзявацца, калі вам патрэбныя прадказальныя і ўзнаўляльныя зборкі і ўсталёўкі.
Можаце выкарыстоўваць тэг X.Y.Z (яны амаль заўсёды нязменныя), аднак у такім выпадку адсочвайце ўсе патчы і абнаўленні да выявы. Калі ў выкарыстоўванай выявы ёсць тэг X.Y, гэта добры варыянт залатой сярэдзіны. Выбраўшы яго, вы аўтаматычна атрымліваеце патчы і ў той жа час абапіраецеся на стабільную версію прыкладання.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «» (агляд і відэа даклада);
- «» (агляд і відэа даклада);
- «» (агляд і відэа даклада);
- «» (агляд і відэа даклада);
- «.
Крыніца: habr.com