Почему журналы микшера istio работают по-другому для моего случая? - PullRequest
Новая
       13

Почему журналы микшера istio работают по-другому для моего случая?

0 голосов
/ 02 октября 2019

У меня есть БД в пространстве имен ns-restriction-demo-2 и приложение nodeJs, которое использует эту БД из пространства имен ns-restriction-demo-1. Поэтому я пытался добавить авторизацию, т. Е. Доступ к БД возможен только из одного пространства имен (ns-limitction-demo-1), но когда я включаю журналы микшера, я понимаю, что атрибуты источника отличаются. 

{
  "level": "warn",
  "time": "0001-01-01T00:00:00.000000Z",
  "instance": "newlog.instance.ns-restriction-demo-2",
  "destination": "db-demo-2",
  "destinationName": "db-demo-2-868c4bb6c7-f5l7c",
  "destinationNamespace": "ns-restriction-demo-2",
  "destinationPort": 3306,
  "destinationPrinciple": "unkown",
  "latency": "0s",
  "mtls": false,
  "requestHost": "unkown",
  "responseCode": 0,
  "responseSize": 0,
  "source": "calico-node",
  "sourceName": "calico-node-ljzxl",
  "sourceNamespace": "kube-system",
  "sourcePrinicple": "unkown",
  "sourceServiceAccount": "calico-node",
  "sourceservices": "unkown",
  "user": "unknown"
}

Конфигурация, которую я использовал 

apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: newlog
  namespace: ns-restriction-demo-2
spec:
  compiledTemplate: logentry
  params:
    severity: '"warning"'
    variables:
      sourceName: source.name | "unkown"
      sourceNamespace: source.namespace | "unkown"
      sourcePrinicple: source.principal | "unkown"
      sourceServiceAccount: source.serviceAccount | "unkown"
      sourceservices: source.services | "unkown"
      destinationPort: destination.port | 0
      destinationName: destination.name | "unkown"
      destinationNamespace: destination.namespace | "unkown"
      destinationPrinciple: destination.principal | "unkown"
      requestHost: request.host | "unkown"
      source: source.labels["app"] | source.workload.name | "unknown"
      user: source.user | "unknown"
      mtls: connection.mtls | false
      destination: destination.labels["app"] | destination.workload.name | "unknown"
      responseCode: response.code | 0
      responseSize: response.size | 0
      latency: response.duration | "0ms"
    monitored_resource_type: '"UNSPECIFIED"'
---
# Configuration for a stdio handler
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: newloghandler
  namespace: ns-restriction-demo-2
spec:
  compiledAdapter: stdio
  params:
    severity_levels:
      warning: 1 # Params.Level.WARNING
    outputAsJson: true
---
# Rule to send logentry instances to a stdio handler
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: newlogstdio
  namespace: ns-restriction-demo-2
spec:
  match: "true" # match for all requests
  actions:
   - handler: newloghandler
     instances:
     - newlog
---

Итак, у меня есть вопрос к эксперту istio здесь. Почему source или sourceName или sourceNamespace относится к ситцу? почему речь идет не о том приложении nodeJs, которое использует эту базу данных?

Пожалуйста, помогите мне понять, что я сделал неправильно или что-то упустил?

Calico Version 

Client Version:    v3.5.8
Git commit:        107e128
Cluster Version:   v3.6.2
Cluster Type:      k8s,bgp,kdd

Другие версии

  • Istio: 1.1.10
  • Kubernetes: 1.13.6

1 Ответ

0 голосов
/ 16 октября 2019

Сбор метрик с помощью Mixer для служб TCP отличается от HTTP.

Доступ к вашей базе данных является примером рабочей нагрузки TCP внутри Istio Mesh.

Поэтому, пожалуйста, используйте специальный ' tcpaccesslog 'шаблон вместо' logentry ', который включает в атрибуты, отображающие действительную конфигурацию протокола: 

'protocol: context.protocol | "tcp"'

Это помогает Istio правильно выводить атрибуты source и sourceName.

Примечание: если запросы к БД отправляются через TCP-соединение с поддержкой mTLS, у вас должны быть доступны некоторые дополнительные атрибуты:

  • source.workload.name
  • source.workload.namespace
...