#2168 WatchKube discovery provider

[kick2nick]

Closes #2168

• Kubernetes service discovery provider based on watch requests #2168

Proposed Changes

• WatchKube service discovery provider that utilizes k8s watch api requests for efficient detection of changes.

It's proof of concept that needs improvements (see comments) and tests.
Tested locally, it works as expected, but with older versions of KubeClient which can be used with newer one after fix tintoy/dotnet-kube-client#163.

[raman-m]

Nikolay, thank you for your submission. Please note that this pull request is not yet ready for code review. I recommend marking it as a draft and proceeding with the development.

Tested locally, it works as expected, but with older versions of KubeClient which can be used with newer one after fix tintoy/dotnet-kube-client#163.

🆗 Consequently, we must await the official resolution of the issue in the integrated library and resume development post-release of the fix.
It is a standard strategy to upgrade to the latest version; hence, we consistently utilize the most recent package version, which is currently v2.5.10, as referenced here:

Ocelot/src/Ocelot.Provider.Kubernetes/Ocelot.Provider.Kubernetes.csproj

Lines 32 to 33 in 414f634

	<PackageReference Include="KubeClient" Version="2.5.10" />
	<PackageReference Include="KubeClient.Extensions.DependencyInjection" Version="2.5.10" />

Downgrading the version is not an option❕
My suggestion is to prioritize addressing the bug at tintoy/dotnet-kube-client#163: reach out to the repository owner and designate this PR as a draft. Best of luck!

P.S.

Please be aware that the PR may be merged in 2 or more releases, and it might not be included in the November'24 release. Note that with the .NET 9 release scheduled for November, the delivery timeline is uncertain due to the concurrent release of the .NET 9 edition of dotnet-kube-client. Additionally, I believe it's unfeasible to develop this feature within two weeks for inclusion in the October'24 release. It appears to be impossible.

[raman-m]

P.P.S

feature branch: kick2nick:develop

It's your decision, but the best practice is to always create a separate feature branch from develop, since develop is the default branch of the fork that needs to be synchronized with the upstream repository.