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.

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

BYO Networking Oddities (or PEBKAC?) #5262

Open
junkiebev opened this issue Nov 11, 2024 · 0 comments
Open

BYO Networking Oddities (or PEBKAC?) #5262

junkiebev opened this issue Nov 11, 2024 · 0 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@junkiebev
Copy link

junkiebev commented Nov 11, 2024

/kind bug

What steps did you take and what happened:
It could be that I'm just not reading the documentation correctly, but I'm attempting to use BYO Networking (networks and subnets exist, they all have routing tables and NAT Gateways already) to roll out a CAPZ cluster. The virtual networks exist in a different resource group, however they are in the same subscription. As this is an enterprise environment, the network settings are not fully user-configurable.

I observe the following when using spec.networkSpec.apiServerLB.type: Internal and altering the KubeadmConfigTemplates to inject a record for the apiserver in /etc/hosts

  • a node route table will be created, and not referenced (the vnet/subnet already has a route table)
    • If I reference the route table by name, it will be created in the resource group of the cluster, not that of AzureCluster.spec.networkSpec.vnet.resourceGroup
    • This does not appear to be the case on the control-plane subnet
    • This resource is not cleaned up when I delete the cluster
  • A NAT gateway will be created, but never used (because it's not tied to a specific network)
    • It does not appear to be possible to opt out of the resource creation
  • A private DNS zone will be created which is never used
    • The DNS is set and not configurable on the subnet's definition - VNET injection only works if you use the Azure Provided DNS
    • The configuration is not needed because I'm setting the host record in /etc/hosts in a preKubeAdm command for all config templates
    • It does not appear to be possible to opt out of the resource creation

What did you expect to happen:

  • I believe the node route table should be able to be discovered if one brings their own network - I think this might just be a bug
  • It should be possible to opt out of the NAT gateway creation if one brings their own network
  • The Private Zone (as far as I can determine?) is only required to propagate the apiserver host record. In a world where that's done by writing a line to /etc/hosts, it's not needed and it should be possible to opt-out of the creation.

Anything else you would like to add:
This has been really cool to use!

Environment:

NAME                    NAMESPACE                           TYPE                     CURRENT VERSION   NEXT VERSION
addon-helm              caaph-system                        AddonProvider            v0.2.6            Already up to date
bootstrap-kubeadm       capi-kubeadm-bootstrap-system       BootstrapProvider        v1.8.5            Already up to date
control-plane-kubeadm   capi-kubeadm-control-plane-system   ControlPlaneProvider     v1.8.5            Already up to date
cluster-api             capi-system                         CoreProvider             v1.8.5            Already up to date
infrastructure-azure    capz-system                         InfrastructureProvider   v1.17.1           Already up to date
  • cluster-api-provider-azure version: v1.17.1
  • Kubernetes version: (use kubectl version): 1.30.3
  • OS (e.g. from /etc/os-release): Ubuntu 22.04.5 LTS (assuming you mean on the bootstrap source?)
@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
Status: Todo
Development

No branches or pull requests

2 participants