Docker Swarm, Kubernetes и Mesos са най-популярните рамки за оркестриране на контейнери. В своята реч Арун Гупта сравнява следните аспекти на Docker, Swarm и Kubernetes:
- Местно развитие.
- Функции за разгръщане.
- Мултиконтейнерни приложения.
- Откриване на услуга.
- Мащабиране на услугата.
- Задачи за еднократно изпълнение.
- Интеграция с Maven.
- "Подвижна" актуализация.
- Създаване на клъстер от база данни Couchbase.
В резултат на това ще придобиете ясно разбиране какво може да предложи всеки инструмент за оркестрация и ще научите как да използвате тези платформи ефективно.
Арун Гупта е главен технолог за продукти с отворен код в Amazon Web Services, който разработва общностите за разработчици на Sun, Oracle, Red Hat и Couchbase повече от 10 години. Има богат опит в ръководенето на многофункционални екипи, разработващи и внедряващи стратегии за маркетингови кампании и програми. Ръководи екипи от инженери на Sun, един от основателите на екипа Java EE и създател на американския клон на Devoxx4Kids. Арун Гупта е автор на повече от 2 хиляди публикации в ИТ блогове и е изнасял лекции в повече от 40 страни.
Ред 55 съдържа COUCHBASE_URI, сочещ към тази услуга за база данни, която също е създадена с помощта на конфигурационния файл на Kubernetes. Ако погледнете ред 2, можете да видите вид: Service е услугата, която създавам, наречена couchbase-service, и същото име е посочено на ред 4. По-долу са някои портове.
Ключовите редове са 6 и 7. В услугата казвам: „Хей, това са етикетите, които търся!“ и тези етикети не са нищо повече от имена на двойки променливи, а ред 7 сочи към моя couchbase-rs-pod приложение. По-долу са портовете, които осигуряват достъп до същите тези етикети.
На ред 19 създавам нов тип ReplicaSet, ред 31 съдържа името на изображението, а редове 24-27 сочат към метаданните, свързани с моя под. Това е точно това, което услугата търси и към което трябва да се направи връзка. В края на файла има някаква връзка между редове 55-56 и 4, казвайки: „използвайте тази услуга!“
И така, стартирам услугата си, когато има набор от реплики и тъй като всеки набор от реплики има свой собствен порт със съответния етикет, той е включен в услугата. От гледна точка на разработчика, вие просто се обаждате на услугата, която след това използва набора от реплики, от които се нуждаете.
В резултат на това имам WildFly pod, който комуникира с бекенда на базата данни чрез услугата Couchbase. Мога да използвам интерфейса с няколко WildFly pods, които също комуникират с бекенда на couchbase чрез услугата couchbase.
По-късно ще разгледаме как услуга, разположена извън клъстера, комуникира чрез своя IP адрес с елементи, които се намират вътре в клъстера и имат вътрешен IP адрес.
И така, контейнерите без състояние са страхотни, но колко добре е да се използват контейнери без състояние? Нека да разгледаме системните настройки за състояние или постоянни контейнери. В Docker има 4 различни подхода към оформлението на съхранението на данни, на които трябва да обърнете внимание. Първият е Implicit Per-Container, което означава, че когато използвате couchbase, MySQL или MyDB satateful контейнери, всички те започват с Sandbox по подразбиране. Тоест всичко, което се съхранява в базата данни, се съхранява в самия контейнер. Ако контейнерът изчезне, данните изчезват заедно с него.
Вторият е Explicit Per-Container, когато създавате конкретно хранилище с командата за създаване на обем на docker и съхранявате данни в него. Третият подход на хост е свързан с картографиране на съхранение, когато всичко, съхранено в контейнера, се дублира едновременно на хоста. Ако контейнерът се повреди, данните ще останат на хоста. Последното е използването на няколко Multi-Host хоста, което е препоръчително на етапа на производство на различни решения. Да приемем, че вашите контейнери с вашите приложения се изпълняват на хоста, но искате да съхранявате данните си някъде в Интернет и за това използвате автоматично картографиране за разпределени системи.
Всеки от тези методи използва конкретно място за съхранение. Неявните и явните контейнери съхраняват данни на хоста в /var/lib/docker/volumes. Когато използвате метода Per-Host, хранилището се монтира вътре в контейнера, а самият контейнер се монтира на хоста. За мултихостове могат да се използват решения като Ceph, ClusterFS, NFS и др.
Ако постоянен контейнер се повреди, директорията за съхранение става недостъпна в първите два случая, но в последните два случая достъпът се запазва. В първия случай обаче можете да получите достъп до хранилището чрез Docker хост, работещ на виртуална машина. Във втория случай данните също няма да бъдат загубени, защото сте създали явно хранилище.
Ако хостът се повреди, директорията за съхранение е недостъпна в първите три случая; в последния случай връзката с хранилището не се прекъсва. И накрая, споделената функция е напълно изключена за съхранение в първия случай и е възможна в останалите. Във втория случай можете да споделяте хранилище в зависимост от това дали вашата база данни поддържа разпределено съхранение или не. В случай на Per-Host разпространението на данни е възможно само на даден хост, а за мултихост се осигурява чрез разширяване на клъстера.
Това трябва да се вземе предвид при създаването на контейнери със състояние. Друг полезен инструмент на Docker е плъгинът Volume, който работи на принципа „има батерии, но трябва да се сменят“. Когато стартирате Docker контейнер, той казва: „Хей, след като стартирате контейнер с база данни, можете да съхранявате данните си в този контейнер!“ Това е функцията по подразбиране, но можете да я промените. Този плъгин ви позволява да използвате мрежово устройство или нещо подобно вместо контейнерна база данни. Той включва драйвер по подразбиране за базирано на хост съхранение и позволява интегриране на контейнери с външни системи за съхранение като Amazon EBS, Azure Storage и GCE Persistent disks.
Следващият слайд показва архитектурата на плъгина Docker Volume.
Синият цвят представлява клиента на Docker, свързан със синия хост на Docker, който има механизъм за локално съхранение, който ви предоставя контейнери за съхранение на данни. Зеленото показва Plugin Client и Plugin Daemon, които също са свързани към хоста. Те предоставят възможност за съхраняване на данни в мрежово хранилище от типа Storage Backend, от който се нуждаете.
Плъгинът Docker Volume може да се използва с хранилището на Portworx. Модулът PX-Dev всъщност е контейнер, който управлявате, който се свързва с вашия хост Docker и ви позволява лесно да съхранявате данни в Amazon EBS.
Клиентът Portworx ви позволява да наблюдавате състоянието на различни контейнери за съхранение, които са свързани към вашия хост. Ако посетите моя блог, можете да прочетете как да се възползвате максимално от Portworx с Docker.
Концепцията за съхранение в Kubernetes е подобна на Docker и е представена от директории, които са достъпни за вашия контейнер в под. Те са независими от живота на всеки контейнер. Най-често срещаните налични типове съхранение са hostPath, nfs, awsElasticBlockStore и gsePersistentDisk. Нека да разгледаме как работят тези магазини в Kubernetes. Обикновено процесът на свързването им се състои от 3 стъпки.
Първият е, че някой от страната на мрежата, обикновено администратор, ви предоставя постоянно хранилище. За това има съответен конфигурационен файл PersistentVolume. След това разработчикът на приложението пише конфигурационен файл, наречен PersistentVolumeClaim или заявка за PVC съхранение, която казва: „Имам осигурено 50 GB разпределено хранилище, но за да могат други хора също да използват неговия капацитет, казвам на този PVC, че в момента трябват само 10 GB". И накрая, третата стъпка е, че вашата заявка се монтира като хранилище и приложението, което има под или набор от реплики, или нещо подобно, започва да го използва. Важно е да запомните, че този процес се състои от 3-те споменати стъпки и е мащабируем.
Следващият слайд показва контейнера за устойчивост на Kubernetes на архитектурата на AWS.
Вътре в кафявия правоъгълник, който представлява клъстера на Kubernetes, има един главен възел и два работни възела, обозначени в жълто. Един от работните възли съдържа оранжева капсула, хранилище, реплика на контролер и зелен контейнер Docker Couchbase. Вътре в клъстера, над възлите, лилав правоъгълник показва услугата, достъпна отвън. Тази архитектура се препоръчва за съхраняване на данни на самото устройство. Ако е необходимо, мога да съхранявам данните си в EBS извън клъстера, както е показано на следващия слайд. Това е типичен модел за мащабиране, но има финансов аспект, който трябва да се вземе предвид при използването му - съхраняването на данни някъде в мрежата може да бъде по-скъпо, отколкото на хост. При избора на решения за контейнеризация това е един от сериозните аргументи.
Точно както с Docker, можете да използвате постоянни контейнери Kubernetes с Portworx.
Това е, което в текущата терминология на Kubernetes 1.6 се нарича „StatefulSet“ – начин на работа с Stateful приложения, който обработва събития за спиране на Pod и извършване на Graceful Shutdown. В нашия случай такива приложения са бази данни. В моя блог можете да прочетете как да създадете StatefulSet в Kubernetes с помощта на Portworx.
Нека поговорим за аспекта на развитието. Както казах Docker има 2 версии - CE и EE, като в първия случай говорим за стабилна версия на Community Edition, която се актуализира веднъж на 3 месеца, за разлика от месечната версия на EE. Можете да изтеглите Docker за Mac, Linux или Windows. Веднъж инсталиран, Docker ще се актуализира автоматично и е много лесно да започнете.
За Kubernetes предпочитам версията Minikube - това е добър начин да започнете с платформата, като създадете клъстер на един възел. За да създадете клъстери от няколко възли, изборът на версии е по-широк: това са kops, kube-aws (CoreOS+AWS), kube-up (остарял). Ако искате да използвате Kubernetes, базиран на AWS, препоръчвам да се присъедините към AWS SIG, който се събира онлайн всеки петък и публикува различни интересни материали за работа с AWS Kubernetes.
Нека да разгледаме как се извършва Rolling Update на тези платформи. Ако има клъстер от няколко възела, той използва конкретна версия на изображението, например WildFly:1. Постепенна актуализация означава, че версията на изображението се заменя последователно с нова на всеки възел, един след друг.
За да направя това, използвам командата docker service update (service name), в която посочвам новата версия на изображението WildFly:2 и метода за актуализиране update-parallelism 2. Числото 2 означава, че системата ще актуализира 2 изображения на приложения в същото време, след това 10-секундно забавяне на актуализацията 10s, след което следващите 2 изображения ще бъдат актуализирани на още 2 възела и т.н. Този прост механизъм за непрекъснато актуализиране ви се предоставя като част от Docker.
В Kubernetes непрекъснатата актуализация работи по следния начин. Контролерът за репликация rc създава набор от реплики на една и съща версия и всеки pod в този webapp-rc е снабден с етикет, разположен в etcd. Когато имам нужда от под, използвам услугата за приложения за достъп до хранилището на etcd, което ми предоставя под, използвайки посочения етикет.
В този случай имаме 3 подове в контролера за репликация, изпълняващи приложението WildFly версия 1. При актуализиране във фонов режим се създава друг контролер за репликация със същото име и индекс в края - - xxxxx, където x са произволни числа и със същите етикети. Сега услугата за приложения има три пакета със старата версия на приложението и три пакета с новата версия в новия контролер за репликация. След това старите подове се изтриват, репликационният контролер с новите подове се преименува и се пуска в експлоатация.
Да преминем към мониторинга. Docker има много вградени команди за наблюдение. Например интерфейсът на командния ред на docker container stats ви позволява да показвате информация за състоянието на контейнерите на конзолата всяка секунда - използване на процесора, използване на диска, натоварване на мрежата. Инструментът Docker Remote API предоставя данни за това как клиентът комуникира със сървъра. Той използва прости команди, но е базиран на Docker REST API. В този случай думите REST, Flash, Remote означават едно и също нещо. Когато комуникирате с хоста, това е REST API. API на Docker Remote ви позволява да получите повече информация за работещите контейнери. Моят блог очертава подробностите за използването на това наблюдение с Windows Server.
Мониторингът на събитията на докер системата при изпълнение на клъстер с множество хостове прави възможно получаването на данни за срив на хост или срив на контейнер на конкретен хост, услуги за мащабиране и други подобни. Започвайки с Docker 1.20, той включва Prometheus, който вгражда крайни точки в съществуващи приложения. Това ви позволява да получавате показатели чрез HTTP и да ги показвате на таблата за управление.
Друга функция за наблюдение е cAdvisor (съкратено от контейнерен съветник). Той анализира и предоставя данни за използване на ресурси и производителност от работещи контейнери, предоставяйки показатели на Prometheus веднага след изваждането от кутията. Особеното при този инструмент е, че предоставя данни само за последните 60 секунди. Следователно трябва да можете да събирате тези данни и да ги поставяте в база данни, за да можете да наблюдавате дългосрочен процес. Може да се използва и за графично показване на показателите на таблото с помощта на Grafana или Kibana. Моят блог има подробно описание как да използвате cAdvisor за наблюдение на контейнери с помощта на таблото за управление на Kibana.
Следващият слайд показва как изглежда крайният изход на Prometheus и наличните показатели за показване.
Долу вляво виждате метрики за HTTP заявки, отговори и т.н., вдясно е тяхното графично изобразяване.
Kubernetes също включва вградени инструменти за наблюдение. Този слайд показва типичен клъстер, съдържащ един главен и три работни възела.
Всеки от работещите възли съдържа автоматично стартиран cAdvisor. Освен това има Heapster, система за наблюдение на производителността и събиране на показатели, съвместима с Kubernetes версия 1.0.6 и по-нова. Heapster ви позволява да събирате не само показатели за ефективност на работни натоварвания, подове и контейнери, но и събития и други сигнали, генерирани от целия клъстер. За да събира данни, той говори с Kubelet на всеки pod, автоматично съхранява информацията в базата данни InfluxDB и я извежда като показатели към таблото за управление на Grafana. Имайте предвид обаче, че ако използвате miniKube, тази функция не е налична по подразбиране, така че ще трябва да използвате добавки за наблюдение. Така че всичко зависи от това къде стартирате контейнерите и кои инструменти за наблюдение можете да използвате по подразбиране и кои трябва да инсталирате като отделни добавки.
Следващият слайд показва таблата за управление на Grafana, които показват текущия статус на моите контейнери. Тук има доста интересни данни. Разбира се, има много комерсиални инструменти за наблюдение на процесите на Docker и Kubernetes, като SysDig, DataDog, NewRelic. Някои от тях имат 30-годишен безплатен пробен период, така че можете да опитате и да намерите този, който ви подхожда най-добре. Лично аз предпочитам да използвам SysDig и NewRelic, които се интегрират добре с Kubernetes. Има инструменти, които се интегрират еднакво добре както в платформите Docker, така и в Kubernetes.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com