Привет, Хаброжители!

Насколько досконально нужно изучить платформу Kubernetes профессиональному разработчику, чтобы произвести развёртывание в системе эксплуатационного уровня? Достаточно познакомиться с «Kubernetes для разработчиков».

По своей сути это обучающее руководство, в котором пошагово показан весь процесс разработки и развёртывания простого контейнеризированного приложения. Для изучения не обязательно иметь предварительные знания о Kubernetes или использовании контейнеров. В книге сначала разбирается, как запустить и сделать доступным в Интернете простейший контейнер, а затем идёт постепенное погружение в такие дополнительные концепции Kubernetes, как stateful-приложения и очереди фоновых задач.

Эта книга поможет вам начать свое путешествие с Kubernetes!

Кто же написал этот незаменимый справочник для разработчика?

Уильям Деннис — продакт-менеджер в компании Google и член команды Google Kubernetes Engine.

Благодаря своей работе Деннис знает о Kubernetes многое: что может пригодиться, а в какие дебри первое время можно не лезть. Именно по этой причине появилась книга «Kubernetes для разработчиков». Однако, чтобы познакомиться с автором, можно для начала изучить его статью, переведённую для Хабра.

Новая ценовая политика в GKE Autopilot — теперь на основе узлов

Начиная с наступившего года в Autopilot будет две модели ценообразования: традиционная, на основе подов, и новая опция — на основе узлов. На странице с тарифами достаточно хорошо объяснена разница между ними (как минимум, надеюсь на это, поскольку я сам это писал) и подсказано, как лучше всего использовать каждую из них. Тем не менее, быстро напомню вам, в чём суть обеих моделей:

Подовая модель отлично подойдёт вам на случай, когда вы не хотите задумываться и тем более беспокоиться об упаковке узлов в контейнеры — и готовы целиком поручить эту работу GKE. Эта модель построена по принципу «всё включено», позволяет вам не беспокоиться о недоиспользуемых узлах или о рабочих нагрузках со странной конфигурацией. Узловая модель полезна в случаях, когда предъявляются специфичные требования к аппаратному обеспечению (например, приходится работать с конкретным GPU или ЦП), либо когда вам приходится иметь дело с большими рабочими нагрузками, которые хорошо контейнеризуются — под них достаточно купить несколько виртуальных машин. Узловая модель тарифицируется отдельно за каждый узел по ценам вычислительного движка (Compute Engine) плюс небольшая переплата. Узловая модель может обойтись вам дешевле при условии, что вы будете заполнять узлы. Как правило, лучше всего при использовании Autopilot смешивать обе стратегии, пользуясь преимуществами той, чья модель лучше соответствует конкретной рабочей нагрузке.

Также появилась ещё одна новая возможность — Custom Compute Class. Она позволяет вам определять пользовательские классы вычислений с включением правил приоритета. Так можно с лёгкостью конфигурировать альтернативы тем вычислительным классам, которые встроены в Autopilot.

Две эти новые возможности — новая узловая модель тарификации и пользовательский вычислительный класс — сильно дополняют друг друга, так как, сочетая их, можно создавать на уровне узлов собственные альтернативы тем вычислительным классам, которые встроены в Autopilot. Встроенные варианты — это «сбалансированный» (Balanced) и «горизонтально масштабируемый» (Scale Out). Более того, новыми вариантами можно заменить даже обобщённые / задаваемые по умолчанию вычислительные классы. Так, при узловой модели тарификации предоставляется удобный метод, действующий на основе рабочих нагрузок, реализуемый прямо на виртуальных машинах вида T2D и N2D. При этом весь процесс полностью управляется GKE.

Вот как.

Вычислительный класс для горизонтального масштабирования на основе узлов

Вот как я бы написал мой собственный вычислительный класс, представляющий собой узловую альтернативу классу горизонтального масштабирования, применяемому в Autopilot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: scaleout-nodes
spec:
  priorities:
  - machineFamily: t2d
    minCores: 4
  activeMigration:
    optimizeRulePriority: false
  nodePoolAutoCreation:
    enabled: true

scaleout-nodes.yaml

Встроенный вычислительный класс для горизонтального масштабирования строится на основе T2D (или T2A для Arm). Как видите, воссоздать такую конфигурацию в узловой модели достаточно легко. Просто укажите t2d (или t2a для Arm) в качестве семейства машин, указываемого в вычислительном классе.

Можно не выставлять настройку minCores или поставить её так, как это сделал я, чтобы получить один из заранее определённых размеров T2D. Как подобрать наиболее подходящий минимум ядер? Для узлов GKE характерны издержки, за которые вы и платите при модели тарификации, основанной на использовании узлов. Именно поэтому стоило бы избегать такой модели при минимальных конфигурациях из 2 или 1 ядра, поскольку узел работал бы в основном впустую. Здесь я беру за минимум 4, но вы можете установить и более высокий минимум, если работаете с более крупными нагрузками.

Совет: Если вам кажется, что 4 ядра процессора — это многовато для минимума, то, пожалуй, вам лучше придерживаться подовой модели.

Класс сбалансированных вычислений на основе узлов

Теперь давайте напишем на основе узлов новый вариант класса сбалансированных вычислений, встроенного в Autopilot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: balanced-nodes
spec:
  priorities:
  - machineFamily: n2d
    minCores: 4
  - machineFamily: n2
    minCores: 4
  activeMigration:
    optimizeRulePriority: false
  nodePoolAutoCreation:
    enabled: true

balanced-nodes.yaml

Встроенный в Autopilot класс сбалансированных вычислений поддерживается N2 и N2D. Поэтому для данного вычислительного класса можно указать в правилах приоритета обе опции. При работе по правилам приоритета система будет вести себя немного иначе — сначала израсходует всю вашу квоту на N2D, а после этого откатится к N2 как к резервному варианту. Autopilot, в свою очередь, более равномерно разделит создание узлов между двумя элементами. Но цель выполнения рабочих нагрузок на N2/N2D будет достигнута. Если у вас есть предпочтения, просто сами задайте соответствующий порядок.

В этих примерах нет ничего особенного. Вы можете сами создавать подобные вычислительные классы при работе с любым семейством машин, в том числе, E2.

Попробуйте сами

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

Примечание: ваш кластер может использовать GKE 1.30.3-gke.1451000 или выше, на момент написания оригинала статьи это всё ещё достаточно свежие версии. Прежде чем попробовать этот пример, обязательно обновите ваш кластер.

Здесь мы развернём 5 подов в нашем пользовательском вычислительном классе горизонтального масштабирования на основе узлов.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: timeserver-scaleout
spec:
  replicas: 5
  selector:
    matchLabels:
      pod: timeserver-scaleout-pod
  template:
    metadata:
      labels:
        pod: timeserver-scaleout-pod
    spec:
      nodeSelector:
        cloud.google.com/compute-class: scaleout-nodes
      containers:
      - name: timeserver-container
        image: docker.io/wdenniss/timeserver:1

deploy-scaleout.yaml

Когда все ресурсы будут определены, начнём с создания вычислительных классов

kubectl create -f https://raw.githubusercontent.com/WilliamDenniss/autopilot-examples/main/custom-compute-class/node-classes/scaleout-nodes.yaml

Затем перейдём к развёртыванию

kubectl create -f https://raw.githubusercontent.com/WilliamDenniss/autopilot-examples/main/custom-compute-class/node-classes/demo/deploy-scaleout.yaml

Теперь можно посмотреть, что получилось. Можно добавить от себя один столбец, в котором будет отображаться тип инстанса, используемого данной рабочей нагрузкой.

kubectl get pods -o wide
kubectl get nodes -o custom-columns="NAME:.metadata.name,INSTANCE_TYPE:.metadata.labels.node\.kubernetes\.io/instance-type"

Вот что у меня получилось в результате пробного прогона:

NAME                                  READY   STATUS	RESTARTS   AGE     IP            NODE                                    NOMINATED NODE   READINESS GATES
timeserver-scaleout-97959c8db-6x97j   1/1 	Running   0      	5m31s   10.19.0.135   gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   <none>           <none>
timeserver-scaleout-97959c8db-7vqrd   1/1 	Running   0      	5m31s   10.19.0.134   gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   <none>           <none>
timeserver-scaleout-97959c8db-8fjf7   1/1 	Running   0      	5m31s   10.19.0.131   gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   <none>           <none>
timeserver-scaleout-97959c8db-wlldw   1/1 	Running   0      	5m31s   10.19.0.133   gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   <none>       	<none>
timeserver-scaleout-97959c8db-zmgtz   1/1 	Running   0      	5m31s   10.19.0.132   gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   <none>           <none>
NAME                                    INSTANCE_TYPE
gk3-wave-1-nap-rio7p80r-54e97860-htfg   e2-standard-2
gk3-wave-1-nap-vxekt9qa-5cf704f6-j4r6   t2d-standard-4

Данная рабочая нагрузка будет тарифицироваться по ставкам для вычислительного движка для инстансов T2D (т.e., по стоимости t2d-standard-4, плюс небольшая надбавка за Autopilot.

В случае если вы развёртываете рабочие нагрузки в большом количестве и можете загрузить все узлы, тарифный план может получиться выгоднее.

Не забудьте установить правильные значения для запросов и лимитов!

Поскольку расходы, конечно же, хочется оптимизировать, убедитесь, что правильно задали в вашем поде запросы на ресурсы. При том, что эта тема выходит за рамки данного поста, она принципиально важна с точки зрения оптимизации расходов, пусть для обслуживания ваших рабочих нагрузок вы и используете Kubernetes (с GKE в режиме Autopilot, при тарификации на основе подов или узлов, либо работаете как раньше, в Стандартном режиме на основе пулов узлов). Именно от заданного запроса на ресурсы зависит, как ресурсы будут выделяться, поэтому чем точнее вы будете, тем лучше оптимизируете ваши расходы, независимо от того, какой моделью воспользуетесь. В моей книге есть целая глава о том, как правильно устанавливать запросы и лимиты на ресурсы при обращении с рабочими нагрузками.

Теперь Autopilot также поддерживает поды с частичным использованием ядра, при помощи которых также можно серьёзно сэкономить. Установив пределы выше уровня запросов, можно (если будет такая возможность) позаимствовать мощности, зарезервированные другими подами, но пока простаивающие без дела. Такая возможность доступна, начиная с версии 1.30.2-gke.1394000.

Резюме

Две модели ценообразования предусмотрены в Autopilot потому, что с их помощью вы можете взять лучшее от двух миров. Ни одна из них не превосходит другую во всём. В принципе, если вы имеете дело со сравнительно небольшими рабочими нагрузками неправильной формы, тщательное планирование при работе с которыми себя не оправдывает, лучше и дальше эксплуатировать их на модели подов, задаваемой по умолчанию. Но если у вас чётко определённые и сравнительно крупные рабочие нагрузки, которые хорошо контейнеризуются, то вам может пригодиться такая узловая модель, которая описана в этом посте. С её помощью вы сможете легко определить пользовательские вычислительные классы, рассчитанные на работу с узловой моделью, а программисты затем смогут выбирать такой вариант при развёртывании.

Приобрести «Kubernetes для разработчиков» можно у нас на сайте.

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Kubernetes