Получение журналов доступа Envoy с помощью Istio на GKE

Для версии Istio, управляемой Google (включенной установкой флажка в вашем кластере GKE), в версиях 1.13 и выше журналы доступа по умолчанию отключены с использованием configmap accessLogFile: "". В версиях 1.12 и более ранних журналы доступа включены по умолчанию, поэтому в configmap есть accessLogFile: "/dev/stdout".

Как вы отметили, вы не можете изменить его, так как согласование сотрет изменение.

Я зарегистрировал обращение в службу поддержки Google, чтобы найти лучший подход, и они предложили вместо этого использовать журналы Mixer. Чтобы получить к ним доступ, вам необходимо включить Stackdriver в вашем кластере GKE (либо устаревший, либо новый мониторинг Kubernetes Engine). Затем вы можете использовать фильтр logName="projects/[PROJECT-NAME]/logs/server-accesslog-stackdriver.logentry.istio-system".

Чтобы увидеть запросы между двумя сервисами, вы должны использовать этот запрос Stackdriver:

logName="projects/[PROJECT-NAME]/logs/server-accesslog-stackdriver.logentry.istio-system"
labels.destination_app="[YOUR-SERVICE]"
labels.source_app="[YOUR-OTHER-SERVICE]"

Чтобы увидеть запросы, исходящие извне GKE и проходящие через шлюз Istio Ingress:

logName="projects/[YOUR-PROJECT]/logs/server-accesslog-stackdriver.logentry.istio-system"
labels.destination_app="[YOUR-SERVICE]"
labels.source_app="istio-ingressgateway"

Однако эти журналы не на 100% эквивалентны журналам доступа к прокси-серверу и могут не помочь в устранении неполадок во всех сценариях. В Google открыт запрос функции для поддержки настройки карты конфигурации Istio, включая параметр accessLogFile: https://issuetracker.google.com/issues/126527530

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

Надеюсь, это поможет!

В GKE все stdout и stderr собираются и отправляется в лог-ротацию узла для последующего анализа и экспорта в Stackdriver через Fluentd.

Журналы доступа доступны с помощью команды kubectl logs, что означает, что они находятся в узле и анализируются и экспортируются с помощью агента Fluentd.

Я воспроизвел это и смог найти журналы доступа с помощью следующего расширенного фильтра Stackdriver (изменить в соответствии с вашими собственными ресурсами):

resource.type="container"
resource.labels.cluster_name="gke-cluster"
resource.labels.namespace_id="application-namespace"
resource.labels.project_id="project-id"
resource.labels.zone:"gcp-zone1-a"
resource.labels.container_name="istio-proxy"
resource.labels.pod_id:"sleep-"

Важные строки - это resource.labels.container_name="istio-proxy" для запроса контейнера istio-proxy и просмотра каждой реплики интересующего модуля с помощью resource.labels.pod_id:"sleep-".

Что касается configMap, поскольку GKE является управляемой реализацией Kubernetes, вы не должны изменять многие конфигурации, включая Fluentd. Цикл согласования автоматически сбрасывает все попытки изменения этих ресурсов.

Если вам это действительно нужно, вы можете развернуть собственную неуправляемую версию Свободно владеет GKE.