Chcete-li používat Linux k poskytování služeb podnikům, musí být tyto služby bezpečné, odolné a škálovatelné. Pěkná slova, ale co máme na mysli?
‘Zajistit’ znamená, že uživatelé mají přístup k požadovaným datům, ať už jde o přístup pouze pro čtení nebo zápis. Zároveň žádná data nejsou vystavena žádné straně’to není oprávněno to vidět. Zabezpečení je klamné: můžete si myslet, že máte vše chráněné, abyste později zjistili, že existují díry. Navrhování zabezpečení od začátku projektu je mnohem snazší, než se pokusit jej později vybavit.
‘Pružný’ znamená, že vaše služby tolerují poruchy v rámci infrastruktury. Selhání může být serverový diskový řadič, který již nemůže přistupovat na žádné disky, což činí data nedostupnými. Nebo selhání může být síťový přepínač, který již neumožňuje komunikaci dvou nebo více systémů. V této souvislosti “jediný bod selhání” nebo SPOF je porucha, která nepříznivě ovlivňuje dostupnost služby. Odolná infrastruktura je infrastruktura bez SPOF.
‘Škálovatelné’ popisuje schopnost systémů zvládnout prudce poptávky. Také určuje, jak snadno lze provést změny v systémech. Například přidání nového uživatele, zvýšení úložné kapacity nebo přesun infrastruktury z Amazon Web Services do Google Cloud – nebo dokonce přesunutí interně.
Jakmile se vaše infrastruktura rozšíří za jeden server, existuje spousta možností pro zvýšení zabezpečení, odolnosti a škálovatelnosti. My’Podívám se na to, jak byly tyto problémy tradičně řešeny a jaká nová technologie je k dispozici, která mění tvář velkých aplikačních počítačů.
Pochopit co’je to dnes možné’Je užitečné podívat se na to, jak byly technologické projekty tradičně implementovány. V dávných dobách – tedy před více než 10 lety – by podniky nakupovaly nebo pronajímaly hardware, aby mohly provozovat všechny komponenty svých aplikací. I relativně jednoduché aplikace, jako je web WordPress, mají více komponent. V případě WordPress je zapotřebí databáze MySQL spolu s webovým serverem, jako je Apache, a způsob manipulace s PHP kódem. Takže oni’d vytvořit server, nastavit Apache, PHP a MySQL, nainstalovat WordPress a vypnout je’d jít.
Celkově to fungovalo. Fungovalo to dost dobře, že v dnešní době je stále přesně takto nakonfigurováno velké množství serverů. Ale nebylo to’Dokonalý a dva z větších problémů byly odolnost a škálovatelnost.
Nedostatek odolnosti znamenal, že jakýkoli významný problém na serveru by měl za následek ztrátu služby. Katastrofické selhání by očividně znamenalo, že nebude existovat žádný web, ale nebyl zde ani žádný prostor pro provádění plánované údržby, aniž by to mělo dopad na web. Dokonce i instalace a aktivace rutinní aktualizace zabezpečení pro Apache by vyžadovala několik sekund’ výpadek pro web.
Problém odolnosti byl do značné míry vyřešen stavbou ‘klastry s vysokou dostupností’. Zásadou bylo mít dva servery provozující web, nakonfigurované tak, že selhání jednoho z nich nevedlo’Výsledkem je, že web je mimo provoz. Poskytovaná služba byla odolná, i když jednotlivé servery nebyly.
Abstraktní mraky
Součástí síly Kubernetes je abstrakce, kterou nabízí. Od vývojáře’s perspektivou, vyvíjejí aplikaci pro běh v kontejneru Docker. Docker ne’nestarám se o to’běží na Windows, Linuxu nebo jiném operačním systému. Stejný kontejner Docker lze odebrat od vývojáře’s MacBook a běží pod Kubernetes bez jakýchkoli úprav.
Samotná instalace Kubernetes může být jediným strojem. Samozřejmě, mnoho výhod Kubernetes zvítězilo’• být k dispozici: nedojde k automatickému změně měřítka; tam’je to zjevný jediný bod selhání, atd. Jako důkaz konceptu v testovacím prostředí však funguje.
Jednou’Jakmile budete připraveni na výrobu, můžete provozovat interně nebo u poskytovatele cloudu, jako je AWS nebo Google Cloud. Poskytovatelé cloudu mají některé vestavěné služby, které pomáhají při provozu Kubernetes, ale žádné z nich nejsou přísné požadavky. Pokud se chcete pohybovat mezi Google, Amazonem a vlastní infrastrukturou, nastavíte Kubernetes a přesunete se. Žádná z vašich aplikací se nesmí nijak měnit.
A kde je Linux? Kubernetes běží na Linuxu, ale operační systém je pro aplikace neviditelný. Jedná se o významný krok ve zralosti a použitelnosti IT infrastruktur.
Efekt Slashdot
Problém škálovatelnosti je o něco složitější. Nechat’Řekněme, že váš web WordPress dostává 1 000 návštěvníků měsíčně. Jednoho dne bude vaše firma uvedena v rádiu 4 nebo v televizi se snídaní. Najednou dostanete více než měsíc’to stojí za 20 minut. My’všichni slyšeli příběhy webových stránek ‘shazovat’, a to’Typicky proč: nedostatek škálovatelnosti.
Dva servery, které pomáhaly s odolností, mohly zvládnout vyšší pracovní vytížení, než jen jeden server, ale to’je stále omezený. Vy’d platit za dva servery 100 procent času a většinu času oba fungovaly perfektně. To’Je pravděpodobné, že váš web by mohl provozovat sám. Pak John Humphrys zmíní vaše podnikání na Dnes a vy’d Na zvládnutí zátěže je potřeba 10 serverů – ale pouze na několik hodin.
Lepším řešením problému odolnosti a škálovatelnosti bylo cloud computing. Nastavte instanci serveru nebo dva – malé servery, které spouštějí vaše aplikace – na Amazon Web Services (AWS) nebo Google Cloud, a pokud některá z instancí selhala z nějakého důvodu, automaticky by se restartovala. Nastavte automatické škálování správně a když pan Humphrys způsobí, že se pracovní zátěž na instancích webového serveru rychle zvýší, automaticky se začnou sdílet další instance serveru. Později, jak úrok klesá, jsou tyto další instance zastaveny a platíte pouze za to, co používáte. Perfektní… nebo je to?
Přestože je cloudové řešení mnohem flexibilnější než tradiční samostatný server, stále existují problémy. Aktualizace všech běžících instancí cloudu není’přímočaré. Vývoj pro cloud má také výzvy: laptop, který vývojáři používají, se může podobat cloudové instanci, ale je to tak’není to stejné. Zavazujete-li se k AWS, je přechod na Google Cloud složitý úkol. A předpokládejme, že z jakéhokoli důvodu prostě ne’Nechcete předávat výpočetní prostředky Amazonu, Google nebo Microsoft?
Kontejnery se objevily jako prostředek k zabalení aplikací se všemi jejich závislostmi do jediného balíčku, který lze spustit kdekoli. Kontejnery, například Docker, mohou běžet na vašich vývojářích’ notebooky stejným způsobem, jakým běží na cloudových instancích, ale správa flotily kontejnerů se s rostoucím počtem kontejnerů stává stále náročnější.
Odpověď je kontejnerová orchestrace. Toto je významný posun v zaměření. Předtím jsme se ujistili, že máme dostatek serverů, ať už fyzických nebo virtuálních, abychom zajistili, že můžeme vyřídit pracovní vytížení. Použití poskytovatelů cloudu’ automatické přizpůsobování pomohlo, ale stále jsme se zabývali případy. Museli jsme nakonfigurovat vyvažovače zatížení, brány firewall, ukládání dat a více ručně. Díky kontejnerové orchestraci se o to vše (a mnohem více) postará. Upřesňujeme výsledky, které požadujeme, a naše nástroje pro správu kontejnerů splňují naše požadavky. Upřesňujeme, co chceme udělat, spíše než to, jak chceme.
Neustálá integrace a nepřetržité nasazení mohou s Kubernetes dobře fungovat. Tady’je přehled Jenkinsů používaných k vytváření a nasazení aplikace Java
(Obrazový kredit: Budoucnost)
Staňte se Kubernete
Kubernetes (ku-ber-net-eez) je dnes hlavním nástrojem pro správu kontejnerů a pochází od Googlu. Pokud někdo ví, jak provozovat rozsáhlé IT infrastruktury, Google to dělá. Původ Kubernetes je Borg, interní projekt Google, který’Používá se stále k běhu většiny Googlu’s aplikacemi včetně vyhledávače, Gmailu, Mapy Google a dalších. Borg byl tajemstvím, dokud Google o něm v roce 2015 nezveřejnil článek, ale tento dokument jasně ukázal, že Borg byl hlavní inspirací za Kubernetesem.
Borg je systém, který spravuje výpočetní zdroje v Googlu’s datových center a udržuje Google’■ Aplikace, produkční i jiné, běžící i přes selhání hardwaru, vyčerpání zdrojů nebo jiné problémy, které by jinak mohly způsobit výpadek. Děje se to pečlivým sledováním tisíců uzlů, které tvoří Borg “buňka” a nádoby, které na ně běží, a spouštění nebo zastavování kontejnerů podle potřeby v reakci na problémy nebo kolísání nákladu.
Samotný Kubernetes se narodil z Googlu’s GIFEE (‘Google’s Infrastruktura pro všechny ostatní’) a byla navržena jako přátelská verze Borg, která by mohla být užitečná mimo společnost Google. Byl darován Linuxové nadaci v roce 2015 vytvořením Cloud Native Computing Foundation (CNCF).
Kubernetes poskytuje systém, kterým vy “prohlásit” vaše aplikace a služby zabalené v kontejnerech a zajišťuje, že aplikace budou spuštěny v souladu s těmito prohlášeními. Pokud vaše programy vyžadují externí zdroje, jako jsou vyrovnávače úložiště nebo načítání, může je Kubernetes poskytnout automaticky. Může škálovat aplikace nahoru nebo dolů, aby udržel krok se změnami v zatížení, a dokonce může škálovat celý svůj cluster, pokud je to potřeba. Váš program’s komponenty don’Nepotřebujete ani vědět, kde jsou’re running: Kubernetes poskytuje interní jmenovací služby aplikacím, aby se k nim mohly připojit “wp_mysql” a být automaticky připojeni ke správnému zdroji.’
Konečným výsledkem je platforma, kterou lze použít ke spuštění vašich aplikací na jakékoli infrastruktuře, od jednoho počítače přes on-premise stojan systémů až po cloudové flotily virtuálních strojů běžících u jakéhokoli významného poskytovatele cloudu, všechny využívající stejné kontejnery a konfigurace. Kubernetes je poskytovatelem agnostický: spusťte ho kamkoli chcete.
Kubernetes je výkonný nástroj a je nutně složitý. Než se dostaneme do přehledu, musíme zavést některé pojmy používané v Kubernetes. Kontejnery spouští jednotlivé aplikace, jak je uvedeno výše, a jsou seskupeny do lusků. Pod je skupina úzce propojených kontejnerů, které jsou rozmístěny společně na stejném hostiteli a sdílejí některé zdroje. Kontejnery v lusku fungují jako tým: oni’Provedu související funkce, jako je kontejner aplikace a kontejner protokolování se specifickými nastaveními pro aplikaci.
Přehled Kubernetes ukazující hlavní běží klíčové komponenty a dva uzly. Všimněte si, že v praxi mohou být hlavní komponenty rozděleny do více systémů
(Obrazový kredit: Budoucnost)
Čtyři klíčové komponenty Kubernetes jsou API Server, Plánovač, Správce řadičů a distribuovaná konfigurační databáze s názvem etcd. Server API je jádrem společnosti Kubernetes a funguje jako primární koncový bod pro všechny požadavky na správu. Ty mohou být generovány řadou zdrojů včetně dalších komponent Kubernetes, jako je plánovač, administrátoři prostřednictvím příkazových řádků nebo webových dashboardů, a samotné aplikace pro kontejnerizaci. Ověřuje požadavky a aktualizuje data uložená v etcd.
Plánovač určuje, na kterých uzlech budou různé pody běžet, s přihlédnutím k omezením, jako jsou požadavky na zdroje, omezení hardwaru nebo softwaru, pracovní vytížení, termíny a další.
Správce řadičů monitoruje stav klastru a pokusí se podle potřeby prostřednictvím serveru API spustit nebo zastavit moduly, aby klastr uvedl do požadovaného stavu. Spravuje také některé interní připojení a funkce zabezpečení.
Každý uzel provozuje proces Kubelet, který komunikuje se serverem API a spravuje kontejnery – obvykle pomocí Docker – a Kube-Proxy, které zpracovávají síťové proxy a vyrovnávání zatížení v rámci clusteru.
Distribuovaný databázový systém etcd odvozuje své jméno z /atd složka v systémech Linux, která se používá k uchovávání informací o konfiguraci systému, plus přípona ‘d’, Často se používá k označení procesu démona. Cílem etcd je ukládat data klíč-hodnota distribuovaným, konzistentním a odolným vůči chybám.
Server API uchovává všechna svá data v etcd a může spouštět mnoho instancí současně. Správce plánovače a řadiče může mít pouze jednu aktivní instanci, ale používá nájemní systém k určení, která spuštěná instance je hlavní. To vše znamená, že Kubernetes může běžet jako vysoce dostupný systém bez jediného bodu selhání.
Dává to všechno dohromady
Jak tedy tyto komponenty používáme v praxi? Následuje příklad nastavení webu WordPress pomocí aplikace Kubernetes. Pokud jste to chtěli dělat opravdu, pak vy’d pravděpodobně použít předdefinovaný recept nazvaný graf kormidla. Jsou k dispozici pro řadu běžných aplikací, ale zde jsme’Podívám se na některé z kroků nezbytných k tomu, aby byl web WordPress zprovozněn a spuštěn na Kubernetes.
Prvním úkolem je definovat heslo pro MySQL:
kubectl vytvořit tajné generické mysql-pass – from-literal = password = YOUR_PASSWORD
kubectl bude hovořit s API serverem, který příkaz potvrdí a poté heslo uloží do etcd. Naše služby jsou definovány v souborech YAML a nyní potřebujeme určité trvalé úložiště pro databázi MySQL.
apiVersion: v1kind: PersistentVolumeClaimmetadata: jméno: mysql-pv-nárokové označení: aplikace: wordpressspec: accessModes: – ReadWriteOnceresources: požadavky: storage: 20Gi
Specifikace by měla být většinou samovysvětlující. Pole jména a štítky se používají k označení tohoto úložiště z jiných částí Kubernetes, v tomto případě z našeho kontejneru WordPress.
Jednou jsme’Když jsme definovali úložiště, můžeme definovat instanci MySQL a ukázat ji na předdefinované úložiště. Že’s následuje definování samotné databáze. Dáváme této databázi název a štítek pro snadnou orientaci v Kubernetes.
Nyní potřebujeme další kontejner ke spuštění WordPress. Součástí specifikace nasazení kontejneru je:
druh: Deploymentmetadata: name: wordpresslabels: app: wordpressspec: strategy: type: Recreate
Typ strategie “Znovu vytvořit” znamená, že pokud se kterýkoli z kódů obsahujících aplikaci změní, budou spuštěné instance odstraněny a znovu vytvořeny. Mezi další možnosti patří možnost cyklizovat nové instance a odstraňovat existující instance, jedna po druhé, což umožňuje, aby služba pokračovala v běhu během nasazení aktualizace. Nakonec deklarujeme službu pro samotný WordPress, která obsahuje PHP kód a Apache. Součástí souboru YAML je prohlášení:
metadata: jméno: wordpresslabels: app: wordpressspec: porty: – port: 80selector: app: wordpresstier: frontendtype: LoadBalancer
Poznamenejte si poslední řádek, definující typ služby jako LoadBalancer. To instruuje Kubernetes, aby tuto službu zpřístupnil mimo Kubernetes. Bez této linie by to bylo pouze vnitřní “Pouze Kubernetes” služba. A to’je to. Kubernetes nyní použije tyto soubory YAML jako prohlášení o tom, co je požadováno, a podle potřeby nastaví moduly, připojení, úložiště atd., Aby se cluster dostal do “žádoucí” Stát.
Pomocí zobrazení na ovládacím panelu získáte stručný přehled Kubernetes v akci
(Obrazový kredit: Příkop)
To byl nutně pouze přehled na vysoké úrovni o Kubernetesovi a mnoho detailů a vlastností systému bylo vynecháno. My’Vymazali jsme se v automatickém měřítku (pody i uzly, které tvoří klastr), cronové úlohy (spouštění kontejnerů podle plánu), Ingress (vyrovnávání zatížení HTTP, přepisování a vykládání SSL), RBAC (řízení přístupu na základě rolí), síť politiky (firewalling) a mnoho dalšího. Kubernetes je extrémně flexibilní a extrémně výkonný: pro každou novou IT infrastrukturu musí být vážným uchazečem.
Zdroje
jestli ty’Neznámé s Dockerem začněte zde: https://docs.docker.com/get-started.
Tam’s interaktivní výukový program nasazení a škálování aplikace zde: https://kubernetes.io/docs/tutorials/kubernetes-basics.
A jak https://kubernetes.io/docs/setup/scratch zjistit, jak vytvořit klastr.
Můžete hrát s klastrem Kubernetes zdarma na https://tryk8s.com.
Konečně můžete pórovat přes dlouhý, technický papír s vynikajícím přehledem o Googlu’s využitím Borg a jak to ovlivnilo design Kubernetes zde: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.
Zjistěte více o Tiger Computing.
- Nejlepší cloudové úložiště 2019 online: bezplatné, placené a obchodní možnosti
