-
Notifications
You must be signed in to change notification settings - Fork 388
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
[ExternalNode] Add feature gate to run Agent on a non-Kubernetes Node #3542
Conversation
b3d3574
to
24a15dc
Compare
/test-all |
Codecov Report
@@ Coverage Diff @@
## feature/externalnode #3542 +/- ##
========================================================
- Coverage 63.54% 55.62% -7.92%
========================================================
Files 278 392 +114
Lines 39502 55133 +15631
========================================================
+ Hits 25101 30669 +5568
- Misses 12466 22089 +9623
- Partials 1935 2375 +440
Flags with carried forward coverage won't be shown. Click here to find out more.
|
/test-e2e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a way to add a feature gate to isolate VM/BM code?
build/yamls/antrea-aks.yml
Outdated
@@ -2975,6 +2975,12 @@ data: | |||
# Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and | |||
# kube-proxy is removed from the cluser, otherwise kube-proxy will still load-balance this traffic. | |||
#proxyLoadBalancerIPs: true | |||
|
|||
# The role in which Antrea Agent is working. Supported values: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, can we generate a separate yaml for VM/BM, to avoid these confusing parameters for normal K8s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I create a sperate build directory for VM/BM configuration, but I didn't modify the create generate-manifest script to generate yaml file because for VM/BM case antrea-agent.conf is used directly on agent side and we don't need a all-in-one yaml file to apply on K8s cluster. Besides, In @mengdie-song 's PR, she will create a separate CRD yaml file for VM agent which could be applied on the cluster, and I think that file should also place in the new configration directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just mean could we find a way to avoid changing the regular yamls and adding VM only contents.
|
||
# The role in which Antrea Agent is working. Supported values: | ||
# - Node (default) | ||
# - VM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any difference between VM and BM and so we need two types? If not or not clear, let us just add one type called "VirtualMachine" for now.
92a71f8
to
be15219
Compare
Any thoughts on this one?
|
2a7178d
to
e826128
Compare
@@ -0,0 +1,39 @@ | |||
# FeatureGates is a map of feature names to bools that enable or disable experimental features. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably change "externalnode" in the path to "vmnode".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, the problem with "externalnode" is that it can refer to a node/policy receiver without Agent running.
# FeatureGates is a map of feature names to bools that enable or disable experimental features. | ||
featureGates: | ||
# Enable running agent on a Virtual Machine. | ||
ExternalNode: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably call it "VirtualMachineNode".
e826128
to
75c76cf
Compare
cmd/antrea-agent/options.go
Outdated
if o.config.TunnelType == "" { | ||
o.config.TunnelType = defaultTunnelType | ||
} | ||
if o.config.ServiceCIDR == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this for VM? Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is to avoid agent crash on line 140 in cmd/antrea-agent/agent.go. o.config.ServiceCIDR
is used to parse the serviceCIDR directly. Maybe I should add feature gate check in that logic.
pkg/agent/config/node_config.go
Outdated
@@ -59,6 +59,13 @@ var ( | |||
VirtualServiceIPv6 = net.ParseIP("fc01::aabb:ccdd:eeff") | |||
) | |||
|
|||
type NodeType string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we often compare the values, probably use enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With feature gate, this is not ofen used in value comparasion. I want to keep string value because I planed to show the Node type in AntreaAgentInfo in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feature gate is not used in "inner" pkgs. Always converted to a boolean.
I mean if we compare the values in any frequent call path (e.g. when handling a new change from API or CNI), I think enum is better. If it is just used in bootstrapping, string is fine. Even for enum, you can add a String() func.
e34639d
to
03b3f2b
Compare
75c76cf
to
09edb18
Compare
|
||
func (o *Options) validateVMOptions() error { | ||
var unsupported []string | ||
for f, enabled := range o.config.FeatureGates { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There can be features not enabled by feature gate (e.g. encapMode, enableNodePortLocal whose feature gate is enabled by default). Could you check any such features should be validated here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you check all the options and no other unsupported options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made two changes:
- Add unsupported options check with
EnableIPSecTunnel
, although it is deprecated, theencryptionMode
is possibly changed to TrafficEncryptionModeIPSec if it is set as true - Set
encryptionMode
default value asTrafficEncryptionModeNone
in Options.run function, and load value from the configuration only when encapMode requires supporting Encap ( the ToT code actually has a useless configuration parsing with noEncap mode ).
pkg/agent/config/node_config.go
Outdated
@@ -59,6 +59,13 @@ var ( | |||
VirtualServiceIPv6 = net.ParseIP("fc01::aabb:ccdd:eeff") | |||
) | |||
|
|||
type NodeType string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feature gate is not used in "inner" pkgs. Always converted to a boolean.
I mean if we compare the values in any frequent call path (e.g. when handling a new change from API or CNI), I think enum is better. If it is just used in bootstrapping, string is fine. Even for enum, you can add a String() func.
pkg/util/env/env.go
Outdated
NodeNameEnvKey = "NODE_NAME" | ||
// ExternalNodeEnvKey is an environment variable used in ExternalNode feature to tell the expected name with which | ||
// antrea agent is running. This is also used in the shell where antctl is running on a VM host. | ||
ExternalNodeEnvKey = "EXTERNAL_NODE" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it just a name string? If so, why not reuse "NODE_NAME"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mainly for antctl support. I need a different env variable to tell antctl it is running on a VM but not a K8s Node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we assume antctl always runs in a container? If not, the env will not be set anyway right?
I feel better to use another env variable to indicate node type for antctl, and also add a parameter for antctl for the case it runs without an env.
pkg/util/env/env.go
Outdated
if nodeName != "" { | ||
return | ||
} | ||
klog.Infof("Environment variable %s not found, using hostname instead", ExternalNodeEnvKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to print NodeNameEnvKey?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NodeNameEnvKey is printed in line 56, maybe I should remove line 56 and change to NodeNameEnvKey in this line.
09edb18
to
f3804b9
Compare
/test-all |
f3804b9
to
178dfc7
Compare
/test-windows-e2e |
/test-conformance |
# The path to access the kubeconfig file used in the connection to Antrea Controller. The file contains the | ||
# antrea-controller APIServer endpoint and the token of ServiceAccount required in the connection. | ||
antreaClientConnection: | ||
kubeconfig: antrea-agent.antrea.kubeconfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wenyingd should we use helm to generate this file based on template? Otherwise we would need to update this file manually whenever there is a change to related parameters? I don't mean it needs to be done in this PR.
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
…3542) 1. Add feature gate for ExternalNode which enables running Agent on a VM or BM. 2. Support Agent running APIServer only on localhost if it is not running on cluster worker Node. 3. CNIServer is loaded only when Agent is running on cluster worker Node. 4. Use a seperate build directory to generate agent configrations for ExternalNode. Signed-off-by: wenyingd <wenyingd@vmware.com>
on a non-Kubernetes Node.
running on cluster worker Node.
Node.
Signed-off-by: wenyingd wenyingd@vmware.com