Get desktop application:
View/edit binary Protocol Buffers messages
Address represents a unique address. Address joins two sub-resources, Workload and Service, to support querying by IP address. Address is intended to be able to be looked up on-demand, allowing a client to answer a question like "what is this IP address", similar to a reverse DNS lookup. Each resource will have a mesh-wide unique opaque name, defined in the individual messages. In addition, to support lookup by IP address, they will have *alias* names for each IP the resource represents. There may be multiple aliases for the same resource (examples: service in multiple networks, or a dual-stack workload). Aliases are keyed by network/IP address. Example: "default/1.2.3.4". In some cases, we do not know the IP address of a Workload. For instance, we may simply know that there is a workload behind a gateway, and rely on the gateway to handle the rest. In this case, the key format will be "resource-uid". The resource can be a Pod, WorkloadEntry, etc. These resources cannot be looked up on-demand. In some cases, we do not know the IP address of a Service. These services cannot be used for matching outbound traffic, as we only have L4 attributes to route based on. However, they can be used for Gateways. In this case, the key format will be "network/hostname". These resources cannot be looked up on-demand.
Workload represents an individual workload. This could be a single Pod, a VM instance, etc.
Service represents a service - a group of workloads that can be accessed together.
ApplicationProtocol specifies a workload (application or gateway) can consume tunnel information.
Used in:
A target natively handles this type of traffic.
optional: if set, traffic should be sent to this port after the last zTunnel hop
Used in:
Bytes are copied from the inner stream without modification.
Prepend PROXY protocol headers before copying bytes Standard PROXY source and destination information is included, along with potential extra TLV headers: 0xD0 - The SPIFFE identity of the source workload 0xD1 - The FQDN or Hostname of the targeted Service
Extension provides a mechanism to attach arbitrary additional configuration to an object.
Used in:
,name provides an opaque name for the extension. This may have semantic meaning or used for debugging. This should be unique amongst all extensions attached to an item.
config provides some opaque configuration.
GatewayAddress represents the address of a gateway
Used in:
,address can either be a hostname (ex: gateway.example.com) or an IP (ex: 1.2.3.4).
TODO: add support for hostname lookup
port to reach the gateway at for mTLS HBONE connections
Used in:
AUTOMATIC is inferred from the configured addresses.
Only IPv4 is supported
Only IPv6 is supported
Both IPv4 and IPv6 is supported
Used in:
routing_preference defines what scopes we want to keep traffic within. The `mode` determines how these routing preferences are handled
mode defines how we should handle the routing preferences.
health_policy defines how we should filter endpoints
Used in:
Only select healthy endpoints
Include all endpoints, even if they are unhealthy.
Used in:
In STRICT mode, only endpoints that meets all of the routing preferences will be considered. This can be used, for instance, to keep traffic ONLY within the same cluster/node/region. This should be used with caution, as it can result in all traffic being dropped if there is no matching endpoints, even if there are endpoints outside of the preferences.
In FAILOVER mode, endpoint selection will prefer endpoints that match all preferences, but failover to groups of endpoints that match less (or, eventually, none) preferences. For instance, with `[NETWORK, REGION, ZONE]`, we will send to: 1. Endpoints matching `[NETWORK, REGION, ZONE]` 2. Endpoints matching `[NETWORK, REGION]` 3. Endpoints matching `[NETWORK]` 4. Any endpoints
Used in:
Prefer traffic in the same region.
Prefer traffic in the same zone.
Prefer traffic in the same subzone.
Prefer traffic on the same node.
Prefer traffic in the same cluster.
Prefer traffic in the same network.
Used in:
NamespacedHostname represents a service bound to a specific namespace.
Used in:
The namespace the service is in.
hostname (ex: gateway.example.com)
NetworkAddress represents an address bound to a specific network.
Used in:
,Network represents the network this address is on.
Address presents the IP (v4 or v6).
NetworkMode indicates how the addresses of the workload should be treated.
Used in:
STANDARD means that the workload is uniquely identified by its address (within its network).
HOST_NETWORK means the workload has an IP address that is shared by many workloads. The data plane should avoid attempting to lookup these workloads by IP address (which could return the wrong result).
Used in:
,Port the service is reached at (frontend).
Port the service forwards to (backend).
PorList represents the ports for a service
Used in:
Service represents a service - a group of workloads that can be accessed together. The xds primary key is "namespace/hostname". Secondary (alias) keys are the unique `network/IP` pairs that the service can be reached at.
Used in:
Name represents the name for the service. For Kubernetes, this is the Service name.
Namespace represents the namespace for the service.
Hostname represents the FQDN of the service. For Kubernetes, this would be <name>.<namespace>.svc.<cluster domain>.
Address represents the addresses the service can be reached at. There may be multiple addresses for a single service if it resides in multiple networks, multiple clusters, and/or if it's dual stack. For a headless kubernetes service, this list will be empty.
Ports for the service. The target_port may be overridden on a per-workload basis.
Optional; if set, the SAN to verify for TLS connections. Typically, this is not set and per-workload identity is used to verify
Waypoint is the waypoint proxy for this service. When set, all incoming requests must go through the waypoint.
Load balancing policy for selecting endpoints. Note: this applies only to connecting directly to the workload; when waypoints are used, the waypoint's load_balancing configuration is used.
IP families provides configuration about the IP families this service supports.
Extension provides a mechanism to attach arbitrary additional configuration to an object.
TunnelProtocol indicates the tunneling protocol for requests.
Used in:
NONE means requests should be forwarded as-is, without tunneling.
HBONE means requests should be tunneled over HTTP. This does not dictate HTTP/1.1 vs HTTP/2; ALPN should be used for that purpose.
Future options may include things like QUIC/HTTP3, etc.
Workload represents a workload - an endpoint (or collection behind a hostname). The xds primary key is "uid" as defined on the workload below. Secondary (alias) keys are the unique `network/IP` pairs that the workload can be reached at.
Used in:
UID represents a globally unique opaque identifier for this workload. For k8s resources, it is recommended to use the more readable format: cluster/group/kind/namespace/name/section-name As an example, a ServiceEntry with two WorkloadEntries inlined could become two Workloads with the following UIDs: - cluster1/networking.istio.io/v1alpha3/ServiceEntry/default/external-svc/endpoint1 - cluster1/networking.istio.io/v1alpha3/ServiceEntry/default/external-svc/endpoint2 For VMs and other workloads other formats are also supported; for example, a single UID string: "0ae5c03d-5fb3-4eb9-9de8-2bd4b51606ba"
Name represents the name for the workload. For Kubernetes, this is the pod name. This is just for debugging and may be elided as an optimization.
Namespace represents the namespace for the workload. This is just for debugging and may be elided as an optimization.
Address represents the IPv4/IPv6 address for the workload. This should be globally unique. This should not have a port number. Each workload must have at least either an address or hostname; not both.
The hostname for the workload to be resolved by the ztunnel. DNS queries are sent on-demand by default. If the resolved DNS query has several endpoints, the request will be forwarded to the first response. At a minimum, each workload must have either an address or hostname. For example, a workload that backs a Kubernetes service will typically have only endpoints. A workload that backs a headless Kubernetes service, however, will have both addresses as well as a hostname used for direct access to the headless endpoint.
Network represents the network this workload is on. This may be elided for the default network. A (network,address) pair makeup a unique key for a workload *at a point in time*.
Protocol that should be used to connect to this workload.
The SPIFFE identity of the workload. The identity is joined to form spiffe://<trust_domain>/ns/<namespace>/sa/<service_account>. TrustDomain of the workload. May be elided if this is the mesh wide default (typically cluster.local)
ServiceAccount of the workload. May be elided if this is "default"
If present, the waypoint proxy for this workload. All incoming requests must go through the waypoint.
If present, East West network gateway this workload can be reached through. Requests from remote networks should traverse this gateway.
Name of the node the workload runs on
CanonicalName for the workload. Used for telemetry.
CanonicalRevision for the workload. Used for telemetry.
WorkloadType represents the type of the workload. Used for telemetry.
WorkloadName represents the name for the workload (of type WorkloadType). Used for telemetry.
If set, this indicates a workload expects to directly receive tunnel traffic. In ztunnel, this means: * Requests *from* this workload do not need to be tunneled if they already are tunneled by the tunnel_protocol. * Requests *to* this workload, via the tunnel_protocol, do not need to be de-tunneled.
If an application, such as a sandwiched waypoint proxy, supports directly receiving information from zTunnel they can set application_protocol.
The services for which this workload is an endpoint. The key is the NamespacedHostname string of the format namespace/hostname.
A list of authorization policies applicable to this workload. NOTE: this *only* includes Selector based policies. Namespace and global polices are returned out of band. Authorization policies are only valid for workloads with `addresses` rather than `hostname`.
The cluster ID that the workload instance belongs to
The Locality defines information about where a workload is geographically deployed
Extension provides a mechanism to attach arbitrary additional configuration to an object.
Capacity for this workload. This represents the amount of traffic the workload can handle, relative to other workloads If unset, the capacity is default to 1.
Used in:
Workload is healthy and ready to serve traffic.
Workload is unhealthy and NOT ready to serve traffic.
Used in: