New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use an init container for CNI when in k8s api datastore mode #2231

Merged
merged 1 commit into from Oct 16, 2018

Conversation

Projects
None yet
2 participants
@caseydavenport
Copy link
Member

caseydavenport commented Oct 13, 2018

Description

I'd like to do this for etcd as well, but it needs more thought first. There's some code which runs and updates certs if they change. I'm not sure if anyone uses that code, so maybe we can just drop it.

I say we do it for kdd anyway, since it's an easy win.

  • One fewer docker containers per node required (which takes up resources).
  • kubectl logs no longer requires specifying container name.
  • simpler kubectl describe output, since it's only for one container.

Todos

  • Tests
  • Documentation
  • Release note

Release Note

The CNI plugin is now installed using a Kubernetes init container rather than a long-lived sidecar.

@caseydavenport caseydavenport requested a review from projectcalico/core-maintainers as a code owner Oct 13, 2018

@caseydavenport caseydavenport force-pushed the caseydavenport:init-container-kdd branch from b5c4bdd to c962c26 Oct 13, 2018

@caseydavenport caseydavenport changed the title WIP: Use an init container for CNI when in k8s api datastore mode Use an init container for CNI when in k8s api datastore mode Oct 13, 2018

@caseydavenport caseydavenport force-pushed the caseydavenport:init-container-kdd branch from c962c26 to b146897 Oct 13, 2018

@fasaxc

This comment has been minimized.

Copy link
Member

fasaxc commented Oct 15, 2018

Any way we can avoid the duplication in the template? I see the value in simplifying for the user and reducing our resource use but if the template gets duplicated we're more likely to introduce bugs in maintenance.

@fasaxc

This comment has been minimized.

Copy link
Member

fasaxc commented Oct 15, 2018

Think I'd prefer making such a change at the start of a release cycle; just to give us time to spot any unexpected quirk of initContainers.

@caseydavenport

This comment has been minimized.

Copy link
Member

caseydavenport commented Oct 15, 2018

Think I'd prefer making such a change at the start of a release cycle; just to give us time to spot any unexpected quirk of initContainers.

Yep, SGTM. Master is now v3.4 dev, so we should be OK now.

Any way we can avoid the duplication in the template? I see the value in simplifying for the user and reducing our resource use but if the template gets duplicated we're more likely to introduce bugs in maintenance.

Hm, I'll think about it. There may be a way. Honestly, I'd like to move etcd over to this approach as well anyway, so maybe we should just do that.

@caseydavenport caseydavenport added this to the Calico v3.4.0 milestone Oct 15, 2018

@fasaxc

fasaxc approved these changes Oct 16, 2018

@caseydavenport caseydavenport merged commit 4925f65 into projectcalico:master Oct 16, 2018

2 checks passed

license/cla Contributor License Agreement is signed.
Details
semaphoreci The build passed on Semaphore.
Details

@caseydavenport caseydavenport deleted the caseydavenport:init-container-kdd branch Oct 16, 2018

@caseydavenport caseydavenport referenced this pull request Nov 18, 2018

Merged

Switch etcd mode to use an init container for CNI #2300

0 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment