Platform Manager

Functionality

Overview

Platform Manager is used to administer the Axual Platform. It is used to perform tasks like:

Apply topic configuration
Allow producer/consumer to access a topic
Synchronize Instance

README & Changelog

More details are in the Platform Manager 16.0.0 Readme and the Platform Manager 16.0.0 Changelog

Example use

As a developer that creates many topics per week, I get tired of clicking through the UI. Instead, I set up a CI/CD pipeline to create topics via API calls.

API

The Platform Manager API is documented here.

Download OpenAPI Specification

Installation

The Platform Manager depends on Database Support and Vault for basic functionality, requires API Gateway, Topic Browse, Apache Kafka

Helm Charts

As part of the Governance Helm charts, the API Gateway can be installed following the guide Installation and Configuration of Axual Platform.

Configuration

Vault

Vault configuration is detailed in the Platform Manager README.

Flink SQL Application Deployment Sizes

Flink SQL applications run with one of a set of predefined sizes, each setting the CPU and memory of the application’s TaskManagers. Platform Manager ships by default with five sizes, and applies the default size when an application deployment doesn’t specify one.

Configuring Deployment Sizes

To override the default available sizes, set deployment-sizes under the platform-manager key of the governance values.yaml. The example lists the sizes Platform Manager ships with:

platform-manager:
  config:
    axual:
      application-deployment:
        flink:
          deployment-sizes:
            - name: "XS"
              cpu: "0.5"
              memory: 2Gi
            - name: "S"
              default-size: true
              cpu: "1"
              memory: 4Gi
            - name: "M"
              cpu: "2"
              memory: 8Gi
            - name: "L"
              cpu: "3"
              memory: 12Gi
            - name: "XL"
              cpu: "4"
              memory: 16Gi

Your list replaces the shipped sizes entirely, so include every size you want to offer. Mark only one size with default-size: true. If no size is marked, the first size in the list becomes the default.

Override the sizes only to change their CPU or memory values or to pick a different default. Give CPU values in cores, for example 0.5, 1 or 2.

Flink SQL Application Kubernetes Pods Spec

Platform Manager can apply a set of Kubernetes pod options to every Flink SQL deployment it creates, for example affinity and tolerations that pin Flink jobs to dedicated nodes. When the option is unset, Platform Manager sends no pod options and the Ververica Platform defaults apply.

Configuring Kubernetes Pods Spec

To set the pod options, add kubernetes.pods under the platform-manager key of the governance values.yaml. Platform Manager passes the value unchanged to Ververica Platform as spec.template.spec.kubernetes.pods, so write it as a YAML block string (|) to keep the Kubernetes camel-case keys:

platform-manager:
  config:
    axual:
      applicationlifecycle:
        flink:
          kubernetes:
            pods: |
              affinity:
                nodeAffinity:
                  requiredDuringSchedulingIgnoredDuringExecution:
                    nodeSelectorTerms:
                      - matchExpressions:
                          - key: axual.io/dedicated
                            operator: In
                            values: ["flink"]
              tolerations:
                - key: "axual.io/dedicated"
                  operator: "Equal"
                  value: "flink"
                  effect: "NoSchedule"

The value is a mapping of Ververica Platform Kubernetes pod options, such as affinity, nodeSelector, tolerations and labels. The affinity and tolerations fields follow the Kubernetes schema; see Assigning Pods to Nodes and Taints and Tolerations.

Platform Manager fails to start if the value isn’t valid YAML or isn’t a mapping. Ververica Platform validates the options only when it creates the Flink cluster, so a well-formed but wrong option shows up as a failed application deployment.

KSML Application Deployment Sizes

KSML applications run with one of a set of predefined sizes, each setting the Kubernetes CPU and memory resources of the application. Platform Manager ships by default with five sizes, and applies the default size when an application deployment doesn’t specify one.

Configuring Deployment Sizes

To change the available sizes, set deployment-sizes under the platform-manager key of the governance values.yaml. The example lists the sizes Platform Manager ships with:

platform-manager:
  config:
    axual:
      application-deployment:
        ksml:
          deployment-sizes:
            - name: "XS"
              cpu: 0.5
              memory: 2Gi
            - name: "S"
              default-size: true
              cpu: 1
              memory: 4Gi
            - name: "M"
              cpu: 2
              memory: 8Gi
            - name: "L"
              cpu: 3
              memory: 12Gi
            - name: "XL"
              cpu: 4
              memory: 16Gi

Override the sizes only to change their CPU or memory values or to pick a different default. Give CPU values in cores, for example 0.5, 1 or 2.

KSML Application Deployment State Store Sizes

State stores hold the state of stateful KSML operations, such as aggregations, joins and windowing. The state store sizes are the persistent volume sizes, in megabytes (MB), that KSML application owners can choose from in Self-Service.

Configuring State Store Sizes

To change the available state store sizes, set sizes-megabytes under the platform-manager key of the governance values.yaml. The example lists the sizes Platform Manager ships with:

platform-manager:
  config:
    axual:
      application-deployment:
        ksml:
          streams-state-store:
            sizes-megabytes:
              - 256
              - 512
              - 1024
              - 2048
              - 4096

Your list replaces the shipped sizes entirely, so include every size you want to offer.

Override the state store sizes only to add or change the options offered to KSML applications. Give every value in megabytes (MB).

KSML Failure Notifications

If Notifications are enabled, KSML applications can be monitored for failure statuses. Platform Manager checks the state of every KSML deployment on a schedule and throttles how often it notifies the application owners about the same deployment.

Both settings go under the platform-manager key of the governance values.yaml. The example shows the defaults: a state check every 5 minutes, and at most one notification per deployment per hour.

platform-manager:
  config:
    axual:
      applicationlifecycle:
        ksml:
          state:
            poll:
              cron: "0 */5 * ? * *"   (1)
      notification:
        ksml:
          max-frequency-minutes: 60  (2)

1	Cron expression for the KSML deployment state check, in the six-field Spring format that starts with seconds. The same check refreshes the KSML deployment status Self-Service shows, so a longer interval also delays status updates.
2	Minimum interval, in minutes, between two failure notifications for the same deployment.

Platform Manager versions before 16.0.0 read these settings from scheduler.deployment.report.failure.ksml.cron and scheduler.deployment.report.failure.ksml.max-frequency-minutes. From 16.0.0 those keys are fallbacks that the shipped defaults always override, so setting them has no effect.

Security

Authentication Methods

The authentication methods provided by the platform can be configured through the configuration of Platform Manager. SCRAM_SHA_256, SCRAM_SHA_512, and OAUTH_BEARER are available only after their support is enabled on the broker level. By default, only SSL is configured as supported authentication method follow below steps to modify authentication methods:

Enable additional listeners on the brokers.

Edit the values.yaml of the Platform Manager charts and add availableAuthMethods as such:

mgmt:
  api:
    axual:
      availableAuthMethods: 'SSL, SCRAM_SHA_512, SCRAM_SHA_256, OAUTH_BEARER'

Using TLS/SSL between Platform Manager and Remote DB

To use TLS/SSL between Remote DB and Platform Manager follow the steps below:

Change useSSL=true in platform/charts/mgmt/charts/api/values.yaml for Platform Manager

mgmt:
  api:
    spring:
      datasource:
        urlSuffix:
          useSsl: true

Add enabledTLSProtocols to urlSuffix as a comma-separated list, for example: enabledTLSProtocols=TLSv1.2,TLSv1.3
```
mgmt:
  api:
    spring:
      datasource:
        urlSuffix:
          enabledTLSProtocols: TLSv1.2,TLSv1.3
```
When enabling TLSv1.3 for DB connection, we need to be sure that TLSv1.3 is a valid client and https protocols in the jvmArguments"
```
mgmt:
  api:
    jvmArguments: "-Djdk.tls.client.protocols=TLSv1.2,TLSv1.3 -Dhttps.protocols=TLSv1.2,TLSv1.3"
```

Connect Reconciliation Jobs

When Connect support has been enabled, the Platform Manager uses two jobs to keep plugins and deployments in sync.

The plugins job retrieves the available plugins from an Axual Connect instance and updates the Self-Service.
The deployments job retrieves the connector status in an Axual Connect instance and compares it with the application deployment status, if they do not match, it updates the application deployment status in the Self-Service.

Edit the values.yaml for Platform Manager and add the following configuration to change the Quarts expressions, for example:

axual-governance:
  platform-manager:
    config:
      scheduler:
        reconciliation:
          connect:
            #  every 30 minutes
            deployments:
              cron: 0 */30 * ? * *
            plugins:
              cron: 0 0 */1 ? * *

Audit logging

Audit logging is used to create an audit trail on user actions to show who exactly did what on secure resources. Within Axual Platform the Platform Manager writes audit logs with the io.axual.auditing.logging package, these can be filtered out for long-term storage if required.

Externalize Audit Event Logs

Platform Manager can write audit events to a rolling log file in addition to storing them in the database. This makes it possible to ship audit events to an external system without polling the database.

How it works

When auditLog.enabled is set to true in the Platform Manager Helm values, a Logback RollingFileAppender is activated. Every audit event that Platform Manager records is serialized to JSON and appended to the active log file. The appender rolls the file daily and compresses older files; files older than logMaxHistory days are deleted automatically.

The log file is written to an emptyDir volume mounted at /logs. This volume is ephemeral: its contents exist only for the lifetime of the pod and are lost on restart. To persist or forward the events you need to add a sidecar container that reads from the same volume and ships the data externally.

Enabling audit log file writing

Set the following in the Platform Manager values.yaml:

platform-manager:
  auditLog:
    enabled: true                                           (1)
    logFile: /logs/audit-events.log                        (2)
    logFileNamePattern: /logs/audit-events.log.%d{yyyy-MM-dd}.gz  (3)
    logMaxHistory: 30                                      (4)
    logPattern: "%m%n"                                     (5)

1	Activates the `RollingFileAppender`; default is `false`.
2	Path of the active (current) log file inside the container.
3	Logback rolling filename pattern. Files are rolled daily and compressed with gzip.
4	Number of days to retain rolled files before Logback deletes them.
5	Encoder pattern for each log line. The default `%m%n` emits the raw JSON audit entry followed by a newline; change this only if your downstream tooling requires a different format.

When auditLog.enabled is false (the default) the logger io.axual.governance.audit.events is set to OFF and no file is written.

Shipping logs with a sidecar container

Because the /logs volume is an emptyDir, you must add a log shipper sidecar to forward events before the pod is recycled.

Metrics

The Platform Manager exposes the default Prometheus metrics via the Spring Boot Actuator, without additional custom metrics.
More info about Monitoring & Metrics here.