#Alauda Build of Kiali

#Использование Alauda Build of Kiali

Alauda Build of Kiali предоставляет возможности наблюдаемости и визуализации для приложений, развернутых внутри сервисной сетки. После добавления приложения в mesh, Alauda Build of Kiali можно использовать для анализа потоков трафика и мониторинга поведения mesh.

#О Kiali

Alauda Build of Kiali основан на open source проекте Kiali и служит консолью управления для Alauda Service Mesh.

Он предоставляет:

• Визуализацию топологии mesh и потоков трафика в реальном времени
• Информацию о состоянии здоровья приложений и метриках производительности
• Централизованный доступ к инструментам конфигурации и валидации
• Интеграцию с Grafana для дашбордов метрик
• Поддержку распределённого трассирования через Jaeger или OpenTelemetry

Эти возможности позволяют пользователям диагностировать поведение сервисов, выявлять потенциальные проблемы и оптимизировать конфигурацию mesh из единого интерфейса.

#Установка Alauda Build of Kiali

Ниже приведены шаги по установке Alauda Build of Kiali.

#Установка через веб-консоль

Требования

• Alauda Build of Kiali должен быть загружен.
• Вы вошли в веб-консоль Alauda Container Platform под пользователем с ролью cluster-admin.

Процедура

1. В веб-консоли Alauda Container Platform перейдите в раздел Administrator.
2. Выберите Marketplace > OperatorHub.
3. Найдите Alauda Build of Kiali.
4. Выберите Alauda Build of Kiali.
5. Нажмите Install.
6. Подтвердите установку, нажав Install и Confirm.

Проверка

Убедитесь, что статус установки оператора отображается как Succeeded в разделе Installation Info.

#Установка через CLI

Требования

• Alauda Build of Kiali должен быть загружен.
• Активная сессия ACP CLI (kubectl) под администратором кластера с ролью cluster-admin.

Процедура

1. Проверка доступных версий

   (
     echo -e "CHANNEL\tNAME\tVERSION"
     kubectl get packagemanifest kiali-operator -o json | jq -r '
       .status.channels[] |
       .name as $channel |
       .entries[] |
       [$channel, .name, .version] | @tsv
     '
   ) | column -t -s $'\t'

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

   CHANNEL  NAME                       VERSION
   stable   kiali-operator.v2.17.1-r1  2.17.1-r1

   Пояснения к полям:

   • CHANNEL: имя канала оператора
   • NAME: имя ресурса CSV
   • VERSION: версия оператора

2. Подтверждение catalogSource

   kubectl get packagemanifests kiali-operator -ojsonpath='{.status.catalogSource}'

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

   platform

   Это означает, что kiali-operator поступает из catalogSource platform.

3. Создание namespace

   kubectl get namespace kiali-operator || kubectl create namespace kiali-operator

4. Создание Subscription

   kubectl apply -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     annotations:
       cpaas.io/target-namespaces: ""
     labels:
       catalog: platform
     name: kiali-operator
     namespace: kiali-operator
   spec:
     channel: stable
     installPlanApproval: Manual
     name: kiali-operator
     source: platform
     sourceNamespace: cpaas-system
     startingCSV: kiali-operator.v2.17.1-r1
   EOF

   Объяснение полей

   • annotation cpaas.io/target-namespaces: рекомендуется оставлять пустым; пустое значение означает установку на весь кластер.
   • .metadata.name: имя Subscription (должно соответствовать DNS, максимум 253 символа).
   • .metadata.namespace: namespace для установки оператора.
   • .spec.channel: канал оператора для подписки.
   • .spec.installPlanApproval: стратегия одобрения (Manual или Automatic). Здесь Manual требует ручного подтверждения установки/обновления.
   • .spec.source: catalogSource оператора.
   • .spec.sourceNamespace: должно быть cpaas-system, так как все catalogSource платформы находятся в этом namespace.
   • .spec.startingCSV: версия для установки при ручном одобрении; если пусто, устанавливается последняя версия в канале. Не требуется для автоматического одобрения.

5. Проверка статуса Subscription

   kubectl -n kiali-operator get subscriptions kiali-operator -o yaml

   Ключевые поля вывода

   • .status.state: UpgradePending означает, что оператор ожидает установки или обновления.
   • Condition InstallPlanPending = True: ожидание ручного одобрения.
   • .status.currentCSV: последняя подписанная CSV.
   • .status.installPlanRef: связанный InstallPlan, который должен быть одобрен перед установкой.

   Ожидайте, пока условие InstallPlanPending станет True:

   kubectl -n kiali-operator wait --for=condition=InstallPlanPending subscription kiali-operator --timeout=2m

6. Одобрение InstallPlan

   kubectl -n kiali-operator get installplan \
     "$(kubectl -n kiali-operator get subscriptions kiali-operator -o jsonpath='{.status.installPlanRef.name}')"

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

   NAME            CSV                         APPROVAL   APPROVED
   install-ddh84   kiali-operator.v2.17.1-r1   Manual     false

   Ручное одобрение

   PLAN="$(kubectl -n kiali-operator get subscription kiali-operator -o jsonpath='{.status.installPlanRef.name}')"
   kubectl -n kiali-operator patch installplan "$PLAN" --type=json -p='[{"op": "replace", "path": "/spec/approved", "value": true}]'

Проверка

Ожидайте создания CSV; фаза должна измениться на Succeeded:

kubectl wait --for=jsonpath='{.status.phase}'=Succeeded csv --all -n kiali-operator --timeout=3m

Проверьте статус CSV:

kubectl -n kiali-operator get csv

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

NAME                        DISPLAY                 VERSION     REPLACES   PHASE
kiali-operator.v2.17.1-r1   Alauda Build of Kiali   2.17.1-r1              Succeeded

Пояснения к полям

• NAME: имя установленного CSV
• DISPLAY: отображаемое имя оператора
• VERSION: версия оператора
• REPLACES: CSV, заменённый при обновлении
• PHASE: статус установки (Succeeded означает успешную установку)

#Настройка мониторинга с Kiali

Ниже описаны шаги по интеграции Alauda Build of Kiali с мониторингом пользовательских нагрузок.

Требования

• Установлен Alauda Service Mesh.
• Настроен мониторинг с Service Mesh. См. Configuring Monitoring with Service Mesh.
• Установлен Alauda Build of Kiali.

Процедура

# CA-сертификат для ACP в base64-кодировке
kubectl -ncpaas-system get secret dex.tls -o jsonpath='{.data.ca\.crt}'

export PLATFORM_URL=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.platformURL}')
export CLUSTER_NAME=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.clusterName}')
export ALB_CLASS_NAME=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.systemAlbIngressClassName}')

export OIDC_ISSUER=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcIssuer}')
export OIDC_CLIENT_ID=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcClientID}')
export OIDC_CLIENT_SECRET=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcClientSecret}')

export MONITORING_URL=$(kubectl get feature monitoring -o jsonpath='{.spec.accessInfo.database.address}')

kubectl create secret generic kiali --from-literal="oidc-secret=$OIDC_CLIENT_SECRET" -nistio-system

secret/kiali created

SECRET_NAME=$(kubectl get feature monitoring -o jsonpath='{.spec.accessInfo.database.basicAuth.secretName}')

AUTH_USERNAME=$(kubectl -ncpaas-system get secret "$SECRET_NAME" -o jsonpath="{.data.username}" | base64 -d)
AUTH_PASSWORD=$(kubectl -ncpaas-system get secret "$SECRET_NAME" -o jsonpath="{.data.password}" | base64 -d)

kubectl create secret generic "kiali-monitoring-basic-auth" \
  --from-literal="username=$AUTH_USERNAME" \
  --from-literal="password=$AUTH_PASSWORD" \
  -n istio-system

secret/kiali-monitoring-basic-auth created

kubectl label namespace istio-system cpaas.io/project=cpaas-system --overwrite

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
  namespace: istio-system
spec:
  server:
    web_port: "443"
    web_root: /clusters/${CLUSTER_NAME}/kiali
  auth:
    openid:
      api_proxy: ${PLATFORM_URL}/kubernetes/${CLUSTER_NAME}
      api_proxy_ca_data: ${PLATFORM_CA}
      insecure_skip_verify_tls: true
      issuer_uri: ${OIDC_ISSUER}
      client_id: ${OIDC_CLIENT_ID}
      username_claim: email
    strategy: openid
  deployment:
    view_only_mode: false
    replicas: 1
    resources:
      requests:
        cpu: "100m"
        memory: "64Mi"
      limits:
        cpu: "2000m"
        memory: "1Gi"
    ingress:
      enabled: true
      class_name: ${ALB_CLASS_NAME}
  external_services:
    grafana:
      enabled: false  # Since Grafana is not bundled in ACP anymore, it is disabled by default
    prometheus:
      # query_scope only required in multi cluster
      # query_scope:
      #   mesh_id: <mesh_id>
      auth:
        type: basic
        username: secret:kiali-monitoring-basic-auth:username
        password: secret:kiali-monitoring-basic-auth:password
        insecure_skip_verify: true
      # Define thanos_proxy if Prometheus is to be queried through a Thanos proxy (it is required when using VictoriaMetrics)
      thanos_proxy:
        enabled: true
        retention_period: 7d
        scrape_interval: 60s
      url: ${MONITORING_URL}
  kiali_feature_flags:
    ui_defaults:
      i18n:
        language: en
        show_selector: true

# Замените <platform-ca> на реальный base64-кодированный CA-сертификат, сохранённый ранее.
export PLATFORM_CA=<platform-ca>

envsubst < kiali.yaml | kubectl apply -f -

#Интеграция платформы распределённого трассирования с Alauda Build of Kiali

После интеграции с платформой распределённого трассирования Alauda Build of Kiali позволяет визуализировать трассы запросов непосредственно в консоли Kiali. Эти трассы дают представление о межсервисном взаимодействии внутри сервисной сетки и помогают выявлять задержки, сбои или узкие места в путях запросов.

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

Требования

• Установлен Alauda Service Mesh.
• Установлена и успешно настроена платформа распределённого трассирования, например Alauda Build of Jaeger.

Процедура

1. Обновите конфигурацию spec ресурса Kiali для трассирования:

   Пример конфигурации spec ресурса Kiali для трассирования

   spec:
     external_services:
       tracing:
         # query_scope only required in multi cluster
         # query_scope:
           # istio.mesh_id: <mesh_id>
         enabled: true
         provider: jaeger
         use_grpc: true
         internal_url: "http://jaeger-prod-query.istio-system:16685/jaeger"
         # When external_url is not defined, disable_version_check should be set to true
         disable_version_check: true
         # (Optional) Public facing URL of Jaeger
         # external_url: "<platform-url>/clusters/<cluster>/istio/jaeger"
   1. Требуется в мультикластерной mesh. <mesh_id> должен совпадать с .spec.values.global.meshId в ресурсе Istio.
   2. Определяет, включено ли трассирование.
   3. Указывает провайдера трассирования (jaeger или tempo).
   4. Указывает внутренний URL API Jaeger или Tempo.
   5. external_url используется UI Kiali для отображения ссылок на интерфейс трассирования. Этот URL должен быть доступен клиентам вне кластера (например, браузеру) для генерации корректных ссылок.

2. Сохраните обновлённый spec в файл kiali_cr.yaml.

3. Выполните команду для применения конфигурации:

   kubectl -nistio-system patch kiali kiali --type merge -p "$(cat kiali_cr.yaml)"

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

   kiali.kiali.io/kiali patched

Проверка

1. Перейдите в UI Kiali.
2. Откройте вкладку Workload Traces для просмотра трасс в UI Kiali.