add a new ClusterIP allocator that uses the new IPAddress API resource
and an informer as the backend, instead a bitmap snapshotted on etcd.
Change-Id: Ia891a2900acd2682d4d169abab65cdd9270a8445
The pod_logs subsystem was inadvertently made redundant in the following
kube-apiserver metrics:
- kube_apiserver_pod_logs_pods_logs_backend_tls_failure_total
- kube_apiserver_pod_logs_pods_logs_insecure_backend_total
To safely rename them, it is required to deprecate them in 1.27 whilst
introducing the new metrics replacing them.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
1. Define ContainerResizePolicy and add it to Container struct.
2. Add ResourcesAllocated and Resources fields to ContainerStatus struct.
3. Define ResourcesResizeStatus and add it to PodStatus struct.
4. Add InPlacePodVerticalScaling feature gate and drop disabled fields.
5. ResizePolicy validation & defaulting and Resources mutability for CPU/Memory.
6. Various fixes from code review feedback (originally committed on Apr 12, 2022)
KEP: /enhancements/keps/sig-node/1287-in-place-update-pod-resources
The ClusterIP allocator tries to reserve on part of the ServiceCIDR
to allocate static IPs to the Services.
The heuristic of the allocator to obtain the offset was taking into
account the whole range size, not the IPs available in the range, the
subnet address and the broadcast address for IPv4 are not available.
This caused that for CIDRs with 16 hosts, /28 for IPv4 and /124 for
IPv6, the offset calculated was higher than the max number of available
addresses on the allocator, causing this to panic.
Change-Id: I6c6f527b0a600b3612be37769e405b8fb3dd33a8
The Services API should warn users about some IP addresses
representations, mainly because some of them are not allowed
by the golang std parsers since go 1.17
Specifically:
- IPv4 addresses with leading zeros, that may cause security risks
- IPv6 addresses in non canonical format, that may cause problems
with controllers hotlooping or cause security issues
Change-Id: Ife50a651d1b22dc4c318e42bd3e5f2e5f88ecbcd
LegacyBindingREST is only used for `bindings` resource. It is not
a subresource and that's why it is required to implement
`GetSingularName` function. However, there is no need to implement
this function for BindingREST because it is only used for binding
subresource.
That's why, this function statically adds GetSingularName for
LegacyBindingREST.
This introduces `singularNameProvider`. This provider will be used
by core types to have their singular names are defined in discovery
endpoint. Thanks to that, core resources singular name always have
higher precedence than CRDs shortcuts or singular names.
