Once your cluster is up and running it's time to put it work!
WKP encourages using GitOps to manage your workloads. We can specify the state of the cluster including all our user workloads in the config git repository. The WKP Flux Cluster Component will ensure that the git repository and the cluster then stay in sync. This gives us a number of benefits including
- An audit trail of who deployed or updated a workload and why
- Deployment rollbacks via
Additionally WKP clusters support all the traditional ways of creating and deploying workloads through
kubectl and the api-server directly. Check out the Kubernetes docs to familiarize yourself with these tools.
By default the
./cluster/manifests path within the config repository is reserved for user manifests. Any
.yaml Kubernetes manifest you add within this path will be deployed to the cluster automatically.
Lets create a new file:
./cluster/manifests/nginx.yaml and set the contents:
Save the file, then we'll commit and push it to the repository host
Once we have pushed we can check the workload is deployed in the cluster like with
There is a new pod running!
We can use the Weave Scope Cluster Component to view all the workloads running on the cluster. First open the WKP ui
Then when the browser opens click the "Open Scope" button in the Cluster Components list. You can use Scope to explore whats running on your cluster.
We can view the Web UI of a pod by forwarding the http ports it listens on
opening http://localhost:8080 in your browser will show the default nginx server response
We can check the logs of our new pod via kubectl
displaying the requests we just made.
A common operation is upgrading a version of a workload when there is a new release. To do that we can edit the
.yaml file and change the docker image to the desired tag:
Then once again we can commit and push to update the cluster:
If a change to the git repository does not seem to be reflected in the cluster we can take some steps to investigate
flux-sync git tag#
When flux applies a commit it will update a git tag on the repository. If you don't have access to the flux pod's logs this is a handy way of checking what was last sync'd:
We can inspect the tag and see when flux last updated it and which commit was last applied.
Flux is configured by default to poll and apply the git repository every 10s. If after waiting this long the tag has not updated flux might be having trouble syncing the repository. To learn more we need to check its logs.
We can inspect the flux logs with:
Flux will report any errors raised while it was applying the yaml manifests. This can include things like:
- Unable to read the git repository if there are connectivity issues.
- Syntax errors in the
- Kubernetes validation errors if the manifest files are badly formed.
Correct any errors in your yaml files and then try commiting and pushing your changes again.
Removing a workload is again a simple operation on the config repository:
Flux will sync and remove the workload from the cluster.