Домінуючою платформою для розгортання контейнерів, безперечно, став Kubernetes. Він надає можливість керувати практично всім, використовуючи свої API і контролери користувача, що розширюють його API за допомогою користувацьких ресурсів.
Тим не менш, користувач все ще повинен приймати докладні рішення про те, як саме розгортати, налаштовувати, керувати і масштабувати програми. На розсуд користувача залишаються питання масштабування програми, захисту, проходження трафіку. Цим Kubernetes відрізняється від традиційних «платформ як послуга» (PaaS), наприклад Cloud Foundry і Heroku.
Платформи мають спрощений інтерфейс користувача, орієнтовані на розробників додатків, які найчастіше займаються налаштуванням окремих додатків. Маршрутизація, розгортання та метрики прозоро для користувача керуються базовою системою PaaS.
Робочий процес “вихідний код – постачання” обробляється PaaS шляхом створення користувача образу контейнера, його розгортання, налаштування нового маршруту та піддомена DNS для вхідного трафіку. Все це запускається за командою git push.
У Kubernetes (навмисно) надаються лише основні блоки для таких платформ, надаючи спільноті можливість зробити цю роботу самостійно. Як :
Kubernetes – платформа для побудови платформ. Найкраща позиція для старту, але не фінішу.
В результаті ми бачимо пачку збірок Kubernetes, а також хостингів, які намагаються створити PaaS для Kubernetes, наприклад OpenShift та Rancher. На тлі зростаючого ринку Kube-PaaS на ринг виходить Knative, створений у липні 2018 року компаніями Google та Pivotal.
Knative вийшов у результаті спільної роботи Google і Pivotal, за невеликого сприяння інших компаній, наприклад IBM, RedHat і Solo.im. Він пропонує аналогічні PaaS речі для Kubernetes з першокласною підтримкою програм на основі безсерверних обчислень. На відміну від збірок Kubernetes, Knative встановлюється у вигляді доповнення на будь-який сумісний кластер Kubernetes, налаштовується через ресурси користувача.
Що таке Knative?
Knative описаний як «Платформа на основі Kubernetes для постачання робочих навантажень та керування ними за допомогою сучасних безсерверних обчислень». Knative, оголошуючи себе такою платформою, активно автоматично масштабує контейнери пропорційно до одночасних запитів HTTP. Сервіси, що не використовуються, в кінцевому підсумку масштабуються до нуля, надаючи масштабування на вимогу в стилі безсерверних обчислень.
Knative складається з набору контролерів, які встановлюються в будь-який кластер Kubernetes і забезпечують такі можливості:
- складання контейнеризованих додатків із вихідного коду (надається компонентом Будувати),
- надання доступу вхідному трафіку до додатків (надається компонентом Обслуговування),
- постачання та автоматичне масштабування додатків на запит (також надається компонентом Обслуговування),
- визначення джерел подій, що призводять до запуску додатків (надається компонентом Події).
Ключовим компонентом є Serving, який надає постачання, автоматичне масштабування та керування проходженням трафіку для керованих програм. Після встановлення Knative все ще зберігається повний доступ до API Kubernetes, що дозволяє користувачам керувати програмами звичайним способом, а також служить для налагодження сервісів Knative, працюючи з тими самими примітивами API, які використовують ці сервіси (модулі, сервіси тощо).
За допомогою Serving також автоматизується blue-green маршрутизація трафіку, забезпечуючи поділ трафіку між новими та старими версіями програми під час постачання користувачем оновленої версії програми.
Сам Knative залежить від встановлення сумісного ingress контролера. На момент написання статті підтримуються и . Він налаштує доступний ingress для маршрутизації трафіку до керованих за допомогою програм Knative.
Istio Service Mesh може стати великою залежністю для користувачів Knative, які бажають спробувати його без встановлення панелі керування Istio, оскільки Knative залежить лише від шлюзу.
З цієї причини більшість користувачів вважають за краще Gloo як шлюз для Knative, що надає подібний набір можливостей з Istio (якщо говорити про мету використання тільки Knative), а також використовує значно менше ресурсів і дає менші експлуатаційні витрати.
Давайте перевіримо Knative у дії на стенді. Я використовуватиму свіжовстановлений кластер, запущений у GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hПриступимо до встановлення Knative та Gloo. Це можна зробити у будь-якому порядку:
# ставим Knative-Serving
kubectl apply -f
https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f
https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...Перевіряємо, що всі Pods у статусі «Running»:
kubectl get pod -n knative-serving
NAME READY STATUS RESTARTS AGE
activator-5dd55958cc-fkp7r 1/1 Running 0 7m32s
autoscaler-fd66459b7-7d5s2 1/1 Running 0 7m31s
autoscaler-hpa-85b5667df4-mdjch 1/1 Running 0 7m32s
controller-85c8bb7ffd-nj9cs 1/1 Running 0 7m29s
webhook-5bd79b5c8b-7czrm 1/1 Running 0 7m29s
kubectl get pod -n gloo-system
NAME READY STATUS RESTARTS AGE
discovery-69548c8475-fvh7q 1/1 Running 0 44s
gloo-5b6954d7c7-7rfk9 1/1 Running 0 45s
ingress-6c46cdf6f6-jwj7m 1/1 Running 0 44s
knative-external-proxy-7dd7665869-x9xkg 1/1 Running 0 44s
knative-internal-proxy-7775476875-9xvdg 1/1 Running 0 44sGloo готовий до маршрутизації, давайте створимо автоматично масштабований сервіс Knative (назвемо його kservice) та направимо йому трафік.
Сервіси Knative надають легший шлях постачання додатків у Kubernetes – порівняно із звичайною моделлю Deployment+Service+Ingress. Працюватимемо з таким прикладом:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
Value: Knative userЯ скопіював це у файл, потім застосував його до мого кластера Kubernetes таким чином:
kubectl apply -f ksvc.yaml -n defaultМи можемо переглянути ресурси, створені Knative у кластері після поставки нашого 'helloworld-go' kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sPod з нашим чином 'helloworld-go' запускається у розгортанні kservice. Якщо трафіку не буде — кількість pod'ів буде скорочено до нуля. І навпаки, якщо кількість одночасних запитів перевищить деяке граничне значення, що налаштовується, — число pod'ів буде зростати.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative налаштовує свій ingress із використанням особливого 'ingress' ресурсу у внутрішньому API Knative. Gloo бере цей API як свою конфігурацію для надання властивостей, властивих PaaS, включаючи blue-green модель розгортання, автоматичне застосування TLS, таймаути та інші розширені особливості маршрутизації.
Через деякий час ми бачимо, що наші pod`и зникли (оскільки не було вхідного трафіку):
kubectl get pod -n default
No resources found.
kubectl get deployment -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sНарешті, ми спробуємо до них достукатися. Отримати URL для Knative Proxy легко та невимушено можна за допомогою glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Без встановленої glooctl можна підглянути адресу та порт у kube service:
kubectl get svc -n gloo-system knative-external-proxy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mПроженемо трохи даних за допомогою cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative надає майже-PaaS для розробників поверх «коробкового» Kubernetes, використовуючи високопродуктивний повнофункціональний шлюз API Gloo. Ця нотатка лише злегка зачепила велику кількість можливостей Knative, доступних для налаштування, а також додаткових функцій. Аналогічно і з Gloo!
Незважаючи на те, що Knative все ще молодий проект, його команда випускає нові версії кожні шість тижнів, розпочато реалізацію просунутих функцій, наприклад автоматичне розгортання TLS, автоматичне масштабування панелі керування. Є висока ймовірність того, що в результаті співпраці численних хмарних компаній, а також як основа нової пропозиції Cloud Run від компанії Google, Knative може стати основним варіантом для організації безсерверних обчислень і PaaS в Kubernetes. Слідкуйте за новинами!
Від редакції SouthBridge
Нам важлива думка читачів, тому ми просимо вас взяти участь у невеликому опитуванні, пов'язаному з майбутніми статтями про Knative, Kubernetes, безсерверні обчислення:
Тільки зареєстровані користувачі можуть брати участь в опитуванні. , будь ласка.
Перекладати писати далі статті та посібники про Knative та безсерверні обчислення?
-
Так будь ласка.
-
Дякую не потрібно.
Проголосували 28 користувачів. Утрималися 4 користувача.
Джерело: habr.com