ISTIO: Общий проход / AWS Alb, Helm Chart с условиями, ISTIO и Externaldns

Давайте продолжим наше путешествие с ISTIO.

Предыдущие части:

Помимо ISTIO, в этом посте мы также настроим внешний вид, см. Kubernetes: Обновление AWS Market53 DNS от проникновения для деталей.

Все, что описано ниже, является своего рода доказательством концепции и будет развернуто к тому же AWS Elastic Cubernetes Service Dev Cluster.

Цели

Итак, теперь у меня есть три задания:

Тест, как будет работать один общий AWS Application LoadBalancer (AWS Alb) и Ворот входа ISTIO с приложениями в разных пространствах имен
Создайте диаграмму HELM с шаблонами, чтобы выбрать, чтобы создать вход в проход, ISTIO Gateway и ISTIO Virtualservice
Настройте внешние данные для создания записей в AWS Route53 при добавлении шлюза ISTIO или VirtualService

Сначала давайте посмотрим, как Gateway Attio Inhress будет работать с приложениями, расположенными в выделенных пространствах имен. Для этого мы создадим вход, который создаст AWS приложение LoadBalancer с Alb Ingress Controller и два тестированных приложения, каждый с собственным обслуживанием, шлюзом и виртуальнымсервисом.

В Ingress/AWS Alb мы опишем хосты, и это будет вызвать Externaldns создавать записи. Кроме того, здесь мы сделаем SSL-завершение — приложим SSL-сертификаты от диспетчера сертификата AWS.

В воротах каждого из этих приложений мы откроем порты на ворот ISTIO Ingress Gateway и добавляем хосты, для которых этот шлюз будет принимать трафик.

Общий проход будет создан в пространстве именного пространства ISTIO-System, поскольку ему необходимо получить доступ к сервису Ingress ISTIO.

На самом деле, мы могли бы создать один общий шлюз, но в конце обсуждения Здесь >>> Люди говорят, что это будет лучше иметь выделенный шлюз на каждое приложение, и это, кажется, более правильным, поэтому давайте сделаем это таким образом.

Таким образом, теперь мы создадим:

Выделенный Ingress/AWS Alb с двумя тестовыми записями в Trance53 в ISTIO-SYSTEM пространство имен
Тест App1 и App2 в пространствах имен Backend-App-1-NS и Backend-App-2-NS Соответственно, каждое приложение со своим собственным развертыванием, обслуживанием, шлюзом и виртуальнымсервисом

Вторая задача будет интереснее: необходимо будет создать шаблоны HELM для развертывания приложений на различных средах (вроде dev и prod) для развертывания приложений на различных средах с различными конфигурациями входа и ISTIO.

И в третьей задаче мы настроим внешний вид на работу с Gateway ISTIO и VirtualService.

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

Общий проход/AWS Alb

Создайте файл манифеста для входа/Alb — Comment-Gateway.yaml:

--------
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: backend-common-alb
  namespace: istio-system
  annotations:
    # create AWS Application LoadBalancer
    kubernetes.io/ingress.class: alb
    # external type
    alb.ingress.kubernetes.io/scheme: internet-facing
    # AWS Certificate Manager certificate's ARN
    alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:us-east-2:534***385:certificate/db886018-c173-43d0-b1be-b940de71f2a2"
    # open ports 80 and 443 
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    # redirect all HTTP to HTTPS
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    # ExternalDNS settings: [https://rtfm.co.ua/en/kubernetes-update-aws-route53-dns-from-an-ingress/](https://rtfm.co.ua/en/kubernetes-update-aws-route53-dns-from-an-ingress/)
    external-dns.alpha.kubernetes.io/hostname: "app1-test-common-ingress.example.com, app2-test-common-ingress.example.com"
spec:
  rules:
  - http:
      paths:
        - path: /*
          backend:
            serviceName: ssl-redirect
            servicePort: use-annotation
        - path: /*
          backend:
            serviceName: istio-ingressgateway
            servicePort: 80

Здесь, в аннотациях, мы описываем домены, которые будут созданы внешними доменами, и они будут сопоставлены на URL AWS ALB, а на бэкэнде мы отправим все трафик на ISTIO-Ingressgateway Cubernetes Service.

Развернуть это:

$ kubectl apply -f common-ingress-gateway.yaml
ingress.extensions/backend-common-alb created

Проверьте вход/Альб:

$ kubectl -n istio-system get ingress backend-common-alb
NAME CLASS HOSTS ADDRESS PORTS AGE
backend-common-alb  * aadca942-***1826302788.us-east-2.elb.amazonaws.com 80 72s

И внешние журналы:

…
time="2021–04–12T09:45:02Z" level=info msg="Desired change: CREATE app-1-test-common-ingress.example.com A [Id: /hostedzone/Z30KLN6M3D0LB6]"
time="2021–04–12T09:45:02Z" level=info msg="Desired change: CREATE app-1-test-common-ingress.example.com TXT [Id: /hostedzone/Z30KLN6M3D0LB6]"
time="2021–04–12T09:45:02Z" level=info msg="Desired change: CREATE app-2-test-common-ingress.example.com A [Id: /hostedzone/Z30KLN6M3D0LB6]"
time="2021–04–12T09:45:02Z" level=info msg="Desired change: CREATE app-2-test-common-ingress.example.com TXT [Id: /hostedzone/Z30KLN6M3D0LB6]"
time="2021–04–12T09:45:03Z" level=info msg="4 record(s) in zone example.com. [Id: /hostedzone/Z30KLN6M3D0LB6] were successfully updated"
…

Попробуйте получить доступ к URL, должен получить ошибку, поскольку шлюз ISTIO Ingress еще не настроен:

$ curl -I [https://app-1-test-common-ingress.example.com](https://app-1-test-common-ingress.example.com)
HTTP/2 502
date: Mon, 12 Apr 2021 09:46:11 GMT
server: istio-envoy

Да, ошибка 502, так как Gateway Istio Inhress не имеет маршрутов для доменов еще:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-8459df68cb-bh76b
NOTE: This output only contains routes loaded via RDS.
NAME DOMAINS MATCH VIRTUAL SERVICE
* /healthz/ready*
* /stats/prometheus*

Теперь давайте создадим тестирование приложений, где мы опишем настройки для ворот istio Inhress Gateway.

Тестирующие приложения

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

Здесь мы создадим:

Пространство имен
Развертывание
Услуга
Шлюз
VirtualService

Целый манифест следующий:

--------
apiVersion: v1
kind: Namespace
metadata:
  name: backend-app-1-ns
  labels:
    istio-injection:
      enabled
--------
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-app-1-deploy
  namespace: backend-app-1-ns
  labels:
    app: backend-app-1
    version: v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend-app-1
  template:
    metadata:
      labels:
        app: backend-app-1
        version: v1
    spec: 
      containers:
      - name: app1
        image: nginxdemos/hello
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        readinessProbe:
          httpGet:
            path: /
            port: 80
--------
apiVersion: v1
kind: Service
metadata:
  name: backend-app-1-servcie
  namespace: backend-app-1-ns
spec:       
  selector:
    app: backend-app-1
  ports:    
    - name: http
      protocol: TCP
      port: 80
--------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: backend-app-1-gateway
  namespace: backend-app-1-ns
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "app-1-test-common-ingress.example.com"
--------
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend-app-1-virtualservice
  namespace: backend-app-1-ns
spec:
  hosts:
  - "app-1-test-common-ingress.example.com"
  gateways:
  - backend-app-1-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: backend-app-1-servcie
        port:
          number: 80

Развернуть это:

$ kubectl apply -f app1.yaml
namespace/backend-app-1-ns created
deployment.apps/backend-app-1-deploy created
service/backend-app-1-servcie created
gateway.networking.istio.io/backend-app-1-gateway created
virtualservice.networking.istio.io/backend-app-1-virtualservice created

Скопируйте файл манифеста, изменить приложение-1 к Приложение-2 Развернуть тоже:

$ kubectl apply -f app2.yaml
namespace/backend-app-2-ns created
deployment.apps/backend-app-2-deploy created
service/backend-app-2-servcie created
gateway.networking.istio.io/backend-app-2-gateway created
virtualservice.networking.istio.io/backend-app-2-virtualservice created

Проверьте маршруты ISTIO еще раз:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-8459df68cb-bh76b=
NOTE: This output only contains routes loaded via RDS.
NAME DOMAINS MATCH VIRTUAL SERVICE
http.80 app-1-test-common-ingress.example.com /* backend-app-1-virtualservice.backend-app-1-ns
http.80 app-2-test-common-ingress.example.com /* backend-app-2-virtualservice.backend-app-2-ns

И попробуйте получить доступ к URL-адресу приложение-1 :

$ curl -I [https://app-1-test-common-ingress.example.com](https://app-1-test-common-ingress.example.com)
HTTP/2 200
date: Mon, 12 Apr 2021 09:52:13 GMT
content-type: text/html
server: istio-envoy

Круто, все работает сейчас. Теперь у нас есть один разделяемый AWS ALB, созданный с помощью kubernetes Ingress, который отправляет трафик через ворот intio Inhress до двух выделенных приложений и выделенных пространств имен.

Ресурсы выпадают, но оставьте вход с общей пообщещенным LoadBalancer для дальнейших тестов:

$ kubectl delete -f app1.yaml
$ kubectl delete -f app2.yaml

И пойдем на хелм-график.

ISTIO: общий проход/AWS Alb, и Helm

Планирование: условия

Следующая задача нетривиальна: у нас есть кластер DEV EKS, а продукция EKS Кластер.

На кластере Dev, у нас уже есть ISTIO И это тестирование там, но не для всех приложений работает там. На производственном кластере мы еще не установили IETIO, но сделаем это в будущем.

Кроме того, все наши приложения теперь уходят в выделенных пространствах имен и имеют выделенный Ingress/AWS ALB.

На Cluster Dev я хотел бы изменить этот подход, и использовать теперь общий проход/Alb и отправлять все трафик через ворот Istio Inhress, но на производстве — оставьте его, то есть каждое приложение будет использовать свой собственный Alb, и На данный момент они отправит трафик на сервис приложения напрямую, и в будущем, когда мы реализуем ISTIO на производство, нам нужно будет изменить вход на использование ворот Istio Inhress Gateway.

Но все же, а приложения DEV и производства могут использовать или не ISTIO, так как он находятся на «ранней стадии», но в нашей архитектуре, и некоторые временные настройки для приложения будут отличаться, поэтому необходимо создать такую графику HELM, которая может настроить необходимость Ресурсы и настройки входа.

Итак, сначала надо т.е. Во-первые — Надо определить Учёт ли таблица использует свой собственный вход или общий? Во-вторых, если он использует свой собственный вход, который он будет использовать его — ISTIO Ingress Gateway или общая служба приложения? И если он будет использовать ворот istio Inhress, график должен создать ворота и ресурсы виртуальнойсервис.

Таким образом, наш шаблон должен принимать три схемы конфигурации:

Используйте общий Loadbalancer и ISTIO: Gateway Gateway Istio Angress Loadbalancer и Hateway Hateway Istio Ase отдохнуть
Собственный/выделенный loadbalancer для приложения и ворот Istio Inhecress Gateway: создать вход в приложение с помощью службы ворот ISTIO Ingress AS отдохнуть
Собственный/выделенный Lookbalancer для приложения, но без ISTIO: создайте попадание в приложение с услугами приложения в качестве отдохнуть

I.e:

проникновений делится или владеет?
Если общие — не создавайте вход в ресурс
Если свой собственный, то создайте вход, но с выбором сервиса входа в Йорн — ISTIO или общего обслуживания Kubernetes приложения
Бэкэнда для входа — ISTIO или сервис приложения?
Если ISTIO, то нужно установить отдохнуть как ServiceName: ISTIO-Ingressgateway и создать ворота и виртуальные ресурсы
Если служба приложения, то установите BASKEND как ServiceName: -service и не создавайте ворот и виртуальные ресурсы

Для достижения этой цели, давайте использовать Значения.yaml — У нас выделенные файлы для разработки и производственных сред.

В этих файлах мы можем определить два параметра — istio.enabled и Ingress.enabled Отказ

Это даст нам возможность установить для Dev ygress.enabled = false и не создавайте вход, но набор istio.enabled == True и создать шлюз и виртуальныйсервис, который будет использоваться по совмещенным входом/ALB из ISTIO-SYSTEM пространство имен.

А для производства мы сможем установить ygress.enabled = True. и istio.enabled = false Затем график будет развернут в текущей использованной схеме, а затем, когда мы будем реализовывать ISTIO в кластере производства, мы установим эти значения как ygress.enabled = true и istio.enabled = true , и это создаст выделенный вход/LoadBalancer, который отправит трафик через ворот Istio Inhress.

Ну, давайте попробуем.

Создание хелм диаграммы и шаблоны

Создать новый график:

$ helm create app-1
Creating app-1

Создавать каталоги, чтобы сохранить Значения.yaml Для разработки и производства:

$ mkdir -p app-1/env/{dev,prod}

Удалить шаблоны и значения по умолчанию:

$ rm -r app-1/templates/* app-1/values.yaml

Создайте собственные значения файлов в те каталоги:

$ vim -p app-1/env/dev/values.yaml app-1/env/prod/values.yaml

Для Dev — app-1/env/dev/values.yaml :

appConfig:
  name: "backend-app-1"
  version: "v1"
  url: "dev-app-1-test-common-ingress.example.com"

istio:
  enabled: true

ingress:
  enabled: false

Не создавайте вход, но создайте шлюз и виртуальный сайт.

Производство — APP-1/ENV/PROD/VANCES.YAML :

appConfig:
  name: "backend-app-1"
  version: "v1"
  url: "prod-app-1-test-common-ingress.example.com"

istio:
  enabled: false

ingress:
  enabled: true

Здесь приступление будет создано как выделенный AWS Alb, но ресурсы для не будут созданы — Приступник отправит трафик непосредственно на сервис приложения

Создать шаблон файлов:

$ vim -p app-1/templates/ingress.yaml app-1/templates/service.yaml app-1/templates/deployment.yaml

Мы не будем определять пространство имен в этих шаблонах (только для входа, см. Ниже), так как пространство имен будет создано Helm во время развертывания.

Развертывание

Нет изменений здесь, только некоторые значения взяты из Значения.yaml :

-------- 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appConfig.name }}-deploy
  labels:
    app: {{ .Values.appConfig.name }}
    version: {{ .Values.appConfig.version }}
spec:
  replicas: 2
  selector:
    matchLabels:
      app: {{ .Values.appConfig.name }}
  template: 
    metadata:
      labels:
        app: {{ .Values.appConfig.name }}
        version: {{ .Values.appConfig.version }}
    spec: 
      containers:
      - name: web-app
        image: nginxdemos/hello
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        readinessProbe:
          httpGet:
            path: /
            port: 80

Сервис, Виртуальныйсервис, Шлюз

Здесь мы всегда будем создавать услугу с проверкой состояния: если Ingress.enabled == True Затем установите тип: NodePort Таким образом, наш LoadBalancer сможет отправить трафик на рабочую сторону. Если это ложное, то используйте значение по умолчанию Кластера Таким образом, наши запросы не будут проходить через дополнительные правила iptables, но вместо этого будут отправлены непосредственно на рабочего режима, где живет POD (читайте также Kubernetes: Сервис, балансировка нагрузки, Kube-Proxy и iptables ):

-------- 
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.appConfig.name }}-service
spec:
  {{- if .Values.ingress.enabled }}
  type: NodePort
  {{- end }}
  selector:
    app: {{ .Values.appConfig.name }}
  ports:
    - name: http
      protocol: TCP
      port: 80

Тогда проверим istio.enabled Состояние, и если он установлен на True — ворота и ресурсы Vateway и Virtualservice:

{{- if .Values.istio.enabled }}
--------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: {{ .Values.appConfig.name }}-gateway
spec:     
  selector: 
    istio: ingressgateway
  servers:
  - port: 
      number: 80
      name: http
      protocol: HTTP
    hosts:  
    - {{ .Values.appConfig.url }}
--------         
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: {{ .Values.appConfig.name }}-virtualservice
spec:
  hosts:
  - {{ .Values.appConfig.url }}
  gateways:
  - {{ .Values.appConfig.name }}-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: {{ .Values.appConfig.name }}-service
        port:
          number: 80
{{- end }}

Проходность

Для проникновения в Ingress.enabled Состояние сначала проверит, нужно ли создать вход вообще, и если true — то будет проверять, какое пространство имен использовать, как будто мы будем использовать ISTIO, то этот вход должен быть создан в пространство имен ISTIO-System И если это «общий» проникновение — тогда в пространстве имен приложения.

позже, с istio.enabled Мы проверим, где будет отправлен свой трафик — в ISTIO или общую службу приложения:

{{- if .Values.ingress.enabled }}
-------- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ .Values.appConfig.name }}-alb
  {{- if .Values.istio.enabled }}
  namespace: istio-system
  {{- end }}
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:us-east-2:534***385:certificate/db886018-c173-43d0-b1be-b940de71f2a2"
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    external-dns.alpha.kubernetes.io/hostname: {{ .Values.appConfig.url }}
spec:   
  rules:
  - http:
      paths:
        - path: /*
          backend:
            serviceName: ssl-redirect
            servicePort: use-annotation
        - path: /*
          backend:
          {{- if .Values.istio.enabled }}
            serviceName: istio-ingressgateway
          {{ else }}
            serviceName: {{ .Values.appConfig.name }}-service
          {{- end }}
            servicePort: 80
{{- end }}

Запустите руль с --debug и - Дри-беги — Не должны быть напечатаны никакого входа, но ворота с виртуальнымсервисом должны быть присутствуют:

$ helm upgrade — install backend-app-1 — namespace dev-backend-app-1-ns — create-namespace -f app-1/env/dev/values.yaml app-1/  -- debug --— dry-run

Если здесь нет ошибок, то разверните его к кластеру Dev:

$ helm upgrade --install backend-app-1 --namespace dev-backend-app-1-ns --create-namespace -f app-1/env/dev/values.yaml app-1/
Release "backend-app-1" does not exist. Installing it now.
NAME: backend-app-1
LAST DEPLOYED: Mon Apr 12 18:03:08 2021
NAMESPACE: dev-backend-app-1-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

Проверьте вход в Dev-Backend-App-1-NS пространство имен:

$ kubectl -n dev-backend-app-1-ns get ingress
No resources found.

Хорошо, и мы должны видеть ворота и виртуальный сервис:

$ kubectl -n dev-backend-app-1-ns get gateway
NAME AGE
backend-app-1-gateway 38s
kubectl -n dev-backend-app-1-ns get virtualservice
NAME GATEWAYS HOSTS AGE
backend-app-1-virtualservice [backend-app-1-gateway] [dev-app-1-test-common-ingress.example.com] 65s

Хороший!

Теперь разверните «производство»:

$ helm upgrade --install backend-app-1 --namespace prod-backend-app-1-ns --create-namespace -f app-1/env/prod/values.yaml app-1/

Проверьте его вход в Prod-Backend-App-1-NS Пространство имен, как мы настроим, не используйте ISTIO здесь:

$ kubectl -n prod-backend-app-1-ns get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
backend-app-1-alb  * aadca942-***-49478225.us-east-2.elb.amazonaws.com 80 4m54s

Для Dev Environment, обновите вход в проход, который мы создали в самом начале — это наш общий проникновение. Добавьте external-dns.alpha.kubernetes.io/hostname. Здесь поэтому Externdns создаст запись сопоставленной к этому LoadBancer:

...
    # ExternalDNS settings: [https://rtfm.co.ua/en/kubernetes-update-aws-route53-dns-from-an-ingress/](https://rtfm.co.ua/en/kubernetes-update-aws-route53-dns-from-an-ingress/)
    external-dns.alpha.kubernetes.io/hostname: "dev-app-1-test-common-ingress.example.com"
...

Подать заявление:

$ kubectl apply -f common-ingress-gateway.yaml
ingress.extensions/backend-common-alb configured

Проверьте маршруты ворот Istio Inhress — мы должны увидеть только разработки маршрутов:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-8459df68cb-bh76b — name http.80
NOTE: This output only contains routes loaded via RDS.
NAME DOMAINS MATCH VIRTUAL SERVICE
http.80 dev-app-1-test-common-ingress.example.com /* backend-app-1-virtualservice.dev-backend-app-1-ns

Или таким образом:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-8459df68cb-bh76b — name http.80 -o json | jq '.[].virtualHosts[].domains[0], .[].virtualHosts[].routes[].route.cluster'
"dev-app-1-test-common-ingress.example.com"
"outbound|80||backend-app-1-service.dev-backend-app-1-ns.svc.cluster.local"

И попробуйте получить доступ к URL-адресам приложения.

Продвигать

$ curl -I [https://prod-app-1-test-common-ingress.example.com](https://prod-app-1-test-common-ingress.example.com)
HTTP/2 200
date: Tue, 13 Apr 2021 12:47:15 GMT
content-type: text/html
server: nginx/1.13.8

Сервер: nginx/1.13.8 — Ответ, полученный от NGINX, и это означает, что запрос был отправлен через LoadBalancer непосредственно на службу приложения к его POD.

И dev:

$ curl -I [https://dev-app-1-test-common-ingress.example.com](https://dev-app-1-test-common-ingress.example.com)
HTTP/2 200
date: Tue, 13 Apr 2021 12:47:18 GMT
content-type: text/html
server: istio-envoy

Сервер: ISTIO-Engoy — Трафик прошел через общий LoadBalancer, затем на ворот IStio Inhress Gateway, затем к контейнеру SideCar с прокси-сервером посланника в POD с приложением.

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

В приложении-1/env/prod/values.yaml Изменить ISTIO. правда , Ingress.Nabled мы уже установили правда :

appConfig:
  name: "backend-app-1"
  version: "v1"
  url: "prod-app-1-test-common-ingress.example.com"

istio:
  enabled: true

ingress:
  enabled: true

Обновите настройку:

$ helm upgrade --install backend-app-1 --namespace prod-backend-app-1-ns --create-namespace -f app-1/env/prod/values.yaml app-1/

Проверьте маршруты ворот istio Inhress снова:

$ istioctl proxy-config routes -n istio-system istio-ingressgateway-8459df68cb-bh76b --name http.80
NOTE: This output only contains routes loaded via RDS.
NAME DOMAINS MATCH VIRTUAL SERVICE
http.80 dev-app-1-test-common-ingress.example.com /* backend-app-1-virtualservice.dev-backend-app-1-ns
http.80 prod-app-1-test-common-ingress.example.com /* backend-app-1-virtualservice.prod-backend-app-1-ns

Да, мы получаем новый маршрут до производства Backend.

Проверьте вход в Prod-Backend-App-1-NS пространство имен:

$ kubectl -n prod-backend-app-1-ns get ingress backend-app-1-alb
Error from server (NotFound): ingresses.extensions "backend-app-1-alb" not found

Хорошо, и проверьте ISTIO-SYSTEM пространство имен:

$ kubectl -n istio-system get ingress backend-app-1-alb
NAME CLASS HOSTS ADDRESS PORTS AGE
backend-app-1-alb  * aadca942-***-1554475105.us-east-2.elb.amazonaws.com 80 8m52s

Попробуй с Curl :

$ curl -I [https://prod-app-1-test-common-ingress.example.com](https://prod-app-1-test-common-ingress.example.com)
HTTP/2 200
date: Tue, 13 Apr 2021 13:14:34 GMT
content-type: text/html
server: istio-envoy

Сервер: ISTIO-Engoy — Отлично! Наш трафик сейчас проходит через ISTIO.

ISTIO и Externaldns

И последнее, что нужно использовать внешние значения с ISTIO.

В настоящее время при использовании общего входа и LoadBalancer мы можем указать хост/URL в аннотациях этого входа, но этот вход не пострадал от Helm Charts приложений, как это создано из выделенного манифеста Comment-Ingress-Gateway.yaml Отказ

Итак, чтобы иметь возможность создавать записи DNS во время развертываний приложения, нам нужно будет обновить аннотации общего входа, и это приводит к рекламу дополнительной автоматизации и сложности.

Вместо этого мы можем настроить внешние данные, когда он будет использовать не только входные аннотации, но и ресурсы ISTIO.

Давайте обновим его развертывание и добавьте --source = ISTIO-Gateway и/или --source = ISTIO-VirtualService см. Документацию Здесь >>> :

...
      containers:
      - args:
        - --log-level=info
        - --log-format=text
        - --events
        - --policy=upsert-only
        - --provider=aws
        - --registry=txt
        - --interval=2m
        - --source=service
        - --source=ingress
        - --source=istio-gateway
        - --source=istio-virtualservice
...

От Comment-Ingress-Gateway.yaml Удалить строку:

...
external-dns.alpha.kubernetes.io/hostname: "dev-app-1-test-common-ingress.example.com"
...

Теперь имя хоста будет установлено в воротах и/или виртуальномсервис, от spec.servers.hosts для шлюза или Spec.hosts для виртуальнойсервиса.

Кроме того, проверьте, могут ли Externaldns читать ресурсы ISTIO в его кластерроле Внешние DNS :

...
- apiGroups:
  - networking.istio.io
  resources:
  - virtualservices
  - gateways
  verbs:
  - get
  - list
  - watch
...

Externaldns не создает записи для Gateway и Virtualservice ISTIO: «Конечные точки не могут быть созданы»

Но здесь я столкнулся с проблемой.

Включить --debug В развертывании Externaldns и проверьте его журналы:

…
time="2021–04–14T12:53:05Z" level=debug msg="Adding event handler for Istio VirtualService"
time="2021–04–14T12:53:05Z" level=debug msg="Adding event handler for Istio Gateway"
time="2021–04–14T12:53:05Z" level=debug msg="Adding event handler for service"
time="2021–04–14T12:53:05Z" level=debug msg="Adding event handler for ingress"
…
level=debug msg="No endpoints could be generated from ingress istio-system/backend-common-alb"
…

Были созданы обработчики для ISTIO, поэтому Externdns может видеть обновления ISTIO, но не может создавать новые записи.

Это происходит из-за того, что служба Gateway Gateway Istio Angress создается с типом службы NodePort, чтобы он работал с общей LoadBalancer вместо DirectAlancer по умолчанию, и Externaldns не сможет разбирать виртуальный сервис, чтобы определить Конечные точки Kubernetes Для внешнего прогула, созданного из Comment-Ingress-Gateway.yaml Манифест.

Мы можем «исправить» это с небольшим взлом: укажите URL ALB непосредственно в аннотациях VirtualService.

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

Поэтому добавьте новое условие на виртуальный манифест — Если нет .values.ingress.enabled :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: {{ .Values.appConfig.name }}-virtualservice
  {{- if not .Values.ingress.enabled }}
  annotations:
    external-dns.alpha.kubernetes.io/target: {{ .Values.istio.externalURL }}
  {{- end }}
...

И установить значение для ISTIO.EXTERNALURL в app-1/env/dev/values.yaml Файл — это будет достаточно настойчивым и будет использоваться только для Dev Environment:

...
istio:
  enabled: true
  externalURL: "aadca942-istiosystem-backe-3ee2-700661912.us-east-2.elb.amazonaws.com"
...

В целом, сервис, шлюз и виртуальныйсервис будут иметь такой манифест:

-------- 
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.appConfig.name }}-service
spec:
  {{- if .Values.ingress.enabled }}
  type: NodePort
  {{- end }}
  selector:
    app: {{ .Values.appConfig.name }}
  ports:
    - name: http
      protocol: TCP
      port: 80

{{- if .Values.istio.enabled }}
-------- 
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: {{ .Values.appConfig.name }}-gateway
spec:
  selector:
    istio: ingressgateway
  servers:  
  - port:
      number: 80
      name: http 
      protocol: HTTP
    hosts:
    - "*"
--------       
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: {{ .Values.appConfig.name }}-virtualservice
  {{- if not .Values.ingress.enabled }}
  annotations:
    external-dns.alpha.kubernetes.io/target: {{ .Values.istio.externalURL }}
  {{- end }}
spec:
  hosts:
  - {{ .Values.appConfig.url | quote }}
  gateways:
  - {{ .Values.appConfig.name }}-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: {{ .Values.appConfig.name }}-service
        port:
          number: 80
{{- end }}

Разверните его и проверьте журналы ExternalDns:

…
time="2021–04–14T13:05:00Z" level=info msg="Desired change: CREATE dev-app-1-test-common-ingress.example.com A [Id: /hostedzone/Z30KLN6M3D0LB6]"
time="2021–04–14T13:05:00Z" level=info msg="Desired change: CREATE dev-app-1-test-common-ingress.example.com TXT [Id: /hostedzone/Z30KLN6M3D0LB6]"
…

Попробуйте еще раз с завитым:

$ curl -I [https://dev-app-1-test-common-ingress.example.com](https://dev-app-1-test-common-ingress.example.com)
HTTP/2 200
date: Wed, 14 Apr 2021 13:21:11 GMT
content-type: text/html
server: istio-envoy

Все сделано.

Первоначально опубликовано в RTFM: Linux, DevOps и системное управление Отказ

Оригинал: «https://dev.to/setevoy/istio-shared-ingress-aws-alb-helm-chart-with-conditions-istio-and-externaldns-32n8»