Upgrading DataPower Operator and Operand independently of the APIC
API Connect and DataPower each have their own Operator, which manages their respective products. The Operand is the actual product that users interact with. Before deploying an Operand, its corresponding Operator must be installed at a specific version. While Operators and Operands can have different versions, each Operator supports a specific range of Operand versions. This separation allows customers to upgrade the Operator and Operand independently, reducing upgrade times. The primary use case is that customers want the flexibility to upgrade API Connect (management plane) and DataPower (data plane) separately. This allows them to either minimize the upgrade window or apply fixes to one component without affecting the other. When DataPower is deployed through API Connect in Kubernetes, API Connect strictly controls the versions of both the DataPower Operator and Operand, ensuring that management and data plane upgrades occur simultaneously. In OpenShift Container Platform and Cloud Pak for Integration, API Connect still handles Operator installation, but customers can change the Operator version without relying on Helm. The Operand upgrade process remains the same across Kubernetes, OpenShift Container Platform, and Cloud Pak for Integration.
Operand upgrade
You can upgrade the DP operand while APIC controls the DP operator version, see Overriding the default DataPower image, version, and license. The operand version that you specify must be compatible with the installed DataPower Operator version. For compatibility information, see DP Operator and Operand Compatibility matrix. If operand is not compatible, you must update the DataPower Operator.
You can update the GatewayCluster CR to override the image, version, and license information for the Gateway subsystem.
- Create the Secret using your own Entitlement Key in the same namespace as the GatewayCluster
subsystem.
oc create secret docker-registry \ ibm-entitlement-key \ --docker-username=cp \ --docker-password=<entitlement-key> \ --docker-server=cp.icr.io
- Specify your secret in GatewayCluster CR under
imagePullSecrets:
property to pull the operand images from the registry.apiVersion: gateway.apiconnect.ibm.com/v1beta1 kind: GatewayCluster metadata: name: api-gateway spec: dataPowerOverride: version: 10.5.0.3 license: X-XXXX-XXXXXX imagePullSecrets: - ibm-entitlement-key
- When a custom registry is used, or if you want to a specific image (for urgent/hot fixes), it is
important to specify the image field in the override. This scenario is not
typical.
apiVersion: gateway.apiconnect.ibm.com/v1beta1 kind: GatewayCluster metadata: name: api-gateway spec: dataPowerOverride: image: customregistry.com/custom-image-datapower:10.5.0.3 version: 10.5.0.3 license: X-XXXX-XXXXXX imagePullSecrets: - ibm-entitlement-key
Operator upgrade
To install DP operator or operand at different times than APIC with greater flexibility in operand version, do the following steps. So that you can control the version of operator rather than APIC deciding operator version.
API Connect Operator version | API Connect Operand version | DataPower minimum Operator version | DataPower supported Operand version |
---|---|---|---|
5.2.0 | 10.0.8.0 | 1.11.0 | DP Operator and Operand Compatibility matrix |
If you previously used the Helm Chart to install the DataPower Operator, then to upgrade Operator, see Upgrading with Helm.
kubectl delete -f ibm-datapower.yaml -n <namespace>
Install the DataPower Operator by using the Helm chart, see Installation with Helm.
Use new CRD during upgrade
If you use Helm chart to upgrade DP operator, use different file to apply new APIC CRDs during APIC upgrades instead of using file to apply combined APIC and DP operator CRDs. See Upgrading subsystems on native Kubernetes.
kubectl apply -f ibm-apiconnect-only-crds.yaml
kubectl apply -f ibm-apiconnect-crds.yaml