From 594b43e62949463e71a5247e21d27193990abe64 Mon Sep 17 00:00:00 2001 From: Otto Bittner Date: Tue, 22 Nov 2022 13:59:38 +0100 Subject: [PATCH] Remove kubernetesServicesVersion from upgrade RFC. Tracking two sets of versions would require us to have two versioning patterns inside the Helm charts. It also complicates the decision making for the user. --- rfc/updates.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/rfc/updates.md b/rfc/updates.md index 7ffde08a7..4b69d9316 100644 --- a/rfc/updates.md +++ b/rfc/updates.md @@ -173,8 +173,7 @@ we should add comments to those fields who will not update the cluster. ```yaml kubernetesVersion: 1.24.3 -kubernetesServicesVersion: 1.24.5 # Bundled Kubernetes components (Autoscaler, CloudControllerManager, CloudNodeManager, GCP Guest Agent, Konnectivity) -microserviceVersion: 2.2.0 # or constellationVersion: (KMS, JoinService, NodeMaintainanceOperator, NodeOperator, OLM, Verification, Cilium) +microserviceVersion: 2.2.0 # All services deployed as part of installing Constellation provider: azure: image: /communityGalleries/ConstellationCVM-b3782fa0-0df7-4f2f-963e-fc7fc42663df/images/constellation/versions/2.3.0 @@ -185,8 +184,15 @@ provider: Note that: -* `microserviceVersion` 2.2.0 contains components which are all released in version 2.2.0 -* `kubernetesServicesVersion` 1.24.5 could contain Autoscaler 1.24.2, CCM 1.24.8 since their patch versions are not in sync with Kubernetes. Moreover, those component versions will be bundled by us. Think: public lookup table from `kubernetesServicesVersion` -> component version. +* `microserviceVersion` is a bundle of component versions which can be conceptually separated into two groups: + * Services that are versioned based on the constellation version: : KMS, JoinService, NodeMaintainanceOperator, NodeOperator, OLM, Verification, Cilium (for now). + There only exists one version of each service and it is compatible with all Kubernetes versions currently supported by Constellation. + The deployment and image version are the same for all three Kubernetes versions. + * Services that are versioned based on the kubernetes version: Autoscaler, CloudControllerManager, CloudNodeManager, GCP Guest Agent, Konnectivity. + There exist one version for each Kubernetes version. + The deployment is the same for all three Kuberenetes version, but the image is specific to the version. + Images are specified by the CLI upon loading the Helm chart, by inspeciting `constellation-conf.yaml`. + Deployment variations could be introduced into the Helm charts if they become necessary in the future. When `constellation upgrade apply` is called the CLI needs to perform the following steps: @@ -194,11 +200,11 @@ When `constellation upgrade apply` is called the CLI needs to perform the follow 2. create a new `k8s-components-1.24.3` ConfigMap with the corresponding URLs and hashes from the lookup table in the CLI 3. update the measurements in the `join-config` ConfigMap 4. update the Kubernetes version and VM image in the `nodeimage` CRD -5. update Cilium + Constellation microservices +5. update Constellation microservices -The actual update in step 2. and 3. will be handled by the node-operator inside Constellation. Step 4. will be done via client side helm deployments. +The actual update in step 2. and 3. will be handled by the node-operator inside Constellation. Step 5. will be done via client side helm deployments. -Since the actual Kubernetes components and Constellation microservice versions are hidden, we will show the user for the actual changes taking place. We also print a warning to back up any important components when the upgrade necessitates a node replacement, i.e. on Kubernetes and VM image upgrades. +Since the service versions bundled inside a `microserviceVersion` are hidden, the CLI will print the changes taking place. We also print a warning to back up any important components when the upgrade necessitates a node replacement, i.e. on Kubernetes and VM image upgrades. ```bash $ constellation upgrade apply