API Connect on Kubernetes, OpenShift, and Cloud Pak for Integration

Understand the Kubernetes artifacts that make up the analytics subsystem, and how to configure your AnalyticsCluster CR.

The AnalyticsCluster Custom Resource (CR)

Your analytics subsystem is defined by a Custom Resource (CR) called AnalyticsCluster. Throughout this documentation, the AnalyticsCluster CR is also referred to as the analytics CR.

Certain analytics features are configured in the AnalyticsCluster CR. How you edit the CR depends on your platform:

Kubernetes and OpenShift individual subsystem CRs: Edit the AnalyticsCluster directly.
Cloud Pak for Integration and OpenShift top-level CR: Edit the analytics section of the top-level CR. When saved, the changes to the top-level CR are applied to AnalyticsCluster CR. If you change the AnalyticsCluster CR directly, changes can be overwritten by the top-level CR.

Note: For convenience, the alias a7s can be used instead of AnalyticsCluster when you edit the CR. For example:

kubectl edit a7s

instead of:

kubectl edit AnalyticsCluster

The properties that you can configure in the AnalyticsCluster CR are listed in Analytics CR properties reference.

Ingresses

The analytics subsystem has one ingress, called the ingestion endpoint. The ingestion endpoint serves requests coming from both the management subsystem and the gateway. The management subsystem communicates with the ingestion endpoint to query API event data stored by the analytics subsystem, and also to manage the analytics subsystem. The gateway sends API event data to the ingestion endpoint.

The ingestion endpoint is listed as ai-endpoint or <instance name>-ai-endpoint in the output of kubectl get ingress.

Note: In OpenShift, routes are used instead of ingresses. The functions of the ingestion endpoint are the same for both the Kubernetes ai-endpoint ingress and the OpenShift ai-endpoint route.

Pods

The following table shows the Kubernetes pods that make up an analytics subsystem:

Table 1. Analytics pods
Name	Description
`osinit`	OpenSearch initialization job. This pod is in `completed` state after installation.
`oscron`	Manages the jobs that transform API event data into summary data. Runs every 15 minutes.
`director`	Manages the analytics subsystem. The director pod serves all requests that come from the management subsystem, such as: initial subsystem registration, queries for analytics data, management of saved queries, and changes to retention settings.
`ingestion`	Logstash-based data pipeline that receives the API event data from the gateway, applies any ingestion filters that the user configures, and forwards the events to the storage pods and/or to third-party offload targets.
`mtls-gw`	Secures all communication that arrives on the analytics ingestion endpoint, forwarding communication from the management subsystem to the `director` pod, and communication from the gateway to the `ingestion` pod.
`storage`	The `storage` pods contain the OpenSearch database that stores all the analytics data. By default the storage pods also run the OpenSearch cluster management tasks. If dedicated storage is enabled the OpenSearch cluster management tasks are done by the `storage-os-master` pods, and the `storage` pods contain just the analytics data.
`storage-os-master`	The `storage-os-master` pod exists only on deployments where dedicated storage is enabled. The `storage-os-master` pods manage the OpenSearch cluster, while the `storage` pods are dedicated to the storage of the analytics data.
`warehouse`	The `warehouse` pod stores your local backups and stages them for transmission to your remote SFTP server or object-store.

PersistentVolumeClaims (PVCs)

The following table describes the PVCs that are created for the analytics subsystem:

Table 2. Analytics PVCs
Name	Description
`data-analytics-storage-<integer>`	The PVC that stores your analytics data. A `data-analytics-storage-<integer>` PVC is created for each analytics `storage` pod. The `<integer>` is the replica number, starting from 0.
`data-analytics-storage-os-master-<integer>`	If dedicated storage is enabled, then the `storage-os-master` PVCs are created. Each `storage-os-master` PVC corresponds to a `storage-os-master` pod. The `<integer>` corresponds to the pod replica number, starting from 0. The PVC stores data that is related to the management of your OpenSearch cluster.
`data-analytics-ingestion-<integer>`	If the persistent queue feature is enabled, a `data-analytics-ingestion-<integer>` PVC is created for each `ingestion` pod. The `data-analytics-ingestion-<integer>` PVC stores API event data temporarily when the `ingestion` pod is unable to forward the data to the `storage` pods. The `<integer>` corresponds to the pod replica number, starting from 0.
`data-a7s-warehouse`	If backups are enabled, then local backups are stored on this PVC.

Certificates

The following table describes the certificates that are used by the analytics subsystem:

Table 3. Analytics certificates
Certificate name	Issuer	Description
`analytics-ai-endpoint or a7s-ai-endpoint`	`ingress-issuer`	Server certificate used on the analytics ingestion endpoint, in the `mtls-gw` pod. Management and gateway subsystems communicate with the analytics subsystem on this endpoint. The client certificates that are used by the management and gateway subsystems must use the same CA certificate as the `analytics-ai-endpoint` certificate. If this certificate is updated, restart the `mtls-gw` pod for the update to take effect.
`analytics-ca or a7s-ca`	`selfsigning-issuer`	The issuer for the `analytics-client` and `analytics-server` certificates. Communication between analytics subsystem pods fails if there is a problem with this certificate. If you update this certificate, you must then update the `analytics-client` and `analytics-server` server certificates, and then ensure that the following pods are restarted: `storage`: Restarts automatically. `warehouse`: Restarts automatically. `ingestion`: Restarts automatically. `director`: Restart manually.
`analytics-client or a7s-client`	`analytics-ca`	Client certificate used in communication between analytics subsystem pods. Communication between analytics subsystem pods fails if there is a problem with this certificate. If this certificate is updated, then the `storage`, `warehouse` and `ingestion` pods restart automatically. You must manually restart the `director` pod.
`analytics-server or a7s-server`	`analytics-ca`	Server certificate used in communication between analytics subsystem pods. Communication between analytics subsystem pods fails if there is a problem with this certificate. Required DNS names within the SAN section are: `.<namespace> .<namespace>.svc .<namespace>.svc.cluster.local .<instance name>-server.<namespace>.svc *.<instance name>-server.<namespace>.svc.cluster.local <instance name>-server <instance name>-storage <instance name>-director <instance name>-ingestion <instance name>-mtls-gw <instance name>-storage-os-master <instance name>-warehouse` If this certificate is updated, then the `storage`, `warehouse` and `ingestion` pods restart automatically. You must manually restart the `director` pod.

For more information about certificates in API Connect, see API Connect certificates.