Category Archives: k8s
Горизонтальное автомасштабирование модуля
Горизонтальное автомасштабирование модуля – это автоматическое масштабирование количества реплик модуля, управляемых контроллером. Оно выполняется горизонтальным контроллером, который активируется и конфигурируется путем создания ресурса HorizontalPodAutoscaler (HPA). Данный контроллер периодически проверяет метрики модуля, вычисляет количество реплик, необходимое для соответствия целевому значению метрики, сконфигурированной в ресурсе HorizontalPodAutoscaler, и настраивает поле replicas на целевом ресурсе (развертывании Deployment, наборе реплик ReplicaSet, контроллере репликации ReplicationController или наборе модулей с внутренним состоянием StatefulSet)
Процесс автомасштабирования
Процесс автомасштабирования можно разделить на три этапа:
- получение метрик всех модулей, управляемых масштабируемым ресурсным объектом;
- расчёт количества модулей, необходимого для приведения метрик к указанному целевому значению (или близкому к нему);
- обновление поля replicas масштабируемого ресурса. Далее мы рассмотрим все три этапа
Получение метрик модуля
Автопреобразователь масштаба сам не выполняет сбор метрик модуля. Он получает метрики из другого источника. Метрики модуля и узла собираются агентом под названием cAdvisor, который выполняется в Kubelet на каждом узле, а затем агрегируется кластерным компонентом под названием Heapster. Контроллер автопреобразователя горизонтального масштаба модуля получает метрики всех модулей, запрашивая агрегатор Heapster посредством вызовов REST.
Ресурс Role определяет, какие действия можно предпринимать и на каких ресурсах (или какие типы HTTP-запросов можно выполнять и на каких ресурсах RESTful). В следующем ниже листинге определяется роль, которая позволяет пользователям получать и выводить список служб в пространстве имен boo.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: boo name: service-reader rules: - apiGroups: [""] verbs: ["get", "list"] resources: ["services"]
Учетные записи ServiceAccount – это ресурсы, такие же, как модули, секреты, словари конфигурации и т. д., которые ограничиваются отдельными простран[1]ствами имен. Устанавливаемая по умолчанию учетная запись ServiceAccount создается автоматически для каждого пространства имен (именно их и ис[1]пользовали ваши модули все время). Список учетных записей ServiceAccount можно вывести точно так же, как вы делаете это с другими ресурсами:
$ kubectl get sa
Текущее пространство имен содержит учетную запись по умолчанию ServiceAccount. При необходимости могут быть добавлены дополнительные учетные записи служб. Каждый модуль связан ровно с одной учетной записью службы, но несколько модулей могут использовать одну и ту же учетную запись. Как видно на рисунке, модуль может использовать учетную запись ServiceAccount только из того же пространства имен.
Для того чтобы позволить приложениям запрашивать хранилище в кластере Kubernetes без необходимости иметь дело со спецификой инфраструктуры, были введены два новых ресурса. Это постоянный том (PersistentVolume) и заявка на постоянный том (PersistentVolumeClaim). Эти имена могут вводить в заблуждение, поскольку, как вы видели в предыдущих томах, даже обычные тома Kubernetes могут использоваться для постоянного хранения данных. Использовать постоянный том PersistentVolume внутри модуля немного сложнее, чем использовать обычный том модуля, на рисунке показано каким образом связаны между собой модули, заявки на постоянный том PersistentVolumeClaim, постоянные тома PersistentVolume и фактическое базовое хранилище.
Конечные точки служб (Endpoints) Kubernetes используются для подключения к службам, находящимся за пределами кластера. Иногда через функционал служб Kubernetes требуется обеспечить доступ к внешним службам, чтобы она перенаправляла подключения на внешние IP-адреса и порты, что позволяет использовать преимущества и балансировки нагрузки служб и обнаружения служб. Клиентские модули, работающие в кластере, могут подключаться к внешней службе так же, как и к внутренним службам.
Службы (Service) не связываются с модулями напрямую. Вместо этого между ними находится ресурс конечных точек (Endpoints). Ресурс Endpoints – это список IP-адресов и портов, предоставляющих доступ к службе. Ресурс конечных точек похож на любой другой ресурс Kubernetes, поэтому можно вывести его основную информацию с помощью команды kubectl get:
$ kubectl get endpoints kubia
Если создать службу без селектора модулей, то Kubernetes не создаст ресурс конечных точек. Поэтому, необходимо вручную создать ресурсы Service и Endpoints и указать список конечных точек для службы. (далее…)
0