{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Wzorce przechowywania danych w Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wzorce<\/a><\/noindex>
\nCze\u015b\u0107, Habr!<\/p>\n

Przypominamy, \u017ce wydali\u015bmy kolejn\u0105 wyj\u0105tkowo ciekaw\u0105 i przydatn\u0105 ksi\u0105\u017ck\u0119<\/a><\/noindex> o wzorcach Kubernetes. Wszystko zacz\u0119\u0142o si\u0119 jeszcze od \"Wzorc\u00f3w<\/a><\/noindex>\" Brendana Burnsa, a w ka\u017cdym razie nasza praca w tym segmencie wrze<\/a><\/noindex>. Dzi\u015b proponujemy Ci przeczyta\u0107 artyku\u0142 z bloga MinIO, kt\u00f3ry w skr\u00f3cie przedstawia tendencje i specyfik\u0119 wzorc\u00f3w przechowywania danych w Kubernetes.
\n<\/a><\/noindex><\/p>\n

Kubernetes zasadniczo zmieni\u0142 tradycyjne wzorce rozwoju i wdra\u017cania aplikacji. Teraz zespo\u0142y mog\u0105 potrzebowa\u0107 zaledwie kilku dni na rozw\u00f3j, testowanie i wdra\u017canie aplikacji \u2014 w r\u00f3\u017cnych \u015brodowiskach, i to wszystko w ramach klastr\u00f3w Kubernetes. Tego rodzaju prace z technologiami poprzednich pokole\u0144 zazwyczaj zajmowa\u0142y ca\u0142e tygodnie, je\u015bli nie miesi\u0105ce.<\/p>\n

Takie przyspieszenie sta\u0142o si\u0119 mo\u017cliwe dzi\u0119ki abstrakcji oferowanej przez Kubernetes \u2014 to znaczy, dzi\u0119ki temu, \u017ce Kubernetes sam zarz\u0105dza interakcj\u0105 z niskopoziomowymi detalami fizycznych lub wirtualnych maszyn, pozwalaj\u0105c u\u017cytkownikom deklarowa\u0107 mi\u0119dzy innymi potrzebny procesor, odpowiedni\u0105 ilo\u015b\u0107 pami\u0119ci, liczb\u0119 instancji kontener\u00f3w. Poniewa\u017c wsparciem Kubernetes zajmuje si\u0119 ogromna spo\u0142eczno\u015b\u0107, a jego zastosowania stale si\u0119 rozszerzaj\u0105, z du\u017c\u0105 przewag\u0105 prowadzi on w\u015br\u00f3d wszystkich platform orkiestracji kontener\u00f3w.<\/p>\n

W miar\u0119 jak wzrasta zastosowanie Kubernetes, ro\u015bnie r\u00f3wnie\u017c zamieszanie dotycz\u0105ce stosowanych w nim wzorc\u00f3w przechowywania danych.<\/b><\/i>.<\/p>\n

W sytuacji, gdy konkurencja o kawa\u0142ek tortu Kubernetes (to znaczy, o magazyn danych) jest tak intensywna, podczas rozm\u00f3w o przechowywaniu danych sygna\u0142 ten ginie w silnym ha\u0142asie.
\nKubernetes wciela nowoczesny model rozwoju i wdra\u017cania aplikacji, a tak\u017ce ich zarz\u0105dzania. Taki nowoczesny model oddziela przechowywanie danych od oblicze\u0144. Aby w pe\u0142ni zrozumie\u0107 to oddzielenie w kontek\u015bcie Kubernetes, nale\u017cy tak\u017ce zrozumie\u0107, czym s\u0105 aplikacje dzia\u0142aj\u0105ce z zachowaniem stanu i bez tego, a tak\u017ce jak z tym zwi\u0105zane jest przechowywanie danych. Tutaj podej\u015bcie REST API u\u017cywane przez S3 ma wyra\u017ane przewagi w por\u00f3wnaniu z podej\u015bciem POSIX\/CSI, charakterystycznym dla innych rozwi\u0105za\u0144.<\/p>\n

W tym artykule porozmawiamy o wzorcach przechowywania danych w Kubernetes oraz osobno om\u00f3wimy sp\u00f3r dotycz\u0105cy aplikacji dzia\u0142aj\u0105cych z przechowywaniem stanu i bez niego, aby dok\u0142adnie zrozumie\u0107, na czym polega r\u00f3\u017cnica mi\u0119dzy nimi i dlaczego jest ona wa\u017cna. Nast\u0119pnie w tek\u015bcie zostan\u0105 om\u00f3wione aplikacje i stosowane w nich wzorce przechowywania danych w \u015bwietle najlepszych praktyk pracy z kontenerami i Kubernetes.<\/p>\n

Kontenery bez stanu<\/h4>\n

\nKontenery s\u0105 z natury lekkie i efemeryczne. Mo\u017cna je \u0142atwo zatrzymywa\u0107, usuwa\u0107 lub wdra\u017ca\u0107 na innym w\u0119\u017ale \u2013 wszystko to zajmuje tylko kilka sekund. W du\u017cym systemie orkiestracji kontener\u00f3w takie operacje odbywaj\u0105 si\u0119 nieustannie, a u\u017cytkownicy nawet nie zauwa\u017caj\u0105 tych zmian. Jednak przemieszczenia s\u0105 mo\u017cliwe tylko wtedy, gdy kontener nie ma \u017cadnych zale\u017cno\u015bci od w\u0119z\u0142a, na kt\u00f3rym si\u0119 znajduje. O takich kontenerach m\u00f3wi si\u0119, \u017ce dzia\u0142aj\u0105 bez stanu<\/i>.<\/p>\n

Kontenery ze stanem<\/h4>\n

\nJe\u015bli kontener przechowuje dane na lokalnie pod\u0142\u0105czonych urz\u0105dzeniach (lub na urz\u0105dzeniu blokowym), to przechowywanie danych, na kt\u00f3rym si\u0119 znajduje, b\u0119dzie musia\u0142o zosta\u0107 przeniesione na nowy w\u0119ze\u0142 razem z samym kontenerem \u2014 w przypadku awarii. To wa\u017cne, poniewa\u017c w przeciwnym razie aplikacja uruchomiona w kontenerze nie b\u0119dzie mog\u0142a prawid\u0142owo funkcjonowa\u0107, poniewa\u017c musi mie\u0107 dost\u0119p do danych przechowywanych na lokalnych no\u015bnikach. O takich kontenerach m\u00f3wi si\u0119, \u017ce dzia\u0142aj\u0105 ze stanem<\/i>.<\/p>\n

Z czysto technicznego punktu widzenia, kontenery ze stanem r\u00f3wnie\u017c mo\u017cna przenosi\u0107 na inne w\u0119z\u0142y. Zwykle odbywa si\u0119 to za pomoc\u0105 rozproszonych system\u00f3w plik\u00f3w lub blokowych sieciowych magazyn\u00f3w danych, kt\u00f3re s\u0105 pod\u0142\u0105czane do wszystkich w\u0119z\u0142\u00f3w, na kt\u00f3rych dzia\u0142aj\u0105 kontenery. Dzi\u0119ki temu kontenery uzyskuj\u0105 dost\u0119p do wolumen\u00f3w do przechowywania danych, a informacje s\u0105 przechowywane na dyskach rozmieszczonych w ca\u0142ej sieci. T\u0119 metod\u0119 nazywam \u201ekontenerowym podej\u015bciem ze stanem<\/i>\u201d, i tak b\u0119d\u0119 j\u0105 nazywa\u0142 w dalszej cz\u0119\u015bci artyku\u0142u dla zachowania sp\u00f3jno\u015bci.<\/p>\n

\"Wzorce
\n
\nW typowym podej\u015bciu kontenerowym z zachowaniem stanu wszystkie pody aplikacji s\u0105 przypisane do jednego rozproszonego systemu plik\u00f3w \u2013 powstaje w ten spos\u00f3b pewnego rodzaju wsp\u00f3\u0142dzielona przestrze\u0144, w kt\u00f3rej przechowywane s\u0105 wszystkie dane aplikacji. Chocia\u017c mo\u017cliwe s\u0105 pewne wariacje, to jest to podej\u015bcie na wysokim poziomie.<\/p>\n

Teraz zajmijmy si\u0119 tym, dlaczego podej\u015bcie kontenerowe z zachowaniem stanu w \u015bwiecie zorientowanym na chmur\u0119 jest antywzorem.<\/p>\n

Projektowanie aplikacji zorientowanych na chmur\u0119<\/h4>\n

\nTradycyjnie aplikacje wykorzystywa\u0142y bazy danych do strukturalnego przechowywania informacji oraz lokalne dyski lub rozproszone systemy plik\u00f3w, do kt\u00f3rych zrzucano wszystkie nieustrukturyzowane lub nawet p\u00f3\u0142strukturyzowane dane. W miar\u0119 wzrostu ilo\u015bci danych nieustrukturyzowanych, programi\u015bci zdali sobie spraw\u0119, \u017ce POSIX jest zbyt 'rozgadany', wi\u0105\u017ce si\u0119 z znacznych kosztami i ostatecznie utrudnia dzia\u0142anie aplikacji przy przej\u015bciu do rzeczywi\u015bcie du\u017cych skali.<\/p>\n

To w g\u0142\u00f3wnej mierze przyczyni\u0142o si\u0119 do powstania nowego standardu przechowywania danych, czyli chmurowych magazyn\u00f3w, dzia\u0142aj\u0105cych g\u0142\u00f3wnie na podstawie REST API i uwalniaj\u0105cych aplikacj\u0119 od uci\u0105\u017cliwego zarz\u0105dzania lokalnym magazynem danych. W takim wypadku aplikacja przechodzi faktycznie w tryb pracy bez zachowania stanu (poniewa\u017c stan znajduje si\u0119 w zdalnym magazynie). Wsp wsp\u00f3\u0142czesne aplikacje s\u0105 budowane od podstaw z uwzgl\u0119dnieniem tego czynnika. Zazwyczaj ka\u017cda nowoczesna aplikacja zajmuj\u0105ca si\u0119 danymi r\u00f3\u017cnego rodzaju (logi, metadane, bloby itp.) jest zbudowana w oparciu o chmurow\u0105 paradygmat\u0119, gdzie stan jest przenoszony do specjalnie przeznaczonego do jego przechowywania systemu oprogramowania. <\/p>\n

Podej\u015bcie kontenerowe z zachowaniem stanu zmusza ca\u0142\u0105 t\u0119 paradygmat\u0119 do powrotu do tego, od czego si\u0119 zacz\u0119\u0142a! <\/b><\/i><\/p>\n

Kiedy aplikacje korzystaj\u0105 z interfejs\u00f3w POSIX do przechowywania danych, dzia\u0142aj\u0105 w ten sam spos\u00f3b, jak gdyby zapisywa\u0142y stan, przez co odst\u0119puj\u0105 od najwa\u017cniejszych zasad projektowania chmurowego, to znaczy od mo\u017cliwo\u015bci zmiany rozmiaru w\u0105tk\u00f3w roboczych aplikacji w zale\u017cno\u015bci od obci\u0105\u017cenia, przechodzenia na nowy w\u0119ze\u0142, gdy aktualny w\u0119ze\u0142 zawiedzie, i tak dalej.<\/p>\n

Przygl\u0105daj\u0105c si\u0119 tej sytuacji bli\u017cej, odkrywamy, \u017ce przy wyborze magazynu danych wci\u0105\u017c napotykamy dylemat \u201ePOSIX kontra REST API\u201d, ALE z dodatkowym pogorszeniem problem\u00f3w zwi\u0105zanych z POSIX, spowodowanym rozproszon\u0105 natur\u0105 \u015brodowisk Kubernetes. W szczeg\u00f3lno\u015bci,<\/p>\n