Checking the agent prerequisites on Red Hat OpenShift

Before you install the agent, make sure that all the necessary prerequisite conditions are met. See the following necessary prerequisite conditions:

  1. Check whether you have a supported Red Hat OpenShift version.

  2. Check whether the network requirements for agents are met as described in Outbound network access requirements for Instana SaaS deployments.

Note: You must configure the network as described in both Configuring firewall settings and Instana agent and sensor repositories sections.

Supported Red Hat OpenShift versions

Instana supports Red Hat OpenShift versions that are described in the Life Cycle Phases documentation.

The Instana agent supports the following managed Red Hat OpenShift offerings:

Current versions of installation methods

New versions of the operator and Helm chart are released frequently. To keep up with the updates for fixes, improvements, and new features, make sure that you are running the latest version of the operator or Helm chart.

To find the version information of the installation methods, see the following pages:

Setting up project and service accounts

If you install the agent by using the Instana agent operator, you must first set up a project for the Instana agent and configure its permissions.

Create the instana-agent project, and set the policy permissions to ensure that the instana-agent service account is in the privileged security context. See the following example commands:

oc login -u system:admin
oc new-project instana-agent
oc adm policy add-scc-to-user privileged -z instana-agent -n instana-agent
oc adm policy add-scc-to-user anyuid -z instana-agent-remote -n instana-agent
 

ROSA Hosted Control Planes (HCP) monitoring limitations

When you run workloads on ROSA with Hosted Control Planes (HCP), you cannot access some control plane components from customer workloads.

In ROSA HCP, Red Hat hosts and manages the Kubernetes control plane (API server, controller manager, scheduler, and etcd) in a separate AWS account. Because of this separation:

  • The following control plane namespaces are not accessible from the customer cluster data-plane:
    • openshift-kube-apiserver
    • openshift-kube-controller-manager
    • openshift-kube-scheduler
    • openshift-etcd
  • Their associated pods and services are also not accessible or routable from the customer cluster's data-plane.

Impact on monitoring

The following capabilities remain fully functional:

  • Workload monitoring (pods, deployments, services, namespaces, CRDs, and related resources)
  • Worker-node monitoring
  • Worker-node kubelet metrics (CPU, memory, and PVC usage)
  • Kubernetes API access to user namespaces and resources.

However, the following limitations apply:

  • Control-plane pods are not visible for direct monitoring.
  • Control-plane /metrics endpoints (API server, controller manager, scheduler, and etcd) cannot be scraped.
  • In-cluster agents cannot access performance and health metrics for control-plane nodes.

The ROSA HCP architecture causes these limitations. The platform fully manages and isolates the control plane from the customer VPC.