v1

package
v1.24.2 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Dec 6, 2024 License: Apache-2.0 Imports: 1 Imported by: 7

Documentation

Overview

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Code generated by protoc-gen-alias. DO NOT EDIT.

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type CaptureMode 

type CaptureMode = v1alpha3.CaptureMode

`CaptureMode` describes how traffic to a listener is expected to be captured. Applicable only when the listener is bound to an IP. 

const CaptureMode_DEFAULT CaptureMode = v1alpha3.CaptureMode_DEFAULT

The default capture mode defined by the environment. 

const CaptureMode_IPTABLES CaptureMode = v1alpha3.CaptureMode_IPTABLES

Capture traffic using IPtables redirection. 

const CaptureMode_NONE CaptureMode = v1alpha3.CaptureMode_NONE

No traffic capture. When used in an egress listener, the application is expected to explicitly communicate with the listener port or Unix domain socket. When used in an ingress listener, care needs to be taken to ensure that the listener port is not in use by other processes on the host.

type ClientTLSSettings 

type ClientTLSSettings = v1alpha3.ClientTLSSettings

SSL/TLS related settings for upstream connections. See Envoy's [TLS context](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto.html#common-tls-configuration) for more details. These settings are common to both HTTP and TCP upstreams.

For example, the following rule configures a client to use mutual TLS for connections to upstream database cluster.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: db-mtls

spec: 

host: mydbserver.prod.svc.cluster.local
trafficPolicy:
  tls:
    mode: MUTUAL
    clientCertificate: /etc/certs/myclientcert.pem
    privateKey: /etc/certs/client_private_key.pem
    caCertificates: /etc/certs/rootcacerts.pem

```

The following rule configures a client to use TLS when talking to a foreign service whose domain matches *.foo.com.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: tls-foo

spec: 

host: "*.foo.com"
trafficPolicy:
  tls:
    mode: SIMPLE

```

The following rule configures a client to use Istio mutual TLS when talking to rating services.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: ratings-istio-mtls

spec: 

host: ratings.prod.svc.cluster.local
trafficPolicy:
  tls:
    mode: ISTIO_MUTUAL

```

type ClientTLSSettings_TLSmode 

type ClientTLSSettings_TLSmode = v1alpha3.ClientTLSSettings_TLSmode

TLS connection mode 

const ClientTLSSettings_DISABLE ClientTLSSettings_TLSmode = v1alpha3.ClientTLSSettings_DISABLE

Do not setup a TLS connection to the upstream endpoint. 

const ClientTLSSettings_ISTIO_MUTUAL ClientTLSSettings_TLSmode = v1alpha3.ClientTLSSettings_ISTIO_MUTUAL

Secure connections to the upstream using mutual TLS by presenting client certificates for authentication. Compared to Mutual mode, this mode uses certificates generated automatically by Istio for mTLS authentication. When this mode is used, all other fields in `ClientTLSSettings` should be empty. 

const ClientTLSSettings_MUTUAL ClientTLSSettings_TLSmode = v1alpha3.ClientTLSSettings_MUTUAL

Secure connections to the upstream using mutual TLS by presenting client certificates for authentication. 

const ClientTLSSettings_SIMPLE ClientTLSSettings_TLSmode = v1alpha3.ClientTLSSettings_SIMPLE

Originate a TLS connection to the upstream endpoint.

type ConnectionPoolSettings 

type ConnectionPoolSettings = v1alpha3.ConnectionPoolSettings

Connection pool settings for an upstream host. The settings apply to each individual host in the upstream service. See Envoy's [circuit breaker](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking) for more details. Connection pool settings can be applied at the TCP level as well as at HTTP level.

For example, the following rule sets a limit of 100 connections to redis service called myredissrv with a connect timeout of 30ms

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: bookinfo-redis

spec: 

host: myredissrv.prod.svc.cluster.local
trafficPolicy:
  connectionPool:
    tcp:
      maxConnections: 100
      connectTimeout: 30ms
      tcpKeepalive:
        time: 7200s
        interval: 75s

```

type ConnectionPoolSettings_HTTPSettings 

type ConnectionPoolSettings_HTTPSettings = v1alpha3.ConnectionPoolSettings_HTTPSettings

Settings applicable to HTTP1.1/HTTP2/GRPC connections.

type ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy 

type ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy = v1alpha3.ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy

Policy for upgrading http1.1 connections to http2. 

const ConnectionPoolSettings_HTTPSettings_DEFAULT ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy = v1alpha3.ConnectionPoolSettings_HTTPSettings_DEFAULT

Use the global default. 

const ConnectionPoolSettings_HTTPSettings_DO_NOT_UPGRADE ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy = v1alpha3.ConnectionPoolSettings_HTTPSettings_DO_NOT_UPGRADE

Do not upgrade the connection to http2. This opt-out option overrides the default. 

const ConnectionPoolSettings_HTTPSettings_UPGRADE ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy = v1alpha3.ConnectionPoolSettings_HTTPSettings_UPGRADE

Upgrade the connection to http2. This opt-in option overrides the default.

type ConnectionPoolSettings_TCPSettings 

type ConnectionPoolSettings_TCPSettings = v1alpha3.ConnectionPoolSettings_TCPSettings

Settings common to both HTTP and TCP upstream connections.

type ConnectionPoolSettings_TCPSettings_TcpKeepalive 

type ConnectionPoolSettings_TCPSettings_TcpKeepalive = v1alpha3.ConnectionPoolSettings_TCPSettings_TcpKeepalive

TCP keepalive.

type CorsPolicy 

type CorsPolicy = v1alpha3.CorsPolicy

Describes the Cross-Origin Resource Sharing (CORS) policy, for a given service. Refer to [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) for further details about cross origin resource sharing. For example, the following rule restricts cross origin requests to those originating from example.com domain using HTTP POST/GET, and sets the `Access-Control-Allow-Credentials` header to false. In addition, it only exposes `X-Foo-bar` header and sets an expiry period of 1 day.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- route:
  - destination:
      host: ratings.prod.svc.cluster.local
      subset: v1
  corsPolicy:
    allowOrigins:
    - exact: https://example.com
    allowMethods:
    - POST
    - GET
    allowCredentials: false
    allowHeaders:
    - X-Foo-Bar
    maxAge: "24h"

```

type CorsPolicy_UnmatchedPreflights added in v1.23.0 

type CorsPolicy_UnmatchedPreflights = v1alpha3.CorsPolicy_UnmatchedPreflights
const CorsPolicy_FORWARD CorsPolicy_UnmatchedPreflights = v1alpha3.CorsPolicy_FORWARD

Preflight requests not matching the configured allowed origin will be forwarded to the upstream. 

const CorsPolicy_IGNORE CorsPolicy_UnmatchedPreflights = v1alpha3.CorsPolicy_IGNORE

Preflight requests not matching the configured allowed origin will not be forwarded to the upstream. 

const CorsPolicy_UNSPECIFIED CorsPolicy_UnmatchedPreflights = v1alpha3.CorsPolicy_UNSPECIFIED

Default to FORWARD

type Delegate 

type Delegate = v1alpha3.Delegate

Describes the delegate VirtualService. The following routing rules forward the traffic to `/productpage` by a delegate VirtualService named `productpage`, forward the traffic to `/reviews` by a delegate VirtualService named `reviews`.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: bookinfo

spec: 

hosts:
- "bookinfo.com"
gateways:
- mygateway
http:
- match:
  - uri:
      prefix: "/productpage"
  delegate:
     name: productpage
     namespace: nsA
- match:
  - uri:
      prefix: "/reviews"
  delegate:
      name: reviews
      namespace: nsB

```

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: productpage
namespace: nsA

spec: 

http:
- match:
   - uri:
      prefix: "/productpage/v1/"
  route:
  - destination:
      host: productpage-v1.nsA.svc.cluster.local
- route:
  - destination:
      host: productpage.nsA.svc.cluster.local

```

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews
namespace: nsB

spec: 

http:
- route:
  - destination:
      host: reviews.nsB.svc.cluster.local

```

type Destination 

type Destination = v1alpha3.Destination

Destination indicates the network addressable service to which the request/connection will be sent after processing a routing rule. The destination.host should unambiguously refer to a service in the service 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(https://istio.io/docs/reference/config/networking/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 the short name based on the namespace of the rule, not the service. A rule in the "default" namespace containing a host "reviews" will be interpreted as "reviews.default.svc.cluster.local", irrespective of the actual namespace associated with the reviews service. _To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names._

The following Kubernetes example routes all traffic by default to pods of the reviews service with label "version: v1" (i.e., subset v1), and some to subset v2, in a Kubernetes environment.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews-route
namespace: foo

spec: 

hosts:
- reviews # interpreted as reviews.foo.svc.cluster.local
http:
- match:
  - uri:
      prefix: "/wpcatalog"
  - uri:
      prefix: "/consumercatalog"
  rewrite:
    uri: "/newcatalog"
  route:
  - destination:
      host: reviews # interpreted as reviews.foo.svc.cluster.local
      subset: v2
- route:
  - destination:
      host: reviews # interpreted as reviews.foo.svc.cluster.local
      subset: v1

```

And the associated DestinationRule

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: reviews-destination
namespace: foo

spec: 

host: reviews # interpreted as reviews.foo.svc.cluster.local
subsets:
- name: v1
  labels:
    version: v1
- name: v2
  labels:
    version: v2

```

The following VirtualService sets a timeout of 5s for all calls to productpage.prod.svc.cluster.local service in Kubernetes. Notice that there are no subsets defined in this rule. Istio will fetch all instances of productpage.prod.svc.cluster.local service from the service registry and populate the sidecar's load balancing pool. Also, notice that this rule is set in the istio-system namespace but uses the fully qualified domain name of the productpage service, productpage.prod.svc.cluster.local. Therefore the rule's namespace does not have an impact in resolving the name of the productpage service.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: my-productpage-rule
namespace: istio-system

spec: 

hosts:
- productpage.prod.svc.cluster.local # ignores rule namespace
http:
- timeout: 5s
  route:
  - destination:
      host: productpage.prod.svc.cluster.local

```

To control routing for traffic bound to services outside the mesh, external services must first be added to Istio's internal service registry using the ServiceEntry resource. VirtualServices can then be defined to control traffic bound to these external services. For example, the following rules define a Service for wikipedia.org and set a timeout of 5s for HTTP requests.

```yaml apiVersion: networking.istio.io/v1 kind: ServiceEntry metadata: 

name: external-svc-wikipedia

spec: 

hosts:
- wikipedia.org
location: MESH_EXTERNAL
ports:
- number: 80
  name: example-http
  protocol: HTTP
resolution: DNS

--- apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: my-wiki-rule

spec: 

hosts:
- wikipedia.org
http:
- timeout: 5s
  route:
  - destination:
      host: wikipedia.org

```

type DestinationRule 

type DestinationRule = v1alpha3.DestinationRule

DestinationRule defines policies that apply to traffic intended for a service after routing has occurred.

<!-- crd generation tags +cue-gen:DestinationRule:groupName:networking.istio.io +cue-gen:DestinationRule:versions:v1beta1,v1alpha3,v1 +cue-gen:DestinationRule:annotations:helm.sh/resource-policy=keep +cue-gen:DestinationRule:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:DestinationRule:subresource:status +cue-gen:DestinationRule:scope:Namespaced +cue-gen:DestinationRule:resource:categories=istio-io,networking-istio-io,shortNames=dr +cue-gen:DestinationRule:printerColumn:name=Host,type=string,JSONPath=.spec.host,description="The name of a service from the service registry" +cue-gen:DestinationRule:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" +cue-gen:DestinationRule:preserveUnknownFields:false -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true -->

type ExecHealthCheckConfig 

type ExecHealthCheckConfig = v1alpha3.ExecHealthCheckConfig

type Gateway 

type Gateway = v1alpha3.Gateway

Gateway describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.

<!-- crd generation tags +cue-gen:Gateway:groupName:networking.istio.io +cue-gen:Gateway:versions:v1beta1,v1alpha3,v1 +cue-gen:Gateway:annotations:helm.sh/resource-policy=keep +cue-gen:Gateway:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:Gateway:subresource:status +cue-gen:Gateway:scope:Namespaced +cue-gen:Gateway:resource:categories=istio-io,networking-istio-io,shortNames=gw +cue-gen:Gateway:preserveUnknownFields:false -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true -->

type HTTPBody 

type HTTPBody = v1alpha3.HTTPBody

type HTTPBody_Bytes 

type HTTPBody_Bytes = v1alpha3.HTTPBody_Bytes

response body as base64 encoded bytes.

type HTTPBody_String_ 

type HTTPBody_String_ = v1alpha3.HTTPBody_String_

response body as a string

type HTTPDirectResponse 

type HTTPDirectResponse = v1alpha3.HTTPDirectResponse

HTTPDirectResponse can be used to send a fixed response to clients. For example, the following rule returns a fixed 503 status with a body to requests for /v1/getProductRatings API.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - uri:
      exact: /v1/getProductRatings
  directResponse:
    status: 503
    body:
      string: "unknown error"
...

```

It is also possible to specify a binary response body. This is mostly useful for non text-based protocols such as gRPC.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - uri:
      exact: /v1/getProductRatings
  directResponse:
    status: 503
    body:
      bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...

```

It is good practice to add headers in the HTTPRoute as well as the direct_response, for example to specify the returned Content-Type.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - uri:
      exact: /v1/getProductRatings
  directResponse:
    status: 503
    body:
      string: "{\"error\": \"unknown error\"}"
  headers:
    response:
      set:
        content-type: "text/plain"
...

```

type HTTPFaultInjection 

type HTTPFaultInjection = v1alpha3.HTTPFaultInjection

HTTPFaultInjection can be used to specify one or more faults to inject while forwarding HTTP requests to the destination specified in a route. Fault specification is part of a VirtualService rule. Faults include aborting the Http request from downstream service, and/or delaying proxying of requests. A fault rule MUST HAVE delay or abort or both.

*Note:* Delay and abort faults are independent of one another, even if both are specified simultaneously.

type HTTPFaultInjection_Abort 

type HTTPFaultInjection_Abort = v1alpha3.HTTPFaultInjection_Abort

Abort specification is used to prematurely abort a request with a pre-specified error code. The following example will return an HTTP 400 error code for 1 out of every 1000 requests to the "ratings" service "v1".

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- route:
  - destination:
      host: ratings.prod.svc.cluster.local
      subset: v1
  fault:
    abort:
      percentage:
        value: 0.1
      httpStatus: 400

```

The _httpStatus_ field is used to indicate the HTTP status code to return to the caller. The optional _percentage_ field can be used to only abort a certain percentage of requests. If not specified, no request will be aborted.

type HTTPFaultInjection_Abort_GrpcStatus 

type HTTPFaultInjection_Abort_GrpcStatus = v1alpha3.HTTPFaultInjection_Abort_GrpcStatus

GRPC status code to use to abort the request. The supported codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md Note: If you want to return the status "Unavailable", then you should specify the code as `UNAVAILABLE`(all caps), but not `14`.

type HTTPFaultInjection_Abort_Http2Error 

type HTTPFaultInjection_Abort_Http2Error = v1alpha3.HTTPFaultInjection_Abort_Http2Error

$hide_from_docs

type HTTPFaultInjection_Abort_HttpStatus 

type HTTPFaultInjection_Abort_HttpStatus = v1alpha3.HTTPFaultInjection_Abort_HttpStatus

HTTP status code to use to abort the Http request.

type HTTPFaultInjection_Delay 

type HTTPFaultInjection_Delay = v1alpha3.HTTPFaultInjection_Delay

Delay specification is used to inject latency into the request forwarding path. The following example will introduce a 5 second delay in 1 out of every 1000 requests to the "v1" version of the "reviews" service from all pods with label env: prod

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews-route

spec: 

hosts:
- reviews.prod.svc.cluster.local
http:
- match:
  - sourceLabels:
      env: prod
  route:
  - destination:
      host: reviews.prod.svc.cluster.local
      subset: v1
  fault:
    delay:
      percentage:
        value: 0.1
      fixedDelay: 5s

```

The _fixedDelay_ field is used to indicate the amount of delay in seconds. The optional _percentage_ field can be used to only delay a certain percentage of requests. If left unspecified, no request will be delayed.

type HTTPFaultInjection_Delay_ExponentialDelay 

type HTTPFaultInjection_Delay_ExponentialDelay = v1alpha3.HTTPFaultInjection_Delay_ExponentialDelay

$hide_from_docs

type HTTPFaultInjection_Delay_FixedDelay 

type HTTPFaultInjection_Delay_FixedDelay = v1alpha3.HTTPFaultInjection_Delay_FixedDelay

Add a fixed delay before forwarding the request. Format: 1h/1m/1s/1ms. MUST be >=1ms.

type HTTPHeader 

type HTTPHeader = v1alpha3.HTTPHeader

type HTTPHealthCheckConfig 

type HTTPHealthCheckConfig = v1alpha3.HTTPHealthCheckConfig

type HTTPMatchRequest 

type HTTPMatchRequest = v1alpha3.HTTPMatchRequest

HttpMatchRequest specifies a set of criteria to be met in order for the rule to be applied to the HTTP request. For example, the following restricts the rule to match only requests where the URL path starts with /ratings/v2/ and the request contains a custom `end-user` header with value `jason`.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - headers:
      end-user:
        exact: jason
    uri:
      prefix: "/ratings/v2/"
    ignoreUriCase: true
  route:
  - destination:
      host: ratings.prod.svc.cluster.local

```

HTTPMatchRequest CANNOT be empty. **Note:** 1. If a root VirtualService have matched any property (path, header etc.) by regex, delegate VirtualServices should not have any other matches on the same property. 2. If a delegate VirtualService have matched any property (path, header etc.) by regex, root VirtualServices should not have any other matches on the same property.

type HTTPMirrorPolicy 

type HTTPMirrorPolicy = v1alpha3.HTTPMirrorPolicy

HTTPMirrorPolicy can be used to specify the destinations to mirror HTTP traffic in addition to the original destination. Mirrored traffic is on a best effort basis where the sidecar/gateway will not wait for the mirrored destinations to respond before returning the response from the original destination. Statistics will be generated for the mirrored destination.

type HTTPRedirect 

type HTTPRedirect = v1alpha3.HTTPRedirect

HTTPRedirect can be used to send a 301 redirect response to the caller, where the Authority/Host and the URI in the response can be swapped with the specified values. For example, the following rule redirects requests for /v1/getProductRatings API on the ratings service to /v1/bookRatings provided by the bookratings service.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - uri:
      exact: /v1/getProductRatings
  redirect:
    uri: /v1/bookRatings
    authority: newratings.default.svc.cluster.local
...

```

type HTTPRedirect_DerivePort 

type HTTPRedirect_DerivePort = v1alpha3.HTTPRedirect_DerivePort

On a redirect, dynamically set the port: * FROM_PROTOCOL_DEFAULT: automatically set to 80 for HTTP and 443 for HTTPS. * FROM_REQUEST_PORT: automatically use the port of the request.

type HTTPRedirect_Port 

type HTTPRedirect_Port = v1alpha3.HTTPRedirect_Port

On a redirect, overwrite the port portion of the URL with this value.

type HTTPRedirect_RedirectPortSelection 

type HTTPRedirect_RedirectPortSelection = v1alpha3.HTTPRedirect_RedirectPortSelection
const HTTPRedirect_FROM_PROTOCOL_DEFAULT HTTPRedirect_RedirectPortSelection = v1alpha3.HTTPRedirect_FROM_PROTOCOL_DEFAULT
const HTTPRedirect_FROM_REQUEST_PORT HTTPRedirect_RedirectPortSelection = v1alpha3.HTTPRedirect_FROM_REQUEST_PORT

type HTTPRetry 

type HTTPRetry = v1alpha3.HTTPRetry

Describes the retry policy to use when a HTTP request fails. For example, the following rule sets the maximum number of retries to 3 when calling ratings:v1 service, with a 2s timeout per retry attempt. A retry will be attempted if there is a connect-failure, refused_stream or when the upstream server responds with Service Unavailable(503).

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- route:
  - destination:
      host: ratings.prod.svc.cluster.local
      subset: v1
  retries:
    attempts: 3
    perTryTimeout: 2s
    retryOn: gateway-error,connect-failure,refused-stream

```

type HTTPRewrite 

type HTTPRewrite = v1alpha3.HTTPRewrite

HTTPRewrite can be used to rewrite specific parts of a HTTP request before forwarding the request to the destination. Rewrite primitive can be used only with HTTPRouteDestination. The following example demonstrates how to rewrite the URL prefix for api call (/ratings) to ratings service before making the actual API call.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: ratings-route

spec: 

hosts:
- ratings.prod.svc.cluster.local
http:
- match:
  - uri:
      prefix: /ratings
  rewrite:
    uri: /v1/bookRatings
  route:
  - destination:
      host: ratings.prod.svc.cluster.local
      subset: v1

```

type HTTPRoute 

type HTTPRoute = v1alpha3.HTTPRoute

Describes match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic. See VirtualService for usage examples.

type HTTPRouteDestination 

type HTTPRouteDestination = v1alpha3.HTTPRouteDestination

Each routing rule is associated with one or more service versions (see glossary in beginning of document). Weights associated with the version determine the proportion of traffic it receives. For example, the following rule will route 25% of traffic for the "reviews" service to instances with the "v2" tag and the remaining traffic (i.e., 75%) to "v1".

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews-route

spec: 

hosts:
- reviews.prod.svc.cluster.local
http:
- route:
  - destination:
      host: reviews.prod.svc.cluster.local
      subset: v2
    weight: 25
  - destination:
      host: reviews.prod.svc.cluster.local
      subset: v1
    weight: 75

```

And the associated DestinationRule

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: reviews-destination

spec: 

host: reviews.prod.svc.cluster.local
subsets:
- name: v1
  labels:
    version: v1
- name: v2
  labels:
    version: v2

```

Traffic can also be split across two entirely different services without having to define new subsets. For example, the following rule forwards 25% of traffic to reviews.com to dev.reviews.com

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews-route-two-domains

spec: 

hosts:
- reviews.com
http:
- route:
  - destination:
      host: dev.reviews.com
    weight: 25
  - destination:
      host: reviews.com
    weight: 75

```

type Headers 

type Headers = v1alpha3.Headers

Message headers can be manipulated when Envoy forwards requests to, or responses from, a destination service. Header manipulation rules can be specified for a specific route destination or for all destinations. The following VirtualService adds a `test` header with the value `true` to requests that are routed to any `reviews` service destination. It also removes the `foo` response header, but only from responses coming from the `v1` subset (version) of the `reviews` service.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: reviews-route

spec: 

hosts:
- reviews.prod.svc.cluster.local
http:
- headers:
    request:
      set:
        test: "true"
  route:
  - destination:
      host: reviews.prod.svc.cluster.local
      subset: v2
    weight: 25
  - destination:
      host: reviews.prod.svc.cluster.local
      subset: v1
    headers:
      response:
        remove:
        - foo
    weight: 75

```

type Headers_HeaderOperations 

type Headers_HeaderOperations = v1alpha3.Headers_HeaderOperations

HeaderOperations Describes the header manipulations to apply

type IstioEgressListener 

type IstioEgressListener = v1alpha3.IstioEgressListener

`IstioEgressListener` specifies the properties of an outbound traffic listener on the sidecar proxy attached to a workload instance.

type IstioIngressListener 

type IstioIngressListener = v1alpha3.IstioIngressListener

`IstioIngressListener` specifies the properties of an inbound traffic listener on the sidecar proxy attached to a workload instance.

type L4MatchAttributes 

type L4MatchAttributes = v1alpha3.L4MatchAttributes

L4 connection match attributes. Note that L4 connection matching support is incomplete.

type LoadBalancerSettings 

type LoadBalancerSettings = v1alpha3.LoadBalancerSettings

Load balancing policies to apply for a specific destination. See Envoy's load balancing [documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing) for more details.

For example, the following rule uses a round robin load balancing policy for all traffic going to the ratings service.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: bookinfo-ratings

spec: 

host: ratings.prod.svc.cluster.local
trafficPolicy:
  loadBalancer:
    simple: ROUND_ROBIN

```

The following example sets up sticky sessions for the ratings service hashing-based load balancer for the same ratings service using the the User cookie as the hash key.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: bookinfo-ratings

spec: 

host: ratings.prod.svc.cluster.local
trafficPolicy:
  loadBalancer:
    consistentHash:
      httpCookie:
        name: user
        ttl: 0s

```

type LoadBalancerSettings_ConsistentHash 

type LoadBalancerSettings_ConsistentHash = v1alpha3.LoadBalancerSettings_ConsistentHash

type LoadBalancerSettings_ConsistentHashLB 

type LoadBalancerSettings_ConsistentHashLB = v1alpha3.LoadBalancerSettings_ConsistentHashLB

Consistent Hash-based load balancing can be used to provide soft session affinity based on HTTP headers, cookies or other properties. The affinity to a particular destination host may be lost when one or more hosts are added/removed from the destination service.

Note: consistent hashing is less reliable at maintaining affinity than common "sticky sessions" implementations, which often encode a specific destination in a cookie, ensuring affinity is maintained as long as the backend remains. With consistent hash, the guarantees are weaker; any host addition or removal can break affinity for `1/backends` requests.

Warning: consistent hashing depends on each proxy having a consistent view of endpoints. This is not the case when locality load balancing is enabled. Locality load balancing and consistent hash will only work together when all proxies are in the same locality, or a high level load balancer handles locality affinity.

type LoadBalancerSettings_ConsistentHashLB_HTTPCookie 

type LoadBalancerSettings_ConsistentHashLB_HTTPCookie = v1alpha3.LoadBalancerSettings_ConsistentHashLB_HTTPCookie

Describes a HTTP cookie that will be used as the hash key for the Consistent Hash load balancer.

type LoadBalancerSettings_ConsistentHashLB_HttpCookie 

type LoadBalancerSettings_ConsistentHashLB_HttpCookie = v1alpha3.LoadBalancerSettings_ConsistentHashLB_HttpCookie

Hash based on HTTP cookie.

type LoadBalancerSettings_ConsistentHashLB_HttpHeaderName 

type LoadBalancerSettings_ConsistentHashLB_HttpHeaderName = v1alpha3.LoadBalancerSettings_ConsistentHashLB_HttpHeaderName

Hash based on a specific HTTP header.

type LoadBalancerSettings_ConsistentHashLB_HttpQueryParameterName 

type LoadBalancerSettings_ConsistentHashLB_HttpQueryParameterName = v1alpha3.LoadBalancerSettings_ConsistentHashLB_HttpQueryParameterName

Hash based on a specific HTTP query parameter.

type LoadBalancerSettings_ConsistentHashLB_MagLev 

type LoadBalancerSettings_ConsistentHashLB_MagLev = v1alpha3.LoadBalancerSettings_ConsistentHashLB_MagLev

type LoadBalancerSettings_ConsistentHashLB_Maglev 

type LoadBalancerSettings_ConsistentHashLB_Maglev = v1alpha3.LoadBalancerSettings_ConsistentHashLB_Maglev

The Maglev load balancer implements consistent hashing to backend hosts.

type LoadBalancerSettings_ConsistentHashLB_RingHash 

type LoadBalancerSettings_ConsistentHashLB_RingHash = v1alpha3.LoadBalancerSettings_ConsistentHashLB_RingHash

type LoadBalancerSettings_ConsistentHashLB_RingHash_ 

type LoadBalancerSettings_ConsistentHashLB_RingHash_ = v1alpha3.LoadBalancerSettings_ConsistentHashLB_RingHash_

The ring/modulo hash load balancer implements consistent hashing to backend hosts.

type LoadBalancerSettings_ConsistentHashLB_UseSourceIp 

type LoadBalancerSettings_ConsistentHashLB_UseSourceIp = v1alpha3.LoadBalancerSettings_ConsistentHashLB_UseSourceIp

Hash based on the source IP address. This is applicable for both TCP and HTTP connections.

type LoadBalancerSettings_Simple 

type LoadBalancerSettings_Simple = v1alpha3.LoadBalancerSettings_Simple

type LoadBalancerSettings_SimpleLB 

type LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_SimpleLB

+kubebuilder:validation:XValidation:message="only one of warmupDurationSecs or warmup can be set",rule="(has(self.warmupDurationSecs)?1:0)+(has(self.warmup)?1:0)<=1" Standard load balancing algorithms that require no tuning. 

const LoadBalancerSettings_LEAST_CONN LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_LEAST_CONN

Deprecated. Use LEAST_REQUEST instead. 

const LoadBalancerSettings_LEAST_REQUEST LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_LEAST_REQUEST

The least request load balancer spreads load across endpoints, favoring endpoints with the least outstanding requests. This is generally safer and outperforms ROUND_ROBIN in nearly all cases. Prefer to use LEAST_REQUEST as a drop-in replacement for ROUND_ROBIN. 

const LoadBalancerSettings_PASSTHROUGH LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_PASSTHROUGH

This option will forward the connection to the original IP address requested by the caller without doing any form of load balancing. This option must be used with care. It is meant for advanced use cases. Refer to Original Destination load balancer in Envoy for further details. 

const LoadBalancerSettings_RANDOM LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_RANDOM

The random load balancer selects a random healthy host. The random load balancer generally performs better than round robin if no health checking policy is configured. 

const LoadBalancerSettings_ROUND_ROBIN LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_ROUND_ROBIN

A basic round robin load balancing policy. This is generally unsafe for many scenarios (e.g. when endpoint weighting is used) as it can overburden endpoints. In general, prefer to use LEAST_REQUEST as a drop-in replacement for ROUND_ROBIN. 

const LoadBalancerSettings_UNSPECIFIED LoadBalancerSettings_SimpleLB = v1alpha3.LoadBalancerSettings_UNSPECIFIED

No load balancing algorithm has been specified by the user. Istio will select an appropriate default.

type LocalityLoadBalancerSetting 

type LocalityLoadBalancerSetting = v1alpha3.LocalityLoadBalancerSetting

Locality-weighted load balancing allows administrators to control the distribution of traffic to endpoints based on the localities of where the traffic originates and where it will terminate. These localities are specified using arbitrary labels that designate a hierarchy of localities in {region}/{zone}/{sub-zone} form. For additional detail refer to [Locality Weight](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight) The following example shows how to setup locality weights mesh-wide.

Given a mesh with workloads and their service deployed to "us-west/zone1/*" and "us-west/zone2/*". This example specifies that when traffic accessing a service originates from workloads in "us-west/zone1/*", 80% of the traffic will be sent to endpoints in "us-west/zone1/*", i.e the same zone, and the remaining 20% will go to endpoints in "us-west/zone2/*". This setup is intended to favor routing traffic to endpoints in the same locality. A similar setting is specified for traffic originating in "us-west/zone2/*".

```yaml 

distribute:
  - from: us-west/zone1/*
    to:
      "us-west/zone1/*": 80
      "us-west/zone2/*": 20
  - from: us-west/zone2/*
    to:
      "us-west/zone1/*": 20
      "us-west/zone2/*": 80

```

If the goal of the operator is not to distribute load across zones and regions but rather to restrict the regionality of failover to meet other operational requirements an operator can set a 'failover' policy instead of a 'distribute' policy.

The following example sets up a locality failover policy for regions. Assume a service resides in zones within us-east, us-west & eu-west this example specifies that when endpoints within us-east become unhealthy traffic should failover to endpoints in any zone or sub-zone within eu-west and similarly us-west should failover to us-east.

```yaml 

failover:
  - from: us-east
    to: eu-west
  - from: us-west
    to: us-east

``` Locality load balancing settings.

type LocalityLoadBalancerSetting_Distribute 

type LocalityLoadBalancerSetting_Distribute = v1alpha3.LocalityLoadBalancerSetting_Distribute

Describes how traffic originating in the 'from' zone or sub-zone is distributed over a set of 'to' zones. Syntax for specifying a zone is {region}/{zone}/{sub-zone} and terminal wildcards are allowed on any segment of the specification. Examples:

`*` - matches all localities

`us-west/*` - all zones and sub-zones within the us-west region

`us-west/zone-1/*` - all sub-zones within us-west/zone-1

type LocalityLoadBalancerSetting_Failover 

type LocalityLoadBalancerSetting_Failover = v1alpha3.LocalityLoadBalancerSetting_Failover

Specify the traffic failover policy across regions. Since zone and sub-zone failover is supported by default this only needs to be specified for regions when the operator needs to constrain traffic failover so that the default behavior of failing over to any endpoint globally does not apply. This is useful when failing over traffic across regions would not improve service health or may need to be restricted for other reasons like regulatory controls.

type OutboundTrafficPolicy 

type OutboundTrafficPolicy = v1alpha3.OutboundTrafficPolicy

`OutboundTrafficPolicy` sets the default behavior of the sidecar for handling unknown outbound traffic from the application.

type OutboundTrafficPolicy_Mode 

type OutboundTrafficPolicy_Mode = v1alpha3.OutboundTrafficPolicy_Mode
const OutboundTrafficPolicy_ALLOW_ANY OutboundTrafficPolicy_Mode = v1alpha3.OutboundTrafficPolicy_ALLOW_ANY

In `ALLOW_ANY` mode, any traffic to unknown destinations will be allowed. Unknown destination traffic will have limited functionality, however, such as reduced observability. This mode allows users that do not have all possible egress destinations registered through `ServiceEntry` configurations to still connect to arbitrary destinations. 

const OutboundTrafficPolicy_REGISTRY_ONLY OutboundTrafficPolicy_Mode = v1alpha3.OutboundTrafficPolicy_REGISTRY_ONLY

In `REGISTRY_ONLY` mode, unknown outbound traffic will be dropped. Traffic destinations must be explicitly declared into the service registry through `ServiceEntry` configurations.

Note: Istio [does not offer an outbound traffic security policy](https://istio.io/latest/docs/ops/best-practices/security/#understand-traffic-capture-limitations). This option does not act as one, or as any form of an outbound firewall. Instead, this option exists primarily to offer users a way to detect missing `ServiceEntry` configurations by explicitly failing.

type OutlierDetection 

type OutlierDetection = v1alpha3.OutlierDetection

A Circuit breaker implementation that tracks the status of each individual host in the upstream service. Applicable to both HTTP and TCP services. For HTTP services, hosts that continually return 5xx errors for API calls are ejected from the pool for a pre-defined period of time. For TCP services, connection timeouts or connection failures to a given host counts as an error when measuring the consecutive errors metric. See Envoy's [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier) for more details.

The following rule sets a connection pool size of 100 HTTP1 connections with no more than 10 req/connection to the "reviews" service. In addition, it sets a limit of 1000 concurrent HTTP2 requests and configures upstream hosts to be scanned every 5 mins so that any host that fails 7 consecutive times with a 502, 503, or 504 error code will be ejected for 15 minutes.

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: reviews-cb-policy

spec: 

host: reviews.prod.svc.cluster.local
trafficPolicy:
  connectionPool:
    tcp:
      maxConnections: 100
    http:
      http2MaxRequests: 1000
      maxRequestsPerConnection: 10
  outlierDetection:
    consecutive5xxErrors: 7
    interval: 5m
    baseEjectionTime: 15m

```

type Percent 

type Percent = v1alpha3.Percent

Percent specifies a percentage in the range of [0.0, 100.0].

type Port 

type Port = v1alpha3.Port

Port describes the properties of a specific port of a service.

type PortSelector 

type PortSelector = v1alpha3.PortSelector

PortSelector specifies the number of a port to be used for matching or selection for final routing.

type ReadinessProbe 

type ReadinessProbe = v1alpha3.ReadinessProbe

type ReadinessProbe_Exec 

type ReadinessProbe_Exec = v1alpha3.ReadinessProbe_Exec

Health is determined by how the command that is executed exited.

type ReadinessProbe_HttpGet 

type ReadinessProbe_HttpGet = v1alpha3.ReadinessProbe_HttpGet

`httpGet` is performed to a given endpoint and the status/able to connect determines health.

type ReadinessProbe_TcpSocket 

type ReadinessProbe_TcpSocket = v1alpha3.ReadinessProbe_TcpSocket

Health is determined by if the proxy is able to connect.

type RegexRewrite 

type RegexRewrite = v1alpha3.RegexRewrite

type RouteDestination 

type RouteDestination = v1alpha3.RouteDestination

L4 routing rule weighted destination.

type Server 

type Server = v1alpha3.Server

`Server` describes the properties of the proxy on a given load balancer port. For example,

```yaml apiVersion: networking.istio.io/v1 kind: Gateway metadata: 

name: my-ingress

spec: 

selector:
  app: my-ingressgateway
servers:
- port:
    number: 80
    name: http2
    protocol: HTTP2
  hosts:
  - "*"

```

Another example

```yaml apiVersion: networking.istio.io/v1 kind: Gateway metadata: 

name: my-tcp-ingress

spec: 

selector:
  app: my-tcp-ingressgateway
servers:
- port:
    number: 27018
    name: mongo
    protocol: MONGO
  hosts:
  - "*"

```

The following is an example of TLS configuration for port 443

```yaml apiVersion: networking.istio.io/v1 kind: Gateway metadata: 

name: my-tls-ingress

spec: 

selector:
  app: my-tls-ingressgateway
servers:
- port:
    number: 443
    name: https
    protocol: HTTPS
  hosts:
  - "*"
  tls:
    mode: SIMPLE
    credentialName: tls-cert

```

type ServerTLSSettings 

type ServerTLSSettings = v1alpha3.ServerTLSSettings

type ServerTLSSettings_TLSProtocol 

type ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLSProtocol

TLS protocol versions. 

const ServerTLSSettings_TLSV1_0 ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLSV1_0

TLS version 1.0 

const ServerTLSSettings_TLSV1_1 ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLSV1_1

TLS version 1.1 

const ServerTLSSettings_TLSV1_2 ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLSV1_2

TLS version 1.2 

const ServerTLSSettings_TLSV1_3 ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLSV1_3

TLS version 1.3 

const ServerTLSSettings_TLS_AUTO ServerTLSSettings_TLSProtocol = v1alpha3.ServerTLSSettings_TLS_AUTO

Automatically choose the optimal TLS version.

type ServerTLSSettings_TLSmode 

type ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_TLSmode

TLS modes enforced by the proxy 

const ServerTLSSettings_AUTO_PASSTHROUGH ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_AUTO_PASSTHROUGH

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. 

const ServerTLSSettings_ISTIO_MUTUAL ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_ISTIO_MUTUAL

Secure connections from the downstream using mutual TLS by presenting server certificates for authentication. Compared to Mutual mode, this mode uses certificates, representing gateway workload identity, generated automatically by Istio for mTLS authentication. When this mode is used, all other fields in `TLSOptions` should be empty. 

const ServerTLSSettings_MUTUAL ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_MUTUAL

Secure connections to the downstream using mutual TLS by presenting server certificates for authentication. A client certificate will also be requested during the handshake and at least one valid certificate is required to be sent by the client. 

const ServerTLSSettings_OPTIONAL_MUTUAL ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_OPTIONAL_MUTUAL

Similar to MUTUAL mode, except that the client certificate is optional. Unlike SIMPLE mode, A client certificate will still be explicitly requested during handshake, but the client is not required to send a certificate. If a client certificate is presented, it will be validated. ca_certificates should be specified for validating client certificates. 

const ServerTLSSettings_PASSTHROUGH ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_PASSTHROUGH

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. 

const ServerTLSSettings_SIMPLE ServerTLSSettings_TLSmode = v1alpha3.ServerTLSSettings_SIMPLE

Secure connections with standard TLS semantics. In this mode client certificate is not requested during handshake.

type ServiceEntry 

type ServiceEntry = v1alpha3.ServiceEntry

ServiceEntry enables adding additional entries into Istio's internal service registry.

<!-- crd generation tags +cue-gen:ServiceEntry:groupName:networking.istio.io +cue-gen:ServiceEntry:versions:v1beta1,v1alpha3,v1 +cue-gen:ServiceEntry:annotations:helm.sh/resource-policy=keep +cue-gen:ServiceEntry:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:ServiceEntry:subresource:status +cue-gen:ServiceEntry:scope:Namespaced +cue-gen:ServiceEntry:resource:categories=istio-io,networking-istio-io,shortNames=se,plural=serviceentries +cue-gen:ServiceEntry:printerColumn:name=Hosts,type=string,JSONPath=.spec.hosts,description="The hosts associated with the ServiceEntry" +cue-gen:ServiceEntry:printerColumn:name=Location,type=string,JSONPath=.spec.location,description="Whether the service is external to the mesh or part of the mesh (MESH_EXTERNAL or MESH_INTERNAL)" +cue-gen:ServiceEntry:printerColumn:name=Resolution,type=string,JSONPath=.spec.resolution,description="Service resolution mode for the hosts (NONE, STATIC, or DNS)" +cue-gen:ServiceEntry:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" +cue-gen:ServiceEntry:preserveUnknownFields:false +cue-gen:ServiceEntry:spec:required -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true istiostatus-override: ServiceEntryStatus: istio.io/api/networking/v1alpha3 --> +kubebuilder:validation:XValidation:message="only one of WorkloadSelector or Endpoints can be set",rule="(has(self.workloadSelector)?1:0)+(has(self.endpoints)?1:0)<=1" +kubebuilder:validation:XValidation:message="CIDR addresses are allowed only for NONE/STATIC resolution types",rule="!(has(self.addresses) && self.addresses.exists(k, k.contains('/')) && (has(self.resolution) && self.resolution != 'STATIC' && self.resolution != 'NONE'))" +kubebuilder:validation:XValidation:message="NONE mode cannot set endpoints",rule="(!has(self.resolution) || self.resolution == 'NONE') ? !has(self.endpoints) : true" +kubebuilder:validation:XValidation:message="DNS_ROUND_ROBIN mode cannot have multiple endpoints",rule="(has(self.resolution) && self.resolution == 'DNS_ROUND_ROBIN') ? (!has(self.endpoints) || size(self.endpoints) == 1) : true"

type ServiceEntryAddress added in v1.23.0 

type ServiceEntryAddress = v1alpha3.ServiceEntryAddress

minor abstraction to allow for adding hostnames if relevant

type ServiceEntryStatus added in v1.23.0 

type ServiceEntryStatus = v1alpha3.ServiceEntryStatus

type ServiceEntry_Location 

type ServiceEntry_Location = v1alpha3.ServiceEntry_Location

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's mTLS authentication is disabled, and policy enforcement is performed on the client-side as opposed to server-side. 

const ServiceEntry_MESH_EXTERNAL ServiceEntry_Location = v1alpha3.ServiceEntry_MESH_EXTERNAL

Signifies that the service is external to the mesh. Typically used to indicate external services consumed through APIs. 

const ServiceEntry_MESH_INTERNAL ServiceEntry_Location = v1alpha3.ServiceEntry_MESH_INTERNAL

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).

type ServiceEntry_Resolution 

type ServiceEntry_Resolution = v1alpha3.ServiceEntry_Resolution

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. 

const ServiceEntry_DNS ServiceEntry_Resolution = v1alpha3.ServiceEntry_DNS

Attempt to resolve the IP address by querying the ambient DNS, asynchronously. 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. 

const ServiceEntry_DNS_ROUND_ROBIN ServiceEntry_Resolution = v1alpha3.ServiceEntry_DNS_ROUND_ROBIN

Attempt to resolve the IP address by querying the ambient DNS, asynchronously. Unlike `DNS`, `DNS_ROUND_ROBIN` only uses the first IP address returned when a new connection needs to be initiated without relying on complete results of DNS resolution, and connections made to hosts will be retained even if DNS records change frequently eliminating draining connection pools and connection cycling. This is best suited for large web scale services that must be accessed via DNS. The proxy will resolve the DNS address specified in the hosts field, if wildcards are not used. DNS resolution cannot be used with Unix domain socket endpoints. 

const ServiceEntry_NONE ServiceEntry_Resolution = v1alpha3.ServiceEntry_NONE

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. 

const ServiceEntry_STATIC ServiceEntry_Resolution = v1alpha3.ServiceEntry_STATIC

Use the static IP addresses specified in endpoints (see below) as the backing instances associated with the service.

type ServicePort 

type ServicePort = v1alpha3.ServicePort

ServicePort describes the properties of a specific port of a service.

type Sidecar 

type Sidecar = v1alpha3.Sidecar

`Sidecar` describes the configuration of the sidecar proxy that mediates inbound and outbound communication of the workload instance to which it is attached.

<!-- crd generation tags +cue-gen:Sidecar:groupName:networking.istio.io +cue-gen:Sidecar:versions:v1beta1,v1alpha3,v1 +cue-gen:Sidecar:annotations:helm.sh/resource-policy=keep +cue-gen:Sidecar:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:Sidecar:subresource:status +cue-gen:Sidecar:scope:Namespaced +cue-gen:Sidecar:resource:categories=istio-io,networking-istio-io +cue-gen:Sidecar:preserveUnknownFields:false -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true -->

type SidecarPort 

type SidecarPort = v1alpha3.SidecarPort

Port describes the properties of a specific port of a service.

type StringMatch 

type StringMatch = v1alpha3.StringMatch

Describes how to match a given string in HTTP headers. `exact` and `prefix` matching is case-sensitive. `regex` matching supports case-insensitive matches.

type StringMatch_Exact 

type StringMatch_Exact = v1alpha3.StringMatch_Exact

exact string match

type StringMatch_Prefix 

type StringMatch_Prefix = v1alpha3.StringMatch_Prefix

prefix-based match

type StringMatch_Regex 

type StringMatch_Regex = v1alpha3.StringMatch_Regex

[RE2 style regex-based match](https://github.com/google/re2/wiki/Syntax).

Example: `(?i)^aaa$` can be used to case-insensitive match a string consisting of three a's.

type Subset 

type Subset = v1alpha3.Subset

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(https://istio.io/docs/reference/config/networking/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 subset named testversion that is composed of endpoints (e.g., pods) with labels (version:v3).

```yaml apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: 

name: bookinfo-ratings

spec: 

host: ratings.prod.svc.cluster.local
trafficPolicy:
  loadBalancer:
    simple: LEAST_REQUEST
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.

One or more labels are typically required to identify the subset destination, however, when the corresponding DestinationRule represents a host that supports multiple SNI hosts (e.g., an egress gateway), a subset without labels may be meaningful. In this case a traffic policy with ClientTLSSettings(#ClientTLSSettings) can be used to identify a specific SNI host corresponding to the named subset.

type TCPHealthCheckConfig 

type TCPHealthCheckConfig = v1alpha3.TCPHealthCheckConfig

type TCPRoute 

type TCPRoute = v1alpha3.TCPRoute

Describes match conditions and actions for routing TCP traffic. The following routing rule forwards traffic arriving at port 27017 for mongo.prod.svc.cluster.local to another Mongo server on port 5555.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: bookinfo-mongo

spec: 

hosts:
- mongo.prod.svc.cluster.local
tcp:
- match:
  - port: 27017
  route:
  - destination:
      host: mongo.backup.svc.cluster.local
      port:
        number: 5555

```

type TLSMatchAttributes 

type TLSMatchAttributes = v1alpha3.TLSMatchAttributes

TLS connection match attributes.

type TLSRoute 

type TLSRoute = v1alpha3.TLSRoute

Describes match conditions and actions for routing unterminated TLS traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS traffic arriving at port 443 of gateway called "mygateway" to internal services in the mesh based on the SNI value.

```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: 

name: bookinfo-sni

spec: 

hosts:
- "*.bookinfo.com"
gateways:
- mygateway
tls:
- match:
  - port: 443
    sniHosts:
    - login.bookinfo.com
  route:
  - destination:
      host: login.prod.svc.cluster.local
- match:
  - port: 443
    sniHosts:
    - reviews.bookinfo.com
  route:
  - destination:
      host: reviews.prod.svc.cluster.local

```

type TrafficPolicy 

type TrafficPolicy = v1alpha3.TrafficPolicy

Traffic policies to apply for a specific destination, across all destination ports. See DestinationRule for examples.

type TrafficPolicy_PortTrafficPolicy 

type TrafficPolicy_PortTrafficPolicy = v1alpha3.TrafficPolicy_PortTrafficPolicy

Traffic policies that apply to specific ports of the service

type TrafficPolicy_ProxyProtocol 

type TrafficPolicy_ProxyProtocol = v1alpha3.TrafficPolicy_ProxyProtocol

type TrafficPolicy_ProxyProtocol_VERSION 

type TrafficPolicy_ProxyProtocol_VERSION = v1alpha3.TrafficPolicy_ProxyProtocol_VERSION
const TrafficPolicy_ProxyProtocol_V1 TrafficPolicy_ProxyProtocol_VERSION = v1alpha3.TrafficPolicy_ProxyProtocol_V1

⁣PROXY protocol version 1. Human readable format. 

const TrafficPolicy_ProxyProtocol_V2 TrafficPolicy_ProxyProtocol_VERSION = v1alpha3.TrafficPolicy_ProxyProtocol_V2

⁣PROXY protocol version 2. Binary format.

type TrafficPolicy_TunnelSettings 

type TrafficPolicy_TunnelSettings = v1alpha3.TrafficPolicy_TunnelSettings

type VirtualService 

type VirtualService = v1alpha3.VirtualService

Configuration affecting traffic routing.

<!-- crd generation tags +cue-gen:VirtualService:groupName:networking.istio.io +cue-gen:VirtualService:versions:v1beta1,v1alpha3,v1 +cue-gen:VirtualService:annotations:helm.sh/resource-policy=keep +cue-gen:VirtualService:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:VirtualService:subresource:status +cue-gen:VirtualService:scope:Namespaced +cue-gen:VirtualService:resource:categories=istio-io,networking-istio-io,shortNames=vs +cue-gen:VirtualService:printerColumn:name=Gateways,type=string,JSONPath=.spec.gateways,description="The names of gateways and sidecars that should apply these routes" +cue-gen:VirtualService:printerColumn:name=Hosts,type=string,JSONPath=.spec.hosts,description="The destination hosts to which traffic is being sent" +cue-gen:VirtualService:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" +cue-gen:VirtualService:preserveUnknownFields:false -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true -->

type WarmupConfiguration added in v1.24.0 

type WarmupConfiguration = v1alpha3.WarmupConfiguration

type WorkloadEntry 

type WorkloadEntry = v1alpha3.WorkloadEntry

WorkloadEntry enables specifying the properties of a single non-Kubernetes workload such a VM or a bare metal services that can be referred to by service entries.

<!-- crd generation tags +cue-gen:WorkloadEntry:groupName:networking.istio.io +cue-gen:WorkloadEntry:versions:v1beta1,v1alpha3,v1 +cue-gen:WorkloadEntry:annotations:helm.sh/resource-policy=keep +cue-gen:WorkloadEntry:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:WorkloadEntry:subresource:status +cue-gen:WorkloadEntry:scope:Namespaced +cue-gen:WorkloadEntry:resource:categories=istio-io,networking-istio-io,shortNames=we,plural=workloadentries +cue-gen:WorkloadEntry:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" +cue-gen:WorkloadEntry:printerColumn:name=Address,type=string,JSONPath=.spec.address,description="Address associated with the network endpoint." +cue-gen:WorkloadEntry:preserveUnknownFields:false +cue-gen:WorkloadEntry:spec:required -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true --> +kubebuilder:validation:XValidation:message="Address is required",rule="has(self.address) || has(self.network)" +kubebuilder:validation:XValidation:message="UDS may not include ports",rule="(has(self.address) && self.address.startsWith('unix://')) ? !has(self.ports) : true"

type WorkloadGroup 

type WorkloadGroup = v1alpha3.WorkloadGroup

`WorkloadGroup` enables specifying the properties of a single workload for bootstrap and provides a template for `WorkloadEntry`, similar to how `Deployment` specifies properties of workloads via `Pod` templates. A `WorkloadGroup` can have more than one `WorkloadEntry`. `WorkloadGroup` has no relationship to resources which control service registry like `ServiceEntry` and as such doesn't configure host name for these workloads.

<!-- crd generation tags +cue-gen:WorkloadGroup:groupName:networking.istio.io +cue-gen:WorkloadGroup:versions:v1beta1,v1alpha3,v1 +cue-gen:WorkloadGroup:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:WorkloadGroup:subresource:status +cue-gen:WorkloadGroup:scope:Namespaced +cue-gen:WorkloadGroup:resource:categories=istio-io,networking-istio-io,shortNames=wg,plural=workloadgroups +cue-gen:WorkloadGroup:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" +cue-gen:WorkloadGroup:preserveUnknownFields:false +cue-gen:WorkloadGroup:spec:required -->

<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1alpha3 +genclient +k8s:deepcopy-gen=true -->

type WorkloadGroup_ObjectMeta 

type WorkloadGroup_ObjectMeta = v1alpha3.WorkloadGroup_ObjectMeta

`ObjectMeta` describes metadata that will be attached to a `WorkloadEntry`. It is a subset of the supported Kubernetes metadata.

type WorkloadSelector 

type WorkloadSelector = v1alpha3.WorkloadSelector

`WorkloadSelector` specifies the criteria used to determine if the `Gateway`, `Sidecar`, `EnvoyFilter`, `ServiceEntry`, or `DestinationRule` configuration can be applied to a proxy. The matching criteria includes the metadata associated with a proxy, workload instance 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 instance to be selected. Currently, only label based selection mechanism is supported.

Source Files

View all Source files

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.