An Introduction to OpenShift Service Mesh 2.3
OpenShift Service Mesh 2.3 has just been released, which we are happy to announce. All Red Hat OpenShift subscription levels offer access to and installation of OpenShift Service Mesh, which is built on the Istio project and uses Kiali as its management console. Istio and Kiali’s base versions have been updated to 1.14 and 1.57, respectively, in OpenShift Service Mesh 2.3. As a result, Istio and Kiali have added a number of new features that boost performance, stability, and maturity. With much more to come in subsequent releases, this release also represents our initial steps toward a stronger convergence between upstream Istio and OpenShift Service Mesh.
Updates on Istio
Numerous enhancements from Istio 1.13 and 1.14 will be visible to anyone upgrading from Service Mesh 2.2. The addition of a new ProxyConfig API for handling proxy-level settings, the capability to specify automatic SNI inclusion, as well as numerous other improvements and configuration choices, are some of the more noticeable features. Review the Istio 1.13 and 1.14 change notes for a complete list.
Gateway Injection is currently available in General.
Traffic entering and leaving the mesh is controlled by Istio Ingress and Egress Gateways. Through the ServiceMeshControlPlane resource, OpenShift Service Mesh has so far established and managed gateways as a part of the control plane. Using injection into a deployment instance, OpenShift Service Mesh 2.3 (and 2.2.4+) introduces GA support for the ability to construct and manage Gateways. As a result, gateway configuration options are expanded, and each gateway’s lifecycle can be managed separately. This is especially helpful when managing Gateways using mesh apps rather than control plane applications. Despite the fact that users can still construct and manage gateways using the ServiceMeshControlPlane, we advise using Gateway injection moving forward if you want to create gateways in namespaces other than the control plane. This is in line with upstream Istio’s advice to build gateways in a namespace apart from the control plane.
A Cluster Level Topology is Introduced
Multi-tenancy is a typical requirement because Red Hat OpenShift is frequently used in large businesses that must serve numerous teams or business units. When OpenShift Service Mesh was first launched, Istio did not support multi-tenancy; therefore, Red Hat has modified Istio to support a multi-tenant deployment architecture. Due to the ability to establish numerous Istio service meshes within a single cluster, customers can utilize them to create “soft” separation between various teams.
Although this is the best scenario for clusters with several meshes, we have observed situations where it is less than ideal for a single large mesh inside a single cluster. The Kubernetes API server may experience a large amount of load while managing hundreds of namespaces, particularly in terms of startup and reconciliation performance. This problem is avoided by running the Istio control plane at the cluster level.
In 2.3, we are providing a topology option that is optimized for a single mesh deployed to a single cluster. This will improve performance and resource utilization for large meshes and is consistent with the deployment structure used by upstream Istio.
While multi-tenant is still the default installation topology in OpenShift Service Mesh 2.3, this tech preview feature will make cluster-wide topology the default topology in a later version of OpenShift Service Mesh. As a result, we urge clients to test out cluster-wide deployments and give Red Hat feedback.
It’s vital to remember that we’ll be helping our clients with their multi-tenant use cases. You can expect us to offer a number of capabilities that allow customers to manage service meshes across many teams or tenants because we have learned that there is no one solution that addresses all multi-tenant demands. Additionally, Istio’s upstream development has made substantial strides in better supporting multi-tenancy, which we want to support, build upon, and advance in collaboration with the community.
Service Mesh Console for OpenShift
The close integration of OpenShift Service Mesh with the OpenShift user interface is one of its advantages. As a technical preview feature in this release, we present the OpenShift Service Mesh Console operator. The OpenShift Console now has access to a variety of service mesh utilities brought by this operator, most notably a new “Service Mesh” page that offers functionality typically available through Kiali, such as the topology graph.
In addition to the new Service Mesh menu, the Deployment and Service consoles also include information about service mesh, such as application metrics, traces, logs, and Envoy data. When managing workloads and services on OpenShift, this will make it simpler to benefit from service mesh information.
The new OpenShift Service Mesh Console operator is where this improvement may be installed.
Please take note that we will still support the standalone community Kiali console. Red Hat is delighted to have developed and will continue to improve what has emerged as the de facto open source dashboard for managing Istio service meshes.
Updates on Kiali
Several Kiali updates from versions 1.49 to 1.57 are included in this release. See the Kiali blog articles from 1.49 to 1.52 and 1.53 to 1.57 for a complete list of updates. The Kiali team often uploads its Sprint demos to its YouTube channel. The following is a description of some of the release’s more prominent additions.
OVERVIEW OF THE CONTROL PLANE
The management of resources for the Isto control plane is a frequent problem for service mesh users. Many users want to know how to size their control plane, and while we offer useful defaults to get you started, the best way to optimise resource usage is to monitor applications that are running in production or under loads that are similar to those in production. Kiali now features a monitoring overview of the control plane to aid in this, showing important health metrics like memory, CPU, and proxy push time.
MADE BETTER VALIDATIONS
Istio setups can be checked with Kiali to see if there are any problems before being implemented. A new “Configuration Analysis” panel has been added to this, which displays validation findings as Error or Warning codes with a tooltip that provides further details.
GATEWAY API SUPPORT
The upcoming Kubernetes Gateway API now has tech preview support in OpenShift Service Mesh 2.2. Initial support for Kiali is added to OpenShift Service Mesh 2.3, enabling users to set Gateway API specs using Kiali:
What will happen to OpenShift Service Mesh next?
This version has various hints about what is to come for OpenShift Service Mesh, including increased interactions with the OpenShift ecosystem, increasing convergence with upstream Istio, and adoption of the Kubernetes Gateway API. Customers can count on us to not just keep going in this direction but to speed up.
The Cloud Native Compute Foundation (CNCF) just announced “ambient mesh,” an Istio data plane option without sidecars, making this a momentous time for the Istio community.