Skip to content

A team focused tool to connect to Kubernetes service, ingress and nodes ports and replace services with local ports.

License

Notifications You must be signed in to change notification settings

vicjicaman/linker-tool

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
 
 
 
 
 
 
 
 

Repository files navigation

linker-tool

A team focused tool to connect to Kubernetes service, ingress and nodes ports and replace services with local ports.

Features

Expose/Forward

  • Kubernetes service port TCP/HTTP/HTTPS to its original host:port url.
  • Kubernetes service port to a localhost port.
  • The ingress 80 and 443 ports.
  • Node ports.
  • Automatic updates of /etc/hosts file (If readable/writable).
  • Play/stop multiple services per session.

Team port sharing

  • Expose your local ports available for your team to connect locally
  • Link local services to replace a kubernetes service.

Link/replace services

  • Replace any service port with a team member port
  • Review and get the env variables of the linked services

Pivot servers

  • Register multiple server to forward the ports
  • Dedicate a pivot server per team or functionality like copy files
  • Pivot server could could be intranet or in the cloud

Tool in action

How it works?

  • Cluster handler: This is a service running on the cluster in charge of forward a ssh port to a pivot server, you can have multiple cluster handler pods and pivot servers to have a nice and stable tunnels across multiple teams and dev workloads.
  • Pivot server: This is another server that acts as a common connectivity point bettween the cluster and the linkers, it is in charge of expose the ssh connection from the cluster handler to the linker users, the pivot can be an static IP, intranet IP or hostname, as long as the linkers and the cluster can reach the pivot.
  • Linkers: Those developers whose want to forward the cluster services to their localhost, share their local services with the cluster or other linkers, the linker-tool is in charge of the local linker functionality previously listed (There could be more elaborated cases where a cluster is a linker to another cluster)
  • Linker user: Keep the relation of the pivots, the cluster and their linkers, generate the cluster and pivot connector scripts and their tokens, there is no need to connect to the linker account once the tokens and scripts are generated, you could be completly offline or in a isolated network and the cluster/pivot/linker will work, the account is only for script and token generation to help with the auth and coordination of cluster, pivots and linkers, the tokens are an extra security layer for the cluster links.

Requeriments

  • node v10.13
  • docker v19.03
  • docker-compose v1.20

Getting started

  • Download the latest linker-tool release and run the start.sh script
curl -fsSL https://github.com/vicjicaman/linker-tool/archive/v1.70.1-master.tar.gz | tar -xzv
./start.sh

We are merging this tool with the core of the tunnel-tool to remove the need to get an user account and token. this will be completly selfhosted on your cluster and localhost, but you can still get an account in the meantime.

  • Get a linker user Repoflow linker login.
  • Create the pivot and the cluster handler
  • Configure and run the pivot docker-compose and create the namespace cluster handler

FAQ

Where are the ssh keys stored and shared? A ssh key is generated inside your cluster handler as a secret, is up to you handle and share the keys with the allowed linkers, **we don't store/access any key to any cluster, node, pivot server**

Why do I need an user account? The linker generate tokens to help with the coordination of the cluster services, the pivot servers and handle the relation of the user that are allowed to a given cluster handler. To connect to a cluster handler you will need the ssh keys and the linker token, an authorized user would need to have both.

Do I need to keep a connection to the linker account service to use this tool? No, you only need to contact the remote service during the login and token generation, the tokens are an extra security layer for the cluster links.

Checkout our other tools and resources focused on increase the developers productivity working with multiple services and kubernetes.

  • repoflow-tool: A tool focused on the development workflow with kubernetes and multiple repositories.
  • microservices: A blog about it's own development and evolution running on kubernetes.

About

A team focused tool to connect to Kubernetes service, ingress and nodes ports and replace services with local ports.

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages