Add Metrics for EndpointSlices

[mrueg]

What this PR does / why we need it:
Implements https://pkg.go.dev/k8s.io/api/discovery/v1#EndpointSlice
Metrics from endpointslices can be used to identify if specific pods are part of an endpoint and thus discoverable through a service.

kube_endpointslice_info{endpointslice="my-app-75zcw",addresstype="IPv4"} 1
kube_endpointslice_created{endpointslice="my-app-75zcw"} 1.605287362e+09
kube_endpointslice_endpoints{endpointslice="my-app-75zcw",ready="true",serving="true",terminating="false",targetref_kind="Pod",targetref_name="my-app-73967648-75dgx",targetref_namespace="my-namespace",endpoint_nodename="my-node",endpoint_zone="west",address="192.168.1.1"} 1
kube_endpointslice_ports{endpointslice="my-app-75zcw",port_name="http",port_protocol="TCP",port_number="8080"} 1

How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
This resource type is disabled by default as they are very verbose and have a high cardinality.

[fpetkovski]

/lgtm
/hold

[dgrisonnet]

/lgtm
/unhold

[dgrisonnet]

/hold

[dgrisonnet]

Suggested change

	LabelKeys: []string{"port_name", "port_protocol", "port_number"},
	LabelKeys: []string{"name", "protocol", "number"},

Prefixing the labels by port feels a bit redundant

[dgrisonnet]

I noticed afterward that we inherit that choice from the endpoint metrics: https://github.com/kubernetes/kube-state-metrics/blob/master/docs/endpoint-metrics.md.

There is not much we can do about it anymore I guess.

[mrueg]

Yep, initially I would have preferred to keep it shorter as well, then decided to stay consistent with endpoints.

[dgrisonnet]

I think we are plumbing too maybe information inside of this metric. What would you think about moving the conditions, targetref and addresses into their own metrics? There are some precedence to that kind of split with statuses metrics and kube_endpoint_address.

[mrueg]

I decided to combine everything in it that is in https://pkg.go.dev/k8s.io/api/discovery/v1#Endpoint (which is used in
https://pkg.go.dev/k8s.io/api/discovery/v1#EndpointSlice). This would make it easier for users to query it instead of combining two or more metrics. Do you see any downsides?

[dgrisonnet]

/lgtm cancel
/unhold

[logicalhan]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fpetkovski, logicalhan, mrueg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fpetkovski,mrueg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment