Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Antctl "agent mode" support on Windows #2104

Closed
antoninbas opened this issue Apr 17, 2021 · 2 comments · Fixed by #3645
Closed

Antctl "agent mode" support on Windows #2104

antoninbas opened this issue Apr 17, 2021 · 2 comments · Fixed by #3645
Labels
area/component/antctl Issues or PRs releated to the command line interface component area/OS/windows Issues or PRs related to the Windows operating system. good first issue Good for newcomers kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@antoninbas
Copy link
Contributor

Describe the problem/challenge you have
I am not sure what the best way of running antctl in "agent mode" on Windows is.

  • Wins installation (docker only): we run the antrea-windows container on each Windows Node, but the image does not include antctl. If we were to include antctl, I assume we would be able to exec into the container and run antctl, like we do on Linux Nodes.
  • Nssm service installation (required for containerd support): there is no antrea-windows container in that case, so I would like to be able to run antctl directly from a shell on the Windows Node. This solution would work for the "Wins" case above as well, but is not as nice as being able to exec into a container and just invoke antctl, without having to install or configure anything.

Here is what I was able to do:

  1. download antctl for Windows and move it to a directory in the PATH, as per the antctl documentation

  2. set some PowerShell environment variables to trick antctl into running in "agent mode":

C:\k\antrea> $Env:POD_NAME="antrea-agent"
C:\k\antrea> $Env:KUBERNETES_SERVICE_HOST="30.0.0.1"
C:\k\antrea> $Env:KUBERNETES_SERVICE_PORT="443"

(not sure why the 2nd and 3rd one are required for agent mode)

  1. run antctl normally
C:\k\antrea> antctl get podinterfaces
NAMESPACE NAME               INTERFACE-NAME  IP         MAC               PORT-UUID                            OF-PORT CONTAINER-ID
tenant-a  iis-f78c74db-2mj7p iis-f78c-0eec11 20.0.3.189 00:15:5d:dc:a5:72 76933240-48d5-4da9-81e3-7f3b842d1e02 10      0a76b509afd
tenant-a  iis-f78c74db-x7rln iis-f78c-d5a481 20.0.3.188 00:15:5d:dc:a8:31 68d6d36b-d21b-4ba5-887b-e7a81cb5e362 11      b86a3e33d0a

I would like a way to eliminate step 2 if possible. If there is an easier way to do that, I didn't find it and we should document it.
@antoninbas antoninbas added kind/feature Categorizes issue or PR as related to a new feature. area/component/antctl Issues or PRs releated to the command line interface component area/OS/windows Issues or PRs related to the Windows operating system. good first issue Good for newcomers priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Apr 17, 2021
@antoninbas antoninbas mentioned this issue Jul 12, 2021
Merged
@github-actions
Copy link
Contributor

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment, or this will be closed in 180 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 15, 2021
@antoninbas antoninbas removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 15, 2021
@github-actions
Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 13, 2022
@antoninbas antoninbas removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 6, 2022
antoninbas added a commit to antoninbas/antrea that referenced this issue Apr 14, 2022
@antoninbas
Out-of-the-box "Agent mode" support for antctl
a82c88e 
At the moment is is possible to run antctl in Agent mode from a Windows
Node on which Antrea is runing, but it requires setting the following
environment variables manually:
```
> $Env:POD_NAME="antrea-agent"
> $Env:KUBERNETES_SERVICE_HOST="<ClusterIP>"
> $Env:KUBERNETES_SERVICE_PORT="443"
```

This is not very convenient and it is not documented
either. Additionally, there is no reason to require
KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT in Agent mode. This
requirement is caused by a bug in the antctl code: when antctl is
running inside a Pod, there is no need to resolve the "in-cluster"
Kubeconfig, as we generate this config manually to connect to the Antrea
API server.

In order to make antctl work out-of-the-box for that case, we change the
logic which decides what the antctl "runtime mode" is: if the antctl
binary is running on Windows and if a loopback client token exists, we
assume that this is a Windows Node which is running the Antrea Agent.

Fixes antrea-io#2104

Signed-off-by: Antonin Bas <abas@vmware.com>
@antoninbas antoninbas mentioned this issue Apr 14, 2022
Merged
antoninbas added a commit that referenced this issue Apr 18, 2022
@antoninbas
Out-of-the-box "Agent mode" support for antctl on Windows (#3645)
bd82ef6 
* Out-of-the-box "Agent mode" support for antctl

At the moment is is possible to run antctl in Agent mode from a Windows
Node on which Antrea is runing, but it requires setting the following
environment variables manually:
```
> $Env:POD_NAME="antrea-agent"
> $Env:KUBERNETES_SERVICE_HOST="<ClusterIP>"
> $Env:KUBERNETES_SERVICE_PORT="443"
```

This is not very convenient and it is not documented
either. Additionally, there is no reason to require
KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT in Agent mode. This
requirement is caused by a bug in the antctl code: when antctl is
running inside a Pod, there is no need to resolve the "in-cluster"
Kubeconfig, as we generate this config manually to connect to the Antrea
API server.

In order to make antctl work out-of-the-box for that case, we change the
logic which decides what the antctl "runtime mode" is: if the antctl
binary is running on Windows and if a loopback client token exists, we
assume that this is a Windows Node which is running the Antrea Agent.

Fixes #2104

Signed-off-by: Antonin Bas <abas@vmware.com>

* Run antctl e2e tests for clusters with Windows Nodes

Signed-off-by: Antonin Bas <abas@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/component/antctl Issues or PRs releated to the command line interface component area/OS/windows Issues or PRs related to the Windows operating system. good first issue Good for newcomers kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Out-of-the-box "Agent mode" support for antctl on Windows antoninbas/antrea
1 participant
@antoninbas