mirror of https://github.com/istio/istio.io.git
Fixup kmod prereqs (#15121)
* Fixup kmod prereqs Signed-off-by: Benjamin Leggett <benjamin.leggett@solo.io> * Fixup lint Signed-off-by: Benjamin Leggett <benjamin.leggett@solo.io> * Add aliases Signed-off-by: Benjamin Leggett <benjamin.leggett@solo.io> --------- Signed-off-by: Benjamin Leggett <benjamin.leggett@solo.io>
This commit is contained in:
Ben Leggett
GitHub
parent
307da8cc62
commit
2bc07f6e55
|
|
@ -59,7 +59,7 @@ Many services will work out of the box, but by adding a little information to yo
|
|||
|
||||
For common ports and protocols, Istio will detect the traffic type. If it can't detect, it will fall back to treating the traffic as TCP, but you can easily [annotate the service](/docs/ops/configuration/traffic-management/protocol-selection/) with the traffic type.
|
||||
|
||||
Learn more about [enabling applications for use with Istio](/docs/ops/deployment/requirements/).
|
||||
Learn more about [enabling applications for use with Istio](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
### Enabling security
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ weight: 95
|
|||
keywords: [mysql,mtls]
|
||||
---
|
||||
|
||||
You may find MySQL can't connect after installing Istio. This is because MySQL is a [server first](/docs/ops/deployment/requirements/#server-first-protocols) protocol,
|
||||
You may find MySQL can't connect after installing Istio. This is because MySQL is a [server first](/docs/ops/deployment/application-requirements/#server-first-protocols) protocol,
|
||||
which can interfere with Istio's protocol detection. In particular, using `PERMISSIVE` mTLS mode, may cause issues.
|
||||
You may see error messages such as `ERROR 2013 (HY000): Lost connection to MySQL server at
|
||||
'reading initial communication packet', system error: 0`.
|
||||
|
||||
This can be fixed by ensuring `STRICT` or `DISABLE` mode is used, or that all clients are configured
|
||||
to send mTLS. See [server first protocols](/docs/ops/deployment/requirements/#server-first-protocols) for more information.
|
||||
to send mTLS. See [server first protocols](/docs/ops/deployment/application-requirements/#server-first-protocols) for more information.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ compatibility with managed offerings, cross-vendor support, and composability wi
|
|||
### Traffic redirection in ambient alpha
|
||||
|
||||
The [istio-cni](/docs/setup/additional-setup/cni/) component is an optional component in the sidecar data plane mode,
|
||||
commonly used to remove the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/requirements/) for
|
||||
commonly used to remove the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/application-requirements/) for
|
||||
users deploying pods into the mesh. `istio-cni` is a required component in the ambient
|
||||
data plane mode. The `istio-cni` component is _not_ a primary CNI implementation, it is a node agent that extends whatever primary CNI implementation is already present in the cluster.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
|
||||
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/requirements/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
1. [Install the Helm client](https://helm.sh/docs/intro/install/), version 3.6 or above.
|
||||
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Before you customize Istio for production use, see these resources:
|
|||
|
||||
- [Deployment models](/docs/ops/deployment/deployment-models/)
|
||||
- [Deployment best practices](/docs/ops/best-practices/deployment/)
|
||||
- [Pod requirements](/docs/ops/deployment/requirements/)
|
||||
- [Pod requirements](/docs/ops/deployment/application-requirements/)
|
||||
- [General installation instructions](/docs/setup/)
|
||||
|
||||
## Join the Istio community
|
||||
|
|
|
|||
|
|
@ -384,7 +384,7 @@ The Istio sidecar works by capturing both inbound traffic and outbound traffic a
|
|||
However, not *all* traffic is captured:
|
||||
|
||||
* Redirection only handles TCP based traffic. Any UDP or ICMP packets will not be captured or modified.
|
||||
* Inbound capture is disabled on many [ports used by the sidecar](/docs/ops/deployment/requirements/#ports-used-by-istio) as well as port 22. This list can be expanded by options like `traffic.sidecar.istio.io/excludeInboundPorts`.
|
||||
* Inbound capture is disabled on many [ports used by the sidecar](/docs/ops/deployment/application-requirements/#ports-used-by-istio) as well as port 22. This list can be expanded by options like `traffic.sidecar.istio.io/excludeInboundPorts`.
|
||||
* Outbound capture may similarly be reduced through settings like `traffic.sidecar.istio.io/excludeOutboundPorts` or other means.
|
||||
|
||||
In general, there is minimal security boundary between an application and its sidecar proxy. Configuration of the sidecar is allowed on a per-pod basis, and both run in the same network/process namespace.
|
||||
|
|
@ -581,7 +581,7 @@ To avoid accidental or intentional miss detection, which may result in unexpecte
|
|||
## CNI
|
||||
|
||||
In order to transparently capture all traffic, Istio relies on `iptables` rules configured by the `istio-init` `initContainer`.
|
||||
This adds a [requirement](/docs/ops/deployment/requirements/) for the `NET_ADMIN` and `NET_RAW` [capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) to be available to the pod.
|
||||
This adds a [requirement](/docs/ops/deployment/application-requirements/) for the `NET_ADMIN` and `NET_RAW` [capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) to be available to the pod.
|
||||
|
||||
To reduce privileges granted to pods, Istio offers a [CNI plugin](/docs/setup/additional-setup/cni/) which removes this requirement.
|
||||
|
||||
|
|
@ -623,7 +623,7 @@ To determine the feature status of features in use in your cluster, consult the
|
|||
|
||||
## Lock down ports
|
||||
|
||||
Istio configures a [variety of ports](/docs/ops/deployment/requirements/#ports-used-by-istio) that may be locked down to improve security.
|
||||
Istio configures a [variety of ports](/docs/ops/deployment/application-requirements/#ports-used-by-istio) that may be locked down to improve security.
|
||||
|
||||
### Control Plane
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ but similar version routing rules have no effect on your own application, it may
|
|||
your Kubernetes services need to be changed slightly.
|
||||
Kubernetes services must adhere to certain restrictions in order to take advantage of
|
||||
Istio's L7 routing features.
|
||||
Refer to the [Requirements for Pods and Services](/docs/ops/deployment/requirements/)
|
||||
Refer to the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/)
|
||||
for details.
|
||||
|
||||
Another potential issue is that the route rules may simply be slow to take effect.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ properly to point at the lab-based NTP services.
|
|||
|
||||
## Verify Istio CNI pods are running (if used)
|
||||
|
||||
The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kubernetes pod lifecycle’s network setup phase, thereby removing the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/requirements/) for users deploying pods into the Istio mesh. The Istio CNI plugin replaces the functionality provided by the `istio-init` container.
|
||||
The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kubernetes pod lifecycle’s network setup phase, thereby removing the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/application-requirements/) for users deploying pods into the Istio mesh. The Istio CNI plugin replaces the functionality provided by the `istio-init` container.
|
||||
|
||||
1. Verify that the `istio-cni-node` pods are running:
|
||||
|
||||
|
|
@ -55,4 +55,4 @@ The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kube
|
|||
$ kubectl -n kube-system get pod -l k8s-app=istio-cni-node
|
||||
{{< /text >}}
|
||||
|
||||
1. If `PodSecurityPolicy` is being enforced in your cluster, ensure the `istio-cni` service account can use a `PodSecurityPolicy` which [allows the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/requirements/).
|
||||
1. If `PodSecurityPolicy` is being enforced in your cluster, ensure the `istio-cni` service account can use a `PodSecurityPolicy` which [allows the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/application-requirements/).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ any interception by the Istio proxy but cannot be used in proxy-only components
|
|||
Istio can automatically detect HTTP and HTTP/2 traffic. If the protocol cannot automatically be determined, traffic will be treated as plain TCP traffic.
|
||||
|
||||
{{< tip >}}
|
||||
Server First protocols, such as MySQL, are incompatible with automatic protocol selection. See [Server first protocols](/docs/ops/deployment/requirements#server-first-protocols) for more information.
|
||||
Server First protocols, such as MySQL, are incompatible with automatic protocol selection. See [Server first protocols](/docs/ops/deployment/application-requirements#server-first-protocols) for more information.
|
||||
{{< /tip >}}
|
||||
|
||||
## Explicit protocol selection
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ aliases:
|
|||
- /docs/ops/setup/required-pod-capabilities
|
||||
- /help/ops/setup/required-pod-capabilities
|
||||
- /docs/ops/prep/requirements
|
||||
- /docs/ops/deployment/requirements
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
---
|
||||
title: Platform Requirements
|
||||
description: Platform requirements for Istio.
|
||||
weight: 1
|
||||
skip_seealso: true
|
||||
keywords: [platform-setup,prerequisites]
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: no
|
||||
aliases: docs/setup/platform-setup/prerequisites
|
||||
---
|
||||
|
||||
## Kernel Module Requirements on Cluster Nodes
|
||||
|
||||
Regardless of the Istio {{< gloss >}}data plane{{< /gloss >}} mode, in Kubernetes contexts Istio generally requires Kubernetes nodes running Linux kernels with `iptables` support in order to function. The majority of Linux kernels released in the past decade include built-in support for all the `iptables` features Istio uses by default - either as kernel modules that will be auto-loaded when required, or built-in.
|
||||
|
||||
For reference, the following lists all the `iptables`-related kernel modules required for Istio to function correctly:
|
||||
|
||||
| Module | Remark |
|
||||
| --- | --- |
|
||||
| `br_netfilter` | |
|
||||
| `ip6table_mangle` | Only needed for IPv6/dual-stack clusters |
|
||||
| `ip6table_nat` | Only needed for IPv6/dual-stack clusters |
|
||||
| `ip6table_raw` | Only needed for IPv6/dual-stack clusters |
|
||||
| `iptable_mangle` | |
|
||||
| `iptable_nat` | |
|
||||
| `iptable_raw` | Only needed for `DNS` interception in sidecar mode |
|
||||
| `xt_REDIRECT` | |
|
||||
| `xt_connmark` | Needed for ambient dataplane mode, and sidecar dataplane mode with `TPROXY` interception (default) |
|
||||
| `xt_conntrack` | |
|
||||
| `xt_mark` | Needed for ambient dataplane mode, and sidecar dataplane mode with `TPROXY` interception (default) |
|
||||
| `xt_owner` | |
|
||||
| `xt_tcpudp` | |
|
||||
| `xt_multiport`| |
|
||||
|
||||
The following additional modules are used by the above listed modules and should be also loaded on the cluster node:
|
||||
|
||||
| Module | Remark |
|
||||
| --- | --- |
|
||||
| `bridge` | |
|
||||
| `ip6_tables` | Only needed for IPv6/dual-stack clusters |
|
||||
| `ip_tables` | |
|
||||
| `nf_conntrack` | |
|
||||
| `nf_conntrack_ipv4` | |
|
||||
| `nf_conntrack_ipv6` | Only needed for IPv6/dual-stack clusters |
|
||||
| `nf_nat` | |
|
||||
| `nf_nat_ipv4` | |
|
||||
| `nf_nat_ipv6` | Only needed for IPv6/dual-stack clusters |
|
||||
| `nf_nat_redirect` | |
|
||||
| `x_tables` | |
|
||||
|
||||
While uncommon, the use of custom or nonstandard Linux kernels or Linux distributions may result in scenarios where the specific modules listed above are not available on the host, or could not be automatically loaded by `iptables`. For example, this [`selinux issue`](https://www.suse.com/support/kb/doc/?id=000020241) describes a scenario in some RHEL releases where `selinux` configuration may prevent the automatic loading of some of the above mentioned kernel modules.
|
||||
|
||||
For more details on the specific Istio components that perform `iptables`-based configuration, see the relevant data plane mode documentation.
|
||||
|
|
@ -41,7 +41,7 @@ before continuing.
|
|||
|
||||
The `istioctl describe` command returns a warning if the {{< gloss >}}Envoy{{< /gloss >}}
|
||||
proxy is not present in a pod or if the proxy has not started. Additionally, the command warns
|
||||
if some of the [Istio requirements for pods](/docs/ops/deployment/requirements/)
|
||||
if some of the [Istio requirements for pods](/docs/ops/deployment/application-requirements/)
|
||||
are not met.
|
||||
|
||||
For example, the following command produces a warning indicating a `kube-dns`
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Kubernetes RBAC permissions.
|
|||
|
||||
The Istio CNI plugin identifies user application pods with sidecars requiring traffic redirection and
|
||||
sets this up in the Kubernetes pod lifecycle's network
|
||||
setup phase, thereby removing the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/requirements/)
|
||||
setup phase, thereby removing the [requirement for the `NET_ADMIN` and `NET_RAW` capabilities](/docs/ops/deployment/application-requirements/)
|
||||
for users deploying pods into the Istio mesh. The Istio CNI plugin
|
||||
replaces the functionality provided by the `istio-init` container.
|
||||
|
||||
|
|
@ -244,7 +244,7 @@ Init containers execute before the sidecar proxy starts, which can result in tra
|
|||
Avoid this traffic loss with one of the following settings:
|
||||
|
||||
1. Set the `uid` of the init container to `1337` using `runAsUser`.
|
||||
`1337` is the [`uid` used by the sidecar proxy](/docs/ops/deployment/requirements/#pod-requirements).
|
||||
`1337` is the [`uid` used by the sidecar proxy](/docs/ops/deployment/application-requirements/#pod-requirements).
|
||||
Traffic sent by this `uid` is not captured by the Istio's `iptables` rule.
|
||||
Application container traffic will still be captured as usual.
|
||||
1. Set the `traffic.sidecar.istio.io/excludeOutboundIPRanges` annotation to disable redirecting traffic to any
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Before you begin, check the following prerequisites:
|
|||
|
||||
1. [Download the Istio release](/docs/setup/getting-started/#download).
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/requirements/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/).
|
||||
1. [Usage of helm for Istio installation](/docs/setup/install/helm).
|
||||
1. Helm version that supports post rendering. (>= 3.1)
|
||||
1. kubectl or kustomize.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Before you begin, check the following prerequisites:
|
|||
|
||||
1. [Download the Istio release](/docs/setup/getting-started/#download).
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/requirements/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
In addition to installing any of Istio's built-in
|
||||
[configuration profiles](/docs/setup/additional-setup/config-profiles/),
|
||||
|
|
|
|||
|
|
@ -311,7 +311,7 @@ Before you customize Istio for production use, see these resources:
|
|||
|
||||
- [Deployment models](/docs/ops/deployment/deployment-models/)
|
||||
- [Deployment best practices](/docs/ops/best-practices/deployment/)
|
||||
- [Pod requirements](/docs/ops/deployment/requirements/)
|
||||
- [Pod requirements](/docs/ops/deployment/application-requirements/)
|
||||
- [General installation instructions](/docs/setup/)
|
||||
|
||||
## Join the Istio community
|
||||
|
|
|
|||
|
|
@ -406,7 +406,7 @@ Before you customize Istio for production use, see these resources:
|
|||
|
||||
- [Deployment models](/docs/ops/deployment/deployment-models/)
|
||||
- [Deployment best practices](/docs/ops/best-practices/deployment/)
|
||||
- [Pod requirements](/docs/ops/deployment/requirements/)
|
||||
- [Pod requirements](/docs/ops/deployment/application-requirements/)
|
||||
- [General installation instructions](/docs/setup/)
|
||||
|
||||
## Join the Istio community
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Before you begin, check the following prerequisites:
|
|||
|
||||
1. [Download the Istio release](/docs/setup/getting-started/#download).
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/requirements/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
## Install Istio using the default profile
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ To avoid a vulnerability, ensure that the operator deployment is sufficiently se
|
|||
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
|
||||
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/requirements/).
|
||||
1. Check the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
1. Install the [{{< istioctl >}} command](/docs/ops/diagnostic-tools/istioctl/).
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Follow this guide to deploy Istio and connect a virtual machine to it.
|
|||
|
||||
1. [Download the Istio release](/docs/setup/getting-started/#download)
|
||||
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/)
|
||||
1. Check the requirements [for Pods and Services](/docs/ops/deployment/requirements/)
|
||||
1. Check the requirements [for Pods and Services](/docs/ops/deployment/application-requirements/)
|
||||
1. Virtual machines must have IP connectivity to the ingress gateway in the connecting mesh, and optionally every pod in the mesh via L3 networking if enhanced performance is desired.
|
||||
1. Learn about [Virtual Machine Architecture](/docs/ops/deployment/vm-architecture/) to gain an understanding of the high level architecture of Istio's virtual machine integration.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,56 +0,0 @@
|
|||
---
|
||||
title: Platform Prerequisites
|
||||
description: Prerequisites for platform setup for Istio.
|
||||
weight: 1
|
||||
skip_seealso: true
|
||||
keywords: [platform-setup,prerequisites]
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
|
||||
## Kernel Module Requirements on Cluster Nodes
|
||||
|
||||
The cluster node running application pods with Istio proxy sidecar container, when using iptables interception mode,
|
||||
requires certain kernel modules to be loaded. Istio can also work in `whitebox` mode where iptables interception is not done
|
||||
and in such cases this section can be skipped as there is no need of any special kernel module.
|
||||
|
||||
The modules are needed specifically by the `istio-init` container or `istio-cni` daemon which sets up iptables rules in the pod to
|
||||
redirect any incoming or outgoing traffic towards the sidecar proxy in the istio-proxy container. While in many platforms, these seem
|
||||
to be automatically loaded, it is always good to make sure the prerequisites are met, as there were incidents reported where some of
|
||||
the specific modules listed down below were not available on the host or could not be automatically loaded by the iptables. For example,
|
||||
this [`selinux issue`](https://www.suse.com/support/kb/doc/?id=000020241) talks about selinux in RHEL sometimes preventing
|
||||
the automatic loading of some of the below mentioned kernel modules.
|
||||
|
||||
| Module | Remark |
|
||||
| --- | --- |
|
||||
| `br_netfilter` | |
|
||||
| `ip6table_mangle` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `ip6table_nat` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `ip6table_raw` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `iptable_mangle` | |
|
||||
| `iptable_nat` | |
|
||||
| `iptable_raw` | Only needed for `DNS` interception |
|
||||
| `xt_REDIRECT` | |
|
||||
| `xt_connmark` | Only needed for `TPROXY` interception mode |
|
||||
| `xt_conntrack` | |
|
||||
| `xt_mark` | Only needed for `TPROXY` interception mode |
|
||||
| `xt_owner` | |
|
||||
| `xt_tcpudp` | |
|
||||
| `xt_multiport`| |
|
||||
|
||||
The following additional modules are used by the above listed modules and should be also loaded on the cluster node:
|
||||
|
||||
| Module | Remark |
|
||||
| --- | --- |
|
||||
| `bridge` | |
|
||||
| `ip6_tables` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `ip_tables` | |
|
||||
| `nf_conntrack` | |
|
||||
| `nf_conntrack_ipv4` | |
|
||||
| `nf_conntrack_ipv6` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `nf_nat` | |
|
||||
| `nf_nat_ipv4` | |
|
||||
| `nf_nat_ipv6` | Only needed for IPv6 or dual-stack clusters |
|
||||
| `nf_nat_redirect` | |
|
||||
| `x_tables` | |
|
||||
|
|
@ -322,7 +322,7 @@ to the request by the `productpage` service.
|
|||
|
||||
Note that Kubernetes services, like the Bookinfo ones used in this task, must
|
||||
adhere to certain restrictions to take advantage of Istio's L7 routing features.
|
||||
Refer to the [Requirements for Pods and Services](/docs/ops/deployment/requirements/) for details.
|
||||
Refer to the [Requirements for Pods and Services](/docs/ops/deployment/application-requirements/) for details.
|
||||
|
||||
In the [traffic shifting](/docs/tasks/traffic-management/traffic-shifting) task, you
|
||||
will follow the same basic pattern you learned here to configure route rules to
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ aliases:
|
|||
|
||||
## Traffic management
|
||||
|
||||
- **Added** [automatic protocol determination](/docs/ops/configuration/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istio’s [conventions](/docs/ops/deployment/requirements/).
|
||||
- **Added** [automatic protocol determination](/docs/ops/configuration/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istio’s [conventions](/docs/ops/deployment/application-requirements/).
|
||||
- **Added** a mode to the Gateway API for mutual TLS operation.
|
||||
- **Fixed** issues present when a service communicates over the network first in permissive mutual TLS mode for protocols like MySQL and MongoDB.
|
||||
- **Improved** Envoy proxy readiness checks. They now check Envoy's readiness status.
|
||||
|
|
|
|||
Loading…
Reference in New Issue