Add admin endpoint to list Kubernetes objects in Hive-managed AKS clusters#4559
Add admin endpoint to list Kubernetes objects in Hive-managed AKS clusters#4559cadenmarchese merged 25 commits intomasterfrom
Conversation
cadenmarchese
left a comment
There was a problem hiding this comment.
This is a good start! It looks like you've configured the endpoint and are validating the request. Now we will need to implement this HiveK8sObjectManager so that it will LIST or GET the k8s objects in the regional AKS clusters on behalf of the RP. Once you've done that, you will be able to set up some unit testing.
To do the implementation, I would follow the same pattern as the /kubernetesobjects / List or Get Kubernetes Objects geneva action (currently in prod) where we can pass a kind, namespace, and name. From there, the action would do a list if no name is provided, or alternately do a get if a name is provided.
Check out pkg/frontend/admin_openshiftcluster_kubernetesobjects.go for a good example to use here.
|
There was a problem hiding this comment.
We're getting closer, but we're not functional yet. Here are a few specific things we need for this PR:
- Since you're opening your first PR here, you will need to accept the CLA.
- You will need to test your code by running a local RP. The instructions can be found here.
- Ensure that Hive environment variables (ARO_INSTALL_VIA_HIVE, HIVE_KUBE_CONFIG_PATH) are set and valid before you run the binary. You'll also need to connect to the Hive AKS VPN so that your RP can talk to the AKS cluster.
- You can test other admin actions by curling the ARO-RP directly as shown here - in your case, it will be something like
curl -X GET -k "https://localhost:8443/admin/hive/k8sobjects/namespaces"and so on. You don't actually need to create a dev cluster to test your changes because we're querying an already-existing AKS cluster. - Once you have locally verified that your route is working and successfully returning the k8s objects, you'll have to resolve any failing CI. We can do that by investigating logs from any failed jobs. Here's an example from the most recent run: https://github.com/Azure/ARO-RP/pull/4559/checks?check_run_id=61528339305
If you get stuck on anything along the way please feel free to reach out in the team channel and we'll be happy to assist!
|
@microsoft-github-policy-service agree company="redhat" |
|
Please rebase pull request. |
4ef342a to
723c2bc
Compare
…troduce HiveK8sObjectManager with unit tests
83f983c to
6a5815d
Compare
|
@copilot please review |
|
@rajdeepc2792 I've opened a new pull request, #4694, to work on those changes. Once the pull request is ready, I'll request review from you. |
kimorris27
left a comment
There was a problem hiding this comment.
LGTM! Rajdeep had mentioned that there's potential for an E2E test, but I could go either way on that.
rajdeepc2792
left a comment
There was a problem hiding this comment.
The functionality looks good, the dynamicClient initialization seems repetitive as we already have the client under the frontend object. It would be great to move the list/get functions to the hiveclustermanager and use the exisiting client to reach Hive AKS Cluster.
…sters (#4559) Authored-by: b-lnimmala <b-lnimmala@microsoft.com> Co-authored-by: Caden Marchese <56140267+cadenmarchese@users.noreply.github.com>
This PR introduces a "new admin-only endpoint" in ARO-RP that allows listing Kubernetes objects from "Hive-managed AKS clusters" without SSH or break-glass.
Right now, if we want to debug a Hive-managed AKS cluster in prod, the only option is:
• SSH into RP VMSS
• Login to Azure
• Get kubeconfig
• Install kubectl
• Use break-glass / elevated JIT
Adds a new admin API handler that lists Kubernetes objects for:
• a specific region
• an optional namespace
• a given resource type (pods, nodes, deployments, etc.)
A new abstraction called HiveK8sObjectManager:
• Handles all logic for fetching k8s objects from Hive clusters
• Keeps Hive-specific logic out of the frontend handlers
• Makes the code easier to test and extend later
The manager is wired into the frontend:
• Passed into NewFrontend as a dependency
• Treated as nil when it’s not configured or not needed
Updates to existing frontend tests:
• Added nil placeholders where this new dependency isn’t required
• Ensures there is no behavior change for existing admin or customer APIs
What this PR does NOT do (out of scope)
Follow-up steps after merge