Руководство по системному администрированию#
Термины и определения#
Термин/аббревиатура |
Определение |
|---|---|
Платформа |
Платформа оркестрации приложений со средствами автоматизации и управления на основе политик, например 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.
Чтобы завершить подключение к контейнеру, достаточно выключить процесс (выполнить 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 контейнера:
Параметр |
Параметр |
Описание |
Возможные значения |
|---|---|---|---|
|
|
Путь к ротируемому файлу логов pilot-agent |
Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy |
|
|
Уровень детализации логов pilot-agent. |
Возможные значения |
|
|
Путь к ротируемому файлу логов Envoy |
Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy |
|
|
Уровень детализации логов Envoy |
Возможные значения: |
|
|
Путь к ротируемому файлу access-логов Envoy |
Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy |
|
|
Раз в минуту pilot-agent проверяет размеры указанных ротируемых файлов и копирует их содержимое в новый файл с именем в формате |
Целое число в МБ, |
|
|
Число бэкап-файлов, сохраняющихся при ротации. 0 - не удалять файлы |
Целое число, |
|
|
Число дней, которое хранятся файлы бэкапов |
Целое число, |
Пример настройки параметров логирования контейнера 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.#
Если в образе IGEG есть исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, то можно зайти в терминал контейнера istio-proxy и выполнить команду:
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#
Для автоматизации изменения числа Pod в зависимости от нагрузки предлагается использовать механизм horizontal pod autoscaler (HPA).
Создание ресурса HorizontalPodAutoscaler позволяет указать минимальное и максимальное количество Pod, параметры загрузки процессора, памяти, значения 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) или переносить на один узел.
Наиболее подходящим инструментом, позволяющим управлять расположением pod, является 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
До применения конфигурации список из десяти Pod приложения 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
Можно заметить, что Pod расположились на одном узле.
После применения конфигурации видно равномерное распределение Pod по узлам:
$ 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
Как воспроизвести
Если необходима доработка — нужно пропускать сертификаты по более сложному регулярному выражению. В итоге регулярное выражение следующее — .*MySystem1.*|.*MySystem2.*|.*MySystem3.*|.*MySystem4.*|.*MySystem5.*|.*MySystem6.*|.*MySystem7.*|.*MySystem8.*|.*MySystem9.*
Загрузите обновленный 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:21:18.319107Z warn ads ADS:LDS: ACK ERROR my-ingress.my-namespace Internal: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 200. Increase configured max program size if necessary.
Проверьте работу приложения. Убедитесь, что все работает. Трафик успешно проходит.
[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 списки отозванных сертификатов накладываются друг на друга.
При заполнении поля «caCRL» в манифестах Gateway или DestinationRule, то есть при ручном указании CRL, сам файл может быть смонтирован в pod из любого допустимого источника в соответствии с требованиями информационной безопасности: ConfigMap или Secret кластера Kubernetes, либо доставлен средствами внешней системы управления секретами.
В релизе Synapse Service Mesh 4.11.3 автоматическая загрузка и обновление CRL стала отключена по умолчанию.
Для подключения автозагрузки в компонент IGEG задайте в Deployment переменную среды ENABLE_AUTO_CRL как „true“.
Пример:
kind: Deployment
spec:
template:
spec:
containers:
...
- name: istio-proxy
env:
- name: ENABLE_AUTO_CRL
value: 'true'
...
Настройка проверки выполняется в ресурсах 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.
События мониторинга#
Сбор статистики осуществляется при обращении:
в формате prometheus: к порту 15000 по пути /stats/prometheus;
в формате envoy: к порту 15000 по пути /stats.
Данный запрос возвращает статистику в формате Prometheus. Система мониторинга, например, такая как компоненты продукта Platform V Monitor, может использовать данные события для построения графиков использования граничного прокси.
Примеры отображения метрик:
envoy_cluster_upstream_rq{response_code=»XXX», cluster_name=»YYY»} — количество запросов к вышестоящему сервису, где:
XXX - код ответа: 2xx, 3xx и так далее (классификация и описание кодов ответов приведено в разделе «Метрики компонента «Граничный прокси» (IGEG)»);
YYY - имя кластера.
Метрики компонента «Граничный прокси» (IGEG)#
Название и описание типов, применимых ко всем таблицам.
Таблица описания типов
Тип |
Название типа |
Описание |
|---|---|---|
тип |
counter |
Метрика, которая увеличивается на единицу каждый раз, когда происходит определенное событие |
тип |
gauge |
Тип метрики, который представляет текущее значение какого-либо показателя |
тип |
histogram |
Тип метрики, который используется для измерения и анализа распределения значений |
тип |
summary |
Тип метрики, который используется для вычисления и предоставления сводной информации о распределении значений |
Таблица описания кодов ответов
Группа |
Описание |
|---|---|
2xx |
Успешный запрос |
3xx |
Перенаправление |
4xx |
Ошибка клиента |
5xx |
Ошибка сервера |
Метрики граничного прокси#
Метрики граничного прокси отслеживают работу Envoy-прокси, принимающего входящий трафик от внешних клиентов в Service Mesh. Данные метрики важны для мониторинга доступности API, обнаружения отказов и выявления проблем с балансировкой. Данные метрики необходимо отслеживать:
При анализе доступности внешнего трафика.
При выявлении отказов, мониторинге производительности API.
Метрика |
Размерность |
Атрибут |
Описание |
|---|---|---|---|
http.<префикс>.downstream_rq{response_code_class=»4xx»} |
шт |
тип: counter |
Количество запросов от клиента к административному интерфейсу Envoy, получивших ответ со статусом 4xx |
http.<префикс>.downstream_rq{response_code_class=»5xx»} |
шт |
тип: counter |
Количество запросов от клиента к Envoy, получивших ответ со статусом 5xx |
http.<префикс>.downstream_cx_active |
шт |
тип: gauge |
Количество активных соединений от клиента к listener в Envoy |
http.<префикс>.downstream_rq_time |
мс |
тип: histogram |
Гистограмма времени обработки HTTP-запроса от клиента к Envoy (в миллисекундах) с указанием перцентилей (P0, P25, P50, P75, P90, P95, P99, P99.5, P99.9, P100) |
Метрики конфигурации и управления#
Метрики конфигурации и управления обеспечивают мониторинг обновлений конфигурации в Service Mesh (кластеры, слушатели, секреты, маршруты), позволяют оперативно выявлять сбои при загрузке и распространении конфигурации. Данные метрики необходимо отслеживать при следующих событиях:
При обновлении конфигурации кластера.
При выявлении ошибок конфигурации.
При анализе отказов в обновлениях.
Метрика |
Размерность |
Атрибут |
Описание |
|---|---|---|---|
cluster.<имя>.bind_errors |
шт |
тип: counter |
Количество случаев, когда Envoy не смог успешно привязать сокет для соединения с сервером xDS через gRPC |
cluster.<имя>.http2.streams_active |
шт |
тип: gauge |
Количество HTTP/2 потоков, которые в данный момент используются для передачи данных между Envoy и сервером xDS через gRPC |
listener_manager.listener_added |
шт |
тип: counter |
Количество добавленных listener |
cluster.<имя кластера>.update_attempt |
шт |
тип: counter |
Количество попыток обновления кластера |
listener_manager.<имя>.update_attempt |
шт |
тип: counter |
Количество попыток обновления LDS |
sds.<имя секрета>.update_attempt |
шт |
тип: counter |
Количество попыток обновления SDS |
cluster_manager.cds.update_attempt |
шт |
тип: counter |
Количество попыток обновления CDS |
cluster.<имя кластера>.update_failure |
шт |
тип: counter |
Количество неудачных попыток обновления кластера |
cluster_manager.<имя>.update_failure |
шт |
тип: counter |
Количество неудачных обновлений CDS |
listener_manager.<имя>.update_failure |
шт |
тип: counter |
Количество неудачных обновлений LDS |
sds.<имя>.update_failure |
шт |
тип: counter |
Количество неудачных обновлений SDS |
cluster.<имя>.assignment_stale |
шт |
тип: counter |
Количество случаев, когда Envoy получил от сервера xDS (Extensible Discovery Service) устаревшую конфигурацию |
listener_manager.listener_create_failure |
шт |
тип: counter |
Количество неудачных попыток создания listener |
listener_manager.total_listeners_active |
шт |
тип: gauge |
Общее количество активных listener |
cluster.<имя>.upstream_cx_idle_timeout |
шт |
тип: counter |
Количество соединений от Envoy к сервису, завершенных из-за простоя (idle timeout) |
cluster.<имя>.upstream_rq_per_try_timeout |
шт |
тип: counter |
Количество запросов к вышестоящему сервису, завершенных из-за таймаута в течение попытки |
cluster.<имя>.upstream_rq_per_try_idle_timeout |
шт |
тип: counter |
Количество запросов, завершенных из-за таймаута простоя в рамках одной попытки |
Административные и системные метрики Envoy#
Административные и системные метрики Envoy отражают внутреннее состояние Envoy, включая информацию о соединениях, запросах, и системных ресурсах. Данные метрики необходимо отслеживать при следующих событиях:
При мониторинге общей производительности и стабильности.
При диагностике проблем с соединениями и запросами.
При анализе использования системных ресурсов.
После изменений в конфигурации Envoy.
Метрика |
Размерность |
Атрибут |
Описание |
|---|---|---|---|
http.<префикс>.downstream_cx_total |
шт |
тип: counter |
Общее количество соединений когда-либо установленных с |
listener.<адрес>.downstream_cx_total |
шт |
тип: counter |
Общее количество соединений от клиента к listener в Envoy |
listener.<адрес>.main_thread.downstream_cx_total |
шт |
тип: counter |
Общее количество соединений от клиента к Envoy на главном потоке |
http.<префикс>.downstream_rq{response_code_class=»2xx»} |
шт |
тип: counter |
Общее количество успешных HTTP-запросов, обработанных Envoy proxy |
listener.<адрес>.http.<префикс>.downstream_rq{response_code_class=»2xx»} |
шт |
тип: counter |
Количество запросов от клиента к административному интерфейсу Envoy, получивших ответ со статусом 2xx |
listener.<адрес>.http.<префикс>.downstream_rq{response_code_class=»5xx»} |
шт |
тип: counter |
Количество HTTP-запросов от клиента к listener в Envoy, получивших ответ со статусом 5xx. Резкий рост может указывать на проблемы с listener, отказ бэкенд-сервисов. В норме значение должно быть близко к 0 |
http.<префикс>.downstream_rq_total |
шт |
тип: counter |
Общее количество запросов от клиента к Envoy для HTTP-запросов |
http.<префикс>.downstream_cx_ssl_active |
шт |
тип: gauge |
Количество активных SSL-соединений от клиента к Envoy |
http.<префикс>.downstream_cx_ssl_total |
шт |
тип: counter |
Общее количество SSL-соединений от клиента к Envoy |
http.agent.rq_total |
шт |
тип: counter |
Общее количество обработанных HTTP-запросов |
http.<префикс>.downstream_rq_timeout |
шт |
тип: counter |
Количество запросов от клиента к Envoy, завершенных из-за таймаута |
Метрики обновления секретов#
Имя |
Тип |
Описание |
|---|---|---|
envoy_sds_SECRET_NAME_update_attempt |
counter |
Количество попыток обновить секрет |
envoy_sds_SECRET_NAME_update_success |
counter |
Количество успешных обновлений секретов |
envoy_sds_SECRET_NAME_update_failure |
counter |
Количество неудачных попыток обновить секрет |
envoy_sds_SECRET_NAME_update_duration |
histogram |
Гистограмма распределения времени обновления секрета в кэше прокси |
envoy_cluster_client_ssl_socket_factory_ssl_context_update_by_sds |
counter |
Количество обновленных контекстов SSL для входящих соединений в Cluster через SDS |
envoy_listener_server_ssl_socket_factory_ssl_context_update_by_sds |
counter |
Количество обновленных контекстов SSL для исходящих в Listener через SDS |
Метрики 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
Часто встречающиеся проблемы и пути их устранения#
Проблема |
Пути решения |
|---|---|
Граничный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready |
Проверьте корректность подключения к контрольной панели. |
До прикладного приложения не доходят запросы |
Проверьте access-логи граничного прокси. Возможные варианты сообщений описаны ниже. |
В access-логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном namespace. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров host/порт в конфигурационных файлах прикладного namespace — Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний host, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания host/порт |
В access-логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном namespace. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule |
В access-логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном namespace. Если используется автоматическая аутентификация |
В access-логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном namespace. Проверьте наличие вызываемого сервиса — в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис — в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение |
В access-логе граничного прокси видны сообщения: |
Проверьте имена портов в объектах Service: они должны иметь формат <протокол>-<номер_порта>. Если имя порта начинается с |
Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели.
Мониторинг ошибок соединения#
Следующие статистики расположены по адресу 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
Логи ошибок соединения#
Формат ошибки:
<Дата и время сообщения> 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 в рантайме.