Update calico to v3.17.1 #1369
Merged
Update calico to v3.17.1 #1369
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Switch calico to be deployed with the operator * Update operator update from v3.17.0 to v3.17.1 * Review update
jayanthvn
approved these changes
Feb 1, 2021
jayanthvn
approved these changes
Feb 1, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry picked PRs #1326 and #1297
Description from #1297 :
This switches the Calico install to be done using the Tigera operator. This PR includes a manifest to install the operator which will install Calico v3.17.
What type of PR is this?
update config?
Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
Testing done on this change:
I have tested upgrading a cluster that had a previous version of Calico (with Amazon VPC CNI) installed and also installed on a cluster that only had the Amazon VPC CNI plugin installed (with no existing Calico).
Automation added to e2e:
Will this break upgrades or downgrades. Has updating a running cluster been tested?:
Because of the way the upgrade will happen with the operator there is a problem upgrading on a small cluster, 3 nodes or less. This is because for 3 nodes or less the operator tries to deploy a typha for each node and the current calico install uses at least one typha and multiple typhas cannot run on a single node.
Once a cluster is upgraded with these changes, it will not be simple to downgrade back to a versions of Calico that was installed without the operator.
Does this change require updates to the CNI daemonset config files to work?:
This is updating the daemonset config files for Calico. A 'kubectl patch' of the image tag does not work because the change switches Calico to be installed by an oeprator.
Does this PR introduce any user-facing change?:
Users of Calico can now use
kubectl get tigerastatusto get an overview status of the Calico installation. They also would have the installations.operator.tigera.io default resource available for making configuration changes.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.