istio
/
api
mirror of https://github.com/istio/api.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Generate separate HTML page per proto under networking (#811) 

* Generate separate pages for each networking proto

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>

* update

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>

* tweaks

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>

* Fix interdoc references

* separate doc and go gen

* change dash to underscore

* fix

* more fixes

* makefile fix

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>

* remove bad target

* Revert "change dash to underscore"

This reverts commit 7fbced66f6.

* final update

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
This commit is contained in:
Shriram Rajagopalan 2019-02-22 16:18:23 -05:00 committed by GitHub
parent 2f783dea2d
commit 5f14eaddcf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
21 changed files with 4838 additions and 5394 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Makefile
View File

@ -70,6 +70,7 @@ gogoslick_plugin := $(gogoslick_plugin_prefix)$(gogo_mapping):$(out_path)
########################
protoc_gen_docs_plugin := --docs_out=warnings=true,mode=html_fragment_with_front_matter:$(repo_dir)/
protoc_gen_docs_plugin_for_networking := --docs_out=warnings=true,per_file=true,mode=html_fragment_with_front_matter:$(repo_dir)/
#####################
# Generation Rules
@ -239,14 +240,14 @@ routing_v1alpha3_path := networking/v1alpha3
routing_v1alpha3_protos := $(shell find networking/v1alpha3 -type f -name '*.proto' | sort)
routing_v1alpha3_pb_gos := $(routing_v1alpha3_protos:.proto=.pb.go)
routing_v1alpha3_pb_pythons := $(routing_v1alpha3_protos:.proto=_pb2.py)
routing_v1alpha3_pb_doc := $(routing_v1alpha3_path)/istio.routing.v1alpha3.pb.html
routing_v1alpha3_pb_docs := $(routing_v1alpha3_protos:.proto=.pb.html)
generate-routing-go: $(routing_v1alpha3_pb_gos) $(routing_v1alpha3_pb_doc)
generate-routing-go: $(routing_v1alpha3_pb_gos) $(routing_v1alpha3_pb_docs)
$(routing_v1alpha3_pb_gos) $(routing_v1alpha3_pb_doc): $(routing_v1alpha3_protos)
$(routing_v1alpha3_pb_gos) $(routing_v1alpha3_pb_docs): $(routing_v1alpha3_protos)
## Generate networking/v1alpha3/*.pb.go
@$(docker_lock) status
@$(docker_gen) $(gogofast_plugin) $(protoc_gen_docs_plugin)$(routing_v1alpha3_path) $^
@$(docker_gen) $(gogofast_plugin) $(protoc_gen_docs_plugin_for_networking)$(routing_v1alpha3_path) $^
generate-routing-python: $(routing_v1alpha3_pb_pythons)
@ -257,7 +258,7 @@ $(routing_v1alpha3_pb_pythons): $(routing_v1alpha3_protos)
clean-routing:
rm -f $(routing_v1alpha3_pb_gos)
rm -f $(routing_v1alpha3_pb_doc)
rm -f $(routing_v1alpha3_pb_docs)
#####################
# rbac/...

4
mesh/v1alpha1/istio.mesh.v1alpha1.pb.html generated
View File

@ -75,7 +75,7 @@ Use fs:/// to specify a file-based backend with absolute path to the directory.<
</tr>
<tr id="ConfigSource-tls_settings">
<td><code>tlsSettings</code></td>
<td><code><a href="https://istio.io/docs/reference/config/istio.networking.v1alpha3.html#TLSSettings">istio.networking.v1alpha3.TLSSettings</a></code></td>
<td><code><a href="https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service.html#TLSSettings">istio.networking.v1alpha3.TLSSettings</a></code></td>
<td>
<p>Use the tls<em>settings to specify the tls mode to use. If the MCP server
uses Istio MTLS and shares the root CA with Pilot, specify the TLS
@ -348,7 +348,7 @@ other services.</p>
</tr>
<tr id="MeshConfig-tcp_keepalive">
<td><code>tcpKeepalive</code></td>
<td><code><a href="https://istio.io/docs/reference/config/istio.networking.v1alpha3.html#ConnectionPoolSettings-TCPSettings-TcpKeepalive">istio.networking.v1alpha3.ConnectionPoolSettings.TCPSettings.TcpKeepalive</a></code></td>
<td><code><a href="https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service.html#ConnectionPoolSettings-TCPSettings-TcpKeepalive">istio.networking.v1alpha3.ConnectionPoolSettings.TCPSettings.TcpKeepalive</a></code></td>
<td>
<p>If set then set SO_KEEPALIVE on the socket to enable TCP Keepalives.</p>

145
networking/v1alpha3/destination_rule.pb.go generated
View File

@ -4,6 +4,77 @@
/*
Package v1alpha3 is a generated protocol buffer package.
`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:
```yaml
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. The
following rule uses a round robin load balancing policy for all traffic
going to a subset named testversion that is composed of endpoints (e.g.,
pods) with labels (version:v3).
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
subsets:
- name: testversion
labels:
version: v3
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
```
**Note:** Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.
Traffic policies can be customized to specific ports as well. The
following rule uses the least connection load balancing policy for all
traffic to port 80, while uses a round robin load balancing setting for
traffic to the port 9080.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings-port
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy: # Apply to all ports
portLevelSettings:
- port:
number: 80
loadBalancer:
simple: LEAST_CONN
- port:
number: 9080
loadBalancer:
simple: ROUND_ROBIN
```
It is generated from these files:
networking/v1alpha3/destination_rule.proto
networking/v1alpha3/envoy_filter.proto
@ -156,81 +227,11 @@ func (TLSSettings_TLSmode) EnumDescriptor() ([]byte, []int) {
return fileDescriptorDestinationRule, []int{6, 0}
}
// `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:
//
// ```yaml
// 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. The
// following rule uses a round robin load balancing policy for all traffic
// going to a subset named testversion that is composed of endpoints (e.g.,
// pods) with labels (version:v3).
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: DestinationRule
// metadata:
// name: bookinfo-ratings
// spec:
// host: ratings.prod.svc.cluster.local
// trafficPolicy:
// loadBalancer:
// simple: LEAST_CONN
// subsets:
// - name: testversion
// labels:
// version: v3
// trafficPolicy:
// loadBalancer:
// simple: ROUND_ROBIN
// ```
//
// **Note:** Policies specified for subsets will not take effect until
// a route rule explicitly sends traffic to this subset.
//
// Traffic policies can be customized to specific ports as well. The
// following rule uses the least connection load balancing policy for all
// traffic to port 80, while uses a round robin load balancing setting for
// traffic to the port 9080.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: DestinationRule
// metadata:
// name: bookinfo-ratings-port
// spec:
// host: ratings.prod.svc.cluster.local
// trafficPolicy: # Apply to all ports
// portLevelSettings:
// - port:
// number: 80
// loadBalancer:
// simple: LEAST_CONN
// - port:
// number: 9080
// loadBalancer:
// simple: ROUND_ROBIN
// ```
type DestinationRule struct {
// REQUIRED. The name of a service from the service registry. Service
// names are looked up from the platform's service registry (e.g.,
// Kubernetes services, Consul services, etc.) and from the hosts
// declared by [ServiceEntries](#ServiceEntry). Rules defined for
// declared by [ServiceEntries](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry). Rules defined for
// services that do not exist in the service registry will be ignored.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"
@ -412,7 +413,7 @@ func (m *TrafficPolicy_PortTrafficPolicy) GetTls() *TLSSettings {
// A subset of endpoints of a service. Subsets can be used for scenarios
// like A/B testing, or routing to a specific version of a service. Refer
// to [VirtualService](#VirtualService) documentation for examples of using
// to [VirtualService](/docs/reference/config/networking/v1alpha3/virtual-service/#VirtualService) documentation for examples of using
// subsets in these scenarios. In addition, traffic policies defined at the
// service-level can be overridden at a subset-level. The following rule
// uses a round robin load balancing policy for all traffic going to a

1021
networking/v1alpha3/destination_rule.pb.html generated Normal file
View File

File diff suppressed because it is too large Load Diff

14
networking/v1alpha3/destination_rule.proto
View File

@ -17,9 +17,9 @@ import "google/protobuf/duration.proto";
import "networking/v1alpha3/virtual_service.proto";
import "gogoproto/gogo.proto";
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
// $title: Destination Rule
// $description: Configuration affecting load balancing, outlier detection, etc.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule.html
// `DestinationRule` defines policies that apply to traffic intended for a
// service after routing has occurred. These rules specify configuration
@ -91,11 +91,15 @@ option go_package = "istio.io/api/networking/v1alpha3";
// loadBalancer:
// simple: ROUND_ROBIN
// ```
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message DestinationRule {
// REQUIRED. The name of a service from the service registry. Service
// names are looked up from the platform's service registry (e.g.,
// Kubernetes services, Consul services, etc.) and from the hosts
// declared by [ServiceEntries](#ServiceEntry). Rules defined for
// declared by [ServiceEntries](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry). Rules defined for
// services that do not exist in the service registry will be ignored.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"
@ -173,7 +177,7 @@ message TrafficPolicy {
// A subset of endpoints of a service. Subsets can be used for scenarios
// like A/B testing, or routing to a specific version of a service. Refer
// to [VirtualService](#VirtualService) documentation for examples of using
// to [VirtualService](/docs/reference/config/networking/v1alpha3/virtual-service/#VirtualService) documentation for examples of using
// subsets in these scenarios. In addition, traffic policies defined at the
// service-level can be overridden at a subset-level. The following rule
// uses a round robin load balancing policy for all traffic going to a

37
networking/v1alpha3/envoy_filter.pb.go generated
View File

@ -140,43 +140,6 @@ func (EnvoyFilter_Filter_FilterType) EnumDescriptor() ([]byte, []int) {
return fileDescriptorEnvoyFilter, []int{0, 3, 0}
}
// `EnvoyFilter` describes Envoy proxy-specific filters that can be used to
// customize the Envoy proxy configuration generated by Istio networking
// subsystem (Pilot). This feature must be used with care, as incorrect
// configurations could potentially destabilize the entire mesh.
//
// NOTE 1: Since this is break glass configuration, there will not be any
// backward compatibility across different Istio releases. In other words,
// this configuration is subject to change based on internal implementation
// of Istio networking subsystem.
//
// NOTE 2: When multiple EnvoyFilters are bound to the same workload, all filter
// configurations will be processed sequentially in order of creation time.
// The behavior is undefined if multiple EnvoyFilter configurations conflict
// with each other.
//
// The following example for Kubernetes enables Envoy's Lua filter for all
// inbound calls arriving at service port 8080 of the reviews service pod with
// labels "app: reviews".
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: EnvoyFilter
// metadata:
// name: reviews-lua
// spec:
// workloadLabels:
// app: reviews
// filters:
// - listenerMatch:
// portNumber: 8080
// listenerType: SIDECAR_INBOUND #will match with the inbound listener for reviews:8080
// filterName: envoy.lua
// filterType: HTTP
// filterConfig:
// inlineCode: |
// ... lua code ...
// ```
type EnvoyFilter struct {
// One or more labels that indicate a specific set of pods/VMs whose
// proxies should be configured to use these additional filters. The

400
networking/v1alpha3/envoy_filter.pb.html generated Normal file
View File

@ -0,0 +1,400 @@
---
title: Envoy Filter
description: Configuration affecting insertion of custom envoy filters.
location: https://istio.io/docs/reference/config/networking/v1alpha3/envoy-filter.html
layout: protoc-gen-docs
generator: protoc-gen-docs
number_of_entries: 8
---
<p><code>EnvoyFilter</code> describes Envoy proxy-specific filters that can be used to
customize the Envoy proxy configuration generated by Istio networking
subsystem (Pilot). This feature must be used with care, as incorrect
configurations could potentially destabilize the entire mesh.</p>
<p>NOTE 1: Since this is break glass configuration, there will not be any
backward compatibility across different Istio releases. In other words,
this configuration is subject to change based on internal implementation
of Istio networking subsystem.</p>
<p>NOTE 2: When multiple EnvoyFilters are bound to the same workload, all filter
configurations will be processed sequentially in order of creation time.
The behavior is undefined if multiple EnvoyFilter configurations conflict
with each other.</p>
<p>The following example for Kubernetes enables Envoy&rsquo;s Lua filter for all
inbound calls arriving at service port 8080 of the reviews service pod with
labels &ldquo;app: reviews&rdquo;.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: reviews-lua
spec:
workloadLabels:
app: reviews
filters:
- listenerMatch:
portNumber: 8080
listenerType: SIDECAR_INBOUND # will match with the inbound listener for reviews:8080
filterName: envoy.lua
filterType: HTTP
filterConfig:
inlineCode: |
... lua code ...
</code></pre>
<h2 id="EnvoyFilter">EnvoyFilter</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-workload_labels">
<td><code>workloadLabels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>One or more labels that indicate a specific set of pods/VMs whose
proxies should be configured to use these additional filters. The
scope of label search is platform dependent. On Kubernetes, for
example, the scope includes pods running in all reachable
namespaces. Omitting the selector applies the filter to all proxies in
the mesh.
NOTE: There can be only one EnvoyFilter bound to a specific workload.
The behavior is undefined if multiple EnvoyFilter configurations are
specified for the same workload.</p>
</td>
</tr>
<tr id="EnvoyFilter-filters">
<td><code>filters</code></td>
<td><code><a href="#EnvoyFilter-Filter">EnvoyFilter.Filter[]</a></code></td>
<td>
<p>REQUIRED: Envoy network filters/http filters to be added to matching
listeners. When adding network filters to http connections, care
should be taken to ensure that the filter is added before
envoy.http<em>connection</em>manager.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-Filter">EnvoyFilter.Filter</h2>
<section>
<p>Envoy filters to be added to a network or http filter chain.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-Filter-listener_match">
<td><code>listenerMatch</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch">EnvoyFilter.ListenerMatch</a></code></td>
<td>
<p>Filter will be added to the listener only if the match conditions are true.
If not specified, the filters will be applied to all listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-insert_position">
<td><code>insertPosition</code></td>
<td><code><a href="#EnvoyFilter-InsertPosition">EnvoyFilter.InsertPosition</a></code></td>
<td>
<p>Insert position in the filter chain. Defaults to FIRST</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_type">
<td><code>filterType</code></td>
<td><code><a href="#EnvoyFilter-Filter-FilterType">EnvoyFilter.Filter.FilterType</a></code></td>
<td>
<p>REQUIRED: The type of filter to instantiate.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_name">
<td><code>filterName</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: The name of the filter to instantiate. The name must match a supported
filter <em>compiled into</em> Envoy.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_config">
<td><code>filterConfig</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#struct">google.protobuf.Struct</a></code></td>
<td>
<p>REQUIRED: Filter specific configuration which depends on the filter being
instantiated.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-Filter-FilterType">EnvoyFilter.Filter.FilterType</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-Filter-FilterType-INVALID">
<td><code>INVALID</code></td>
<td>
<p>placeholder</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-FilterType-HTTP">
<td><code>HTTP</code></td>
<td>
<p>Http filter</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-FilterType-NETWORK">
<td><code>NETWORK</code></td>
<td>
<p>Network filter</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-InsertPosition">EnvoyFilter.InsertPosition</h2>
<section>
<p>Indicates the relative index in the filter chain where the filter should be inserted.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-InsertPosition-index">
<td><code>index</code></td>
<td><code><a href="#EnvoyFilter-InsertPosition-Index">EnvoyFilter.InsertPosition.Index</a></code></td>
<td>
<p>Position of this filter in the filter chain.</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-relative_to">
<td><code>relativeTo</code></td>
<td><code>string</code></td>
<td>
<p>If BEFORE or AFTER position is specified, specify the name of the
filter relative to which this filter should be inserted.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-InsertPosition-Index">EnvoyFilter.InsertPosition.Index</h2>
<section>
<p>Index/position in the filter chain.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-InsertPosition-Index-FIRST">
<td><code>FIRST</code></td>
<td>
<p>Insert first</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-LAST">
<td><code>LAST</code></td>
<td>
<p>Insert last</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-BEFORE">
<td><code>BEFORE</code></td>
<td>
<p>Insert before the named filter.</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-AFTER">
<td><code>AFTER</code></td>
<td>
<p>Insert after the named filter.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch">EnvoyFilter.ListenerMatch</h2>
<section>
<p>Select a listener to add the filter to based on the match conditions.
All conditions specified in the ListenerMatch must be met for the filter
to be applied to a listener.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-port_number">
<td><code>portNumber</code></td>
<td><code>uint32</code></td>
<td>
<p>The service port/gateway port to which traffic is being
sent/received. If not specified, matches all listeners. Even though
inbound listeners are generated for the instance/pod ports, only
service ports should be used to match listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-port_name_prefix">
<td><code>portNamePrefix</code></td>
<td><code>string</code></td>
<td>
<p>Instead of using specific port numbers, a set of ports matching a
given port name prefix can be selected. E.g., &ldquo;mongo&rdquo; selects ports
named mongo-port, mongo, mongoDB, MONGO, etc. Matching is case
insensitive.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-listener_type">
<td><code>listenerType</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch-ListenerType">EnvoyFilter.ListenerMatch.ListenerType</a></code></td>
<td>
<p>Inbound vs outbound sidecar listener or gateway listener. If not specified,
matches all listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-listener_protocol">
<td><code>listenerProtocol</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch-ListenerProtocol">EnvoyFilter.ListenerMatch.ListenerProtocol</a></code></td>
<td>
<p>Selects a class of listeners for the same protocol. If not
specified, applies to listeners on all protocols. Use the protocol
selection to select all HTTP listeners (includes HTTP2/gRPC/HTTPS
where Envoy terminates TLS) or all TCP listeners (includes HTTPS
passthrough using SNI).</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-address">
<td><code>address</code></td>
<td><code>string[]</code></td>
<td>
<p>One or more IP addresses to which the listener is bound. If
specified, should match at least one address in the list.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch-ListenerProtocol">EnvoyFilter.ListenerMatch.ListenerProtocol</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-ALL">
<td><code>ALL</code></td>
<td>
<p>All protocols</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-HTTP">
<td><code>HTTP</code></td>
<td>
<p>HTTP or HTTPS (with termination) / HTTP2/gRPC</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-TCP">
<td><code>TCP</code></td>
<td>
<p>Any non-HTTP listener</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch-ListenerType">EnvoyFilter.ListenerMatch.ListenerType</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-ANY">
<td><code>ANY</code></td>
<td>
<p>All listeners</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-SIDECAR_INBOUND">
<td><code>SIDECAR_INBOUND</code></td>
<td>
<p>Inbound listener in sidecar</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-SIDECAR_OUTBOUND">
<td><code>SIDECAR_OUTBOUND</code></td>
<td>
<p>Outbound listener in sidecar</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-GATEWAY">
<td><code>GATEWAY</code></td>
<td>
<p>Gateway listener</p>
</td>
</tr>
</tbody>
</table>
</section>

12
networking/v1alpha3/envoy_filter.proto
View File

@ -16,9 +16,9 @@ syntax = "proto3";
import "google/protobuf/struct.proto";
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
// $title: Envoy Filter
// $description: Configuration affecting insertion of custom envoy filters.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/envoy-filter.html
// `EnvoyFilter` describes Envoy proxy-specific filters that can be used to
// customize the Envoy proxy configuration generated by Istio networking
@ -50,13 +50,17 @@ option go_package = "istio.io/api/networking/v1alpha3";
// filters:
// - listenerMatch:
// portNumber: 8080
// listenerType: SIDECAR_INBOUND #will match with the inbound listener for reviews:8080
// listenerType: SIDECAR_INBOUND # will match with the inbound listener for reviews:8080
// filterName: envoy.lua
// filterType: HTTP
// filterConfig:
// inlineCode: |
// ... lua code ...
// ```
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message EnvoyFilter {
// One or more labels that indicate a specific set of pods/VMs whose
// proxies should be configured to use these additional filters. The

135
networking/v1alpha3/gateway.pb.go generated
View File

@ -98,141 +98,6 @@ func (Server_TLSOptions_TLSProtocol) EnumDescriptor() ([]byte, []int) {
return fileDescriptorGateway, []int{1, 0, 1}
}
// `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), and
// port 2379 (TCP) for ingress. The gateway will be applied to the proxy
// running on a pod with labels `app: my-gateway-controller`. While Istio
// will configure the proxy to listen on these ports, it is the
// responsibility of the user to ensure that external traffic to these
// ports are allowed into the mesh.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Gateway
// metadata:
// name: my-gateway
// namespace: some-config-namespace
// spec:
// selector:
// app: my-gateway-controller
// servers:
// - port:
// number: 80
// name: http
// protocol: HTTP
// hosts:
// - uk.bookinfo.com
// - eu.bookinfo.com
// tls:
// httpsRedirect: true # sends 301 redirect for http requests
// - port:
// number: 443
// name: https
// protocol: HTTPS
// hosts:
// - uk.bookinfo.com
// - eu.bookinfo.com
// tls:
// mode: SIMPLE #enables HTTPS on this port
// serverCertificate: /etc/certs/servercert.pem
// privateKey: /etc/certs/privatekey.pem
// - port:
// number: 9080
// name: http-wildcard
// protocol: HTTP
// hosts:
// - "*"
// - port:
// number: 2379 # to expose internal service via external port 2379
// name: mongo
// protocol: MONGO
// hosts:
// - "*"
// ```
// The Gateway specification above describes the L4-L6 properties of a load
// balancer. A `VirtualService` can then be bound to a gateway to control
// the forwarding of traffic arriving at a particular host or gateway port.
//
// For example, the following VirtualService splits traffic for
// "https://uk.bookinfo.com/reviews", "https://eu.bookinfo.com/reviews",
// "http://uk.bookinfo.com:9080/reviews",
// "http://eu.bookinfo.com:9080/reviews" into two versions (prod and qa) of
// an internal reviews service on port 9080. In addition, requests
// containing the cookie "user: dev-123" will be sent to special port 7777
// in the qa version. The same rule is also applicable inside the mesh for
// requests to the "reviews.prod.svc.cluster.local" service. This rule is
// applicable across ports 443, 9080. Note that "http://uk.bookinfo.com"
// gets redirected to "https://uk.bookinfo.com" (i.e. 80 redirects to 443).
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: VirtualService
// metadata:
// name: bookinfo-rule
// namespace: bookinfo-namespace
// spec:
// hosts:
// - reviews.prod.svc.cluster.local
// - uk.bookinfo.com
// - eu.bookinfo.com
// gateways:
// - some-config-namespace/my-gateway
// - mesh # applies to all the sidecars in the mesh
// http:
// - match:
// - headers:
// cookie:
// user: dev-123
// route:
// - destination:
// port:
// number: 7777
// host: reviews.qa.svc.cluster.local
// - match:
// uri:
// prefix: /reviews/
// route:
// - destination:
// port:
// number: 9080 # can be omitted if its the only port for reviews
// host: reviews.prod.svc.cluster.local
// weight: 80
// - destination:
// host: reviews.qa.svc.cluster.local
// weight: 20
// ```
//
// The following VirtualService forwards traffic arriving at (external)
// port 27017 to internal Mongo server on port 5555. This rule is not
// applicable internally in the mesh as the gateway list omits the
// reserved name `mesh`.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: VirtualService
// metadata:
// name: bookinfo-Mongo
// namespace: bookinfo-namespace
// spec:
// hosts:
// - mongosvr.prod.svc.cluster.local #name of internal Mongo service
// gateways:
// - some-config-namespace/my-gateway # can omit the namespace if gateway is in same
// namespace as virtual service.
// tcp:
// - match:
// - port: 27017
// route:
// - destination:
// host: mongo.prod.svc.cluster.local
// port:
// number: 5555
// ```
type Gateway struct {
// REQUIRED: A list of server specifications.
Servers []*Server `protobuf:"bytes,1,rep,name=servers" json:"servers,omitempty"`

563
networking/v1alpha3/gateway.pb.html generated Normal file
View File

@ -0,0 +1,563 @@
---
title: Gateway
description: Configuration affecting edge load balancer.
location: https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html
layout: protoc-gen-docs
generator: protoc-gen-docs
number_of_entries: 6
---
<p><code>Gateway</code> 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.</p>
<p>For example, the following Gateway configuration sets up a proxy to act
as a load balancer exposing port 80 and 9080 (http), 443 (https), and
port 2379 (TCP) for ingress. The gateway will be applied to the proxy
running on a pod with labels <code>app: my-gateway-controller</code>. While Istio
will configure the proxy to listen on these ports, it is the
responsibility of the user to ensure that external traffic to these
ports are allowed into the mesh.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
namespace: some-config-namespace
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
httpsRedirect: true # sends 301 redirect for http requests
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
mode: SIMPLE # enables HTTPS on this port
serverCertificate: /etc/certs/servercert.pem
privateKey: /etc/certs/privatekey.pem
- port:
number: 9080
name: http-wildcard
protocol: HTTP
hosts:
- &quot;*&quot;
- port:
number: 2379 # to expose internal service via external port 2379
name: mongo
protocol: MONGO
hosts:
- &quot;*&quot;
</code></pre>
<p>The Gateway specification above describes the L4-L6 properties of a load
balancer. A <code>VirtualService</code> can then be bound to a gateway to control
the forwarding of traffic arriving at a particular host or gateway port.</p>
<p>For example, the following VirtualService splits traffic for
&ldquo;https://uk.bookinfo.com/reviews&rdquo;, &ldquo;https://eu.bookinfo.com/reviews&rdquo;,
&ldquo;http://uk.bookinfo.com:9080/reviews&rdquo;,
&ldquo;http://eu.bookinfo.com:9080/reviews&rdquo; into two versions (prod and qa) of
an internal reviews service on port 9080. In addition, requests
containing the cookie &ldquo;user: dev-123&rdquo; will be sent to special port 7777
in the qa version. The same rule is also applicable inside the mesh for
requests to the &ldquo;reviews.prod.svc.cluster.local&rdquo; service. This rule is
applicable across ports 443, 9080. Note that &ldquo;http://uk.bookinfo.com&rdquo;
gets redirected to &ldquo;https://uk.bookinfo.com&rdquo; (i.e. 80 redirects to 443).</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-rule
namespace: bookinfo-namespace
spec:
hosts:
- reviews.prod.svc.cluster.local
- uk.bookinfo.com
- eu.bookinfo.com
gateways:
- some-config-namespace/my-gateway
- mesh # applies to all the sidecars in the mesh
http:
- match:
- headers:
cookie:
user: dev-123
route:
- destination:
port:
number: 7777
host: reviews.qa.svc.cluster.local
- match:
uri:
prefix: /reviews/
route:
- destination:
port:
number: 9080 # can be omitted if its the only port for reviews
host: reviews.prod.svc.cluster.local
weight: 80
- destination:
host: reviews.qa.svc.cluster.local
weight: 20
</code></pre>
<p>The following VirtualService forwards traffic arriving at (external)
port 27017 to internal Mongo server on port 5555. This rule is not
applicable internally in the mesh as the gateway list omits the
reserved name <code>mesh</code>.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-Mongo
namespace: bookinfo-namespace
spec:
hosts:
- mongosvr.prod.svc.cluster.local # name of internal Mongo service
gateways:
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same
namespace as virtual service.
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.prod.svc.cluster.local
port:
number: 5555
</code></pre>
<h2 id="Gateway">Gateway</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Gateway-servers">
<td><code>servers</code></td>
<td><code><a href="#Server">Server[]</a></code></td>
<td>
<p>REQUIRED: A list of server specifications.</p>
</td>
</tr>
<tr id="Gateway-selector">
<td><code>selector</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>REQUIRED: One or more labels that indicate a specific set of pods/VMs
on which this gateway configuration should be applied. The scope of
label search is restricted to the configuration namespace in which the
the resource is present. In other words, the Gateway resource must
reside in the same namespace as the gateway workload.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Port">Port</h2>
<section>
<p>Port describes the properties of a specific port of a service.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Port-number">
<td><code>number</code></td>
<td><code>uint32</code></td>
<td>
<p>REQUIRED: A valid non-negative integer port number.</p>
</td>
</tr>
<tr id="Port-protocol">
<td><code>protocol</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: The protocol exposed on the port.
MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TLS.
TLS implies the connection will be routed based on the SNI header to
the destination without terminating the TLS connection.</p>
</td>
</tr>
<tr id="Port-name">
<td><code>name</code></td>
<td><code>string</code></td>
<td>
<p>Label assigned to the port.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server">Server</h2>
<section>
<p><code>Server</code> describes the properties of the proxy on a given load balancer
port. For example,</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-ingress
spec:
selector:
app: my-ingress-gateway
servers:
- port:
number: 80
name: http2
protocol: HTTP2
hosts:
- &quot;*&quot;
</code></pre>
<p>Another example</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-tcp-ingress
spec:
selector:
app: my-tcp-ingress-gateway
servers:
- port:
number: 27018
name: mongo
protocol: MONGO
hosts:
- &quot;*&quot;
</code></pre>
<p>The following is an example of TLS configuration for port 443</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-tls-ingress
spec:
selector:
app: my-tls-ingress-gateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- &quot;*&quot;
tls:
mode: SIMPLE
serverCertificate: /etc/certs/server.pem
privateKey: /etc/certs/privatekey.pem
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-port">
<td><code>port</code></td>
<td><code><a href="#Port">Port</a></code></td>
<td>
<p>REQUIRED: The Port on which the proxy should listen for incoming
connections. If using unix domain socket, use 0 as the port number,
with a valid protocol and port name, along with the bind parameter.</p>
</td>
</tr>
<tr id="Server-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. A list of hosts exposed by this gateway. At least one
host is required. While typically applicable to
HTTP services, it can also be used for TCP services using TLS with
SNI. May contain a wildcard prefix for the bottom-level component of
a domain name. For example <code>*.foo.com</code> matches <code>bar.foo.com</code>
and <code>*.com</code> matches <code>bar.foo.com</code>, <code>example.com</code>, and so on.</p>
<p><strong>Note</strong>: A <code>VirtualService</code> that is bound to a gateway must have one
or more hosts that match the hosts specified in a server. The match
could be an exact match or a suffix match with the server&rsquo;s hosts. For
example, if the server&rsquo;s hosts specifies &ldquo;*.example.com&rdquo;,
VirtualServices with hosts dev.example.com, prod.example.com will
match. However, VirtualServices with hosts example.com or
newexample.com will not match.</p>
</td>
</tr>
<tr id="Server-tls">
<td><code>tls</code></td>
<td><code><a href="#Server-TLSOptions">Server.TLSOptions</a></code></td>
<td>
<p>Set of TLS related options that govern the server&rsquo;s behavior. Use
these options to control if all http requests should be redirected to
https, and the TLS modes to use.</p>
</td>
</tr>
<tr id="Server-default_endpoint">
<td><code>defaultEndpoint</code></td>
<td><code>string</code></td>
<td>
<p>The loopback IP endpoint or unix domain socket to which traffic should
be forwarded to by default. Format should be 127.0.0.1:PORT or
unix:///path/to/socket or unix://@foobar (Linux abstract namespace).</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions">Server.TLSOptions</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-https_redirect">
<td><code>httpsRedirect</code></td>
<td><code>bool</code></td>
<td>
<p>If set to true, the load balancer will send a 301 redirect for all
http connections, asking the clients to use HTTPS.</p>
</td>
</tr>
<tr id="Server-TLSOptions-mode">
<td><code>mode</code></td>
<td><code><a href="#Server-TLSOptions-TLSmode">Server.TLSOptions.TLSmode</a></code></td>
<td>
<p>Optional: Indicates whether connections to this port should be
secured using TLS. The value of this field determines how TLS is
enforced.</p>
</td>
</tr>
<tr id="Server-TLSOptions-server_certificate">
<td><code>serverCertificate</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>SIMPLE</code> or <code>MUTUAL</code>. The path to the file
holding the server-side TLS certificate to use.</p>
</td>
</tr>
<tr id="Server-TLSOptions-private_key">
<td><code>privateKey</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>SIMPLE</code> or <code>MUTUAL</code>. The path to the file
holding the server&rsquo;s private key.</p>
</td>
</tr>
<tr id="Server-TLSOptions-ca_certificates">
<td><code>caCertificates</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>MUTUAL</code>. The path to a file containing
certificate authority certificates to use in verifying a presented
client side certificate.</p>
</td>
</tr>
<tr id="Server-TLSOptions-credential_name">
<td><code>credentialName</code></td>
<td><code>string</code></td>
<td>
<p>The credentialName stands for a unique identifier that can be used
to identify the serverCertificate and the privateKey. The credentialName
appended with suffix &ldquo;-cacert&rdquo; is used to identify the CaCertificates
associated with this server. Gateway workloads capable of fetching
credentials from a remote credential store will be configured to retrieve
the serverCertificate and the privateKey using credentialName, instead of
using the file system paths specified above. If using mutual TLS,
gateway workloads will retrieve the CaCertificates using
credentialName-cacert. The semantics of the name are platform dependent.
In Kubernetes, the default Istio supplied credential server expects the
credentialName to match the name of the Kubernetes secret that holds the
server certificate, the private key, and the CA certificate
(if using mutual TLS).</p>
</td>
</tr>
<tr id="Server-TLSOptions-subject_alt_names">
<td><code>subjectAltNames</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of alternate names to verify the subject identity in the
certificate presented by the client.</p>
</td>
</tr>
<tr id="Server-TLSOptions-min_protocol_version">
<td><code>minProtocolVersion</code></td>
<td><code><a href="#Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</a></code></td>
<td>
<p>Optional: Minimum TLS protocol version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-max_protocol_version">
<td><code>maxProtocolVersion</code></td>
<td><code><a href="#Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</a></code></td>
<td>
<p>Optional: Maximum TLS protocol version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-cipher_suites">
<td><code>cipherSuites</code></td>
<td><code>string[]</code></td>
<td>
<p>Optional: If specified, only support the specified cipher list.
Otherwise default to the default cipher list supported by Envoy.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</h2>
<section>
<p>TLS protocol versions.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-TLSProtocol-TLS_AUTO">
<td><code>TLS_AUTO</code></td>
<td>
<p>Automatically choose the optimal TLS version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_0">
<td><code>TLSV1_0</code></td>
<td>
<p>TLS version 1.0</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_1">
<td><code>TLSV1_1</code></td>
<td>
<p>TLS version 1.1</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_2">
<td><code>TLSV1_2</code></td>
<td>
<p>TLS version 1.2</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_3">
<td><code>TLSV1_3</code></td>
<td>
<p>TLS version 1.3</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions-TLSmode">Server.TLSOptions.TLSmode</h2>
<section>
<p>TLS modes enforced by the proxy</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-TLSmode-PASSTHROUGH">
<td><code>PASSTHROUGH</code></td>
<td>
<p>The SNI string presented by the client will be used as the match
criterion in a VirtualService TLS route to determine the
destination service from the service registry.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSmode-SIMPLE">
<td><code>SIMPLE</code></td>
<td>
<p>Secure connections with standard TLS semantics.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSmode-MUTUAL">
<td><code>MUTUAL</code></td>
<td>
<p>Secure connections to the upstream using mutual TLS by presenting
client certificates for authentication.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSmode-AUTO_PASSTHROUGH">
<td><code>AUTO_PASSTHROUGH</code></td>
<td>
<p>Similar to the passthrough mode, except servers with this TLS mode
do not require an associated VirtualService to map from the SNI
value to service in the registry. The destination details such as
the service/subset/port are encoded in the SNI value. The proxy
will forward to the upstream (Envoy) cluster (a group of
endpoints) specified by the SNI value. This server is typically
used to provide connectivity between services in disparate L3
networks that otherwise do not have direct connectivity between
their respective endpoints. Use of this mode assumes that both the
source and the destination are using Istio mTLS to secure traffic.</p>
</td>
</tr>
</tbody>
</table>
</section>

14
networking/v1alpha3/gateway.proto
View File

@ -14,9 +14,9 @@
syntax = "proto3";
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
// $title: Gateway
// $description: Configuration affecting edge load balancer.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html
// `Gateway` describes a load balancer operating at the edge of the mesh
// receiving incoming or outgoing HTTP/TCP connections. The specification
@ -58,7 +58,7 @@ option go_package = "istio.io/api/networking/v1alpha3";
// - uk.bookinfo.com
// - eu.bookinfo.com
// tls:
// mode: SIMPLE #enables HTTPS on this port
// mode: SIMPLE # enables HTTPS on this port
// serverCertificate: /etc/certs/servercert.pem
// privateKey: /etc/certs/privatekey.pem
// - port:
@ -140,7 +140,7 @@ option go_package = "istio.io/api/networking/v1alpha3";
// namespace: bookinfo-namespace
// spec:
// hosts:
// - mongosvr.prod.svc.cluster.local #name of internal Mongo service
// - mongosvr.prod.svc.cluster.local # name of internal Mongo service
// gateways:
// - some-config-namespace/my-gateway # can omit the namespace if gateway is in same
// namespace as virtual service.
@ -153,6 +153,10 @@ option go_package = "istio.io/api/networking/v1alpha3";
// port:
// number: 5555
// ```
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message Gateway {
// REQUIRED: A list of server specifications.
repeated Server servers = 1;

4665
networking/v1alpha3/istio.networking.v1alpha3.pb.html generated
View File

File diff suppressed because it is too large Load Diff

308
networking/v1alpha3/service_entry.pb.go generated
View File

@ -99,312 +99,6 @@ func (ServiceEntry_Resolution) EnumDescriptor() ([]byte, []int) {
return fileDescriptorServiceEntry, []int{0, 1}
}
// `ServiceEntry` enables adding additional entries into Istio'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's
// service registry (e.g., a set of VMs talking to services in Kubernetes).
//
// The following configuration adds a set of MongoDB instances running on
// unmanaged VMs to Istio's registry, so that these services can be treated
// as any other service in the mesh. The associated DestinationRule is used
// to initiate mTLS connections to the database instances.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: external-svc-mongocluster
// spec:
// hosts:
// - mymongodb.somedomain # not used
// addresses:
// - 192.192.192.192/24 # VIPs
// ports:
// - number: 27018
// name: mongodb
// protocol: MONGO
// location: MESH_INTERNAL
// resolution: STATIC
// endpoints:
// - address: 2.2.2.2
// - address: 3.3.3.3
// ```
//
// and the associated DestinationRule
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: DestinationRule
// metadata:
// name: mtls-mongocluster
// spec:
// host: mymongodb.somedomain
// trafficPolicy:
// tls:
// mode: MUTUAL
// clientCertificate: /etc/certs/myclientcert.pem
// privateKey: /etc/certs/client_private_key.pem
// caCertificates: /etc/certs/rootcacerts.pem
// ```
//
// The following example uses a combination of service entry and TLS
// routing in virtual service to demonstrate the use of SNI routing to
// forward unterminated TLS traffic from the application to external
// services via the sidecar. The sidecar inspects the SNI value in the
// ClientHello message to route to the appropriate external service.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: external-svc-https
// spec:
// hosts:
// - api.dropboxapi.com
// - www.googleapis.com
// - api.facebook.com
// location: MESH_EXTERNAL
// ports:
// - number: 443
// name: https
// protocol: TLS
// resolution: DNS
// ```
//
// And the associated VirtualService to route based on the SNI value.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: VirtualService
// metadata:
// name: tls-routing
// spec:
// hosts:
// - api.dropboxapi.com
// - www.googleapis.com
// - api.facebook.com
// tls:
// - match:
// - port: 443
// sniHosts:
// - api.dropboxapi.com
// route:
// - destination:
// host: api.dropboxapi.com
// - match:
// - port: 443
// sniHosts:
// - www.googleapis.com
// route:
// - destination:
// host: www.googleapis.com
// - match:
// - port: 443
// sniHosts:
// - api.facebook.com
// route:
// - destination:
// host: api.facebook.com
//
// ```
//
// The following example demonstrates the use of a dedicated egress gateway
// through which all external service traffic is forwarded.
// The 'exportTo' field allows for control over the visibility of a service
// declaration to other namespaces in the mesh. By default a service is exported
// to all namespaces. The following example restricts the visibility to the
// current namespace, represented by ".", so that it cannot be used by other
// namespaces.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: external-svc-httpbin
// namespace : egress
// spec:
// hosts:
// - httpbin.com
// exportTo:
// - "."
// location: MESH_EXTERNAL
// ports:
// - number: 80
// name: http
// protocol: HTTP
// resolution: DNS
// ```
//
// Define a gateway to handle all egress traffic.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Gateway
// metadata:
// name: istio-egressgateway
// namespace: egress
// spec:
// selector:
// istio: egressgateway
// servers:
// - port:
// number: 80
// name: http
// protocol: HTTP
// hosts:
// - "*"
// ```
//
// And the associated VirtualService to route from the sidecar to the
// gateway service (istio-egressgateway.istio-system.svc.cluster.local), as
// well as route from the gateway to the external service. Note that the
// virtual service is exported to all namespaces enabling them to route traffic
// through the gateway to the external service. Forcing traffic to go through
// a managed middle proxy like this is a common practice.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: VirtualService
// metadata:
// name: gateway-routing
// namespace: egress
// spec:
// hosts:
// - httpbin.com
// exportTo:
// - *
// gateways:
// - mesh
// - istio-egressgateway
// http:
// - match:
// - port: 80
// gateways:
// - mesh
// route:
// - destination:
// host: istio-egressgateway.istio-system.svc.cluster.local
// - match:
// - port: 80
// gateway:
// - istio-egressgateway
// route:
// - destination:
// host: httpbin.com
// ```
//
// The following example demonstrates the use of wildcards in the hosts for
// external services. If the connection has to be routed to the IP address
// requested by the application (i.e. application resolves DNS and attempts
// to connect to a specific IP), the discovery mode must be set to `NONE`.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: external-svc-wildcard-example
// spec:
// hosts:
// - "*.bar.com"
// location: MESH_EXTERNAL
// ports:
// - number: 80
// name: http
// protocol: HTTP
// resolution: NONE
// ```
//
// The following example demonstrates a service that is available via a
// Unix Domain Socket on the host of the client. The resolution must be
// set to STATIC to use unix address endpoints.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: unix-domain-socket-example
// spec:
// hosts:
// - "example.unix.local"
// location: MESH_EXTERNAL
// ports:
// - number: 80
// name: http
// protocol: HTTP
// resolution: STATIC
// endpoints:
// - address: unix:///var/run/example/socket
// ```
//
// For HTTP-based services, it is possible to create a VirtualService
// backed by multiple DNS addressable endpoints. In such a scenario, the
// application can use the HTTP_PROXY environment variable to transparently
// reroute API calls for the VirtualService to a chosen backend. For
// example, the following configuration creates a non-existent external
// service called foo.bar.com backed by three domains: us.foo.bar.com:8080,
// uk.foo.bar.com:9080, and in.foo.bar.com:7080
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: external-svc-dns
// spec:
// hosts:
// - foo.bar.com
// location: MESH_EXTERNAL
// ports:
// - number: 80
// name: http
// protocol: HTTP
// resolution: DNS
// endpoints:
// - address: us.foo.bar.com
// ports:
// https: 8080
// - address: uk.foo.bar.com
// ports:
// https: 9080
// - address: in.foo.bar.com
// ports:
// https: 7080
// ```
//
// With `HTTP_PROXY=http://localhost/`, calls from the application to
// `http://foo.bar.com` will be load balanced across the three domains
// specified above. In other words, a call to `http://foo.bar.com/baz` would
// be translated to `http://uk.foo.bar.com/baz`.
//
// The following example illustrates the usage of a ServiceEntry
// containing a subject alternate name
// whose format conforms to the SPIFEE standard
// <https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md>:
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
// metadata:
// name: httpbin
// namespace : httpbin-ns
// spec:
// hosts:
// - httpbin.com
// location: MESH_INTERNAL
// ports:
// - number: 80
// name: http
// protocol: HTTP
// resolution: STATIC
// endpoints:
// - address: 2.2.2.2
// - address: 3.3.3.3
// subjectAltNames:
// - "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
// ```
//
type ServiceEntry struct {
// REQUIRED. The hosts associated with the ServiceEntry. Could be a DNS
// name with wildcard prefix (external services only). DNS names in hosts
@ -461,7 +155,7 @@ type ServiceEntry struct {
ExportTo []string `protobuf:"bytes,7,rep,name=export_to,json=exportTo" json:"export_to,omitempty"`
// The list of subject alternate names allowed for workloads that
// implement this service. This information is used to enforce
// secure-naming <https://istio.io/docs/concepts/security/#secure-naming>.
// [secure-naming](/docs/concepts/security/#secure-naming).
// If specified, the proxy will verify that the server
// certificate's subject alternate name matches one of the specified values.
SubjectAltNames []string `protobuf:"bytes,8,rep,name=subject_alt_names,json=subjectAltNames" json:"subject_alt_names,omitempty"`

612
networking/v1alpha3/service_entry.pb.html generated Normal file
View File

@ -0,0 +1,612 @@
---
title: Service Entry
description: Configuration affecting service registry.
location: https://istio.io/docs/reference/config/networking/v1alpha3/service-entry.html
layout: protoc-gen-docs
generator: protoc-gen-docs
number_of_entries: 4
---
<p><code>ServiceEntry</code> 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).</p>
<p>The following configuration adds a set of MongoDB instances running on
unmanaged VMs to Istio&rsquo;s registry, so that these services can be treated
as any other service in the mesh. The associated DestinationRule is used
to initiate mTLS connections to the database instances.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-mongocluster
spec:
hosts:
- mymongodb.somedomain # not used
addresses:
- 192.192.192.192/24 # VIPs
ports:
- number: 27018
name: mongodb
protocol: MONGO
location: MESH_INTERNAL
resolution: STATIC
endpoints:
- address: 2.2.2.2
- address: 3.3.3.3
</code></pre>
<p>and the associated DestinationRule</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mtls-mongocluster
spec:
host: mymongodb.somedomain
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/myclientcert.pem
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
</code></pre>
<p>The following example uses a combination of service entry and TLS
routing in virtual service to demonstrate the use of SNI routing to
forward unterminated TLS traffic from the application to external
services via the sidecar. The sidecar inspects the SNI value in the
ClientHello message to route to the appropriate external service.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-https
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: DNS
</code></pre>
<p>And the associated VirtualService to route based on the SNI value.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tls-routing
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
tls:
- match:
- port: 443
sniHosts:
- api.dropboxapi.com
route:
- destination:
host: api.dropboxapi.com
- match:
- port: 443
sniHosts:
- www.googleapis.com
route:
- destination:
host: www.googleapis.com
- match:
- port: 443
sniHosts:
- api.facebook.com
route:
- destination:
host: api.facebook.com
</code></pre>
<p>The following example demonstrates the use of a dedicated egress gateway
through which all external service traffic is forwarded.
The &lsquo;exportTo&rsquo; field allows for control over the visibility of a service
declaration to other namespaces in the mesh. By default a service is exported
to all namespaces. The following example restricts the visibility to the
current namespace, represented by &ldquo;.&rdquo;, so that it cannot be used by other
namespaces.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-httpbin
namespace : egress
spec:
hosts:
- httpbin.com
exportTo:
- &quot;.&quot;
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
</code></pre>
<p>Define a gateway to handle all egress traffic.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
namespace: egress
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- &quot;*&quot;
</code></pre>
<p>And the associated VirtualService to route from the sidecar to the
gateway service (istio-egressgateway.istio-system.svc.cluster.local), as
well as route from the gateway to the external service. Note that the
virtual service is exported to all namespaces enabling them to route traffic
through the gateway to the external service. Forcing traffic to go through
a managed middle proxy like this is a common practice.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: gateway-routing
namespace: egress
spec:
hosts:
- httpbin.com
exportTo:
- *
gateways:
- mesh
- istio-egressgateway
http:
- match:
- port: 80
gateways:
- mesh
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
- match:
- port: 80
gateway:
- istio-egressgateway
route:
- destination:
host: httpbin.com
</code></pre>
<p>The following example demonstrates the use of wildcards in the hosts for
external services. If the connection has to be routed to the IP address
requested by the application (i.e. application resolves DNS and attempts
to connect to a specific IP), the discovery mode must be set to <code>NONE</code>.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-wildcard-example
spec:
hosts:
- &quot;*.bar.com&quot;
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: NONE
</code></pre>
<p>The following example demonstrates a service that is available via a
Unix Domain Socket on the host of the client. The resolution must be
set to STATIC to use unix address endpoints.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: unix-domain-socket-example
spec:
hosts:
- &quot;example.unix.local&quot;
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: STATIC
endpoints:
- address: unix:///var/run/example/socket
</code></pre>
<p>For HTTP-based services, it is possible to create a VirtualService
backed by multiple DNS addressable endpoints. In such a scenario, the
application can use the HTTP_PROXY environment variable to transparently
reroute API calls for the VirtualService to a chosen backend. For
example, the following configuration creates a non-existent external
service called foo.bar.com backed by three domains: us.foo.bar.com:8080,
uk.foo.bar.com:9080, and in.foo.bar.com:7080</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-dns
spec:
hosts:
- foo.bar.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
endpoints:
- address: us.foo.bar.com
ports:
https: 8080
- address: uk.foo.bar.com
ports:
https: 9080
- address: in.foo.bar.com
ports:
https: 7080
</code></pre>
<p>With <code>HTTP_PROXY=http://localhost/</code>, calls from the application to
<code>http://foo.bar.com</code> will be load balanced across the three domains
specified above. In other words, a call to <code>http://foo.bar.com/baz</code> would
be translated to <code>http://uk.foo.bar.com/baz</code>.</p>
<p>The following example illustrates the usage of a ServiceEntry
containing a subject alternate name
whose format conforms to the SPIFEE standard
<a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md</a>:</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin
namespace : httpbin-ns
spec:
hosts:
- httpbin.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: STATIC
endpoints:
- address: 2.2.2.2
- address: 3.3.3.3
subjectAltNames:
- &quot;spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account&quot;
</code></pre>
<h2 id="ServiceEntry">ServiceEntry</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. The hosts associated with the ServiceEntry. Could be a DNS
name with wildcard prefix (external services only). DNS names in hosts
will be ignored if the application accesses the service over non-HTTP
protocols such as mongo/opaque TCP/HTTPS. In such scenarios, the
IP addresses specified in the Addresses field or the port will be used
to uniquely identify the destination.</p>
</td>
</tr>
<tr id="ServiceEntry-addresses">
<td><code>addresses</code></td>
<td><code>string[]</code></td>
<td>
<p>The virtual IP addresses associated with the service. Could be CIDR
prefix. For HTTP services, the addresses field will be ignored and
the destination will be identified based on the HTTP Host/Authority
header. For non-HTTP protocols such as mongo/opaque TCP/HTTPS,
the hosts will be ignored. If one or more IP addresses are specified,
the incoming traffic will be identified as belonging to this service
if the destination IP matches the IP/CIDRs specified in the addresses
field. If the Addresses field is empty, traffic will be identified
solely based on the destination port. In such scenarios, the port on
which the service is being accessed must not be shared by any other
service in the mesh. In other words, the sidecar will behave as a
simple TCP proxy, forwarding incoming traffic on a specified port to
the specified destination endpoint IP/host. Unix domain socket
addresses are not supported in this field.</p>
</td>
</tr>
<tr id="ServiceEntry-ports">
<td><code>ports</code></td>
<td><code><a href="https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html#Port">Port[]</a></code></td>
<td>
<p>REQUIRED. The ports associated with the external service. If the
Endpoints are unix domain socket addresses, there must be exactly one
port.</p>
</td>
</tr>
<tr id="ServiceEntry-location">
<td><code>location</code></td>
<td><code><a href="#ServiceEntry-Location">ServiceEntry.Location</a></code></td>
<td>
<p>Specify whether the service should be considered external to the mesh
or part of the mesh.</p>
</td>
</tr>
<tr id="ServiceEntry-resolution">
<td><code>resolution</code></td>
<td><code><a href="#ServiceEntry-Resolution">ServiceEntry.Resolution</a></code></td>
<td>
<p>REQUIRED: Service discovery mode for the hosts. Care must be taken
when setting the resolution mode to NONE for a TCP port without
accompanying IP addresses. In such cases, traffic to any IP on
said port will be allowed (i.e. 0.0.0.0:<port>).</p>
</td>
</tr>
<tr id="ServiceEntry-endpoints">
<td><code>endpoints</code></td>
<td><code><a href="#ServiceEntry-Endpoint">ServiceEntry.Endpoint[]</a></code></td>
<td>
<p>One or more endpoints associated with the service.</p>
</td>
</tr>
<tr id="ServiceEntry-export_to">
<td><code>exportTo</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of namespaces to which this service is exported. Exporting a service
allows it to used by sidecars, gateways and virtual services defined in
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of services across
namespace boundaries.</p>
<p>If no namespaces are specified then the service is exported to all
namespaces by default.</p>
<p>The value &ldquo;.&rdquo; is reserved and defines an export to the same namespace that
the service is declared in, similarly the value &ldquo;*&rdquo; is reserved and
defines an export to all namespaces.</p>
<p>For a Kubernetes Service the equivalent effect can be achieved by setting
the annotation &ldquo;networking.istio.io/exportTo&rdquo; to a comma-separated list
of namespace names.</p>
</td>
</tr>
<tr id="ServiceEntry-subject_alt_names">
<td><code>subjectAltNames</code></td>
<td><code>string[]</code></td>
<td>
<p>The list of subject alternate names allowed for workloads that
implement this service. This information is used to enforce
<a href="/docs/concepts/security/#secure-naming">secure-naming</a>.
If specified, the proxy will verify that the server
certificate&rsquo;s subject alternate name matches one of the specified values.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Endpoint">ServiceEntry.Endpoint</h2>
<section>
<p>Endpoint defines a network address (IP or hostname) associated with
the mesh service.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Endpoint-address">
<td><code>address</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: Address associated with the network endpoint without the
port. Domain names can be used if and only if the resolution is set
to DNS, and must be fully-qualified without wildcards. Use the form
unix:///absolute/path/to/socket for unix domain socket endpoints.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-ports">
<td><code>ports</code></td>
<td><code>map&lt;string,&nbsp;uint32&gt;</code></td>
<td>
<p>Set of ports associated with the endpoint. The ports must be
associated with a port name that was declared as part of the
service. Do not use for unix:// addresses.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-labels">
<td><code>labels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>One or more labels associated with the endpoint.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-network">
<td><code>network</code></td>
<td><code>string</code></td>
<td>
<p>Network enables Istio to group endpoints resident in the same L3
domain/network. All endpoints in the same network are assumed to be
directly reachable from one another. When endpoints in different
networks cannot reach each other directly, an Istio Gateway can be
used to establish connectivity (usually using the
AUTO_PASSTHROUGH mode in a Gateway Server). This is
an advanced configuration used typically for spanning an Istio mesh
over multiple clusters.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-locality">
<td><code>locality</code></td>
<td><code>string</code></td>
<td>
<p>The locality associated with the endpoint. A locality corresponds
to a failure domain (e.g., country/region/zone). Arbitrary failure
domain hierarchies can be represented by separating each
encapsulating failure domain by /. For example, the locality of an
an endpoint in US, in US-East-1 region, within availability zone
az-1, in data center rack r11 can be represented as
us/us-east-1/az-1/r11. Istio will configure the sidecar to route to
endpoints within the same locality as the sidecar. If none of the
endpoints in the locality are available, endpoints parent locality
(but within the same network ID) will be chosen. For example, if
there are two endpoints in same network (networkID &ldquo;n1&rdquo;), say e1
with locality us/us-east-1/az-1/r11 and e2 with locality
us/us-east-1/az-2/r12, a sidecar from us/us-east-1/az-1/r11 locality
will prefer e1 from the same locality over e2 from a different
locality. Endpoint e2 could be the IP associated with a gateway
(that bridges networks n1 and n2), or the IP associated with a
standard service endpoint.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-weight">
<td><code>weight</code></td>
<td><code>uint32</code></td>
<td>
<p>The load balancing weight associated with the endpoint. Endpoints
with higher weights will receive proportionally higher traffic.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Location">ServiceEntry.Location</h2>
<section>
<p>Location specifies whether the service is part of Istio mesh or
outside the mesh. Location determines the behavior of several
features, such as service-to-service mTLS authentication, policy
enforcement, etc. When communicating with services outside the mesh,
Istio&rsquo;s mTLS authentication is disabled, and policy enforcement is
performed on the client-side as opposed to server-side.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Location-MESH_EXTERNAL">
<td><code>MESH_EXTERNAL</code></td>
<td>
<p>Signifies that the service is external to the mesh. Typically used
to indicate external services consumed through APIs.</p>
</td>
</tr>
<tr id="ServiceEntry-Location-MESH_INTERNAL">
<td><code>MESH_INTERNAL</code></td>
<td>
<p>Signifies that the service is part of the mesh. Typically used to
indicate services added explicitly as part of expanding the service
mesh to include unmanaged infrastructure (e.g., VMs added to a
Kubernetes based service mesh).</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Resolution">ServiceEntry.Resolution</h2>
<section>
<p>Resolution determines how the proxy will resolve the IP addresses of
the network endpoints associated with the service, so that it can
route to one of them. The resolution mode specified here has no impact
on how the application resolves the IP address associated with the
service. The application may still have to use DNS to resolve the
service to an IP so that the outbound traffic can be captured by the
Proxy. Alternatively, for HTTP services, the application could
directly communicate with the proxy (e.g., by setting HTTP_PROXY) to
talk to these services.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Resolution-NONE">
<td><code>NONE</code></td>
<td>
<p>Assume that incoming connections have already been resolved (to a
specific destination IP address). Such connections are typically
routed via the proxy using mechanisms such as IP table REDIRECT/
eBPF. After performing any routing related transformations, the
proxy will forward the connection to the IP address to which the
connection was bound.</p>
</td>
</tr>
<tr id="ServiceEntry-Resolution-STATIC">
<td><code>STATIC</code></td>
<td>
<p>Use the static IP addresses specified in endpoints (see below) as the
backing instances associated with the service.</p>
</td>
</tr>
<tr id="ServiceEntry-Resolution-DNS">
<td><code>DNS</code></td>
<td>
<p>Attempt to resolve the IP address by querying the ambient DNS,
during request processing. If no endpoints are specified, the proxy
will resolve the DNS address specified in the hosts field, if
wildcards are not used. If endpoints are specified, the DNS
addresses specified in the endpoints will be resolved to determine
the destination IP address. DNS resolution cannot be used with unix
domain socket endpoints.</p>
</td>
</tr>
</tbody>
</table>
</section>

12
networking/v1alpha3/service_entry.proto
View File

@ -16,9 +16,9 @@ syntax = "proto3";
import "networking/v1alpha3/gateway.proto";
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
// $title: Service Entry
// $description: Configuration affecting service registry.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/service-entry.html
// `ServiceEntry` enables adding additional entries into Istio's internal
// service registry, so that auto-discovered services in the mesh can
@ -326,6 +326,10 @@ option go_package = "istio.io/api/networking/v1alpha3";
// - "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
// ```
//
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message ServiceEntry {
// REQUIRED. The hosts associated with the ServiceEntry. Could be a DNS
// name with wildcard prefix (external services only). DNS names in hosts
@ -490,7 +494,7 @@ message ServiceEntry {
// The list of subject alternate names allowed for workloads that
// implement this service. This information is used to enforce
// secure-naming <https://istio.io/docs/concepts/security/#secure-naming>.
// [secure-naming](/docs/concepts/security/#secure-naming).
// If specified, the proxy will verify that the server
// certificate's subject alternate name matches one of the specified values.
repeated string subject_alt_names = 8;

77
networking/v1alpha3/sidecar.pb.go generated
View File

@ -47,83 +47,6 @@ func (x CaptureMode) String() string {
}
func (CaptureMode) EnumDescriptor() ([]byte, []int) { return fileDescriptorSidecar, []int{0} }
// `Sidecar` describes the configuration of the sidecar proxy that mediates
// inbound and outbound communication to the workload it is attached to. By
// default, Istio will program all sidecar proxies in the mesh with the
// necessary configuration required to reach every workload 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. In addition, it is possible to restrict the set
// of services that the proxy can reach when forwarding outbound traffic
// from the workload.
//
// Services and configuration in a mesh are organized into one or more
// namespaces (e.g., a Kubernetes namespace or a CF org/space). A Sidecar
// resource in a namespace will apply to one or more workloads in the same
// namespace, selected using the workloadSelector. In the absence of a
// workloadSelector, it will apply to all workloads in the same
// namespace. When determining the Sidecar resource to be applied to a
// workload, preference will be given to the resource with a
// workloadSelector that selects this workload, over a Sidecar resource
// without any workloadSelector.
//
// NOTE: *_Each namespace can have only one Sidecar resource without any
// workload selector_*. The behavior of the system is undefined if more
// than one selector-less Sidecar resources exist in a given namespace. The
// behavior of the system is undefined if two or more Sidecar resources
// with a workload selector select the same workload.
//
// The example below declares a Sidecar resource in the prod-us1 namespace
// that configures the sidecars in the namespace to allow egress traffic to
// public services in the prod-us1, prod-apis, and the istio-system
// namespaces.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
// metadata:
// name: default
// namespace: prod-us1
// spec:
// egress:
// - hosts:
// - "prod-us1/*"
// - "prod-apis/*"
// - "istio-system/*"
// ```
//
// The example below declares a Sidecar resource in the prod-us1 namespace
// that accepts inbound HTTP traffic on port 9080 and forwards
// it to the attached workload listening on a unix domain socket. In the
// egress direction, in addition to the istio-system namespace, the sidecar
// proxies only HTTP traffic bound for port 9080 for services in the
// prod-us1 namespace.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
// metadata:
// name: default
// namespace: prod-us1
// spec:
// ingress:
// - port:
// number: 9080
// protocol: HTTP
// name: somename
// defaultEndpoint: unix:///var/run/someuds.sock
// egress:
// - hosts:
// - "istio-system/*"
// - port:
// number: 9080
// protocol: HTTP
// name: egresshttp
// hosts:
// - "prod-us1/*"
// ```
//
type Sidecar struct {
// Criteria used to select the specific set of pods/VMs on which this
// sidecar configuration should be applied. If omitted, the sidecar

348
networking/v1alpha3/sidecar.pb.html generated Normal file
View File

@ -0,0 +1,348 @@
---
title: Sidecar
description: Configuration affecting network reachability of a sidecar.
location: https://istio.io/docs/reference/config/networking/v1alpha3/sidecar.html
layout: protoc-gen-docs
generator: protoc-gen-docs
number_of_entries: 5
---
<p><code>Sidecar</code> describes the configuration of the sidecar proxy that mediates
inbound and outbound communication to the workload it is attached to. By
default, Istio will program all sidecar proxies in the mesh with the
necessary configuration required to reach every workload 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. In addition, it is possible to restrict the set
of services that the proxy can reach when forwarding outbound traffic
from the workload.</p>
<p>Services and configuration in a mesh are organized into one or more
namespaces (e.g., a Kubernetes namespace or a CF org/space). A Sidecar
resource in a namespace will apply to one or more workloads in the same
namespace, selected using the workloadSelector. In the absence of a
workloadSelector, it will apply to all workloads in the same
namespace. When determining the Sidecar resource to be applied to a
workload, preference will be given to the resource with a
workloadSelector that selects this workload, over a Sidecar resource
without any workloadSelector.</p>
<p>NOTE: <em><em>Each namespace can have only one Sidecar resource without any
workload selector</em></em>. The behavior of the system is undefined if more
than one selector-less Sidecar resources exist in a given namespace. The
behavior of the system is undefined if two or more Sidecar resources
with a workload selector select the same workload.</p>
<p>The example below declares a Sidecar resource in the prod-us1 namespace
that configures the sidecars in the namespace to allow egress traffic to
public services in the prod-us1, prod-apis, and the istio-system
namespaces.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
egress:
- hosts:
- &quot;prod-us1/*&quot;
- &quot;prod-apis/*&quot;
- &quot;istio-system/*&quot;
</code></pre>
<p>The example below declares a Sidecar resource in the prod-us1 namespace
that accepts inbound HTTP traffic on port 9080 and forwards
it to the attached workload listening on a unix domain socket. In the
egress direction, in addition to the istio-system namespace, the sidecar
proxies only HTTP traffic bound for port 9080 for services in the
prod-us1 namespace.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
ingress:
- port:
number: 9080
protocol: HTTP
name: somename
defaultEndpoint: unix:///var/run/someuds.sock
egress:
- hosts:
- &quot;istio-system/*&quot;
- port:
number: 9080
protocol: HTTP
name: egresshttp
hosts:
- &quot;prod-us1/*&quot;
</code></pre>
<h2 id="CaptureMode">CaptureMode</h2>
<section>
<p>CaptureMode describes how traffic to a listener is expected to be
captured. Applicable only when the listener is bound to an IP.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="CaptureMode-DEFAULT">
<td><code>DEFAULT</code></td>
<td>
<p>The default capture mode defined by the environment</p>
</td>
</tr>
<tr id="CaptureMode-IPTABLES">
<td><code>IPTABLES</code></td>
<td>
<p>Capture traffic using IPtables redirection</p>
</td>
</tr>
<tr id="CaptureMode-NONE">
<td><code>NONE</code></td>
<td>
<p>No traffic capture. When used in egress listener, the application is
expected to explicitly communicate with the listener port/unix
domain socket. When used in ingress listener, care needs to be taken
to ensure that the listener port is not in use by other processes on
the host.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="IstioEgressListener">IstioEgressListener</h2>
<section>
<p>IstioEgressListener specifies the properties of an outbound traffic
listener on the sidecar proxy attached to a workload.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="IstioEgressListener-port">
<td><code>port</code></td>
<td><code><a href="https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html#Port">Port</a></code></td>
<td>
<p>The port associated with the listener. If using unix domain socket,
use 0 as the port number, with a valid protocol. The port if
specified, will be used as the default destination port associated
with the imported hosts. If the port is omitted, Istio will infer the
listener ports based on the imported hosts. Note that when multiple
egress listeners are specified, where one or more listeners have
specific ports while others have no port, the hosts exposed on a
listener port will be based on the listener with the most specific
port.</p>
</td>
</tr>
<tr id="IstioEgressListener-bind">
<td><code>bind</code></td>
<td><code>string</code></td>
<td>
<p>The ip or the unix domain socket to which the listener should be bound
to. Port MUST be specified if bind is not empty. Format: x.x.x.x or
unix:///path/to/uds or unix://@foobar (Linux abstract namespace). If
omitted, Istio will autoconfigure the defaults based on imported
services, the workload to which this configuration is applied to and
the captureMode. If captureMode is NONE, bind will default to
127.0.0.1.</p>
</td>
</tr>
<tr id="IstioEgressListener-capture_mode">
<td><code>captureMode</code></td>
<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
<td>
<p>When the bind address is an IP, the captureMode option dictates
how traffic to the listener is expected to be captured (or not).
captureMode must be DEFAULT or NONE for unix domain socket binds.</p>
</td>
</tr>
<tr id="IstioEgressListener-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED: One or more services/virtualServices exposed by the listener
in namespace/dnsName format. Publicly scoped services and
VirtualServices from remote namespaces corresponding to the specified
hosts will be imported. The service in a namespace can be a service in
the service registry (e.g., a kubernetes or cloud foundry service) or
a service specified via ServiceEntry configuration. In addition, any
publicly scoped DestinationRule associated with the imported services
will also be imported.</p>
<p>Set the namespace to * to import a particular service from any
available namespace (e.g., &ldquo;*/foo.example.com&rdquo;). Set the dnsName field
to * to import all services from the specified namespace (e.g.,
&ldquo;prod/*&rdquo;). The services should be specified using FQDN format.</p>
<p>NOTE: Only exported services and configuration artifacts from a
namespace can be imported. Private services/configuration will not be
imported. Refer to the scope setting associated with VirtualService,
DestinationRule, ServiceEntry, etc. for details.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="IstioIngressListener">IstioIngressListener</h2>
<section>
<p>IstioIngressListener specifies the properties of an inbound
traffic listener on the sidecar proxy attached to a workload.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="IstioIngressListener-port">
<td><code>port</code></td>
<td><code><a href="https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html#Port">Port</a></code></td>
<td>
<p>REQUIRED. The port associated with the listener. If using
unix domain socket, use 0 as the port number, with a valid
protocol.</p>
</td>
</tr>
<tr id="IstioIngressListener-bind">
<td><code>bind</code></td>
<td><code>string</code></td>
<td>
<p>The ip or the unix domain socket to which the listener should be bound
to. Format: x.x.x.x or unix:///path/to/uds or unix://@foobar (Linux
abstract namespace). If omitted, Istio will autoconfigure the defaults
based on imported services and the workload to which this
configuration is applied to.</p>
</td>
</tr>
<tr id="IstioIngressListener-capture_mode">
<td><code>captureMode</code></td>
<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
<td>
<p>When the bind address is an IP, the captureMode option dictates
how traffic to the listener is expected to be captured (or not).
captureMode must be DEFAULT or NONE for unix domain socket binds.</p>
</td>
</tr>
<tr id="IstioIngressListener-default_endpoint">
<td><code>defaultEndpoint</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: The loopback IP endpoint or unix domain socket to which
traffic should be forwarded to. This configuration can be used to
redirect traffic arriving at the bind point on the sidecar to a port
or unix domain socket where the application workload is listening for
connections. Format should be 127.0.0.1:PORT or unix:///path/to/socket</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Sidecar">Sidecar</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Sidecar-workload_selector">
<td><code>workloadSelector</code></td>
<td><code><a href="#WorkloadSelector">WorkloadSelector</a></code></td>
<td>
<p>Criteria used to select the specific set of pods/VMs on which this
sidecar configuration should be applied. If omitted, the sidecar
configuration will be applied to all workloads in the same config
namespace.</p>
</td>
</tr>
<tr id="Sidecar-ingress">
<td><code>ingress</code></td>
<td><code><a href="#IstioIngressListener">IstioIngressListener[]</a></code></td>
<td>
<p>Ingress specifies the configuration of the sidecar for processing
inbound traffic to the attached workload. If omitted, Istio will
autoconfigure the sidecar based on the information about the workload
obtained from the orchestration platform (e.g., exposed ports, services,
etc.).</p>
</td>
</tr>
<tr id="Sidecar-egress">
<td><code>egress</code></td>
<td><code><a href="#IstioEgressListener">IstioEgressListener[]</a></code></td>
<td>
<p>Egress specifies the configuration of the sidecar for processing
outbound traffic from the attached workload to other services in the
mesh. If omitted, Istio will autoconfigure the sidecar to be able to
reach every service in the mesh that is visible to this namespace.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="WorkloadSelector">WorkloadSelector</h2>
<section>
<p>WorkloadSelector specifies the criteria used to determine if the Gateway
or Sidecar resource can be applied to a proxy. The matching criteria
includes the metadata associated with a proxy, workload info such as
labels attached to the pod/VM, or any other info that the proxy provides
to Istio during the initial handshake. If multiple conditions are
specified, all conditions need to match in order for the workload to be
selected. Currently, only label based selection mechanism is supported.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="WorkloadSelector-labels">
<td><code>labels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>REQUIRED: One or more labels that indicate a specific set of pods/VMs
on which this sidecar configuration should be applied. The scope of
label search is restricted to the configuration namespace in which the
the resource is present.</p>
</td>
</tr>
</tbody>
</table>
</section>

10
networking/v1alpha3/sidecar.proto
View File

@ -16,9 +16,9 @@ syntax = "proto3";
import "networking/v1alpha3/gateway.proto";
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
// $title: Sidecar
// $description: Configuration affecting network reachability of a sidecar.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/sidecar.html
// `Sidecar` describes the configuration of the sidecar proxy that mediates
// inbound and outbound communication to the workload it is attached to. By
@ -97,6 +97,10 @@ option go_package = "istio.io/api/networking/v1alpha3";
// - "prod-us1/*"
// ```
//
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message Sidecar {
// Criteria used to select the specific set of pods/VMs on which this
// sidecar configuration should be applied. If omitted, the sidecar

64
networking/v1alpha3/virtual_service.pb.go generated
View File

@ -18,66 +18,6 @@ var _ = proto.Marshal
var _ = fmt.Errorf
var _ = math.Inf
// A `VirtualService` defines a set of traffic routing rules to apply when a host is
// addressed. Each routing rule defines matching criteria for traffic of a specific
// protocol. If the traffic is matched, then it is sent to a named destination service
// (or subset/version of it) defined in the registry.
//
// The source of traffic can also be matched in a routing rule. This allows routing
// to be customized for specific client contexts.
//
// The following example on Kubernetes, routes all HTTP traffic by default to
// pods of the reviews service with label "version: v1". In addition,
// HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will
// be rewritten to /newcatalog and sent to pods with label "version: v2".
//
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: VirtualService
// metadata:
// name: reviews-route
// spec:
// hosts:
// - reviews.prod.svc.cluster.local
// http:
// - match:
// - uri:
// prefix: "/wpcatalog"
// - uri:
// prefix: "/consumercatalog"
// rewrite:
// uri: "/newcatalog"
// route:
// - destination:
// host: reviews.prod.svc.cluster.local
// subset: v2
// - route:
// - destination:
// host: reviews.prod.svc.cluster.local
// subset: v1
// ```
//
// A subset/version of a route destination is identified with a reference
// to a named service subset which must be declared in a corresponding
// `DestinationRule`.
//
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: DestinationRule
// metadata:
// name: reviews-destination
// spec:
// host: reviews.prod.svc.cluster.local
// subsets:
// - name: v1
// labels:
// version: v1
// - name: v2
// labels:
// version: v2
// ```
//
type VirtualService struct {
// REQUIRED. The destination hosts to which traffic is being sent. Could
// be a DNS name with wildcard prefix or an IP address. Depending on the
@ -202,7 +142,7 @@ func (m *VirtualService) GetExportTo() []string {
// registry. Istio's service registry is composed of all the services found
// in the platform's service registry (e.g., Kubernetes services, Consul
// services), as well as services declared through the
// [ServiceEntry](#ServiceEntry) resource.
// [ServiceEntry](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry) resource.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"
// instead of "reviews.default.svc.cluster.local"), Istio will interpret
@ -327,7 +267,7 @@ type Destination struct {
// REQUIRED. The name of a service from the service registry. Service
// names are looked up from the platform's service registry (e.g.,
// Kubernetes services, Consul services, etc.) and from the hosts
// declared by [ServiceEntry](#ServiceEntry). Traffic forwarded to
// declared by [ServiceEntry](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry). Traffic forwarded to
// destinations that are not found in either of the two, will be dropped.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"

1759
networking/v1alpha3/virtual_service.pb.html generated Normal file
View File

File diff suppressed because it is too large Load Diff

21
networking/v1alpha3/virtual_service.proto
View File

@ -17,11 +17,9 @@ syntax = "proto3";
import "google/protobuf/duration.proto";
import "google/protobuf/wrappers.proto";
// $title: Traffic Routing
// $description: Configuration affecting traffic routing.
// $location: https://istio.io/docs/reference/config/istio.networking.v1alpha3.html
// $aliases:
// $ - /docs/reference/config/istio.routing.v1alpha1/
// $title: Virtual Service
// $description: Configuration affecting label/content routing, sni routing, etc.
// $location: https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service.html
// Configuration affecting traffic routing. Here are a few terms useful to define
// in the context of traffic routing.
@ -51,10 +49,7 @@ import "google/protobuf/wrappers.proto";
// actual choice of the version is determined by the proxy/sidecar, enabling the
// application code to decouple itself from the evolution of dependent
// services.
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
//
// A `VirtualService` defines a set of traffic routing rules to apply when a host is
// addressed. Each routing rule defines matching criteria for traffic of a specific
// protocol. If the traffic is matched, then it is sent to a named destination service
@ -115,6 +110,10 @@ option go_package = "istio.io/api/networking/v1alpha3";
// version: v2
// ```
//
package istio.networking.v1alpha3;
option go_package = "istio.io/api/networking/v1alpha3";
message VirtualService {
// REQUIRED. The destination hosts to which traffic is being sent. Could
// be a DNS name with wildcard prefix or an IP address. Depending on the
@ -197,7 +196,7 @@ message VirtualService {
// registry. Istio's service registry is composed of all the services found
// in the platform's service registry (e.g., Kubernetes services, Consul
// services), as well as services declared through the
// [ServiceEntry](#ServiceEntry) resource.
// [ServiceEntry](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry) resource.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"
// instead of "reviews.default.svc.cluster.local"), Istio will interpret
@ -322,7 +321,7 @@ message Destination {
// REQUIRED. The name of a service from the service registry. Service
// names are looked up from the platform's service registry (e.g.,
// Kubernetes services, Consul services, etc.) and from the hosts
// declared by [ServiceEntry](#ServiceEntry). Traffic forwarded to
// declared by [ServiceEntry](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry). Traffic forwarded to
// destinations that are not found in either of the two, will be dropped.
//
// *Note for Kubernetes users*: When short names are used (e.g. "reviews"