Translate

пʼятниця, 6 жовтня 2017 р.

Kubernetes. Part III: Objects And How To Use Them

Отже у нас вже є готовий налаштований кластер і, озброївшись необхідним теоретичним мінімумом, ми можемо переходити до подальшого вивчення Kubernetes. Цього разу ми поговоримо детальніше про основні примітиви (objects) Kubernetes, як вони взаємодіють між собою та як реалізовані.

Забігаючи наперед, основні команд для отримання даних про роботу об'єктів є наступні:
  • kubectl get object_type - перерахунок всіх об'єктів даного типу, котрі знаходяться в межах одного неймспейсу
  • kubectl describe object_type - детальна інформація про всі об'єкт даного типу, що також знаходяться в одному неймспейсі
Всі основні об'єкти перераховані нижче. Якщо замість object_type вказати all, то буде виведено все, що знаходиться в неймспейсі.

ПОД (POD). Створимо под, що буде складатись з одного docker-контейнера і буде доступний на порту 9876. Для цього використаємо образ з dockerhub mhausenblas/simpleservice:0.5.0:

$ kubectl run first-pod --image=mhausenblas/simpleservice:0.5.0 --port=9876
deployment "first-pod" created

Перевіримо чи новий под працює:

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
first-pod-2257828502-l6z96   1/1       Running   0          23s

$ kubectl describe pod first-pod-2257828502-l6z96 | grep IP:
IP:   10.34.0.25

Отже, в межах кластеру под працює за адресою 10.34.0.25. Із будь-якого вузла кластеру пересвідчимось в цьому, зробивши запит до додатку:

[cluster]$ curl 10.34.0.25:9876/info
{"host": "10.34.0.25:9876", "version": "0.5.0", "from": "10.32.0.1"}

вівторок, 12 вересня 2017 р.

Kubernetes. Part II: Setup Cluster With Kubeadm. Plugins

Після ознайомлення з теорією можна перейти і до практичної частини. Цього разу установимо кластер Kubernetes на bare-metal, тобто звичайні віртуальні машини чи залізні сервера, що не входять до існуючих IAAS платформ.

Способів установки Kubernetes кластеру існує дуже багато. Всі ці перераховані варіанти різної актуальності, необхідно дивитись і перевіряти все уважно, щоб не витратити зайвого часу на марні спроби. Найбільш популярні способи:

  • minikube. Найпростіший спосіб установки Kubernetes на власний локальний PC. Буде корисний людям, котрі хочуть приступити до вивчення Kubernetes, не втрачаючи купу часу на його більш повноцінну установку. 
  • kubeadm. Підтримує установку на звичайні bare-metal сервера чи віртуальні машини, що працюють під управлінням наступних операційних систем Ubuntu 16.04+, CentOS 7 чи HypriotOS v1.0.1+ (Debian+Docker для ARM девайсів). Наразі kubeadm перебуває в статусі beta і поки не підтримує створення HA (High Availability) Master інсталяцій, проте підтримку цієї функції обіцяють в наступних релізах.
  • kops. Призначений для розгортання Kubernetes на AWS, для чого використовує API виклики платформи. Написаний на мові Go. Як зазначено на github сторінці проекту, робота kops з GCE та VMware vSphere перебуває в статусі альфа, а в майбутньому також планується підтримка інших хмарних платформ. У якості операційної системи для вузлів використовує Debian/Ubuntu, проте також є початкова підтримка CentOS/RHEL. Підтримує розгортання HA Master конфігурацій.
  • kubespray. По суті це набір Ansible плейбуків для розгортання Kubernetes на платформах AWS, GCE, Azure, OpenStack, vSphere чи bare-metal машинах. Має найбільш обширний список підтримки дистрибутивів Linux: Container Linux by CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7. Це community-проект. https://kubernetes.io/docs/getting-started-guides/kubespray/
  • conjure-up. Комплекс скриптів установки, котрий розробляє компанія Canonical. У основі conjure-up лежать такі технології як Juju, MAAS та LXD. Це чудовий варіант, якщо у якості хост-системи вас задовольняє Ubuntu. Також підтримує довгий перелік можливих cloud платформ. https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/

У цій статті ми розгорнемо власний кластер Kubernetes за допомогою утиліти kubeadm. Це буде не HA інсталяція на основі операційної системи Ubuntu 16.04, що в свою чергу працюватиме в системі віртуалізації VirtualBox. Перелік адрес хостів та їх доменів наступний:

k8s-m1  192.168.60.110
k8s-s1    192.168.60.111
k8s-s2    192.168.60.112
k8s-s3    192.168.60.113

Як рекомендує офіційна документація, кожній віртуальній машині варто виділити як мінімум 1ГБ оперативної пам’яті, інакше може не вистачити місця для запуску додатків.

середа, 23 серпня 2017 р.

Kubernetes. Part I: Overview

Яка ж мета існування всіх сучасних PaaS платформ? Які додатки варто на них запускати? Далеко не всі існуючі рішення є сенс запускати на таких платформах. Перш за все додаток має бути відповідно написаний, а точніше відповідати 12 вимогам (twelve-factor app методологія). Слідування цим вимогам може надати такі переваги вашому додатку:

- Зменшить час на входження нових розробників до проекту. Мається на увазі, що розробник працюватиме лише над окремою частиною/частинами додатку (мікросервісом), без необхідності розуміння одразу всього коду продукту.

- Збільшить переносимість частин коду між різними середовищами виконання.

- Підніме якість та зручність процесів CI/CD. Кожна частина продукту (мікросервіс) може оновлюватись окремо, головне - не пошкодити інтерфейс взаємодії (REST API і т.п.).

- Дозволить зручно горизонтально масштабувати додатки без значних змін архітектури.

Бажано також мінімізувати вагу додатків до ~300MB, інакше завантаження та старт великих контейнерів (у випадку використання контейнерів як середовища, як зазвичай і є) може зайняти пристойну кількість часу. Якщо ж засунути в контейнер купу пакетів, компіляторів і т.п. - то це вже буде такий собі мікросервіс.

Я вже робив огляд та базову конфігурацію кластерних систем управління контейнерами, серед яких:

Mesos/Marathon
Bosh/Cloud Foundry

А цього разу мова піде про Kubernetes (це ім'я часто пишуть як K8s, адже звучить схоже). Kubernetes - це система з відкритим вихідним кодом для автоматизації розгортання, масштабування та управління додатками (мікросервісами) в контейнерах. У якості системи контейнеризації (container runtime) використовує Docker (і експериментально rkt). У останніх релізах Kubernetes взято курс на підтримку інших систем контейнеризації через CRI (Container Runtime Interface) інтерфейс.

понеділок, 15 травня 2017 р.

Cloud Foundry. Part III: BOSH 2 Lite/Cloud Foundry (Diego)

Декілька тижнів тому я опублікував другу статтю про PAAS-платформу Cloud Foundry, а цього разу мова піде про установку нового Cloud Foundry з Diego runtime. Нагадаю, що Diego має купу вдосконалень в порівнянні з DEA, а саме нова система менеджменту контейнерів Garden, що підтримує деплой Docker-контейнерів, новий алгоритм розміщення задач Diego Auction та інші оптимізації.

Підтримка DEA буде припинена 22 травня 2017 року, останні релізи stemcell вже не працюють з DEA, тому практичне знайомство з Cloud Foundry ліпше починати з цієї статті. Цього разу буде описана установка BOSH2 Lite (так, існує ще і друга версія), Cloud Foundry з Diego runtime.

1. BOSH 2 LITE INSTALLATION (BOSH 2 DIRECTOR)


BOSH Lite - це реліз системи виливки Cloud Foundry для системи VirtualBox. Тож останній має бути встановлений в хост-системі:

$ VBoxManage --version
5.1.22r115126

Для інсталяції BOSH 2 Lite більше не потрібен Vagrant, адже його установочні скрипти вміють працювати з VirtualBox напряму.

BOSH 2 CLI написаний на мові Go і його установка для macOS заключається в завантаженні готового бінарного файлу:

$ cd ~/Downloads
$ wget https://s3.amazonaws.com/bosh-cli-artifacts/bosh-cli-2.0.16-darwin-amd64
$ chmod +x bosh-cli-*
# mv bosh-cli-* /usr/local/bin/bosh2

$ bosh2 -v
version 2.0.16-88aa790-2017-05-02T01:12:20Z

За релізами версій BOSH2 CLI можна слідкувати за наступним посиланням https://bosh.io/docs/cli-v2.html. Там же можна завантажити останню версію BOSH2 CLI для ОС Linux.

понеділок, 1 травня 2017 р.

Cloud Foundry. Part II: BOSH Lite/Cloud Foundry (DEA)

Зовсім нещодавно я написав першу ввідну статтю про PAAS-платформу Cloud Foundry , а зараз я пропоную локально встановити та на практиці оцінити цю платформу.

Є 2 найпростіші способи спробувати Cloud Foundry на локальній системі: PCF Dev та BOSH Lite. У цій статті буде розглянуто останній варіант, як більш гнучкий, проте і складніший. У якості хост-системи буде використано macOS, але звісно з установкою на інших операційних системах проблем не має бути. У кінцевому рахунку це все рівно буде віртуальна машина VirtualBox з Ubuntu 14.04 всередині. Головне - це мати систему з мінімальною кількістю оперативної пам'яті, що рівна 8ГБ.


1. BOSH LITE INSTALLATION (BOSH DIRECTOR)


Отже, до діла. Перш за все установимо BOSH, систему, котра розгортає вузли Cloud Foundry. У випадку Lite-версії, BOSH розповсюджується у вигляді готового образу віртуальної машини, тому Vagrant та VirtualBox мають бути установлені:

$ vagrant --version
Vagrant 1.9.1

$ VBoxManage --version
5.1.18r114002

Для VirtualBox варто також проінсталювати Oracle VM VirtualBox Extension Pack, адже інакше можливі проблеми з мережею між майбутніми компонентами.

Установимо BOSH CLI клієнт, котрий розповсюджується як ruby gem-пакет:

# gem install bosh_cli --no-ri --no-rdoc

$ bosh --version
BOSH 1.3215.4.0

неділя, 16 квітня 2017 р.

Cloud Foundry. Part I: Basics

Cloud платформи дозволяють будь-кому розгортати мережеві програми чи сервіси за лічені хвилини. Більш того, вони спрощують масштабування програм для потреб обслуговування більших навантажень, завдяки ним це відбувається кількома командами. Cloud платформи дозволяють розробникам більше фокусуватись на розробці кінцевого продукту, а не на інфраструктурі, що лежить в його основі. Проте, відверто кажучи, це скоріше ускладнить життя відділу адміністрування, адже чим більше рівнів абстракцій - тим вищим рівнем кваліфікації мають володіти співробітники, що будуть її обслуговувати.

Наступний малюнок відображає рівень абстракцій, з якими необхідно буде працювати конкретному розробнику. Всі інші рівні будуть обслуговуватись власним відділом адміністрування (якщо cloud платформа встановлена на власному залізі) або ж третьою стороною, на зразок IAAS-провайдера Amazon Web Services чи Google Cloud Platform.


Одного разу я вже писав про IAAS/PAAS-платформу Mesos/Marathon, про її особливості та переваги, а цього разу я пропоную познайомитись з хмарною платформою Cloud Foundry.

Cloud Foundry - вільне програмне забезпечення, розробкою якого з 2009 року займалась компанія VMware, а наразі - Pivotal. Код Cloud Foundry був відкритий в 2011 році і на сьогодній час курується організацією Cloud Foundry Foundation (Linux Foundation Collaborative Project).

Сloud Foundry можна встановити на одну із IAAS-платформ, що офіційно підтримується: AWS, VMware vSphere, OpenStack та ін. Власні комерційні PAAS-рішення на основі Cloud Foundry пропонують HPE (Stackato), IBM (Bluemix), Huawei (FusionStage), Pivotal та ін. Для потреб розробників можна звісно встановити увесь стек локально, використавши напрацювання Bosh Lite чи PCF Dev.

пʼятниця, 3 лютого 2017 р.

OpenVPN Part II: Connect Two Local Networks

Декілька тижнів тому я опублікував першу статтю про програму OpenVPN, де описав декілька способів її практичного використання. Цього разу я розповім про те, як об’єднати дві різні локальні мережі, в результаті чого кожен із вузлів буде мати доступ до всіх інших вузлів обох підмереж. Звісно дуже раджу спочатку ознайомитись із першою статтею, яка надасть необхідний теоретичний мінімум.

Для експериментів будемо використовувати наступні вузли:

 Short name  Public IP  Private IP  Network  Role
 ams1 37.139.10.10 10.129.18.182  10.129.0.0/16 SERVER
 ams2  - 10.129.20.80 10.129.0.0/16   -
 local1  - 192.168.1.10 192.168.1.0/24 CLIENT
 local2 -  192.168.1.20 192.168.1.0/24  -

Отже ми маємо два хости у підмережі 10.129.0.0/16 та два в іншій підмережі 192.168.1.0/24. ams1 (10.129.18.182) буде працювати у ролі сервера і для зовнішніх з’єднань володітиме публічною адресою 37.139.10.10 (це обов’язкова умова, якщо не враховувати можливість перебросу порта на OpenVPN-сервер). А local1 (192.168.1.10) буде підключатись до сервера у якості клієнта OpenVPN.

Установимо OpenVPN на ams1 та local1 вузлах:

# apt install openvpn

неділя, 22 січня 2017 р.

OpenVPN Part I: Setup and Configuration

OpenVPN - вільна реалізація технології Віртуальної Приватної Мережі (VPN) для створення зашифрованих каналів типу точка-точка або сервер-клієнти між комп’ютерами і може працювати як у звичайному routing, так і у bridge-режимі. Програма дозволяє створювати з’єднання навіть між вузлами, що знаходяться за NAT та мережевими екранами (фаєрволами), без необхідності їх переналаштування. OpenVPN була написана Джеймсом Йонаном (James Yonan) на мові програмування C і поширюється по ліцензії GNU GPL. Її перший реліз побачив світ в далекому 2001 році, і, на момент написання статті, актуальною є версія 2.4.

Для організації з’єднань OpenVPN використовує свій оригінальний протокол над TCP/UDP, що в свою чергу застосовує SSL/TLS для обміну ключами. Програма використовує бібліотеку OpenSSL для шифрування як корисних даних, так і сервісних, що необхідні для створення підключень і підтримки з’єднань. Остання, в свою чергу, дозволяє задіяти увесь набір алгоритмів шифрування, що доступні в бібліотеці.

Клієнти для OpenVPN існують для великої кількості операційних систем і платформ, в т.ч. мобільних та ОС для роутерів. У цьому сенсі це майже універсальне рішення.

Автентифікувати підключення OpenVPN-сервер може наступними способами:

  • За допомогою логіна та пароля із клієнтськими сертифікатами/без сертифікатів. Це забезпечується сторонніми модулями.
  • За допомогою попередньо згенерованого єдиного ключа для сервера та клієнта (PSK, тобто з’єднання встановлюється симетричним алгоритмом шифруванням).
  • Аутентифікація за допомогою сертифікатів (TLS client/server mode). Найбільш надійний варіант, адже в клієнта та сервера є свій унікальний набір ключів/серифікатів, що підписані одним центром сертифікації.

У останньому варіанті аутентифікації, сервер та клієнт мають свій ключ, випущений сертифікат та кореневий (СА) сертифікат. Для підняття рівня безпеки, клієнт також може мати додатковий пароль.