📖 Add alternative communication patterns feature group #7902
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
the
size/M
richardcase
force-pushed
the
feat_group_proxying
branch
2 times, most recently
from
023e341 to
71b708f
Compare
richardcase
force-pushed
the
feat_group_proxying
branch
from
71b708f to
532a084
Compare
| --- | ||
| # Alternative Communication Patterns Feature Group | ||
|
|
||
| This document briefly outlines the scope, communication media, and stakeholders for a formal Feature Group dedicated to defining a Cluster API-approved solution for supporting alternative communication patterns between the workload clusters and the management clusters as alternatives to the current model which is management cluster initiated direct connections. |
There was a problem hiding this comment.
Shall we also include the communication from providers to the infrastructure control plane in a disjoint network?
E.g. CAPV wants to create a cluster in a private vSphere, where the vSphere endpoint is not directly reachable from the management cluster.
There was a problem hiding this comment.
I agree and this was one of the main use cases from the original issue. I have changed the summary. This use case is listed in the user stories? Are the user stories sufficient to cover this?
|
|
||
| 1. A solution for managed clusters only, which does not require API-server connectivity from CAPI at all. | ||
| 1. The "common cluster as a service offering" scenario where only the workload clusters' worker nodes are in a different network. | ||
| 1. The scenario where a management cluster manages workload clusters (including control plane nodes), which are in a different network than the management cluster. |
There was a problem hiding this comment.
This is an interesting use case for us. We were able to successfully run a POC last year with unmodified CAPI controllers to create a workload cluster with a unidirectional network setup where the workload cluster machines had to establish the connection with the management cluster.
It relied on a SOCKS5 proxy and some additional config changes to generate the correct kubeconfig, but it would be awesome to have a simpler support for this.
I will join the meetings once those start.
There was a problem hiding this comment.
First meeting is planned for tomorrow (27th Jan 2023 @ 09:00 PT). It would be great to have your experience included in this 😄
|
praise for a well written charter, ping me when you want to merge it |
This change adds a doc to cover the new "alternative communication patterns" feature group. Signed-off-by: Richard Case <[email protected]>
richardcase
force-pushed
the
feat_group_proxying
branch
from
532a084 to
0139b60
Compare
|
I have made some slight alterations and added the meeting time to the doc. Feel free to comment here or we can discuss in the first meeting tomorrow. @fabriziopandini - i think this is good to go. |
richardcase
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: e62f2bb1a6acef5af9cc95dcabd0823f255fcf6c
|
|
Very interesting topic! /lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
What this PR does / why we need it:
This change adds a doc to cover the new "alternative communication patterns" feature group. This covers the scope and use cases that the group will be focused on.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Relates to #6520