Руководство по системному администрированию#

Термины и определения#

Термин/аббревиатура	Определение
Платформа	Платформа оркестрации приложений со средствами автоматизации и управления на основе политик, например Kubernetes
Istio SE	Настраиваемая сервисная сетка с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в кластере Kubernetes
Проект / namespace	Изолированная область (пространство имен) в кластере Kubernetes, предназначенная для разграничения доступа к ресурсам кластера (deployment, service, и т.д.)
Контрольная панель	Namespace, где запущены управляющие приложения (компонент POLM)
Управление политиками / POLM	Компонент Управление политиками
Граничный прокси / IGEG	Компонент Граничный прокси
Сервисный прокси / SVPX	Компонент Сервисный прокси
Ingress Gateway	Входная точка в namespace компонента IGEG
Egress Gateway	Выходная точка из namespace компонента IGEG
istio-proxy	Граничный прокси — контейнер, предназначенный для маршрутизации трафика
Deployment	Набор инструкций для запуска приложения в Kubernetes
Pod	Набор контейнеров внутри узла кластера Kubernetes
Дамп конфигурации	Снимок информации о состоянии конфигурации
TLS	Transport Layer Security, протокол защиты транспортного уровня

Сценарии администрирования#

Для администрирования программного компонента Граничный прокси используются:

дамп конфигурации приложений Ingress и Egress;
журнал приложений Ingress и Egress;
просмотр конфигурационных файлов: VirtualService, Gateway, ServiceEntry, DestinationRule и т.д.;
просмотр метрик.

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

Сценарий 1. Получение дампа конфигурации приложений Ingress и Egress#

В зависимости от наполнения образов компонентов IGEG существуют разные способы получения дампа конфигурации.

Способ 1.#

Если в контейнере istio-proxy приложения Ingress или Egress доступна исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, то можно зайти в терминал контейнера и выполнить команду:

curl localhost:15000/config_dump

При этом весь дамп конфигурации, который может занимать несколько мегабайт, отобразится на экране. Можно выполнить поиск необходимого элемента:

curl localhost:15000/config_dump | grep -C 10 "starttls"

Способ 2.#

Если в контейнере istio-proxy нет исполняемой оболочки, но есть утилита curl, то можно выполнить команду удаленно через клиентскую утилиту kubectl:

kubectl exec <IGEG_pod_name> -c istio-proxy -n <namespace_name> -- curl localhost:15000/config_dump

Также можно перенаправить вывод команды в файл:

kubectl exec egress-794688bfb5-vmpcg -c istio-proxy -n syn-test -- curl localhost:15000/config_dump > ./egress_dump.json

Аналогично можно воспользоваться клиентской утилитой istioctl (поставляется в дистрибутиве) и командой proxy-config (сокращенная форма - pc):

istioctl proxy-config all <IGEG_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> -o <output_format>

где формат вывода результата <output_format> может быть одним из следующих значений: json, yaml, short.

Файл kubeconfig по умолчанию находится по пути ~/.kube/config.

Пример:

istioctl pc all egress-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test -o json > ./egress_dump.json

Способ 3.#

Если в контейнере istio-proxy недоступны исполняемая оболочка и curl, можно воспользоваться клиентской утилитой kubectl и выполнить команду /usr/local/bin/pilot-agent request:

kubectl exec <IGEG_pod_name> -c istio-proxy -n <namespace_name>  -- /usr/local/bin/pilot-agent request GET /config_dump

Пример:

kubectl exec egress-794688bfb5-vmpcg -c istio-proxy -n syn-test -- /usr/local/bin/pilot-agent request GET /config_dump > ./egress_dump.json

Способ 4.#

Если в контейнере istio-proxy недоступны исполняемая оболочка и curl, можно запустить интерфейс администратора для istio-proxy командой istioctl dashboard envoy:

istioctl dashboard envoy <IGEG_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> --port=<port_value> --browser=<open_browser>

где:

флаг --port отвечает за то, по какому порту будет выполняться обращение к интерфейсу (значение по умолчанию - 15000),
флаг --browser принимает значения true или false, при значении true в браузере пользователя откроется окно с интерфейсом администратора.

Флаги --port и --browser опциональны.

После выполнения команды на рабочей машине пользователя будет создано подключение к удаленному контейнеру. Интерфейс можно будет открыть в браузере по адресу localhost:<port_value>.

Пример:

istioctl dashboard envoy egress-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test

В данном примере в браузере откроется окно с адресом http://localhost:15000, где будет доступен интерфейс администратора istio-proxy.

Model

Чтобы завершить подключение к контейнеру, достаточно выключить процесс (выполнить Ctrl + C в консоли).

Сценарий 2. Просмотр дополнительных сведений о конфигурации Envoy в составе приложений Ingress и Egress#

Дополнительная информация о состоянии Envoy в составе IGEG может быть получена обращением к api Envoy, расположенному по адресу localhost:15000/ в контейнере istio-proxy.

Способ 1.#

Если в образе IGEG есть исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, то можно зайти в терминал контейнера istio-proxy и выполнить команду:

curl localhost:15000/help

Способ 2.#

Если в образе IGEG нет исполняемой оболочки, но есть утилита curl, то можно подключиться к api Envoy удаленно с помощью клиентской утилиты kubectl:

kubectl exec <IGEG_pod_name> -c istio-proxy -n <namespace_name>  -- curl localhost:15000/help

Пример:

kubectl exec egress-794688bfb5-vmpcg -c istio-proxy -n syn-test -- curl localhost:15000/help

Способ 3.#

Если в образе IGEG нет исполняемой оболочки и утилиты curl, то можно подключиться к api Envoy удаленно с помощью клиентской утилиты kubectl и команды:

kubectl exec <IGEG_pod_name> -c istio-proxy -n <namespace_name>  -- /usr/local/bin/pilot-agent request GET /help

Пример:

kubectl exec egress-794688bfb5-vmpcg -c istio-proxy -n syn-test -- /usr/local/bin/pilot-agent request GET /help

В результате будет выведен список доступных команд:

admin commands are:
  /: Admin home page
  /certs: print certs on machine
  /clusters: upstream cluster status
  /config_dump: dump current Envoy configs (experimental)
      resource: The resource to dump
      mask: The mask to apply. When both resource and mask are specified, the mask is applied to every element in the desired repeated field so that only a subset of fields are returned. The mask is parsed as a ProtobufWkt::FieldMask
      name_regex: Dump only the currently loaded configurations whose names match the specified regex. Can be used with both resource and mask query parameters.
      include_eds: Dump currently loaded configuration including EDS. See the response definition for more information
  /contention: dump current Envoy mutex contention stats (if enabled)
  /cpuprofiler (POST): enable/disable the CPU profiler
      enable: enables the CPU profiler; One of (y, n)
  /drain_listeners (POST): drain listeners
      graceful: When draining listeners, enter a graceful drain period prior to closing listeners. This behaviour and duration is configurable via server options or CLI
      inboundonly: Drains all inbound listeners. traffic_direction field in envoy_v3_api_msg_config.listener.v3.Listener is used to determine whether a listener is inbound or outbound.
  /healthcheck/fail (POST): cause the server to fail health checks
  /healthcheck/ok (POST): cause the server to pass health checks
  /heap_dump: dump current Envoy heap (if supported)
  /heapprofiler (POST): enable/disable the heap profiler
      enable: enable/disable the heap profiler; One of (y, n)
  /help: print out list of admin commands
  /hot_restart_version: print the hot restart compatibility version
  /init_dump: dump current Envoy init manager information (experimental)
      mask: The desired component to dump unready targets. The mask is parsed as a ProtobufWkt::FieldMask. For example, get the unready targets of all listeners with /init_dump?mask=listener`
  /listeners: print listener info
      format: File format to use; One of (text, json)
  /logging (POST): query/change logging levels
      paths: Change multiple logging levels by setting to <logger_name1>:<desired_level1>,<logger_name2>:<desired_level2>.
      level: desired logging level; One of (, trace, debug, info, warning, error, critical, off)
  /memory: print current allocation/heap usage
  /quitquitquit (POST): exit the server
  /ready: print server state, return 200 if LIVE, otherwise return 503
  /reopen_logs (POST): reopen access logs
  /reset_counters (POST): reset all counters to zero
  /runtime: print runtime values
  /runtime_modify (POST): Adds or modifies runtime values as passed in query parameters. To delete a previously added key, use an empty string as the value. Note that deletion only applies to overrides added via this endpoint; values loaded from disk can be modified via override but not deleted. E.g. ?key1=value1&key2=value2...
  /server_info: print server version/status information
  /stats: print server stats
      usedonly: Only include stats that have been written by system since restart
      filter: Regular expression (Google re2) for filtering stats
      format: Format to use; One of (html, text, json)
      type: Stat types to include.; One of (All, Counters, Histograms, Gauges, TextReadouts)
      histogram_buckets: Histogram bucket display mode; One of (cumulative, disjoint, none)
  /stats/prometheus: print server stats in prometheus format
      usedonly: Only include stats that have been written by system since restart
      text_readouts: Render text_readouts as new gaugues with value 0 (increases Prometheus data size)
      filter: Regular expression (Google re2) for filtering stats
  /stats/recentlookups: Show recent stat-name lookups
  /stats/recentlookups/clear (POST): clear list of stat-name lookups and counter
  /stats/recentlookups/disable (POST): disable recording of reset stat-name lookup names
  /stats/recentlookups/enable (POST): enable recording of reset stat-name lookup names

С помощью этих команд можно посмотреть все сертификаты Envoy:

curl localhost:15000/certs

или количество текущих и закрытых соединений к конкретному адресу:

curl localhost:15000/clusters | grep postgres-db-svc | grep "cx_active\|cx_total\|rq_active\|rq_total"

Сценарий 3. Просмотр дополнительных сведений о конфигурации Service Mesh#

Дополнительная информация о состоянии Service Mesh может быть получена с помощью клиентской утилиты istioctl.

Чтобы получить список всех доступных команд, в терминале рабочей машины пользователя необходимо выполнить:

istioctl help

Результат выполнения:

Istio configuration command line utility for service operators to
debug and diagnose their Istio mesh.

Usage:
  istioctl [command]

Available Commands:
  admin                Manage control plane (istiod) configuration
  analyze              Analyze Istio configuration and print validation messages
  authz                (authz is experimental. Use `istioctl experimental authz`)
  bug-report           Cluster information and log capture support tool.
  completion           Generate the autocompletion script for the specified shell
  create-remote-secret Create a secret with credentials to allow Istio to access remote Kubernetes apiservers
  dashboard            Access to Istio web UIs
  experimental         Experimental commands that may be modified or deprecated
  help                 Help about any command
  install              Applies an Istio manifest, installing or reconfiguring Istio on a cluster.
  kube-inject          Inject Istio sidecar into Kubernetes pod resources
  manifest             Commands related to Istio manifests
  operator             Commands related to Istio operator controller.
  profile              Commands related to Istio configuration profiles
  proxy-config         Retrieve information about proxy configuration from Envoy [kube only]
  proxy-status         Retrieves the synchronization status of each Envoy in the mesh [kube only]
  remote-clusters      Lists the remote clusters each istiod instance is connected to.
  tag                  Command group used to interact with revision tags
  uninstall            Uninstall Istio from a cluster
  upgrade              Upgrade Istio control plane in-place
  validate             Validate Istio policy and rules files
  verify-install       Verifies Istio Installation Status
  version              Prints out build version information

Flags:
      --context string          The name of the kubeconfig context to use
  -h, --help                    help for istioctl
  -i, --istioNamespace string   Istio system namespace (default "istio-system")
  -c, --kubeconfig string       Kubernetes configuration file
  -n, --namespace string        Config namespace
      --vklog Level             number for the log level verbosity. Like -v flag. ex: --vklog=9

Additional help topics:
  istioctl options                           Displays istioctl global options

Use "istioctl [command] --help" for more information about a command.

Можно запросить информацию о доступных опциях каждой конкретной команды в составе istioctl. Для просмотра состояния IGEG и SVPX используется команда istioctl proxy-config:

$ istioctl proxy-config help
A group of commands used to retrieve information about proxy configuration from the Envoy config dump

Usage:
  istioctl proxy-config [command]

Aliases:
  proxy-config, pc

Examples:
  # Retrieve information about proxy configuration from an Envoy instance.
  istioctl proxy-config <clusters|listeners|routes|endpoints|bootstrap|log|secret> <pod-name[.namespace]>

Available Commands:
  all            Retrieves all configuration for the Envoy in the specified pod
  bootstrap      Retrieves bootstrap configuration for the Envoy in the specified pod
  cluster        Retrieves cluster configuration for the Envoy in the specified pod
  ecds           Retrieves typed extension configuration for the Envoy in the specified pod
  endpoint       Retrieves endpoint configuration for the Envoy in the specified pod
  listener       Retrieves listener configuration for the Envoy in the specified pod
  log            (experimental) Retrieves logging levels of the Envoy in the specified pod
  rootca-compare Compare ROOTCA values for the two given pods
  route          Retrieves route configuration for the Envoy in the specified pod
  secret         Retrieves secret configuration for the Envoy in the specified pod

Flags:
  -h, --help                   help for proxy-config
  -o, --output string          Output format: one of json|yaml|short (default "short")
      --proxy-admin-port int   Envoy proxy admin port (default 15000)

Global Flags:
      --context string          The name of the kubeconfig context to use
  -i, --istioNamespace string   Istio system namespace (default "istio-system")
  -c, --kubeconfig string       Kubernetes configuration file
  -n, --namespace string        Config namespace
      --vklog Level             number for the log level verbosity. Like -v flag. ex: --vklog=9

Use "istioctl proxy-config [command] --help" for more information about a command.

С ее помощью можно просмотреть статус endpoints, доступных на выбранном istio-proxy:

istioctl proxy-config endpoint egress-794688bfb5-vmpcg -n syn-test

или просмотреть кластеры, объявленные в конфигурации Envoy:

istioctl pc cluster egress-794688bfb5-vmpcg -n syn-test

Сценарий 4. Настройка логирования на Ingress и Egress#

В каждом контейнере istio-proxy компонента IGEG можно направить вывод всех 3 типов логов в файлы и настроить их ротацию.

Есть 2 способа настройки:

с помощью создания сущности EnvoyFilter в прикладном namespace и настройки deployments;
с помощью внесения изменений в IstioOperator, создания сущности Telemetry в прикладном namespace и настройки deployments.

Способ 1. EnvoyFilter#

Для настройки вывода access-логов Envoy в файл создайте ресурс EnvoyFilter, который может быть применен ко всем приложениям namespace или к одному из них.

Пример:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: envoy-access-logs
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          access_log:
          - name: envoy.access_loggers.file
            typedConfig:
              '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: /etc/istio/proxy/access.log
              # jsonFormat:
              #   businessID: '%REQ(ufs-business-id)%'
              #   clientID: '%REQ(ufs-client-id)%'
              #   message: '%BYTES_RECEIVED%'
              #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
              #   requestUid: '%REQ(x-request-chain-id)%'
              #   sessionLogin: '%REQ(ufs-user-login)%'
              #   sessionUid: '%REQ(ufs-forward-sid)%'
              #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
              logFormat:
                textFormatSource:
                  inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.tcp_proxy
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          access_log:
          - name: envoy.access_loggers.file
            typedConfig:
              '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: /etc/istio/proxy/access.log
              # jsonFormat:
              #   businessID: '%REQ(ufs-business-id)%'
              #   clientID: '%REQ(ufs-client-id)%'
              #   message: '%BYTES_RECEIVED%'
              #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
              #   requestUid: '%REQ(x-request-chain-id)%'
              #   sessionLogin: '%REQ(ufs-user-login)%'
              #   sessionUid: '%REQ(ufs-forward-sid)%'
              #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
              logFormat:
                textFormatSource:
                  inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
  - applyTo: LISTENER
    match:
      context: ANY
    patch:
      operation: MERGE
      value:
        access_log:
        - name: envoy.access_loggers.file
          typedConfig:
            '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            path: /etc/istio/proxy/access.log
            # jsonFormat:
            #   businessID: '%REQ(ufs-business-id)%'
            #   clientID: '%REQ(ufs-client-id)%'
            #   message: '%BYTES_RECEIVED%'
            #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
            #   requestUid: '%REQ(x-request-chain-id)%'
            #   sessionLogin: '%REQ(ufs-user-login)%'
            #   sessionUid: '%REQ(ufs-forward-sid)%'
            #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
            logFormat:
              textFormatSource:
                inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"

Если в проекте настроено подключение к кластеру kafka с помощью указания протокола kafka в портах Gateway и ServiceEntry (доработка POLM в версии 3.9.1), то в EnvoyFilter необходимо добавить следующий код:

  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.kafka_proxy
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.kafka_proxy
        typed_config:
          '@type': type.googleapis.com/udpa.type.v1.TypedStruct
          type_url: type.googleapis.com/envoy.extensions.filters.network.kafka_proxy.v3.KafkaProxy
          value:
            access_log:
            - name: envoy.access_loggers.file
              typedConfig:
                '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                path: /dev/stdout
                # jsonFormat:
                #   businessID: '%REQ(ufs-business-id)%'
                #   clientID: '%REQ(ufs-client-id)%'
                #   message: '%BYTES_RECEIVED%'
                #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
                #   requestUid: '%REQ(x-request-chain-id)%'
                #   sessionLogin: '%REQ(ufs-user-login)%'
                #   sessionUid: '%REQ(ufs-forward-sid)%'
                #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
                logFormat:
                  textFormatSource:
                    inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
            - name: envoy.access_loggers.file
              typedConfig:
                '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                path: /etc/istio/proxy/access.log
                # jsonFormat:
                #   businessID: '%REQ(ufs-business-id)%'
                #   clientID: '%REQ(ufs-client-id)%'
                #   message: '%BYTES_RECEIVED%'
                #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
                #   requestUid: '%REQ(x-request-chain-id)%'
                #   sessionLogin: '%REQ(ufs-user-login)%'
                #   sessionUid: '%REQ(ufs-forward-sid)%'
                #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
                logFormat:
                  textFormatSource:
                    inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"

Можно использовать стандартный формат записи (не закомментирован в примере) или формат json (закомментирован в примере), который подходит для обработки файлов логов компонентом LOGA.

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

Пример лога HTTP-запроса в формате по умолчанию:

[2023-09-22T13:08:27.531Z] "GET /test HTTP/1.1" 200 - 0 22 2 2 "-" "Go-http-client/1.1" "1cf460fb-b3f6-45e1-ad4a-d4ef1f11c7ee" "server-v1.test-http.svc.cluster.local:8080" "XX.XX.XX.XX:9999"

Пример лога HTTP-запроса в формате inlineString, совпадающем с тем, как логи пишутся в stdout контейнера:

[2023-09-22T13:08:32.533Z] "GET /test HTTP/1.1" 200 - via_upstream - "-" 0 22 3 3 "-" "Go-http-client/1.1" "a98c0241-78bc-4b16-85a1-1a7a92e20fa3" "server-v1.test-http.svc.cluster.local:8080" "XX.XX.XX.XX:9999" outbound|9999||egress-gw-svc.test-http.svc.cluster.local XX.XX.XX.XX:33792 XX.XX.XX.XX:8080 XX.XX.XX.XX:60822 - -

Пример лога HTTP-запроса в формате json:

{"timestamp":"2023-09-22T13:09:29.555","sessionLogin":"-","requestDepth":"-","requestUid":"-","sessionUid":"-","clientID":"-","message":"0","businessID":"-"}

Способ 2. IstioOperator и Telemetry#

Для настройки вывода access-логов Envoy в файл в namespace должен быть создан ресурс типа Telemetry, и в настройках контрольной панели в параметре meshConfig IstioOperator создан ресурс extensionProviders со значением пути, равным необходимому пути для записи access-логов Envoy.

Подробнее о настройке meshConfig в IstioOperator указано в документе «Руководство по установке» компонента POLM.

Пример IstioOperator:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-demo
  namespace: istio-system
spec:
  meshConfig:
    extensionProviders:
    - name: envoy_default
      envoyFileAccessLog:
        path: /dev/stdout
    - name: envoy_file
      envoyFileAccessLog:
        path: /etc/istio/proxy/access.log

Пример ресурса Telemetry, применяемого ко всем приложениям namespace:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: default
  namespace: syn-test
spec:
  accessLogging:
  - providers:
    - name: envoy_default
    - name: envoy_file

Пример ресурса Telemetry, применяемого к выбранному приложению namespace:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: default
  namespace: syn-test
spec:
  accessLogging:
  - providers:
    - name: envoy_default
    - name: envoy_file
  selector:
    matchLabels:
      app: pg-client

Настройка deployments#

Для настройки логирования и ротации в каждом контейнере istio-proxy компонента IGEG можно задать следующие переменные в args или env контейнера:

Параметр `env`	Параметр `args`	Описание	Возможные значения
`PILOT_LOG_PATH`	`--log_rotate`	Путь к ротируемому файлу логов pilot-agent	Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy
`PILOT_LOG_LEVEL`	`--log_output_level`	Уровень детализации логов pilot-agent. Строка значений вида `scope:level`, объединенных запятой	Возможные значения `scope`: `default, validation, processing, analysis,installer, translator, adsc, klog, kube` Возможные значения `level`: `debug, info, warn, error, fatal, none`
`PROXY_LOG_PATH`	`--proxyLogPath`	Путь к ротируемому файлу логов Envoy	Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy
`PROXY_LOG_LEVEL`	`--proxyLogLevel`	Уровень детализации логов Envoy	Возможные значения: `trace, debug, info, warning, error, critical, off`
`ACCESS_LOG_PATH`	`--accessLogPath`	Путь к ротируемому файлу access-логов Envoy	Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy
`LOG_ROTATE_MAX_SIZE`	`--log_rotate_max_size`	Раз в минуту pilot-agent проверяет размеры указанных ротируемых файлов и копирует их содержимое в новый файл с именем в формате -., очищая исходный файл	Целое число в МБ, значение по умолчанию - 100
`LOG_ROTATE_MAX_BACKUPS`	`--log_rotate_max_backups`	Число бэкап-файлов, сохраняющихся при ротации. 0 - не удалять файлы	Целое число, значение по умолчанию - 0
`LOG_ROTATE_MAX_AGE`	`--log_rotate_max_age`	Число дней, которое хранятся файлы бэкапов	Целое число, значение по умолчанию - 30

Пример настройки параметров логирования контейнера istio-proxy в deployment с использованием env контейнера:

kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: istio-proxy
        env:
          - name: PILOT_LOG_PATH
            value: '/etc/istio/proxy/pilotagent.log'
          - name: PILOT_LOG_LEVEL
            value: 'default:debug'
          - name: PROXY_LOG_PATH
            value: '/etc/istio/proxy/envoy.log'
          - name: PROXY_LOG_LEVEL
            value: 'trace'
          - name: ACCESS_LOG_PATH
            value: '/etc/istio/proxy/access.log'
          - name: LOG_ROTATE_MAX_SIZE
            value: '1'
          - name: LOG_ROTATE_MAX_BACKUPS
            value: '2'
          - name: LOG_ROTATE_MAX_AGE
            value: '5'

Пример настройки параметров логирования контейнера istio-proxy в deployment с использованием args контейнера:

kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: istio-proxy
        args:
          - proxy
          - '--log_rotate=/etc/istio/proxy/pilotagent.log'
          - '--log_output_level=default:debug'
          - '--proxyLogPath=/etc/istio/proxy/envoy.log'
          - '--proxyLogLevel=trace'
          - '--accessLogPath=/etc/istio/proxy/access.log'
          - '--log_rotate_max_size=1'
          - '--log_rotate_max_backups=2'
          - '--log_rotate_max_age=30'

Пример проекта#

Пример проекта с настроенной ротацией логов на sidecar приложений и в deployment Egress находится здесь

Сценарий 5. Изменение уровня логирования Envoy в составе IGEG в рантайме#

Изменить уровень логирования Envoy в контейнере istio-proxy, не прерывая его работу, можно двумя способами.

Способ 1.#

curl -X POST localhost:15000/logging?level=<level>

Способ 2.#

Если в образе IGEG нет исполняемой оболочки и/или утилиты curl, то можно изменить уровень логирования Envoy с помощью клиентской утилиты istioctl:

istioctl proxy-config log --level <logger1:level,logger2:level...> <IGEG_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name>

Чтобы получить текущие loggers и уровни их логирования, необходимо выполнить следующую команду:

istioctl proxy-config log <IGEG_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name>

Значение параметра level задается как перечисление loggers и их уровней логирования через запятую в формате logger1:level,logger2:level.

В качестве logger можно указывать значения: admin, aws, assert, backtrace, client, config, connection, conn_handler, dubbo, file, filter, forward_proxy, grpc, hc, health_checker, http, http2, hystrix, init, io, jwt, kafka, lua, main, misc, mongo, quic, pool, rbac, redis, router, runtime, stats, secret, tap, testing, thrift, tracing, upstream, udp, wasm.

В качестве значений уровня логирования можно указывать одно из следующих значений: trace, debug, info, warning, error, critical, off

Если не выставить значение для logger, то уровень логирования применится ко всем loggers.

Пример:

istioctl proxy-config log --level http:trace,wasm:debug egress-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test

Чтобы вернуть уровни логирования всех loggers к значениям по умолчанию, необходимо выполнить следующую команду.

istioctl proxy-config log <IGEG_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> -r

Пример:

istioctl proxy-config log egress-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test -r

Сценарий 6. Горизонтальное масштабирование граничных прокси с использованием HorizontalPodAutoscaler#

Для автоматизации изменения числа Pods в зависимости от нагрузки предлагается использовать механизм horizontal pod autoscaler (HPA).

Создание ресурса HorizontalPodAutoscaler позволяет указать минимальное и максимальное количество Pods, параметры загрузки процессора, памяти, значения Logs, метрики Prometheus и другие параметры, по которым происходит масштабирование.

Пример ресурса:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: <имя_HPA>
  namespace: <имя_namespace>
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  minReplicas: <минимальное_количество_Pods>
  maxReplicas: <максимальное_количество_Pods>
  metrics:
    - type: Resource
      resource:
        name: <Имя_ресурса_по_которому_делаем_HPA>
        target:
          type: AverageValue
          averageValue: <среднее_значение_ресурса>
    - type: Resource
      resource:
        name: <Имя_ресурса_по_которому_делаем_HPA>
        target:
          type: AverageValue
          averageValue: <среднее_значение_ресурса>

Диаграмма взаимодействия#

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

В случае скачкообразной нагрузки от Horizontal Pod Autoscaler следует отказаться.

Сценарий 7. Маскирование данных#

Начиная с версии SSM 4.2, в образе proxyv2 (образ контейнеров istio-proxy приложений IGEG и sidecars istio-proxy SVPX) задана переменная окружения:

# Environment variable to mask authorization headers & ott-tokens by default
ENV SYNAPSE_MASKING_CONFIG='{"exact":[{"name":"authorization","pattern":"^.{4}(.+).{4}$"},{"name":"ott-token","pattern":"^.{4}(.+).{4}$"}]}'

Она устанавливает маскирование заголовков authorization и ott-token в логах контейнеров istio-proxy включенным по умолчанию.

Существуют следующие пути переопределения маскирования по умолчанию:

Задание переменной окружения SYNAPSE_MASKING_CONFIG в Deployment IGEG с указанием полного пути до файла конфигурации.
Задание переменной окружения SYNAPSE_MASKING_CONFIG в Deployment IGEG с указанием конфигурации маскирования.
Задание переменной окружения SYNAPSE_MASKING_CONFIG в Deployment IGEG из конфигурации ConfigMap.

Конфигурация переменной окружения SYNAPSE_MASKING_CONFIG имеет следующие параметры:

Параметр	Значение
exact	Поиск точного совпадения в имени заголовка
regex	Поиск совпадения регулярного выражения с именем заголовка
name	Имя заголовка для поиска
pattern	Паттерн регулярного выражения для маскирования значения заголовка

Задание переменной окружения с указанием полного пути до файла конфигурации#

Необходимо выполнить два условия:

Задайте переменную окружения SYNAPSE_MASKING_CONFIG для istio-proxy контейнера, с указанием полного пути до файла с конфигурацией маскирования, и примонтируйте конфигурационный файл. Пример:

kind: Deployment
spec:
  template:
    spec:
      containers:
      	...
        - name: istio-proxy
         env:
            - name: SYNAPSE_MASKING_CONFIG
              value: /etc/app/masking-config.yaml
          ...
          volumeMounts:
            - name: configmap
              readOnly: true
              mountPath: /etc/app/
        ...
        volumes:
          - name: envoy-configmap
            configMap:
              name: envoy-configmap
              defaultMode: 256

Опишите файл конфигурации маскирования. Пример конфигурации:

apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-configmap
data:
  masking-config.yaml: |-
      exact:
        - name: authorization
          pattern: "^.{4}(.+).{4}$"
        - name: path
          pattern: "secret_value"
      regex:
        - name: "x-request.+"
          pattern: "^.{4}(.+).{4}$"

Задание переменной окружения с указанием конфигурации маскирования#

Укажите конфигурацию маскирования, передав значение в переменную окружения:

- name: istio-proxy
  env:
    - name: SYNAPSE_MASKING_CONFIG
      value: '{"exact":{"name":"authorization","pattern":"^.{4}(.+).{4}$"},"regex":{"name":"x-request.+","pattern":"^.{4}(.+).{4}$"}}'

Задание переменной окружения из конфигурации ConfigMap#

Опишите файл конфигурации маскирования:

apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-configmap
data:
  SYNAPSE_MASKING_CONFIG: |-
    exact:
      - name: authorization
        pattern: "^.{4}(.+).{4}$"
      - name: path
        pattern: "secret_value"
    regex:
      - name: "x-request.+"
        pattern: "^.{4}(.+).{4}$"

Укажите описанный ConfigMap как параметр для чтения переменных:

spec:
  ...
  spec:
      ....
      containers:
          ...
      - name: istio-proxy
          envFrom:
          - configMapRef:
              name: envoy-configmap

Приоритет поиска/применения конфига маскирования#

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

Например:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache

В заголовке данного вида первым обработается имя заголовка «GET» — оно сравнивается с первым параметром конфигурации маскирования «authorization». Далее проверяется равенство «GET» и «path». Следующая проверка сравнивает регулярное выражение «x-request.+» с «GET». И так далее, ниже по списку конфигурации.

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

Специфичные параметры для access-логов, где явно указан вывод параметров чувствительно важной информации.
Уровень логирования ниже чем warning. В этом случае есть вероятность, что чувствительно важная информация может попасть, например, из query запроса.

Внимание! В качестве параметров для маскирования не должны быть указаны чувствительно важные данные.

Как составить регулярное выражение#

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

При наличии групп — маскируется только первая группа.
При отсутствии групп и наличия совпадения — маскируется только первое совпадение.

Выражение типа: «^.{4}(.+).{4}$», из примера, маскирует середину, оставляя первые и последние 4 символа без изменений. Такие приемы не всегда очевидны, поэтому для удобства можно воспользоваться информацией с сайта regex101.com.

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

Таким образом, найдено одно совпадение и три группы. По условиям маскирования только первая группа будет заменена, что соответствует цифре 8. Самое простое решение — обернуть выражение в круглые скобки, для выделения основной группы. Сложнее составить регулярное выражение, в котором только Match или одна группа.

Сценарий 8. Указание необходимости распределения экземпляров исполняемого компонента по разным узлам среды исполнения#

В зависимости от функционала сервиса экземпляры исполняемого компонента (Pods) необходимо распределять по разным узлам кластера (Nodes) или переносить на один узел.

Наиболее подходящим инструментом, позволяющим управлять расположением pods, является affinity и anti-affinity.

Пример конфигурации deployment граничного прокси:

spec:
  template:
      metadata:
        affinity:
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 100
                podAffinityTerm:
                  labelSelector:
                      matchExpressions:
                      - key: app
                        operator: In
                        values:
                        - inressgateway
                  topologyKey: topology.kubernetes.io/hostname

При этом в уникальных labels deployment необходимо добавить:

spec:
  template:
    metadata:
      labels:
        app: ingressgateway

До применения конфигурации список из десяти Pods приложения Ingress выглядел следующим образом:

$ kubectl get pod -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName -n syn-test
NAME                             STATUS    NODE
ingress-75d9cb6cf4-5qsch   Running   worker-03.**.solution
ingress-75d9cb6cf4-8p8fg   Running   worker-03.**.solution
ingress-75d9cb6cf4-jf989   Running   worker-03.**.solution
ingress-75d9cb6cf4-kr8c7   Running   worker-03.**.solution
ingress-75d9cb6cf4-lgp4r   Running   worker-03.**.solution
ingress-75d9cb6cf4-m7xml   Running   worker-03.**.solution
ingress-75d9cb6cf4-pjgtp   Running   worker-03.**.solution
ingress-75d9cb6cf4-wmx95   Running   worker-03.**.solution
ingress-75d9cb6cf4-wx5dq   Running   worker-03.**.solution
ingress-75d9cb6cf4-z6qr4   Running   worker-03.**.solution

Можно заметить, что Pods расположились на одном узле.

После применения конфигурации видно равномерное распределение Pods по узлам:

$ kubectl get pod -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName -n syn-test
NAME                             STATUS    NODE
ingress-84f847c7b8-2ddc6   Running   worker-02.**.solution
ingress-84f847c7b8-595sw   Running   worker-02.**.solution
ingress-84f847c7b8-l949m   Running   worker-05.**.solution
ingress-84f847c7b8-nlxcz   Running   worker-04.**.solution
ingress-84f847c7b8-qvtpm   Running   worker-05.**.solution
ingress-84f847c7b8-qzgsw   Running   worker-01.**.solution
ingress-84f847c7b8-tv6wj   Running   worker-06.**.solution
ingress-84f847c7b8-wf2dq   Running   worker-04.**.solution
ingress-84f847c7b8-z8b47   Running   worker-01.**.solution
ingress-84f847c7b8-zpxhk   Running   worker-03.**.solution

Сценарий 9. Недоступность прокси после применения некорректной конфигурации#

Пререквизиты

Используется rbac для валидации по CN сертификата. Если не удовлетворяет условию, то запрос отбивается. В данном случае пропускаются только те взаимодействия, где при установке handshake от клиента пришел заголовок x-forwarded-client-cert, удовлетворяющий регулярному выражению — .*MySystem1.*. Также ограничивается параметр max_program_size.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: authz-cert-filter
spec:
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
          portNumber: 8444
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.rbac
          typed_config:
            '@type': type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
            rules:
              action: ALLOW
              policies:
                client-cert-policy:
                  permissions:
                    - or_rules:
                        rules:
                          - header:
                              name: ':path'
                              prefix_match: /health_check
                  principals:
                    - or_ids:
                        ids:
                          - header:
                              name: x-forwarded-client-cert
                              safe_regex_match:
                                google_re2:
                                  max_program_size: 100
                                regex: >-
                                  .*MySystem1.*
  workloadSelector:
    labels:
      app: my-ingress

Приложение настроено и работает. Трафик идет через Ingress успешно. Пример лога с успешным http запросом: [2024-07-25T11:12:22.167Z] "GET /health_check HTTP/2" 200 - via_upstream - "-" 0 788 8 8 "11.11.11.11" "Mozilla/5.0 " "90e8a876-4815-4595-b555-c1cafd450dc5" "test.my" "2.2.2.2:9081" outbound|8888||myService.myNamespace.svc.cluster.local 3.3.3.3:3333

Как воспроизвести

Загрузите обновленный EnvoyFilter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: authz-cert-filter
spec:
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
          portNumber: 8444
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.rbac
          typed_config:
            '@type': type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
            rules:
              action: ALLOW
              policies:
                client-cert-policy:
                  permissions:
                    - or_rules:
                        rules:
                          - header:
                              name: ':path'
                              prefix_match: /health_check
                  principals:
                    - or_ids:
                        ids:
                          - header:
                              name: x-forwarded-client-cert
                              safe_regex_match:
                                google_re2:
                                  max_program_size: 100
                                regex: >-
                                  .*MySystem1.*
  workloadSelector:
    labels:
      app: my-ingress

В логе прокси будет ошибка, т.к. Program size регулярного выражения вышел за лимит в 100. Пример ошибки в логе прокси: [2024-07-25 11:21:18.318][23][warning][config] gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8444: regex '.*MySystem1.*|.*MySystem2.*|.*MySystem3.*|.*MySystem4.*|.*MySystem5.*|.*MySystem6.*|.*MySystem7.*|.*MySystem8.*|.*MySystem9.*' RE2 program size of 125 > max program size of 100. Increase configured max program size if necessary.

Пример ошибки в логе istiod на control-plane:

Проверьте работу приложения. Убедитесь, что все работает. Трафик успешно проходит.

[2024-07-25T11:12:22.167Z] "GET /health_check HTTP/2" 200 - via_upstream - "-" 0 788 8 8 "11.11.11.11" "Mozilla/5.0 " "90e8a876-4815-4595-b555-c1cafd450dc5" "test.my" "2.2.2.2:9081" 4.4.4.4:221322 outbound|8888||myService.myNamespace.svc.cluster.local 3.3.3.3:3333 -

Внимание! Несмотря на конфликтную конфигурацию прокси работает, т.к. он не применил новую и работает со старой, которая была до загрузки обновленного envoyFilter.

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

[2024-07-25T11:34:35.004Z] "GET /health_check HTTP/2" 403 SLR rbac_access_denied_matched_policy[none] - "-" 0 19 0 - "1.1.11.1" "Mozilla/5.0" "90e8a876-4815-4595-b555-c1cafd450fc5" "test.my" "2.2.2.2:9081" 4.4.4.4:221322

Перезагрузка Ingress-Gateway. При поднятии новой реплики Ingress-Gateway теперь совсем не стартует, т.к. старую рабочую конфигурацию получить от Control Plane уже нельзя:

[2024-07-24 12:18:53.131][23][warning][config] gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8444: regex '.*MySystem1.*|.*MySystem2.*|.*MySystem3.*|.*MySystem4.*|.*MySystem5.*|.*MySystem6.*|.*MySystem7.*|.*MySystem8.*|.*MySystem9.*' RE2 program size of 125 > max program size of 100. Increase configured max program size if necessary.

2024-07-24T12:18:54.729691Z    warn    Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected

Рекомендации

Чтобы не допустить подобных проблем, рекомендуется:

Использовать стратегию обновления rollingUpdate.
Использовать replicas > 1 в deployment.
Не перезагружать рабочие pods, если в их системном журнале есть ошибки (error) или предупреждения (warning) с тегом [config].
Настроить мониторинг метрик, связанный с отклоненными конфигурациями. Если после обновления манифестов istio значения этих метрик растут, то есть проблема с конфигурацией. Список метрик Prometheus:

envoy_listener_manager_lds_update_rejected - количество отклоненных listeners
envoy_cluster_manager_cds_update_rejected - количество отклоненных clusters
envoy_listener_manager_lds_update_failure - количество ошибочных listeners
envoy_cluster_manager_cds_update_failure - количество ошибочных clusters

Сценарий 10. Проверка клиентов и серверов по списку отозванных сертификатов.#

В релизе Synapse Service Mesh 4.10 и выше реализована функция проверки входящих и исходящих подключений IGEG по списку отозванных сертификатов, CRL.

В релизе Synapse Service Mesh 4.11 и выше реализована автоматическая загрузка и обновление CRL для tls-соединений, работающих в режиме MUTUAL. Соответственно, ниже приведенные примеры могут использоваться без явного указания CRL. Источником загрузки CRL является список точек распространения CRL Distribution Points, задаваемый в расширениях каждого корневого сертификата из бандла caCertificates, прописанных в Gateway и DestinationRule. В случае явного указания CRL загружаемые из caCertificates.CRL Distribution Points и описанные вручную в Gateway и DestinationRule списки отозванных сертификатов накладываются друг на друга.

Настройка проверки выполняется в ресурсах Gateway и DestinationRule конфигурации прикладного проекта.

В CustomResourceDefinitions ресурсов Gateway и DestinationRule было добавлено поле tls.caCrl, в котором можно прописать список отозванных сертификатов в формате .pem, подмонтированный как файл в приложения Ingress или Egress.

Пример настройки Gateway, выполняющего проверку входящих соединений по списку отозванных сертификатов:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gw
spec:
  selector:
    app: egress
  servers:
  - hosts:
    - egress-gw-svc.test-https.svc.cluster.local
    port:
      name: https-9999
      number: 9999
      protocol: HTTPS
    tls:
      mode: MUTUAL
      serverCertificate: /var/certs/egress-svr/tls.crt
      privateKey: /var/certs/egress-svr/tls.key
      caCertificates: /var/certs/egress-svr/ca.crt
      caCrl: /var/certs/egress-svr/ca.crl

Пример настройки DestinationRule, выполняющего проверку исходящих соединений по списку отозванных сертификатов:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: server1-dr
spec:
  exportTo:
  - .
  host: server1.test-https.svc.cluster.local
  workloadSelector:
    matchLabels:
      app: egress
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 8080
      tls:
        mode: MUTUAL
        sni: server1.test-https.svc.cluster.local
        clientCertificate: /var/certs/egress-clnt/tls.crt
        privateKey: /var/certs/egress-clnt/tls.key
        caCertificates: /var/certs/egress-clnt/ca.crt
        caCrl: /var/certs/clnt/egress-ca.crl

Если в Gateway или DestinationRule поле tls.caCrl не было задано, проверка соединения по этому списку отозванных сертификатов выполняться не будет.

Также можно создать ресурс Secret Kubernetes и указать в нем сертификаты и список отозванных сертификатов.

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

Пример Secret типа kubernetes.io/tls:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
  name: egress-svr
data:
  tls.crt: ==base64-tls-crt==
  tls.key: ==base64-tls-key==
  ca.crt: ==base64-ca-crt==
  ca.crl: ==base64-ca-crl==

Пример Secret типа Opaque:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: egress-clnt
data:
  cert: ==base64-cert==
  key: ==base64-key==
  cacert: ==base64-cacert==
  crl: ==base64-crl==

Если в Secret поле ca.crl или crl не было задано, проверка соединения по этому списку отозванных сертификатов выполняться не будет.

Пример настройки Gateway, выполняющего проверку входящих соединений по списку отозванных сертификатов из Secret:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gw
spec:
  selector:
    app: egress
  servers:
  - hosts:
    - egress-gw-svc.test-https.svc.cluster.local
    port:
      name: https-9999
      number: 9999
      protocol: HTTPS
    tls:
      mode: MUTUAL
      credentialName: egress-svr

Пример настройки DestinationRule, выполняющего проверку исходящих соединений по списку отозванных сертификатов из Secret:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: server1-dr
spec:
  exportTo:
  - .
  host: server1.test-https.svc.cluster.local
  workloadSelector:
    matchLabels:
      app: egress
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 8080
      tls:
        mode: MUTUAL
        sni: server1.test-https.svc.cluster.local
        credentialName: egress-clnt

События системного журнала#

По умолчанию граничный прокси сохраняет свои логи в стандартный вывод linux (stdout).

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

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

Включение уровней логирования trace и debug не рекомендуется в промышленных инсталляциях.

В контейнере istio-proxy компонента IGEG в стандартный вывод (/dev/stdout) пишутся 3 вида логов:

1. Логи pilot-agent

При старте контейнера запускается исполняемый файл /usr/local/bin/pilot-agent, который анализирует конфигурацию текущего deployment, создает соединение с deployment istiod в namespace с контрольной панелью, получает и обновляет конфигурацию Envoy, а также запускает его.

Логи pilot-agent содержат информацию о параметрах и переменных окружения, настроенных в deployment, о взаимодействии с XDS-сервером контрольной панели, о запуске Envoy.

Пример логов pilot-agent

2023-09-14T11:34:05.617888Z     info    FLAG: --concurrency="2"
2023-09-14T11:34:05.618002Z     info    FLAG: --domain="test-pg-multi.svc.cluster.local"
2023-09-14T11:34:05.618013Z     info    FLAG: --help="false"
2023-09-14T11:34:05.618016Z     info    FLAG: --log_as_json="false"
2023-09-14T11:34:05.618020Z     info    FLAG: --log_caller=""
2023-09-14T11:34:05.618023Z     info    FLAG: --log_output_level="default:info"
2023-09-14T11:34:05.618035Z     info    FLAG: --log_rotate="/etc/istio/proxy/pilotagent.log"
2023-09-14T11:34:05.618038Z     info    FLAG: --log_rotate_max_age="5"
2023-09-14T11:34:05.618041Z     info    FLAG: --log_rotate_max_backups="2"
2023-09-14T11:34:05.618044Z     info    FLAG: --log_rotate_max_size="1"
2023-09-14T11:34:05.618046Z     info    FLAG: --log_stacktrace_level="default:none"
2023-09-14T11:34:05.618054Z     info    FLAG: --log_target="[stdout]"
2023-09-14T11:34:05.618058Z     info    FLAG: --meshConfig="./etc/istio/config/mesh"
2023-09-14T11:34:05.618061Z     info    FLAG: --outlierLogPath=""
2023-09-14T11:34:05.618064Z     info    FLAG: --proxyComponentLogLevel="misc:error"
2023-09-14T11:34:05.618066Z     info    FLAG: --proxyLogFormat=""
2023-09-14T11:34:05.618069Z     info    FLAG: --proxyLogLevel="warning"
2023-09-14T11:34:05.618072Z     info    FLAG: --proxyLogPath=""
2023-09-14T11:34:05.618075Z     info    FLAG: --serviceCluster="istio-proxy"
2023-09-14T11:34:05.618078Z     info    FLAG: --stsPort="0"
2023-09-14T11:34:05.618080Z     info    FLAG: --templateFile=""
2023-09-14T11:34:05.618084Z     info    FLAG: --tokenManagerPlugin="GoogleTokenExchange"
2023-09-14T11:34:05.618088Z     info    FLAG: --vklog="0"
2023-09-14T11:34:05.618092Z     info    Version 1.17-dev-24c9c092f1dbe2b0184f1127e11bc894b9b5e8ee-dirty-Clean
2023-09-14T11:34:05.671933Z     info    Maximum file descriptors (ulimit -n): 1048576
2023-09-14T11:34:05.672149Z     info    Proxy role      ips=[XX.XXX.X.XXX] type=sidecar id=pg-client-postgres-5b497bd5f7-s7785.test-pg-multi domain=test-pg-multi.svc.cluster.local
2023-09-14T11:34:05.672295Z     info    Apply proxy config from env {"proxyMetadata":{"ACCESS_LOG_PATH":"/etc/istio/proxy/access.log","LOG_ROTATE_MAX_AGE":"5","LOG_ROTATE_MAX_BACKUPS":"2","LOG_ROTATE_MAX_SIZE":"1","PILOT_LOG_LEVEL":"default:debug","PILOT_LOG_PATH":"/etc/istio/proxy/pilotagent.log","PROXY_LOG_LEVEL":"trace","PROXY_LOG_PATH":"/etc/istio/proxy/envoy.log"}}

2023-09-14T11:34:05.677951Z     info    Apply proxy config from annotation proxyMetadata:
  PILOT_LOG_LEVEL: 'default:debug'
  PILOT_LOG_PATH: '/etc/istio/proxy/pilotagent.log'
  PROXY_LOG_LEVEL: 'trace'
  PROXY_LOG_PATH: '/etc/istio/proxy/envoy.log'
  ACCESS_LOG_PATH: '/etc/istio/proxy/access.log'
  LOG_ROTATE_MAX_SIZE: '1'
  LOG_ROTATE_MAX_BACKUPS: '2'
  LOG_ROTATE_MAX_AGE: '5'

2023-09-14T11:34:05.678720Z     info    Effective config: binaryPath: /usr/local/bin/envoy
concurrency: 2
configPath: ./etc/istio/proxy
controlPlaneAuthPolicy: MUTUAL_TLS
discoveryAddress: istiod.istio-system.svc:15012
drainDuration: 45s
proxyAdminPort: 15000
proxyMetadata:
  ACCESS_LOG_PATH: /etc/istio/proxy/access.log
  LOG_ROTATE_MAX_AGE: "5"
  LOG_ROTATE_MAX_BACKUPS: "2"
  LOG_ROTATE_MAX_SIZE: "1"
  PILOT_LOG_LEVEL: default:debug
  PILOT_LOG_PATH: /etc/istio/proxy/pilotagent.log
  PROXY_LOG_LEVEL: trace
  PROXY_LOG_PATH: /etc/istio/proxy/envoy.log
serviceCluster: istio-proxy
statNameLength: 189
statusPort: 15020
terminationDrainDuration: 5s
tracing:
  zipkin:
    address: zipkin.istio-system:9411

2023-09-14T11:34:05.678839Z     info    JWT policy is third-party-jwt
2023-09-14T11:34:05.678912Z     info    using credential fetcher of JWT type in cluster.local trust domain
2023-09-14T11:34:05.690371Z     info    Workload SDS socket not found. Starting Istio SDS Server
2023-09-14T11:34:05.690469Z     info    CA Endpoint istiod.istio-system.svc:15012, provider Citadel
2023-09-14T11:34:05.690503Z     info    Using CA istiod.istio-system.svc:15012 cert with certs: var/run/secrets/istio/root-cert.pem
2023-09-14T11:34:05.691761Z     info    Opening status port 15020
2023-09-14T11:34:05.716896Z     info    ads     All caches have been synced up in 110.036131ms, marking server ready
2023-09-14T11:34:05.717274Z     info    xdsproxy        Initializing with upstream address "istiod.istio-system.svc:15012" and cluster "Kubernetes"
2023-09-14T11:34:05.717619Z     info    sds     Starting SDS grpc server
2023-09-14T11:34:05.717886Z     info    starting Http service at 127.0.0.1:15004
2023-09-14T11:34:05.719222Z     info    Pilot SAN: [istiod.istio-system.svc]
2023-09-14T11:34:05.721175Z     info    Starting proxy agent
2023-09-14T11:34:05.770190Z     info    starting
2023-09-14T11:34:05.770401Z     info    Envoy command: [-c etc/istio/proxy/envoy-rev.json --drain-time-s 45 --drain-strategy immediate --local-address-ip-version v4 --file-flush-interval-msec 1000 --disable-hot-restart --allow-unknown-static-fields --log-path /etc/istio/proxy/envoy.log --log-format [%Y-%m-%d %T.%e][%t][%l][%n] %v -l trace --component-log-level misc:error --concurrency 2]
2023-09-14T11:34:06.071682Z     info    cache   generated new workload certificate      latency=354.43117ms ttl=23h59m59.92833167s
2023-09-14T11:34:06.071767Z     info    cache   Root cert has changed, start rotating root cert
2023-09-14T11:34:06.071785Z     info    ads     XDS: Incremental Pushing:0 ConnectedEndpoints:0 Version:
2023-09-14T11:34:06.072291Z     info    cache   returned workload trust anchor from cache       ttl=23h59m59.927713303s
2023-09-14T11:34:06.174117Z     info    xdsproxy        connected to upstream XDS server: istiod.istio-system.svc:15012
2023-09-14T11:34:06.208038Z     info    ads     ADS: new connection for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi-1
2023-09-14T11:34:06.208127Z     info    cache   returned workload certificate from cache        ttl=23h59m59.791877412s
2023-09-14T11:34:06.208367Z     info    ads     SDS: PUSH request for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi resources:1 size:4.0kB resource:default
2023-09-14T11:34:06.208065Z     info    ads     ADS: new connection for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi-2
2023-09-14T11:34:06.208529Z     info    cache   returned workload trust anchor from cache       ttl=23h59m59.79147353s
2023-09-14T11:34:06.208601Z     info    ads     SDS: PUSH request for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi resources:1 size:1.1kB resource:ROOTCA
2023-09-14T11:34:06.579568Z     info    Readiness succeeded in 983.077533ms
2023-09-14T11:34:06.579912Z     info    Envoy proxy is ready

2. Логи Envoy

Содержат информацию о работе Envoy в составе istio-proxy, например, логи уровня trace.

Пример логов Envoy

[2023-09-15 10:04:10.968][27][trace][connection] [C229760] socket event: 3
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] write ready
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] read ready. dispatch_buffered_data=0
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl read returns: 0
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl error occurred while read: ZERO_RETURN
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl read 0 bytes
[2023-09-15 10:04:10.968][27][trace][filter] [C229759] upstream connection received 0 bytes, end_stream=true
[2023-09-15 10:04:10.968][27][trace][connection] [C229759] writing 0 bytes, end_stream true
[2023-09-15 10:04:10.968][27][debug][connection] [C229760] remote close
[2023-09-15 10:04:10.968][27][debug][connection] [C229760] closing socket: 0

3. Access-логи Envoy

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

время начала запроса,
метод запроса,
URI path, если применимо,
протокол запроса,
HTTP-код ответа, если применимо,
флаги ответа,
число байт запроса,
число байт ответа,
длительность транзакции в миллисекундах,
некоторые заголовки запроса и ответа,
ip-адрес и порт вызова,
кластер Envoy, соответствующий вызванному адресу.

Пример access-логов Envoy

[2023-09-15T09:46:11.053Z] "POST /receive HTTP/1.1" 200 - via_upstream - "-" 235 0 0 0 "-" "vmagent" "6b0ed2e5-87ae-43e1-bb51-a2dce59408a0" "synapse-metrics-adapter:8080" "XX.XXX.X.XXX:8080" inbound|8080|| 127.0.0.6:43916 XX.XXX.X.XXX:8080 XX.XXX.X.XXX:46814 outbound_.8080_._.synapse-metrics-adapter.ntpub-tribe-sy-polm-lt-dp.svc.cluster.local default
[2023-09-15T10:07:56.052Z] "POST /receive HTTP/1.1" 200 - via_upstream - "-" 987 0 1 0 "-" "vmagent" "afaecef0-666d-4701-98c7-87429aa6805c" "synapse-metrics-adapter:8080" "XX.XXX.X.XXX:8080" inbound|8080|| 127.0.0.6:40234 XX.XXX.X.XXX:8080 XX.XXX.X.XXX:46814 outbound_.8080_._.synapse-metrics-adapter.ntpub-tribe-sy-polm-lt-dp.svc.cluster.local default

[2023-09-14T07:53:40.169Z] "- - -" 0 UF,URX - - "delayed_connect_error:_111" 0 0 1 - "-" "-" "-" "-" "XX.XXX.X.XXX:5432" outbound|5432||ignite.test.com - XX.XXX.X.XXX:54320 XX.XXX.X.XXX:53420 - -
[2023-09-14T08:14:45.382Z] "- - -" 0 UF,URX - - "delayed_connect_error:_111" 0 0 1 - "-" "-" "-" "-" "XX.XXX.X.XXX:5432" outbound|5432||ignite.test.com - XX.XXX.X.XXX:54320 XX.XXX.X.XXX:37144 - -

[2023-07-24T06:35:35.427Z] "POST /one-window/start-payment-search/pay-doc-info HTTP/1.1" 503 UF,URX,SLR "-" "TLS error: peer ip XX.XXX.X.XXX:443 : session_id  : SSL routines : OPENSSL_internal : TLSV1_ALERT_UNKNOWN_CA : certificate unknown : internal error code 46 : hostname ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru: Peer CA info - issuer info CN=SberCA Test Int,O=Bank,C=RU : subject info CN=mtls.rec-cloud.apps.psi-terra000030-ips.ХХХ.ХХХ.ХХХ.ru,OU=00CA,O=Bank,C=RU : serial number 51795be915de0f140ab112a15f421b18109a4aa7 : expiration 2026-02-19" 39 91 102 - "XX.XXX.X.XXX" "Apache-HttpAsyncClient/4.1.5 (Java/11.0.12)" "8d47fffc-a0df-9cf2-8077-1710eaa3e116" "ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru - XX.XXX.X.XXX:21139 XX.XXX.X.XXX:45096 outbound_.21139_._.schd-svc-egress-tenant-rec-cloud-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T01:50:00.343Z] "GET /scheduled/retry HTTP/1.1" 503 UF,URX,SLR "-" "TLS error: peer ip XX.XXX.X.XXX:443 : session_id  : SSL routines : OPENSSL_internal : CERTIFICATE_VERIFY_FAILED : unsupported certificate : internal error code 43 : hostname notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru: Peer CA info - issuer info CN=CA Test Int,O=Bank,C=RU : subject info CN=00CA0001PPRBNotifyNOTIFICATION,OU=00CA,O=Bank,C=RU : serial number 66bb6c35dcb4210ca2c1e63e9637f6806b58bc29 : expiration 2025-05-29" 0 91 314 - "XX.XXX.X.XXX" "Apache-HttpAsyncClient/4.1.5 (Java/11.0.12)" "fa74fb56-b798-9624-8b65-02289408d21b" "notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru - XX.XXX.X.XXX:21106 XX.XXX.X.XXX:33182 outbound_.21106_._.schd-svc-egress-tenant-pprb4-digital-notify-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T00:35:16.670Z] "POST /v1/events HTTP/1.1" 200 - "-" "-" 3226 21 14 12 "XX.XXX.X.XXX" "Fluent-Bit" "c536b004-0b09-93f8-a626-14d1bea7fbc1" "logger-psi-ott.geo.igw.psi-18-19-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||logger-psi-ott.geo.igw.psi-18-19-apps.ХХХ.ХХХ.ХХХ.ru XX.XXX.X.XXX:44946 XX.XXX.X.XXX:8888 XX.XXX.X.XXX:49848 outbound_.8888_._.schd-svc-egress-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T00:35:17.118Z] "GET /v1/CI02710143_CI03976456/A/CI03132776/P/PPRB_BATCH_PSI/KV/SCHD/journal-certs HTTP/1.1" 200 - "-" "-" 0 9378 153 151 "XX.XXX.X.XXX" "Apache-HttpClient/4.5.14 (Java/11.0.12)" "969cf77a-a5cc-9df2-aefa-7bf4b371a54b" "ift.secrets.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||ift.secrets.ХХХ.ХХХ.ru XX.XXX.X.XXX:54268 XX.XXX.X.XXX:8888 XX.XXX.X.XXX:55624 outbound_.8888_._.schd-svc-egress-4.ci03132776-batch-scheduler.svc.cluster.local -

Примеры других сообщений и ошибок обработки трафика приведены в разделе «Часто встречающиеся проблемы и пути их устранения»

Проверка системного журнала#

Общий журнал событий граничного прокси доступен в интерфейсе Pod Kubernetes на вкладке «Logs». Можно скачать его, нажав на соответствующую кнопку.

Авторизуйтесь в веб-консоли платформы, пользователь должен иметь полномочия не ниже view на ресурсы pods/logs.
Выберите прикладной namespace, подключенный к контрольной панели.
Слева в меню Workloads выберите раздел Deployments.
В списке выберите нужный deployment приложения граничного прокси.
Перейдите на вкладку Pods.
Перейдите на вкладку Logs.

События мониторинга#

Сбор статистики осуществляется при обращении к порту 15020 IGEG по пути /stats/prometheus.

Данный endpoint отдает статистику в формате prometheus, система мониторинга (например, компоненты продукта Platform V Monitor) может использовать данные события для построения графиков использования граничного прокси.

Примеры метрик#

envoy_cluster_upstream_rq_200 - число успешных HTTP-запросов, прошедших через прокси;
envoy_cluster_upstream_rq_400 - число неуспешных HTTP-запросов, прошедших через прокси;
envoy_cluster_upstream_rq_500 - число ошибочных запросов.

Часто встречающиеся проблемы и пути их устранения#

Проблема	Пути решения
Граничный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready	Проверьте корректность подключения к контрольной панели. Проверьте значения переменных окружения `PROXY_CONFIG` и `CA_ADDR` - в них должен быть указан корректный адрес сервиса istiod (из состава POLM). Обратитесь к системным администраторам контрольной панели
До прикладного приложения не доходят запросы	Проверьте access-логи граничного прокси. Возможные варианты сообщений описаны ниже.
В access-логе граничного прокси видно сообщение: `NR (No route configured)`: В конфигурации граничного прокси отсутствует требуемый маршрут	Авторизуйтесь в прикладном namespace. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров host/порт в конфигурационных файлах прикладного namespace — Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний host, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания host/порт
В access-логе граничного прокси видно сообщение: `UO (Upstream overflow with circuit breaking)`: Поставщик перегружен запросами	Авторизуйтесь в прикладном namespace. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule
В access-логе граничного прокси видно сообщение: `UF (Failed to connect to upstream):` Поставщик сбросил соединение	Авторизуйтесь в прикладном namespace. Если используется автоматическая аутентификация `ISTIO_MUTUAL` — проверьте наличие конфликта в разделе `trafficPolicy` конфигурационного файла DestinationRule, относящегося к проблемному сервису, и разделе `Spec/mTLS` конфигурационного файла peerAuthentication. В случае указания разных режимов работы в поле `tls` — возможны указанные ошибки
В access-логе граничного прокси видно сообщение: `UH (No healthy upstream):` Поставщик неработоспособен	Авторизуйтесь в прикладном namespace. Проверьте наличие вызываемого сервиса — в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис — в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение `running`
В access-логе граничного прокси видны сообщения: `gRPC config for Cluster rejected: Error adding/updating cluster(s): Proto constraint validation failed:` Ошибка валидации конфигурации	Проверьте имена портов в объектах Service: они должны иметь формат <протокол>-<номер_порта>. Если имя порта начинается с `kafka`, `postgres`, `mongo` или других слов, обозначающих дополнительные протоколы, istiod попытается создать кластеры с указанными протоколами, что вызовет ошибку

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

Мониторинг ошибок соединения#

Следующие статистики расположены по адрессу listener.<address>.ssl.:

ocsp_staple_failed - total TLS connections that failed compliance with the OCSP policy;
fail_verify_san - total TLS connections that failed SAN verification;
fail_verify_no_cert - total TLS connections that failed because of missing client certificate;
fail_verify_error - total TLS connections that failed CA verification;
fail_verify_cert_hash - total TLS connections that failed certificate pinning verification;
connection_error - total TLS connection errors not including failed certificate verifications;

sh-4.4$ curl localhost:15000/stats | grep ssl 
listener.0.0.0.0_12443.ssl.connection_error: 0
listener.0.0.0.0_12443.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_12443.ssl.fail_verify_error: 0
listener.0.0.0.0_12443.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_12443.ssl.fail_verify_san: 0
listener.0.0.0.0_12443.ssl.handshake: 0
listener.0.0.0.0_12443.ssl.no_certificate: 0
listener.0.0.0.0_12443.ssl.ocsp_staple_failed: 0
listener.0.0.0.0_12443.ssl.ocsp_staple_omitted: 0
listener.0.0.0.0_12443.ssl.ocsp_staple_requests: 0
listener.0.0.0.0_12443.ssl.ocsp_staple_responses: 0
listener.0.0.0.0_12443.ssl.session_reused: 0
listener.0.0.0.0_12443.ssl.was_key_usage_invalid: 0

sh-4.4$ curl localhost:15000/stats/prometheus | grep ssl 
4# TYPE envoy_listener_ssl_connection_error counter
2envoy_listener_ssl_connection_error{listener_address="0.0.0.0_12443"} 0
4# TYPE envoy_listener_ssl_fail_verify_cert_hash counter
8envoy_listener_ssl_fail_verify_cert_hash{listener_address="0.0.0.0_12443"} 0
 # TYPE envoy_listener_ssl_fail_verify_error counter
 envoy_listener_ssl_fail_verify_error{listener_address="0.0.0.0_12443"} 0
 # TYPE envoy_listener_ssl_fail_verify_no_cert counter
 envoy_listener_ssl_fail_verify_no_cert{listener_address="0.0.0.0_12443"} 0
 ...

Отображение метрик:#

Для отображения необходимо добавить в деплоймент:

Способ 1.

- name: PROXY_CONFIG
  value: >
    ...
    "proxyStatsMatcher":{"inclusionRegexps":[".*outlier_detection.*",".*upstream_rq_retry.*",".*upstream_cx_.*",
    ".*ssl.*"],"inclusionSuffixes":["upstream_rq_time","downstream_rq_time"]}}}

Способ 2.

spec:
  template:
    metadata:
      annonations:
        sidecar.istio.io/statsInclusionRegexps: .*ssl.*

Способ 3.

spec:
  template:
    metadata:
      annonations:
        sidecar.istio.io/statsInclusionPrefixes: listener

Способ 4: Добавить название метрики в суффикс

spec:
  template:
    metadata:
      annonations:
        sidecar.istio.io/statsInclusionSuffixes: connection_error

Метрики Postgres-proxy фильтра#

На данный момент прокси генерирует следующие метрики при интеграции с Postgres:

Name	Type	Описание
errors	Counter	Количество раз, когда сервер ответил сообщением ERROR
errors_error	Counter	Количество раз, когда сервер ответил сообщением ERROR с уровнем серьезности ERROR
errors_fatal	Counter	Количество раз, когда сервер ответил сообщением ERROR с уровнем серьезности FATAL
errors_panic	Counter	Количество раз, когда сервер ответил сообщением ERROR с уровнем серьезности PANIC
errors_unknown	Counter	Количество раз, когда сервер ответил сообщением ERROR, но декодер не смог его распознать
messages	Counter	Общее количество сообщений, обработанных фильтром
messages_backend	Counter	Общее количество сообщений от серверной части, обнаруженных фильтром
messages_frontend	Counter	Количество сообщений от клиентской части, обнаруженных фильтром
messages_unknown	Counter	Количество раз, когда фильтр успешно декодировал сообщение, но не знал, как его обработать
sessions	Counter	Общее количество успешных входов в систему
sessions_encrypted	Counter	Количество раз, когда фильтр обнаружил и передал зашифрованные сессии на сервер
sessions_terminated_ssl	Counter	Количество раз, когда фильтр завершил SSL-сессии
sessions_unencrypted	Counter	Количество сообщений, указывающих на успешный вход в систему без шифрования
sessions_upstream_ssl_success	Counter	Количество раз, когда фильтр установил SSL-соединение с сервером
sessions_upstream_ssl_failed	Counter	Количество раз, когда фильтр не смог установить SSL-соединение с сервером
statements	Counter	Общее количество SQL-запросов
statements_delete	Counter	Количество запросов DELETE
statements_insert	Counter	Количество запросов INSERT
statements_select	Counter	Количество запросов SELECT
statements_update	Counter	Количество запросов UPDATE
statements_other	Counter	Количество запросов, отличных от DELETE, INSERT, SELECT или UPDATE
statements_parsed	Counter	Количество успешно распарсенных SQL-запросов
statements_parse_error	Counter	Количество SQL-запросов, которые не удалось распарсить
transactions	Counter	Общее количество SQL-транзакций
transactions_commit	Counter	Количество транзакций COMMIT
transactions_rollback	Counter	Количество транзакций ROLLBACK
notices	Counter	Общее количество сообщений NOTICE
notices_notice	Counter	Количество сообщений NOTICE с подтипом NOTICE
notices_log	Counter	Количество сообщений NOTICE с подтипом LOG
notices_warning	Counter	Количество сообщений NOTICE с уровнем серьезности WARNING
notices_debug	Counter	Количество сообщений NOTICE с уровнем серьезности DEBUG
notices_info	Counter	Количество сообщений NOTICE с уровнем серьезности INFO
notices_unknown	Counter	Количество сообщений NOTICE, которые не удалось распознать

Пример:

postgres.<hostname/stat_prefix>.statements: 7
postgres.<hostname/stat_prefix>.statements_delete: 1
postgres.<hostname/stat_prefix>.statements_insert: 2
postgres.<hostname/stat_prefix>.statements_other: 2
postgres.<hostname/stat_prefix>.statements_parse_error: 4
postgres.<hostname/stat_prefix>.statements_parsed: 4
postgres.<hostname/stat_prefix>.statements_select: 1
postgres.<hostname/stat_prefix>.statements_update: 1
tcp.<hostname/stat_prefix>.downstream_cx_no_route: 0
tcp.<hostname/stat_prefix>.downstream_cx_rx_bytes_buffered: 0
tcp.<hostname/stat_prefix>.downstream_cx_rx_bytes total: 1726
tcp.<hostname/stat_prefix>.downstream_cx_total: 2
tcp.<hostname/stat_prefix>.downstream_cx_tx_bytes_buffered: 0
tcp.<hostname/stat_prefix>.downstream_cx_tx_bytes_total: 1984
tcp.<hostname/stat_prefix>.idle_timeout: 1
tcp.<hostname/stat_prefix>.max_downstream_connection_duration: 0

Логи ошибок соединения#

Формат ошибки:

<Дата и время сообщения> warning/debug envoy conection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254 [Tags: "ConnectionId" : <connection id>] remote address:<the remote address of the socket>,TLS error:  <внутреняя библиотека Boringssl> : <функция ошибки Boringssl> : <тип ошибки> : <описание ошибки> : session_id: <session id>, SNI value for downstream host: <>, subject info: [O=service client organization,CN=service-client], ip sans peer <IP entries in the SAN field>, issuer info <issuer>, serial number <serial number>, expiration <expiration date> thread=<>

Пример:

2024-01-24T10:04:12.657335Z warning envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254 [Tags: "ConnectionId":"42"] remote address:XXX.XXX.XX.X:42636,TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED, session_id: 9e53231da5dae7c9f862f60bf01dac4dbf3a553d1040529d6f75c9643ac39dcb, SNI value for downstream host: [<hostname>], subject info: [O=service client organization,CN=service-client], ip sans peer [[]], issuer info CN=sec.syn,O=SynSec, serial number 0, expiration 2024-12-03T05:49:18.000Z    thread=36

В режиме логирования debug дополнительно выводится сертификат, использованный для подключения:

2024-01-24T10:13:50.029702Z debug   envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:271   [Tags: "ConnectionId":"91"] remote address:XXX.XXX.XX.X:60178,TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED, session_id: 76f18d66ebea8c6309fb2c34d5bbf43b0546811cb61f3b9af081c013094cc3d8, SNI value for downstream host: [<hostname>], subject info: [O=service client organization,CN=service-client], ip sans peer [[]], issuer info CN=sec.syn,O=SynSec, dns sans info [], serial number 0, expiration 2024-12-03T05:49:18.000Z, encoded cert [-----BEGIN%20CERTIFICATE-----%0A...%0A-----END%20CERTIFICATE-----%0A],
 cert chain [-----BEGIN%20CERTIFICATE-----%0A...%0A-----END%20CERTIFICATE-----%0A] thread=39
2024-01-24T10:13:50.029755Z debug   envoy connection external/envoy/source/common/network/connection_impl.cc:250    [Tags: "ConnectionId":"91"] closing socket: 0   thread=39

Настройка логирования Ingress, Egress — см. Сценарий 4. Настройка логирования на Ingress и Egress.

Включение debug в рантайме — см. Сценарий 5. Изменение уровня логирования Envoy в составе IGEG в рантайме.