-
Notifications
You must be signed in to change notification settings - Fork 306
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
[Question] AKS created using a custom VNET without a route table is failing when trying to reach a service located in a different namespace. #3973
Comments
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment. |
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment. |
1 similar comment
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment. |
Action required from @Azure/aks-pm |
Action required from @chasewilson. |
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment. |
This issue will now be closed because it hasn't had any activity for 7 days after stale. acano-arrive feel free to comment again on the next 7 days to reopen or open a new issue after that time if you still have a question/issue or suggestion. |
Describe scenario
I have an AKS configured using a custom vnet with 3 subnets:
Admin subnet is used for admin nodepool
App subnet is used for applications nodepool
NSG: Default ports
Route table: No exist
Question
Within the same namespace, calls to {servicename} should work. For a call across namespaces, calls to {servicename}.{namespace} should work. For all calls, the fully qualified domain name {servicename}.{namespace}.svc.cluster.local should work.
Currently, only the FQDN seems to be working.
/home/app # nslookup team-service.team-dev.svc.cluster.local
Server: 10.201.0.10
Address: 10.201.0.10:53
Name: team-service.team-dev.svc.cluster.local
Address: 10.201.0.129
/home/app # nslookup team-service.team-dev
Server: 10.201.0.10
Address: 10.201.0.10:53
** server can't find location-service.tso-dev: NXDOMAIN
** server can't find location-service.tso-dev: NXDOMAIN
Not sure how can I fix this.
The text was updated successfully, but these errors were encountered: