cluster-api-provider-aws
cluster-api-provider-aws copied to clipboard
Creating Route Table using AWSManagedControlPlane
/kind bug
What steps did you take and what happened: I am trying to create the Route Table with subnet association where routeTableId is defined using the below config , but the routeTableId is ignored and controller created the default new route table.
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: AWSManagedControlPlane
metadata:
name: capi-eks-quickstart-control-plane
namespace: default
spec:
associateOIDCProvider: true
bastion:
allowedCIDRBlocks:
- 0.0.0.0/0
enabled: true
eksClusterName: name-provided-cluster
endpointAccess:
private: true
public: true
kubeProxy:
disable: false
logging:
apiServer: true
audit: false
authenticator: true
controllerManager: true
scheduler: true
network:
subnets:
- availabilityZone: eu-west-3a
cidrBlock: 10.10.11.0/24
id: hpe-public-subnet-0
isPublic: true
routeTableId: hpe-public-subnet-rt
tags:
Name: hpe-public-subnet-0
kubernetes.io/cluster/name-provided-cluster: shared
kubernetes.io/role/elb: "1"
- availabilityZone: eu-west-3b
cidrBlock: 10.10.21.0/24
id: hpe-public-subnet-1
isPublic: true
routeTableId: hpe-public-subnet-rt
tags:
Name: hpe-public-subnet-1
kubernetes.io/cluster/name-provided-cluster: shared
kubernetes.io/role/elb: "1"
- availabilityZone: eu-west-3a
cidrBlock: 10.10.10.0/24
id: hpe-ctrlp-subnet-0
isPublic: false
routeTableId: hpe-ctrlp-subnet-rt
tags:
Name: hpe-ctrlp-subnet-0
kubernetes.io/cluster/name-provided-cluster: shared
kubernetes.io/role/internal-elb: "1"
- availabilityZone: eu-west-3b
cidrBlock: 10.10.20.0/24
id: hpe-ctrlp-subnet-1
isPublic: false
routeTableId: hpe-ctrlp-subnet-rt
tags:
Name: hpe-ctrlp-subnet-1
kubernetes.io/cluster/name-provided-cluster: shared
kubernetes.io/role/internal-elb: "1"
- availabilityZone: eu-west-3a
cidrBlock: 10.10.17.0/24
id: hpe-wnodk1-subnet-0
isPublic: false
routeTableId: hpe-wnodk1-subnet-rt
tags:
Name: hpe-wnodk1-subnet-0
vpc:
availabilityZoneSelection: Ordered
availabilityZoneUsageLimit: 1
cidrBlock: 10.10.0.0/16
tags:
Name: capi-eks-quickstart-vpc
region: eu-west-3
sshKeyName: terraform-aws3-key
tokenMethod: iam-authenticator
version: v1.23.0
vpcCni:
disable: false
What did you expect to happen: It is expected that new route table
- is created with routeTableId name provided,
- should have subnet association with subnets in which same routeTableId name is used.
Anything else you would like to add: Currently one subnet is associated with one route table, one subnet -to-one route table association , e.g, 5 subnets, 5 Route Tables mapped one-to-one.
Environment:
- Cluster-api-provider-aws version: v2.3.0
- Kubernetes version: (use
kubectl version): 1.27.3 - OS (e.g. from
/etc/os-release): Ubuntu 22.04.3
This issue is currently awaiting triage.
If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.