Kubernetes - Istio

Istio supports k8s Ingress, k8s Gateway and istio Gateway.

Ingress can point to different backend Services in spec.rules.

Hierarchy:

Gateway -> VirtualService -> Service (LoadBalancer)

Istion ingress = istio-ingressgateway service / deployment running envoy + Gateway + VirtualService

• Gateway (networking.istio.io): configure layer 4-6 load balancing properties such as ports to expose, TLS settings, and so on.
• VirtualService (networking.istio.io): application-layer traffic routing (L7); works in tandem with the Gateway; defines the destination service; defines the rules that control how requests for a service are routed within an Istio service mesh; configure routing to the backend services.
• istio-ingressgateway is a Service of LoadBalancer type.

An ingress controller is a piece of software that provides reverse proxy, configurable traffic routing, and TLS termination capabilities for Kubernetes services. Kubernetes ingress resources are used to configure the ingress rules and routes for individual Kubernetes services.

Istio provides some preconfigured gateway proxy deployments

• istio-ingressgateway
• istio-egressgateway: An egress gateway lets you configure a dedicated exit node for the traffic leaving the mesh, letting you limit which services can or should access external networks, or to enable secure control of egress traffic to add security to your mesh

Why Ingress? Otherwise needs multiple LoadBalancers, multiple public IPs.

Why not k8s Ingress? The Kubernetes Ingress resource has for some time been known to have significant shortcomings, especially when using it to configure ingress traffic for large applications and when working with protocols other than HTTP.

Components

• Control plane: istiod. run on Istio control plane; provsides service discovery, configuration and certificate management.
• Data plane: Envoy proxy. Envoy proxies are the only Istio components that interact with data plane traffic.

More:

• Kiali: The Console (i.e. UI) for Istio Service Mesh.
• otel-collector: otel = OpenTelemetry. Collect logs.
• istioctl: CLI.

API

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter

istiod traffic

• istiod of the primary cluster observes the API Servers in all clusters for endpoints. In this way, the control plane will be able to provide service discovery for workloads in all clusters. The service discovery includes both those with the sidecar and those without.
• Workloads / Services within the primary cluster opens direct connection to istiod.
• Workloads / Services within the remote clusters connects to the istiod via the Eastwest Gateway in the primary cluster.

xDS

DS = Discovery Service, x = a specific type, for example:

• ADS: Aggregated Discovery Service
• CDS: Cluster Discovery Service
• LDS: Listener Discovery Service
• RDS: Route Discovery Service

xDS protocol/API: based on gRPC; used for communication between the data plane (Envoy proxy, istio-proxy) and the control plane (istiod).

The data plane can communicate with one or multiple control planes:

• Istio uses a central control plane for managing the mesh
• Linkerd uses a decentralized control plane where each service has its own control plane instance.

When a new service instance is deployed, istio-proxy registers with the control plane to receive its configuration. The control plane istiod then sends the appropriate configuration updates to the istio-proxy, such as which service instances to route traffic to and what policies to apply.

Sidecar Mode vs Ambient Mode

Sidecar mode:

• per-pod proxy (using Envoy, inside the application pods)

Ambient mode:

• per-node Layer 4 (L4) proxy: ztunnel (Zero Trust tunnel) handle L3 and L4 functions such as mTLS, authentication, L4 authorization and telemetry.
• per-namespace Layer 7 (L7) proxy. Waypoint proxies (using Envoy, outside of application pods)

To enable ambient mode: You can enable all pods in a given namespace to be part of an ambient mesh by simply labeling the namespace

$ kubectl label namespace default istio.io/dataplane-mode=ambient
namespace/default labeled

istio-init vs istio-cni

By default Istio injects an init container, istio-init, in pods deployed in the mesh. The istio-init container sets up the pod network traffic redirection to/from the istio-proxy. This requires the user or service-account deploying pods to the mesh to have sufficient Kubernetes RBAC permissions to deploy containers with the NET_ADMIN and NET_RAW capabilities.

The istio-cni node agent is effectively a replacement for the istio-init container that enables the same networking functionality, but without requiring the use or deployment of privileged init containers in every workload. Instead, istio-cni itself runs as a single privileged pod on the node. It uses this privilege to install a chained CNI plugin on the node, which is invoked after your “primary” interface CNI plugin.