Здравей, Хабр!
В края на лятото искаме да напомним, че продължаваме да работим по темата и решихме да публикуваме статия от 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 = "Контейнерите не трябва да работят като 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 има , който, заедно с SIG-овете, разглежда новите и съществуващи фондове, насочени към облачната екосистема. Повечето от тези проекти помагат за подобряване на силните страни на Kubernetes.
Накрая, вярвам, че Kubernetes нямаше да има такъв успех без осъзнатите усилия на цялото общество, където хората са сплутени помежду си, но в същото време с радост приемат новаците.
Бъдеще
Едно от основните предизвикателства, с които разработчиците ще трябва да се справят в бъдеще, е способността им да се фокусират върху детайлите на самия код, а не върху инфраструктурата, в която работи. Именно на тези тенденции отговаря , която в момента е една от водещите. Вече съществуват напреднали рамки, например, и , които използват Kubernetes за абстрахиране на инфраструктурата от разработчика.
В тази статия накратко разгледахме настоящото състояние на Kubernetes – всъщност, това е само върхът на айсберга. Потребителите на Kubernetes разполагат с множество други ресурси, възможности и конфигурации.
Източник: habr.com
