Closed euank closed 5 years ago
Cool. We can definitely get away with most of the work done in CNI, but there are a few things not currently supported there:
-traffic shaping -firewalling -port forwarding (though rkt handles this)
Also: there are a few connection tunables, such as MTU, that need to be injected in to the CNI config on disk :-/
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
It was decided that the runtime should manage network plugins, so we should use the kubenet/cni packages that exist in Kubernetes in order to keep compatibility.
For compatibility with other Kubernetes runtimes, we should be able to support kubenet/cni, or something very like it.
For the current rkt integration, we depended entirely on the Kubenretes-CNI, but the reasons are largely outdated (pod ip not available prior to running apps; rkt-CRI fixes that).
The main consideration now is configuration-directory compatibility and any other differences kubenet has from pure CNI.
We might be able to get away with rkt-cni now. cc @squeed