Phenquestions
Нека да започнем с наивна дефиниция на „безгражданство“ и след това бавно да преминем към по-строг и реален поглед.
Приложение без гражданство е това, което зависи от постоянното съхранение. Единственото нещо, за което отговаря вашият клъстер, е кодът и другото статично съдържание, хоствано на него. Това е всичко, без промяна на бази данни, без запис и без остатъчни файлове при изтриване на шушулката.
Приложението с състояние, от друга страна, има няколко други параметъра, за които се очаква да се грижи в клъстера. Има динамични бази данни, които дори когато приложението е офлайн или изтрито, продължават да съществуват на диска. В разпределена система, като Kubernetes, това повдига няколко проблема. Ще ги разгледаме подробно, но първо нека изясним някои заблуди.
Услугите без гражданство всъщност не са „без гражданство“
Какво означава, когато казваме състоянието на системата? Е, нека да разгледаме следния прост пример за автоматична врата.
Вратата се отваря, когато сензорът засече някой, който се приближава, и се затваря, след като сензорът не получи подходящ вход.
На практика приложението ви без гражданство е подобно на този механизъм по-горе. Той може да има много повече състояния, отколкото просто затворени или отворени, както и много различни видове вход, което го прави по-сложен, но по същество един и същ.
Той може да реши сложни проблеми, като просто получи вход и изпълни действия, които зависят както от входа, така и от „състоянието“, в което се намира. Броят на възможните състояния е предварително зададен.
Така че безгражданството е погрешно наименование.
Приложенията без гражданство на практика могат също така да изневеряват, като запазват подробности за, да речем, клиентските сесии на самия клиент (HTTP бисквитките са чудесен пример) и въпреки това имат приятно безгражданство, което ще ги накара да работят безотказно на клъстера.
Например, подробности за сесията на клиента, като например какви продукти са били запазени в количката и не са извадени, могат да се съхраняват в клиента и следващият път, когато сесията започне, тези съответни подробности също се припомнят.
В клъстер Kubernetes приложение без състояние няма постоянно съхранение или том, свързани с него. От гледна точка на операциите това е страхотна новина. Различните шушулки в целия клъстер могат да работят независимо с множество заявки, идващи към тях едновременно. Ако нещо се обърка, можете просто да рестартирате приложението и то ще се върне в първоначалното състояние с малко престой.
Държавни услуги и теорема за ОСП
От друга страна, държавните служби ще трябва да се притесняват за много, много крайни случаи и странни проблеми. Подът се придружава с поне един том и ако данните в него са повредени, това продължава, дори ако целият клъстер се рестартира.
Например, ако използвате база данни на клъстер Kubernetes, всички шушулки трябва да имат локален том за съхранение на базата данни. Всички данни трябва да бъдат перфектно синхронизирани.
Така че, ако някой модифицира запис в базата данни и това е направено в под A, а заявка за четене идва в под B, за да види тези модифицирани данни, тогава под B трябва да покаже последните данни или да ви даде съобщение за грешка. Това е известно като последователност.
Последователност, в контекста на клъстер Kubernetes, означава всяко четене получава последното писане или съобщение за грешка.
Но това намалява наличност, една от най-важните причини за наличието на разпределена система. Наличността предполага, че вашето приложение функционира възможно най-близо до съвършенство, денонощно, с възможно най-малко грешки.
Може да се твърди, че можете да избегнете всичко това, ако имате само една централизирана база данни, която е отговорна за обработката на всички постоянни нужди от съхранение. Сега се върнахме към една точка на отказ, което е още един проблем, който клъстерите Kubernetes трябва да решат на първо място.
Трябва да имате децентрализиран начин за съхраняване на постоянни данни в клъстер. Обикновено се нарича мрежово разделяне. Освен това вашият клъстер трябва да може да оцелее при отказ на възли, изпълняващи приложението с състояние. Това е известно като толерантност на дяла.
Всяка услуга за състояние (или приложение), изпълнявана на клъстер Kubernetes, трябва да има баланс между тези три параметъра. В индустрията е известна като теорема за ОСП, при която се вземат предвид компромисите между последователност и наличност при наличие на мрежово разделяне.
Допълнителни справки
За по-нататъшно вникване в теоремата за ОСП може да искате да разгледате тази отлична беседа, изнесена от Брайън Кантрил, който разглежда много по-отблизо работещите разпределени системи в производството.
