Skip to content
This repository has been archived by the owner on Oct 24, 2023. It is now read-only.

docs: don’t use upgrade if IaaS has been changed #387

Merged
merged 1 commit into from Jan 26, 2019
Merged

docs: don’t use upgrade if IaaS has been changed #387

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/topics/upgrade.md
View file
Open in desktop
Expand Up @@ -18,7 +18,7 @@ In order to ensure that your `aks-engine upgrade` operation runs smoothly, there

1) You will need access to the original `_output/` directory files that were generated during cluster deployment in order to run `upgrade`. `aks-engine` will use the `--deployment-dir` argument provided in the upgrade command to introspect the `apimodel.json` file and Azure Resource Manager (ARM) parameters in order to determine the cluster's current Kubernetes version, as well as all other cluster configuration data as defined by `aks-engine` during the last time that `aks-engine` was used to deploy, scale, or upgrade the cluster.

2) `aks-engine upgrade` expects a cluster configuration that conforms to the current state of the cluster. In other words, the Azure resources deployed by `aks-engine` should be in the same state that when they were originally created by `aks-engine`. If you perform manual operations on your Azure IaaS resources (other than `aks-engine scale` and `aks-engine upgrade`) you risk not being able to upgrade your cluster successfully, as the aks-engine-generated ARM template won't be reconcilable against the state of the Azure resources that reside in the resource group. This includes naming of resources; `aks-engine` relies on some resources (such as VMs) to be named in accordance with the original `aks-engine` deployment. In summary, the set of Azure resources in the resource group are mutually reconcilable only if they have been exclusively created and managed as the result of a series of successive ARM template deployments originating from `aks-engine`.
2) `aks-engine upgrade` expects a cluster configuration that conforms to the current state of the cluster. In other words, the Azure resources inside the resource group deployed by `aks-engine` should be in the same state that when they were originally created by `aks-engine`. If you perform manual operations on your Azure IaaS resources (other than `aks-engine scale` and `aks-engine upgrade`) DO NOT use `aks-engine upgrade`, as the aks-engine-generated ARM template won't be reconcilable against the state of the Azure resources that reside in the resource group. This includes naming of resources; `aks-engine` relies on some resources (such as VMs) to be named in accordance with the original `aks-engine` deployment. In summary, the set of Azure resources in the resource group are mutually reconcilable only if they have been exclusively created and managed as the result of a series of successive ARM template deployments originating from `aks-engine`.

3) `aks-engine upgrade` allows upgrading the Kubernetes version to any aks-engine-supported patch release in the current minor release channel that is greater than the current version on the cluster (e.g., from `1.11.4` to `1.11.5`), or to the next aks-engine-supported minor version (e.g., from `1.11.4` to `1.12.5`). In practice, the next aks-engine-supported minor version will commonly be a single minor version ahead of the current cluster version. However, if the cluster has not been upgraded in a significant amount of time, the "next" minor version may have actually been deprecated by aks-engine. In such a case, your long-lived cluster will be upgradable to the nearest, supported minor version that `aks-engine` supports at the time of upgrade (e.g., from `1.7.16` to `1.9.11`).

Expand Down