Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

167
Views
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 answers
Answer question

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!