Translate

вівторок, 21 червня 2022 р.

Prometheus. Setup And Monitoring In Kubernetes


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


WHAT IS PROMETHEUS OPERATOR

Prometheus реалізований як оператор Kubernetes. Цю концепцію вперше запропонувала компанія CoreOS, яка була поглинута RedHat-ом. Оператор - це додаткова абстракція, що допомагає менеджити сервіси, які можуть бути дещо "нерідними" для Kubernetes і надає додатковий рівень автоматизації такому програмному продукту. Оператор вводить додаткові типи об'єктів, котрі включають в себе об'єкти більш низького рівня (native resources). Скажімо використавши "kind: Prometeus", оператор (додатковий постійний сервіс) автоматично створить та налаштує StatefulSet, а в його поди буде змонтовано необхідний Secret, що містить конфігураційний файл для старту Прометеуса. Цей контролер також буде слідкувати за подальшою ситуацією щодо ресурсів, створених ним же, і буде їх змінювати за необхідності: скейлити, даунскейлити, видаляти і т.п.

Такі типи об'єктів реалізовуються за допомогою CRD (custom resource definition), що є розширенням до Kubernetes API. Існує велика множина операторів, для деяких продуктів - це офіційний спосіб їх установки і менеджменту, для інших - опціональний чи навіть неофіційний. Ніщо не заважає запакувати оператор в Helm-чарт чи просто виливати його як набір yaml-файлів.

Є декілька варіантів установки Prometheus оператора, і це варто усвідомлювати перед вибором способу інсталяції:
  • prometheus-operator. Основний та офіційний репозиторій, де відбувається розробка. Після його установки  всі ресурси (Prometheus, Alertmanager та ін.) необхідно буде створити власноруч, він описує лише створення оператору та CRDs, якими і маніпулює. Prometheus Operator не тягне за собою купи дашбордів для графани чи щось подібне, як наступний проект в списку.
  • kube-prometheus. Також офіційний спосіб інсталяції, який вже включає приклад конфігурації для повного моніторингу Kubernetes кластеру, створює Prometheus та Alertmanager в HA режимі і навіть активізує нотифікації у разі критичних проблем. Так би мовити мінімальний набір Kubernetes-користувача.
  • kube-prometheus-stack helm chart надає схожі з kube-prometheus  можливості, проте не є офіційним рішенням від проекту.

Із питаннями по першим двом можна звертатись в офіційний Kubernetes slack-канал. Community helm чарт може мати інакшу конфігугацію, інші Grafana-дашборди та навіть інші лейбли для додавання сервісів до моніторингу. Однак всередині все ті ж CRDs та оператор.

У статті буде розглянуто лише два перші способи установки. Основна ціль статті - показати як працювати із примітивами оператора, а не просто встановити Prometheus.

середа, 27 квітня 2022 р.

Istio. Part II: Concepts And Traffic Management

Минулого разу ми познайомились із Service Mesh, поговорили про історичні передумови його появи та встановили Istio. Про особливості його використання згадали лише мимохіть, тож в цій частині спробуємо це виправити.

Для того щоб рухатись далі необхідні робочі Kubernetes та Istio. Версії, котрими я користуюсь, можна знайти в попередніх статтях. Для зручності також можна встановити MetalLB, що реалізує програмний LoadBalancer, хоч він і не обов'язковий в цьому випадку.

Основні додаткові абстракції, котрі привносить Istio в Kubernetes, реалізовані через CRD-розширення:

  • Gateway. Направляє трафік на відповідний VirtualService в залежності від доменного імені. У деякому приближенні про Gateway можна думати як про балансувальник, котрий стоїть перед всіма ресурсами. Разом із VirtualService виступає як більш гнучка заміна Kubernetes Ingress.
  • VirtualService. Абстракція Istio, котра описує, як запити мають потрапляти до кінцевого K8s сервісу. На відміну від Gateway працює із внутрішнім трафіком.
  • DestinationRule. Описує підмножини можливих сервісів та їх мапінги. Їх використовує VirtualService для розрізнення на яку саме версію сервісу має піти трафік. Окрім цього тут також описуються опції Сircuit Вreaker логіки.
  • ServiceEntry. Абстракція, що відповідає за додавання записів до внутрішнього реєстру сервісів Istio (service registry). Після чого Envoy може відправляти трафік на таку адресу, як ніби вона всередині mesh-мережі.

Одразу складно зрозуміти їх призначення, проте далі має бути зрозуміліше.


1. KUBERNETES ISTIO INGRESS

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

субота, 16 квітня 2022 р.

Istio. Part I: Service Mesh. Intro And Installation

Це вступна перша стаття про Istio і основи його роботи. У ній також торкнемось основ Service Mesh, його призначення та бонусів, що він надає.


1. WHAT IS SERVICE MESH

Отже почнемо із Service Mesh. Однією із причин її появи стало збільшення кількості різноманітних мікросервісів в інфраструктурах великих компаній після ділення монолітних додатків. Як наслідок цього процесу зросла кількість внутрішнього мережевого трафіку, котрий потрібно було якось "приборкувати". 

Разом із тим була необхідність в розмежуванні коду додатків та коду-обв'язки на кшталт балансування трафіку на рівні запитів (request-level load balancing), circuit-breaking (мережевий розрив інтеграції сервісів після досягнень певних показників запитів), дзеркалювання трафіку (mirroring, тобто повторення трафіку на декілька сервісів, наприклад, для тестування), трейсінгу тощо. Попередньо цей функціонал реалізовувався в окремих, іноді закритих, бібліотеках великих компаній (Hysterix в Netflix, Finagle в компанії Twitter тощо). У сучасному світі розгорнути додатковий проксі значно простіше ніж інтегрувати додаткову бібліотеку в кожне програмне рішення. До того ж вони можуть бути написані на різних мовах програмування, що ще більше підвищує вартість розробки.

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

Найбільш популярні реалізації Service Mesh, що не прив'язані до cloud-платформ:

  • Consul Connect. Продукт відомої HashiCorp. Розроблювався як рішення для власної платформи Nomad, проте наразі доступний і для Kubernetes. У його основі також Envoy.
  • Linkerd. Проект входить до CNCF і фокусується більше на простоті ніж гнучкості.
  • Traefik Mesh. Також основна ціль - простота інсталяції і підтримки. На відміну від більшості конкурентів, у якості проксі виступає Traefik
  • Kuma. Platform-agnostic рішення, що може обслуговувати не лише Kubernetes сервіси, а також звичайні віртуальних машини. Основним мейтейнером Kuma є Kong, виробник популярного шлюзу Kong Gateway з відкритим кодом. Має статус CNCF Sandbox проєкту.
  • OSM (Open Service Mesh). Імплементація від Microsoft, тож ймовірно це непогане рішення для Azure. Використовує всі ті ж популярні дизайн-принципи що і конкуренти: Data/Control plane, Envoy, а також реалізує SMI (Service Mesh Interface)
  • Istio. Мабуть найбільш функціональний і як наслідок дещо складніший за інші рішення. Про нього, як я вже обіцяв надалі і піде мова.

середа, 9 березня 2022 р.

Kubernetes. Part V: Configure And Use Ingress. MetalLB

Ця стаття вже п'ята з серії статей про Kubernetes. Перед її прочитанням рекомендую ознайомитись хоча б з базовими об'єктами кластеру та їх використанням для вирішення задач.

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

hostNetwork: true. Под, створений із такою опцією, матиме можливість бачити мережеві інтерфейси Kubernetes хосту, де його було запущено.

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  hostNetwork: true
  containers:
  - name: influxdb
    image: influxdb

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

Задеплоїмо вищезгаданий поді та знайдемо на якому вузлі він оселився:

$ kubectl get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP            NODE   
influxdb   1/1     Running   0          38h   10.30.0.141   k8s-s-a


$ kubectl get nodes -o wide
NAME      STATUS   ROLES   AGE     VERSION   INTERNAL-IP
...
k8s-s-a   Ready    <none>  4d16h   v1.23.4   192.168.1.48


І перевіримо чи порт справді відкритий:

$ ssh 192.168.1.48
$ netstat -tulpn | grep influx
tcp        0      0 127.0.0.1:4222   0.0.0.0:*   LISTEN      949214/influxd
tcp6       0      0 :::8086          :::*        LISTEN      949214/influxd


hostPort: integer. Ця опція дозволяє поду активувати лише один порт на всіх інтерфейсах вузла Kubernetes. Yaml для створення такого поду буде виглядати наступним чином:

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      ports:
        - containerPort: 8086
          hostPort: 8086

Його, як і попередній варіант, дуже не рекомендовано використовувати по тим же причинам.

вівторок, 8 березня 2022 р.

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"}

Kubernetes. Part II: Setup Cluster With Kubeadm. Plugins

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

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

  • minikube чи kind. Найпростіший спосіб установки Kubernetes на власний локальний PC. Буде корисний людям, котрі хочуть приступити до вивчення Kubernetes, не втрачаючи купу часу на його більш повноцінну установку, чи локального тестування роботи додатків, що потреують цього середовища.
  • kubeadm. Офіційний, доволі мануальний спосіб. Підтримує установку на звичайні bare-metal сервера чи віртуальні машини, що працюють під управлінням OS Linux. Наразі kubeadm також підтримує створення HA (High Availability) Master інсталяцій.
  • kops. Призначений для розгортання Kubernetes на AWS, для чого використовує API-виклики платформи. Написаний на мові Go. Як зазначено на github сторінці проекту, робота kops з GCE, OpenStack та DigitalOcean перебуває в статусі бета, а в майбутньому також планується підтримка інших хмарних платформ. Також підтримує розгортання HA Master конфігурацій.
  • kubespray. Це набір Ansible плейбуків для розгортання Kubernetes на платформах AWS, GCE, Azure, OpenStack, vSphere, bare-metal машинах і т.п. Має найбільш обширний список підтримки дистрибутивів Linux. Також підтримує установку HA Master конфігурацій. Це community-проект, детальніше про нього можна прочитати за посиланням.
  • K0s. Установка K8s по ssh але, на відміну від Kubespray, без залучення Ansible. Написаний на мові Go компанією Mirantis. Я йому присвятив окрему статтю в блозі, де і можна ознайомитись із деталями.
  • Варіанти, що пропонують провайдери хостингів чи клауди. На зразок AWS Elastic Kubernetes Service (EKS) чи Google Kubernetes Engine (GKE). Мабуть найпростіший варіант, котрий в тому числі найпростіший в обслуговуванні.
  • Та багато-багато інших варіантів

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

k8s-m-a  192.168.1.45
k8s-s-a    192.168.1.48
k8s-s-b    192.168.1.49

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

середа, 23 лютого 2022 р.

Kubernetes. Part I: Overview

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

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

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

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

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

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

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

Mesos/Marathon (вже не підтримується)
Bosh/Cloud Foundry (туманне майбутнє)

А цього разу мова піде про Kubernetes (це ім'я часто пишуть як K8s, адже звучить схоже). Kubernetes - це система з відкритим вихідним кодом для автоматизації розгортання, масштабування та управління додатками (мікросервісами) в контейнерах. У якості системи контейнеризації (container runtime) використовує в основному containerd/cri-o, але є і інші, менш популярні. Все завдяки CRI-інтерфейсу, що зробив можливим відв'язку Kubernetes від Docker-у. Його і досі можна використовувати, але не варто. На низькому рівні, не залежно від того, яку імплементацію CRI було обрано, все рівно працює низькорівневий runC.

неділя, 9 січня 2022 р.

Redis Cluster

Я вже якось писав про базові можливості Redis і про способи забезпечення вищої доступності. Але цей цикл статей не був би повний без статті про Redis Cluster, інсталяції, що покриває як питання високої доступності, так і шардингу. 


1. INTRO

Redis Cluster має наступні переваги/особливості:

  • Висока доступність та горизонтальне масштабування до 1000 вузлів. Проте consistent hashing відсутній: при додаванні чи видаленні серверів із кластеру необхідно самому попіклуватись про рівномірний розподіл та переміщеня даних в кластері. Деякі з цих проблем вирішені в Enterprise версії.
  • Асинхронна синхронізація зі слейвами. Тобто кластер не гарантує консистентності операцій, тож при певному збігу обставин (наприклад фейловер процес) деякі дані можуть бути втраченими. Але це позитивно впливає на продуктивність.
  • Відсутність тразакцій/multiple-keys операцій (MULTI, EXEC, DISCARD, WATCH ), але це можна дещо пом'якшити із простановкою hash tag для ключів. Це пов'язано із самим процесом хешування (алгоритмом розміщення даних в кластері): перший ключ при записі може потрапити на перший сервер, а наступний після нього - на останній. Тож можливо код клієнта треба буде дещо змінити.
  • Одна із основних переваг Redis Cluster - це шардинг. Тобто великі об'єми даних можна розділити на групи серверів. У випадку Redis Sentinel він обмежений кількістю оперативної пам'яті сервера. До речі, Enterprise версія вміє використовувати кеш SSD-диску
  • Slave-вузли не простоюють, а забезпечують операції читання для кінцевих клієнтів. Хоч звісно можливі випадки надання не найсвіжіших даних через асинхронну природу реплікації.
  • Наявність replica migration. Тобто майстри, що мають декілька реплік, можуть ділитись реплікою із іншим майстром, який її потребує.

Із деталями будемо розбиратись в процесі налаштування. Cluster функціонал з'явився починаючи із версії 3, де його створенням та розподіленням даних в кластері ще займався ruby-скрипт. Наразі все інтегровано в redis-cli утиліту.