host port mapping change #4
Open
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
rawahars
force-pushed
the
master
branch
4 times, most recently
from
9eca858
to
a26d849
Compare
* windows: enhance vpc-bridge plugin to use HNS V2 APIs by default Presently, in the `vpc-bridge` plugin, we use HNS V1 APIs to create the HNS network and the HNS endpoint. Once the endpoint is created, we use either V1 or V2 APIs for attaching the endpoint to the container. Given that V2 is the way forward where Microsoft supports newer features, we are converting our plugins to be V2 first. In this commit, we make the following changes- - We use HNS V2 to create the network - We use HNS V2 to create the HNS endpoint After that, we will use either V1 or V2 to attach the endpoint to our container/namespace depending upon the runtime. * windows: add support for port mapping in vpc-bridge plugin Presently, the vpc-bridge plugin silently ignores any port mapping between container to host for the configured endpoint. As per the current CNI convention, plugins can request that the runtime insert this dynamic configuration by explicitly listing their capabilities in the network configuration. Dynamic information (i.e. data that a runtime fills out) should be placed in a runtimeConfig section. Reference: https://www.cni.dev/docs/conventions/#dynamic-plugin-specific-fields-capabilities--runtime-configuration `portMappings` is one such capability. This change adds the support for creating NAT port mappings between container and host ports as configured by the runtime.
This is a bug fix in the `vpc-bridge` CNI plugin for Windows where we need to use `Search` parameter in `DNS` configuration for setting multiple domains used for short hostname lookups. Earlier we were using `Domain` which is a single string. This change fixes this issue.
1. CNI plugin depends on vpc-cni-k8s-connector executed in EKS Windows nodes. 2. Call is made to vpc-cni-k8s-connector with podname, pod namespace and path to pipe as input args. 3. CNI receives output over named pipe and vpc-cni-k8s-connector logs over stdout. 4. CNI plugin creates a named pipe, start listener and read pipe connections to receive output from vpc-cni-k8s-connector
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.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.