You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.
Template successfully created, but any deployed windows containers were unable to access the internet. Was able to resolve ips from host names (dns worked), but unable to connect to sites outside the cluster (cannot connect to google even). Whats odd was that the windows nodes running the containers was able to connect to the internet. The outbound connectivity issue seemed limited to the containers themselves.
What you expected to happen:
Containers should have access to the internet, especially since the nodes do have access.
How to reproduce it (as minimally and precisely as possible):
Deploy a cluster with windows nodes on a custom vnet.
Anything else we need to know:
The only extra step was that I did manually update the azuredeploy.json file to add a "subnet" parameter because of this known issue: #1767
The text was updated successfully, but these errors were encountered:
Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
Version: v0.20.7
GitCommit: da4127d
GitTreeState: clean
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes
I created a cluster with windows nodes using the below template
What happened:
Template successfully created, but any deployed windows containers were unable to access the internet. Was able to resolve ips from host names (dns worked), but unable to connect to sites outside the cluster (cannot connect to google even). Whats odd was that the windows nodes running the containers was able to connect to the internet. The outbound connectivity issue seemed limited to the containers themselves.
What you expected to happen:
Containers should have access to the internet, especially since the nodes do have access.
How to reproduce it (as minimally and precisely as possible):
Deploy a cluster with windows nodes on a custom vnet.
Anything else we need to know:
The only extra step was that I did manually update the azuredeploy.json file to add a "subnet" parameter because of this known issue: #1767
The text was updated successfully, but these errors were encountered: