Replies: 2 comments 1 reply
-
|
I like the feature. I'm wondering who/which component should be responsible of the provisioning of the infrastructure needed to expose the Konnectivity server (i.e. public IP, NAT gateway, etc.). |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I think we don't need to add this feature since it can be easily achieved using an additional Ingress or Service, and using the provided hostname or IP added to the @bsctl let me know if we can close this. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Some of the Managed Kubernetes Services out there, e.g.
AKS,IKS, provide a public Cluster Endpoint, e.g.https://35.41.67.241:443to expose the Control Plane to the public Internet, used bykubectlfrom users, and a private Cluster Endpoint, e.g.https://10.10.100.12:6443to expose the Control Plane in the private network where worker nodes are placed.The Konnectivity-server Endpoint, port
8132, is also exposed to the Public Internet, if you want join worker nodes placed on a remote datacenter or another cloud or, most likely, it's only exposed to the private network.For example, on
IKS:This proposal is to introduce the same concept in Kamaji and should be part of the refactoring work for the
tcp.spec.networkProfileas stated in #48Beta Was this translation helpful? Give feedback.
All reactions