Úvod
Kubernetes nabízí mimořádnou úroveň flexibility pro orchestraci velkého clusteru distribuovaných kontejnerů.
Obrovský počet dostupných funkcí a možností může představovat výzvu. Použití osvědčených postupů vám pomůže vyhnout se potenciálním překážkám a vytvořit bezpečné a efektivní prostředí hned od začátku.
Použijte uvedené doporučené postupy pro Kubernetes k vytváření optimalizovaných kontejnerů, zefektivnění nasazení, správě spolehlivých služeb a správě plnohodnotného clusteru.
Zabezpečte a optimalizujte kontejnery
Kontejnery poskytují mnohem menší izolaci než virtuální stroje. Vždy byste měli ověřovat obrázky kontejnerů a udržovat přísnou kontrolu nad uživatelskými oprávněními.
Použití obrázků malých kontejnerů zvyšuje efektivitu, šetří zdroje a snižuje plochu útoku pro potenciální útočníky.
Používejte pouze důvěryhodné obrázky kontejnerů
Hotové obrázky kontejnerů jsou vysoce dostupné a výjimečně užitečné. Veřejné obrázky se však mohou rychle stát zastaralými, mohou obsahovat exploity, chyby nebo dokonce škodlivý software, který se rychle šíří v clusteru Kubernetes.
Používejte pouze obrázky z důvěryhodných úložišť a vždy skenujte obrázky, zda nejsou potenciální zranitelnosti. Četné online nástroje, jako je Anchore nebo Clair, poskytují rychlou statickou analýzu obrázků kontejnerů a informují vás o potenciálních hrozbách a problémech. Věnujte několik okamžiků skenování obrázků kontejnerů před jejich nasazením a vyhněte se potenciálně katastrofálním následkům.
Uživatelé bez oprávnění root a souborové systémy pouze pro čtení
Změňte kontext vestavěného zabezpečení tak, aby vynutil spuštění všech kontejnerů pouze s uživateli bez oprávnění root a se souborovým systémem pouze pro čtení.
Vyhněte se spouštění kontejnerů jako uživatel root. Narušení zabezpečení může rychle eskalovat, pokud si uživatel může udělit další oprávnění.
Pokud je souborový systém nastaven na pouze pro čtení, je malá šance na manipulaci s obsahem kontejneru. Místo úpravy systémových souborů by bylo potřeba odstranit celý kontejner a umístit na jeho místo nový.
Vytvářejte malé obrázky a obrázky ve vrstvách
Malé obrázky urychlují vaše sestavení a vyžadují méně místa. Efektivní vrstvení obrazu může výrazně snížit velikost obrazu. Zkuste vytvořit své obrázky od začátku, abyste dosáhli optimálních výsledků.
Pokud potřebujete mnoho různých komponent, použijte více příkazů FROM v jednom souboru Dockerfile. Tato funkce vytváří sekce, z nichž každá odkazuje na jiný základní obrázek. Finální obrázek již neukládá předchozí vrstvy, pouze komponenty, které z každé potřebujete, čímž je kontejner Docker mnohem štíhlejší.
Každá vrstva je získávána na základě FROM příkaz umístěný v nasazeném kontejneru.
Omezit uživatelský přístup pomocí RBAC
Řízení přístupu na základě rolí (RBAC) zajišťuje, že žádný uživatel nemá více oprávnění, než kolik potřebuje k dokončení svých úkolů. RBAC můžete povolit připojením následujícího příznaku při spouštění serveru API:
--authorization-mode=RBACRBAC používá rbac.authorization.k8s.io Skupina API pro řízení rozhodnutí o autorizaci prostřednictvím rozhraní Kubernetes API.
Protokoly Stdout a Stderr
Je běžnou praxí zasílat protokoly aplikací na stdout (standardní výstup) stream a protokoly chyb do stderr (standardní chyba) stream. Jakmile aplikace zapíše do stdout a stderr, kontejnerový modul, jako je Docker, přesměruje a uloží záznamy do souboru JSON.
Kontejnery, pody a uzly Kubernetes jsou dynamické entity. Protokoly musí být konzistentní a trvale dostupné. Proto se doporučuje uchovávat vaše protokoly pro celý cluster v samostatném backendovém úložném systému.
Kubernetes lze integrovat se širokou škálou stávajících protokolovacích řešení, jako je ELK Stack.
Zefektivnění nasazení
Nasazení Kubernetes vytváří šablonu, která zajišťuje, že pody budou spuštěny a spuštěny, pravidelně aktualizovány nebo vráceny zpět, jak je definováno uživatelem.
Použití jasných štítků, příznaků, propojených kontejnerů a DaemonSets vám může poskytnout jemnou kontrolu nad procesem nasazení.
Použití příznaku záznamu
Když připojíte --record příznak, provedený kubectl příkaz je uložen jako anotace. Kontrolou historie zavádění nasazení můžete snadno sledovat aktualizace v ZMĚNA PŘÍČINY sloupec.
Vraťte se zpět k jakékoli revizi deklarováním čísla revize v příkazu undo.
kubectl rollout undo deployment example-deployment --to-revision=1
Bez --record příznak, bylo by obtížné určit konkrétní revizi.
Popisné štítky
Zkuste použít co nejvíce popisných štítků. Štítky jsou páry klíč:hodnota, které uživatelům umožňují seskupovat a organizovat moduly do smysluplných podmnožin. Většina funkcí, pluginů a řešení třetích stran potřebuje štítky, aby bylo možné identifikovat moduly a řídit automatizované procesy.
Například Kubernetes DaemonSets závisí na štítcích a selektorech uzlů při správě nasazení pod v rámci clusteru.
Vytvořte více procesů v modulu
Použijte schopnosti Kubernetes propojovat kontejnery místo toho, abyste se pokoušeli vyřešit každý problém uvnitř kontejneru. Efektivně nasazuje více kontejnerů na jeden Kubernetes modul. Dobrým příkladem je outsourcing bezpečnostních funkcí na proxy sidecar kontejner.
Propojený kontejner může podporovat nebo vylepšovat základní funkce hlavního kontejneru nebo pomoci hlavnímu kontejneru přizpůsobit se jeho prostředí nasazení.
Použít kontejnery Init
Jeden nebo více init kontejnerů obvykle provádí pomocné úlohy nebo bezpečnostní kontroly, které nechcete zahrnout do hlavního kontejneru aplikace. Můžete použít init kontejnery, abyste se ujistili, že je služba připravena před spuštěním hlavního kontejneru podu.
Každý init kontejner musí být úspěšně dokončen před spuštěním následujícího init kontejneru. Init kontejnery mohou zpozdit nástup hlavního kontejneru modulu, dokud není splněna podmínka. Bez tohoto předpokladu Kubernetes restartuje modul. Jakmile je splněna podmínka, init kontejner se sám ukončí a umožní spuštění hlavního kontejneru.
Nepoužívejte nejnovější značku
Nepoužívejte žádnou značku nebo :latest tag při nasazování kontejnerů v produkčním prostředí. Nejnovější značka ztěžuje určení, která verze obrázku je spuštěna.
Účinným způsobem, jak zajistit, aby kontejner vždy používal stejnou verzi obrázku, je použít jako značku jedinečný souhrn obrázku. V tomto příkladu je verze obrázku Redis nasazena pomocí jedinečného výtahu:
[email protected]:675hgjfn48324cf93ffg43269ee113168c194352dde3eds876677c5cbKubernetes automaticky neaktualizuje verzi obrázku, pokud nezměníte hodnotu digestu.
Nastavení sond připravenosti a živosti
Životnost a sondy připravenosti pomozte Kubernetes sledovat a interpretovat stav vašich aplikací. Pokud definujete kontrolu živosti a proces splňuje požadavky, Kubernetes zastaví kontejner a na jeho místo spustí novou instanci.
Sondy připravenosti provádějí audity na úrovni modulu a hodnotí, zda modul může přijímat provoz. Pokud modul nereaguje, sonda připravenosti spustí proces restartování modulu.
Dokumentace pro konfiguraci sond připravenosti a životnosti je k dispozici na oficiálním webu Kubernetes.
Vyzkoušejte různé typy služeb
Naučíte-li se využívat různé typy služeb, můžete efektivně spravovat interní a externí provoz pod. Vaším cílem je vytvořit stabilní síťové prostředí správou spolehlivých koncových bodů, jako jsou adresy IP, porty a DNS.
Statické porty s NodePort
Vystavte moduly externím uživatelům nastavením typu služby na NodePort. Pokud zadáte hodnotu v nodePort Kubernetes rezervuje toto číslo portu napříč všemi uzly a předává veškerý příchozí provoz určený pro pody, které jsou součástí služby. Služba je přístupná pomocí IP interního clusteru i IP uzlu s vyhrazeným portem.
Uživatelé mohou kontaktovat službu NodePort z vnějšku clusteru požadavkem:
NodeIP:NodePortVždy používejte číslo portu v rozsahu nakonfigurovaném pro NodePort (30000-32767). Pokud se transakce API nezdaří, budete muset vyřešit možné kolize portů.
Ingress vs LoadBalancer
Typ LoadBalancer zpřístupňuje služby externě pomocí nástroje pro vyrovnávání zatížení vašeho poskytovatele. Každá služba, kterou zpřístupníte pomocí typu LoadBalancer, obdrží svou IP. Pokud máte mnoho služeb, můžete zaznamenat neplánované dodatečné náklady na základě počtu vystavených služeb.
Standardním požadavkem na konfiguraci je poskytnout řadiči vstupu existující statickou veřejnou IP adresu. Statická veřejná IP adresa zůstane, pokud je řadič vstupu odstraněn. Tento přístup vám umožňuje používat aktuální záznamy DNS a síťové konfigurace konzistentně po celou dobu životního cyklu vašich aplikací.
Namapujte externí služby na DNS
Typ ExternalName nemapuje služby na selektor, ale místo toho používá název DNS. Použijte externalName parametr k mapování služeb pomocí záznamu CNAME. Záznam CNAME je plně kvalifikovaný název domény, nikoli číselná adresa IP.
Klienti připojující se ke službě se chystají obejít server proxy a připojit se přímo k externímu zdroji. V tomto příkladu služba pnap je namapován na admin.phoenixnap.com externí zdroj.
Přístup ke službě pnap funguje stejně jako u jiných služeb. Zásadní rozdíl je v tom, že k přesměrování nyní dochází na úrovni DNS.
Návrh aplikace
Automatizované nasazení kontejnerů s Kubernetes zajišťuje, že většina operací nyní běží bez přímého lidského zásahu. Navrhněte své aplikace a obrázky kontejnerů tak, aby byly vzájemně zaměnitelné a nevyžadovaly neustálou mikrosprávu.
Zaměření na jednotlivé služby
Zkuste svou aplikaci rozdělit do více služeb a vyhněte se sdružování příliš mnoha funkcí do jednoho kontejneru. Je mnohem snazší horizontálně škálovat aplikace a znovu používat kontejnery, pokud se zaměřují na provádění jedné funkce.
Při vytváření aplikací předpokládejte, že vaše kontejnery jsou krátkodobé entity, které budou pravidelně zastavovány a restartovány.
Používejte grafy kormidla
Helm, správce balíků aplikací Kubernetes, dokáže velmi rychle zefektivnit proces instalace a nasadit prostředky v celém clusteru. Aplikační balíčky Helm se nazývají Charts.
Aplikace jako MySQL, PostgreSQL, MongoDB, Redis, WordPress jsou žádanými řešeními. Místo vytváření a úprav několika složitých konfiguračních souborů můžete nasadit snadno dostupné Helm Charts.
Pomocí následujícího příkazu vytvořte potřebná nasazení, služby, persistentVolumeClaims a tajemství potřebné ke spuštění Kafka Manager ve vašem clusteru.
helm install --name my-messenger stable/kafka-managerUž nemusíte analyzovat konkrétní komponenty a učit se, jak je nakonfigurovat, aby Kafka správně fungoval.
Využijte afinitu uzlu a podu
Funkce afinity se používá k definování afinity uzlů i afinity mezi pody. Afinita uzlů vám umožňuje určit uzly, pro které může být modul naplánován, pomocí existujících štítků uzlů.
- požadovánoDuringSchedulingIgnoredDuringExecution – Stanovuje povinná omezení, která musí být splněna, aby mohl být modul naplánován do uzlu.
- preferredDuringSchedulingIgnoredDuringExecution – Definuje preference, které plánovač upřednostňuje, ale nezaručuje.
Pokud se štítky uzlů za běhu změní a pravidla afinity podu již nejsou splněna, pod se z uzlu neodstraní. nodeSelector parametr omezuje pody na konkrétní uzly pomocí štítků. V tomto příkladu bude grafana pod naplánován pouze na uzlech, které mají ssd štítek.
Funkce afinity/antiafinity podu rozšiřuje typy omezení, která můžete vyjádřit. Místo použití štítků uzlů můžete použít existující štítky podů k vymezení uzlů, na kterých lze naplánovat pod. Tato funkce vám umožňuje nastavit pravidla tak, aby byly jednotlivé pody naplánovány na základě štítků jiných podů.
Poskvrny uzlů a tolerance
Kubernetes se automaticky pokusí nasadit pody do míst s nejmenší zátěží. Afinita uzlu a podu vám umožní řídit, do kterého uzlu bude pod nasazen. Poskvrny mohou zabránit rozmístění modulů do konkrétních uzlů, aniž by došlo ke změně stávajících modulů. Pody, které chcete nasadit na poškozený uzel, se musí přihlásit k používání tohoto uzlu.
- Poskvrny – Zabraňte plánování nových podů v uzlech, definujte předvolby uzlů a odeberte stávající pody z uzlu.
- Tolerance – Povolit plánování podů pouze na uzlech s existujícími a odpovídajícími závadami.
Poskvrny a tolerance poskytují optimální výsledky, když se používají společně, aby bylo zajištěno, že se lusky dostanou do příslušných uzlů.
Skupinové zdroje s jmennými prostory
Použijte jmenné prostory Kubernetes k rozdělení velkých clusterů na menší, snadno identifikovatelné skupiny. Jmenné prostory vám umožňují vytvářet samostatná testovací, QA, produkční nebo vývojová prostředí a alokovat adekvátní zdroje v rámci jedinečného jmenného prostoru. Názvy zdrojů Kubernetes musí být jedinečné pouze v rámci jednoho jmenného prostoru. Různé jmenné prostory mohou mít zdroje se stejným názvem.
Pokud má více uživatelů přístup ke stejnému clusteru, můžete omezit uživatele a povolit jim jednat v rámci konkrétního jmenného prostoru. Oddělení uživatelů je skvělý způsob, jak oddělit zdroje a vyhnout se potenciálnímu konfliktu názvů nebo verzí.
Jmenné prostory jsou prostředky Kubernetes a lze je výjimečně snadno vytvořit. Vytvořte soubor YAML definující název oboru názvů a použijte kubectl k jeho odeslání na server Kubernetes API. Následně můžete jmenný prostor použít ke správě nasazení dalších zdrojů.