Kubernetes – це такий docker-compose на стероїдах, що дозволяє керувати кластером машин на яких запускаються контейнери. Infrastructure as a code, і всяке таке. Дивно що в цьому кібернетичному блозі про кібернетіс ще жодного разу не згадувалось, тому варто цю ситуацію виправити.
Інсталяція
Є різні способи поставити локально однонодовий кластер, minikube (з яким в мене не дуже вийшло), і microk8s, який на Ubuntu, і лінукси в яких є менеджер пакетів Snappy, ставиться так:
sudo snap install microk8s --classic
Це встановить кластер і CLI для керування кластером kubectl. Правда вона називатиметься microk8s.kubectl. Якщо ви не ставили kubectl окремо (можна через той же snap install) для керування кластером десь в хмарах, то можна зробити аліас, а якщо ставили – так можна переконфігурити її для роботи з локальним кластером:
microk8s.kubectl config view --raw > ~/.kube/config
Тоді можна наприклад отримати список нодів кластера:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION bunyk-latitude-e5470 Ready <none> 3h v1.14.0
Логічно що у випадку локальної інсталяції це буде лише один комп’ютер.
Щоб перемкнути kubectl на керування наприклад якимось кластером в хмарах Google, за умови що у вас встановлений gcloud, треба виконати:
gcloud container clusters get-credentials [CLUSTER_NAME]
Аддони й панель керування
Ще microk8s має команди для вмикання (enable) і вимикання (disable) аддонів:
microk8s.enable dns dashboard
dns потрібний для багатьох речей, тому його радять вмикати. dashboard – web UI, і InfluxDB з Grafana для моніторингу ресурсів. Щоб його побачити, треба викликати kubectl proxy і перейти за адресою: http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login
Сторінка логіну
Там попросять залогінитись, щоб отримати JWT токен для логіну, треба виконати
kubectl -n kube-system get secret # тоді в списку знайти ім'я що починається з kubernetes-dashboard-token- # а тоді: kubectl -n kube-system describe secret kubernetes-dashboard-token-c4bmp
Параметр -n означає простір імен, це щось на зразок директорії де лежать всі об’єкти кластера, наприклад секрети. Це також відображається в шляхах до API, як от /api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ для доступу до сервісу https:kubernetes-dashboard. За замовчуванням kubectl працює з простором імен default, але у випадку вище, нам треба kube-system.
Запуск контейнерів в Kubernetes
Тепер може спробуємо щось запустити? Для цього треба створити под (pod – англійське слово що позначає групу китів. Вони взагалі дивні слова мають для цього. Зграя сов – це parliament, круків – murder). Под – це група контейнерів зі спільною IP адресою, які запускаються а ноді.
Найпростіший спосіб створити под – майже такий самий як запустити контейнер:
kubectl run nginx --image=nginx # kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. # deployment.apps/nginx created
Це говорить нам що команда створила deployment, але в майбутньому створюватиме лише поди, якщо не передати параметр --generator=run-pod/v1. Чому так пояснюють тут.
Що таке деплоймент? Нуууу, це важко пояснити, і це мене найбільше в Кубернетісі вибішує. Под – це набір конейнерів зі спільною IP адресою, набором портів, диском, і т.д. Под сам по собі запускати в kubernetes не рекомендують, бо після того як в нього трапиться якась аварія наприклад через закінчення пам’яті, його ніхто не перезапустить. Подом керує контролер, одним з яких є контролер що називається ReplicaSet, який задає кількість копій пода що мають бути запущені. І якщо одна з них з якихось причин здихає – запускається нова, щоб кількість завжди відповідала потрібній. Deployment – об’єкт що містить контролер ReplicaSet, і керує версіями імеджів контейнерів в подах цього контролера. Абстракцій як в TCP/IP…
Тим не менш, ми побачимо под в списку:
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-w6468 1/1 Running 1 44h
Щоб видалити деплоймент разом з подами дають команду:
kubectl delete deployments/nginx
Трохи складніший спосіб створити под – написати маніфест:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: http
protocol: TCP
Якщо його записати в файл, наприклад nginx.yaml, то щоб запустити:
kubectl apply -f nginx.yaml
Як подивитись що всередині пода? Можна прокинути порт, і тоді те що контейнери в поді віддають на якомусь порті буде доступно на порті localhost:
kubectl port-forward nginx 8088:80
Загальне правило для портів в Kubernetes (бо такі пари порт:порт зустрічаються часто) – зліва порти ззовні, справа – всередині. Якщо все працює, на http://localhost:8088 ви маєте побачити сторінку де пише “If you see this page, the nginx web server is successfully installed and working.”
Можна подивитись логи:
$ kubectl logs -f nginx 127.0.0.1 - - [31/Mar/2019:17:00:53 +0000] "GET /favicon.ico HTTP/1.1" 404 154 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0" "-" 127.0.0.1 - - [31/Mar/2019:17:01:56 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0" "-"
Як змінити те що под показує на головній? Створити якийсь html файл і закинути його командою:
kubectl cp index.html nginx:/usr/share/nginx/html/index.html
Хоча так не прийнято робити, і можна хіба що під час розробки. Краще додати файли в імедж за допомогою Dockerfile.
Запуск сайту
Але давайте вже зробимо щось серйозне на кілька контейнерів. Наприклад як в цій публікації було за допомогою docker compose, тільки за допомогою kubernetes: два контейнери, один з них nginx веб-сервер що віддає статичні файли для фронт-енду, інший – API на python що віддає дані графіків.
Таким чином файли backend.docker, dashboard.html і server.py можна скопіювати собі в проект без змін (звідси). nginx.docker напевне краще називати frontend.docker, і помістити туди лише файли фронт-енду:
FROM nginx COPY dashboard.html /usr/share/nginx/html/index.html
Конфігурацію nginx ми змінювати не будемо, бо відповідальним за диспетчеризацію запитів між фронт-ендом і бекендом в нас буде штука що називається Ingress.
Тут, на відміну від docker-compose який сам наші контейнери може зібрати, їх треба створити вручну:
docker build -t frontend -f frontend.docker . docker build -t backend -f backend.docker .
Покладемо конфіг для двох деплойментів у файл site.yaml і скажемо кластеру оновитись (kubectl apply -f site.yaml):
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend-deployment
spec:
selector:
matchLabels:
tier: frontend
replicas: 1
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: frontend
image: frontend
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend-deployment
spec:
selector:
matchLabels:
tier: backend
replicas: 2 # більше подів для бекенду, бо йому самому може важко.
template:
metadata:
labels:
tier: backend
spec:
containers:
- name: backend
image: backend
ports:
- containerPort: 80
Один файл в Kubernetes може містити описи багатьох об’єктів, розділені рядком що містить “—“. Так простіше працювати, бо треба менше команд kubectl apply, чи kubectl delete.
Якщо kubectl get pods показує що наші поди мають статус ErrImagePull або ImagePullBackOff, це означає що kubernetes намагається взяти імеджі не з нашого комп’ютера, а з докерхабу.
Виявляється треба ще додати їх в реєстр microk8s. Для цього:
microk8s.enable registry docker tag backend localhost:32000/backend docker push localhost:32000/backend docker tag frontend localhost:32000/frontend docker push localhost:32000/frontend
Підозрюю що це можна було зробити простіше і швидше якщо зразу називати імеджі правильним тегом. Але майстерність приходить з досвідом. 
В кінцевому результаті ви маєте мати три запущені поди, в двох деплойментах.
І що з того? Поки нічого, бо IP адреси цих подів динамічно міняються (коли їх перезапускають). Для того щоб мати постійний доступ потрібен сервіс, який проксює доступ до подів заданих мітками (labels). Мітки це пари ключ-значення які чіпляються до об’єктів в Kubernetes. Коли ми в описі пода писали:
labels: tier: backend
То це ми йому якраз задавали мітки. Тепер по мітках ми можемо ці об’єкти отримувати:
bunyk@bunyk-thinkpad:~/projects/dockerizing$ kubectl get pods -l tier=frontend NAME READY STATUS RESTARTS AGE frontend-deployment-695cfcc94c-jl5hg 1/1 Running 0 3h6m bunyk@bunyk-thinkpad:~/projects/dockerizing$ kubectl get pods -l tier=backend NAME READY STATUS RESTARTS AGE backend-deployment-669d885465-cfbrc 1/1 Running 0 3h6m backend-deployment-669d885465-nh8lg 1/1 Running 0 3h6m
Так само сервіс має надає доступ з постійним IP до набору подів заданого мітками. Сервіси створюються так:
apiVersion: v1
kind: Service
metadata:
name: backend
spec:
selector:
tier: backend
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
tier: frontend
ports:
- protocol: TCP
port: 80
targetPort: 80
Сервіс має селектор що визначає за якими подами стежити, і відкриває порти. port – це який порт відкрити, targetPort – це до якого порта в поді приєднатись. За цим треба слідкувати, бо якщо не виконається одна з умов: порт на якому слухає сервер в контейнері == containerPort, containerPort == targetPort сервіса, port сервіса == порт до якого приєднується клієнт, то отримаємо помилку “Connection refused” чи подібну.
Після чергового kubectl apply -f site.yaml можна подивитись які сервіси отримуємо:
$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE backend ClusterIP 10.152.183.69 <none> 80/TCP 110m frontend ClusterIP 10.152.183.63 <none> 80/TCP 30m kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 8d $ curl 10.152.183.69/data/1 [1.0997977838,0.6222197737,0.7265324166,1.0475918458,0.8271129655,0.6489646475,0.3625859258,0.7692987393,1.1331619921,1.4889188394]
Бачимо що сервіси які ми створюємо мають тип ClusterIP. Це тип за замовчуванням, і означає що він буде доступний лише з середини кластера. Нам доступний, бо ми ж сидимо на одній єдиній ноді кластера. Крім нього є ще NodePort, LoadBalancer і ExternalName, але розбиратись що це – ми не будемо, бо й без того голова вже пухне (чи у вас ні?).
Залишився ще Ingress. Це штука що дає доступ до сервісів кластера ззовні кластера. Конфігурується так:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: entrypoint
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- http:
paths:
- path: /api/(.*)
backend:
serviceName: backend
servicePort: 80
- path: /(.*)
backend:
serviceName: frontend
servicePort: 80
Тут важливий параметр nginx.ingress.kubernetes.io/rewrite-target, який означає “передавати сервісу запит замінивши URL на той що вказано, підставивши групи з регулярного виразу в path“.
Після застосування цієї конфігурації, на localhost в нас завантажиться фронтенд, пошле через ingress запити до бекенду, і все навіть буде через HTTP 2.0.
Питайтесь якщо що не виходить чи не доходить, в мене теж багато з того що тут написано не виходило зразу, може я вже стикався з тими проблемами що у вас.
. Якщо в файл 
