admin/kubesphere
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update dependencies

Browse Source 
Signed-off-by: hongming <talonwan@yunify.com>
This commit is contained in:
hongming
2020-12-22 16:48:26 +08:00
parent 4a11a50544
commit fe6c5de00f
2857 changed files with 252134 additions and 115656 deletions
Download Patch File Download Diff File Expand all files Collapse all files

255
vendor/istio.io/api/networking/v1alpha3/sidecar_deepcopy.gen.go generated vendored
View File

@@ -22,23 +22,29 @@
// `workloadSelector` that selects this workload instance, over a `Sidecar` configuration
// without any `workloadSelector`.
//
// NOTE 1: *_Each namespace can have only one `Sidecar` configuration without any
// `workloadSelector`_*. The behavior of the system is undefined if more
// than one selector-less `Sidecar` configurations exist in a given namespace. The
// behavior of the system is undefined if two or more `Sidecar` configurations
// with a `workloadSelector` select the same workload instance.
// **NOTE 1**: *_Each namespace can have only one `Sidecar`
// configuration without any `workloadSelector`_ that specifies the
// default for all pods in that namespace*. It is recommended to use
// the name `default` for the namespace-wide sidecar. The behavior of
// the system is undefined if more than one selector-less `Sidecar`
// configurations exist in a given namespace. The behavior of the
// system is undefined if two or more `Sidecar` configurations with a
// `workloadSelector` select the same workload instance.
//
// NOTE 2: *_A `Sidecar` configuration in the `MeshConfig`
// **NOTE 2**: *_A `Sidecar` configuration in the `MeshConfig`
// [root namespace](https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig)
// will be applied by default to all namespaces without a `Sidecar`
// configuration_*. This global default `Sidecar` configuration should not have
// any `workloadSelector`.
//
// The example below declares a global default `Sidecar` configuration in the
// root namespace called `istio-config`, that configures sidecars in
// all namespaces to allow egress traffic only to other workloads in
// the same namespace, and to services in the `istio-system` namespace.
// The example below declares a global default `Sidecar` configuration
// in the root namespace called `istio-config`, that configures
// sidecars in all namespaces to allow egress traffic only to other
// workloads in the same namespace as well as to services in the
// `istio-system` namespace.
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
@@ -50,14 +56,33 @@
// - hosts:
// - "./*"
// - "istio-system/*"
//```
// ```
// {{</tab>}}
//
// The example below declares a `Sidecar` configuration in the `prod-us1`
// namespace that overrides the global default defined above, and
// configures the sidecars in the namespace to allow egress traffic to
// public services in the `prod-us1`, `prod-apis`, and the `istio-system`
// namespaces.
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1beta1
// kind: Sidecar
// metadata:
// name: default
// namespace: istio-config
// spec:
// egress:
// - hosts:
// - "./*"
// - "istio-system/*"
// ```
// {{</tab>}}
// {{</tabset>}}
//
// The example below declares a `Sidecar` configuration in the
// `prod-us1` namespace that overrides the global default defined
// above, and configures the sidecars in the namespace to allow egress
// traffic to public services in the `prod-us1`, `prod-apis`, and the
// `istio-system` namespaces.
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
@@ -71,21 +96,46 @@
// - "prod-apis/*"
// - "istio-system/*"
// ```
// {{</tab>}}
//
// The example below declares a `Sidecar` configuration in the `prod-us1` namespace
// that accepts inbound HTTP traffic on port 9080 and forwards
// it to the attached workload instance listening on a Unix domain socket. In the
// egress direction, in addition to the `istio-system` namespace, the sidecar
// proxies only HTTP traffic bound for port 9080 for services in the
// `prod-us1` namespace.
//
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// apiVersion: networking.istio.io/v1beta1
// kind: Sidecar
// metadata:
// name: default
// namespace: prod-us1
// spec:
// egress:
// - hosts:
// - "prod-us1/*"
// - "prod-apis/*"
// - "istio-system/*"
// ```
// {{</tab>}}
// {{</tabset>}}
//
// The following example declares a `Sidecar` configuration in the
// `prod-us1` namespace for all pods with labels `app: ratings`
// belonging to the `ratings.prod-us1` service. The workload accepts
// inbound HTTP traffic on port 9080. The traffic is then forwarded to
// the attached workload instance listening on a Unix domain
// socket. In the egress direction, in addition to the `istio-system`
// namespace, the sidecar proxies only HTTP traffic bound for port
// 9080 for services in the `prod-us1` namespace.
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
// metadata:
// name: ratings
// namespace: prod-us1
// spec:
// workloadSelector:
// labels:
// app: ratings
// ingress:
// - port:
// number: 9080
@@ -102,20 +152,55 @@
// - hosts:
// - "istio-system/*"
// ```
// {{</tab>}}
//
// If the workload is deployed without IPTables-based traffic capture, the
// `Sidecar` configuration is the only way to configure the ports on the proxy
// attached to the workload instance. The following example declares a `Sidecar`
// configuration in the `prod-us1` namespace for all pods with labels
// `app: productpage` belonging to the `productpage.prod-us1` service. Assuming
// that these pods are deployed without IPtable rules (i.e. the `istio-init`
// container) and the proxy metadata `ISTIO_META_INTERCEPTION_MODE` is set to
// `NONE`, the specification, below, allows such pods to receive HTTP traffic
// on port 9080 and forward it to the application listening on
// `127.0.0.1:8080`. It also allows the application to communicate with a
// backing MySQL database on `127.0.0.1:3306`, that then gets proxied to the
// externally hosted MySQL service at `mysql.foo.com:3306`.
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1beta1
// kind: Sidecar
// metadata:
// name: ratings
// namespace: prod-us1
// spec:
// workloadSelector:
// labels:
// app: ratings
// ingress:
// - port:
// number: 9080
// protocol: HTTP
// name: somename
// defaultEndpoint: unix:///var/run/someuds.sock
// egress:
// - port:
// number: 9080
// protocol: HTTP
// name: egresshttp
// hosts:
// - "prod-us1/*"
// - hosts:
// - "istio-system/*"
// ```
// {{</tab>}}
// {{</tabset>}}
//
// If the workload is deployed without IPTables-based traffic capture,
// the `Sidecar` configuration is the only way to configure the ports
// on the proxy attached to the workload instance. The following
// example declares a `Sidecar` configuration in the `prod-us1`
// namespace for all pods with labels `app: productpage` belonging to
// the `productpage.prod-us1` service. Assuming that these pods are
// deployed without IPtable rules (i.e. the `istio-init` container)
// and the proxy metadata `ISTIO_META_INTERCEPTION_MODE` is set to
// `NONE`, the specification, below, allows such pods to receive HTTP
// traffic on port 9080 (wrapped inside Istio mutual TLS) and forward
// it to the application listening on `127.0.0.1:8080`. It also allows
// the application to communicate with a backing MySQL database on
// `127.0.0.1:3306`, that then gets proxied to the externally hosted
// MySQL service at `mysql.foo.com:3306`.
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
@@ -143,9 +228,43 @@
// hosts:
// - "*/mysql.foo.com"
// ```
// {{</tab>}}
//
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1beta1
// kind: Sidecar
// metadata:
// name: no-ip-tables
// namespace: prod-us1
// spec:
// workloadSelector:
// labels:
// app: productpage
// ingress:
// - port:
// number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
// protocol: HTTP
// name: somename
// defaultEndpoint: 127.0.0.1:8080
// captureMode: NONE # not needed if metadata is set for entire proxy
// egress:
// - port:
// number: 3306
// protocol: MYSQL
// name: egressmysql
// captureMode: NONE # not needed if metadata is set for entire proxy
// bind: 127.0.0.1
// hosts:
// - "*/mysql.foo.com"
// ```
// {{</tab>}}
// {{</tabset>}}
//
// And the associated service entry for routing to `mysql.foo.com:3306`
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: ServiceEntry
@@ -162,6 +281,27 @@
// location: MESH_EXTERNAL
// resolution: DNS
// ```
// {{</tab>}}
//
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1beta1
// kind: ServiceEntry
// metadata:
// name: external-svc-mysql
// namespace: ns1
// spec:
// hosts:
// - mysql.foo.com
// ports:
// - number: 3306
// name: mysql
// protocol: MYSQL
// location: MESH_EXTERNAL
// resolution: DNS
// ```
// {{</tab>}}
// {{</tabset>}}
//
// It is also possible to mix and match traffic capture modes in a single
// proxy. For example, consider a setup where internal services are on the
@@ -170,11 +310,14 @@
// additional network interface on `172.16.0.0/16` subnet for inbound
// traffic. The following `Sidecar` configuration allows the VM to expose a
// listener on `172.16.1.32:80` (the VM's IP) for traffic arriving from the
// `172.16.0.0/16` subnet. Note that in this scenario, the
// `ISTIO_META_INTERCEPTION_MODE` metadata on the proxy in the VM should
// contain `REDIRECT` or `TPROXY` as its value, implying that IP tables
// based traffic capture is active.
// `172.16.0.0/16` subnet.
//
// **NOTE**: The `ISTIO_META_INTERCEPTION_MODE` metadata on the
// proxy in the VM should contain `REDIRECT` or `TPROXY` as its value,
// implying that IP tables based traffic capture is active.
//
// {{<tabset category-name="example">}}
// {{<tab name="v1alpha3" category-value="v1alpha3">}}
// ```yaml
// apiVersion: networking.istio.io/v1alpha3
// kind: Sidecar
@@ -202,6 +345,38 @@
// hosts:
// - "*/*"
// ```
// {{</tab>}}
//
// {{<tab name="v1beta1" category-value="v1beta1">}}
// ```yaml
// apiVersion: networking.istio.io/v1beta1
// kind: Sidecar
// metadata:
// name: partial-ip-tables
// namespace: prod-us1
// spec:
// workloadSelector:
// labels:
// app: productpage
// ingress:
// - bind: 172.16.1.32
// port:
// number: 80 # binds to 172.16.1.32:80
// protocol: HTTP
// name: somename
// defaultEndpoint: 127.0.0.1:8080
// captureMode: NONE
// egress:
// # use the system detected defaults
// # sets up configuration to handle outbound traffic to services
// # in 192.168.0.0/16 subnet, based on information provided by the
// # service registry
// - captureMode: IPTABLES
// hosts:
// - "*/*"
// ```
// {{</tab>}}
// {{</tabset>}}
//
package v1alpha3