This document walks through the installation procedure for Seldon Enterprise Platform v2.1.0 onto Red Hat OpenShift (RHOCP) v4.13.
Note: These instructions have been tested on OpenShift 4.13. These instructions work on OpenShift versions 4.10 - 4.13 only.
The prerequisites for the installation are aligned with usual requirements for installation / configuration of operators on the Red Hat OpenShift platform:
Access to the OpenShift Container Platform web console.
An account with the cluster-admin role.
Being logged in to the OpenShift Container Platform cluster as an administrator.
Note: Whenever a (*) symbol is present next to an operator version it indicates a version available in Operator Hub at the moment of writing this documentation. When following this guide the available or default versions of operators may be different. These versions are noted here for information purposes only and upstream OpenShift documentation should be consulted when in doubts.
Preparation
Creating the Seldon Namespaces
Seldon Enterprise Platform has a number of namespaces which it expects to be present, and associated with given labels.
The first namespace to create is where the Seldon Enterprise Platform controller pod will run. This is the main orchestrator of the Seldon technology stack, and expects to run in the seldon-system namespace.
Next, create a namespace within which models can be deployed. In this documentation this is going to be called seldon, however can be configured to any name of your choosing. Create the namespace, and then add the seldon.restricted label so SD has access to it.
The first step within the installation process is to add OpenShift Service Mesh. This is required for the networking of all other pieces within the Seldon Enterprise Platform stack, as well as the ingress/egress for model endpoints.
Note: Istio (OpenShift Service Mesh) is an external component outside of the main Seldon stack. Therefore, it is the cluster administrator's responsibility to administrate and manage the Istio installation used by Seldon.
Adding Operators
The initial action taken is to add the relevant operators required for the logging stack. Log into the RHOCP console and navigate to the OperatorHub, within the Operators tab.
Red Hat OpenShift distributed tracing platform (provided by Red Hat) (1.39.0-3*)
Kiali Operator (provided by Red Hat) (1.57.3*)
Red Hat OpenShift Service Mesh (provided by Red Hat) (2.3.0*)
Configuring the ServiceMeshControlPlane
Next, configure the ServiceMeshControlPlane. Ensuring Control Plane in Version v2.0 is installed and the control plane is created within the istio-system namespace, as per the OpenShift documentation.
Add Namespaces to ServiceMeshMemberRoll
Navigate to the Red Hat OpenShift Service Mesh operator under your installed operators. Select the Istio Service Mesh Member Roll tab and create a new ServiceMeshMemberRoll in istio-system namespace with the following namespaces added to the member roll:
seldon
seldon-logs
seldon-kafka
seldon-system
Note: this is easiest done using the YAML editor.
Create Seldon’s Istio Gateway
Seldon then requires an Istio gateway to allow traffic to and from the SD controller pod as well as to enable advanced routing features like canary and shadow deployments. Create a following YAML manifest called in this example istio-gateway.yaml:
OpenShift clusters usually come with Let's Encrypt certificates enabled for default ingress domain. One can create Route with the tls.termination: edge in order to re-use these certificates. Create the following YAML manifest called seldon-route.yaml:
To display your default ingress domain, run the following command:
$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
After using it in the above manifest in place of <Ingress_Domain> your Istio Ingress will be exposed under
INGRESS_DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
echo https://seldon.$INGRESS_DOMAIN/
Note: This setup terminates the SSL on edge and provides non-SSL in-cluster traffic.
Apply the above manifest with
oc apply -f seldon-route.yaml
OpenShift Serverless
Seldon Enterprise Platform uses OpenShift Serverless, in the form of Knative Serving and Knative Eventing, to power many of the advanced monitoring components associated with your deployments; namely outlier and drift detection. Without this component these features will fail to function within the platform.
Note: Knative is an external component outside of the main Seldon stack. Therefore, it is the cluster administrator's responsibility to administrate and manage the Knative installation used by Seldon.
Serverless Operator
Once more, navigate to the Operator Hub and install the official Red Hat OpenShift Serverless (1.26.0*) operator. Install using the default options.
Install Knative Eventing
Using the Serverless Operator, and as per the OpenShift documentation, install an instance of Knative Eventing.
Install Knative Serving
Using the Serverless Operator, and as per the OpenShift documentation, install an instance of Knative Serving.
Logs Namespace and Broker
The Knative events which activate the outlier and drift detectors in the form of Knative served pods are reliant on events from the Seldon logging stack. The Seldon logging stack is installed into the seldon-logs namespace with a Knative Eventing Broker configured within it.
If you did not create this namespace yet create it now
oc create namespace seldon-logs
Create the Knative Eventing Broker, eventing-broker.yaml
Finally, we need to add a couple of NetworkPolicy resources to ensure that traffic can flow from Knative Eventing and Serving to the different Seldon namespace:
Seldon Logs Namespace
To allow traffic from Knative Eventing into the Seldon Logs namespace we will create a NetworkPolicy resource. Create networkpolicy-seldon-logs.yaml:
For each model namespace, we will need to create a couple of NetworkPolicy resources to ensure that traffic from both Knative Eventing and Serving can go into our model namespace. For this, first create a file named networkpolicy-detectors.yaml with the following resources:
Elasticsearch is responsible for storing all requests and responses sent to the machine learning models hosted within Seldon Enterprise Platform. Requests and responses are forwarded to Elasticsearch by the Seldon request logging component, which also runs within the seldon-logs namespace.
Elasticsearch also stores the container logs of all running models and monitoring components hosted within Seldon Enterprise Platform. These are forwarded to Elasticsearch by Fluentd.\
Elasticsearch is an external component outside the main Seldon stack. Therefore, it is the cluster administrator's responsibility to administrate and manage the Elasticsearch instance used by Seldon.
Installing the ECK Operator
The first step to configure Elasticsearch is to add the Elasticsearch (ECK) Operator (2.5.0*) from within the Operator Hub. This operator should be installed with default options, with access to all namespaces.
Create the Elasticsearch Cluster
Navigate to the Elasticsearch (ECK) Operator operator under your installed operators. Select the Elasticsearch Cluster tab and create a new cluster in seldon-logs namespace called elasticsearch-seldon using 8.7.x version:
Note: Currently, Seldon guarantees compatibility with Elasticsearch 7.X. Compatibility with Elasticsearch 8.X is not guaranteed.
Add NetworkPolicy Resource
You need to add the below NetworkPolicyresource in the seldon-logs namespace to ensure that traffic can flow between the seldon-logs namespace and openshift-operators, where the ECK operator is running. For this, first create a file named networkpolicy-seldon-elastic.yaml with the following resource:
In order for Seldon Enterprise Platform to access the Elasticsearch cluster there are two secrets which are required to be created. One secret in the seldon-logs namespace to allow access to the cluster for the request logger component. The other in the seldon-system namespace where the Seldon Enterprise Platform pod will be installed.
Grab the Elasticsearch password and assign it to a variable for later use.
ELASTIC_PASSWORD=$(kubectl get secret elasticsearch-seldon-es-elastic-user -n seldon-logs -o go-template='{{.data.elastic | base64decode}}')
To enable container logs visibility in Seldon Enterprise Platform we use OpenShift Logging.
Installing OpenShift Logging Operator
Follow OpenShift documentation to install Red Hat OpenShift Logging (5.5.5*) operator.
Installing ClusterLogging Component
Note: As we will be forwarding logs to the Elastic instance elasticsearch-seldon in seldon-logs namespace you can disable the internal Elasticsearch logStore and Kibana visualization components from the ClusterLogging custom resource (CR). Therefore installation of the OpenShift Elasticsearch Operator is not required.
Navigate to the Red Hat OpenShift Logging operator under your installed operators. Select the Cluster Logging tab and create an instance containing at minimum the fluentd logs collection:
Navigate to the Red Hat OpenShift Logging operator under your installed operators. Select the Cluster Log Forwarder tab and create an instance forwarding logs to our Elastic instance.
For further details refer to OpenShift documentation.
Finally, we need to add NetworkPolicy to allow traffic from openshift-logging into seldon-logs namespace. Create networkpolicy-seldoncontainerlogs.yaml with following resource:
OpenShift provides an out of the box monitoring stack consisting of Prometheus and Thanos, alongside the Prometheus AlertManager. This stack is configured to monitor the standard OpenShift workloads, but can be extended to collect the metrics which Seldon Enterprise Platform produces. This is done through adding a PodMonitor component to any of the namespaces where Seldon models are expected to be running.
Configuring Cluster Monitoring Stack
First, check that the OpenShift cluster has the correct configuration applied in order to monitor the standard workloads it expects to. This can be done by following the relevant OpenShift documentation.
Once cluster wide monitoring has been set up, the next configuration to add is that for user defined workloads - such as Seldon Enterprise Platform. The steps are very similar to cluster monitoring configuration, and can be completed by following the user defined workload monitoring documentation available here.
By following the OpenShift documentation you should now have these two ConfigMaps created with enableUserWorkload enabled:
Finally, apply the token as a secret within the seldon-system namespace. This is the secret with which Seldon will authenticate itself against the Prometheus instance:
Note: Depending on the permissions of the token used above different metrics and alerts will be available for Seldon Enterprise Platform to use and display.
Adding Network Access Policies
The next step in configuring the monitoring services is to add NetworkPolicy that will allow for ingress from openshift-user-workload-monitoring namespace to any namespace containing seldon specific deployments.
For any of the namespaces which Seldon Enterprise Platformed models are going to run within there needs to be a couple of PodMonitor resources created within that namespace. Create file seldon-podmonitor.yaml:
For any of the namespaces which Seldon Enterprise Platformed models are going to run within there needs to be a PrometheusRule resource created within that namespace.
Create file deployment-usage-rules.yaml which content you can find in the appendix at the end of this document. You must apply it to all namespaces that will host SeldonDeployment models
Once OpenShift reconciles the relevant configuration changes you can verify in the Admin UI -> Observe -> Alerting -> Alerting rules that TestAlertNoActionRequired rule was created (you may need to disable Platform filter to find it).
Configuring Seldon Enterprise Platform as receiver of Alertmanager
The OpenShift documentation explains how to configure alert receivers. This can be done either:
using OpenShift Container Platform web console
using CLI to modify main alertmanager-main secret in openshift-monitoring namespace
creating AlertmanagerConfig custom resource (alpha preview of OpenShift feature)
The Model Catalog acts as a registry for all models deployed onto the Seldon platform, where additional metadata can be added to allow for faster deployment, easier model re-use and provenance of metadata across your experimentation, deployment and monitoring tools. The Model Catalog persists this metadata within an instance of PostgreSQL.
Note: PostgreSQL is an external component outside of the main Seldon stack. Therefore, it is the cluster administrator's responsibility to administrate and manage the PostgreSQL instance used by Seldon.
The PostgreSQL documentation page contains extensive information how to configure connection to managed postgres solution. In the document here we will give an example using the built-in PostgreSQL application template provided by RHOCP.
Creating built-in PostgreSQL instance
Note: These instructions will help you to quickly spin up a PostgreSQL instance. However, we don't recommend using it in a production context, and should be treated as development-only.
Once the template is instantiated, the following Openshift/Kubernetes resources will be created to support the Model Catalog:
DeploymentConfiguration
ReplicationController
Postgresql pod
Service
PersistentVolumeClaim
Adding Secrets
Seldon Enterprise Platform needs to be able to authenticate to the PostgreSQL instance, and therefore a secret is created called metadata-postgres using the below command.
Seldon Enterprise Platform leverages GitOps to ensure an up-to-date declarative representation of model deployments. GitOps enables changes in deployments to be tracked and deployments to be rolled back to previous states- via commits to a Git repository. The Git repository stores the SeldonDeployments which describe how to create the machine learning models on the Kubernetes cluster.
Red Hat OpenShift provides a GitOps operator, which is built on top of ArgoCD and provides an easy to install and maintain component for enabling GitOps workflows. This installation will leverage the OpenShift GitOps Operator to enable Seldon’s own GitOps functionality.
Prepare Seldon Namespace for GitOps
Each namespace in which Seldon models are meant to be deployed using GitOps needs to specially prepared. Here we will provide example for namespace called seldon-gitops:
The above configures the seldon-gitops namespace to be recognized as gitops-enabled by Seldon Enterprise Platform. Assuming that we install ArgoCD instance into the seldon-argocd namespace we need to allow seldon-gitops namespace to be managed by it:
The first step to configure GitOps is to add the Red Hat OpenShift GitOps (1.7.0*) operator from within the Operator Hub. This operator should be installed with default options. Please follow OpenShift documentation here.
The OpenShift GitOps Operator automatically creates an ArgoCD instance in the openshift-gitops namespace. You can use this ArgoCD instance or create a new one as we describe in the next section.
Creating ArgoCD Instance
For purpose of this documentation we will use a new ArgoCD instance. First create a new project/namespace:
oc create namespace seldon-argocd
Then, create a new Argo CD instance dedicated to Seldon following the OpenShift documentation. We recommend to make following changes to the Argo CD instance using the YAML editor:
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
name: seldon-argocd # Change here
namespace: seldon-argocd # Change here
spec:
server:
route:
enabled: true
tls: # Change here
termination: reencrypt # Change here
dex:
openShiftOAuth: true
rbac:
policy: g, cluster-admins, role:admin # Change here
scopes: '[groups]'
# ...
Explanation:
spec.server.route.tls.termination: this can be set to re-use the SSL certificates as we did when setting seldon-route in the istio-system namespace
spec.server.rbac.policy: the default value there reads system:cluster-admins which in certain configurations does not provide expected admin access
Note: the above definition enables Dex OpenShift OAuth Connector that allows you to log into ArgoCD using OpenShift OAuth. OpenShift admin user (belonging to cluster-admins) group will have admin privileges in ArgoCD UI.
Your ArgoCD instance will now be available under
INGRESS_DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
echo https://seldon-argocd-server-seldon-argocd.$INGRESS_DOMAIN/
To configure our Git credentials in Seldon Enterprise Platform, we will follow these steps:
Create a Kubernetes secret containing our credentials, either as a SSH key or a User / Password combination. This secret can have any arbitrary name, but must live in the same namespace as Seldon Enterprise Platform.
If the private key is present under $GIT_SSH_PATH, you can create the credentials secret as:
Make sure that Seldon Enterprise Platform's configuration point to our newly created secret. In particular, we verify the gitops section of the values of the Seldon Enterprise Platform Helm chart. Here, we need the gitops.argocd.enabled flag be to true, and the gitops.git.secret field to point to the right secret name. The Helm installation of Seldon Enterprise Platform is described in section further down in this document and the Helm values provided there already have GitOps enabled.
Note: Kafka is an external component outside of the main Seldon stack. Therefore, it is the cluster administrator's responsibility to administrate and manage the Kafka installation used by Seldon.
Install Kafka Operator
The first step to install Kafka is to install an operator that can manage Kafka cluster.
Add the Red Hat Integration - AMQ Streams (2.2.0-4*) operator from within the Operator Hub. This operator should be installed with default options. AMQ Streams is based on Strimzi Operator and can read more about it in the Red Hat documentation here.
Add Strimzi (0.32.0*) operator. This operator should be installed with default options. This is the community Strimzi Operator.
Create Kafka Cluster
Once we have Strimzi (Strimzi provided by Strimzi or AMQ Streams provided by Red Hat) operator up and running we need to create Kafka cluster.
Create seldon-kafka namespace for our Kafka cluster
oc create namespace seldon-kafka
Make sure that seldon-kafka namespace is added to Service Mesh Member Roll as described in OpenShift Service Mesh section.
Select seldon-kafka project and navigate to your Kafka operator under your installed operators. Select the Kafka tab and create the Kafka cluster. Following is a minimal required configuration.
Seldon Core is used to serve machine learning models over REST and gRPC endpoints, using a variety of advanced deployment strategies (canaries, shadows, A/B, multi-armed bandits).
Seldon Core (v1.16.0) is available as an operator within the Operator Hub and can therefore be readily installed onto OpenShift.
Once the operator has been installed there are a number of configuration changes required to ensure smooth interaction with the wider environment of tools. This can be achieved by editing the operator’s ClusterServiceVersion in the YAML tab of newly installed operator.
The configuration parameters to edit are the deployment environment variables:
ISTIO_ENABLED set to true
EXECUTOR_REQUEST_LOGGER_DEFAULT_ENDPOINT set to http://broker-ingress.knative-eventing.svc.cluster.local/seldon-logs/default
Seldon Core v2
Seldon Core v2 can be installed using published Helm charts. To add Helm charts run:
seldon-system for cluster-wide installation, or each model namespace for namespaced installations, e.g. seldon
seldon-core-v2-runtime
Seldon Runtime defines core components required in each model namespace
each model namespace, e.g. seldon
seldon-core-v2-servers
Seldon Core v2 pre-configured servers to host your models (optional)
each model namespace, e.g. seldon
Installation Modes
Seldon Core v2 supports both cluster-wide and namespaced installations:
In cluster-wide mode, we recommend installing the seldon-core-v2-setup Helm Chart into the seldon-system namespace. The operator will then reconcile Core v2 resources like SeldonRuntime, Server, Model, and Pipeline in all namespaces.
In namespaced mode, you must install the seldon-core-v2-setup Helm chart into each model namespace. Each operator will then reconcile Core v2 resources only in the namespace it is installed in itself.
Cluster-wide installation of Seldon Core v2 is only available from version 2.6.0 onwards. Installation of the Seldon Core operator into the seldon-system namespace (i.e. the same namespace as Core v1) is only available from version 2.7.0.
For a namespaced installation, we will use seldon as an exemplary namespace throughout this page to install Core v2. You'd have to repeat these steps for each namespace you want to use Core v2 in. In case of a cluster-wide installation, the seldon namespace is an exemplary namespace for only the Seldon Runtime and Servers.
Create components-values.yaml file that we will use to configure the installation. The values below are meant as a starting point and should be edited where necessary:
Create components-values.yaml file that we will use to configure the installation. The values below are meant as a starting point and should be edited where necessary:
In order to run models, you will need to provision a server or more. As a convenience for getting started, you can install pre-configured Seldon Core v2 Servers. To do this, we first need to create servers-values.yaml that we will use to configure the installation. Create servers-values.yaml file (below are just the default values, adjust them to your needs):
To send HTTP requests to Seldon Mesh you will need to set two headers: -H "namespace:<namespace>" -H "inference:seldon-mesh" to reach Seldon Mesh in given namespace. For example to reach iris pipeline in seldon namespace:
Download the seldon-deploy-install.tar file that contains required installation resources. For example, to download the installation resources for version 2.4.0 of Seldon Enterprise Platform run the following:
Extract the contents of the seldon-deploy-install.tar file.
tar -xzf seldon-deploy-install.tar.gz
Seldon Enterprise Platform relies on Helm charts to perform the installation. There is a master configuration file which contains all of the relevant Helm values for the given installation, in the appendix of this document there is the recommended Helm values for the installation of Seldon Enterprise Platform on OpenShift. Save these values as values-openshift.yaml and then run the following helm command to install Seldon Enterprise Platform.
Once the Seldon Enterprise Platform pods have come up, the UI can be accessed by running the following command, and entering the resultant URI into the browser.:
INGRESS_DOMAIN=$(oc get ingresses.config/cluster -o jsonpath={.spec.domain})
echo https://seldon.$INGRESS_DOMAIN/seldon-deploy/
Appendix
Adding new namespace for Seldon Enterprise Platform
To add a new namespace for Seldon Enterprise Platform to use called my-new-namespace do
If the new namespace is meant to be gitops-enabled (recommended) follow steps described in Argo CD section:
add seldon.gitops=enabled label
add git-repo annotation
add argocd.argoproj.io/managed-by label
update AppProject with new namespace entry
create new Application resource
If you specified explicitly namespaces in the ClusterLogForwarder config you need to add new namespace to the list.
Install Seldon Core v2 in the new namespace. Note that, when following the instructions, you will need to replace seldon for the new namespace name (e.g. my-new-namespace).
Validating Installation
This subsection describes basic validation steps for the Seldon installation.
Validating Ingress
Verify that Istio Gateway and Route for Seldon is created with
$ oc get gateway -n istio-system seldon-gateway
NAME AGE
seldon-gateway 7d20h
$ oc get route -n istio-system seldon-route
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
seldon-route seldon.$INGRESS_DOMAIN istio-ingressgateway http2 edge/Redirect None
Validating Serverless
Verify that Broker exist and is in READY state with
$ oc get broker -n seldon-logs
NAME URL AGE READY REASON
default http://broker-ingress.knative-eventing.svc.cluster.local/seldon-logs/default 7d20h True
Validating NetworkPolicy resources
Verify that following NetworkPolicy resources exist in seldon-system and seldon-logs namespaces:
$ oc get networkpolicy -n seldon-system
NAME POD-SELECTOR AGE
user-workload-monitoring <none> 7d19h
$ oc get networkpolicy -n seldon-logs
NAME POD-SELECTOR AGE
seldon-container-logs <none> 7d19h
seldon-request-logs <none> 7d20h
seldon-elastic-cluster <none> 7d20h
Verify that in every namespace with your Seldon models a following NetworkPolicy resources exist:
$ oc get networkpolicy -n <model namespace>
NAME POD-SELECTOR AGE
seldon-detectors <none> 7d20h
seldon-detectors-serving <none> 7d20h
user-workload-monitoring <none> 7d19h
Validating Monitoring Resources
Verify that following PodMonitor and PrometheusRules exists in seldon-system namespace:
$ oc get podmonitor,prometheusrules -n seldon-system
NAME AGE
podmonitor.monitoring.coreos.com/seldon-deploy-monitor 6d
NAME AGE
prometheusrule.monitoring.coreos.com/deploy-infra-alerts 2d21h
prometheusrule.monitoring.coreos.com/deploy-user-alerts 2d21h
prometheusrule.monitoring.coreos.com/seldon-drift-alerts 2d21h
Verify that following PodMonitor and PrometheusRules exist in every model namespace:
$ oc get podmonitor,prometheusrules -n <model namespace>
NAME AGE
podmonitor.monitoring.coreos.com/seldon-podmonitor 7d20h
podmonitor.monitoring.coreos.com/seldon-drift-detector 7d20h
podmonitor.monitoring.coreos.com/seldon-podmonitor-metrics-server 7d20h
NAME AGE
prometheusrule.monitoring.coreos.com/seldon-deployment-usage-rules 7d20h
Validating Kafka
Verify that following pods are present in seldon-kafka namespace:
This set of Helm values of Seldon Enterprise Platform is designed to work properly on the OpenShift 4.13 platform with all dependencies installed and configured as described in this document.
Please only set Namespace Authorization using labels (rbac.nsLabelsAuth.enabled: true entry) in your Helm values file if you are not going to use OPA Policy Authorization.
Note:
Only set Namespace Authorization using labels (rbac.nsLabelsAuth.enabled: true entry) in your Helm values file if you are not going to use OPA Policy Authorization.
Contact your Seldon account manager or sales representative to access the image.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: seldon-deployment-usage-rules
labels:
prometheus: k8s
role: record-rules
spec:
groups:
- name: deployment-usage.rules
interval: 3m
rules:
- record: deployment_container_count
expr: sum by (namespace, name) (kube_pod_container_info * on (namespace, pod) group_left(name) label_replace(kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}, "name", "$1", "label_seldon_deployment_id", "(.+)"))
labels:
type: "SeldonDeployment"
- record: deployment_memory_usage_bytes
expr: label_replace(sum by (namespace, label_seldon_deployment_id) (container_memory_usage_bytes{container=""} * on (namespace, pod) group_left(label_seldon_deployment_id) kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}), "name", "$1", "label_seldon_deployment_id", "(.+)")
labels:
type: "SeldonDeployment"
- record: deployment_cpu_usage_seconds_total
expr: label_replace(sum by (namespace, label_seldon_deployment_id) (rate(container_cpu_usage_seconds_total{container=""}[2m]) * on (namespace, pod) group_left(label_seldon_deployment_id) kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}), "name", "$1", "label_seldon_deployment_id", "(.+)")
labels:
type: "SeldonDeployment"
- record: deployment_cpu_requests
expr: sum by (namespace, name) (kube_pod_container_resource_requests{resource="cpu", unit="core"} * on (namespace, pod) group_left(name) label_replace(kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}, "name", "$1", "label_seldon_deployment_id", "(.+)"))
labels:
type: "SeldonDeployment"
- record: deployment_cpu_limits
expr: sum by (namespace, name) (kube_pod_container_resource_limits{resource="cpu", unit="core"} * on (namespace, pod) group_left(name) label_replace(kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}, "name", "$1", "label_seldon_deployment_id", "(.+)"))
labels:
type: "SeldonDeployment"
- record: deployment_memory_requests_bytes
expr: sum by (namespace, name) (kube_pod_container_resource_requests{resource="memory", unit="byte"} * on (namespace, pod) group_left(name) label_replace(kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}, "name", "$1", "label_seldon_deployment_id", "(.+)"))
labels:
type: "SeldonDeployment"
- record: deployment_memory_limits_bytes
expr: sum by (namespace, name) (kube_pod_container_resource_limits{resource="memory", unit="byte"} * on (namespace, pod) group_left(name) label_replace(kube_pod_labels{label_app_kubernetes_io_managed_by="seldon-core"}, "name", "$1", "label_seldon_deployment_id", "(.+)"))
labels:
type: "SeldonDeployment"
Prometheus Rules for Alerting
Save file as user-alerts.yaml:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus: k8s
role: alert-rules
name: deploy-user-alerts
spec:
groups:
- name: deploy-user-alerts.rules
rules:
- alert: ModelHighErrorRate
# This matches a regex for 5XX errors, and calculates the percentage over 5 minutes.
# It requires a percentage higher than 30 for at least 100 requests to fire.
expr: (sum(rate(seldon_api_executor_client_requests_seconds_count{code=~"5[0-9]{2}"}[5m])) by (seldon_deployment_id)
/
sum(rate(seldon_api_executor_client_requests_seconds_count[5m])) by (seldon_deployment_id) * 100.0) > 30
and
sum(increase(seldon_api_executor_client_requests_seconds_count[5m])) by (seldon_deployment_id) > 100
for: 1m
annotations:
title: 'High error rate on deployed model.'
description: 'Model {{ $labels.seldon_deployment_id }} has an internal error rate of greater than 30% for more than 100 requests total.'
labels:
severity: 'critical'
type: 'user'
- alert: TestAlertNoActionRequired
expr: increase(deploy_alerting_trigger_test_alert[3m]) > 1
for: 1m
annotations:
title: 'Test alert, safe to ignore.'
description: 'This is a test alert, used to verify the alerting system is working correctly - it will resolve itself and no action is required.'
labels:
severity: 'warning'
type: 'user'
Save file as infra-alerts.yaml:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus: k8s
role: alert-rules
name: deploy-infra-alerts
spec:
groups:
- name: deploy-infra-alerts.rules
rules:
- alert: MetasyncerNotSyncing
expr: sum(increase(deploy_metasyncer_processed_sync_total[11m])) < 1
for: 11m
# Sync window is 10 minutes, we measure increase over 11m and expect failure condition for 11m to prevent edge cases. Can't measure over 20m for 1m as it would alert at initial startup.
annotations:
title: 'The runtime metasyncer has not synced for two cycles.'
description: 'Deployment information from Kubernetes and model metadata information from Postgres has not been synchronised for more than 20 minutes. Functionality depending on this, like project-based authorisation and the metadata API, might be affected.'
labels:
severity: 'critical'
type: 'infra'
- alert: DeployIsDown
expr: absent(up{container="seldon-deploy"})
for: 1m
annotations:
title: 'Enterprise Platform server is down.'
description: 'Enterprise Platform is not running, check the pods in Kubernetes for status.'
labels:
severity: 'critical'
type: 'infra'
- alert: DeployApiHighErrorRate
# This matches a regex for 5XX errors, and calculates the percentage over 5 minutes.
# It requires a percentage higher than 30 for at least 100 requests to fire.
expr: (sum(rate(http_request_duration_seconds_count{code=~"5[0-9]{2}"}[5m])) by (handler)
/
sum(rate(http_request_duration_seconds_count[5m])) by (handler) * 100.0) > 30
and
sum(increase(http_request_duration_seconds_count[5m])) by (handler) > 100
for: 1m
annotations:
title: 'High error rate on Enterprise Platform api.'
description: 'The Enterprise Platform api for handler {{ $labels.handler }} has an internal error rate of greater than 30% for more than 100 requests total.'
labels:
severity: 'critical'
type: 'infra'
- alert: DeployMetadataMigrationsFailed
expr: increase(deploy_metadata_sql_migrations_total{status="failure"}[5m]) > 1
for: 5m
annotations:
title: 'Enterprise Platform Metadata SQL Migrations Failed'
description: 'Enterprise Platform has failed to perform SQL migrations on the metadata database {{ $value }} times in the last 5 minutes.'
labels:
severity: 'warning'
type: 'infra'
- alert: DeployOPADynamicPolicyUpdateFailed
expr: increase(deploy_opa_policies_updates_total{status="failure"}[5m]) > 0
for: 5m
annotations:
title: 'Enterprise Platform OPA Dynamic Policy Update Failed'
description: 'Enterprise Platform has failed updating the OPA policies from the dynamic policy config {{ $value }} times in the last 5 minutes.'
labels:
severity: 'warning'
type: 'infra'
Save file as drift-alerts.yaml:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: seldon-drift-alerts
spec:
groups:
- name: seldon-dd-alerts.rules
rules:
- alert: DriftDetectedV1
expr: increase(seldon_metric_drift_counter_total[1m]) > 1
annotations:
title: 'Drift is occurring in {{ $labels.deployment_name }} deployment.'
description: 'Drift is happening within deployment {{ $labels.deployment_name }} in the {{ $labels.seldon_deployment_namespace }} namespace (Seldon Core v1).'
labels:
severity: 'warning'
type: 'user'
- alert: DriftDetectedV2
expr: increase(seldon_model_drift_count[1m]) > 1
annotations:
title: 'Drift is occurring in {{ $labels.model_name }} detector.'
description: 'Drift is happening within detector {{ $labels.model_name }} in the {{ $labels.namespace }} namespace (Seldon Core v2).'
labels:
severity: 'warning'
type: 'user'
Troubleshooting
Core v2 Pipelines
If you see an error from the producer in the Pipeline gateway complaining about not enough insync replicas then the replication factor Seldon is using is less than the cluster setting for min.insync.replicas which for a default AWS MSK cluster defaults to 2. Ensure this is equal to that of the cluster. This value can be set in the seldon-charts/seldon-core-v2-setup Helm chart with kafka.topics.replicationFactor.
Prometheus Metrics
If you do not see any metrics in Seldon Enterprise Platform first check if all NetworkPolicy, PodMonitor and kind: PrometheusRule resources are configured correctly. If you still do not see any metrics verify if JWT token given to Seldon Enterprise Platform is correct.