English | 简体中文
This upgrade guide is intended for Spiderpool running on Kubernetes. If you have questions, feel free to ping us on Spiderpool Community.
-
Read the full upgrade guide to understand all the necessary steps before performing them.
-
When rolling out an upgrade with Kubernetes, Kubernetes will first terminate the pod followed by pulling the new image version and then finally spin up the new image. In order to reduce the downtime of the agent and to prevent ErrImagePull errors during upgrade. You can refer to the following command to pull the corresponding version of the image in advance.
# Taking docker as an example, please modify [upgraded-version] to your upgraded version. docker pull ghcr.io/spidernet-io/spiderpool/spiderpool-agent:[upgraded-version] docker pull ghcr.io/spidernet-io/spiderpool/spiderpool-controller:[upgraded-version] # If you are mainland user who is not available to access ghcr.io, you can use the mirror source ghcr.m.daocloud.io docker pull ghcr.m.daocloud.io/spidernet-io/spiderpool/spiderpool-agent:[upgraded-version] docker pull ghcr.m.daocloud.io/spidernet-io/spiderpool/spiderpool-controller:[upgraded-version]
It is recommended to always upgrade to the latest and maintained patch version of Spiderpool. Check Stable Releases to learn about the latest supported patch versions.
-
Make sure you have Helm installed.
-
Setup Helm repository and update
helm repo add spiderpool https://spidernet-io.github.io/spiderpool helm repo update spiderpool
-
Remove spiderpool-init Pod (optional)
spiderpool-init
Pod will help initialize environment information, and it will be incomplete
state after each run. If your environment has aspiderpool-init
Pod, delete it throughkubectl delete
before upgrading, otherwise it will fail during helm upgrade. -
Upgrade via
helm upgrade
# -n specifies the namespace where your Spiderpool is located, and modify [upgraded-version] to the version you want to upgrade to. helm upgrade spiderpool spiderpool/spiderpool -n kube-system --version [upgraded-version]
You can use --set
to update the Spiderpool configuration when upgrading. For available values parameters, please see the values documentation. The following example shows how to enable Spiderpool's SpiderSubnet function
helm upgrade spiderpool spiderpool/spiderpool -n kube-system --version [upgraded-version] --set ipam.spidersubnet.enable=true
You can also use --reuse-values
to reuse the values from the previous release and merge any overrides from the command line. However, it is only safe to use the --reuse-values
flag if the Spiderpool chart version remains unchanged, e.g. when using helm upgrade to change the Spiderpool configuration without upgrading the Spiderpool components. For --reuse-values
usage, see the following example:
helm upgrade spiderpool spiderpool/spiderpool -n kube-system --version [upgraded-version] --set ipam.spidersubnet.enable=true --reuse-values
Conversely, if the Spiderpool chart version has changed and you want to reuse the values from the existing installation, save the old values in a values file, check that file for any renamed or deprecated values, and pass it to helm upgrade command, you can retrieve and save values from existing installations using.
helm get values spiderpool --namespace=kube-system -o yaml > old-values.yaml
helm upgrade spiderpool spiderpool/spiderpool -n kube-system --version [upgraded-version] -f old-values.yaml
Occasionally, it may be necessary to undo the rollout because a step was missed or something went wrong during upgrade. To undo the rollout run:
helm history spiderpool --namespace=kube-system
helm rollback spiderpool [REVISION] --namespace=kube-system
The following upgrade notes will be updated on a rolling basis with the release of new versions. They will have a priority relationship (from old to new). If your current version meets any one of them, when upgrading, you need to check in order from that item to Latest on every note.
In versions lower than 0.3.6, -
is used as a separator for SpiderSubnet delimiter for autopool names. It was ultimately difficult to extract it to trace the namespace and name of the application to which the autopool corresponded. The SpiderSubnet functionality in these releases was flawed by design, and has been modified and optimised in the latest patch releases, as well as supporting multiple network interfaces for the SpiderSubnet functionality in releases from 0.3.6 onwards. As mentioned above, the names of the new auto pools created in the new release have been changed, e.g., the IPv4 auto pool corresponding to application kube-system/test-app
is auto4-test-app-eth0-40371
. At the same time, the auto pool is marked with some labels as follows.
metadata:
labels:
ipam.spidernet.io/interface: eth0
ipam.spidernet.io/ip-version: IPv4
ipam.spidernet.io/ippool-cidr: 172-100-0-0-16
ipam.spidernet.io/ippool-reclaim: "true"
ipam.spidernet.io/owner-application-gv: apps_v1
ipam.spidernet.io/owner-application-kind: DaemonSet
ipam.spidernet.io/owner-application-name: test-app
ipam.spidernet.io/owner-application-namespace: kube-system
ipam.spidernet.io/owner-application-uid: 2f78ccdd-398e-49e6-a85b-40371db6fdbd
ipam.spidernet.io/owner-spider-subnet: vlan100-v4
spec:
podAffinity:
matchLabels:
ipam.spidernet.io/app-api-group: apps
ipam.spidernet.io/app-api-version: v1
ipam.spidernet.io/app-kind: DaemonSet
ipam.spidernet.io/app-name: test-app
ipam.spidernet.io/app-namespace: kube-system
Upgrading below 0.3.6 to the latest patch version is an incompatible upgrade. If the SpiderSubnet feature is enabled, you will need to add a series of tags as described above to the stock auto pool in order to make it available to the stock auto pool, as follows:
kubectl patch sp ${auto-pool} --type merge --patch '{"metadata": {"labels": {"ipam.spidernet.io/owner-application-name": "test-app"}}}'
kubectl patch sp ${auto-pool} --type merge --patch '{"metadata": {"labels": {"ipam.spidernet.io/owner-application-namespace": "kube-system"}}}'
...
SpiderSubnet supports multiple network interfaces, you need to add the corresponding network interface label
for the auto pool as follows:
kubectl patch sp ${auto-pool} --type merge --patch '{"metadata": {"labels": {"ipam.spidernet.io/interface": "eth0"}}}}'
Due to architecture adjustment, SpiderEndpoint.Status.OwnerControllerType
property is changed from None
to Pod
. Therefore, find all SpiderEndpoint objects with Status.OwnerControllerType
of None
and replace the SpiderEndpoint.Status.OwnerControllerType
property from None
to Pod
.
In versions higher than 0.5.0, the SpiderMultusConfig and Coordinator functions are added. However, due to helm upgrade, the corresponding CRDs cannot be automatically installed: spidercoordinators.spiderpool.spidernet.io
and spidermultusconfigs.spiderpool.spidernet.io
. Therefore, before upgrading, you can obtain the latest stable version through the following commands, decompress the chart package and apply all CRDs.
~# helm search repo spiderpool --versions
# Please replace [upgraded-version] with the version you want to upgrade to.
~# helm fetch spiderpool/spiderpool --version [upgraded-version]
~# tar -xvf spiderpool-[upgraded-version].tgz && cd spiderpool/crds
~# ls | grep '\.yaml$' | xargs -I {} kubectl apply -f {}
Due to the addition of the txQueueLen
field to the SpiderCoordinator CRD in version 0.9.0, you need to manually update the CRD before upgrading as Helm does not support upgrading or deleting CRDs during the upgrade process.(We suggest skipping version 0.9.0 and upgrading directly to version 0.9.1)
TODO.