Upgrading to the latest version of 10.0.1.x-eus on Kubernetes
Upgrade your API Connect deployment to the latest version of 10.0.1.x-eus on native Kubernetes.
Before you begin
- Review the supported upgrade paths and upgrade requirements in Upgrade considerations on native Kubernetes.
Your deployment must be at 10.0.1.7-eus or later before you can upgrade to the newest version of API Connect 10.0.1.x-eus.
- Check your installed Kubernetes version and ensure that it is supported by the latest version of API Connect 10.0.1.x-eus: check IBM API Connect Version 10 software product compatibility requirements. If your Kubernetes version is older than the minimum supported version, then upgrade Kubernetes first.
- The Gateway subsystem remains available during the upgrade of the Management, Portal, and Analytics subsystems.
Procedure
-
Prepare for upgrading the management subsystem:
- Verify that the
pgcluster
is healthy:- Get the name of the
pgcluster
:kubectl get pgcluster -n <APIC_namespace>
The response displays the name of the postgres cluster running in the specified namespace.
- Check the status of the
pgcluster
:kubectl get pgcluster <pgcluster_name> -n <APIC_namespace> -o yaml | grep status -A 2 | tail -n3
The response for a healthy
pgcluster
looks like the following example, where the state isInitialized
:status: message: Cluster has been initialized state: pgcluster Initialized
Important: If thepgcluster
returns any other state, it is not healthy and an upgrade will fail.- If there are any ongoing backup or restore jobs, wait until they complete and then check the
status again. Do not proceed with the upgrade until the status is
Initialized
. - If all of the background jobs complete but the
pgcluster
remains unhealthy, contact IBM Support for assistance.
- Get the name of the
- Verify that the
- Backup the current deployment.
- Wait until the backup completes before starting the upgrade.
- Do not start an upgrade if a backup is scheduled to run within a few hours.
- Do not perform maintenance tasks )such as rotating keys and certificates, restoring from a backup, or starting a new backup) while the upgrade process is running.
- If you used any microservice image overrides in the management CR during a fresh install,
remove the image overrides prior to upgrade. Important: If you used any microservice image overrides in the management CR during a fresh install, these image overrides will be automatically removed by the operator during upgrade. You can apply them again after the upgrade is complete.
- Run the pre-upgrade health check:
- Verify that the
apicops
utility is installed by running the following command to check the current version of the utility:apicops --version
If the response indicates that
apicops
is not available, install it now. See The API Connect operations tool: apicops in the API Connect documentation. - Run the following command to set the KUBECONFIG environment.
export KUBECONFIG=/path/to/kubeconfig
- Run the following command to execute the pre-upgrade
script:
apicops version:pre-upgrade -n <namespace>
If the system is healthy, the results will not include any errors.
- Verify that the
- Obtain the API Connect files from IBM Fix
Central.
From the IBM Fix Central site, download the Docker image-tool file of the API Connect subsystems. Next, you will upload the image-tool file to your Docker local registry. If necessary, you can populate a remote container registry with repositories. Then you can push the images from the local registry to the remote registry.
You will also download the Kubernetes operators, API Connect Custom Resource (CR) templates, and Certificate Manager, for use during deployment configuration.
The following files are used for deployment on native Kubernetes:
- IBM® API Connect <version> for Containers
- Docker images for all API Connect subsystems
- IBM® API Connect <version> Operator Release Files for Containers
- Kubernetes operators and API Connect Custom Resource (CR) templates
- IBM® API Connect <version> Toolkit for <operating_system_type>
- Toolkit command line utility.
Not required during initial installation. After installation, you can download the toolkit directly from the Cloud Manager UI and API Manager UI. See Installing the toolkit for instructions.
The Toolkit is packaged standalone, with Loopback, and with API Designer and Loopback:
- IBM® API Connect <version> Toolkit for <operating_system_type>
- IBM® API Connect <version> Toolkit with Loopback for <operating_system_type>
- IBM® API Connect <version> Toolkit Designer with Loopback for <operating_system_type>
- IBM® API Connect <version> Local Test Environment
- Optional test environment. See Testing an API with the Local Test Environment
- IBM® API Connect <version> Security Signature Bundle File
- Checksum files that you can use to verify the integrity of your downloads.
- Upload the image files that you obtained from Fix Central.
- Load the image-tool image into your Docker local registry:
docker load < apiconnect-image-tool-<version>.tar.gz
Ensure that the registry has sufficient disk space for the files.
- If your Docker registry requires repositories to be created before images
can be pushed, create the repositories for each of the images listed by the image tool. If your
Docker registry does not require creation of repositories, skip this step.
- Run the following command to get a list of the images from
image-tool:
docker run --rm apiconnect-image-tool-<version> version --images
- From the output of each entry of the form
<image-name>:<image-tag>
, use your Docker registry repository creation command to create a repository for<image-name>
.For example in the case of AWS ECR the command would be for each<image-name>
:aws ecr create-repository --repository-name <image-name>
- Run the following command to get a list of the images from
image-tool:
- Upload the image:
- If you do not need to authenticate with the docker registry,
use:
docker run --rm apiconnect-image-tool-<version> upload <registry-url>
- Otherwise, if your docker registry accepts authentication with username and password arguments,
use:
docker run --rm apiconnect-image-tool-<version> upload <registry-url> --username <username> --password <password>
- Otherwise, such as with IBM Container Registry, if you need the image-tool to use your local
Docker credentials, first authenticate with your Docker registry, then upload images with the
command:
docker run --rm -v ~/.docker:/root/.docker --user 0 apiconnect-image-tool-<version> upload <registry-url>
If necessary, review the following installation notes:
- If you do not need to authenticate with the docker registry,
use:
- Load the image-tool image into your Docker local registry:
- Download and decompress IBM® API Connect <version> Operator Release Files for Containers.
- If you are upgrading from 10.0.1.7-eus, upgrade cert-manager to version 1.7.1.
API Connect 10.0.1.7-eus used cert-manager 1.5.1.
- Create a directory named helper_files.
- Extract the contents of the helper_files.zip from the release_files.zip file into the new helper_files directory.
- Run the following command to back up the existing certificates and issuers to a file
called backup.yaml:
kubectl get --all-namespaces -oyaml issuer,clusterissuer,cert,secret > backup.yaml
- Run the following command to verify that you are upgrading from cert-manager
1.5.1:
kubectl get crds certificates.cert-manager.io -o jsonpath='{.metadata.labels.app\.kubernetes\.io\/version}' v1.5.1
- Run the following command to upgrade cert-manager 1.5.1 to version 1.7.1:
kubectl apply -f helper_files/cert-manager-1.7.1.yaml
- If you used customized internal certificates, and are upgrading from
10.0.1.8: The
helper_files/custom-certs-internal.yaml
includes a new certificate that is calleddbClientPrimaryuser
. This new certificate must be created before you update the Management CR.Follow Generate custom internal certificates to update thehelper_files/custom-certs-internal.yaml
file to match your namespace and site name, and apply the newyaml
file with:kubectl apply -f custom-certs-internal.yaml -n <namespace>
Alternatively, add the new certificate to your existingcustom-certs-internal.yaml
and apply it, updating the namespace to match your deployment:--- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: db-client-primaryuser labels: { app.kubernetes.io/instance: "management", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "db-client-primaryuser" } spec: commonName: primaryuser secretName: db-client-primaryuser dnsNames: - "*.<namespace>" - "*.<namespace>.svc" - "primaryuser.<namespace>.svc" - "primaryuser" issuerRef: name: ingress-issuer usages: - "client auth" - "signing" - "key encipherment" duration: 17520h # 2 years renewBefore: 720h # 30 days ---
- Apply the new CRDs from the Operator Release Files for Containers that you
decompressed:
kubectl apply -f ibm-apiconnect-crds.yaml
- Apply the new DataPower Operator YAML into the namespace where the DataPower Operator is
running.
- If the operator is not running in the
default
namespace, open theibm-datapower.yaml
file in a text editor and find and replace all references todefault
the name of your namespace. You do not need to take this action when using Operator Lifecycle Manager (OLM). - Open
ibm-datapower.yaml
in a text editor. Locate theimage:
key in the containers section of the deployment YAML file immediately afterimagePullSecrets:
. Replace the value of theimage:
key with the location of the datapower-operator image, either uploaded to your own registry or pulled from a public registry. kubectl apply -f ibm-datapower.yaml -n <namespace>
The Gateway CR goes to Pending state when the operator is updated. The state of the Gateway CR will change to Running after installation of the API Connect operator in the next step.
For information on troubleshooting the DataPower operator, see Operator not removed in the DataPower operator documentation.
- If the operator is not running in the
- Apply the new API Connect operator YAML into the namespace where the API
Connect operator is running.
- Single-namespace deployment:
- If the operator is not running in the
default
namespace, open theibm-apiconnect.yaml
file in a text editor and find and replace all references todefault
the name of your namespace. You do not need to take this action when using Operator Lifecycle Manager (OLM). - Open
ibm-apiconnect.yaml
in a text editor. Replace the value of eachimage:
key with the location of the apiconnect operator images (from the ibm-apiconnect container and the ibm-apiconnect-init container), either uploaded to your own registry or pulled from a public registry. kubectl apply -f ibm-apiconnect.yaml -n <namespace>
- If the operator is not running in the
- Multi-namespace deployment:
- Locate and open the newly downloaded
ibm-apiconnect-distributed.yaml
in a text editor of choice. Then, find and replace each occurrence of$OPERATOR_NAMESPACE
with<namespace>
, replacing<namespace>
with the desired namespace for the deployment. In this example, the namespace isoperator
. - Also in
ibm-apiconnect-distributed.yaml
, locate theimage:
keys in the containers sections of the deployment yaml right belowimagePullSecrets:
. Replace the placeholder valuesREPLACE-DOCKER-REGISTRY
of theimage:
keys with the docker registry host location of the apiconnect operator image (either uploaded to own registry or pulled from public registry). - Install
ibm-apiconnect-distributed.yaml
with the following commandkubectl apply -f ibm-apiconnect-distributed.yaml
- Locate and open the newly downloaded
When the API Connect operator deployment is updated, it detects that the existing version 10 pods for all subsystems have labels that no longer match, and tries to fix labels. When fixing the labels, most of the microservices (for all subsystems) are recreated. All the subsystem CRs go into
Pending
state and then intoRunning
state. Management subsystem microservices are recreated, with the exception of postgres/NATS components, at the end of the process. - Single-namespace deployment:
- Verify that all microservices and clusters report
Running
:- Run the following command to check the deployment's status:
kubectl get apic -n <namespace>
All systems must report
Running
before you proceed with the upgrade. - If any cluster reports
Pending
, run the followingapicops
(v10 version 0.10.57+ required) command to validate the certificates:apicops upgrade:stale-certs -n <namespace>
For information on installing and using
apicops
, see The API Connect operations tool: apicops. - If any certificate that is managed by cert-manager failed the validation, run the
following command to delete the stale certificate secret and let cert-manager regenerate
it:
kubectl delete secret <stale-secret> -n <namespace>
- Run the following command to check the deployment's status again:
kubectl get apic -n <namespace>
All systems must report
Running
before you proceed with the upgrade.
- Run the following command to check the deployment's status:
- Upgrade the subsystems (operands) by updating the CRs. Important: When you save each updated CR, the version change is detected by the operator, which triggers the subsystem upgrade. To ensure a successful upgrade, update the subsystem CRs in the following required sequence:1. Management
2. Portal
3. Analytics
4. GatewayFor each CR, make the following changes:
- Update the
version
to reflect the new release of API Connect:For example:
version: 10.0.1.12-eus
- In the Gateway CR, remove the
template
override section, if it exists.You cannot perform an upgrade if the CR contains an override.
- Update the
- Verify that the upgraded subsystems report as
Running
and theRECONCILED VERSION
displays the new version of API Connect.Run the following command:
kubectl get apic --all-namespaces
Example response:
NAME READY STATUS VERSION RECONCILED VERSION AGE analyticscluster.analytics.apiconnect.ibm.com/analytics 8/8 Running 10.0.1.12-eus 10.0.1.12-eus-1074 121m NAME PHASE READY SUMMARY VERSION AGE datapowerservice.datapower.ibm.com/gw1 Running True StatefulSet replicas ready: 1/1 10.0.1.12-eus 100m NAME PHASE LAST EVENT WORK PENDING WORK IN-PROGRESS AGE datapowermonitor.datapower.ibm.com/gw1 Running false false 100m NAME READY STATUS VERSION RECONCILED VERSION AGE gatewaycluster.gateway.apiconnect.ibm.com/gw1 2/2 Running 10.0.1.12-eus 10.0.1.12-eus-1074 100m NAME READY STATUS VERSION RECONCILED VERSION AGE managementcluster.management.apiconnect.ibm.com/m1 16/16 Running 10.0.1.12-eus 110.0.1.12-eus-1074 162m NAME READY STATUS VERSION RECONCILED VERSION AGE portalcluster.portal.apiconnect.ibm.com/portal 3/3 Running 10.0.1.12-eus 10.0.1.12-eus-1074 139m
- Optional: Install the latest version of the API Connect Toolkit and the API Connect Local Test Environment.