Привіт, Хабре!
Наприкінці літа ми хочемо нагадати, що продовжуємо опрацювання теми і вирішили опублікувати статтю зі Stackoverflow, яка демонструє стан справ у цьому проекті на початок червня.
Приємного читання!
На момент написання цієї статті вік Kubernetes складає близько , і за останні два роки його популярність настільки зросла, що він стабільно входить до числа платформ. Цього року Kubernetes посідає третє місце. Нагадаємо: Kubernetes - це платформа, призначена для запуску та оркестрації контейнерних робочих навантажень.
Контейнери зародилися як спеціальна конструкція для ізоляції процесів у Linux; до складу контейнерів з 2007 року входять , і з 2002 – простору імен. Контейнери оформилися ще краще до 2008 року, коли стала доступна , а в Google розробили свій внутрішньокорпоративний механізм під назвою , де «вся робота ведеться у контейнерах». Звідси перенесемося в 2013 році, коли відбувся перший реліз Docker, і контейнери остаточно перейшли до розряду популярних масових рішень. На той момент основним інструментом для оркестрації контейнерів був , Хоча, шаленою популярністю він не користувався. Перший реліз Kubernetes відбувся 2015 року, після чого цей інструмент де-факто став стандартом у сфері оркестрації контейнерів.
Щоб спробувати зрозуміти, чому такий популярний Kubernetes, давайте спробуємо відповісти на кілька запитань. Коли востаннє розробникам вдавалося дійти згоди про те, як розгортати програми у продакшені? Скільки ви знаєте розробників, які використовують інструменти у вигляді, як вони надаються «з коробки»? Скільки сьогодні таких хмарних адміністраторів, які не розуміють, як працюють програми? Відповіді на ці питання ми розглянемо у цій статті.
Інфраструктура як YAML
У світі, який від Puppet і Chef прийшов до Kubernetes, одна з найбільших змін полягала в переході від «інфраструктури як код» до «інфраструктури як дані» – саме, як YAML. Всі ресурси в Kubernetes, до яких належать поди, конфігурації, розгорнуті екземпляри, томи та ін., можна легко описати у файлі YAML. Наприклад:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80З таким поданням фахівцям з DevOps або SRE зручніше повністю висловлювати свої робочі навантаження, без необхідності писати програмний код мовами як Python або Javascript.
Інші переваги організації інфраструктури як даних, зокрема такі:
- GitOps чи контроль версій Git Operations Version. Такий підхід дозволяє тримати всі YAML-файли Kubernetes в репозиторіях git, завдяки чому ви точно можете відстежити, коли було внесено зміну, хто його вніс, і що саме змінилося. Завдяки цьому підвищується прозорість операцій у межах всієї організації, підвищується ефективність роботи з усунення неоднозначності, зокрема, у тому, де працівники повинні шукати потрібні їм ресурси. У той же час, стає простіше автоматично вносити зміни до ресурсів Kubernetes – шляхом звичайного злиття pull-запиту.
- Масштабованість. Коли ресурси визначені у вигляді YAML, операторам кластера стає надзвичайно просто змінити одне чи два числа у ресурсі Kubernetes, змінивши цим принципи його масштабування. У Kubernetes передбачено механізм для горизонтального автомасштабування подів, за допомогою якого зручно визначати, яка мінімальна та максимальна кількість подів, яка потрібна в конкретній розгорнутій конфігурації, щоб справлятися з низьким і високим рівнем трафіку. Наприклад, якщо ви розгорнули конфігурацію, для якої потрібні додаткові потужності через різкий сплеск трафіку, то показник maxReplicas можна змінити з 10 на 20:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50- Безпека та управління. YAML чудово підходить для оцінки того, як ті чи інші речі розгортаються у Kubernetes. Наприклад, серйозна проблема, пов'язана із забезпеченням безпеки, стосується того, чи запускаються ваші робочі навантаження з-під користувача, який не має права адміністратора. В даному випадку нам можуть стати у нагоді такі інструменти як , валідатор YAML/JSON, плюс , валідатор політик, що дозволяє переконатися, що контекст ваших робочих навантажень не дозволяє контейнеру працювати з привілеями адміністратора. Якщо потрібно це забезпечити, користувачі можуть застосувати просту політику , ось так:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Варіанти інтеграції із хмарним провайдером. Одна з найпомітніших тенденцій у сучасних високих технологіях – запускати робочі навантаження на потужності загальнодоступних хмарних провайдерів. За допомогою компонента Kubernetes дозволяє будь-якому кластеру інтегруватися з хмарним провайдером, на якому він працює. Наприклад, якщо користувач запустив програму Kubernetes на AWS і хоче відкрити доступ до цієї програми через сервіс, хмарний провайдер допомагає автоматично створити сервіс
LoadBalancer, який автоматично надасть балансувальник навантаження , щоб перенаправити трафік у поди додатків.
Можливість розширення
Kubernetes дуже добре розширюється, і це подобається розробникам. Існує набір наявних ресурсів, таких як поди, розгортки, StatefulSets, секрети, ConfigMaps, і т.д. Щоправда, користувачі та розробники можуть додавати й інші ресурси у формі .
Наприклад, якщо ми хочемо визначити ресурс CronTab, то могли б зробити щось подібне:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
- name: v1
served: true
storage: true
Schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Пізніше ми можемо створити ресурс CronTab приблизно так:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Ще один варіант розширюваності Kubernetes полягає в тому, що розробник може писати власні оператори. – це особливий процес у кластері Kubernetes, що працює за патерном.». За допомогою оператора може автоматизувати управління CRD (власними визначеннями ресурсів), обмінюючись інформацією з Kubernetes API.
У співтоваристві є кілька інструментів, за допомогою яких розробникам зручно створювати власні оператори. Серед них - і його . Цей SDK надає основу, відштовхуючись від якої розробник може дуже швидко приступити до створення оператора. Скажімо, можна почати з командного рядка приблизно так:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorТак створюється весь стереотипний код для вашого оператора, у тому числі, файли YAML та код на Golang:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.goПотім можна додавати потрібні API та контролер, ось так:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceПісля чого, нарешті, зібрати оператор і відправити його до реєстру вашого контейнера:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Якщо розробнику потрібно ще більш повний контроль, можна змінити стереотипний код у файлах на Go. Наприклад, щоб змінити специфіку контролера, можна внести зміни до файлу controller.go.
Інший проект, , дозволяє створювати оператори, користуючись лише декларативними YAML-файлами. Наприклад, оператор для Apache Kafka визначатиметься приблизно . З його допомогою можна лише парою команд встановити кластер Kafka поверх Kubernetes:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaА потім налаштувати його за допомогою ще однієї команди:
$ kubectl kudo install kafka --instance=my-kafka-name
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m
-p BROKER_COUNT=5 -p BROKER_MEM=4096m
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
інновації
Протягом кількох останніх років великі релізи Kubernetes виходять раз на кілька місяців – тобто по три-чотири великі релізи на рік. Кількість нових фіч, що впроваджуються у кожному з них, не зменшується. Більше того, ознак уповільнення не спостерігається навіть у наші складні часи – подивіться, яка зараз .
Нові можливості дозволяють гнучкіше кластеризувати операції за наявності різноманітних робочих навантажень. Крім того, програмістам подобається більш повний контроль при розгортанні програм безпосередньо в продакшені.
Спільнота
Ще один серйозний аспект популярності Kubernetes полягає у силі його спільноти. У 2015 році, після досягнення версії 1.0, Kubernetes спонсорувався .
Також існують різноманітні спільноти (спеціальні групи з інтересів), орієнтовані на опрацювання різних областей Kubernetes у міру того, як цей проект розвивається. Ці групи постійно додають нові можливості, завдяки чому працювати з Kubernetes стає зручніше і зручніше.
Фонд Cloud Native Foundation також проводить CloudNativeCon/KubeCon, яка на момент написання цього тексту є найбільшою опенсорсною конференцією у світі. Як правило, вона проводиться три рази на рік і збирає тисячі професіоналів, які бажають покращити Kubernetes та його екосистему, а також освоїти нові можливості, котрі з'являються кожні три місяці.
Більше того, у Cloud Native Foundation є , який, спільно з SIGs розглядає нові та наявні орієнтовані на хмарну екосистему. Більшість із цих проектів допомагають покращити сильні сторони Kubernetes.
Нарешті, я вірю, що Kubernetes не мав би такого успіху без усвідомлених зусиль усієї спільноти, де люди тримаються один за одного, але, водночас, з радістю приймають до своїх лав новачків.
майбутнє
Один із основних викликів, з якими розробникам доведеться мати справу в майбутньому, є вміння зосереджуватися на деталях самого коду, а не на тій інфраструктурі, в якій він працює. Саме цим тенденціям відповідає , що сьогодні є однією з провідних. Вже існують просунуті фреймворки, наприклад, и які використовують Kubernetes для абстрагування інфраструктури від розробника.
У цій статті ми лише загалом розглянули нинішній стан Kubernetes – насправді це лише верхівка айсберга. У розпорядженні користувачів Kubernetes є і безліч інших ресурсів, можливостей і конфігурацій.
Джерело: habr.com