Статьи о Kubernetes Pod: вы легко сможете играть в Pod

задняя часть Kubernetes
Статьи о Kubernetes Pod: вы легко сможете играть в Pod

Эта статья участвовала в приказе о созыве Haowen, нажмите, чтобы просмотреть:Заявки на бэк-энд и фронт-энд с двумя треками, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!

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

在这里插入图片描述

1. Обзор модуля

1.1 Что такое поды?

PodЯвляется атомарным объектом в Kubernetes, базовой структурной единицей.

PodПредставляет набор запущенных контейнеров в кластере. Поды обычно создаются для запуска одного главного контейнера. Поды также могут запускать дополнительные контейнеры sidecar для реализации дополнительных функций, таких как ведение журнала. (Например: в Service Mesh он существует вместе с приложениемistio-proxy,istio-initконтейнер)

ОдинPodОн может содержать несколько контейнеров (другие контейнеры служат функциональными дополнениями), отвечающих за обработку томов данных, ключей и настройку контейнеров.在这里插入图片描述

1.2 Зачем вводить понятие Pod?

Причина 1: Kubernetes масштабируется

Kubernetes не имеет прямого отношения к контейнерам, единственные ресурсы, к которым пользователи Kubernetes могут получить доступ, — это поды, а поды могут содержать несколько контейнеров. Когда мы используем kubectl для выполнения различных команд для работы с различными ресурсами в Kubernetes, мы не можем напрямую управлять контейнерами и часто полагаемся на поды.

Kubernetes — не единственная среда выполнения контейнеров, поддерживающая Docker.Чтобы сделать Kubernetes не привязанным к конкретной технологии выполнения контейнеров, а поддерживать замену различных технологий выполнения контейнеров без перекомпиляции исходного кода, точно так же, как введение интерфейса в качестве уровня абстракции в нашем объектно-ориентированном дизайне, мы вводим абстракцию слой между Kubernetes и средой выполнения контейнера, интерфейс среды выполнения контейнера (CRI: Container Runtime Interface).在这里插入图片描述

С помощью уровня абстракции CRI Kubernetes не полагается на конкретную базовую технологию реализации среды выполнения контейнеров, а напрямую управляет подом, а под управляет несколькими пользовательскими бизнес-контейнерами, которые тесно связаны с бизнесом.Эта архитектура более удобна для Расширение Кубернета.

Причина 2: Простота управления

Предполагая, что Kubernetes не имеет концепции Pod, а напрямую управляет контейнерами, некоторые контейнеры должны быть тесно связаны по своей природе.Например, в ELK сбор журналов Filebeat должен быть тесно развернут с приложением. Если тесно связанный набор контейнеров рассматривается как единица, предположим, что один из контейнеров умирает, как следует определить состояние этой единицы в это время? Следует ли понимать это как общую смерть или индивидуальную смерть?

Причина, по которой на этот вопрос нелегко ответить, заключается в том, что не существует единого способа представления состояния всей группы контейнеров, поскольку она содержит логическую единицу этой группы бизнес-контейнеров.Это концепция Pod, представленная Kubernetes, и у каждого пода есть Kubernetes. Контейнер паузы, поставляемый с системой, предназначен для введения паузы, стандартного контейнера системы Kubernetes, который не имеет ничего общего с бизнесом и функционирует аналогично процессу демона в операционной системе Linux. состояние контейнера паузы представляет состояние всей группы контейнеров.在这里插入图片描述Для этих контейнеров, которые должны быть тесно связаны по своей природе, их можно поместить в один и тот же модуль, чтобы планировать, расширять, совместно использовать ресурсы и управлять жизненным циклом с модулем как наименьшей единицей.

Причина 3: Общение, совместное использование ресурсов

Несколько бизнес-контейнеров в поде совместно используют IP-адрес контейнера Pause и тома, прикрепленного к контейнеру Pause, что не только упрощает связь между тесно связанными бизнес-контейнерами, но и решает проблему обмена файлами между ними.

Одно и то же пространство имен может взаимодействовать с локальным хостом, может совместно использовать хранилище и т. д.

1.3 Какие преимущества может принести Pod?

Какие преимущества это может нам принести после выяснения происхождения Pod?

  • Как сервисная единица, которая может работать независимо, Pod упрощает развертывание приложений и обеспечивает удобство управления развертыванием приложений с более высоким уровнем абстракции.
  • Будучи самым маленьким экземпляром приложения, Pod может работать независимо, поэтому его можно легко развернуть, горизонтально расширить и свернуть, а также облегчить планирование управления и распределение ресурсов.
  • Контейнеры в поде используют одно и то же пространство данных и сетевых адресов, а между подами также осуществляется унифицированное управление ресурсами и их распределение.

2. Базовое использование Pod

либо по командеkubectl, или графический интерфейс управления Dashboard неотделим от определения файла списка ресурсов. Если вы используете графический интерфейс управления Dashboard для работы, он в конечном итоге основан на команде kubectl.Здесь только команда kubectl используется для управления модулем.

Для получения дополнительных инструкций по команде kubectl вы можете обратиться к официальной документации:Это особенное.IO/docs/refer E…

В манифесте ресурса Pod есть несколько важных свойств:apiVersion,kind,metadata,specтак же какstatus. вapiVersionа такжеkindявляется относительно фиксированным.statusэто состояние во время выполнения, поэтому самое главноеmetadataа такжеspecдве части.

(Определение списка ресурсов Kubernetes см. в предыдущей статье:Список ресурсов Kubernetes: как создавать ресурсы?)

Сначала определите простой файл ресурсов Pod с именем frontend-pod.yml:

Pod в примере определяется в тесте пространства имен, поэтому параметры, определяющие пространство имен, участвуют в следующих командах выполнения.-n test. Если он определен в пространстве имен по умолчанию default, нет необходимости указывать параметр -n для выполнения.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  namespace: test	# 如果没有命名空间test，需提前创建。也可以使用默认命名空间default，即：namespace属性标签可以不定义
  labels:
    app: frontend
spec:
  containers:
  - name: frontend
    image: xcbeyond/vue-frontend:latest		# 发布在DockerHub中的镜像
    ports:
      - name: port
        containerPort: 80
        hostPort: 8080

можно использовать командуkubectl explain podЧтобы просмотреть конкретное использование и значение каждого тега атрибута.

[xcbeyond@bogon ~]$ kubectl explain pod
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object>
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status	<Object>
     Most recently observed status of the pod. This data may not be up to date.
     Populated by the system. Read-only. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

2.1 Создать

Создавайте модули на основе файлов манифеста ресурсов,kubectl create -f <filename>:

[xcbeyond@localhost ~]$ kubectl create -f frontend-pod.yml
pod/frontend created

2.2 Просмотр статуса

После создания пода, если вы хотите узнать текущий статус пода, вы можете запустить командуkubectl get pods -n <namespace>Проверять:

(Для пространства имен по умолчанию параметр -n указывать не нужно. Если он не по умолчанию, необходимо указать конкретное пространство имен, иначе запрос будет недоступен.)

[xcbeyond@localhost ~]$ kubectl get pods -n test
NAME       READY   STATUS    RESTARTS   AGE
frontend   1/1     Running   0          36s

2.3 Просмотр конфигурации

Если вы хотите узнать конфигурацию работающего пода, вы можете передать командуkubectl get pod <pod-name> -n <namespace> -o <json|yaml>Проверять:

(параметр -o используется для указания формата выходной конфигурации, формат json, yaml)

На этом этапе посмотрите на результаты в рабочем состоянии, которое содержит множество свойств, нам нужно сосредоточиться только на ключевых свойствах.

[xcbeyond@localhost ~]$ kubectl get pod frontend -n test -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-11-19T08:33:20Z"
  labels:
    app: frontend
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
      f:spec:
        f:containers:
          k:{"name":"frontend"}:
            .: {}
            f:image: {}
            f:imagePullPolicy: {}
            f:name: {}
            f:ports:
              .: {}
              k:{"containerPort":80,"protocol":"TCP"}:
                .: {}
                f:containerPort: {}
                f:hostPort: {}
                f:name: {}
                f:protocol: {}
            f:resources: {}
            f:terminationMessagePath: {}
            f:terminationMessagePolicy: {}
        f:dnsPolicy: {}
        f:enableServiceLinks: {}
        f:restartPolicy: {}
        f:schedulerName: {}
        f:securityContext: {}
        f:terminationGracePeriodSeconds: {}
    manager: kubectl-create
    operation: Update
    time: "2020-11-19T08:33:20Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"ContainersReady"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Initialized"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Ready"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
        f:containerStatuses: {}
        f:hostIP: {}
        f:phase: {}
        f:podIP: {}
        f:podIPs:
          .: {}
          k:{"ip":"172.18.0.5"}:
            .: {}
            f:ip: {}
        f:startTime: {}
    manager: kubelet
    operation: Update
    time: "2020-11-23T08:10:40Z"
  name: frontend
  namespace: test
  resourceVersion: "28351"
  selfLink: /api/v1/namespaces/test/pods/frontend
  uid: be4ad65c-e426-4110-8337-7c1dd542f647
spec:
  containers:
  - image: xcbeyond/vue-frontend:latest
    imagePullPolicy: Always
    name: frontend
    ports:
    - containerPort: 80
      hostPort: 8080
      name: port
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-bbmj5
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: minikube
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-bbmj5
    secret:
      defaultMode: 420
      secretName: default-token-bbmj5
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-11-19T08:33:20Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-11-23T08:10:40Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2020-11-23T08:10:40Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2020-11-19T08:33:20Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://84d978ee70d806d38b9865021d9c68881cf096960c7eb45e87b3099da85b4f6d
    image: xcbeyond/vue-frontend:latest
    imageID: docker-pullable://xcbeyond/vue-frontend@sha256:aa31cdbca5ca17bf034ca949d5fc7d6e6598f507f8e4dad481e050b905484f28
    lastState: {}
    name: frontend
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2020-11-23T08:10:40Z"
  hostIP: 172.17.0.2
  phase: Running
  podIP: 172.18.0.5
  podIPs:
  - ip: 172.18.0.5
  qosClass: BestEffort
  startTime: "2020-11-19T08:33:20Z"

2.4 Просмотр журналов

Если вы хотите просмотреть стандартный журнал вывода, вы можете использовать командуkubectl logs <pod-name> -n <namespace>Проверять:

[xcbeyond@localhost ~]$ kubectl logs frontend -n test

Если в поде несколько контейнеров, для просмотра логов конкретного контейнера необходимо указать имя контейнера.kubectl logs <pod-name> -c <container-name>

2.5 Изменить конфигурацию

Если вы хотите изменить созданный модуль, например изменить метку, есть следующие способы:

(1) пройтиКоманды управления тегамиkubectl labelУстановите или обновите метки объекта ресурса.

Этот метод предназначен только для модификации этикетки.

по командеkubectl get pods -n <namespace> --show-labelsПросмотреть теги:

[xcbeyond@localhost ~]$ kubectl get pods -n test --show-labels
NAME       READY   STATUS    RESTARTS   AGE   LABELS
frontend   1/1     Running   0          4d    app=frontend

по командеkubectl label pod <pod-name> -n <namespace> <key=value>Добавить ярлык:

[xcbeyond@localhost ~]$ kubectl label pod frontend -n test tir=frontend
pod/frontend labeled
[xcbeyond@localhost ~]$ kubectl get pods -n test --show-labels
NAME       READY   STATUS    RESTARTS   AGE    LABELS
frontend   1/1     Running   0          4d1h   app=frontend,tir=frontend

по командеkubectl label pod <pod-name> -n <namespace> <key=new-value> --overwriteОтредактировать тэги:

[xcbeyond@localhost ~]$ kubectl label pod frontend -n test tir=unkonwn --overwrite
pod/frontend labeled
[xcbeyond@localhost ~]$ kubectl get pods -n test --show-labels
NAME       READY   STATUS    RESTARTS   AGE    LABELS
frontend   1/1     Running   0          4d1h   app=frontend,tir=unkonwn

(2) По командеkubectl apply -f <filename>команда для обновления конфигурации.

(3) По командеkubectl edit -f <filename> -n <namespace>команда для обновления конфигурации онлайн.

(4) По командеkubectl replace -f <filename> -n <namespace> --forceЗаказобязательныйЗамените ресурсный объект.

На самом деле, сначала удалите перед заменой.

[xcbeyond@localhost ~]$ kubectl replace -f frontend-pod.yml --force
pod "frontend" deleted
pod/frontend replaced

2.6 Удалить

по командеkubectl delete (-f <filename> | pod [<pod-name> | -l label]) -n <namespace>удалить.

[xcbeyond@localhost ~]$ kubectl delete pod frontend -n test
pod "frontend" deleted

3. Жизненный цикл стручка

PodПромежуток времени объекта от его создания до его прекращения называется временем жизни пода. В течение этого времени,Podбудет находиться в нескольких различных состояниях и выполнять некоторые действия. Среди них создайте основной контейнер (main container), другие необязательные операции включают запуск контейнера инициализации (init container), хук после запуска контейнера (post start hook), определение жизнеспособности контейнера (liveness probe), зонд готовности (readiness probe) и концевой крючок перед контейнером (pre stop hook) и т. д. выполнение этих операций зависит отPodОпределение. Как показано ниже:在这里插入图片描述

Podизstatusполе представляет собойPodStatusОбъект,PodStatusсуществует одинphaseполе.

Либо создан вручную, либо черезDeploymentПодождите, пока контроллер будет создан,PodОбъект всегда находится на следующих стадиях своего жизненного цикла (phase)один:

  • вешать (Pending):API ServerсоздалPod, и был депонирован вetcd, но он не запланирован или все еще находится в процессе загрузки образа из репозитория.
  • Бег (Running):PodВсе контейнеры были созданы, запланированы для узла, и все контейнеры былиkubeletСоздан, и хотя бы один контейнер запущен, запущен или перезапущен.
  • успех(Succeeded):PodПосле того, как все контейнеры будут успешно выполнены, выйдите и завершите работу и не будете перезапускаться.
  • потерпеть неудачу(Failed):PodВсе контейнеры вышли, и по крайней мере один контейнер вышел из-за сбоя. То есть контейнер начинается с非0Состояние завершено или отключено системой.
  • неизвестный(Unknown): Почему-тоApi Serverне могу получитьPodИнформация о состоянии объекта может быть связана с невозможностью связи сkubeletИз-за связи (плохая сетевая связь).

在这里插入图片描述

3.1 Процесс создания пода

PodЭто базовая единица в Kubernetes. Понимание процесса ее создания очень полезно для понимания ее жизненного цикла. На следующем рисунке показаноPodТипичный процесс создания объектов ресурсов.在这里插入图片描述

(1) Пользователь проходитkubectlили другиеAPIклиент представилPod SpecдаватьAPI Server. (создать под)

(2)API Serverпопробуй поставитьPodНапишите информацию об объектеetcdВ системе хранения после завершения операции записиAPI ServerКлиенту будет возвращено подтверждающее сообщение.

(3)API Serverначать обратную связьetcdизменения состояния в .

(4) Всеkubernetesиспользуются компоненты“watch”механизм отслеживания проверокAPI Serverсопутствующие изменения.

(5)kube-scheduler(планировщик) через его“watcher”пониматьAPI Serverсоздал новыйPodобъект, но еще не привязан ни к одному рабочему узлу.

(6)kube-schedulerзаPodОбъект выбирает рабочий узел и обновляет полученную информацию доAPI Server.

(7) Информация о результатах планирования задается какAPI ServerОбновить доetcdсистема хранения иAPI Serverтоже начал об этом сообщатьPodРезультат планирования объекта.

(8)Podна целевом рабочем узле, который должен быть запланирован дляkubeletпопробуйте вызвать текущий узелDockerЗапустите контейнер и верните полученный статус контейнера вAPI Server.

(9)API ServerбудетPodИнформация о состоянии сохраняетсяetcdв системе.

(10) вetcdУбедившись, что операция записи успешно завершена,API ServerОтправьте подтверждение соответствующемуkubelet, через которые будут приниматься события.

3.2 Важные процессы

3.2.1 Контейнер инициализации

Инициализировать контейнер (init container) — это контейнер специального назначения, используемый для запуска одного или нескольких контейнеров инициализации перед запуском контейнера приложения (контейнера приложения) для выполнения предварительных условий, требуемых контейнером приложения.在这里插入图片描述

Контейнер инициализатора очень похож на обычный контейнер, но имеет следующие уникальные характеристики:

  • Контейнер инициализации всегда работает до тех пор, пока не завершится успешно.
  • Каждый контейнер инициализации должен успешно завершиться до запуска следующего контейнера инициализации.

Согласно политике перезапуска пода (restartPolicy), когда init-контейнер не запускается и устанавливаетrestartPolicyЕсли установлено значение «Никогда», модуль не запустится и не перезапустится; вместо этого установитеrestartPolicyЕсли установлено значение «Всегда», модуль будет автоматически перезапущен системой.

Если Pod указывает несколько контейнеров инициализации, эти контейнеры инициализации запускаются по одному последовательно. Следующий контейнер инициализации может быть запущен только после успешного запуска текущего контейнера инициализации. Когда все инициализированные контейнеры запущены, Kubernetes инициализирует Pod и запускает контейнер приложения.

3.2.2 Обнаружение контейнера

обнаружение контейнера (container probe)ДаPodВажная повседневная задача в жизненном цикле объекта.kubeletПериодически выполнять диагностику состояния работоспособности контейнеров, которая выполняется процессором контейнера (handler) определять.KubernetesПоддерживает три процессора дляPodЗонд:

  • ExecAction: Вызывается операция выполнения указанной команды в контейнере и ее диагностики по возвращаемому коду состоянияExecобнаружение, код состояния0Указывает на успех, в противном случае это нездорово.
  • TCPSocketAction: по определенномуTCPПорт пытается установить соединение для диагностики. Если порт может быть успешно открыт, это нормально. В противном случае он находится в неработоспособном состоянии.
  • HTTPGetAction: перейти к контейнеруIPОбозначение назначенного порта адресаpathположить началоHTTP GETЗапрос на диагностику, код ответа2xxили3xxуспешно, в противном случае это провал.

Есть три возможных результата любого метода обнаружения:“Success”（成功）,“Failure”（失败）,“Unknown”（未知）,ТолькоsuccessУказывает, что проверка прошла успешно.

Существует два типа контейнерных зондов:

  • Зонд живости (livenessProbe): используется для определения того, «работает» ли контейнер (Running)условие. Как только такие тесты терпят неудачу,kubeletуничтожит контейнер и в соответствии с политикой перезапуска (restartPolicy), чтобы решить, перезапускать его или нет, состояние контейнера по умолчанию без определения живучести: "Success".
  • Зонд готовности (readinessProbe): используется для определения того, готов ли контейнер и может ли он предоставлять внешние службы. Контейнер, который не прошел инструментирование, означает, что он еще не готов, и контроллер конечной точки (например,Serviceобъект) сделает этоIPиз всех матчей к этомуPodобъектServiceУдалено из списка конечных точек объекта. После прохождения теста будетIPдобавлен в список конечных точек.

Когда использовать тесты живучести и готовности?

Тесты живости не обязательно требуются, если процесс в контейнере может привести к сбою, если он столкнется с проблемой или окажется неработоспособным.kubeletбудет основываться наPodизrestartPolicyАвтоматизируйте правильное действие.

Если вы хотите, чтобы контейнер был убит и перезапущен в случае сбоя зонда, укажите зонд живости и укажитеrestartPolicyзаAlwaysилиOnFailure.

Если вы хотите начать отправку на зонд только после успешного выполнения зондаPodДля отправки трафика укажите пробу готовности. В этом случае проба готовности может быть такой же, как проба живучести, ноspecНаличие зонда готовности вPodЗапустится без получения трафика и начнет получать трафик только в случае успешного зондирования.

Если вы хотите, чтобы контейнер мог обслуживать себя, вы можете указать проверку готовности, которая проверяет конечную точку, отличную от проверки живучести.

Примечание: если вы хотите толькоPodЕсли запрос может быть исключен при его удалении, не обязательно использовать пробу готовности;Podчас,Podавтоматически ставит себя в незавершенное состояние, независимо от наличия пробы готовности. во время ожиданияPodКогда контейнер внутри остановлен,PodЕще в незавершенном состоянии.

4. Планирование подов

В Kubernetes мы редко создаем Pod напрямую, в большинстве случаев мы используем RC (Replication Controller), Deployment, DaemonSet, Job и другие контроллеры для завершения создания, планирования и полного жизненного цикла набора копий Pod. .

В самой ранней версии Kubernetes было не так много контроллеров реплики пода, был только один контроллер реплики пода RC.Этот контроллер был разработан и реализован таким образом: RC был независим от пода, которым он управлял, и имел слабосвязанную связь через метки Label.Контролируйте создание и уничтожение целевых экземпляров Pod.С развитием Kubernetes в RC появился новый преемник, Deployment, который используется для более автоматического завершения развертывания, обновления версии, отката и других функций Pod копии.

Строго говоря, преемником RC на самом деле является не Deployment, а ReplicaSet, поскольку ReplicaSet дополнительно повышает гибкость селектора меток RC. Раньше селектор меток RC мог выбирать только одну метку, а в ReplicaSet есть селектор коллективных меток, который может выбирать несколько меток Pod, как показано ниже:

selector:
  matchLabels:
    tier: frontend
  matchExpressions:
    - {key: tier, operator: In, values: [frontend]}

В отличие от RC, ReplicaSet предназначен для управления несколькими репликами Pod с разными метками. Обычный сценарий приложения заключается в том, что приложение APP в настоящее время выпустило две версии v1 и v2.Пользователь хочет, чтобы количество копий Pod приложения оставалось равным 3, а Pod версий v1 и v2 можно было включить в в то же время.Для этого можно использовать ReplicaSet.Control, записанный следующим образом:

selector:
  matchLabels:
    version: v2
  matchExpressions:
    - {key: version, operator: In, values: [v1,v2]}

На самом деле последовательное обновление Kubernetes достигается за счет умелого использования этой функции ReplicaSet, а Deployment также использует ReplicaSet для реализации функции автоматического управления репликами Pod.

4.1 Полностью автоматическое планирование

Одной из основных функций Deployment или RC является автоматическое развертывание нескольких копий приложения-контейнера и постоянный мониторинг количества копий, всегда поддерживая указанное пользователем количество копий в кластере.

Пример:

(1) Ниже приведен пример конфигурации развертывания. Используя этот файл конфигурации манифеста ресурса nginx-deployment.yml, можно создать набор реплик. Этот набор реплик создаст 3 модуля Nginx:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
           - name: http
             containerPort: 80

(2) Выполнитьkubectl createКоманда создает это развертывание:

[xcbeyond@localhost ~]$ kubectl create -f nginx-deployment.yml -n test
deployment.apps/nginx-deployment created

(3) Выполнитьkubectl get deploymentsКоманда для проверки статуса развертывания:

[xcbeyond@localhost ~]$ kubectl get deployments -n test
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           17m

Эта структура указывает на то, что развертывание создало 3 реплики, и все реплики обновлены.

(4) Путем выполненияkubectl get rsа такжеkubectl get podsКоманда может просматривать информацию о созданных ReplicaSet (RS) и Pod:

[xcbeyond@localhost ~]$ kubectl get rs -n test
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-86b8cc866b   3         3         3       24m
[xcbeyond@localhost ~]$ kubectl get pods -n test
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86b8cc866b-7rqzt   1/1     Running   0          27m
nginx-deployment-86b8cc866b-k2rwp   1/1     Running   0          27m
nginx-deployment-86b8cc866b-rn7l7   1/1     Running   0          27m

С точки зрения стратегии планирования, эти три модуля Nginx автоматически планируются Kubernetes. Какой узел, на котором они запланированы, полностью рассчитывается расписанием на мастере после серии вычислений. Пользователи не могут вмешиваться в процесс планирования и планирование. .

В дополнение к использованию автоматического планирования, Kubernetes также предоставляет множество стратегий планирования для пользователей, которые могут фактически выбирать, пользователям нужно только использовать их в определении Pod.NodeSelector,NodeAffinity,PodAffinityБолее подробные параметры политики планирования, такие как , выселение Pod и т. д., могут завершить точное планирование Pod.

4.2 NodeSelector: направленное планирование

Планировщик на Kubernetes Master (kube-scheduler) отвечает за планирование подов. Весь процесс планирования, наконец, вычисляет оптимальный целевой узел для каждого пода, выполняя серию сложных алгоритмов. Этот процесс завершается автоматически, и мы не можем знать, что под в конечном итоге будет запланирован. узел.

В реальных сценариях может потребоваться запланировать Pod для некоторых указанных узлов.Вы можете использовать метку узла (Label) и PodnodeSelectorАтрибуты совпадают для достижения вышеуказанной цели. Например, если вы хотите запланировать базу данных MySQL на целевой узел SSD-диска, шаблон Pod вNodeSelectorСвойства вступают в игру.

Пример:

(1) Выполнитьkubectl label nodes <node-name> <label-key>=<label-value>Команда добавляет метку к указанному узлу.

Например, добавьте метку к узлу SSD-диска.disk-type=ssd:

$ kubectl label nodes k8s-node-1 disk-type=ssd

(2) Добавить в список ресурсов определение PodnodeSelectorАтрибуты.

apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    env: test
spec:
  containers:
  - name: mysql
    image: mysql
  nodeSelector:
    disk-type: ssd

(3) Путем выполненияkubectl get pods -o wideкоманду, чтобы увидеть, вступит ли она в силу.

Помимо того, что пользователи могут добавлять метки в Node, Kubernetes также предопределяет некоторые метки для Node, которые пользователям удобно использовать напрямую.Предопределенные метки:

  • kubernetes.io/arch: пример,kubernetes.io/arch=amd64. Полезно в таких ситуациях, как смешанная рука и узлы x86.
  • kubernetes.io/os: пример,kubernetes.io/os=linux. Полезно, когда в кластере есть узлы с разными операционными системами (например: узлы со смешанными операционными системами Linux и Windows).
  • beta.kubernetes.io/os (устарело)
  • beta.kubernetes.io/arch (устарело)
  • kubernetes.io/имя хоста: пример,kubernetes.io/hostname=k8s-node-1.
  • ...

Для дополнительной справки:Это особенное.IO/docs/refer E…

NodeSelectorС помощью метода меток просто реализуется метод ограничения узлов, в которых находится Pod.Это кажется простым и совершенным, но в реальной среде он может столкнуться со следующими неприятными проблемами:

(1) ЕслиNodeSelectorЧто делать, если выбранная метка не существует или не соответствует условиям, например, когда эти целевые узлы не работают или ресурсов недостаточно?

(2) Что делать, если вы хотите выбрать несколько подходящих целевых узлов, например, узлы с SSD-дисками или узлы со сверхскоростными жесткими дисками? Представление KubernetesNodeAffinity(сходство узлов) для решения вышеуказанной проблемы.

(3) Сходство между разными модулями. Например, MySQL и Redis не могут быть запланированы для одного и того же целевого узла, или два разных модуля должны быть запланированы для одного и того же узла для выполнения особых требований, таких как локальный общий доступ к файлам или связь по локальной сети.PodAffinityпроблема, которую нужно решить.

4.3 NodeAffinity: планирование привязки узлов

NodeAffinity, является стратегией планирования сходства узлов и используется для решенияNodeSelectorНовая стратегия планирования, которая недостаточна.

В настоящее время существует два способа выражения:

  • RequiredDuringSchuedlingIgnoredDuringExecution:должен встретитьТолько указанные правила могут планировать поды на Node (функция похожа на nodeSelector, но использует другой синтаксис), что эквивалентно жесткому ограничению.
  • PreferredDuringSchedulingIgnoredDuringExection:подчеркиватьприоритетное удовлетворениеУкажите правило, планировщик попытается запланировать Pod на Node, но это не обязательно, что эквивалентно мягкому лимиту. Несколько правил приоритета также могут устанавливать значения веса для определения порядка выполнения.

lgnoredDuringExecutionНеявно, вPodПосле того, как ресурс назначен узлу на основе правила привязки к узлу, когда метка узла изменяется и больше не соответствует правилу привязки к узлу, планировщик не будетPodОбъекты удаляются из этого узла. следовательно,NodeAffinityтолько для новыхPodОбъект вступает в силу.

Привязка узлов доступна черезpod.spec.affinity.nodeAffinityуказать.

Пример:

настраиватьNodeAffinityПравила составления расписания следующие:

  • requiredDuringSchedulingIgnoredDuringExecutionТребуется для работы только на узлах amd64 (kubernetes.io/arch В amd64).
  • preferredDuringSchedulingIgnoredDuringExecutionТребуется максимально запустить на узле с типом диска ssd (disk-type In ssd).

pod-with-node-affinity.ymlОпределяется следующим образом:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - amd64
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disk-type
            operator: In
            values:
            - ssd
  containers:
  - name: with-node-affinity
    image: busybox

Как видно из приведенного выше примера с использованиемInоператор.NodeAffinityОператоры, поддерживаемые синтаксисом, включают:In,NotIn,Exists,DoesNotExist,Gt,Lt. ты можешь использоватьNotInа такжеDoesNotExistРеализовать антиаффинное поведение узла, то есть реализовать функцию проверки.

NodeAffinityРекомендации по определениям правил следующие:

  • Если также указаноnodeSelectorа такжеnodeAffinity, то оба должны быть удовлетворены, чтобы запланировать Pod на указанный узел.
  • еслиnodeAffinityнесколько указанныхnodeSelectorTerms, то один из них может успешно совпадать.
  • если вnodeSelectorTermsимеет более одногоmatchExpressions, то узел должен удовлетворять всемmatchExpressionsдля запуска пода.

Если указать несколькоnodeSelectorTermsСвязанныйmatchExpressions,

4.4 PodAffinity: стратегия планирования привязки подов и взаимного исключения

Соответствие и взаимное исключение между модулями были введены, начиная с версии Kubernetes 1.4. Эта функция позволяет пользователям ограничивать узлы, которые может запускать под, с другой точки зрения: оценка и планирование выполняются в соответствии с меткой пода, работающего на узле, а не меткой узла, и двумя условиями узла и Pod должны быть согласованы. Это правило можно описать так: если один или несколько подов, отвечающих условию Y, работают на узле с меткой X, то под должен работать на этом узле.

а такжеNodeAffinityРазница в том, что Pod принадлежит к пространству имен, поэтому условие Y выражает селектор меток в одном или во всех пространствах имен.

а такжеNodeAffinityТо же самое, настройки привязки и взаимного исключения Pod такжеrequiredDuringSchedulingIgnoredDuringExecutionа такжеPreferredDuringSchedulingIgnoredDuringExection.

Сходство Pod доступно черезpod.spec.affinity.podAffinityуказать.

4.5 Пороки и допуски

Привязка узлов NodeAffinity — это атрибут, определенный в Pod, который позволяет планировать запуск Pod на определенных узлах. а такжеTaints делает прямо противоположное, он говорит Node отклонить запуск подов.

Заражения необходимо использовать в сочетании с допуском, чтобы позволить модулям избегать некоторых неподходящих узлов. После настройки одного или нескольких дефектов на узле он не может работать на этих узлах, если только модуль явно не объявит, что он может допускать эти заражения. Допуск — это свойство пода, которое позволяет поду работать на узле, отмеченном Taint.

быть пригодным для использованияkubectl taintКоманда для установки информации о заражении для узла:

[xcbeyond@localhost ~]$ kubectl taint nodes node1 key=value:NoSchedule

4.6 Планирование приоритета пода

В Kubernetes версии 1.8 была введена политика планирования, основанная на вытеснении приоритета пода. В настоящее время Kubernetes попытается выпустить поды с низким приоритетом на целевом узле, чтобы освободить место в ресурсах для размещения подов с высоким приоритетом. Метод планирования называется «упреждающее планирование».

Его можно определить по следующим размерам:

  • Приоритет: приоритет
  • QoS: уровень качества обслуживания
  • Другие системные показатели

Пример:

(1) Создайте PriorityClasses, которые не принадлежат ни к какому пространству имен:

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
  value: 1000000
  globalDefault: false
  description: "this priority class should be used for XYZ service pods only."

Описание: Определите приоритет с именем high-priority, приоритет равен 1000000, чем больше число, тем выше приоритет. Номера с приоритетом более 100 миллионов зарезервированы системой для присвоения компонентам системы.

(2) Обратитесь к приоритету пода, определенному выше в поде:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  namespace: test
  labels:
    app: frontend
spec:
  containers:
  - name: frontend
    image: xcbeyond/vue-frontend:latest
    ports:
      - name: port
        containerPort: 80
        hostPort: 8080
    priorityClassName: high-priority  # 引用Pod优先级

Стратегии планирования, использующие вытеснение с приоритетом, могут привести к тому, что некоторые поды никогда не будут успешно запланированы. Приоритетное планирование не только увеличивает сложность системы, но и может привнести дополнительные факторы нестабильности. Поэтому, как только возникает ситуация нехватки ресурсов, первое, что нужно рассмотреть, — это расширение кластера.Если расширение невозможно, рассмотрите функцию планирования с контролируемым приоритетом, например, объединение ограничений квоты ресурсов на основе пространства имен для ограничения произвольного вытеснения приоритета.

4.7 DaemonSet: запланируйте Pod на каждом узле

DaemonSet — это новый объект ресурса в Kubernetes версии 1.2.Используется для управления экземплярами реплик, которые запускают только один модуль на каждом узле в кластере.. Как показано ниже:

[Не удалось передать изображение по внешней ссылке, исходный сайт может иметь механизм защиты от пиявки, рекомендуется сохранить изображение и загрузить его напрямую (img-3UJhzRij-1611625546431) (./DaemonSet example.jpg)]

Некоторые типичные варианты использования DaemonSet:

  • Запустите демон кластера на каждом узле. Например: запуск процесса Daemon хранилища GlusterFS или хранилища Ceph.
  • Запустите демон сбора журналов на каждом узле. Например: запустите программу сбора журналов, Fluentd или Logstach.
  • Запустите демон мониторинга на каждом узле. Например: сбор текущих данных о производительности узла, Prometheus Node Exporter, collectd и т. д.

4.8 Работа: групповое планирование

JobОтвечает за пакетирование кратковременных разовых задач, то есть задач, которые выполняются только один раз, и гарантирует успешное завершение одного или нескольких подов пакетной задачи.

В зависимости от того, как реализованы пакетные задачи, к различным бизнес-сценариям применимы следующие типовые режимы:

  • Расширение на основе шаблона задания:

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

  • Очередь по каждому элементу работы:

    • Пользователям необходимо заранее подготовить службу очереди сообщений, такую ​​как rabbitMQ, которая является общедоступным компонентом, и каждый рабочий элемент может вставлять в нее сообщения задачи.
    • Пользователи могут создавать параллельные задания, которые необходимо применять к очереди сообщений, а затем использовать задачи из очереди сообщений и обрабатывать их до тех пор, пока сообщение не будет обработано.
    • В этом режиме пользователю необходимо заполнить по количеству пунктовspec.completions, количество параллельных.spec.parallelismОн может быть заполнен в соответствии с реальной ситуацией. В этом режиме задание завершится успешно, когда все задачи будут успешно выполнены.

  • Очередь с переменным количеством задач:

    • Пользователям необходимо заранее подготовить службу хранилища для сохранения рабочей очереди, например Redis. Каждый элемент может заполнять службу хранения сообщениями.
    • Пользователи могут запускать несколько параллельных заданий, применимых к рабочей очереди для обработки сообщений. Отличие от предыдущей очереди сообщений Rabbit заключается в том, что каждая задача Job может знать, что рабочая очередь пуста, и может успешно завершиться в это время.
    • В этом режимеspec.completionsНеобходимо установить 1, количество параллельных.spec.parallelismОн может быть заполнен в соответствии с реальной ситуацией. Пока одна из задач завершается успешно, задание завершается успешно.

  • Обычные статические задачи:

    Назначайте элементы задач статическим образом.

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

  • Непараллельное задание:

    Обычно задание запускает только один модуль, и как только модуль завершится нормально, задание завершится. (Если Pod неисправен, он будет перезапущен)

  • Параллельные задания с фиксированным количеством выполнений:

    Запускайте указанное количество модулей одновременно, пока указанное количество модулей не завершится успешно и задание не завершится.

  • Параллельное задание с очередью работ:

    • Пользователи могут указать количество параллельных модулей, и при успешном завершении любого модуля новые модули создаваться не будут.
    • Как только под успешно завершается, и все поды завершаются, задание завершается успешно.
    • Как только под успешно завершается, другие поды готовы к выходу.

4.9 Cronjob: запланированная задача

CronJob, запланированная задача, похожая на Cron в Linux.

Выражение времени, формат следующий:

Minutes Hours DayofMonth Month DayofWeek Year

  • Минуты: Минуты, целое число в допустимом диапазоне от 0 до 59. возможно, - * /эти 4 символа.

  • Часы: Часы, целое число в допустимом диапазоне от 0 до 23. возможно, - * /эти 4 символа.

  • DayofMonth: день месяца, допустимый диапазон — целое число от 0 до 31. возможно, - * / ? L W Cэти 8 символов.

  • Месяц: месяц, целое число в диапазоне от 1 до 12 или от января до декабря. возможно, - * /эти 4 символа.

  • DayofWeek: неделя, целое число в допустимом диапазоне от 1 до 7 или SUN-SAT, 1 означает воскресенье, 2 означает понедельник и т. д. возможно, - * / ? L C #эти 8 символов.

Например, чтобы выполнять задачу каждую 1 минуту, выражение Cron будет*/1 * * * *

Пример:

(1) Определите файл конфигурации ресурсов CronJobtest-cronjob.yml:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: test
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: hello
              image: busybox
              args:
                - /bin/sh
                - -c
                - date; echo hello from the Kubernetes cluster
          restartPolicy: OnFailure

(2) Выполнитьkubectl crateКоманда для создания CronJob:

[xcbeyond@localhost k8s]$ kubectl create -f test-cronjob.yml -n test
cronjob.batch/test created

(3) Выполнять каждую 1 минутуkubectl get cronjobКоманда проверяет статус задачи и обнаруживает, что она действительно запланирована каждую минуту:

[xcbeyond@localhost k8s]$ kubectl get cronjob test -n test
NAME   SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
test   */1 * * * *   False     1        61s             69s
[xcbeyond@localhost k8s]$ kubectl get cronjob test -n test
NAME   SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
test   */1 * * * *   False     2        7s              75s
[xcbeyond@localhost k8s]$ kubectl get cronjob test -n test
NAME   SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
test   */1 * * * *   False     3        28s             2m36s

воплощать в жизньkubectl delete cronjobкоманду удалить.

4.10 Пользовательский планировщик

Если вышеуказанные планировщики по-прежнему не могут удовлетворить некоторые уникальные требования, простые или сложные настраиваемые планировщики могут быть реализованы на любом языке.

5. Обновление модуля и откат

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

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

Если модуль создается посредством развертывания, вы можете изменить определение модуля развертывания (spc.template) или имя образа во время выполнения и применить его к объекту развертывания, после чего система сможет выполнить операцию автоматического обновления развертывания. Если в процессе обновления возникает ошибка, версию Pod можно восстановить с помощью операции отката.

5.1 Обновление развертывания

кnginx-deployment.ymlНапример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
           - name: http
             containerPort: 80

(1) Количество запущенных реплик Pod равно 3, проверьте статус Pod:

[xcbeyond@localhost k8s]$ kubectl get pod -n test
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86b8cc866b-7rqzt   1/1     Running   2          53d
nginx-deployment-86b8cc866b-k2rwp   1/1     Running   2          53d
nginx-deployment-86b8cc866b-rn7l7   1/1     Running   2          53d

(2) Теперь обновите версию nginx до nginx:1.9.1, которую можно выполнить, выполнивkubectl set imageКоманда устанавливает новый образ для развертывания:

[xcbeyond@localhost k8s]$ kubectl set image deployment/nginx-deployment  nginx=nginx:1.9.1 -n test
deployment.apps/nginx-deployment image updated

kubectl set image: обновить образ контейнера существующего объекта ресурса.

Другой способ обновления — использоватьkubectl editКоманда изменяет конфигурацию файла Deployment.

(3) В это время (в процессе обновления) проверьте статус модуля и обнаружите, что обновление выполняется:

[xcbeyond@localhost k8s]$ kubectl get pod -n test
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-79fbf694f6-kplgz   0/1     ContainerCreating   0          96s
nginx-deployment-86b8cc866b-7rqzt   1/1     Running             2          53d
nginx-deployment-86b8cc866b-k2rwp   1/1     Running             2          53d
nginx-deployment-86b8cc866b-rn7l7   1/1     Running             2          53d

В процессе обновления вы можете выполнитьkubectl rollout statusКоманда для просмотра процесса обновления файла Deployment.

(4) После завершения обновления проверьте статус модуля:

[xcbeyond@localhost k8s]$ kubectl get pod -n test
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-79fbf694f6-h7nfs   1/1     Running   0          2m43s
nginx-deployment-79fbf694f6-kplgz   1/1     Running   0          7m21s
nginx-deployment-79fbf694f6-txrfj   1/1     Running   0          2m57s

Если сравнить имена в списке статусов подов до и после завершения обновления, они изменились.

Проверьте образ, используемый модулем, который был обновлен до nginx:1.9.1:

[xcbeyond@localhost k8s]$ kubectl describe pod/nginx-deployment-79fbf694f6-h7nfs -n test
Name:         nginx-deployment-79fbf694f6-h7nfs
Namespace:    test
……
Containers:
  nginx:
    Container ID:   docker://0ffd43455aa3a147ca0795cf58c68da63726a3c77b40d58bfa5084fb879451d5
    Image:          nginx:1.9.1
    Image ID:       docker-pullable://nginx@sha256:2f68b99bc0d6d25d0c56876b924ec20418544ff28e1fb89a4c27679a40da811b
    Port:           80/TCP
……

Так как же Deployment завершает обновления Pod?

использоватьkubectl describe deployment/nginx-deploymentКоманда более подробно рассматривает процесс обновления развертывания:

При первоначальном создании развертывания система создала ReplicaSet (nginx-deployment-86b8cc866b) и создала 3 реплики Pod. При обновлении развертывания система создает новый набор реплик (nginx-deployment-79fbf694f6) и увеличивает количество реплик до 1, а затем сокращает старый набор реплик до 2. После этого система продолжает корректировать старый и новый наборы реплик один за другим в соответствии с той же стратегией обновления. Наконец, новый ReplicaSet запускает 3 копии новой версии Pod, а количество копий старого ReplicaSet уменьшается до 0.

Как показано ниже:在这里插入图片描述

воплощать в жизньkubectl describe deployment/nginx-deploymentКоманда для просмотра окончательной информации о развертывании:

[xcbeyond@localhost k8s]$ kubectl describe deployment/nginx-deployment -n test
Name:                   nginx-deployment
Namespace:              test
CreationTimestamp:      Thu, 26 Nov 2020 19:32:04 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 2
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-79fbf694f6 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  30m   deployment-controller  Scaled up replica set nginx-deployment-79fbf694f6 to 1
  Normal  ScalingReplicaSet  25m   deployment-controller  Scaled down replica set nginx-deployment-86b8cc866b to 2
  Normal  ScalingReplicaSet  25m   deployment-controller  Scaled up replica set nginx-deployment-79fbf694f6 to 2
  Normal  ScalingReplicaSet  25m   deployment-controller  Scaled down replica set nginx-deployment-86b8cc866b to 1
  Normal  ScalingReplicaSet  25m   deployment-controller  Scaled up replica set nginx-deployment-79fbf694f6 to 3
  Normal  ScalingReplicaSet  24m   deployment-controller  Scaled down replica set nginx-deployment-86b8cc866b to 0

воплощать в жизньkubectl get rsКоманда для просмотра конечного состояния двух наборов реплик:

[xcbeyond@localhost k8s]$ kubectl get rs -n test
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-79fbf694f6   3         3         3       39m
nginx-deployment-86b8cc866b   0         0         0       53d

В течение всего процесса обновления система будет следить за тем, чтобы были доступны как минимум два пода и не более четырех подов одновременно. Развертывания должны гарантировать, что только определенное количество модулей может быть недоступно в течение всего процесса обновления. По умолчанию развертывание гарантирует, что общее количество доступных подов равно как минимум необходимому количеству реплик (желаемых) минус 1, то есть не более 1 недоступного (maxUnreachable=1).

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

обновить стратегию

В определении развертывания вы можете передатьspec.strategyУказывает стратегию обновления Pod. В настоящее время поддерживаются две стратегии: Recreate (перестроение) и RollingUpdate (последовательное обновление).Значением по умолчанию является RollingUpdate.

  • **Восстановить:** Настройкиspec.strategy.type=Recrate, указывая на то, что когда развертывание обновляет поды, оно сначала уничтожит все запущенные поды, а затем создаст новые поды.
  • **Последовательное обновление:** Настройкиspec.strategy.type=RollingUpdate, указывая на то, что развертывание будет обновлять модули Pod один за другим в режиме непрерывного обновления. В то же время, установивspec.strategy.rollingUpdateдва параметра вmaxUnavailableа такжеmaxSurgeдля управления процессом непрерывного обновления.
    • spec.strategy.rollingUpdate.maxUnavailable: используется для указания максимального количества модулей в недоступном состоянии развертывания во время процесса обновления. Значение может быть конкретным числом или процентом от количества реплик, ожидаемых подом.
    • spec.strategy.rollingUpdate.maxSurge: используется для указания максимального значения части, в которой общее количество подов превышает ожидаемое количество копий подов в процессе развертывания, обновляющего поды. Значение может быть конкретным числом или процентом от количества реплик, ожидаемых подом.

5.2 Откат развертывания

По умолчанию история выпусков всех развертываний хранится в системе, чтобы мы могли откатиться в любое время. (Количество записей истории настраивается)

может быть выполненkubectl rollout undoКоманда завершает откат развертывания.

(1) Выполнитьkubectl rollout historyКоманда для проверки истории развертывания Deployment:

[xcbeyond@localhost k8s]$ kubectl rollout history deployment/nginx-deployment -n test
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none

Используется при создании развертывания--recordпараметры, вы можете увидеть команду для создания/обновления каждой версии в столбце CHANGE-CAUSE.

(2) Если вам нужно просмотреть подробную информацию об указанной версии, вы можете добавить--revision=<N>параметр:

[xcbeyond@localhost k8s]$ kubectl rollout history deployment/nginx-deployment --revision=2 -n test
deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:	app=nginx
	pod-template-hash=79fbf694f6
  Containers:
   nginx:
    Image:	nginx:1.9.1
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

(3) Во-первых, обновленная версия будет отозвана и выполнен откат до предыдущей версии, а именно: nginx:1.9.1->nginx:latest. воплощать в жизньkubectl rollout undoЗаказ:

[xcbeyond@localhost k8s]$ kubectl rollout undo deployment/nginx-deployment -n test
deployment.apps/nginx-deployment rolled back

Конечно, вы также можете использовать параметр --to-revision, чтобы указать откат до определенного номера версии.

(4) исполняемыйkubectl describe deployment/nginx-deploymentКоманда для просмотра всего процесса отката:

[xcbeyond@localhost k8s]$ kubectl describe deployment/nginx-deployment -n test
Name:                   nginx-deployment
Namespace:              test
CreationTimestamp:      Thu, 26 Nov 2020 19:32:04 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 3
Selector:               app=nginx
Replicas:               3 desired | 2 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:  nginx-deployment-79fbf694f6 (2/2 replicas created)
NewReplicaSet:   nginx-deployment-86b8cc866b (2/2 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  5m50s  deployment-controller  Scaled up replica set nginx-deployment-86b8cc866b to 1
  Normal  ScalingReplicaSet  4m55s  deployment-controller  Scaled down replica set nginx-deployment-79fbf694f6 to 2
  Normal  ScalingReplicaSet  4m55s  deployment-controller  Scaled up replica set nginx-deployment-86b8cc866b to 2

5.3 Последовательное обновление RC

Для последовательных обновлений RC Kubernetes также предоставляетkubectl rolling-updateреализация команды. Эта команда создает новый RC, а затем автоматически контролирует количество реплик Pod в старом RC, чтобы оно постепенно уменьшалось до 0, в то время как количество реплик Pod в новом RC постепенно увеличивалось с 0 до целевого значения для завершения обновления Pod.

5.4 Стратегия обновления для других объектов

Начиная с Kubernetes версии 1.6, стратегия обновления для DaemonSet и StatefulSet также представляет последовательное обновление, аналогичное развертыванию, которое автоматически завершает обновление версии приложения с помощью различных стратегий.

5.4.1 Стратегия обновления DaemonSet

Существует два типа стратегий обновления для DaemonSet:

  • OnDelete: политика DaemonSet по умолчанию. когда используешьOnDeleteКогда политика обновляет DaemonSet, после создания новой конфигурации DaemonSet новый Pod не будет создан автоматически, и новая операция не будет запущена, пока пользователь вручную не удалит старую версию Pod.
  • RollingUpdate: когда используешьRollingUpdateКогда политика обновляет DaemonSet, старая версия Pod будет автоматически удалена, а затем будет автоматически создана новая версия Pod.

5.4.2 Стратегия обновления StatefulSet

Начиная с Kubernetes версии 1.6, стратегия обновления для StatefulSet постепенно согласовывается со стратегией обновления Deployment и DaemonSet, а также будут реализованы такие политики, как RollingUpdate, Partioned и onDelete, чтобы обеспечить упорядоченное и последовательное обновление модулей в StatefulSet. -one, и записи истории обновлений сохраняются, а также можно откатиться до исторической версии.

6. Расширение модуля

В реальной производственной среде мы можем настраивать (увеличивать или уменьшать) количество экземпляров службы в различных сценариях, чтобы обеспечить полное использование системных ресурсов. На этом этапе вы можете использовать механизм масштабирования Deployment/RC для выполнения этих задач.

Kubernetes предоставляет ручной и автоматический режимы масштабирования Pod:

  • **Ручной режим:** путем выполненияkubectl scaleЗадайте количество реплик Pod для развертывания/RC с помощью команд или API RESTful.
  • **Автоматический режим: **Пользователи указывают диапазон количества реплик Pod на основе показателя производительности или пользовательского бизнес-показателя, и система будет автоматически корректироваться в пределах этого диапазона на основе изменений показателей эффективности.

6.1 Расширение ручного режима

кnginx-deployment.ymlНапример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
           - name: http
             containerPort: 80

(1) Количество запущенных реплик Pod равно 3, проверьте статус Pod:

[xcbeyond@localhost ~]$ kubectl get pod -n test
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86b8cc866b-7g4xp   1/1     Running   0          24h
nginx-deployment-86b8cc866b-pgh6c   1/1     Running   0          24h
nginx-deployment-86b8cc866b-qg26j   1/1     Running   0          23h

(2) Путем выполненияkubectl scaleКоманда обновляет количество реплик Pod с первоначальных 3 до 5:

[xcbeyond@localhost ~]$ kubectl scale deployment nginx-deployment --replicas 5 -n test
deployment.apps/nginx-deployment scaled
[xcbeyond@localhost ~]$ kubectl get pod -n test
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-86b8cc866b-7g4xp   1/1     Running             0          24h
nginx-deployment-86b8cc866b-dbkms   0/1     ContainerCreating   0          5s
nginx-deployment-86b8cc866b-pgh6c   1/1     Running             0          24h
nginx-deployment-86b8cc866b-qg26j   1/1     Running             0          23h
nginx-deployment-86b8cc866b-xv5pm   0/1     ContainerCreating   0          5s
[xcbeyond@localhost ~]$ kubectl get pod -n test
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86b8cc866b-7g4xp   1/1     Running   0          24h
nginx-deployment-86b8cc866b-dbkms   1/1     Running   0          79s
nginx-deployment-86b8cc866b-pgh6c   1/1     Running   0          24h
nginx-deployment-86b8cc866b-qg26j   1/1     Running   0          23h
nginx-deployment-86b8cc866b-xv5pm   1/1     Running   0          79s

Если для параметра --replicas установлено значение меньше, чем текущая реплика пода, некоторые запущенные поды будут удалены для уменьшения масштаба.

6.2 Расширение автоматического режима

Начиная с версии 1.1, в Kubernetes добавлена ​​функция горизонтального автоматического расширения пода (Horizontal Pod Autoscaler, сокращенно HPA), которая используется для реализации функции автоматического расширения пода на основе загрузки ЦП.

Как и Deployment and Service, HPA также является ресурсным объектом Kubernetes.

Цель HPA — автоматически регулировать количество копий Pod, отслеживая изменения нагрузки всех Pod’ов в кластере (на основе сервиса Master kube-controller-manager для постоянного мониторинга определенных показателей производительности целевого Pod) для соответствия Требования к приложениям спрос и сокращение траты ресурсов.

В настоящее время Kubernetes поддерживает следующие типы метрик:

  • Использование ресурсов пода:Показатели производительности на уровне пода, обычно соотношение, например загрузка ЦП.
  • Пользовательские показатели модуля:Показатели производительности на уровне пода, обычно числовые, например количество обслуживаемых запросов в секунду (TPS или QPS).
  • Пользовательский индикатор объекта или внешний пользовательский индикатор:Обычно это значение, которое должно каким-либо образом предоставляться приложением-контейнером, например, через URL-адрес HTTP "/metrics" или URL-адрес коллекции метрик (например, бизнес-метрика), предоставляемый внешней службой.

Как посчитать и запросить эти показатели?

Kubernetes устарел, начиная с версии 1.11, на основанииHeapsterКомпонент завершает механизм сбора данных об использовании ЦП Pod и всесторонне превращается в основанный наMetrics ServerПолный сбор данных.Metrics ServerПредоставьте собранные данные индикатора производительности модуля контроллеру HPA для запроса через API агрегации (например, metrics.k8s.io, custom.metrics.k8s.io и external.metrics.k8s.io).

6.2.1 Как работает HPA

Сервер метрик (Heapster или пользовательский сервер метрик) в Kubernetes постоянно собирает данные метрик всех реплик Pod. Контроллер HPA получает данные через API сервера метрик и вычисляет на основе определенных пользователем правил расширения, чтобы получить целевое количество реплик Pod. Когда количество реплик целевых подов отличается от текущего количества реплик, контроллер HPA инициирует операцию масштабирования для контроллера реплики пода (развертывание, RC или набор реплик) (эквивалентно выполнению в ручном режиме).kubectl scaleкоманда), отрегулируйте количество копий модуля и завершите операцию расширения.

Следующая диаграмма описывает ключевые компоненты и рабочий процесс в системе HPA:在这里插入图片描述

Контроллер HPA основан на Masterkube-controller-managerПараметры запуска службы--horizontal-pod-autoscaler-sync-periodОпределенный период обнаружения (по умолчанию 15 с).

6.2.2 Инструкции по настройке HPA

Расширение в автоматическом режиме предоставляется пользователям через объект ресурса HorizontalPodAutoscaler для определения правил расширения.

Объект ресурса HorizontalPodAutoscaler находится в группе Kubernetes API «автомасштабирование», которая в настоящее время включает две версии: v1 и v2.

  • autoscaling/v1: поддерживает только автоматическое масштабирование на основе использования ЦП.
  • autoscaling/v2*: поддерживает настройку автоматического масштабирования на основе любого индикатора, включая данные индикатора на основе использования ресурсов, индикаторы Pod и другие индикаторы. Текущая версия — autoscaling/v2beta2.

Ниже подробно описаны настройка и использование HorizontalPodAutoscaler.

Для получения подробных сведений об элементах конфигурации см.:

  1. Это особенное.IO/docs/refer E…

  2. Это особенное.IO/docs/refer E…

(1) Конфигурация HorizontalPodAutoscaler на основе версии autoscaling/v1:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Описание параметра:

  • scaleTargetRef: целевой объект роли, которым может быть Deployment, RC и ReplicaSet.
  • targetCPUUtilizationPercentage: ожидаемая загрузка ЦП на модуль.
  • minReplicasа такжеmaxReplicas: P Минимальное и максимальное количество больших реплик, система будет автоматически расширяться в пределах этого диапазона и поддерживать использование ЦП каждого пода на заданном значении.

Чтобы использовать версию HorizontalPodAutoscaler Autoscaling/v1, необходимо предварительно установить компонент Heapster или сервер метрик для сбора данных об использовании ЦП модулями.

(2) Конфигурация HorizontalPodAutoscaler на основе версии autoscaling/v2beta2:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Описание параметра:

  • scaleTargetRef: объект целевой роли, которым может быть Deployment, RC и ReplicaSet.
  • minReplicasа такжеmaxReplicas: P Минимальное и максимальное количество больших реплик, система будет автоматически расширяться в пределах этого диапазона и поддерживать использование ЦП каждого пода на заданном значении.
  • metrics: Целевое значение индекса.
    • type: определяет тип индикатора. Можно установить четыре типа, а также можно установить комбинацию одного или нескольких типов:
      • Resource: значения метрик на основе ресурсов, таких как ЦП и память. Для использования ЦП установите AverageUtilization в целевом параметре, чтобы определить целевое среднее использование ЦП; для ресурсов памяти установите AverageValue в целевом параметре, чтобы определить целевое среднее значение использования памяти.
      • Pods: на основе метрик пода система рассчитает среднее значение метрик всех реплик пода. Тип его целевого индикатора может использовать только значение AverageValue. Для данных метрик обычно требуется создание собственного сервера метрик и инструментов мониторинга для сбора и обработки.
      • Object: индикатор на основе определенного объекта ресурса или любого пользовательского индикатора прикладной системы. Для данных метрик обычно требуется создание собственного сервера метрик и инструментов мониторинга для сбора и обработки.
      • External: Kubernetes представил поддержку внешних системных метрик, начиная с версии 1.10. Например, пользователи, использующие службы сообщений или внешнюю балансировку нагрузки, предоставляемые поставщиками общедоступных облачных служб, могут автоматически масштабировать свои собственные службы, развернутые в Kubernetes, на основе показателей производительности этих внешних служб.
    • target: Определите соответствующее целевое значение индикатора, и система запустит операцию расширения, когда данные индикатора достигнут целевого значения.

Пример 1, установите имя индикатора наrequests-per-second, значение которого исходит от Ingress "main-route", установите целевое значение (value) равным 2000, то есть, когда количество запросов Ingress в секунду достигает 2000, срабатывает операция расширения:

metrics:
- type: Object
  object:
    metric:
      name: requests-per-second
    describedObject:
      apiVersion: extensions/v1beta1
      kind: Ingress
      name: main-route
    target:
      type: Value
      value: 2k

Пример 2, имя индикатора установлено как http_requests, а объект ресурса имеет метку "verb=GET", а операция раскрытия запускается, когда среднее значение индикатора достигает 500:

metrics:
- type: Object
  object:
    metric:
      name: http_requests
      selector: 'verb=GET'
    target:
      type: AverageValue
      averageValue: 500

Вы также можете определить несколько типов метрик в одном и том же объекте ресурса HorizontalPodAutoscaler, и система рассчитает целевое количество реплик Pod для каждого типа метрик и увеличит масштаб на основе максимального значения. Например:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1beta1
        kind: Ingress
      target:
        type: Value
        value: 10k

В примере 3 задайте для метрики имя queue_messages_ready с тегом queue=worker_tasks, запускающим операцию автоматического масштабирования, когда целевое среднее значение метрики равно 30:

metrics:
- type: External
  external:
    metric:
      name: queue_messages_ready
      selector: 'queue=worker_tasks'
    target:
      type: AverageValue
      averageValue: 30

При использовании индикаторов внешних сервисов необходимо установить и развернуть систему мониторинга, которая может подключаться к модели Kubernetes HPA, и завершить понимание механизма системы мониторинга для сбора этих индикаторов, чтобы можно было выполнить последующие операции автоматического расширения. .

6.2.3 Практика HPA на основе пользовательских показателей

Ниже приведен полный пример, иллюстрирующий создание и использование системы HPA на основе пользовательских индикаторов.

При выполнении автоматического расширения на основе пользовательских метрик необходимо заранее развернуть пользовательский сервер метрик.В настоящее время для реализации пользовательского сервера метрик можно использовать адаптеры на основе таких систем, как Prometheus, Microsoft Azure и Google Stackdriver. Пользовательский сервер метрик может относиться кGitHub.com/Это так особенно/…инструкция о.

Этот раздел основан на системе мониторинга Prometheus и содержит подробное описание развертывания основных компонентов HPA и конфигурации HPA.

Архитектура HPA на основе Prometheus показана на следующем рисунке:在这里插入图片描述

Ключевые компоненты описаны ниже:

  • Прометей:Это система мониторинга служб с открытым исходным кодом, используемая для периодического сбора данных индекса производительности каждого модуля.
  • Пользовательский сервер метрик:Настройте сервер метрик и используйте адаптер Prometheus для конкретной реализации. Он собирает данные индикаторов производительности из службы Prometheus и регистрирует API пользовательских индикаторов на сервере API мастера через уровень агрегации показателей Kubernetes./apis/custom.metrics.k8s.ioПути предоставляют метрические данные.
  • Контроллер HPA:Контроллер HPA Kubernetes выполняет операции автоматического масштабирования на основе определяемого пользователем HorizontalPodAutoscaler.

Весь процесс развертывания выглядит следующим образом:

(1) Включитьkube-apiserver,kube-controller-managerСоответствующие параметры запуска службы.

kube-apiserver,kube-controller-managerСлужба уже развернута по умолчаниюkube-systemПространства имен.

[xcbeyond@localhost minikube]$ kubectl get pod -n kube-system
NAME                               READY   STATUS    RESTARTS   AGE
coredns-6c76c8bb89-p26xx           1/1     Running   11         103d
etcd-minikube                      1/1     Running   11         103d
kube-apiserver-minikube            1/1     Running   11         103d
kube-controller-manager-minikube   1/1     Running   11         103d
kube-proxy-gcd8d                   1/1     Running   11         103d
kube-scheduler-minikube            1/1     Running   11         103d
storage-provisioner                1/1     Running   29         103d

Примечание. Эта среда Kubernetes представляет собой локальную среду, развернутую на основе Minikube.

доступныйkubectl describeКоманда для просмотра текущих параметров запуска службы, например:

[xcbeyond@localhost minikube]$ kubectl describe pod/kube-apiserver-minikube -n kube-system
Name:                 kube-apiserver-minikube
Namespace:            kube-system
……
Containers:
kube-apiserver:
……
 Command:
   kube-apiserver
   --advertise-address=172.17.0.2
   --allow-privileged=true
   --authorization-mode=Node,RBAC
   --client-ca-file=/var/lib/minikube/certs/ca.crt
   --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
   --enable-bootstrap-token-auth=true
   --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt
   --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt
   --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key
   --etcd-servers=https://127.0.0.1:2379
   --insecure-port=0
   --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt
   --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key
   --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
   --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt
   --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key
   --requestheader-allowed-names=front-proxy-client
   --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt
   --requestheader-extra-headers-prefix=X-Remote-Extra-
   --requestheader-group-headers=X-Remote-Group
   --requestheader-username-headers=X-Remote-User
   --secure-port=8443
   --service-account-key-file=/var/lib/minikube/certs/sa.pub
   --service-cluster-ip-range=10.96.0.0/12
   --tls-cert-file=/var/lib/minikube/certs/apiserver.crt
   --tls-private-key-file=/var/lib/minikube/certs/apiserver.key
……

доступныйkubectl editКоманда обновляет параметры запуска службы, такие как:

[xcbeyond@localhost minikube]$ kubectl edit pod kube-apiserver-minikube -n kube-system

Запустите уровень агрегации на сервере API мастера, установив следующие параметры запуска службы kube-apiserver.

  • --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt: Сертификат ЦС клиента.
  • --requestheader-allowed-names=front-proxy-client: Список общих имен клиентов, к которым разрешен доступ через заголовок--requestheader-username-headersПолучить поле, указанное параметром. Имя общих имен клиентов необходимо настроить в файле client-ca.Если для него задано пустое значение, это означает, что любой клиент может получить к нему доступ.
  • --requestheader-extra-headers-prefix=X-Remote-Extra-: Имя префикса, которое необходимо сохранить в заголовках запросов.
  • --requestheader-group-headers=X-Remote-Group: имя группы для проверки в заголовке запроса.
  • --requestheader-username-headers=X-Remote-User: имя пользователя для проверки в заголовке запроса.
  • --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt: проверка сертификата ЦС клиента агрегатора во время запроса.
  • --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key: проверка закрытого ключа клиента агрегатора во время запроса.

Настройте соответствующие параметры запуска (дополнительная конфигурация) HPA в службе kube-controller-manager следующим образом:

  • --horizontal-pod-autoscaler-sync-period=10s: Интервал пространства для контроллера HPA для синхронизации количества реплик Pod, значение по умолчанию — 15 с.
  • --horizontal-pod-autoscaler-downscale-stabilization=1m: Время ожидания операции расширения Значение по умолчанию — 5 минут.
  • --horizontal-pod-autoscaler-initial-readiness-delay=30s: задержка ожидания перехода пода в состояние чтения.Значение по умолчанию — 30 минут.
  • --horizontal-pod-autoscaler-tolerance=0.1: допуск результата расчета расширения, значение по умолчанию — 0,1, что означает [-10% - +10%].

(2) Разверните Прометей.

Здесь для развертывания используется Prometheus-operator.

Оператор Prometheus предоставляет простые определения для мониторинга управления службами Kubernetes, развертываниями и экземплярами Prometheus, упрощая развертывание, управление и работу в Kubernetes.

(3) Разверните собственный сервер показателей.

Разверните как реализацию адаптера Prometheus.

(4) Разверните приложение.

Приложение предоставляет RESTful интерфейс/metricsи укажите значение специальной метрики с именем http_requests_total.

(5) Создайте объект Prometheus ServiceMonitor для мониторинга индикаторов, предоставляемых приложением.

(6) Создайте объект HorizontalPodAutoscaler, чтобы предоставить контроллеру HPA конфигурацию автоматического масштабирования, ожидаемую пользователем.

(7) Инициируйте HTTP-запрос доступа к приложению, чтобы проверить механизм автоматического расширения HPA.

Справочная статья:

  1. блог woo woo woo.cn on.com/coco шерсти/afraid/…
  2. Это особенное.IO/docs/refer E…
  3. Блог Woohoo.cn на.com/Linux mad/afraid/95…
  4. Это особенное.IO/docs/refer E…
Категории