Page MenuHomePhabricator

Upgrade Calico
Closed, ResolvedPublic

Description

We are currently running calico version 2.2.0. While up to now, it's been sufficient, things have progressed on the calico field as well as the kubernetes front. NetworkPolicy API is marked GA since 1.8 and calico has moved on to that and uses a different pattern in 2.4.

From https://github.com/projectcalico/calico/releases/tag/v2.4.0

#105: Calico now implements the networking.k8s.io/NetworkPolicy API semantics as defined by Kubernetes when using the etcd datastore
Note: This represents a change in how existing Kubernetes NetworkPolicies are enforced by Calico. To maintain existing behavior when upgrading, follow these steps:
* In Namespaces that previously did not have the “DefaultDeny” annotation, you should delete any existing NetworkPolicy objects.
* In Namespaces that previously did have the “DefaultDeny” annotation, you can create the equivalent semantics by creating a NetworkPolicy that selects all pods but does not allow any traffic. (@caseydavenport)

So this means we need to do a careful migration of the policies beforehand

Event Timeline

Change 469339 had a related patch set uploaded (by Alexandros Kosiaris; owner: Alexandros Kosiaris):
[operations/puppet@production] calico: Support version 2.4.1

https://gerrit.wikimedia.org/r/469339

jijiki triaged this task as Medium priority.Oct 25 2018, 11:46 AM

I 've had to deannotate the zotero namespace with commands like the one below

sudo KUBECONFIG="/etc/kubernetes/admin-codfw.config" kubectl annotate namespace zotero net.beta.kubernetes.io/network-policy-

in all 3 clusters in order to avoid being bitten by the fact that zotero seems to require talking to the public LVS endpoints, a practice we want to eliminate as it makes it way harder for us to conduct per service failovers using DNS discovery RRs.

When we upgrade to 2.4.x calico we will be able to specify a per namespace specific egress policy and thus our current default egress will be deprecated and hence the problem will be solved.

akosiaris added a parent task: Restricted Task.Feb 15 2019, 11:30 AM
JMeybohm renamed this task from Upgrade calico in production to version 2.4+ to Upgrade Calico.Oct 20 2020, 3:14 PM
JMeybohm added a project: Prod-Kubernetes.

We packaged and deployed calico 3.16 to staging-codfw but currently we lack full IPv6 support due to the fact that we now require kubernetes to dual-stack/IPv6 enabled as well (as we run calico with kubernetes datastore backend).

Change 674628 had a related patch set uploaded (by JMeybohm; owner: JMeybohm):
[operations/puppet@production] calico: Clean up code from calico 2.2.0

https://gerrit.wikimedia.org/r/674628

Change 674628 merged by Alexandros Kosiaris:
[operations/puppet@production] calico: Clean up code from calico 2.2.0

https://gerrit.wikimedia.org/r/674628

Change 469339 abandoned by Alexandros Kosiaris:

[operations/puppet@production] calico: Support version 2.4.1

Reason:

No longer needed, we 've jumped to 3.16 directly

https://gerrit.wikimedia.org/r/469339

All of our clusters are now on calico 3.16, we can close this as resolved!