feat: add redisreplication status masterNode

[drivebyer]

Description

Add redisreplication status masterNode

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• Tests have been added/modified and all tests pass.
• Functionality/bugs have been confirmed to be unchanged or fixed.
• I have performed a self-review of my own code.
• Documentation has been updated or added where necessary.

Additional Context

[codecov]

Codecov Report

Attention: Patch coverage is 19.35484% with 25 lines in your changes are missing coverage. Please review.

Project coverage is 38.08%. Comparing base (d121d86) to head (f923e05).
Report is 15 commits behind head on master.

Files	Patch %	Lines
controllers/redisreplication_controller.go	0.00%	17 Missing ⚠️
k8sutils/redis.go	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #849      +/-   ##
==========================================
+ Coverage   35.20%   38.08%   +2.88%     
==========================================
  Files          19       19              
  Lines        3213     2649     -564     
==========================================
- Hits         1131     1009     -122     
+ Misses       2015     1569     -446     
- Partials       67       71       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wkd-woo]

Hello @drivebyer :) !!!
Could it be a feature of the same purpose as the Pull Request I previously requested? #785

[drivebyer]

@wkd-woo At first glance, they may seem identical, but they actually serve different purposes. With this pull request, we can obtain the conclusion status from a custom resource without having to delve into the details of the pod.

[wkd-woo]

Thank you for your response! @drivebyer
Actually, there were some problems with the features I added.

As you said, the feature I requested was a workflow in the form of diving in and out of the pod, so it took a lot of time for reconcilers to update the "master" label after failover (about 1 minute)

This was too fatal to be applied in a production environment in reality. It means that HA outages take more than a minute to access a single endpoint as a service.

It would be great if this PR merges. Thanks!

---

• I have an additional question, I'm not a k8s expert, so I'm asking, then is it possible to access master/slave from outside the cluster as a single endpoint through service?

[shubham-cmyk]

@drivebyer can we try some failover testing here and check who is the master now

[drivebyer]

@drivebyer can we try some failover testing here and check who is the master now

Sure

[drivebyer]

It would be great if this PR merges. Thanks!

I would review it.

[drivebyer]

@shubham-cmyk, I tested it on my local k8s setup(sentinel + replication). The status gets updated to the new master once the old master pod is killed.

[shubham-cmyk]

LGTM