Kubernetes prakticky: perzistentní storage pro stateful situace
Kontejnery v Kubernetes jsou naprosto ideální pro stateless služby. Pokud potřebujete držet state, použijte plně spravované služby Azure jako jsou databáze, fronty nebo objektová storage. Přesto někdy můžete mít potřebu ukládat data v kontejnerech tak, že pod tím bude perzistentní storage. Tak jak si ve storage vytvoříte Volume pro připojení k VM, víte že je spolehlivý, redundantní a po odstranění VM tam data stále jsou, tak můžete chtít používat storage v kontejnerech. Jak na to?
Perzistence a stav v kontejnerech v Kubernetes
První moje doporučení je v co nejvíc službách to jde žádný state nemít. Pokud to vaše byznys logika umožňuje, tak ať jsou to bezestavové idempotentní funkce. Něco se jich zeptáte, ony se třeba někam podívají nebo budou něco počítat a vyplivnou výsledek. Mezi jejich voláním netřeba držet žádný state. U některých funkcí je to přirozený způsob, například webový frontend, který má za úkol vygenerovat stránku a veškerý state je buď v backendu nebo naopak na straně klienta.
Pokud potřebujete držet nějaký stav mezi voláními navrhuji jako druhou cestu co do preference tento stav externalizovat. Můžete třeba místo držení stavu jako takového zapisovat změny stavu (události) třeba do Azure Event Hub a implementovat tak Event Sourcing pattern. Možná je state jednoduchý a dočasný, třeba obsah nákupního košíku, a pak použijte Azure Redis. Dlouhodobější stav držte v Azure Cosmos DB (s možností MongoDB, SQL, Gremlin či Cassandra API), Azure Database fo MySQL, PostgreSQL, MariaDB nebo Azure SQL. Provázání komponent či událostně řízené systémy krásně rozjedete s Azure Queue, Azure Service Bus, Azure Event Grid a tak podobně. Statický obsah webu můžete servírovat rovnou z Azure Blob Storage případně v kombinaci s Azure CDN. Zkráta proč se trápit se stavem v Kubernetes, když jsou krásné hotové služby s SLA běžně na úrovni 99,99% a je to bez práce a přemýšlení.
Ani jedno neberete? Například máte aplikaci postavenou na databázi, která v Azure jako plně spravovaná služba zatím není? Či se váš distribuovaný systém neobejde bez koordinace v Etcd či Consul? Nebo potřebujete perzistenci a máte masivní požadavky na propustnost a latenci? V takový okamžik je rozhodně na místě použít perzistentní storage v Kubernetes.
V dnešním díle se budeme věnovat jen a pouze perzistentní storage. Z pohledu Compute je klasický Deployment v Kubernetes vhodný pro stateless služby, ne pro ty stavové. Často totiž potřebujete trochu jemnější chování ke stavové aplikaci (nepříklad nesestřelovat náhodně mastera databáze, nepřejmenovávat uzly a tak podobně). O tom a konceptu StatefulSetů někdy příště.