Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Introduce multicluster proxy mode for Kubeapps APIs #5468

Open
castelblanque opened this issue Oct 17, 2022 · 0 comments
Open

Introduce multicluster proxy mode for Kubeapps APIs #5468

castelblanque opened this issue Oct 17, 2022 · 0 comments
Labels
component/multi-cluster Issue related to multi-cluster configuration kind/feature An issue that reports a feature (approved) to be implemented
Milestone
Multi-cluster sup...

Comments

@castelblanque
Copy link
Collaborator

castelblanque commented Oct 17, 2022 •
edited
Loading

Summary
Introduce a new setup for installing Kubeapps in which Kubeapps APIs can act as a proxy for all incoming requests to another Kubeapps APIs.

Background and rationale
As decided in the Multicluster redesign document, Kubeapps will be required to be present in all workload clusters of a multicluster setup. At least Kubeapps APIs with plugins.
The Kubeapps installation in charge of managing the multicluster (acting as a control plane) will have Kubeapps API in a "proxy" mode in which al business-related requests (e.g. create repo, list available packages, etc.) will be proxied as-is to the selected workload/target cluster.

Target cluster will expose a Kubeapps APIs that will receive those proxied requests, not needed to expose the K8s APIs endpoint.

Acceptance criteria

  • Clusters set up for multicluster (clusters: value in chart) allow to provide, per cluster, the Kubeapps endpoint and not the K8s API endpoint.
  • Chart has a flag value to start Kubeapps APIs with proxy mode enabled.
  • Requests to Kubeapps APIs that have a specific header (to be decided) are proxied to the target cluster, instead of being processed internally. Only applies when the target cluster is different from the current cluster, and target cluster is among the list specified in charts value clusters:.
  • All possible operations are computed by the target Kubeapps APIs and not the source Kubeapps APIs.
@kubeapps-bot kubeapps-bot moved this to 🗂 Backlog in Kubeapps Oct 17, 2022
@castelblanque castelblanque added kind/feature An issue that reports a feature (approved) to be implemented component/multi-cluster Issue related to multi-cluster configuration labels Oct 17, 2022
@castelblanque castelblanque self-assigned this Oct 17, 2022
@castelblanque castelblanque added this to the Multi-cluster support milestone Oct 17, 2022
@castelblanque castelblanque moved this from 🗂 Backlog to 🗒 Todo in Kubeapps Oct 17, 2022
@castelblanque castelblanque moved this from 🗒 Todo to 🏗 In Progress in Kubeapps Oct 18, 2022
This was referenced Oct 20, 2022
Closed
Merged
@castelblanque castelblanque moved this from 🏗 In Progress to 🔎 In Review in Kubeapps Oct 21, 2022
@castelblanque castelblanque mentioned this issue Oct 21, 2022
Closed
castelblanque added a commit that referenced this issue Oct 26, 2022
@castelblanque
Add Kubeapps setup for headless (API-only mode) (#5543)
b401c1b 
### Description of the change

Adds a new chart flag `ingress.apiOnly.enabled` that allows to deploy
Kubeapps with an ingress setup that only allows API calls to:
- `/apis` using `http`
- `/` using `grpc`

When the mode is enabled, the default ingress used so far is not
deployed.
Instead deploys two ingresses:
- `kubeapps` ingress with path `/` and protocol `grpc`
- `kubeapps-http-api` ingress with path `/apis`

There is a requirement and enforcement message to disable the dashboard,
as `/` path will not be available to serve it.

### Benefits

- Kubeapps can be used in API-only mode:
  - REST calls can still be made
  - Also GRPC calls can be made, e.g. 

  ```bash
  export APIHOST=<INGRESS_HOSTNAME>:<INGRESS_PORT>
grpcurl $APIHOST
kubeappsapis.core.plugins.v1alpha1.PluginsService.GetConfiguredPlugins
  ```

- It might also be beneficial for development, as there won't be the
need to do port-forward to use GRPC.
- Does not change default behavior

### Possible drawbacks

This forces the user to disable the dashboard, as it will be unusable
when the API mode is on. We could remove the requirement, but users
might complain when trying to access dashboard.

### Applicable issues

- related to #5468

Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@castelblanque castelblanque moved this from 🔎 In Review to 🏗 In Progress in Kubeapps Oct 27, 2022
@castelblanque castelblanque moved this from 🏗 In Progress to 🚧 Blocked in Kubeapps Oct 28, 2022
@ppbaena ppbaena moved this from 🚧 Blocked to 🗂 Backlog in Kubeapps Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component/multi-cluster Issue related to multi-cluster configuration kind/feature An issue that reports a feature (approved) to be implemented
Projects
Kubeapps
Status: 🗂 Backlog
Milestone
Multi-cluster support
Development

No branches or pull requests
2 participants
@castelblanque and others