Creating a gateway
Identify the management cluster endpoint
Obtain the hostname and CA certificate for the management cluster:
Specify a workspace namespace
Obtain the desired workspace namespace on the management cluster for the tunnel gateway:
Alternatively, if you wish to create a new workspace instead of using an existing workspace:
You can verify the workspace exists using:
Create a tunnel gateway
Create a tunnel gateway on the management cluster to listen for tunnel agents on remote clusters:
You can verify the gateway exists using the command:
Connecting a remote cluster
Create a tunnel connector
Create a tunnel connector on the management cluster for the remote cluster:
You can verify the connector exists using:
Wait for the tunnel connector to reach Listening
state and then export the agent manifest:
Create a network policy for the tunnel server
This step is optional, but improves security by restricting which remote hosts can connect to the tunnel.
Apply a network policy that restricts access to the tunnel to specific namespaces and IP blocks. The following example permits connections from pods running in the kommander-federation
, kommander
, and kubeaddons
namespaces, from pods running in namespaces with a label kubetunnel.d2iq.io/networkpolicy
matching the tunnel name and namespace, and to remote clusters with IP addresses in the ranges 192.0.2.0 to 192.0.2.255 and 203.0.113.0 to 203.0.113.255:
Setup the managed cluster
Copy the manifest.yaml
file to the managed cluster and deploy the tunnel agent:
You can check the status of the created pods using:
After a short time, expect to see a post-kubeconfig
pod that reaches Completed
state and a tunnel-agent
pod that stays in Running
state.
Add the managed cluster into Kommander
On the management cluster, wait for the tunnel to be connected by the tunnel agent:
Add the cluster into Kommander:
Wait for the managed cluster to join the Kommander cluster:
Using a remote cluster
To access services running on the remote cluster from the management cluster, connect to the tunnel proxy.
You can use these three methods:
- If the client program supports use of a kubeconfig file, use the managed cluster’s kubeconfig.
- If the client program supports SOCKS5 proxies, use the proxy directly.
- Otherwise, deploy a proxy server on the management cluster.
Managed cluster service
These sections require a service to run on the managed cluster.
As an example, start the following service:
On the managed cluster, a client Job can access this service using:
The final command returns the default Nginx web page:
Use of kubeconfig file
This is primarily useful for running kubectl
commands on the management cluster to monitor the managed cluster.
On the management cluster, a kubeconfig
file for the managed cluster configured to use the tunnel proxy is available as a Secret. The Secret’s name can be identified using:
After setting service_namespace
and service_name
to the managed service resource, on the management cluster run:
Direct use of SOCKS5 proxy
To use the SOCKS5 proxy directly, obtain the SOCKS5 proxy endpoint using:
Provide the value of ${socks_proxy}
as the SOCKS5 proxy to your client.
For example, since curl
supports SOCKS5 proxies, the managed service started above can be accessed from the management cluster by adding the SOCKS5 proxy to the curl
command. After setting service_endpoint
to the service endpoint, on the management cluster run:
The final command returns the same output as for the job on the managed cluster, demonstrating that the job on the management cluster accessed the service running on the managed cluster.
Use of deployed proxy on management cluster
To deploy a proxy on the management cluster, obtain the SOCKS5 proxy endpoint using:
Provide the value of ${socks_proxy}
as the SOCKS5 proxy to a proxy deployed on the management cluster. After setting service_endpoint
to the service endpoint, on the management cluster run:
Any client running on the management cluster can now access the service running on the managed cluster using the proxy service endpoint. Note in the following that the curl
job runs in the same namespace as the proxy, to provide access to the CA certificate secret.
The final command returns the same output as the job on the managed cluster, demonstrating that the job on the management cluster accessed the service running on the managed cluster.