To upgrade VMware Telco Cloud Automation in an airgap environment, the airgap server must host all the dependent images and packages of the target version and the current version.
Ensure that the new airgap server contains the same domain name as the existing one. Also, VMware Telco Cloud Automation must be able to verify the certificates of the new airgap server without updating the CA certificates configured on the clusters.
- Cluster creation.
- Management Cluster deletion.
- Node Pool creation.
- Cluster scale out.
- CNF instantiation.
During replacement, pulling images for these activities can fail as the connection is broken or the airgap server IP is unreachable temporarily. Kubernetes reconciles these failures after you replace the airgap server.
To avoid this temporary impact, you can adopt a high availability (HA) architecture for the airgap server. Deploy multiple airgap servers and expose a single virtual server through a third party load balancer. You can set the virtual server as HTTPS offloading or HTTPS passthrough. HTTPS offloading stops the SSL connection and HTTPS passthrough stops the TCP connection. If there is no requirement to inspect or manipulate the http-level signatures of the airgap server image, package, and Helm charts downloading traffic, configure load balancer with HTTPS passthrough.
- Add the new airgap server virtual machine that contains the images, Helm charts, and packages into the load balancer airgap server pool.
- In the load balancer configuration, deactivate the existing airgap server by changing its state to Disabled. The load balancer server does not schedule any new requests to the deactivated server. However, it continues to process existing HTTP requests.
- Remove the previous version of the airgap server from the load balancer server pool and delete the airgap server virtual machine.