Soy nuevo en istio, por lo tanto, podría ser una pregunta sin sentido, pero me gustaría entender el mejor enfoque. Tengo estos espacios de nombres como se muestra a continuación en k8s. Por lo tanto, actualmente el microservicio que se ejecuta en hub-dev puede acceder a PostgreSQL donde istio está deshabilitado. para el espacio de nombres de la base de datos.

1. ¿Cómo podría ser posible en modo STRICT o hice algo mal o analicé de manera incorrecta? Entonces, ¿significa que el pod en malla puede hablar con otro pod que no está en malla, pero el otro pod no puede hablar con ningún otro pod que esté en malla?

como puede ver aquí, parece que mi aplicación puede hablar con la base de datos

 [2021-01-15T15:21:38.601Z] "GET /userinfo?t=1610724097377 HTTP/1.1" 200 - "-" 0 236 5 3 "95.0.145.40,10.6.0.24" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36" "34130335-b0dd-4cca-b157-f612e3767c9c" "oneapihub-auth-dev" "127.0.0.1:50002" inbound|80|| 127.0.0.1:51230 10.6.19.251:50002 10.6.0.24:0 outbound_.80_._.oneapihub-auth-dev.hub-dev.svc.cluster.local default [2021-01-15T15:21:38.608Z] "- - -" 0 - "-" 374 778 10012 - "-" "-" "-" "-" "10.6.5.95:64000" outbound|64000||my-postgres-postgresql-helm.database.svc.cluster.local 10.6.19.251:50024 10.254.134.161:64000 10.6.19.251:47396 - -

Tengo un servicio monolítico que ejecuta un espacio de nombres de analytics donde estos servicios necesitan conectarse para el logging y la monitoring , al igual que los microservicios que se ejecutan en hub-dev. Entonces, si habilité Istio para el logging y la monitoring , los servicios que se ejecutan en el espacio de nombres de análisis no podrían acceder a los servicios. ejecutando en el logging y la monitoring , ¿verdad? Entonces, ¿debería crear otras instancias de ELK o Prometheus?

Entonces, ¿cuál es el mejor enfoque para administrar este flujo?

 $ kubectl get ns --show-labels NAME STATUS AGE LABELS database Active 319d name=database analytics Actice. 20d. name=analytics hub-dev Active 46h istio-injection=enabled istio-system Active 2d8h istio-injection=disabled logging Active 133d purpose=logging monitoring Active 291d name=monitoring,namespace=monitoring

Y aquí está la autenticación entre pares

 $ kubectl get peerauthentication -n istio-system -o yaml apiVersion: v1 items: - apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"security.istio.io/v1beta1","kind":"PeerAuthentication","metadata":{"annotations":{},"name":"default","namespace":"istio-system"},"spec":{"mtls":{"mode":"STRICT"}}} name: default namespace: istio-system spec: mtls: mode: STRICT