Two types of installation:
- install.yaml - Standard installation method.
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
This will create a new namespace, argo-rollouts
, where Argo Rollouts controller will run.
!!! tip
If you are using another namespace name, please update install.yaml
clusterrolebinding's serviceaccount namespace name.
!!! tip When installing Argo Rollouts on Kubernetes v1.14 or lower, the CRD manifests must be kubectl applied with the --validate=false option. This is caused by use of new CRD fields introduced in v1.15, which are rejected by default in lower API servers.
!!! tip On GKE, you will need grant your account the ability to create new cluster roles:
```shell
kubectl create clusterrolebinding YOURNAME-cluster-admin-binding --clusterrole=cluster-admin [email protected]
```
-
namespace-install.yaml - Installation of Argo Rollouts which requires only namespace level privileges. An example usage of this installation method would be to run several Argo Rollouts controller instances in different namespaces on the same cluster.
Note: Argo Rollouts CRDs are not included into namespace-install.yaml. and have to be installed separately. The CRD manifests are located in manifests/crds directory. Use the following command to install them:
kubectl apply -k https://github.com/argoproj/argo-rollouts/manifests/crds\?ref\=stable
You can find released container images of the controller at Quay.io. There are also old releases at Dockerhub, but since the introduction of rate limiting, the Argo project has moved to Quay.
The kubectl plugin is optional, but is convenient for managing and visualizing rollouts from the command line.
brew install argoproj/tap/kubectl-argo-rollouts
-
Install Argo Rollouts Kubectl plugin with curl.
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-amd64
!!! tip "" For Linux dist, replace
darwin
withlinux
-
Make the kubectl-argo-rollouts binary executable.
chmod +x ./kubectl-argo-rollouts-darwin-amd64
-
Move the binary into your PATH.
sudo mv ./kubectl-argo-rollouts-darwin-amd64 /usr/local/bin/kubectl-argo-rollouts
Test to ensure the version you installed is up-to-date:
kubectl argo rollouts version
To enable auto completion for the plugin when used with kubectl
(version 1.26 or newer), you need to create a shell script on your PATH called kubectl_complete-argo-rollouts
which will provide the completions.
cat <<EOF >kubectl_complete-argo-rollouts
#!/usr/bin/env sh
# Call the __complete command passing it all arguments
kubectl argo rollouts __complete "\$@"
EOF
chmod +x kubectl_complete-argo-rollouts
sudo mv ./kubectl_complete-argo-rollouts /usr/local/bin/
To enable auto completion for the CLI run as a standalone binary, the CLI can export shell completion code for several shells.
For bash, ensure you have bash completions installed and enabled. To access completions in your current shell, run $ source <(kubectl-argo-rollouts completion bash)
. Alternatively, write it to a file and source in .bash_profile
.
The completion command supports bash, zsh, fish and powershell.
See the completion command documentation for more details.
The CLI is also available as a container image at https://quay.io/repository/argoproj/kubectl-argo-rollouts
You can run it like any other Docker image or use it in any CI platform that supports Docker images.
docker run quay.io/argoproj/kubectl-argo-rollouts:master version
Check e2e testing file to see what the Kubernetes version is being fully tested.
You can switch to different tags to see what relevant Kubernetes versions were being tested for the respective version.
Argo Rollouts is a Kubernetes controller that doesn't hold any external state. It is active only when deployments are actually happening.
To upgrade Argo Rollouts:
- Try to find a time period when no deployments are happening
- Delete the previous version of the controller and apply/install the new one
- When a new Rollout takes place the new controller will be activated.
If deployments are happening while you upgrade the controller, then you shouldn't have any downtime. Current Rollouts will be paused and as soon as the new controller becomes active it will resume all in-flight deployments.