Convert Figma logo to code with AI

txn2 logokubefwd

Bulk port forwarding Kubernetes services for local development.

3,755
203
3,755
25

Top Related Projects

Local development against a remote Kubernetes or OpenShift cluster

3,235

Develop your applications directly in your Kubernetes Cluster

open source Kubernetes-native API gateway for microservices built on the Envoy Proxy

1,970

kubernetes log viewer

17,537

Faster way to switch between clusters and namespaces in kubectl

Quick Overview

Kubefwd is a command-line utility that bulk forwards Kubernetes services for local development. It allows developers to access services in remote Kubernetes clusters as if they were running locally, simplifying the development and testing process for distributed applications.

Pros

  • Simplifies local development by making remote Kubernetes services accessible locally
  • Supports bulk forwarding of multiple services simultaneously
  • Works with any Kubernetes cluster, including managed services like EKS, GKE, and AKS
  • Provides a user-friendly CLI interface for easy configuration and management

Cons

  • Requires sudo privileges to modify local DNS settings, which may be a security concern
  • Can potentially conflict with existing local services using the same ports
  • May introduce latency when accessing services, depending on network conditions
  • Limited to forwarding services only, not other Kubernetes resources

Getting Started

To get started with Kubefwd, follow these steps:

  1. Install Kubefwd:

    brew install txn2/tap/kubefwd
    
  2. Ensure you have a valid Kubernetes configuration file (~/.kube/config).

  3. Forward all services in a namespace:

    sudo kubefwd services -n mynamespace
    
  4. Access the forwarded services locally using their service names as hostnames.

For more detailed instructions and advanced usage, refer to the project's GitHub repository: https://github.com/txn2/kubefwd

Competitor Comparisons

Local development against a remote Kubernetes or OpenShift cluster

Pros of Telepresence

  • More comprehensive solution for local development, allowing developers to run services locally while connected to a remote Kubernetes cluster
  • Supports intercept functionality, enabling selective routing of traffic to local development environment
  • Offers a CLI and desktop GUI for easier management and visualization

Cons of Telepresence

  • More complex setup and configuration compared to kubefwd
  • Requires installation of additional components on the cluster, potentially increasing security concerns
  • May have a steeper learning curve for new users due to its advanced features

Code Comparison

kubefwd:

sudo kubefwd services -n mynamespace

Telepresence:

telepresence connect
telepresence intercept my-service --port 8080:80

Both tools aim to simplify local development with Kubernetes, but Telepresence offers a more feature-rich solution at the cost of increased complexity. kubefwd focuses primarily on port-forwarding services, making it simpler to use for basic scenarios. Telepresence provides a more comprehensive development environment, allowing developers to run and debug services locally while maintaining seamless integration with the remote cluster.

3,235

Develop your applications directly in your Kubernetes Cluster

Pros of Okteto

  • Provides a complete development environment in Kubernetes, not just port forwarding
  • Supports live code synchronization and remote development
  • Offers a collaborative platform for team development

Cons of Okteto

  • More complex setup and learning curve compared to simpler port forwarding tools
  • Requires more resources as it creates development environments in the cluster

Code Comparison

Kubefwd usage:

sudo -E kubefwd services -n namespace

Okteto usage:

okteto up
okteto down

Okteto offers a more comprehensive development workflow, while Kubefwd focuses solely on port forwarding. Okteto requires more configuration but provides a richer feature set for Kubernetes development. Kubefwd is simpler to use for basic port forwarding needs.

Okteto is better suited for teams working on complex Kubernetes applications, while Kubefwd is ideal for developers who need quick access to services in a Kubernetes cluster without additional features.

Both tools serve different purposes within the Kubernetes ecosystem, with Okteto offering a more integrated development experience and Kubefwd providing a straightforward solution for port forwarding.

open source Kubernetes-native API gateway for microservices built on the Envoy Proxy

Pros of Emissary

  • Full-featured API Gateway and Ingress Controller for Kubernetes
  • Supports advanced traffic management and routing capabilities
  • Offers built-in authentication and rate limiting features

Cons of Emissary

  • More complex setup and configuration compared to Kubefwd
  • Requires additional resources to run as a separate service in the cluster
  • Steeper learning curve for users new to API gateways

Code Comparison

Kubefwd (port-forward configuration):

spec:
  containers:
  - name: kubefwd
    image: txn2/kubefwd
    args:
    - -n default
    - -l app=myapp

Emissary (basic routing configuration):

apiVersion: getambassador.io/v2
kind: Mapping
metadata:
  name: example-mapping
spec:
  prefix: /example/
  service: example-service

Kubefwd is a simple tool for port-forwarding Kubernetes services to localhost, while Emissary is a comprehensive API Gateway and Ingress Controller. Kubefwd is easier to set up and use for basic port-forwarding needs, but Emissary offers more advanced features for managing and securing API traffic in Kubernetes environments. The code examples demonstrate the simplicity of Kubefwd's configuration compared to Emissary's more detailed routing setup.

1,970

kubernetes log viewer

Pros of kail

  • Focuses specifically on log streaming from Kubernetes pods
  • Supports filtering logs by various criteria (labels, containers, etc.)
  • Provides real-time log tailing functionality

Cons of kail

  • Limited to log-related operations only
  • Doesn't offer port-forwarding capabilities
  • May require additional tools for comprehensive cluster management

Code Comparison

kail:

cmd := &cobra.Command{
    Use:   "kail",
    Short: "Kubernetes tail",
    Run:   run,
}

kubefwd:

cmd := &cobra.Command{
    Use:   "kubefwd services",
    Short: "Forward kubernetes services",
    Long:  `Forward multiple Kubernetes services from one or more namespaces.`,
    Run:   runServices,
}

Key Differences

  • kubefwd primarily focuses on port-forwarding Kubernetes services
  • kail specializes in log streaming and filtering
  • kubefwd offers broader cluster connectivity features
  • kail provides more granular control over log output

Use Cases

  • Use kail for efficient log monitoring and debugging
  • Choose kubefwd for local development and testing of services
  • Combine both tools for a comprehensive development workflow

Community and Maintenance

  • Both projects are open-source and actively maintained
  • kail has a slightly larger community and more frequent updates
  • kubefwd offers extensive documentation and usage examples
17,537

Faster way to switch between clusters and namespaces in kubectl

Pros of kubectx

  • Simpler and more focused tool for managing Kubernetes contexts and namespaces
  • Lightweight and easy to install with minimal dependencies
  • Provides shell completion for faster and more convenient usage

Cons of kubectx

  • Limited functionality compared to kubefwd, focusing only on context and namespace switching
  • Doesn't provide direct service forwarding capabilities
  • May require additional tools for more advanced Kubernetes operations

Code Comparison

kubectx:

kubectx my-cluster
kubens my-namespace

kubefwd:

sudo kubefwd services -n my-namespace

Key Differences

kubectx is a lightweight tool for managing Kubernetes contexts and namespaces, while kubefwd focuses on forwarding Kubernetes services to local ports. kubectx is ideal for users who frequently switch between different clusters or namespaces, whereas kubefwd is more suited for developers who need to access services running in a Kubernetes cluster from their local machine.

kubectx offers a simpler and more focused approach to context and namespace management, making it easier to use for specific tasks. On the other hand, kubefwd provides more advanced functionality for service forwarding, which can be crucial for local development and testing of Kubernetes-based applications.

While both tools serve different purposes, they can be complementary in a Kubernetes workflow. Users may find value in using both kubectx for quick context switching and kubefwd for local service access, depending on their specific needs and development processes.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

English|中文

Kubernetes port forwarding for local development.

NOTE: Accepting pull requests for bug fixes, tests, and documentation only.

kubefwd - kubernetes bulk port forwarding

Build Status GitHub license Go Report Card GitHub release

kubefwd (Kube Forward)

Read Kubernetes Port Forwarding for Local Development for background and a detailed guide to kubefwd. Follow Craig Johnston on Twitter for project updates.

kubefwd is a command line utility built to port forward multiple services within one or more namespaces on one or more Kubernetes clusters. kubefwd uses the same port exposed by the service and forwards it from a loopback IP address on your local workstation. kubefwd temporally adds domain entries to your /etc/hosts file with the service names it forwards.

When working on our local workstation, my team and I often build applications that access services through their service names and ports within a Kubernetes namespace. kubefwd allows us to develop locally with services available as they would be in the cluster.

kubefwd - Kubernetes port forward

kubefwd - Kubernetes Port Forward Diagram

OS

Tested directly on macOS and Linux based docker containers.

MacOs Install / Update

kubefwd assumes you have kubectl installed and configured with access to a Kubernetes cluster. kubefwd uses the kubectl current context. The kubectl configuration is not used. However, its configuration is needed to access a Kubernetes cluster.

Ensure you have a context by running:

kubectl config current-context

If you are running MacOS and use homebrew you can install kubefwd directly from the txn2 tap:

brew install txn2/tap/kubefwd

To upgrade:

brew upgrade kubefwd

Windows Install / Update

scoop install kubefwd

To upgrade:

scoop update kubefwd

Docker

Forward all services from the namespace the-project to a Docker container named the-project:

docker run -it --rm --privileged --name the-project \
    -v "$(echo $HOME)/.kube/":/root/.kube/ \
    txn2/kubefwd services -n the-project

Execute a curl call to an Elasticsearch service in your Kubernetes cluster:

docker exec the-project curl -s elasticsearch:9200

Alternative Installs (tar.gz, RPM, deb)

Check out the releases section on Github for alternative binaries.

Contribute

Fork kubefwd and build a custom version. Accepting pull requests for bug fixes, tests, stability and compatibility enhancements, and documentation only.

Usage

Forward all services for the namespace the-project. Kubefwd finds the first Pod associated with each Kubernetes service found in the Namespace and port forwards it based on the Service spec to a local IP address and port. A domain name is added to your /etc/hosts file pointing to the local IP.

Update

Forwarding of headlesss Service is currently supported, Kubefwd forward all Pods for headless service; At the same time, the namespace-level service monitoring is supported. When a new service is created or the old service is deleted under the namespace, kubefwd can automatically start/end forwarding; Supports Pod-level forwarding monitoring. When the forwarded Pod is deleted (such as updating the deployment, etc.), the forwarding of the service to which the pod belongs is automatically restarted;

sudo kubefwd svc -n the-project

Forward all svc for the namespace the-project where labeled system: wx:

sudo kubefwd svc -l system=wx -n the-project

Forward a single service named my-service in the namespace the-project:

sudo kubefwd svc -n the-project -f metadata.name=my-service

Forward more than one service using the in clause:

sudo kubefwd svc -l "app in (app1, app2)"

Help

$ kubefwd svc --help

INFO[00:00:48]  _          _           __             _     
INFO[00:00:48] | | ___   _| |__   ___ / _|_      ____| |    
INFO[00:00:48] | |/ / | | | '_ \ / _ \ |_\ \ /\ / / _  |    
INFO[00:00:48] |   <| |_| | |_) |  __/  _|\ V  V / (_| |    
INFO[00:00:48] |_|\_\\__,_|_.__/ \___|_|   \_/\_/ \__,_|    
INFO[00:00:48]                                              
INFO[00:00:48] Version 0.0.0                                
INFO[00:00:48] https://github.com/txn2/kubefwd              
INFO[00:00:48]                                              
Forward multiple Kubernetes services from one or more namespaces. Filter services with selector.

Usage:
  kubefwd services [flags]

Aliases:
  services, svcs, svc

Examples:
  kubefwd svc -n the-project
  kubefwd svc -n the-project -l app=wx,component=api
  kubefwd svc -n default -l "app in (ws, api)"
  kubefwd svc -n default -n the-project
  kubefwd svc -n default -d internal.example.com
  kubefwd svc -n the-project -x prod-cluster
  kubefwd svc -n the-project -m 80:8080 -m 443:1443
  kubefwd svc -n the-project -z path/to/conf.yml
  kubefwd svc -n the-project -r svc.ns:127.3.3.1
  kubefwd svc --all-namespaces

Flags:
  -A, --all-namespaces          Enable --all-namespaces option like kubectl.
  -x, --context strings         specify a context to override the current context
  -d, --domain string           Append a pseudo domain name to generated host names.
  -f, --field-selector string   Field selector to filter on; supports '=', '==', and '!=' (e.g. -f metadata.name=service-name).
  -z, --fwd-conf string         Define an IP reservation configuration
  -h, --help                    help for services
  -c, --kubeconfig string       absolute path to a kubectl config file
  -m, --mapping strings         Specify a port mapping. Specify multiple mapping by duplicating this argument.
  -n, --namespace strings       Specify a namespace. Specify multiple namespaces by duplicating this argument.
  -r, --reserve strings         Specify an IP reservation. Specify multiple reservations by duplicating this argument.
  -l, --selector string         Selector (label query) to filter on; supports '=', '==', and '!=' (e.g. -l key1=value1,key2=value2).
  -v, --verbose                 Verbose output.

License

Apache License 2.0

Sponsor

Open source utility by Craig Johnston, imti blog and sponsored by Deasil Works, Inc.

Please check out my book Advanced Platform Development with Kubernetes: Enabling Data Management, the Internet of Things, Blockchain, and Machine Learning.

Book Cover - Advanced Platform Development with Kubernetes: Enabling Data Management, the Internet of Things, Blockchain, and Machine Learning

Source code from the book Advanced Platform Development with Kubernetes: Enabling Data Management, the Internet of Things, Blockchain, and Machine Learning by Craig Johnston (@cjimti) ISBN 978-1-4842-5610-7 Apress; 1st ed. edition (September, 2020)

Read my blog post Advanced Platform Development with Kubernetes for more info and background on the book.

Follow me on Twitter: @cjimti (Craig Johnston)

Please Help the Children of Ukraine

UNICEF is on the ground helping Ukraine's children, please donate to https://www.unicefusa.org/ <- "like" this project by donating.