Upgrade Preparation Checklist for PKS v1.3

Page last updated:

Warning: Pivotal Container Service (PKS) v1.3 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy.
To stay up to date with the latest software and security updates, upgrade to a supported version.

This topic serves as a checklist for preparing to upgrade Pivotal Container Service (PKS) from v1.2 to v1.3.

This topic contains important preparation steps that you must follow before beginning your upgrade. Failure to follow these instructions may jeopardize your existing deployment data and cause the upgrade to fail.

After completing the steps in this topic, you can continue to Upgrading PKS. If you are upgrading PKS for environments using vSphere with NSX-T, continue to Upgrading PKS with NSX-T.

Back Up Your PKS Deployment

We recommend backing up your PKS deployment before upgrading, to restore in case of failure.

If you are upgrading PKS for environments using vSphere with NSX-T, back up your environment using the procedures in the following topics:

If you are upgrading PKS for any other IaaS, back up the PKS v1.2 control plane. For more information, see Backing Up and Restoring PKS.

Review Changes in PKS v1.3

Review the Release Notes for the version or versions of PKS you are upgrading to.

Understand What Happens During PKS Upgrades

Review What Happens During PKS Upgrades, and consider your workload capacity and uptime requirements.

View Workload Resource Usage

View your workload resource usage in Dashboard. For more information, see Accessing Dashboard.

If workers are operating too close to their capacity, the PKS upgrade can fail. To prevent workload downtime during a cluster upgrade, Pivotal recommends running your workload on at least three worker VMs, using multiple replicas of your workloads spread across those VMs. For more information, see Maintaining Workload Uptime.

If your clusters are near capacity for your existing infrastructure, we recommend scaling up your clusters before you upgrade. Scale up your cluster by running pks resize or create a cluster using a larger plan. For more information, see Scaling Existing Clusters.

Verify Health of Kubernetes Environment

Verify that your Kubernetes environment is healthy. To verify the health of your Kubernetes environment, see Verifying Deployment Health.

Verify NSX-T Configuration (vSphere with NSX-T Only)

If you are upgrading PKS for environments using vSphere with NSX-T, perform the following steps:

  1. Make sure there are no issues with vSphere by following the steps below:
    1. Verify that datastores have enough space.
    2. Verify that hosts have enough memory.
    3. Verify that there are no alarms.
    4. Verify that hosts are in a good state.
  2. Verify that NSX Edge is configured for high availability using Active/Standby mode.

    Note: Workloads in your Kubernetes cluster are unavailable while the NSX Edge nodes run the upgrade unless you configure NSX Edge for high availability. For more information, see the Configure NSX Edge for High Availability (HA) section of Preparing NSX-T Before Deploying PKS.

Clean Up Failed Kubernetes Clusters

Clean up previous failed attempts to delete PKS clusters with the PKS Command Line Interface (PKS CLI).

Perform the following steps:

  1. View your deployed clusters by running the following command:

    pks clusters

    If the Status of any cluster displays as FAILED, continue to the next step. If no cluster displays as FAILED, no action is required. Continue to the next section.

  2. Perform the procedures in Cannot Re-Create a Cluster that Failed to Deploy to clean up the failed BOSH deployment.

  3. Run pks clusters to view your deployed clusters again. If any clusters remain in the FAILED state, contact PKS Support.

Verify Kubernetes Clusters Have Unique External Hostnames

Verify that existing Kubernetes clusters have unique external hostnames by checking for multiple Kubernetes clusters with the same external hostname.

Perform the following steps:

  1. Log in to the PKS CLI. For more information, see Logging in to PKS. You must log in with an account that has the UAA scope of pks.clusters.admin. For more information about UAA scopes, see Managing Users in Enterprise PKS with UAA.

  2. View your deployed PKS clusters by running the following command:

    pks clusters
  3. For each deployed cluster, run pks cluster CLUSTER-NAME to view the details of the cluster. For example:

    $ pks cluster my-cluster

    Examine the output to verify that the Kubernetes Master Host is unique for each cluster.

Verify PKS Proxy Configuration

Verify your current PKS proxy configuration.

Perform the following steps:

  1. Check whether an existing proxy is enabled:

    1. Log in to Ops Manager.
    2. Click the Pivotal Container Service tile.
    3. Click Networking.
    4. If HTTP/HTTPS Proxy is Disabled, no action is required. Continue to the next section.

      If HTTP/HTTPS Proxy is Enabled, continue to the next step.
  2. If the existing No Proxy field contains any of the following values, or you plan to add any of the following values, contact PKS Support:

    • localhost
    • Hostnames containing dashes, such as my-host.mydomain.com

Check PodDisruptionBudget Value

A PKS upgrade will run endlessly and never complete if any Kubernetes application, for any reason, has had a PodDisruptionBudget created for it with maxUnavailable set to 0.

Perform the following steps:

  1. Use the Kubernetes CLI, kubectl, to verify the PodDisruptionBudget as the cluster administrator. Run the following command:

    kubectl get poddisruptionbudgets --all-namespaces

    Note: For more information about kubectl, see Overview of kubectl in the Kubernetes documentation.

  2. Examine the output. Any app listed should not show 0 in the MAX UNAVAILABLE column.

Please send any feedback you have to pks-feedback@pivotal.io.