{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 najlepszych praktyk dotycz\u0105cych eksploatacji kontener\u00f3w wed\u0142ug Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Przyp. t\u0142um.<\/b>: Autor oryginalnego artyku\u0142u \u2014 Th\u00e9o Chamley, architekt rozwi\u0105za\u0144 chmurowych Google. W tej publikacji na blogu Google Cloud przedstawi\u0142 kr\u00f3tkie podsumowanie bardziej szczeg\u00f3\u0142owego przewodnika swojej firmy, zatytu\u0142owanego \u201eNajlepsze praktyki dotycz\u0105ce obs\u0142ugi kontener\u00f3w<\/a><\/noindex>\u201d. W nim specjali\u015bci Google zebrali najlepsze praktyki dotycz\u0105ce eksploatacji kontener\u00f3w w kontek\u015bcie u\u017cycia Google Kubernetes Engine i nie tylko, poruszaj\u0105c szeroki zakres temat\u00f3w: od bezpiecze\u0144stwa po monitorowanie i rejestrowanie. Jakie zatem praktyki w pracy z kontenerami s\u0105 wed\u0142ug Google najwa\u017cniejsze?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (us\u0142uga oparta na Kubernetes do uruchamiania aplikacji konteneryzowanych w Google Cloud \u2014 przyp. t\u0142um.<\/b>)<\/i> \u2014 to jeden z najlepszych sposob\u00f3w uruchamiania obci\u0105\u017ce\u0144 wymagaj\u0105cych skalowania. Kubernetes<\/a><\/noindex> zapewni bezproblemowe dzia\u0142anie wi\u0119kszo\u015bci aplikacji, je\u015bli s\u0105 one konteneryzowane. Ale je\u015bli chcesz, aby aplikacja by\u0142a \u0142atwa w zarz\u0105dzaniu i chcia\u0142by\u015b skorzysta\u0107 ze wszystkich zalet Kubernetes, musisz stosowa\u0107 najlepsze praktyki. U\u0142atwi\u0105 one eksploatacj\u0119 aplikacji, jej monitorowanie i debugowanie, a tak\u017ce zwi\u0119ksz\u0105 bezpiecze\u0144stwo.<\/p>\n

W tym artykule przejdziemy przez list\u0119 rzeczy, kt\u00f3re warto wiedzie\u0107 i robi\u0107, aby kontenery w Kubernetes dzia\u0142a\u0142y efektywnie. Osoby chc\u0105ce zag\u0142\u0119bi\u0107 si\u0119 w szczeg\u00f3\u0142y powinny przeczyta\u0107 materia\u0142 Najlepsze praktyki dotycz\u0105ce obs\u0142ugi kontener\u00f3w<\/a><\/noindex>, a tak\u017ce zwr\u00f3ci\u0107 uwag\u0119 na nasz wcze\u015bniejszy post<\/a><\/noindex> na temat budowy kontener\u00f3w.<\/p>\n

1. U\u017cywaj natywnych mechanizm\u00f3w kontener\u00f3w do logowania<\/h2>\n

\nJe\u015bli aplikacja jest uruchomiona w klastrze Kubernetes, do log\u00f3w nie trzeba wiele. Zcentralizowany system logowania prawdopodobnie ju\u017c jest wbudowany w u\u017cywany klaster. W przypadku korzystania z Kubernetes Engine odpowiada za to Stackdriver Logging<\/a><\/noindex>. (Przyp. t\u0142um.<\/b>: A w przypadku korzystania z w\u0142asnej instalacji Kubernetes polecamy zwr\u00f3ci\u0107 uwag\u0119 na nasze rozwi\u0105zanie Open Source \u2014 loghouse<\/a><\/noindex>.)<\/i> Nie komplikuj sobie \u017cycia i korzystaj z natywnych mechanizm\u00f3w logowania kontener\u00f3w. Pisz logi do stdout i stderr \u2014 zostan\u0105 one automatycznie przechwycone, zapisane i zaindeksowane.<\/p>\n

W razie potrzeby mo\u017cna r\u00f3wnie\u017c pisa\u0107 logi do formacie JSON<\/a><\/noindex>. Takie podej\u015bcie umo\u017cliwi \u0142atwe dodawanie do nich metadanych. A wraz z nimi w Stackdriver Logging pojawi si\u0119 mo\u017cliwo\u015b\u0107 przeszukiwania log\u00f3w z u\u017cyciem tych metadanych.<\/p>\n

2. Upewnij si\u0119, \u017ce kontenery s\u0105 stateless i immutable<\/h2>\n

\nAby kontenery w klastrze Kubernetes dzia\u0142a\u0142y poprawnie, musz\u0105 by\u0107 stateless i immutable. Kiedy te warunki s\u0105 spe\u0142nione, Kubernetes mo\u017ce wykonywa\u0107 swoj\u0105 prac\u0119, tworz\u0105c i niszcz\u0105c byty aplikacji, kiedy i gdzie to konieczne.<\/p>\n

Stateless<\/i> oznacza, \u017ce jakiekolwiek stany (trwa\u0142e dane wszelkiego rodzaju) s\u0105 przechowywane poza kontenerem. W tym celu, w zale\u017cno\u015bci od potrzeb, mog\u0105 by\u0107 wykorzystywane r\u00f3\u017cne rodzaje zewn\u0119trznych magazyn\u00f3w: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> lub inne zarz\u0105dzane bazy danych. (Przyp. t\u0142um.<\/b>: Wi\u0119cej na ten temat przeczytasz tak\u017ce w naszym artykule \u201eZalety i wady HugePages<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> oznacza, \u017ce kontener nie b\u0119dzie modyfikowany w trakcie swojego \u017cycia: \u017cadnych aktualizacji, poprawek, zmian w konfiguracji. Je\u015bli musisz zaktualizowa\u0107 kod aplikacji lub zastosowa\u0107 poprawk\u0119, stw\u00f3rz nowy obraz i wdro\u017c go. Zaleca si\u0119 przeniesienie konfiguracji kontenera (port do nas\u0142uchiwania, parametry \u015brodowiska wykonawczego itp.) na zewn\u0105trz \u2014 do Secrets<\/a><\/noindex> i ConfigMaps<\/a><\/noindex>. Mo\u017cna je aktualizowa\u0107 bez potrzeby ponownej budowy nowego obrazu kontenera. Do prostego tworzenia pipeline'\u00f3w do budowy obraz\u00f3w mo\u017cna u\u017cy\u0107 Cloud Build<\/a><\/noindex>. (Przyp. t\u0142um.<\/b>: Dla tych cel\u00f3w u\u017cywamy narz\u0119dzia Open Source dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nPrzyk\u0142ad aktualizacji konfiguracji Deployment w Kubernetes przy u\u017cyciu ConfigMap, zamontowanego w podach jako config<\/i><\/p>\n

3. Unikaj uruchamiania kontener\u00f3w z uprawnieniami<\/h2>\n

\nPewnie nie uruchamiasz aplikacji jako root na swoich serwerach, prawda? Je\u015bli haker dostanie si\u0119 do aplikacji, uzyska dost\u0119p z uprawnieniami root. Te same zasady dotycz\u0105 tak\u017ce nieuruchamiania uprzywilejowanych kontener\u00f3w. Je\u015bli zachodzi potrzeba zmiany ustawie\u0144 na ho\u015bcie, mo\u017cna przyzna\u0107 kontenerowi konkretne zdolno\u015bciami<\/i> za pomoc\u0105 opcji securityContext<\/code><\/a><\/noindex> w Kubernetes. Je\u015bli konieczne jest zmienienie sysctls<\/i>, Kubernetes ma osobn\u0105 adnotacj\u0119<\/a><\/noindex> do tego. Og\u00f3lnie rzecz bior\u0105c, staraj si\u0119 maksymalnie wykorzysta\u0107 init-<\/a><\/noindex> i kontenery sidecar do wykonywania podobnych uprzywilejowanych operacji. Nie musz\u0105 by\u0107 dost\u0119pne ani dla ruchu wewn\u0119trznego, ani zewn\u0119trznego.<\/p>\n

Je\u015bli zarz\u0105dzasz klastrem, mo\u017cesz skorzysta\u0107 z Pod Security Policy<\/a><\/noindex> do ogranicze\u0144 w stosowaniu uprzywilejowanych kontener\u00f3w.<\/p>\n

4. Unikaj uruchamiania jako root<\/h2>\n

\nO uprzywilejowanych kontenerach ju\u017c wspomniano, ale jeszcze lepiej, je\u015bli dodatkowo nie b\u0119dziesz uruchamia\u0107 aplikacji w kontenerze jako root. Je\u015bli haker znajdzie w aplikacji dzia\u0142aj\u0105cej z uprawnieniami root zdaln\u0105 luk\u0119 umo\u017cliwiaj\u0105c\u0105 wykonanie kodu, a nast\u0119pnie zdo\u0142a wydosta\u0107 si\u0119 z kontenera przez jeszcze nieznan\u0105 luk\u0119, uzyska dost\u0119p do roota na ho\u015bcie.<\/p>\n

Najlepszym sposobem, aby temu zapobiec, jest przede wszystkim nieuruchamianie niczego jako root. W tym celu mo\u017cna skorzysta\u0107 z dyrektywy USER<\/code> do Dockerfile<\/code> lub runAsUser<\/code> w Kubernetes. Administrator klastra mo\u017ce r\u00f3wnie\u017c skonfigurowa\u0107 wymuszone zachowanie przy pomocy Pod Security Policy<\/a><\/noindex>.<\/p>\n

5. U\u0142atwiaj monitorowanie aplikacji<\/h2>\n

\nPodobnie jak logowanie, monitorowanie jest nieod\u0142\u0105czn\u0105 cz\u0119\u015bci\u0105 zarz\u0105dzania aplikacj\u0105. Popularnym rozwi\u0105zaniem do monitorowania w spo\u0142eczno\u015bci Kubernetes jest Prometheus<\/a><\/noindex> \u2014 system, kt\u00f3ry automatycznie wykrywa pody i us\u0142ugi wymagaj\u0105ce monitorowania. (Przyp. t\u0142um.<\/b>: Zobacz tak\u017ce nasz szczeg\u00f3\u0142owy raport<\/a><\/noindex> na temat monitorowania za pomoc\u0105 Prometheus i Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> mo\u017ce monitorowa\u0107 klastry Kubernetes i zawiera swoj\u0105 wersj\u0119 Prometheus do monitorowania aplikacji.<\/p>\n

\"7
\nPanel monitorowania Kubernetes w Stackdriver<\/i><\/p>\n

Prometheus oczekuje, \u017ce aplikacja udost\u0119pni metryki na ko\u0144c\u00f3wce HTTP. W tym celu dost\u0119pne s\u0105 biblioteki klienckie Prometheus.<\/a><\/noindex>Taki sam format stosuj\u0105 inne narz\u0119dzia, takie jak OpenCensus<\/a><\/noindex> i Istio<\/a><\/noindex>.<\/p>\n

6. Umo\u017cliwiaj dost\u0119p do stanu zdrowia aplikacji<\/h2>\n

\nZarz\u0105dzaniu aplikacj\u0105 w produkcji pomaga jej zdolno\u015b\u0107 do raportowania swojego stanu ca\u0142emu systemowi. Czy aplikacja jest uruchomiona? Czy dzia\u0142a prawid\u0142owo? Czy jest gotowa do obs\u0142ugi ruchu? Jak si\u0119 zachowuje? Najbardziej powszechnym sposobem rozwi\u0105zania tego problemu jest implementacja kontrolnych punkt\u00f3w zdrowia (health checks)<\/i>. Kubernetes ma dwa ich typy: liveness i readiness probes<\/a><\/noindex>.<\/p>\n

Dla liveness probe (sprawdzanie \u017cywotno\u015bci)<\/i> aplikacja musi mie\u0107 ko\u0144c\u00f3wk\u0119 HTTP, kt\u00f3ra zwraca odpowied\u017a \u201e200 OK\u201d, je\u015bli dzia\u0142a i jej podstawowe zale\u017cno\u015bci s\u0105 spe\u0142nione. Dla readiness probe (sprawdzanie gotowo\u015bci do obs\u0142ugi)<\/i> aplikacja powinna mie\u0107 inny punkt ko\u0144cowy HTTP zwracaj\u0105cy odpowied\u017a \u201e200 OK\u201d, je\u015bli aplikacja jest w zdrowym stanie, kroki inicjalizacji zosta\u0142y wykonane, a ka\u017cde prawid\u0142owe \u017c\u0105danie nie prowadzi do b\u0142\u0119du. Kubernetes skieruje ruch do kontenera tylko wtedy, gdy aplikacja b\u0119dzie gotowa zgodnie z tymi kontrolami. Dwa punkty ko\u0144cowe mog\u0105 by\u0107 po\u0142\u0105czone, je\u015bli nie ma r\u00f3\u017cnicy mi\u0119dzy stanami \u017cywotno\u015bci (liveness) a gotowo\u015bci (readiness).<\/p>\n

Wi\u0119cej informacji mo\u017cna znale\u017a\u0107 w odpowiednim artykule autorstwa Sandeep Dinesha, rzecznika dewelopera z Google: \u201eNajlepsze praktyki Kubernetes: Ustawianie kontroli zdrowia za pomoc\u0105 pr\u00f3b gotowo\u015bci i \u017cywotno\u015bci<\/a><\/noindex>\u00bb.<\/p>\n

7. Starannie wybieraj wersj\u0119 obrazu<\/h2>\n

\nWi\u0119kszo\u015b\u0107 publicznych i prywatnych obraz\u00f3w u\u017cywa systemu tagowania podobnego do opisanego w Najlepsze praktyki tworzenia kontener\u00f3w<\/a><\/noindex>. Gdy obraz stosuje system zbli\u017cony do semantycznego wersjonowania<\/a><\/noindex>, nale\u017cy uwzgl\u0119dni\u0107 specyfik\u0119 tagowania. Na przyk\u0142ad tag latest<\/code> mo\u017ce cz\u0119sto przechodzi\u0107 z obrazu na obraz \u2014 nie mo\u017cna na nim polega\u0107, je\u015bli potrzebujesz przewidywalnych i odtwarzalnych wersji i instalacji.<\/p>\n

Mo\u017cesz u\u017cy\u0107 tagu X.Y.Z<\/code> (zazwyczaj pozostaje niezmienny), jednak w takim przypadku \u015bled\u017a wszystkie \u0142atki i aktualizacje obrazu. Je\u015bli u\u017cywany obraz ma tag X.Y<\/code>, to dobry wyb\u00f3r z\u0142otego \u015brodka. Wybieraj\u0105c go, automatycznie otrzymujesz \u0142atki, jednocze\u015bnie opieraj\u0105c si\u0119 na stabilnej wersji aplikacji.<\/p>\n

P.S. od t\u0142umacza<\/h2>\n

\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n