🚀 feat: adds ReplicaSet in Deployments

[naineel1209]

closes #147

📑 Description

[BE]

• Added a new DTO, ReplicaSet, and its helper methods, which will be populated when fetching the details of the deployment.

[FE]

• Added a new progress bar which shows how many pods available from the active ReplicaSet in green and all the other pods from non-active ReplicaSet in blue

✅ Checks

• [✅] I have tested my code (provide screenshots or screen recordings of a working solution)
• [✅] I have performed a self-review of my code

ℹ Additional context

[naineel1209]

@quest-bot loot #147

[quest-bot]

Quest PR submitted!

@naineel1209, you are attempting to solve the issue and loot this Quest. Will you be successful?

---

Questions? Check out the docs.

[naineel1209]

Hey @petar-cvit, could you take a look at this and suggest any changes, if any?

[petar-cvit]

@naineel1209, thanks for the PR.

However, I wouldn't have a separate table for replicasets, because Kubernetes will by retain the last 10 replicasets of a deployment

Can we just add a progress bar to the existing pods table that would indicate how many pods are created from each replicaset. For example, if the rollout is in progress and 2 pods are managed from the old replicaset, and 3 are managed from the new one, then 2/5 of the progress bar would be blue (for old pods) and 3/5 is green

[naineel1209]

Hi @petar-cvit , I’ve updated the ReplicaSet structure to display as a progress bar (check the PR comment for screenshots). The green section represents available pods from the active ReplicaSet, while the blue section shows available pods from non-active ReplicaSets.

Currently, I’m identifying the active ReplicaSet by sorting the list received in the response, using the number of replicas (in descending order) and creation time (in ascending order). If this approach is not favorable, could you suggest any alternative strategies for determining the active ReplicaSet?

[petar-cvit]

@naineel1209 Looks awesome! You can actually find the latest replica in the status.conditions fro a condition of type Progressing and parse the replicaset name from the message. More info on deployment status here. From there, you can check which pods are managed from this replicaset.

I would prefer we infer it from here, not to call the k8s API once more to not bloat the endpoint.

From the UI standpoint, I would remove the numbers on the right since those are not accurate in some cases

[petar-cvit]

Also, I just stumbled upon this issue where pods are still pending and the progressbar is saying 1 active / 1 non-active / 2 total

[naineel1209]

Hi @petar-cvit, As per the suggestions, In the BE, I've added a new field, activeReplicaSet, in the mapDeployment method which returns us the active ReplicaSet. In the FE, I've added a check to find the active ReplicaSet from the ReplicaSet list. Additionally, I've removed the text on the right to the progress bar and replaced it with a <SyncOutlined spin /> while the replicaset is progressing and <CheckCircleOutlined /> when replicaset is completed, to provide the users with some visual feedback.

Screenshots

[petar-cvit]

@naineel1209 at first, it looked good, but when I restarted a deployment that specified 4 pods, and during rollout, there were six pods (2 from the new replicaset and four from the old one), the progress bar said 3 total, which doesn't match.

Can we make the desired number of replicas in deployment the total, and the green part would tell you how many replicas from the latest replicaset are healthy. If the pods of the new replicaset are unhealthy, they will still show blue.

Also, I would suggest that we don't query for replicasets separately but that we get it from the existing pods. Each pod will have a reference to its replicaset, so we don't have to ask K8s API for it. From there, you can just calculate (number of healthy pods) / (number of desired replicas in the deployment)

[naineel1209]

Hey @petar-cvit, could you please check out the blocking bug details on Discord? I've got a bug blocking the PR.

[petar-cvit]

@naineel1209 thanks for reporting it! We can solve it in a separate PR, and you can ignore it in this PR. If you render data based on the deployment state, we can just fix this bug in a separate PR.

[naineel1209]

Hi @petar-cvit, this PR is ready for review.