Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

177
Visualizações
Istio best practice for managing microservices and monolith services in same k8s tenant for common usage

I am new in istio therefore might be nonsense question but I would like to understand the best approach.. I have these namespaces as below in k8s.. So currently the microservice running in hub-dev can able to access PostgreSQL where the istio is disabled for database namespace.

  1. How could it be possible in STRICT mode or did I do something wrong or analyse a wrong way? So it means pod in mesh can talk with another pod which is not meshed, but the other pod can not talk any other pod which is meshed ?

as you can see here, seems my application can talk with database

[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 - -

I have some monolith service running analytics namespace where these services needs to connect logging and monitoring likewise the microservices running in hub-dev .. So if I enabled Istio for logging and monitoring, the services running in analytics namespace could not able to access the services running in logging and monitoring , am I right? so should ı create another ELK or prometheus instances ?

So what is the best approach to manage this flow ?

$ 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

And here is peerauthentication

$ 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
over 4 years ago · Santiago Trujillo
1 Respostas
Responde à pergunta

0

You are correct in both cases:

  1. A service that is outside of the mesh, can't talk to a service within the mesh, when strict mode is enabled, but vice-versa is possible.
  2. If logging and monitoring get into the mesh, indeed, analytics can't communicate with it, when STRICT mode is enabled.
over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda