eShopOnContainers — часть 2 (локальный кластер Kubernetes)

В части 1 мы рассмотрели развертывание eShopOnContainers с помощью docker-compose. Здесь мы рассмотрим развертывание eShopOnCONtainers в локальном кластере Kubernetes в Docker Desktop. Вы можете обратиться Развертывание в локальном Kubernetes шаг за шагом, чтобы развернуть его в локальном кластере Kubernetes. Цель этого поста — объяснить, как и что делается в этой указанной ссылке.

Все файлы, необходимые для развертывания, находятся в папке eShopOnContainers\deploy\k8s\helm.

Давайте начнем с развертывание-все.ps1 —

.\deploy-all.ps1 -imageTag linux-latest -useLocalk8s $true -imagePullPolicy Always

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

Быстрее всего понять helm в Kubernetes можно на практике. Чтобы установить Helm в Windows, выполните следующие действия:

1. Загрузите последнюю версию Helm из официального репозитория Helm на GitHub. https://github.com/helm/helm/релизы.

2. Извлеките загруженный архив в каталог по вашему выбору. Откройте окно командной строки или Powershell и перейдите в каталог, в который вы распаковали файлы Helm.

3. Добавьте исполняемый файл Helm в переменную среды PATH вашей системы, чтобы вы могли запускать команды Helm из любой точки вашей системы.

4. Инициализируйте Helm в вашей системе, выполнив следующую команду:

helm init

5. Проверьте установку, выполнив следующую команду:

helm version

Используйте команду ниже, чтобы создать диаграмму руля —

helm create demoChart

Это создаст следующие файлы и папку —

И для локального рендеринга в консоли используйте следующую команду:

helm template .

Давайте разберемся в этом на высоком уровне на примере services.yaml —

Ниже файл шаблона —

И локальный рендер генерирует следующее:

Простой, {{ .Values.service.type }} заменяется значениями, предоставленными в values.yaml (по умолчанию).

Разберемся, что происходит ниже —

include указывает, что это функция и определена в файле, начинающемся с _

Обычно вы определяете свой именованный шаблон

{{- define "mychart.labels" -}}
  labels:
    myLabel: {{ .Values.myLabel }}
{{- end -}}

Затем вы можете вызвать свой шаблон и передать текущую область видимости. к этому:

{{- include "mychart.labels" . }}

Строки 39 и 40 относятся к .Chart (Chart.yaml). Это встроенный объект, аналогичный Values ​​и Release, к которому вы можете получить доступ в своих шаблонах. У нас нет файла для выпуска, и он вычисляется на основе текущего состояния —

Релиз. Ревизия: Номер версии для этого выпуска. При установке это значение равно 1 и увеличивается при каждом обновлении и откате.
Релиз.Сервис: Служба, выполняющая рендеринг текущего шаблона. На Хелме это всегда Шлем.

Теперь, когда мы получили общее представление о руле, давайте поиграем с диаграммами руля eShopOnContainers. Мы видим services.yaml содержание, как показано ниже —

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.app.svc.mvc }}
  labels:
    app: {{ template "webmvc.name" . }}
    chart: {{ template "webmvc.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: {{ template "webmvc.name" . }}
    release: {{ .Release.Name }}

Давайте рендерим локально webmvc —

D:\eShopOnContainers\deploy\k8s\helm\webmvc>helm template .

Мы получаем следующую ошибку —

Ошибка: шаблон: webmvc/templates/service.yaml:4:18: выполнение «webmvc/templates/service.yaml» в <.Values.app.svc.mvc>: нулевой указатель, оценивающий интерфейс {}.svc

Приведенная выше ошибка говорит о том, что в values.yaml отсутствует <.Values.app.svc.mvc> в service.yaml. Так где это? Посмотрите в корневую папку, вы увидите app.yaml. Там это определено. Отлично, а как включить это в команду —

D:\eShopOnContainers\deploy\k8s\helm>helm template webmvc -f app.yaml

Теперь возникает ошибка для <.Values.inf.k8s.suffix> в ingress.yaml.

Ошибка: шаблон: webmvc/templates/ingress.yaml:2:20: выполнение «webmvc/templates/ingress.yaml» в : ошибка вызова включает: шаблон: webmvc/templates/_names.tpl:38 :14: выполнение «pathBase» в <.Values.inf.k8s.suffix>: нулевой указатель, оценивающий интерфейс {}.k8s

Это означает, что его нет ни в values.yaml, ни в app.yaml. Так где это? Посмотрите в корне инф.ямл. Отлично, давайте включим и этот файл —

D:\eShopOnContainers\deploy\k8s\helm>helm template webmvc -f app.yaml -f inf.yaml

Отлично, ошибка ушла, и мы получаем результат ниже —

# Source: webmvc/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: "cfg-RELEASE-NAME-webmvc"
  labels:
    app: webmvc
    chart: webmvc-0.1.0
    release: RELEASE-NAME
    heritage: Helm
data:
  all__InstrumentationKey: ""
  all__UseAzureServiceBus: "false"
  webmvc__keystore: keystore-data
  ...
  ...

Хорошо, давайте развернем все диаграммы в кластер kubernates с помощью deploy-all.ps1.

.\deploy-all.ps1 -imageTag linux-latest -useLocalk8s $true -imagePullPolicy Always

Обратите внимание, что вам не нужно очищать кластер каждый раз при развертывании. deploy-all.ps1 позаботится об удалении ранее развернутых модулей или служб, как показано ниже:

После завершения развертывания вы можете получить модули в качестве сервисов, как показано ниже:

kubectl get pods

kubectl get services

Доступ к службам с локального хоста

Docker Desktop сопоставляет порты вашего локального хоста с портами на виртуальной машине, что означает, что вы можете запустить контейнер, скажем, на порту 80 на виртуальной машине и иметь доступ к нему из браузера на локальном хосте. Когда дело доходит до раскрытия рабочей нагрузки Kubernetes внешнему трафику, создание входов или служб, таких как NodePorts и LoadBalancers, является стандартной практикой. Каждая из этих функций отличается тем, как они позволяют получить доступ к модулям.

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

kubectl port-forward svc/webmvc 9999:80

С помощью перенаправления портов вы можете получить доступ к любому сервису —

Установите контроллер входа NGINX

Ingress — это объект API, который позволяет получить доступ к вашим кластерным службам извне. Это как обратный прокси, который может обрабатывать балансировку нагрузки, TLS, виртуальный хостинг и тому подобное.

NGINX — это контроллер Ingress, используемый для eShopOnContainers.

Чтобы установить контроллер NGINX Ingress, выполните следующую команду:

kubectl apply -f 

Вы можете получить доступ к приложению webmvc с IP-адресом хост-компьютера.

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

Установите пользовательский интерфейс панели управления Kubernetes.

Вы можете развернуть Kubernetes Web UI (Dashboard) для локального мониторинга кластера. Перейдите в папку k8s в вашей локальной копии репозитория eShopOnContainers.

Разверните панель управления с помощью этой команды:

kubectl apply -f 

Создайте образец привязки пользователя и роли администратора, запустив скрипт:

kubectl apply -f dashboard-adminuser.yaml

Запустите панель управления, выполнив эту команду:

kubectl proxy

Получите токен носителя для входа в панель управления, выполнив эту команду:

kubectl -n kubernetes-dashboard create token admin-user

Вы должны получить что-то вроде этого:

Скопируйте токен и перейдите к Панель управления Kubernetes

Выберите «Токен» и вставьте скопированный токен в поле «Введите токен»:

Вы должны увидеть что-то вроде этого:

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