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-deepcopy. DO NOT EDIT.
Code generated by protoc-gen-jsonshim. 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 ¶
- Variables
- type CaptureMode
- type ClientTLSSettings
- type ClientTLSSettings_TLSmode
- type ConnectionPoolSettings
- type ConnectionPoolSettings_HTTPSettings
- type ConnectionPoolSettings_HTTPSettings_H2UpgradePolicy
- type ConnectionPoolSettings_TCPSettings
- type ConnectionPoolSettings_TCPSettings_TcpKeepalive
- type CorsPolicy
- type CorsPolicy_UnmatchedPreflights
- type Delegate
- type Destination
- type DestinationRule
- type ExecHealthCheckConfig
- type Gateway
- type HTTPBody
- type HTTPBody_Bytes
- type HTTPBody_String_
- type HTTPDirectResponse
- type HTTPFaultInjection
- type HTTPFaultInjection_Abort
- type HTTPFaultInjection_Abort_GrpcStatus
- type HTTPFaultInjection_Abort_Http2Error
- type HTTPFaultInjection_Abort_HttpStatus
- type HTTPFaultInjection_Delay
- type HTTPFaultInjection_Delay_ExponentialDelay
- type HTTPFaultInjection_Delay_FixedDelay
- type HTTPHeader
- type HTTPHealthCheckConfig
- type HTTPMatchRequest
- type HTTPMirrorPolicy
- type HTTPRedirect
- type HTTPRedirect_DerivePort
- type HTTPRedirect_Port
- type HTTPRedirect_RedirectPortSelection
- type HTTPRetry
- type HTTPRewrite
- type HTTPRoute
- type HTTPRouteDestination
- type Headers
- type Headers_HeaderOperations
- type IstioEgressListener
- type IstioIngressListener
- type L4MatchAttributes
- type LoadBalancerSettings
- type LoadBalancerSettings_ConsistentHash
- type LoadBalancerSettings_ConsistentHashLB
- type LoadBalancerSettings_ConsistentHashLB_HTTPCookie
- type LoadBalancerSettings_ConsistentHashLB_HttpCookie
- type LoadBalancerSettings_ConsistentHashLB_HttpHeaderName
- type LoadBalancerSettings_ConsistentHashLB_HttpQueryParameterName
- type LoadBalancerSettings_ConsistentHashLB_MagLev
- type LoadBalancerSettings_ConsistentHashLB_Maglev
- type LoadBalancerSettings_ConsistentHashLB_RingHash
- type LoadBalancerSettings_ConsistentHashLB_RingHash_
- type LoadBalancerSettings_ConsistentHashLB_UseSourceIp
- type LoadBalancerSettings_Simple
- type LoadBalancerSettings_SimpleLB
- type LocalityLoadBalancerSetting
- type LocalityLoadBalancerSetting_Distribute
- type LocalityLoadBalancerSetting_Failover
- type OutboundTrafficPolicy
- type OutboundTrafficPolicy_Mode
- type OutlierDetection
- type Percent
- type Port
- type PortSelector
- type ProxyConfig
- func (in *ProxyConfig) DeepCopy() *ProxyConfig
- func (in *ProxyConfig) DeepCopyInterface() interface{}
- func (in *ProxyConfig) DeepCopyInto(out *ProxyConfig)
- func (*ProxyConfig) Descriptor() ([]byte, []int)deprecated
- func (x *ProxyConfig) GetConcurrency() *wrappers.Int32Value
- func (x *ProxyConfig) GetEnvironmentVariables() map[string]string
- func (x *ProxyConfig) GetImage() *ProxyImage
- func (x *ProxyConfig) GetSelector() *v1beta1.WorkloadSelector
- func (this *ProxyConfig) MarshalJSON() ([]byte, error)
- func (*ProxyConfig) ProtoMessage()
- func (x *ProxyConfig) ProtoReflect() protoreflect.Message
- func (x *ProxyConfig) Reset()
- func (x *ProxyConfig) String() string
- func (this *ProxyConfig) UnmarshalJSON(b []byte) error
- type ProxyImage
- func (in *ProxyImage) DeepCopy() *ProxyImage
- func (in *ProxyImage) DeepCopyInterface() interface{}
- func (in *ProxyImage) DeepCopyInto(out *ProxyImage)
- func (*ProxyImage) Descriptor() ([]byte, []int)deprecated
- func (x *ProxyImage) GetImageType() string
- func (this *ProxyImage) MarshalJSON() ([]byte, error)
- func (*ProxyImage) ProtoMessage()
- func (x *ProxyImage) ProtoReflect() protoreflect.Message
- func (x *ProxyImage) Reset()
- func (x *ProxyImage) String() string
- func (this *ProxyImage) UnmarshalJSON(b []byte) error
- type ReadinessProbe
- type ReadinessProbe_Exec
- type ReadinessProbe_HttpGet
- type ReadinessProbe_TcpSocket
- type RegexRewrite
- type RouteDestination
- type Server
- type ServerTLSSettings
- type ServerTLSSettings_TLSProtocol
- type ServerTLSSettings_TLSmode
- type ServiceEntry
- type ServiceEntryAddress
- type ServiceEntryStatus
- type ServiceEntry_Location
- type ServiceEntry_Resolution
- type ServicePort
- type Sidecar
- type SidecarPort
- type StringMatch
- type StringMatch_Exact
- type StringMatch_Prefix
- type StringMatch_Regex
- type Subset
- type TCPHealthCheckConfig
- type TCPRoute
- type TLSMatchAttributes
- type TLSRoute
- type TrafficPolicy
- type TrafficPolicy_PortTrafficPolicy
- type TrafficPolicy_ProxyProtocol
- type TrafficPolicy_ProxyProtocol_VERSION
- type TrafficPolicy_TunnelSettings
- type VirtualService
- type WarmupConfiguration
- type WorkloadEntry
- type WorkloadGroup
- type WorkloadGroup_ObjectMeta
- type WorkloadSelector
Constants ¶
This section is empty.
Variables ¶
var ( ProxyConfigMarshaler = &jsonpb.Marshaler{} ProxyConfigUnmarshaler = &jsonpb.Unmarshaler{AllowUnknownFields: true} )
var File_networking_v1beta1_proxy_config_proto protoreflect.FileDescriptor
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 ¶
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 ¶
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_Bytes ¶
type HTTPBody_Bytes = v1alpha3.HTTPBody_Bytes
response body as base64 encoded bytes.
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 ¶
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 ¶
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 ¶
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 PortSelector ¶
type PortSelector = v1alpha3.PortSelector
PortSelector specifies the number of a port to be used for matching or selection for final routing.
type ProxyConfig ¶
type ProxyConfig struct { // Optional. Selectors specify the set of pods/VMs on which this `ProxyConfig` resource should be applied. // If not set, the `ProxyConfig` resource will be applied to all workloads in the namespace where this resource is defined. Selector *v1beta1.WorkloadSelector `protobuf:"bytes,1,opt,name=selector,proto3" json:"selector,omitempty"` // The number of worker threads to run. // If unset, this will be automatically determined based on CPU limits. // If set to 0, all cores on the machine will be used. // +kubebuilder:validation:Minimum=0 Concurrency *wrappers.Int32Value `protobuf:"bytes,2,opt,name=concurrency,proto3" json:"concurrency,omitempty"` // Additional environment variables for the proxy. // Names starting with `ISTIO_META_` will be included in the generated bootstrap configuration and sent to the XDS server. // +protoc-gen-crd:map-value-validation:MaxLength=2048 EnvironmentVariables map[string]string `` /* 209-byte string literal not displayed */ // Specifies the details of the proxy image. Image *ProxyImage `protobuf:"bytes,4,opt,name=image,proto3" json:"image,omitempty"` // contains filtered or unexported fields }
`ProxyConfig` exposes proxy level configuration options.
<!-- crd generation tags +cue-gen:ProxyConfig:groupName:networking.istio.io +cue-gen:ProxyConfig:versions:v1beta1 +cue-gen:ProxyConfig:storageVersion +cue-gen:ProxyConfig:annotations:helm.sh/resource-policy=keep +cue-gen:ProxyConfig:labels:app=istio-pilot,chart=istio,heritage=Tiller,release=istio +cue-gen:ProxyConfig:subresource:status +cue-gen:ProxyConfig:scope:Namespaced +cue-gen:WasmPlugin:releaseChannel:extended +cue-gen:ProxyConfig:resource:categories=istio-io,networking-istio-io,plural=proxyconfigs +cue-gen:ProxyConfig:preserveUnknownFields:false -->
<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=networking.istio.io/v1beta1 +genclient +k8s:deepcopy-gen=true -->
func (*ProxyConfig) DeepCopy ¶
func (in *ProxyConfig) DeepCopy() *ProxyConfig
DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ProxyConfig. Required by controller-gen.
func (*ProxyConfig) DeepCopyInterface ¶
func (in *ProxyConfig) DeepCopyInterface() interface{}
DeepCopyInterface is an autogenerated deepcopy function, copying the receiver, creating a new ProxyConfig. Required by controller-gen.
func (*ProxyConfig) DeepCopyInto ¶
func (in *ProxyConfig) DeepCopyInto(out *ProxyConfig)
DeepCopyInto supports using ProxyConfig within kubernetes types, where deepcopy-gen is used.
func (*ProxyConfig) Descriptor
deprecated
func (*ProxyConfig) Descriptor() ([]byte, []int)
Deprecated: Use ProxyConfig.ProtoReflect.Descriptor instead.
func (*ProxyConfig) GetConcurrency ¶
func (x *ProxyConfig) GetConcurrency() *wrappers.Int32Value
func (*ProxyConfig) GetEnvironmentVariables ¶
func (x *ProxyConfig) GetEnvironmentVariables() map[string]string
func (*ProxyConfig) GetImage ¶
func (x *ProxyConfig) GetImage() *ProxyImage
func (*ProxyConfig) GetSelector ¶
func (x *ProxyConfig) GetSelector() *v1beta1.WorkloadSelector
func (*ProxyConfig) MarshalJSON ¶
func (this *ProxyConfig) MarshalJSON() ([]byte, error)
MarshalJSON is a custom marshaler for ProxyConfig
func (*ProxyConfig) ProtoMessage ¶
func (*ProxyConfig) ProtoMessage()
func (*ProxyConfig) ProtoReflect ¶
func (x *ProxyConfig) ProtoReflect() protoreflect.Message
func (*ProxyConfig) Reset ¶
func (x *ProxyConfig) Reset()
func (*ProxyConfig) String ¶
func (x *ProxyConfig) String() string
func (*ProxyConfig) UnmarshalJSON ¶
func (this *ProxyConfig) UnmarshalJSON(b []byte) error
UnmarshalJSON is a custom unmarshaler for ProxyConfig
type ProxyImage ¶
type ProxyImage struct { // The image type of the image. // Istio publishes default, debug, and distroless images. // Other values are allowed if those image types (example: centos) are published to the specified hub. // supported values: default, debug, distroless. ImageType string `protobuf:"bytes,1,opt,name=image_type,json=imageType,proto3" json:"image_type,omitempty"` // contains filtered or unexported fields }
The following values are used to construct proxy image url. format: `${hub}/${image_name}/${tag}-${image_type}`, example: `docker.io/istio/proxyv2:1.11.1` or `docker.io/istio/proxyv2:1.11.1-distroless`. This information was previously part of the Values API.
func (*ProxyImage) DeepCopy ¶
func (in *ProxyImage) DeepCopy() *ProxyImage
DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ProxyImage. Required by controller-gen.
func (*ProxyImage) DeepCopyInterface ¶
func (in *ProxyImage) DeepCopyInterface() interface{}
DeepCopyInterface is an autogenerated deepcopy function, copying the receiver, creating a new ProxyImage. Required by controller-gen.
func (*ProxyImage) DeepCopyInto ¶
func (in *ProxyImage) DeepCopyInto(out *ProxyImage)
DeepCopyInto supports using ProxyImage within kubernetes types, where deepcopy-gen is used.
func (*ProxyImage) Descriptor
deprecated
func (*ProxyImage) Descriptor() ([]byte, []int)
Deprecated: Use ProxyImage.ProtoReflect.Descriptor instead.
func (*ProxyImage) GetImageType ¶
func (x *ProxyImage) GetImageType() string
func (*ProxyImage) MarshalJSON ¶
func (this *ProxyImage) MarshalJSON() ([]byte, error)
MarshalJSON is a custom marshaler for ProxyImage
func (*ProxyImage) ProtoMessage ¶
func (*ProxyImage) ProtoMessage()
func (*ProxyImage) ProtoReflect ¶
func (x *ProxyImage) ProtoReflect() protoreflect.Message
func (*ProxyImage) Reset ¶
func (x *ProxyImage) Reset()
func (*ProxyImage) String ¶
func (x *ProxyImage) String() string
func (*ProxyImage) UnmarshalJSON ¶
func (this *ProxyImage) UnmarshalJSON(b []byte) error
UnmarshalJSON is a custom unmarshaler for ProxyImage
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 ¶
`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 ¶
`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 ¶ added in v1.20.0
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_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 ¶
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 ¶
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 ¶
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 ¶ added in v1.21.0
type TrafficPolicy_ProxyProtocol = v1alpha3.TrafficPolicy_ProxyProtocol
type TrafficPolicy_ProxyProtocol_VERSION ¶ added in v1.21.0
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.