| title | menu_order |
|---|---|
Upgrading to Flux v1 |
100 |
Flux v1 is a major improvement over the previous versions, and is different enough that you need to do a bit of work to upgrade it.
In previous releases of Flux, much of the work was done by the service. This meant that to get a useful system, you had to run both the daemon and the service in your cluster, or connect the daemon to Weave Cloud. In version 1, the daemon does all of the mechanical work by itself, and Weave Cloud “merely” adds a web user interface and integrations, e.g., with Slack.
In version 1 the daemon is more self-sufficient and easier to set up. It is also more capable, and in particular, it now synchronises your cluster with the manifests you keep in git -- enabling you to use git (and GitHub) workflows to manage your cluster.
| Old Flux | Flux v1 |
|---|---|
| Setting up the repo | |
|
|
| Supplying Docker registry credentials | |
|
The daemon finds credentials for itself by looking at Kubernetes resources |
| Managing your cluster with Flux | |
|
|
In summary, you will need to:
- Remove the old Flux resources from your cluster
- Delete any deployment keys
- Run the new Flux resources
- Install a new deploy key
First, it will help in a few places to have an old fluxctl around. Download it from GitHub:
curl -o fluxctl_030 https://github.com/weaveworks/flux/releases/download/0.3.0/fluxctl_linux_amd64
# or if using macOS,
# curl -o fluxctl_030 https://github.com/weaveworks/flux/releases/download/0.3.0/fluxctl_darwin_amd64
chmod a+x ./fluxctl_030The next steps depend on whether you
- Connect Flux to Weave Cloud; or,
- You are running Flux standalone (i.e., you run both the Flux daemon and the Flux service, rather than going through Weave Cloud).
Set the environment variable FLUX_SERVICE_TOKEN to be your service
token (found in the Weave Cloud UI for the instance you are
upgrading).
Before making changes, get the config so that it can be consulted later:
./fluxctl_030 get-config --fingerprint=md5 | tee old-config.yamlImportant! If you have Flux resources committed to git The first thing to do is remove any manifests for running Flux that you have stored in git, before deleting them in the cluster (below). Otherwise, when the new Flux daemon runs it will restore the old configuration.
Run Weave Cloud’s launch generator to delete the resources in the cluster:
kubectl delete -n kube-system -f \
https://cloud.weave.works/k8s/flux.yaml?flux-version=0.3.0”It’s good practice to remove any unused deployment keys. If you’re using GitHub, look at the settings for the repository you were pointing Flux at, and delete the key Flux was using.
To check you are removing the correct key, get the fingerprint of the key used by Flux with
./fluxctl_030 get-config --fingerprint=md5First, it is important to understand that Flux manages more of your cluster resources now. It will automatically apply manifests that appear in your config repo, either by creating or by updating them. In other words, it tries to keep the cluster running whatever is represented in the repo. (Though it doesn’t delete things, yet.)
To run the new Flux with Weave Cloud:
- Go to your instance settings (the cog icon) and click the “Config” then “Deploy” menu items
- Enter the git URL, path and branch values from the saved config
(in
old-config.yaml) - Run the
kubectlcommand shown below the form. - Following the instructions underneath the command, to install the deploy key (this is also a good opportunity to delete any old keys, if you didn’t do that above).
- Wait for the big red "Agent not configured" message to clear.
You should now be able to click the “Deploy” tab at the top and see your running system (again), with the updated Flux daemon.
Set the environment variable FLUX_URL to point to the Flux service you are running, as described in the old deployment docs. The particular URL will differ, depending on how you have told Kubernetes to expose the Flux service.
Before making any changes, get the config so that it can be consulted later:
./fluxctl_030 get-config --fingerprint=md5 | tee old-config.yaml
Important! If you have Flux resources committed to git
The first thing to do here is to remove any manifests for running flux you have stored in git, before deleting them in the cluster (below). If you don’t remove these, running the new flux daemon will restore the old configuration.
You can delete the Flux resources by referring to the manifest files used to create them. If you don’t have the files on hand, you can try using the example deployment as a stand-in:
git clone --branch 0.3.0 [email protected]:weaveworks/flux flux-0.3.0
kubectl delete --ignore-not-found -R -f ./flux-0.3.0/deployThat’s something of a sledgehammer! But it should cover most cases.
It’s good practice to remove any unused deployment keys. If you’re
using GitHub, look at the settings for the repository you were
pointing Flux at, and delete the key Flux was using. To check you are
removing the correct key, you can see the fingerprint of the key used
by Flux in the file old-config.yaml that was created earlier.
First, it is important to understand that Flux manages more of your cluster resources now. It will automatically apply the manifests that appear in your config repo, either by creating or by updating them. In other words, it tries to keep the cluster running whatever is represented in the repo. (Though it doesn’t delete things, yet).
To run Flux without connecting to Weave Cloud, adapt the manifests
provided in the
Flux repo
with the git parameters (URL, path, and branch) from
old-config.yaml, and then apply them with kubectl. Consider adding
these adapted manifests to your own config repo.
The daemon now has an API itself, so you can point fluxctl directly at it (the example manifests include a Kubernetes service so you can do just that).
You may find that you need to set FLUX_URL again, to take account of the new deployment. See the setup instructions for guidance.
To see the SSH key created by Flux, download the latest fluxctl from the release page and run:
fluxctl identityYou will need to add this as a deploy key, which is also described in the setup instructions linked above.
It’s possible that the Flux resources are in an unusual namespace or given a different name. As a last resort, you can hunt down the resources by name and delete them. Weave Cloud’s “Explore” tab may help; or use kubectl to look for likely suspects.
kubectl get serviceaccount,service,deployment --all-namespacesHave a look for deployments and services with “flux” in the name.
The most likely explanation is that you have manifests for the resources in your config repo. When Flux v1 starts, it does a sync -- and if there are manifests for the old Flux still in git, it will create those as resources.
If that’s the case, you will need to remove the manifests from git before running Flux v1. You can download manifests from Weave Cloud, or adapt those given in the repo, if you want to check them back in.
You can reach Weaveworks developers in our community Slack -- https://weaveworks.github.io/community-slack/ -- where we will be able to help.