#Установка шлюза с помощью внедрения шлюза

В этой процедуре объясняется, как установить шлюз с помощью внедрения шлюза.

#Предварительные требования

• Установлен оператор Alauda Service Mesh v2.
• Развернута управляющая плоскость Istio.
• Подтвердите совместимость с ядром Linux.
• Подтвердите требования к Namespace.

#Процедура

1. Создайте namespace для шлюза:

   kubectl create namespace <gateway_namespace>
   NOTE

   Устанавливайте шлюз и управляющую плоскость Istio в разных пространствах имён.

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

2. Создайте YAML-файл с именем secret-reader.yaml, который определяет service account, роль и привязку роли для развертывания шлюза. Эти настройки позволяют шлюзу читать секреты, что необходимо для получения TLS-учётных данных.

   secret-reader.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: secret-reader
     namespace: <gateway_namespace>
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-reader
     namespace: <gateway_namespace>
   rules:
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["get", "watch", "list"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name:  secret-reader
     namespace: <gateway_namespace>
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: secret-reader
   subjects:
     - kind: ServiceAccount
       name:  secret-reader

3. Примените YAML-файл, выполнив следующую команду:

   kubectl apply -f secret-reader.yaml

4. Создайте YAML-файл с именем gateway-deployment.yaml, который определяет объект Kubernetes Deployment для шлюза.

   gateway-deployment.yaml

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: <gateway_name>
     namespace: <gateway_namespace>
   spec:
     selector:
       matchLabels:
         istio: <gateway_name>
     template:
       metadata:
         annotations:
           inject.istio.io/templates: gateway
         labels:
           istio: <gateway_name>
           sidecar.istio.io/inject: "true"
       spec:
         containers:
           - name: istio-proxy
             image: auto
             securityContext:
               capabilities:
                 drop:
                   - ALL
               allowPrivilegeEscalation: false
               privileged: false
               readOnlyRootFilesystem: true
               runAsNonRoot: true
             ports:
               - containerPort: 15090
                 protocol: TCP
                 name: http-envoy-prom
             resources:
               limits:
                 cpu: 2000m
                 memory: 1024Mi
               requests:
                 cpu: 100m
                 memory: 128Mi
         serviceAccountName: secret-reader
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
           - effect: NoSchedule
             key: node-role.kubernetes.io/infra
             value: reserved
             operator: Equal
   1. Указывает, что управляющая плоскость Istio использует шаблон внедрения шлюза вместо шаблона sidecar по умолчанию.
   2. Убедитесь, что для развертывания шлюза установлен уникальный label. Уникальный label необходим, чтобы ресурсы Istio Gateway могли выбирать рабочие нагрузки шлюза.
   3. Включает внедрение шлюза, устанавливая label sidecar.istio.io/inject в значение true. Если имя ресурса Istio не является default, необходимо использовать label istio.io/rev: <istio_revision>, где revision — активная ревизия ресурса Istio.
   4. Устанавливает поле image в значение auto, чтобы образ автоматически обновлялся при каждом запуске pod.
   5. Устанавливает serviceAccountName в имя ранее созданного ServiceAccount.
   6. (Опционально) Устанавливает node selectors для планирования pod шлюза на Infra Nodes.
   7. (Опционально) Устанавливает tolerations, чтобы разрешить планирование pod шлюза на Infra Nodes.

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

   kubectl apply -f gateway-deployment.yaml

6. Проверьте успешность развертывания Deployment шлюза, выполнив следующую команду:

   kubectl rollout status deployment/<gateway_name> -n <gateway_namespace>

   Вы должны увидеть вывод, похожий на следующий:

   Пример вывода

   Waiting for deployment "<gateway_name>" rollout to finish: 0 of 1 updated replicas are available...
   deployment "<gateway_name>" successfully rolled out

7. Создайте YAML-файл с именем gateway-service.yaml, который содержит объект Kubernetes Service для шлюза.

   gateway-service.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: <gateway_name>
     namespace: <gateway_namespace>
   spec:
     type: ClusterIP
     selector:
       istio: <gateway_name>
     ports:
       - name: status-port
         port: 15021
         protocol: TCP
         targetPort: 15021
       - name: http2
         port: 80
         protocol: TCP
         targetPort: 80
       - name: https
         port: 443
         protocol: TCP
         targetPort: 443
   1. При установке spec.type в ClusterIP объект Service шлюза доступен только внутри кластера. Если шлюз должен обрабатывать входящий трафик извне кластера, установите spec.type в LoadBalancer.
   2. Установите selector в уникальный label или набор label, указанных в шаблоне pod развертывания шлюза, созданного ранее.

8. Примените YAML-файл, выполнив следующую команду:

   kubectl apply -f gateway-service.yaml

9. Проверьте, что сервис шлюза нацелен на endpoint pod шлюза, выполнив следующую команду:

   kubectl get endpoints <gateway_name> -n <gateway_namespace>

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

Пример вывода

NAME              ENDPOINTS                                             AGE
<gateway_name>    10.131.0.181:15021,10.131.0.181:80,10.131.0.181:443   1m

10. Опционально: Создайте YAML-файл с именем gateway-hpa.yaml, который определяет горизонтальный автоскейлер pod для шлюза. В следующем примере минимальное количество реплик установлено в 2, максимальное — в 5, а масштабирование вверх происходит при превышении средней загрузки CPU 80% от лимита ресурсов CPU. Этот лимит указан в шаблоне pod развертывания шлюза.

    gateway-hpa.yaml

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      minReplicas: 2
      maxReplicas: 5
      metrics:
      - resource:
          name: cpu
          target:
            averageUtilization: 80
            type: Utilization
        type: Resource
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <gateway_name>
    1. Установите spec.scaleTargetRef.name в имя ранее созданного развертывания шлюза.

11. Опционально: Примените YAML-файл, выполнив следующую команду:

    kubectl apply -f gateway-hpa.yaml

12. Опционально: Создайте YAML-файл с именем gateway-pdb.yaml, который определяет Pod Disruption Budget для шлюза. В следующем примере допускается эвакуация pod шлюза только в том случае, если после эвакуации в кластере останется как минимум 1 здоровый pod шлюза.

    gateway-pdb.yaml

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: <gateway_name>
      namespace: <gateway_namespace>
    spec:
      minAvailable: 1
      selector:
        matchLabels:
          istio: <gateway_name>
    1. Установите spec.selector.matchLabels в уникальный label или набор label, указанных в шаблоне pod развертывания шлюза, созданного ранее.

13. Опционально: Примените YAML-файл, выполнив следующую команду:

    kubectl apply -f gateway-pdb.yaml