Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

The Istio service mesh mediates traffic between workloads so services inside the mesh can call each other through their Envoy sidecars (for example, Service 1 → Service 3 → Service 2).
A diagram titled "Istio Service Mesh" inside a Kubernetes boundary showing three nodes. Each node contains an app, a service, and an Envoy sidecar, illustrating service-to-service communication through the mesh.

​
Outbound traffic policy: REGISTRY_ONLY vs ALLOW_ANY

When you install Istio with the IstioOperator you can set a mesh-wide outbound traffic policy that controls how Envoy handles outbound requests to external services. The two modes are:
ModeBehavior
REGISTRY_ONLYEnvoy only allows outbound traffic to services present in Istio’s internal service registry (including ServiceEntry resources). Unknown external destinations are blocked.
ALLOW_ANYEnvoy passes through requests to unknown external services (default). Istio has limited visibility and cannot apply traffic management, security, or telemetry to those calls.
A documentation slide titled "Outbound Traffic Policy" explaining meshConfig.outboundTrafficPolicy.mode for sidecars. It shows a table of mode options (e.g., REGISTRY_ONLY, ALLOW_ANY) with descriptions of how unknown outbound traffic is handled.
By default Istio uses ALLOW_ANY, which simplifies reaching external services but prevents Istio from applying telemetry, routing, or security controls to those calls. Switching to REGISTRY_ONLY forces you to explicitly register external services so Istio can manage them.
If you set meshConfig.outboundTrafficPolicy.mode to REGISTRY_ONLY and you do not declare a ServiceEntry for an external host, Envoy will drop outbound traffic to that host.

​
What is a ServiceEntry?

A ServiceEntry adds external (or otherwise non-discovered) hosts into Istio’s internal service registry. Once an external host is defined as a ServiceEntry, Envoy can treat it like any other mesh service so Istio can apply:
  • Traffic management (retries, timeouts, routing)
  • Security controls (mTLS where applicable, access policies)
  • Telemetry and observability for egress traffic
Use cases:
  • Enable controlled access to databases, APIs, or third-party services when REGISTRY_ONLY is enforced.
  • Centralize egress configuration so policies and telemetry apply consistently across the mesh.

​
Installing Istio with REGISTRY_ONLY

To change the default behavior during installation, set meshConfig.outboundTrafficPolicy.mode to REGISTRY_ONLY in your IstioOperator spec. Example: 
apiVersion: networking.istio.io/v1
kind: IstioOperator
spec:
  components:
    base:
      enabled: true
    cni:
      enabled: false
    egressGateways:
    - enabled: false
      name: istio-egressgateway
    ingressGateways:
    - enabled: true
      name: istio-ingressgateway
    istiodRemote:
      enabled: false
    pilot:
      enabled: true
  hub: docker.io/istio
  meshConfig:
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY
  defaultConfig:
    proxyMetadata: {}

​
Example: ServiceEntry for a PostgreSQL database

When your mesh uses REGISTRY_ONLY, declare each external service with a ServiceEntry. The following ServiceEntry allows workloads in the frontend namespace to reach db.example.com:5432: 
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: postgres-db
  namespace: frontend
spec:
  hosts:
  - db.example.com
  ports:
  - number: 5432
    name: db
    protocol: TCP
  resolution: DNS
Note: This ServiceEntry is namespace-scoped (namespace: frontend), so only workloads in the frontend namespace can use it. Workloads in other namespaces (for example, default) will still be blocked under REGISTRY_ONLY unless a ServiceEntry is created for their namespace or a cluster-wide approach is used.

​
Key ServiceEntry fields

FieldPurpose
hostsDomain names or hostnames for the external service.
portsPort numbers and protocols to expose for the host.
resolutionHow endpoints are resolved: DNS, STATIC, or NONE.
endpointsStatic IPs used when resolution: STATIC.
locationMESH_EXTERNAL or MESH_INTERNAL to indicate where the service resides.

​
Why use ServiceEntry if ALLOW_ANY is easier?

  • Centralized management: Declare external services so policies and configurations are consistent.
  • Traffic control: Apply retries, timeouts, and routing to egress calls.
  • Security and compliance: Enforce access rules and mTLS for outbound traffic.
  • Observability: Capture telemetry for external calls rather than losing visibility in pass-through mode.

​
References and further reading

In this lesson you learned what a ServiceEntry is, why it’s required when outboundTrafficPolicy is set to REGISTRY_ONLY, and how to declare a basic ServiceEntry for an external PostgreSQL database. For the Istio Certified Associate (ICA) exam, be comfortable creating ServiceEntry resources (including specifying ports) and understanding how outboundTrafficPolicy affects egress behavior.

Watch Video