Коли ви хочете використовувати Linux для надання послуг бізнесу, ці послуги повинні бути безпечними, стійкими та масштабованими. Приємні слова, але що ми маємо на увазі під ними?
"Безпечний" означає, що користувачі можуть отримати доступ до даних, які їм потрібні, будь то доступ лише для читання або доступ до запису. У той же час жодні дані не передаються стороні, яка не має повноважень їх бачити. Безпека оманлива: ви можете подумати, що у вас все захищене, щоб пізніше з’ясувати, що там дірки. Проектувати безпеку з самого початку проекту набагато простіше, ніж намагатися модернізувати його пізніше.
"Еластичний" означає, що ваші служби терплять збої в інфраструктурі. Помилка може бути контролером дискового сервера, який більше не може отримати доступ до будь-яких дисків, що робить дані недоступними. Або збій може бути мережевим комутатором, який більше не дозволяє комунікаціям двох або більше систем. У цьому контексті “одна точка відмови” або SPOF - це відмова, яка негативно впливає на доступність послуги. Еластична інфраструктура - це інфраструктура без SPOF.
„Масштабована” описує здатність систем витончено обробляти стрибки попиту. Це також визначає, наскільки легко можна внести зміни в системи. Наприклад, додавання нового користувача, збільшення обсягу пам’яті або переміщення інфраструктури з веб-служб Amazon до Google Cloud - або навіть переміщення її власним способом.
Як тільки ваша інфраструктура розширюється за межі одного сервера, існує безліч варіантів підвищення безпеки, стійкості та масштабованості. Ми розглянемо, як ці проблеми традиційно вирішувались, і які нові технології доступні, що змінює обличчя обчислень великих додатків.
Отримайте більше Linux!Вам подобається те, що ви читаєте? Хочете більше Linux та відкритого коду? Ми можемо доставити буквально! Підпишіться на формат Linux сьогодні за вигідною ціною. Ви можете отримати друковані видання, цифрові видання чи чому не обидва? Ми доставляємо до ваших дверей по всьому світу за просту річну плату. Тож зробіть своє життя кращим та легшим, підпишіться зараз!
Щоб зрозуміти, що можливо сьогодні, корисно поглянути на те, як традиційно впроваджуються технологічні проекти. Ще за старих часів - тобто більше 10 років тому - підприємства купували або здавали в оренду обладнання для запуску всіх компонентів своїх програм. Навіть порівняно прості програми, такі як веб-сайт WordPress, мають кілька компонентів. У випадку з WordPress потрібна база даних MySQL, а також веб-сервер, такий як Apache, і спосіб обробки PHP-коду. Отже, вони побудують сервер, налаштують Apache, PHP та MySQL, встановлять WordPress і підуть.
За великим рахунком, це спрацювало. Це спрацювало досить добре, що сьогодні все ще існує величезна кількість серверів, налаштованих саме таким чином. Але це не було ідеально, і двома найбільшими проблемами були стійкість та масштабованість.
Відсутність стійкості означало, що будь-яка суттєва проблема на сервері призведе до втрати служби. Очевидно, що катастрофічний збій означав би відсутність веб-сайту, але також не було місця для проведення планового технічного обслуговування, не впливаючи на веб-сайт. Навіть встановлення та активація рутинного оновлення безпеки для Apache потребуватиме відключення веб-сайту за кілька секунд.
Проблема стійкості в основному була вирішена шляхом створення "кластерів високої доступності". Принцип полягав у тому, щоб на веб-сайті працювало два сервери, налаштовані таким чином, що збій жодного з них не призвів до того, що веб-сайт не працював. Надана послуга була стійкою, навіть якщо окремі сервери не були такими.
Анотація хмариЧастина сили Кубернетеса - це абстракція, яку він пропонує. З точки зору розробника, вони розробляють додаток для запуску в контейнері Docker. Docker байдуже, працює він у Windows, Linux чи якійсь іншій операційній системі. Цей самий контейнер Docker можна взяти з MacBook розробника та запускати під керуванням Kubernetes без будь-яких змін.
Сама установка Kubernetes може бути однією машиною. Звичайно, багато переваг Kubernetes будуть недоступні: не буде автоматичного масштабування; є очевидний єдиний момент відмови тощо. Однак, як доказ концепції в тестовому середовищі, це працює.
Після того, як ви будете готові до виробництва, ви можете запустити власну програму або на постачальника хмарних послуг, наприклад AWS або Google Cloud. Провайдери хмарних технологій мають деякі вбудовані служби, які допомагають запустити Kubernetes, але жодне з них не є суворими вимогами. Якщо ви хочете перейти між Google, Amazon і власною інфраструктурою, ви налаштували Kubernetes і перейшли. Жодна з ваших програм не повинна будь-яким чином змінюватися.
А де Linux? Kubernetes працює на Linux, але операційна система невидима для додатків. Це важливий крок у зрілості та зручності використання ІТ-інфраструктур.
Ефект Slashdot
Проблема масштабованості дещо складніша. Скажімо, ваш сайт на WordPress отримує 1000 відвідувачів на місяць. Одного разу про вашу справу згадують на радіо 4 або на телевізорі для сніданків. Раптом за 20 хвилин відвідувачі відвідують більше ніж місяць. Ми всі чули історії про "збій" веб-сайтів, і саме тому: відсутність масштабованості.
Два сервери, які допомогли підвищити стійкість, могли б управляти більшим навантаженням, ніж один сервер, але це все ще обмежено. Ви б платили за два сервери 100 відсотків часу, і більшу частину часу обидва працювали бездоганно. Цілком ймовірно, що один може керувати вашим сайтом. Тоді Джон Хамфріс згадує про ваш бізнес сьогодні, і вам знадобиться 10 серверів для обробки навантаження, але лише на кілька годин.
Кращим рішенням проблеми стійкості та масштабованості були хмарні обчислення. Налаштуйте один-два екземпляри сервера - маленькі сервери, які запускають ваші програми - на Amazon Web Services (AWS) або Google Cloud, і якщо один із екземплярів не вдасться з якихось причин, його буде автоматично перезапущено. Правильно налаштуйте автоматичне масштабування, і коли пан Хамфріс спричинить швидке зростання навантаження на екземплярах вашого веб-сервера, додаткові екземпляри серверів автоматично запускаються для розподілу робочого навантаження. Пізніше, коли відсотки зменшуються, ці додаткові випадки припиняються, і ви платите лише за те, що використовуєте. Ідеально… чи це?
Хоча хмарне рішення набагато гнучкіше, ніж традиційний автономний сервер, все ще існують проблеми. Оновлення всіх запущених екземплярів хмари не є простим. Розробка для хмари теж має проблеми: ноутбук, яким користуються ваші розробники, може бути схожий на екземпляр хмари, але це не те саме. Якщо ви берете на себе зобов'язання щодо AWS, перехід на Google Cloud є складним завданням. І припустимо, з якоїсь причини ви просто не хочете передавати свої обчислення Amazon, Google або Microsoft?
Контейнери виникла як засіб для обгортання програм з усіма їх залежностями в єдиний пакет, який можна запускати де завгодно. Контейнери, такі як Docker, можуть працювати на ноутбуках розробників так само, як і на ваших екземплярах хмари, але управління парком контейнерів стає все більш складним завданням із збільшенням кількості контейнерів.
Відповідь - оркестрація контейнерів. Це значний зсув фокусу. Раніше ми переконувались, що у нас достатньо серверів, фізичних чи віртуальних, щоб ми могли обслуговувати навантаження. Використання автомасштабування хмарних провайдерів допомогло, але ми все ще мали справу з екземплярами. Нам довелося налаштовувати балансири навантаження, брандмауери, зберігання даних тощо. З оркестрацією контейнерів все це (і багато іншого) подбано. Ми вказуємо результати, які нам потрібні, і наші інструменти для організації контейнерів відповідають нашим вимогам. Ми вказуємо, що ми хочемо зробити, а не як ми хочемо це зробити.
Постійна інтеграція та постійне розгортання можуть добре працювати з Kubernetes. Ось огляд Дженкінса, який використовується для створення та розгортання програми JavaСтати Кубернете
Kubernetes (ku-ber-net-eez) на сьогодні є провідним інструментом організації контейнерів, і він надійшов від Google. Якщо хтось знає, як керувати величезними ІТ-інфраструктурами, Google це знає. Походження Kubernetes - Borg, внутрішній проект Google, який досі використовується для запуску більшості програм Google, включаючи пошукову систему, Gmail, Карти Google тощо. Борг був таємницею, поки Google не опублікував статтю про це в 2015 році, але з цієї статті було дуже очевидно, що Борг був головним натхненником Кубернетеса.
Borg - це система, яка керує обчислювальними ресурсами в центрах обробки даних Google і підтримує роботу додатків Google, як виробничих, так і інших, що працюють, незважаючи на збій обладнання, вичерпання ресурсів чи інші проблеми, що можуть призвести до відключення. Це робиться шляхом ретельного моніторингу тисяч вузлів, що складають «комірку» Борга, та запущених на них контейнерів, а також запуску або зупинки контейнерів, як це вимагається у відповідь на проблеми або коливання навантаження.
Сама Kubernetes народилася з ініціативи Google «Інфраструктура Google для всіх інших» від Google і була розроблена як більш дружня версія Borg, яка може бути корисною за межами Google. Він був переданий Фонду Linux у 2015 році шляхом створення Cloud Native Computing Foundation (CNCF).
Kubernetes пропонує систему, згідно з якою ви «заявляєте» про свої контейнерні програми та послуги, і забезпечує, щоб ваші програми працювали відповідно до цих декларацій. Якщо ваші програми вимагають зовнішніх ресурсів, таких як сховища чи балансири навантаження, Kubernetes може забезпечити їх автоматично. Він може масштабувати ваші програми вгору або вниз, щоб не відставати від змін навантаження, і навіть може масштабувати весь ваш кластер, коли це потрібно. Компонентам вашої програми навіть не потрібно знати, де вони працюють: Kubernetes надає послуги внутрішнього іменування додатків, щоб вони могли підключатися до "wp_mysql" і автоматично підключатися до правильного ресурсу. "
Кінцевим результатом є платформа, яка може використовуватися для запуску ваших додатків на будь-якій інфраструктурі, від однієї машини через локальний набір систем до хмарних парків віртуальних машин, що працюють на будь-якому великому хмарному провайдері, і всі використовують однакові контейнери та конфігурація. Kubernetes є агностиком провайдера: запускайте його де завгодно.
Kubernetes є потужним інструментом, і він обов'язково є складним. Перш ніж ми потрапляємо в огляд, нам потрібно представити деякі терміни, що використовуються в Кубернетесі. Контейнери запускають одиничні програми, як обговорювалося вище, і згруповані в під. Pod - це група тісно пов’язаних контейнерів, які розгортаються разом на одному хості та діляться деякими ресурсами. Контейнери, що перебувають у підсистемі, працюють командно: вони виконуватимуть відповідні функції, такі як контейнер програми та контейнер реєстрації, з певними налаштуваннями для програми.
Огляд Kubernetes, що показує майстер, що запускає ключові компоненти та два вузли. Зверніть увагу, що на практиці головні компоненти можуть бути розділені на кілька системЧотири ключові компоненти Kubernetes - це API-сервер, планувальник, диспетчер контролерів та розподілена база даних конфігурації з назвою etcd. Сервер API лежить в основі Kubernetes і діє як основна кінцева точка для всіх запитів управління. Вони можуть генеруватися з різних джерел, включаючи інші компоненти Kubernetes, такі як планувальник, адміністратори за допомогою командного рядка або веб-панелі інструментів, а також самі контейнерні програми. Він перевіряє запити та оновлює дані, що зберігаються в etcd.
Планувальник визначає, на яких вузлах будуть працювати різні підсистеми, беручи до уваги такі обмеження, як вимоги до ресурсів, будь-які обмеження на апаратне чи програмне забезпечення, робоче навантаження, терміни та багато іншого.
Диспетчер контролерів відстежує стан кластера і намагатиметься запускати або зупиняти підсистеми, як це необхідно, через сервер API, щоб привести кластер у бажаний стан. Він також управляє деякими внутрішніми зв’язками та функціями безпеки.
Кожен вузол запускає процес Kubelet, який взаємодіє з сервером API і управляє контейнерами - як правило, за допомогою Docker - та Kube-Proxy, який обробляє мережеве проксі і балансування навантаження всередині кластера.
Розподілена система баз даних etcd отримала свою назву від / тощо папка в системах Linux, яка використовується для зберігання інформації про конфігурацію системи, а також суфікс "d", який часто використовується для позначення процесу демона. Цілями etcd є зберігання даних ключ-значення розподіленим, послідовним та відмовостійким способом.
Сервер API зберігає всі свої дані про стан у etcd і може одночасно запускати багато екземплярів. Планувальник і менеджер контролера можуть мати лише один активний екземпляр, але використовує систему оренди, щоб визначити, який запущений екземпляр є головним. Все це означає, що Kubernetes може працювати як високодоступна система без єдиних точок відмови.
Склавши все це разом
То як ми можемо використовувати ці компоненти на практиці? Далі йде приклад налаштування веб-сайту WordPress за допомогою Kubernetes. Якщо ви хотіли б зробити це по-справжньому, то, мабуть, скористалися б заздалегідь визначеним рецептом, який називається кермовою картою. Вони доступні для ряду поширених додатків, але тут ми розглянемо деякі кроки, необхідні для запуску та запуску сайту WordPress на Kubernetes.
Перше завдання - визначити пароль для MySQL:
kubectl створити секретний загальний mysql-pass --from-literal = password = YOUR_PASSWORD
kubectl поговорить із API-сервером, який перевірить команду, а потім збереже пароль у etcd. Наші служби визначаються у файлах YAML, і тепер нам потрібно постійне сховище для бази даних MySQL.
apiVersion: v1 kind: PersistentVolumeClaim метадані: name: mysql-pv-label labels: app: wordpress spec: accessModes: - ReadWriteOnce ресурси: запити: зберігання: 20Gi
Специфікація повинна бути здебільшого зрозумілою. Поля імені та мітки використовуються для посилання на це сховище з інших частин Kubernetes, в даному випадку нашого контейнера WordPress.
Щойно ми визначили сховище, ми можемо визначити екземпляр MySQL, вказуючи його на заздалегідь визначене сховище. Далі слід визначити саму базу даних. Ми надаємо цій базі даних ім’я та ярлик для зручності в Kubernetes.
Тепер нам потрібен ще один контейнер для запуску WordPress. Частиною специфікації розгортання контейнера є:
вид: Метадані розгортання: назва: мітки wordpress: додаток: специфікація wordpress: стратегія: тип: Відтворити
Тип стратегії «Відтворити» означає, що якщо будь-який із коду, що містить додаток, зміниться, запущені екземпляри будуть видалені та відтворені. Інші варіанти включають можливість циклу нових екземплярів та видалення існуючих екземплярів по одному, що дозволяє службі продовжувати працювати під час розгортання оновлення. Нарешті, ми оголошуємо послугу для самого WordPress, що включає код PHP та Apache. Частина файлу YAML, що декларує це:
метадані: назва: мітки wordpress: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer
Зверніть увагу на останній рядок, визначаючи тип послуги як LoadBalancer. Це вказує Kubernetes зробити послугу доступною за межами Kubernetes. Без цієї лінії це була б просто внутрішня послуга "Лише Kubernetes". І це все. Kubernetes тепер використовуватиме ці файли YAML як декларацію про те, що потрібно, і налаштовуватиме стручки, підключення, сховище тощо, як потрібно, щоб перевести кластер у “бажаний” стан.
Скористайтеся поданням інформаційної панелі, щоб отримати короткий огляд Kubernetes в діїЦе обов’язково був лише огляд Kubernetes на високому рівні, і багато деталей та особливостей системи були пропущені. Ми розглянули автомасштабування (як стручки, так і вузли, що складають кластер), завдання cron (запуск контейнерів за розкладом), Ingress (балансування навантаження HTTP, перезапис та розвантаження SSL), RBAC (контроль доступу на основі ролей) , мережеві політики (брандмауер) та багато іншого. Kubernetes надзвичайно гнучкий і надзвичайно потужний: для будь-якої нової ІТ-інфраструктури він повинен бути серйозним претендентом.
Ресурси
Якщо ви не знайомі з Docker, почніть тут: https://docs.docker.com/get-started.
Тут є інтерактивний посібник із розгортання та масштабування програми тут: https://kubernetes.io/docs/tutorials/kubernetes-basics.
І див. Https://kubernetes.io/docs/setup/scratch про те, як створити кластер.
Ви можете грати з безкоштовним кластером Kubernetes на https://tryk8s.com.
Нарешті, ви можете розглянути довгий технічний документ із чудовим оглядом використання Google Borg та того, як це вплинуло на дизайн Kubernetes тут: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Дізнайтеся більше про Tiger Computing.
- Краще хмарне сховище 2022-2023 року в Інтернеті: безкоштовні, платні та ділові варіанти
Вам подобається те, що ви читаєте? Хочете більше Linux та відкритого коду? Ми можемо доставити буквально! Підпишіться на формат Linux сьогодні за вигідною ціною. Ви можете отримати друковані видання, цифрові видання чи чому не обидва? Ми доставляємо до ваших дверей по всьому світу за просту річну плату. Тож зробіть своє життя кращим та легшим, підпишіться зараз!