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
A subnet created with an invalid CIDR causes the kube-ovn-cni pods to panic and enter a crashloopbackoff.
Instead, there should be validation on the API and the kubectl command to create the subnet with the inccorect cidr should fail, with a clear message explaining that the CIDR block was of the wrong format.
In addition, there should be validation in the kube-ovn code, so that if it tries to parse a CIDR block and it can't, it handles the error and does not panic.
@isabelleatkins Hello there! I'm Dosu, a bot here to help you with any bugs, questions, or contributions. Let's tackle this issue together!
To address the issue of invalid CIDR blocks causing the kube-ovn-cni pods to panic and enter a crashloopbackoff, you can implement validation in the Kube-OVN API and code. Here are some steps and existing mechanisms that can help:
Validation in the API: Implement validation checks in the Kube-OVN API to ensure that invalid CIDR blocks are not accepted. The ValidateSubnet function in pkg/util/validator.go already includes several validation checks for CIDR blocks, such as ensuring the CIDR is a valid format and that the gateway is within the CIDR block [1].
Error Handling in CIDR Parsing: The AddOrUpdateSubnet function in pkg/ipam/ipam.go handles CIDR parsing and logs errors if the CIDR format is invalid. This function should be enhanced to ensure that any invalid CIDR blocks are caught and handled gracefully, preventing panics [2].
Webhook Configurations: Use existing webhook configurations in pkg/webhook/subnet.go to validate subnet configurations during creation and updates. These webhooks can prevent invalid configurations from being applied [3].
Error Handling in kube-ovn-cni: The kube-ovn-cni pod should handle errors related to CIDR parsing by logging warnings and continuing without adding the problematic CIDR to the list of addresses. This is done in the AddressSetUpdateAddress function, which logs a warning if a CIDR cannot be parsed [4].
By implementing these validation and error-handling mechanisms, you can prevent invalid CIDR blocks from causing the kube-ovn-cni pods to panic and enter a crashloopbackoff.
Kube-OVN Version
v1.11.5
Kubernetes Version
v1.28.6
Operation-system/Kernel Version
"Ubuntu 22.04.5 LTS"
5.15.0-124-generic
Description
A subnet created with an invalid CIDR causes the kube-ovn-cni pods to panic and enter a crashloopbackoff.
Instead, there should be validation on the API and the kubectl command to create the subnet with the inccorect cidr should fail, with a clear message explaining that the CIDR block was of the wrong format.
In addition, there should be validation in the kube-ovn code, so that if it tries to parse a CIDR block and it can't, it handles the error and does not panic.
Pod in crashloopbackoff yaml:
Logs on kube-ovn-cni pod:
Steps To Reproduce
kubectl apply -f subnet.yaml
kubectl get pods -n kube-system
and see the kube-ovn-cni pods in crashloopbackackoffCurrent Behavior
Panics, and the kube-ovn-cni pod enters a crashloopbackoff.
Pod in crashloopbackoff yaml:
Logs on kube-ovn-cni pod:
Expected Behavior
Kubectl command to apply the subnet with the incorrect CIDR fails with clear message as to why e.g. "Invalid CIDR Block: should be of form ..."
The text was updated successfully, but these errors were encountered: