Gateway migration
As a network administrator, the preferred method for deploying ingress and egress gateways is with a Deployment resource using gateway injection.
About gateway migration
In Red Hat OpenShift Service Mesh 2.x, the Service Mesh Operator creates an ingress and egress gateway in the control plane namespace by default. You can define additional gateways in the ServiceMeshControlPlane resource.
Deploying ingress and egress gateways with a Deployment resource using gateway injection provides greater flexibility and control. This deployment approach is a better practice because it allows you to manage gateways alongside the corresponding applications rather than in the control plane resource. Therefore, you should disable the default gateways, move away from the Service Mesh Control Plane declaration, and begin to use gateway injection.
Migrate from SMCP-Defined gateways to gateway injection
This procedure explains how to migrate with zero downtime from gateways defined in the ServiceMeshControlPlane resource to gateways that are managed using gateway injection. This migration is achieved by using the existing gateway Service object to target a new gateway deployment that is created using gateway injection.
-
You are logged in to the OpenShift Container Platform web console as
cluster-admin. -
The Red Hat OpenShift Service Mesh Operator must be installed.
-
The
ServiceMeshControlPlaneresource must be deployed and an ingress gateway exists in the configuration.
-
Create a new ingress gateway that is configured to use gateway injection.
Note
This procedure migrates away from the default ingress gateway deployment defined in the
ServiceMeshControlPlaneresource to gateway injection. The procedure may be modified to migrate from additional ingress gateways configured in the SMCP.Example ingress gateway resource with gateway injectionapiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway-canary namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway sidecar.istio.io/inject: "true" spec: containers: - name: istio-proxy image: auto serviceAccountName: istio-ingressgateway --- apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: istio-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader namespace: istio-system rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway-secret-reader namespace: istio-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: secret-reader subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: gatewayingress namespace: istio-system spec: podSelector: matchLabels: istio: ingressgateway ingress: - {} policyTypes: - Ingress- The gateway injection deployment and all supporting resources should be deployed in the same namespace as the SMCP-defined gateway.
- Ensure that the labels specified in the pod template include all of the label selectors specified in the
Serviceobject associated with the existing SMCP-defined gateway. - Grant access to the new gateway from outside the cluster. This access is required whenever the
spec.security.manageNetworkPolicyof theServiceMeshControlPlaneresource is set totrue, which is the default setting.
-
Verify that the new gateway deployment is successfully handling requests.
If access logging was configured in the
ServiceMeshControlPlaneresource, view the access logs of the new gateway deployment to confirm the behavior. -
Scale down the old deployment and scale up the new deployment.
Gradually shift traffic from the old gateway deployment to the new gateway deployment by performing the following steps:
-
Increase the number of replicas for the new gateway deployment by running the following command:
$ oc scale -n istio-system deployment/<new_gateway_deployment> --replicas <new_number_of_replicas> -
Decrease the number of replicas for the old gateway deployment by running the following command:
$ oc scale -n istio-system deployment/<old_gateway_deployment> --replicas <new_number_of_replicas> -
Repeat running the previous two commands. Each time, increase the number of replicas for the new gateway deployment and decrease the number of replicas for the old gateway deployment. Continue repeating until the new gateway deployment handles all traffic to the gateway
Serviceobject.
-
-
Remove the
app.kubernetes.io/managed-bylabel from the gatewayServiceobject by running the following command:$ oc label service -n istio-system istio-ingressgateway app.kubernetes.io/managed-by-Removing the label prevents the service from being deleted when the gateway is disabled in the
ServiceMeshControlPlaneresource. -
Remove the
ownerReferencesobject from the gatewayServiceobject by running the following command:$ oc patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "remove", "path": "/metadata/ownerReferences"}]'Removing this object prevents the service from being garbage collected when the
ServiceMeshControlPlaneresource is deleted. -
Disable the old gateway deployment that was managed by the
ServiceMeshControlPlaneresource by running the following command:$ oc patch smcp -n istio-system <smcp_name> --type='json' -p='[{"op": "replace", "path": "/spec/gateways/ingress/enabled", "value": false}]'Note
-
When the old ingress gateway
Serviceobject is disabled it is not deleted. You may save thisServiceobject to a file and manage it alongside the new gateway injection resources. -
The
/spec/gateways/ingress/enabledpath is available if you explicitly set it for theServiceMeshControlPlaneresource. If you are using the default value, you must patch the/spec/gateways/enabledpath for both ingress and egress gateways.
-