Prerequisites
The following prerequisites need to be met in order to deploy Language Weaver Edge on Kubernetes.
- You have a working Kubernetes cluster.
- You have a Docker registry. The Kubernetes cluster should be able to pull images from this registry.
- Docker is installed locally in order to pull/push images.
- You have a client machine where the deployment will be triggered from. On the client machine, the following utilities must be installed:
Utility Install Instructions Comments kubectl https://kubernetes.io/docs/tasks/tools/install-kubectl/ Kubernetes command line utility helm https://helm.sh/docs/intro/install/ Utility on top of kubectl to facilitate deployment - If your Kubernetes cluster is hosted on a cloud provider platform, you may want to install the relevant cloud provider tools to enable access to the Kubernetes cluster from your client machine.
- For Google Cloud Platform, install the gcloud utility: https://cloud.google.com/sdk/install.
- For Microsoft Azure AKS, install the Azure CLI: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli.
- For Amazon Web Services EKS, install the AWS CLI and eksctl utility: https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html.
- You have the Language Weaver Edge application and the language pair container images pulled from the RWS container registry: https://docker.edge.languageweaver.com.
- You have the latest version of Helm Charts and Values.yaml file downloaded and extracted from https://files.edge.languageweaver.com/login, under /Delivery/Language Weaver Edge/Latest Releases/Kubernetes
The deployment package includes:
- sdl-mtedge-data-VERSION.tgz
- sdl-mtedge-VERSION.tgz
- Values.yaml default configuration file examples (for MS Azure and Google Cloud Platform)
- You have a valid Language Weaver Edge license for Kubernetes.
Considerations for RedHat OpenShift (ROSA)
Running Language Weaver Edge on RedHat OpenShift (ROSA) requires some security related changes when compared to a standard Kubernetes deployment hosted on any other cloud or on-premise platform, like AKS, GKE or EKS.
Mandatory requirements
- UID and GID of mtedge user should be 1001000000 or higher.
- User mtedge should not run as root, nor as a privileged user.
- Privilege escalation must be disabled.
- All capabilities of pods must be disabled.
Example:
securityContext:
default:
pod:
runAsNonRoot: true
fsGroup: 990000000
fsGroupChangePolicy: Always
container:
seccompProfile:
type: RuntimeDefault
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
runAsNonRoot: true
runAsUser: 990000000
runAsGroup: 990000000
Optional requirements
There are also some optional requirements. These requirements can be adjusted based on customer preference.
- Namespace: Security context (SCC) of “default” namespace is different to any other customer created namespaces in a ROSA Kubernetes cluster. Security context settings applied by the helm charts are written for “restricted” SCC and not for “privileged” SCC. It is highly recommended to deploy Language Weaver Edge in a newly created namespace and not in the default namespace.
Example:
name=default pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/warn=privilegedpod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/audit-version=v1.24 pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/warn-version=v1.24 - UID & GID: Standard image of Language Weaver Edge (8.6.4.3) has a UID & GID of 10001. Whereas ROSA version of Language Weaver Edge image (8.6.4.3-oshift) has a UID & GID of 990000000. UID of the namespace where Language Weaver Edge will be deployed must be set accordingly.
Example:
kubectl edit ns mtedge - Service account: Default service account (“default”) is used by the Language Weaver Edge deployment by default. This works "out of the box" and has no implication to Language Weaver Edge deployment. There is, however, a provision in the latest helm chart (8.6.4-3) to specify a different service account, other than the “default”, should it be required.
Example:
kubectl create serviceaccount mtedge-sa -n mtedgeserviceAccounts: installer: name: mtedge-sa controller: name: mtedge-sa worker: name: mtedge-sa - Persistent volumes: ROSA supports a variety of different storage vendors, which are not available in standard cloud Kubernetes deployments, like Azure blob or Google Filestore. There is a provision in the latest helm charts (8.6.4-3) to bring your own persistent volume (BYOP). Customers can choose which block storage (RWO) is used as the controller persistent volume and which file storage (RWX) is used as the language pair storage. Names of persistent volumes do not need to be exactly the defaults.
Example:
storage: controller: size: 200Gi class: ebs-sc pvc: my-controller-pvc lp: size: 1200Gi class: efs-sc pvc: my-languagepair-pvc