Initial proposal for dealing with network isolation SDNs #572
Conversation
* first implementation should be redhat/ovs-multitenant network plugin
openshift-ci-robot
added
the
size/M
|
Changes Unknown when pulling 9c8862c on shawn-hurley:network-iso-prop into ** on openshift:master**. |
docs/proposals/Network-Isolation.md
Outdated
|
|
||
| > The ovs-multitenant plug-in provides OpenShift Container Platform project level isolation for pods and services. Each project receives a unique Virtual Network ID (VNID) that identifies traffic from pods assigned to the project. Pods from different projects cannot send packets to or receive packets from pods and services of a different project. | ||
|
|
||
| The ASB creates a transient namespace while running an APB and grants the correct access to the target namespace. This network plugin will cause APBs that assume they can reach, over the network the pod in the target namespace, to fail. |
There was a problem hiding this comment.
Let's try to reword that last sentence.
This network plugin will cause some APBs to fail, if the APB assumes it can access pods in the target namespace over the network.
docs/proposals/Network-Isolation.md
Outdated
| ## Problem Description | ||
| The transient namespace does not have network access to the target namespace, leaving the APB pod unable to perform all the tasks that it should be able to perform. | ||
|
|
||
| ## <Implementation Details> |
There was a problem hiding this comment.
why is this heading in angle brackets?
docs/proposals/Network-Isolation.md
Outdated
| The transient namespace does not have network access to the target namespace, leaving the APB pod unable to perform all the tasks that it should be able to perform. | ||
|
|
||
| ## <Implementation Details> | ||
| There are ways to manage this [network](https://docs.openshift.com/container-platform/3.6/admin_guide/managing_networking.html). We should be able to add the transient namespace to the same network as the target namespace. One of the big things is we want this to be easily expandable to [kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/networking) SDN's that could implement the same basic structure. This PR will not address each networking option but rather create a common structure for implementing more SDN's in the future. |
There was a problem hiding this comment.
Sorry rewriting the above paragraph to make it more clear in my mind:
With no network access to the target namespace, APBs will be limited in some of the more advanced tasks they can perform. We need a mechanism to give the APBs in the transient namespace access to the target namespace. We should be able to add the transient namespace to the same network as the target namespace. See the managing networking document for different ways of working with networking.
One of the big things is we want this to be easily expandable to kubernetes SDN's that could implement the same basic structure. This proposal will not address each networking option but rather create a common structure for implementing more SDN's in the future.
| } | ||
| } | ||
| ``` | ||
| 2. If we do need to add networks together, then during the apb sandbox creation, we should join the networks. |
There was a problem hiding this comment.
how would the preSandboxCreation hooks we talked about be affected by this?
There was a problem hiding this comment.
So, I think we can either make this a postSandboxCreation action that gets added once all the checks pass, or we can create a new function that is specific to joining networks similar to extract credentials is what I was thinking.
I think that if we went the first option this would be a good example of how to use the hooks from within our codebase.
docs/proposals/Network-Isolation.md
Outdated
| ``` | ||
| 2. If we do need to add networks together, then during the apb sandbox creation, we should join the networks. | ||
| 1. Examples of how to do this are in the `oadm` client in origin. [here](https://github.com/openshift/origin/blob/1f270ca122306656b228faa92bc71d2136e0f97a/pkg/oc/admin/network/project_options.go#L157) and the [update](https://github.com/openshift/origin/blob/master/pkg/network/netid.go#L73) to the annotation. | ||
| 3. If we can not join the networks together, and we should, then we should error out of the provision. |
There was a problem hiding this comment.
change #3 to read:
If we should join the networks together but are not able to, then we should error out of the provision
|
Changes Unknown when pulling 629a762 on shawn-hurley:network-iso-prop into ** on openshift:master**. |
| } | ||
|
|
||
| func NewRuntime() { | ||
| networkIsolation := shouldJoinNetworks(...) |
There was a problem hiding this comment.
Not blocking this since it's pseudo code, but I don't think we want to expose openshift specific calls outside of the coe interface.
How about something like: p.coe.shouldJoinNetworks or something more general: p.coe.initCoe.
Describe what this PR does and why we need it:
This PR will define how we can deal with joining networks that are isolated to allow APBs to talk to the resulting pods that it creates over the network.
Changes proposed in this pull request
redhat/ovs-multitenantnetwork plugin