Skip to content

Latest commit

 

History

History
61 lines (49 loc) · 3.33 KB

disconnected-upgrade.md

File metadata and controls

61 lines (49 loc) · 3.33 KB

Disconnected Upgrade

Action Required

  • Local registry must be seeded with the images required for the upgrade.
  • Local package repository must contain the required packages for the upgrade.

Summary

Starting with v1.6.0, KET no longer relies on the RPM or DEB packages maintained by the Kismatic team. Instead, KET installs the packages that are maintained by the community. This has an impact on registry seeding, given that KET no longer has access to the kismatic-offline package which contained all the container images required for an installation or upgrade. Moving forward, you are required to seed the image registry before the upgrade.

Scenarios

Existing cluster with user-managed local registry

In this scenario, your local registry is already set in the KET plan file, and KET has seeded your registry in the past during the installation or upgrade process.

Moving forward, you are required to seed your local registry before performing an upgrade. KET v1.6.0 introduced a new command, seed-registry, that will assist you in this task. For more information, see the container registry documentation and the disconnected installation documentation.

Existing cluster with registry stood up by KET

In this scenario, your local registry was stood up by KET and the docker registry related fields (docker_registry.address and docker_registry.port) are not set in the plan file.

Moving forward, you must seed the registry before performing an upgrade. Furthermore, you must set the docker registry fields in the plan file to the appropriate values.

Given that the registry deployed by KET is not recommended for production deployments, we recommend you use your own registry. If you want to move away from the KET-deployed registry, you can set the plan file fields to point to the new registry before the upgrade. KET will update all the manifests and the images will be pulled from your local registry, instead of the one deployed by KET.

If you want to continue using the registry that was deployed by KET, you must set the plan file fields to the following values:

  • docker_registry.server: The hostname or IP of the first master node and port 8443 (This is the port that KET used when deploying the registry during the (installation of your cluster). This is where KET deployed the registry during the installation of your cluster.
  • docker_registry.CA: Absolute path to the certificate authority located in generated/keys/ca.pem

When using the seed-registry command to seed the registry deployed by KET, you must configure docker on the node where you are running the command to trust the certificate authority generated by KET. The way to configure this in docker depends on the operating system. If you are seeding the registry from a Linux machine, you must copy the generated/keys/ca.pem certificate to /etc/docker/certs.d/${docker_registry.server}/ca.crt. For example, if the docker_registry.server field is set to registry.example.com:8443, you would copy the CA to /etc/docker/certs.d/registry.example.com:8443/ca.crt. See the official docker documentation for more information about using a registry with a self-signed certificate.