Routing Example

Service Mesh OpenShift

- Thomas Jungbauer Thomas Jungbauer ( Lastmod: 2024-05-05 ) - 3 min read

In part 5 of the OpenShift 4 and Service Mesh tutorials, basic routing, using the objects VirtualService and DesitnationRule, are described. All operations have been successfully tested on OpenShift 4.3.

Some Theory

In this section another version of the recommendation microservice will be deployed. The traffic to the new version will be controlled with different settings of the VirtualService. Multiple scenarios can be realized with ServiceMesh. In general these are defined as follows ([1]):

Blue-Green Deployments

In a Blue-Green deployment the old version (green) is kept running, while a new version (blue) is deployed and tested. When testing is successful, the 100% of the traffic is switched to the new version. If there is any error, the traffic could be switched back to the green version.

A/B Deployments

A/B deployments, in difference to Blue-Green deployments, will enable you to try a new version of the application in a limited way in the production environment. It is possible to specify that the production version gets most of the user requests, while a limited number of requests is sent to the new version. This could be specified by location of the user for example, so that all users from Vienna are sent to the new version, while all others are still using the old version.

Canary Deployments

Canary releases can be used to allow a small, minimum amount of traffic to the new version of your application. This traffic can be increased gradually until all traffic is sent to the new version. If any issues are found, you can roll back and send the traffic to the old version.

Prerequisites

It is assumed that an OpenShift environment is up and running and that Issues #1 - #3 are done at least:

Prepare Simple Routing

OPTIONAL: Build the recommendation microservice

If you want to locally build the microservice, you must change the source code from version v1 to v2 the following way:

Open the file:

istio-tutorial/recommendation/java/vertx/src/main/java/com/redhat/developer/demos/recommendation/RecommendationVerticle.java

and change the following line from v1 to v2

private static final String RESPONSE_STRING_FORMAT = "recommendation v2 from '%s': %d\n";

Now you can build the image:

cd istio-tutorial/recommendation/java/vertx
mvn package
podman build -t example/recommendation:v2 . (1)
1Note the v2 tag

Create second deployment with version2

A deployment with our recommendation:v2 microservice must be created. A service object must not be created this time, as it already exists.

cd ~/istio-tutorial/recommendation/
oc apply -f kubernetes/Deployment-v2.yml -n tutorial
oc get pods -w

If you want to diff v1 and v2 deployment, you will notice that the main change is the image which gets pulled.

diff recommendation/kubernetes/Deployment-v2.yml  recommendation/kubernetes/Deployment.yml
6,7c6,7
<     version: v2
<   name: recommendation-v2
---
>     version: v1
>   name: recommendation-v1
13c13
<       version: v2
---
>       version: v1
18c18
<         version: v2
---
>         version: v1
27c27
<         image: quay.io/rhdevelopers/istio-tutorial-recommendation:v2.1
---
>         image: quay.io/rhdevelopers/istio-tutorial-recommendation:v1.1

Call application

Execute the test command to access the application. Since no rules are defined yet, the traffic is split by 50% to version 1 and version 2 (round robin):

sh ~/run.sh 10 $GATEWAY_URL

# 0: customer => preference => recommendation v2 from '3cbba7a9cde5': 27
# 1: customer => preference => recommendation v1 from 'f11b097f1dd0': 27
# 2: customer => preference => recommendation v2 from '3cbba7a9cde5': 28
# 3: customer => preference => recommendation v1 from 'f11b097f1dd0': 28
...

In Kiali presents this as well:

Kiali v1 v2 trafficsplit1
Figure 1. Kiali sends 50% to v1 and v2

Send all traffic to recommendation:v2

To route the traffic accordingly a DestinationRule and a VirtualService must be created for recommendation. While the DesinationRule will add a name to each version, VirtualService specifies the actual destination of the traffic.

Define DestinationRule for recommendation

The object DestinationRule will define the versions in subsets.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: recommendation
spec:
  host: recommendation
  subsets:
  - labels:
      version: v1
    name: version-v1
  - labels:
      version: v2
    name: version-v2

Create the object with the command: oc create -f <filename>

Define VirtualService for recommendation

The VirtualService defines that 100% (weight) of the traffic for recomendation (host) will be sent to the subset (version-v2), which is defined in the DefinationRule

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - route:
    - destination:
        host: recommendation
        subset: version-v2
      weight: 100

Create the object with the command: oc create -f <filename>

Call application

If you now call the application, only traffic to v2 should be shown:

sh ~/run.sh 1000 $GATEWAY_URL

# 0: customer => preference => recommendation v2 from '3cbba7a9cde5': 27
# 1: customer => preference => recommendation v1 from 'f11b097f1dd0': 27
# 2: customer => preference => recommendation v2 from '3cbba7a9cde5': 28
# 3: customer => preference => recommendation v1 from 'f11b097f1dd0': 28
...

In Kiali presents this as well and send 100% of the traffic to recommendation:v2:

Kiali 100 v2 trafficsplit2
Figure 2. Kiali sends 100% to v2

Sources

See Also:

  • Introducing AdminNetworkPolicies –

    Classic Kubernetes/OpenShift offer a feature called NetworkPolicy that allows users to control the traffic to and from their assigned Namespace. NetworkPolicies are designed to give project owners or tenants the ability to protect their own namespace. Sometimes, however, I worked with customers where the cluster administrators or a dedicated (network) team need to enforce these policies. Since the NetworkPolicy API is namespace-scoped, it is not possible to enforce policies across namespaces. The only solution was to create custom (project) admin and edit roles, and remove the ability of creating, modifying or deleting NetworkPolicy objects. Technically, this is possible and easily done. But shifts the whole network security to cluster administrators. Luckily, this is where AdminNetworkPolicy (ANP) and BaselineAdminNetworkPolicy (BANP) comes into play.

  • Using Kustomize to post render a Helm Chart –

    Lately I came across several issues where a given Helm Chart must be modified after it has been rendered by Argo CD. Argo CD does a helm template to render a Chart. Sometimes, especially when you work with Subcharts or when a specific setting is not yet supported by the Chart, you need to modify it later …​ you need to post-render the Chart. In this very short article, I would like to demonstrate this on a real-live example I had to do. I would like to inject annotations to a Route objects, so that the certificate can be injected. This is done by the cert-utils operator. For the post-rendering the Argo CD repo pod will be extended with a sidecar container, that is watching for the repos and patches them if required.

  • Managing Certificates using GitOps approach –

    The article SSL Certificate Management for OpenShift on AWS explains how to use the Cert-Manager Operator to request and install a new SSL Certificate. This time, I would like to leverage the GitOps approach using the Helm Chart cert-manager I have prepared to deploy the Operator and order new Certificates. I will use an ACME Letsencrypt issuer with a DNS challenge. My domain is hosted at AWS Route 53. However, any other integration can be easily used.

  • Update Cluster Version using GitOps approach –

    During a GitOps journey at one point, the question arises, how to update a cluster? Nowadays it is very easy to update a cluster using CLI or WebUI, so why bother with GitOps in that case? The reason is simple: Using GitOps you can be sure that all clusters are updated to the correct, required version and the version of each cluster is also managed in Git. All you need is the channel you want to use and the desired cluster version. Optionally, you can define the exact image SHA. This might be required when you are operating in a restricted environment.

  • Multiple Sources for Applications in Argo CD –

    Argo CD or OpenShift GitOps uses Applications or ApplicationSets to define the relationship between a source (Git) and a cluster. Typically, this is a 1:1 link, which means one Application is using one source to compare the cluster status. This can be a limitation. For example, if you are working with Helm Charts and a Helm repository, you do not want to re-build (or re-release) the whole chart just because you made a small change in the values file that is packaged into the repository. You want to separate the configuration of the chart with the Helm package. The most common scenarios for multiple sources are (see: Argo CD documentation): Your organization wants to use an external/public Helm chart You want to override the Helm values with your own local values You don’t want to clone the Helm chart locally as well because that would lead to duplication and you would need to monitor it manually for upstream changes. This small article describes three different ways with a working example and tries to cover the advantages and disadvantages of each of them. They might be opinionated but some of them proved to be easier to use and manage.

Copyright © 2020 - 2024 Toni Schmidbauer & Thomas Jungbauer