-
Notifications
You must be signed in to change notification settings - Fork 575
Description
Bug description
If a CRD defined via protobuf contains a primitive int64/uint64 field, it will be impossible to set using kubernetes client-go. The API server will log a validation error along these lines:
spec.subsets[0].trafficPolicy.loadBalancer.consistentHash.maglev.tableSize: Invalid value: "string": spec.subsets[0].trafficPolicy.loadBalancer.consistentHash.maglev.tableSize in body must be of type integer: "string""
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
Expected behavior
The expected behavior is that the resource will be created without API errors.
I would suggest either of the following solutions:
- Add the cue-gen:DestinationRule:intOrString:xxx option
- Change the uint64 to uint32 in the destination_rule.proto file, specifically in the ConsistentHashLB message:
message ConsistentHashLB {
message RingHash {
// The minimum number of virtual nodes to use for the hash
// ring. Defaults to 1024. Larger ring sizes result in more granular
// load distributions. If the number of hosts in the load balancing
// pool is larger than the ring size, each host will be assigned a
// single virtual node.
uint32 minimum_ring_size = 1;
};
message MagLev {
// The table size for Maglev hashing. This helps in controlling the
// disruption when the backend hosts change.
// Increasing the table size reduces the amount of disruption.
// The table size must be prime number less than 5000011.
// If it is not specified, the default is 65537.
uint32 table_size = 1;
};
...
}
Steps to reproduce the bug
- Define a CRD using protobuf that includes primitive int64 or uint64 fields.(e.g. tableSize field of DestinationRule)
- Attempt to create an instance of this CRD using kubernetes client-go.
- Observe the validation error in the API server logs.
Version (include the output of istioctl version --remote
and kubectl version
)
- istioctl version --remote: 1.16.1
- kubectl version: v1.25.2
How was Istio installed?
istioctl
Environment where bug was observed (cloud vendor, OS, etc)
MacOS sequoia v15.1.1
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.