Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 21. Deploying Kogito microservices on Red Hat OpenShift Container Platform

As a business rules developer, you can deploy Kogito microservices on Red Hat OpenShift Container Platform for cloud implementation. The Red Hat Decision Manager Kogito Operator automates many of the deployment steps for you or guides you through the deployment process.

Prerequisites

  • Red Hat OpenShift Container Platform 4.6 or 4.7 is installed.
  • The OpenShift project for the deployment is created.

21.1. Kogito on Red Hat OpenShift Container Platform

You can deploy Kogito microservices on Red Hat OpenShift Container Platform for cloud implementation. In this architecture, Kogito microservices are deployed as OpenShift pods that you can scale up and down individually to provide as few or as many containers as required for a particular service.

To help you deploy your Kogito microservices on OpenShift, Red Hat Decision Manager provides Red Hat Process Automation Manager Kogito Operator. This operator guides you through the deployment process. The operator is based on the Operator SDK and automates many of the deployment steps for you. For example, when you provide the operator with a link to the Git repository that contains your application, the operator automatically configures the components required to build your project from source and deploys the resulting services.

To install the Red Hat Process Automation Manager Kogito Operator in OpenShift web console, go to Operators OperatorHub in the left menu, search for and select RHPAM Kogito Operator, and follow the on-screen instructions to install the latest operator version.

21.2. OpenShift deployment options with the Red Hat Decision Manager Kogito Operator

After you create your Kogito microservices as part of a business application, you can use the Red Hat OpenShift Container Platform web console to deploy your microservices. The Red Hat Decision Manager Kogito Operator page in the OpenShift web console guides you through the deployment process.

The Red Hat Process Automation Manager Kogito Operator supports the following options for building and deploying Kogito microservices on Red Hat OpenShift Container Platform:

  • Git source build and deployment
  • Binary build and deployment
  • Custom image build and deployment
  • File build and deployment

21.2.1. Deploying Kogito microservices on OpenShift using Git source build and OpenShift web console

The Red Hat Process Automation Manager Kogito Operator uses the following custom resources to deploy domain-specific microservices (the microservices that you develop):

  • KogitoBuild builds an application using the Git URL or other sources and produces a runtime image.
  • KogitoRuntime starts the runtime image and configures it as per your requirements.

In most use cases, you can use the standard runtime build and deployment method to deploy Kogito microservices on OpenShift from a Git repository source, as shown in the following procedure.

Note

If you are developing or testing your Kogito microservice locally, you can use the binary build, custom image build, or file build option to build and deploy from a local source instead of from a Git repository.

Prerequisites

  • The Red Hat Process Automation Manager Kogito Operator is installed.
  • The application with your Kogito microservices is in a Git repository that is reachable from your OpenShift environment.
  • You have access to the OpenShift web console with the necessary permissions to create and edit KogitoBuild and KogitoRuntime.

  • (Quarkus only) The pom.xml file of your project contains the following dependency for the Quarkus smallrye-health extension. This extension enables the liveness and readiness probes that are required for Quarkus-based projects on OpenShift.

    SmallRye Health dependency for Quarkus applications on OpenShift

    <dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-smallrye-health</artifactId>
</dependency>
    Copy to Clipboard

Procedure

  1. Go to Operators Installed Operators and select RHPAM Kogito Operator.
  2. To create the Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

  3. In the application window, use Form View or YAML View to configure the build definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-quarkus  # Application name
spec:
  type: RemoteSource
  gitSource:
    uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
    contextDir: dmn-quarkus-example  # Git folder location of application
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
  type: RemoteSource
  gitSource:
    uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
    contextDir: dmn-springboot-example  # Git folder location of application
    Copy to Clipboard

    Note

    If you configured an internal Maven repository, you can use it as a Maven mirror service and specify the Maven mirror URL in your Kogito build definition to shorten build time substantially: 

    spec:
  mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/
    Copy to Clipboard

    For more information about internal Maven repositories, see the Apache Maven documentation.

  4. After you define your application data, click Create to generate the Kogito build.

    Your application is listed in the KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

  5. To create the Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

  6. In the application window, use Form View or YAML View to configure the microservice definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-quarkus  # Application name
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
    Copy to Clipboard

    Note

    In this case, the application is built from Git and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

  7. After you define your application data, click Create to generate the Kogito microservice.

    Your application is listed in the Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

  8. In the left menu of the web console, go to Builds Builds to view the status of your application build.

    You can select a specific build to view build details.

    Note

    For every Kogito microservice that you create for OpenShift deployment, two builds are generated and listed in the Builds page in the web console: a traditional runtime build and a Source-to-Image (S2I) build with the suffix -builder. The S2I mechanism builds the application in an OpenShift build and then passes the built application to the next OpenShift build to be packaged into the runtime container image. The Kogito S2I build configuration also enables you to build the project directly from a Git repository on the OpenShift platform.

  9. After the application build is complete, go to Workloads Deployments to view the application deployments, pod status, and other details.

  10. After your Kogito microservice is deployed, in the left menu of the web console, go to Networking Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Kogito microservices with your business automation solutions as needed.

21.2.2. Deploying Kogito microservices on OpenShift using binary build and OpenShift web console

OpenShift builds can require extensive amounts of time. As a faster alternative for building and deploying your Kogito microservices on OpenShift, you can use a binary build.

The operator uses the following custom resources to deploy domain-specific microservices (the microservices that you develop):

  • KogitoBuild processes an uploaded application and produces a runtime image.
  • KogitoRuntime starts the runtime image and configures it as per your requirements.

Prerequisites

  • The Red Hat Process Automation Manager Kogito Operator is installed.
  • The oc OpenShift CLI is installed and you are logged in to the relevant OpenShift cluster. For oc installation and login instructions, see the OpenShift documentation.
  • You have access to the OpenShift web console with the necessary permissions to create and edit KogitoBuild and KogitoRuntime.

  • (Quarkus only) The pom.xml file of your project contains the following dependency for the Quarkus smallrye-health extension. This extension enables the liveness and readiness probes that are required for Quarkus-based projects on OpenShift.

    SmallRye Health dependency for Quarkus applications on OpenShift

    <dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-smallrye-health</artifactId>
</dependency>
    Copy to Clipboard

Procedure

  1. Build an application locally.
  2. Go to Operators Installed Operators and select RHPAM Kogito Operator.
  3. To create the Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

  4. In the application window, use Form View or YAML View to configure the build definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-quarkus  # Application name
spec:
  type: Binary
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
  type: Binary
    Copy to Clipboard

  5. After you define your application data, click Create to generate the Kogito build.

    Your application is listed in the KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

  6. Upload the built binary using the following command: 

    $ oc start-build example-quarkus --from-dir=target/ -n namespace
    Copy to Clipboard
    • from-dir is equals to the target folder path of the built application.
    • namespace is the namespace where KogitoBuild is created.
  7. To create the Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

  8. In the application window, use Form View or YAML View to configure the microservice definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-quarkus  # Application name
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
    Copy to Clipboard

    Note

    In this case, the application is built locally and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

  9. After you define your application data, click Create to generate the Kogito microservice.

    Your application is listed in the Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

  10. In the left menu of the web console, go to Builds Builds to view the status of your application build.

    You can select a specific build to view build details.

  11. After the application build is complete, go to Workloads Deployments to view the application deployments, pod status, and other details.

  12. After your Kogito microservice is deployed, in the left menu of the web console, go to Networking Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Kogito microservices with your business automation solutions as needed.

21.2.3. Deploying Kogito microservices on OpenShift using custom image build and OpenShift web console

You can use custom image build as an alternative for building and deploying your Kogito microservices on OpenShift.

The operator uses the following custom resources to deploy domain-specific microservices (the microservices that you develop):

  • KogitoRuntime starts the runtime image and configures it as per your requirements.

Prerequisites

  • The Red Hat Process Automation Manager Kogito Operator is installed.
  • You have access to the OpenShift web console with the necessary permissions to create and edit KogitoRuntime.

  • (Quarkus only) The pom.xml file of your project contains the following dependency for the Quarkus smallrye-health extension. This extension enables the liveness and readiness probes that are required for Quarkus-based projects on OpenShift.

    SmallRye Health dependency for Quarkus applications on OpenShift

    <dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-smallrye-health</artifactId>
</dependency>
    Copy to Clipboard

Procedure

  1. Build an application locally.

  2. Create Containerfile in the project root folder with the following content:

    Example Containerfile for a Quarkus application

    FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0

ENV RUNTIME_TYPE quarkus

COPY target/quarkus-app/lib/ $KOGITO_HOME/bin/lib/
COPY target/quarkus-app/*.jar $KOGITO_HOME/bin
COPY target/quarkus-app/app/ $KOGITO_HOME/bin/app/
COPY target/quarkus-app/quarkus/ $KOGITO_HOME/bin/quarkus/
    Copy to Clipboard

    Example Containerfile for a Spring Boot application

    FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0

ENV RUNTIME_TYPE springboot

COPY target/<application-jar-file> $KOGITO_HOME/bin
    Copy to Clipboard

    • application-jar-file is the name of the JAR file of the application.

  3. Build the Kogito image using the following command: 

    podman build --tag <final-image-name> -f <Container-file>
    Copy to Clipboard

    In the previous command, final-image-name is the name of the Kogito image and Container-file is name of the Containerfile that you created in the previous step.

  4. Optionally, test the built image using the following command: 

    podman run --rm -it -p 8080:8080 <final-image-name>
    Copy to Clipboard

  5. Push the built Kogito image to an image registry using the following command: 

    podman push <final-image-name>
    Copy to Clipboard
  6. Go to Operators Installed Operators and select RHPAM Kogito Operator.
  7. To create the Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

  8. In the application window, use Form View or YAML View to configure the microservice definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime # Application type
metadata:
  name: example-quarkus # Application name
spec:
  image: <final-image-name> # Kogito image name
  insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime # Application type
metadata:
  name: example-springboot # Application name
spec:
  image: <final-image-name> # Kogito image name
  insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate
  runtime: springboot
    Copy to Clipboard

  9. After you define your application data, click Create to generate the Kogito microservice.

    Your application is listed in the Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

  10. After the application build is complete, go to Workloads Deployments to view the application deployments, pod status, and other details.

  11. After your Kogito microservice is deployed, in the left menu of the web console, go to Networking Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Kogito microservices with your business automation solutions as needed.

21.2.4. Deploying Kogito microservices on OpenShift using file build and OpenShift web console

You can build and deploy your Kogito microservices from a single file, such as a Decision Model and Notation (DMN), Drools Rule Language (DRL), or properties file, or from a directory with multiple files. You can specify a single file from your local file system path or specify a file directory from a local file system path only. When you upload the file or directory to an OpenShift cluster, a new Source-to-Image (S2I) build is automatically triggered.

The operator uses the following custom resources to deploy domain-specific microservices (the microservices that you develop):

  • KogitoBuild generates an application from a file and produces a runtime image.
  • KogitoRuntime starts the runtime image and configures it as per your requirements.

Prerequisites

  • The Red Hat Process Automation Manager Kogito Operator is installed.
  • The oc OpenShift CLI is installed and you are logged in to the relevant OpenShift cluster. For oc installation and login instructions, see the OpenShift documentation.
  • You have access to the OpenShift web console with the necessary permissions to create and edit KogitoBuild and KogitoRuntime.

Procedure

  1. Go to Operators Installed Operators and select RHPAM Kogito Operator.
  2. To create the Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

  3. In the application window, use Form View or YAML View to configure the build definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-quarkus  # Application name
spec:
  type: LocalSource
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito build

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoBuild  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
  type: LocalSource
    Copy to Clipboard

    Note

    If you configured an internal Maven repository, you can use it as a Maven mirror service and specify the Maven mirror URL in your Kogito build definition to shorten build time substantially: 

    spec:
  mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/
    Copy to Clipboard

    For more information about internal Maven repositories, see the Apache Maven documentation.

  4. After you define your application data, click Create to generate the Kogito build.

    Your application is listed in the KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

  5. Upload the file asset using the following command: 

    $ oc start-build example-quarkus-builder --from-file=<file-asset-path> -n namespace
    Copy to Clipboard
    • file-asset-path is the path of the file asset that you want to upload.
    • namespace is the namespace where KogitoBuild is created.
  6. To create the Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

  7. In the application window, use Form View or YAML View to configure the microservice definition.

    At a minimum, define the application configurations shown in the following example YAML file:

    Example YAML definition for a Quarkus application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-quarkus  # Application name
    Copy to Clipboard

    Example YAML definition for a Spring Boot application with Kogito microservices

    apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime  # Application type
metadata:
  name: example-springboot  # Application name
spec:
  runtime: springboot
    Copy to Clipboard

    Note

    In this case, the application is built from a file and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

  8. After you define your application data, click Create to generate the Kogito microservice.

    Your application is listed in the Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

  9. In the left menu of the web console, go to Builds Builds to view the status of your application build.

    You can select a specific build to view build details.

    Note

    For every Kogito microservice that you create for OpenShift deployment, two builds are generated and listed in the Builds page in the web console: a traditional runtime build and a Source-to-Image (S2I) build with the suffix -builder. The S2I mechanism builds the application in an OpenShift build and then passes the built application to the next OpenShift build to be packaged into the runtime container image.

  10. After the application build is complete, go to Workloads Deployments to view the application deployments, pod status, and other details.

  11. After your Kogito microservice is deployed, in the left menu of the web console, go to Networking Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Kogito microservices with your business automation solutions as needed.

21.3. Probes for Kogito microservices on Red Hat OpenShift Container Platform

The probes in Red Hat OpenShift Container Platform verify that an application is working or it needs to be restarted. For Kogito microservices on Quarkus and Spring Boot, probes interact with the application using an HTTP request, defaulting to the endpoints that are exposed by an extension. Therefore, to run your Kogito microservices on Red Hat OpenShift Container Platform, you must import the extensions to provide application availability information for the liveness, readiness, and startup probes.

21.3.1. Adding health check extension for Quarkus-based Kogito microservices on Red Hat OpenShift Container Platform

You can add the health check extension for the Quarkus-based Kogito services on Red Hat OpenShift Container Platform.

Procedure

In a command terminal, navigate to the pom.xml file of your project and add the following dependency for the Quarkus smallrye-health extension:

SmallRye Health dependency for Quarkus applications on Red Hat OpenShift Container Platform

<dependencies>
  <dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-smallrye-health</artifactId>
  </dependency>
</dependencies>
Copy to Clipboard

21.3.2. Adding health check extension for Spring Boot-based Kogito microservices on Red Hat OpenShift Container Platform

You can add the health check extension for the Spring Boot-based Kogito microservices on Red Hat OpenShift Container Platform.

Procedure

In a command terminal, navigate to the pom.xml file of your project and add the following Spring Boot actuator dependency:

Spring Boot actuator dependency for Spring Boot applications on Red Hat OpenShift Container Platform

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
</dependencies>
Copy to Clipboard

21.3.3. Setting custom probes for Kogito microservices on Red Hat OpenShift Container Platform

You can also configure the custom endpoints for the liveness, readiness, and startup probes.

Procedure

  1. Define the probes in the KogitoRuntime YAML file of your project, as shown in the following example:

Example Kogito microservice custom resource with custom probe endpoints

apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this service
kind: KogitoRuntime
metadata:
  name: process-quarkus-example # Application name
spec:
  replicas: 1
  probes:
    livenessProbe:
      httpGet:
        path: /probes/live # Liveness endpoint
        port: 8080
    readinessProbe:
      httpGet:
        path: /probes/ready # Readiness endpoint
        port: 8080
    startupProbe:
      tcpSocket:
        port: 8080
Copy to Clipboard

21.4. Red Hat Process Automation Manager Kogito Operator interaction with Prometheus and Grafana

Kogito in Red Hat Decision Manager provides a monitoring-prometheus-addon add-on that enables Prometheus metrics monitoring for Kogito microservices and generates Grafana dashboards that consume the default metrics exported by the add-on. The RHPAM Kogito Operator uses the Prometheus Operator to expose the metrics from your project for Prometheus to scrape. Due to this dependency, the Prometheus Operator must be installed in the same namespace as your project.

If you want to enable the Prometheus metrics monitoring for your Kogito microservices, add the following dependency to the pom.xml file in your project, depending on the framework you are using:

Dependency for Prometheus Quarkus add-on

<dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>monitoring-prometheus-quarkus-addon</artifactId>
</dependency>
Copy to Clipboard

Dependency for Prometheus Spring Boot add-on

<dependency>
      <groupId>org.kie.kogito</groupId>
      <artifactId>monitoring-prometheus-springboot-addon</artifactId>
</dependency>
Copy to Clipboard

When you deploy a Kogito microservice that uses the monitoring-prometheus-addon add-on and the Prometheus Operator is installed, the Red Hat Process Automation Manager Kogito Operator creates a ServiceMonitor custom resource to expose the metrics for Prometheus, as shown in the following example:

Example ServiceMonitor resource for Prometheus

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: onboarding-service
  name: onboarding-service
  namespace: kogito
spec:
  endpoints:
  - path: /metrics
    targetPort: 8080
    scheme: http
  namespaceSelector:
    matchNames:
    - kogito
  selector:
    matchLabels:
      app: onboarding-service
Copy to Clipboard

You must manually configure your Prometheus custom resource that is managed by the Prometheus Operator to select the ServiceMonitor resource:

Example Prometheus resource

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      app: dmn-drools-quarkus-metrics-service
Copy to Clipboard

After you configure your Prometheus resource with the ServiceMonitor resource, you can see the endpoint scraped by Prometheus in the Targets page in the Prometheus web console. The metrics exposed by the Red Hat Decision Manager service appear in the Graph view.

The Red Hat Process Automation Manager Kogito Operator also creates a GrafanaDashboard custom resource defined by the Grafana Operator for each of the Grafana dashboards generated by the add-on. The app label for the dashboards is the name of the deployed Kogito microservice. You must set the dashboardLabelSelector property of the Grafana custom resource according to the relevant Kogito microservice.

Example Grafana resource

apiVersion: integreatly.org/v1alpha1
kind: Grafana
metadata:
  name: example-grafana
spec:
  ingress:
    enabled: true
  config:
    auth:
      disable_signout_menu: true
    auth.anonymous:
      enabled: true
    log:
      level: warn
      mode: console
    security:
      admin_password: secret
      admin_user: root
  dashboardLabelSelector:
    - matchExpressions:
        - key: app
          operator: In
          values:
            - my-kogito-application
Copy to Clipboard

21.5. Kogito microservice deployment troubleshooting

Use the information in this section to troubleshoot issues that you might encounter when using the operator to deploy Kogito microservices. The following information is updated as new issues and workarounds are discovered.

No builds are running

If you do not see any builds running nor any resources created in the relevant namespace, enter the following commands to retrieve running pods and to view the operator log for the pod:

View Kogito Operator log for a specified pod

// Retrieves running pods
$ oc get pods

NAME                                     READY   STATUS      RESTARTS   AGE
kogito-operator-6d7b6d4466-9ng8t   1/1     Running     0          26m

// Opens Kogito Operator log for the pod
$ oc logs -f kogito-operator-6d7b6d4466-9ng8t
Copy to Clipboard

Verify KogitoRuntime status

If you create, for example, KogitoRuntime application with a non-existing image using the following YAML definition:

Example YAML definition for a KogitoRuntime application

apiVersion: rhpam.kiegroup.org/v1 # Kogito API for this microservice
kind: KogitoRuntime # Application type
metadata:
  name: example # Application name
spec:
  image: 'not-existing-image:latest'
  replicas: 1
Copy to Clipboard

You can verify the status of the KogitoRuntime application using the oc describe KogitoRuntime example command in the bash console. When you run the oc describe KogitoRuntime example command in the bash console, you receive the following output:

Example KogitoRuntime status

[user@localhost ~]$ oc describe KogitoRuntime example
Name:         example
Namespace:    username-test
Labels:       <none>
Annotations:  <none>
API Version:  rhpam.kiegroup.org/v1
Kind:         KogitoRuntime
Metadata:
  Creation Timestamp:  2021-05-20T07:19:41Z
  Generation:          1
  Managed Fields:
    API Version:  rhpam.kiegroup.org/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        .:
        f:image:
        f:replicas:
    Manager:      Mozilla
    Operation:    Update
    Time:         2021-05-20T07:19:41Z
    API Version:  rhpam.kiegroup.org/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        f:monitoring:
        f:probes:
          .:
          f:livenessProbe:
          f:readinessProbe:
        f:resources:
        f:runtime:
      f:status:
        .:
        f:cloudEvents:
        f:conditions:
    Manager:         main
    Operation:       Update
    Time:            2021-05-20T07:19:45Z
  Resource Version:  272185
  Self Link:         /apis/rhpam.kiegroup.org/v1/namespaces/ksuta-test/kogitoruntimes/example
  UID:               edbe0bf1-554e-4523-9421-d074070df982
Spec:
  Image:     not-existing-image:latest
  Replicas:  1
Status:
  Cloud Events:
  Conditions:
    Last Transition Time:  2021-05-20T07:19:44Z
    Message:
    Reason:                NoPodAvailable
    Status:                False
    Type:                  Deployed
    Last Transition Time:  2021-05-20T07:19:44Z
    Message:
    Reason:                RequestedReplicasNotEqualToAvailableReplicas
    Status:                True
    Type:                  Provisioning
    Last Transition Time:  2021-05-20T07:19:45Z
    Message:               you may not have access to the container image "quay.io/kiegroup/not-existing-image:latest"
    Reason:                ImageStreamNotReadyReason
    Status:                True
    Type:                  Failed
Copy to Clipboard

At the end of the output, you can see the KogitoRuntime status with a relevant message.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat