mirror of https://github.com/istio/istio.io.git
5 lines
5.1 KiB
XML
5 lines
5.1 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Traffic Management on Istio</title><link>/v1.3/docs/reference/config/networking/</link><description>Recent content in Traffic Management on Istio</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="/v1.3/docs/reference/config/networking/feed.xml" rel="self" type="application/rss+xml"/><item><title>Destination Rule</title><link>/v1.3/docs/reference/config/networking/v1alpha3/destination-rule/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/destination-rule/</guid><description>DestinationRule defines policies that apply to traffic intended for a service after routing has occurred. These rules specify configuration for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. For example, a simple load balancing policy for the ratings service would look as follows:
|
|
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: bookinfo-ratings spec: host: ratings.prod.svc.cluster.local trafficPolicy: loadBalancer: simple: LEAST_CONN Version specific policies can be specified by defining a named subset and overriding the settings specified at the service level.</description></item><item><title>Envoy Filter</title><link>/v1.3/docs/reference/config/networking/v1alpha3/envoy-filter/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/envoy-filter/</guid><description>EnvoyFilter provides a mechanism to customize the Envoy configuration generated by Istio Pilot. Use EnvoyFilter to modify values for certain fields, add specific filters, or even add entirely new listeners, clusters, etc. This feature must be used with care, as incorrect configurations could potentially destabilize the entire mesh. Unlike other Istio networking objects, EnvoyFilters are additively applied. Any number of EnvoyFilters can exist for a given workload in a specific namespace.</description></item><item><title>Gateway</title><link>/v1.3/docs/reference/config/networking/v1alpha3/gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/gateway/</guid><description>Gateway describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections. The specification describes a set of ports that should be exposed, the type of protocol to use, SNI configuration for the load balancer, etc.
|
|
For example, the following Gateway configuration sets up a proxy to act as a load balancer exposing port 80 and 9080 (http), 443 (https), 9443(https) and port 2379 (TCP) for ingress.</description></item><item><title>Service Entry</title><link>/v1.3/docs/reference/config/networking/v1alpha3/service-entry/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/service-entry/</guid><description>ServiceEntry enables adding additional entries into Istio&rsquo;s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services. A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform&rsquo;s service registry (e.g., a set of VMs talking to services in Kubernetes).</description></item><item><title>Sidecar</title><link>/v1.3/docs/reference/config/networking/v1alpha3/sidecar/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/sidecar/</guid><description>Sidecar describes the configuration of the sidecar proxy that mediates inbound and outbound communication to the workload instance it is attached to. By default, Istio will program all sidecar proxies in the mesh with the necessary configuration required to reach every workload instance in the mesh, as well as accept traffic on all the ports associated with the workload. The Sidecar resource provides a way to fine tune the set of ports, protocols that the proxy will accept when forwarding traffic to and from the workload.</description></item><item><title>Virtual Service</title><link>/v1.3/docs/reference/config/networking/v1alpha3/virtual-service/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/networking/v1alpha3/virtual-service/</guid><description>Configuration affecting traffic routing. Here are a few terms useful to define in the context of traffic routing.
|
|
Service a unit of application behavior bound to a unique name in a service registry. Services consist of multiple network endpoints implemented by workload instances running on pods, containers, VMs etc.
|
|
Service versions (a.k.a. subsets) - In a continuous deployment scenario, for a given service, there can be distinct subsets of instances running different variants of the application binary.</description></item></channel></rss> |