Traffic Management practice questions

kubectl get

kubectl get queries the Kubernetes API server for Istio custom resources such as VirtualServices, Gateways and DestinationRules within the specified namespace, listing their current state. This satisfies the requirement to view existing Istio configuration resources without modifying them.

To limit the configuration sent to a proxy

The Sidecar resource scopes the configuration that Istio's control plane pushes to the sidecar proxies in a namespace or workload, reducing memory and configuration load. It limits what each proxy receives, not what traffic it forwards.

VirtualService timeout

A VirtualService route rule carries the timeout field, which caps how long Envoy waits for a response from the external destination before aborting. ServiceEntry alone defines the host but cannot express per-route timeouts, so the VirtualService is required.

Kiali

Kiali's traffic graph and workload detail views surface Envoy-generated response flags and error codes, pinpointing why a request failed. This satisfies the stem's troubleshooting need by correlating failures across the mesh rather than inspecting a single proxy's logs.

DestinationRule

DestinationRule defines circuit breaking logic.

DestinationRule

DestinationRule defines connection pool settings.

By creating a ServiceEntry with resolution DNS

DNS resolution lets the ServiceEntry resolve the external hostname at request time, so TLS origination and routing work correctly for the external TLS service. This satisfies the stem's need to route traffic to an externally hosted endpoint.

Gateway

Gateway handles TLS termination.

kubectl get virtualservices

Lists the resource.

They are merged

Istio merges multiple VirtualServices sharing the same host by combining their route rules into one effective configuration. Conflicting matches across the merged set are resolved by Istio's precedence ordering rather than one VirtualService overriding the other.

regex field

The regex field under a match condition specifies a regular expression that the request attribute must satisfy, such as a URI pattern. This is the mechanism Istio uses to express regex-based matching in a VirtualService.

DestinationRule

ConnectionPool is in DestinationRule.

uri

The uri criterion matches on the request path, letting a VirtualService route traffic by URL. Istio's match block supports uri alongside headers, method, scheme, authority, port and sourceLabels, so it satisfies the requirement for a valid request-attribute match condition.

headers

The VirtualService match block supports headers as a criterion, allowing routing decisions based on HTTP header keys and exact, prefix or regex values. This satisfies the question's requirement for valid match criteria in Istio traffic management.

sourceLabels

`sourceLabels` matches traffic by the workload labels of the originating pod, satisfying the requirement for a label-based source criterion within the `match` block. Istio evaluates these labels against the source workload's identity, enabling routing decisions scoped to specific callers rather than destination attributes.

ROUND_ROBIN

ROUND_ROBIN is a valid DestinationRule load balancer algorithm, distributing requests cyclically across healthy endpoints in the pool. Istio's trafficPolicy loadBalancer settings support it alongside RANDOM and PASSTHROUGH, satisfying the question's requirement for a genuine algorithm rather than a routing action.

LEAST_CONN

LEAST_CONN is a valid DestinationRule load balancer algorithm, routing each request to the endpoint with the fewest active connections. Istio's trafficPolicy loadBalancer supports it alongside ROUND_ROBIN and RANDOM, satisfying the question's requirement for a genuine algorithm.

To enable mTLS for an external service

ServiceEntry registers external hosts into Istio's registry, and its tls block with mode MUTUAL plus client certificates enables mTLS to that external service. It satisfies the external-service requirement because mesh policies, including mutual TLS origination, otherwise apply only to registered endpoints.

To add an external service to the mesh registry

ServiceEntry adds external endpoints, such as APIs or databases outside the mesh, into Istio's internal service registry. This lets sidecars treat them as mesh services, enabling discovery, policy enforcement and telemetry for traffic that would otherwise bypass Istio entirely.

To manage routing for external traffic

Once an external host is registered, Istio's routing rules apply to it. VirtualService and DestinationRule can then govern traffic to that external service, providing load balancing, retries and traffic splitting for egress destinations that the mesh otherwise could not control.

NONE

NONE resolution tells Istio the endpoint addresses are already resolved IPs, so no DNS lookup occurs and traffic routes directly to the listed addresses. This suits static backends where resolution is unnecessary, satisfying the stem's requirement for a valid ServiceEntry resolution type.

DNS

DNS resolution makes Istio periodically query the configured DNS name to refresh the ServiceEntry's endpoint addresses, rather than treating them as static IPs. This satisfies the stem by naming a valid resolution type for dynamically resolved external hosts.

consecutiveGatewayErrors

Valid parameter.

baseEjectionTime

Valid parameter.

interval

Valid parameter.

TCP

Gateway server ports accept TCP alongside HTTP, HTTPS and TLS, with TCP used for opaque or non-HTTP protocols. This satisfies the stem's protocol selection, letting the gateway proxy raw TCP streams without HTTP-level route processing.

HTTP

HTTP is a supported protocol field value on an Istio Gateway, letting the server accept plaintext HTTP traffic on the specified port. It satisfies the stem's requirement for a definable gateway protocol, though production traffic should prefer TLS-terminated listeners.

HTTPS

HTTPS is a valid Gateway protocol value, configuring the listener to terminate TLS using a referenced credential and serve encrypted HTTP traffic. It satisfies the stem's requirement for definable gateway protocols and is the standard choice for external client access.

match

The 'match' field defines the conditions—URI, headers, method, port—under which an HTTP route applies, and it is a valid top-level field within the VirtualService 'http' stanza. It satisfies the question's requirement by being one of the two legitimate route fields alongside 'route'.

route

The 'route' field holds the ordered list of destination rules, each pairing a destination host with a weight, and it is a valid top-level field in the VirtualService 'http' stanza. It satisfies the question by being one of the two legitimate route fields alongside 'match'.

Kubernetes API

Underlying dependency.

istiod

Main component.