自定义服务网格集成Istio：Pilot/Mixer/Auth API及运行时交互咨询

Great question! Integrating your custom service mesh with Istio to tap into its rich ecosystem (like Eureka, Cloud Foundry, Prometheus, etc.) is a smart move. Let’s break down how to access the Pilot, Mixer, and Auth APIs, plus the key runtime interaction patterns you’ll need.

Pilot API: Service Discovery & Routing Control #

API Access Paths #

• Code/Protocol Level: Pilot’s core APIs are built on the Envoy xDS protocol. You can directly leverage Istio’s official Go packages to work with these APIs:
  • Import istio.io/api for all xDS and control plane proto definitions
  • Import istio.io/pilot for Pilot-specific implementation details and utilities
• Network Endpoints:
  • Pilot’s gRPC service (for xDS communication) listens on port 15010 by default
  • REST endpoints for service discovery and config queries are available on port 15014 (e.g., fetching service registration data)

Runtime Interaction #

Your custom mesh’s data plane needs to act as an xDS client to sync with Pilot:

• Use the Aggregated Discovery Service (ADS) to subscribe to all required xDS resources (clusters, routes, endpoints, listeners) in a single stream. This keeps your data plane updated with Pilot’s service registry and routing rules automatically.
• For ad-hoc queries, call Pilot’s REST APIs—for example, GET /v1/registration/{service-name} to fetch the list of instances for a specific service.
• If you need to integrate with Eureka, Pilot has built-in adapters to pull data from Eureka; your custom mesh just needs to consume the standardized service discovery data Pilot surfaces via xDS.

Mixer API: Policy Checks & Telemetry Reporting #

Note: In newer Istio versions (1.10+), Mixer is being phased out in favor of Wasm extensions and Istiod’s built-in capabilities. If you’re using a recent release, prioritize Istiod’s unified APIs, but here’s how to work with legacy Mixer:

API Access Paths #

• Code Level: Mixer’s core APIs (Check, Report, Quota) are defined in the istio.io/api/mixer/v1 proto package.
• Network Endpoints:
  • Mixer’s gRPC service runs on port 9091 by default
  • Corresponding REST endpoints are also available for simpler, non-gRPC integration

Runtime Interaction #

Mixer acts as a central hub for policy enforcement and telemetry aggregation:

• Policy Checks: Before processing a request, your data plane should call Mixer’s Check API to validate permissions, enforce quotas, or run custom policy rules. Construct a CheckRequest with request metadata (like source/destination identities, request attributes) and send it to Mixer—you’ll get a response allowing or blocking the request.
• Telemetry Reporting: After the request completes, send a ReportRequest to Mixer with metrics, logs, or traces. Mixer uses adapters to route this data to systems like StatsD or Prometheus—you just need to ensure your data plane captures the required attributes and formats the request correctly.

Auth API: Identity & Access Control #

Istio’s Auth capabilities are now integrated into Istiod (the merged control plane of Pilot, Mixer, and Auth), but here’s how to access the relevant APIs:

API Access Paths #

• Code Level: Authentication and RBAC APIs are defined in:
  • istio.io/api/security/v1 (for mTLS, JWT auth policies)
  • istio.io/api/rbac/v1 (for role-based access control rules)
• Network Endpoints:
  • Istiod’s gRPC service for auth-related configs listens on port 15012
  • REST endpoints for auth policy queries are available via port 15014

Runtime Interaction #

• Config Sync: Your data plane should subscribe to auth policies from Istiod (via xDS or direct API calls) to enforce mTLS, JWT validation, or RBAC rules. For example, Istiod will push mTLS certificates and validation rules to your proxy automatically.
• Real-Time Checks: For dynamic RBAC decisions, your data plane can call Istiod’s RBAC Check API with the request’s source identity, target service, and action—Istiod will return whether the request is allowed.

内容的提问来源于stack exchange，提问作者user1511054